[03:03] kasc_ (n=kasc@dslb-084-060-104-202.pools.arcor-ip.net) joined #rocklinux.
[03:10] kasc (n=kasc@dslb-084-060-104-105.pools.arcor-ip.net) left irc: Read error: 110 (Connection timed out)
[03:10] Nick change: kasc_ -> kasc
[04:41] stf^rocklinux (n=user@heim-037-186.raab-heim.uni-linz.ac.at) left irc: "using sirc version 2.211+KSIRC/1.3.12"
[04:44] stf^rocklinux (n=user@heim-037-186.raab-heim.uni-linz.ac.at) joined #rocklinux.
[06:11] stf^rocklinux (n=user@heim-037-186.raab-heim.uni-linz.ac.at) left irc: "using sirc version 2.211+KSIRC/1.3.12"
[06:14] stf^rocklinux (n=user@heim-037-186.raab-heim.uni-linz.ac.at) joined #rocklinux.
[06:20] stf^rocklinux (n=user@heim-037-186.raab-heim.uni-linz.ac.at) left irc: "using sirc version 2.211+KSIRC/1.3.12"
[06:23] stf^rocklinux (n=user@heim-037-186.raab-heim.uni-linz.ac.at) joined #rocklinux.
[06:38] stf^rocklinux (n=user@heim-037-186.raab-heim.uni-linz.ac.at) left irc: Remote closed the connection
[06:43] stf^rocklinux (n=user@heim-033-18.raab-heim.uni-linz.ac.at) joined #rocklinux.
[07:31] blindcod1r (i=blindcod@tor/session/direct/x-86393039d35e634a) joined #rocklinux.
[07:31] blindcoder (i=blindcod@tor/regular/blindcoder) left irc: Nick collision from services.
[09:08] Nick change: blindcod1r -> blindcoder
[09:41] [raphael] (n=raphael@raphael.netpark.at) joined #rocklinux.
[09:41] <[raphael]> moin
[09:41] <[raphael]> So my build is no completed, but its not a ROCK Linux, but only a ROCK
[09:42] <[raphael]> without the linux
[09:42] <[raphael]> you really managed to get the linux24 kernel broken
[09:42] <[raphael]> it doesn't compile for some odd reason
[09:46] <[raphael]> and... I
[09:46] <[raphael]> I'm quite suspicious that the build would have worked even if linux24 compiled, because somehow the linux-clib-headers are only available for kernel 2.6
[09:46] <[raphael]> are you not supporting linux24 anymore? then you should remove the package and all the options for it
[09:48] <[raphael]> anyway, the log is here: http://raphael.g-system.at/secret/5-linux24.err
[09:52] <blindcoder> I don't think anyone has done a 24 build in a long time
[09:52] <blindcoder> it _is_ obsolete
[09:58] <[raphael]> blindcoder: not if you use drivers that only work with 2.4
[09:58] <[raphael]> but, I'm thinking of porting the driver over to netbsd anyway
[09:59] <blindcoder> what driver is it?
[09:59] <[raphael]> CAN bus controller
[09:59] <[raphael]> the intel one
[09:59] <[raphael]> let's see.... the URL is
[09:59] <[raphael]> http://ar.linux.it/software/index.html#ocan
[10:00] <[raphael]> there is another one, but its not maintained anymore: http://home.wanadoo.nl/arnaud/index.html
[10:00] <[raphael]> both of them only work with kernel 2.2 or 2.4
[10:00] <[raphael]> regarding the target system I already have a running NetBSD on there, that worked out of the box (isn't that cute?)
[10:00] <[raphael]> but NetBSD does not have a CAN bus driver
[10:01] <[raphael]> so the option is either to get some linux working there or port the driver to NetBSD
[10:02] <[raphael]> blindcoder: but if linux24 is (obviously) not supported anymore, then please remove it completely, it is only leading uneducated people like me to broken builds
[10:02] <blindcoder> sounds like a plan
[10:03] <[raphael]> and... are the RTAI patches working for linux 2.6 ?
[10:03] <[raphael]> anyone tested that?
[10:03] <blindcoder> [raphael]: they haven't been tested in ages, too
[10:04] <blindcoder> [raphael]: the one maintaining them has retired
[10:04] <[raphael]> I see
[10:04] <[raphael]> well, then I'll either use a plain old rock 2.0 or port the driver to netbsd
[10:06] <blindcoder> why not port the driver to 2.6?
[10:09] <[raphael]> 2.6 is not stable enough IMO
[10:09] <[raphael]> its a moving target
[10:09] <[raphael]> and, I don't have any 2.6 around
[10:10] <blindcoder> I see
[10:11] <[raphael]> another reason might be that I'm interested in NetBSD driver development
[10:12] <[raphael]> and this might be a good chance to really get into it
[10:14] <blindcoder> that it is
[10:14] <blindcoder> andwhy pass up ona good chance?
[10:14] <[raphael]> yes... :)
[10:16] <[raphael]> especially because its going to be a critical production system I want to use something that is really stable, well maintained and defined (i.e. netbsd "3.0" compared to linux m.n with gcc x.y, glibc a.b, ...)
[10:19] <blindcoder> well, SuSE 10.1 is well defined
[10:19] <blindcoder> as is RHEL x.y
[10:21] <[raphael]> yes, indeed
[10:21] <[raphael]> and both use kernel 2.6
[10:23] <[raphael]> and I only have 64 MB
[10:26] <[raphael]> .... and I just checked, its probably easier to get your hands on a NetBSD 1.0 than on a SuSE... 6.4 for example
[10:28] <[raphael]> I hope this doesn't sound insulting
[10:28] <[raphael]> no operating system is the best solution for everything, not even netbsd
[10:29] <blindcoder> no offense taken
[10:37] <th> .
[10:37] <blindcoder> !
[10:40] <th> ha!
[10:40] <th> in a full rebuild with rev6 and the pcmciautils - the pcmciautils fails
[10:40] <th> Apply patch /ROCK/package/base/pcmciautils/ln_path.patch ...
[10:40] <th> patching file Makefile
[10:40] <th> Hunk #1 FAILED at 73.
[10:42] <blindcoder> that's why I deleted it
[10:42] <blindcoder> isn't it in the patch?
[10:42] <th> i guess i missed that
[10:44] <blindcoder> right, it's missing in the patch
[10:44] <th> i'll commit it hotfixed then. no need for changing the patch
[10:44] <blindcoder> my bad
[10:46] <blindcoder> thanks
[10:50] <stf^rocklinux> moin
[10:51] <stf^rocklinux> raphael: the linux24 build error is a typical gcc4 error, caused by stricter C syntax...
[10:51] <stf^rocklinux> raphael: either look for a gcc4 patchset for linux24, or use e.g. gcc34 as your default compiler
[10:53] <stf^rocklinux> afaict the linux-libc-headers does not pose special problems with linux24.
[10:54] <stf^rocklinux> err, [raphael], not raphael... see above :)
[11:03] <th> btw - stf^rocklinux did you test the rev6 iso yet?
[11:03] <th> or blindy?
[11:04] <stf^rocklinux> th: yes. I've marked two then untested patches as tested yesterday ;)
[11:05] <th> stf^rocklinux: so you did the full testing things, so that we can say "this journal does not introduce new bugs"?
[11:05] <stf^rocklinux> th: and I
[11:05] <stf^rocklinux> th: and I'm happy to say I haven't found any new bugs
[11:05] <th> okay - this should be enough for committing, agreed?
[11:06] <stf^rocklinux> th: yes, I've done the usual full install in qemu, with user creation, KDE startup, and all.
[11:06] <th> ok cool
[11:07] <stf^rocklinux> :)
[11:09] <th> do  you remember the two patches in your journal that got swapped?
[11:10] <stf^rocklinux> hmm
[11:10] <stf^rocklinux> yes
[11:10] <th> it was about initrd
[11:10] <th> i manually applied them instead of changing the order...
[11:10] <th> so now when applying i should better reorder
[11:11] <th> 2006053023244423861
[11:11] <stf^rocklinux> th: in my journal they are already in order
[11:11] <th> that was one of them
[11:12] <stf^rocklinux> the other one must have been 2006053023195723512
[11:12] <th> ahh of course
[11:12] <th> and thelatter must be first
[11:12] <stf^rocklinux> yes
[11:16] <stf^rocklinux> th: when you apply the journal, please also apply 2006060919234023684 (it updates rockinitrd version)
[11:18] <th> ok
[11:18] <stf^rocklinux> thx
[11:19] <th> +               CONFIG_INPUT_JOYSTICK=y
[11:19] <th> that's not possible with module?
[11:20] <stf^rocklinux> it's an option that does not directly affect the binary kernel image, but it allows joystick modules to be built.
[11:20] <th> ahhh
[11:20] <th> ok
[11:20] <stf^rocklinux> short answer: no ^^
[11:20] <th> ;-]
[11:22] <th> journal applied hotfixes follow.
[11:26] <th> -               echo "Can't find required program '$P'! Aborting..."
[11:26] <th> +               echo "Can't find program $P! Aborting..."
[11:26] <th> which patch was that?
[11:26] <th> thats not in the journal..
[11:26] <th> confuses me
[11:27] <stf^rocklinux> that's 2006053023244423861
[11:27] <stf^rocklinux> but reversed o_O
[11:27] <th> ahhh - that's because i manually applied it first - and i missed the literal change
[11:29] <th> ok that's it
[11:32] <stf^rocklinux> so there's a few more (more or less important) bugfixes in SubMaster...
[11:32] <th> yea i'm just about to inspect submaster :)
[11:32] <th> i'd like to have that sound-oss thing in the next journal ithink
[11:34] <th> stf^rocklinux: do i understand it correctly that 2006041211494029578 is only introducing an option which is off by default?
[11:35] <stf^rocklinux> yes, the default gcc package will also include a gcc-autopch script, that's all.
[11:35] <stf^rocklinux> but it doesn't affect default builds.
[11:36] <th> and coud you work (mail) on cliff to include 2006042618320016732 upstream?
[11:37] <stf^rocklinux> hm, I found that it's not really needed... I think I'll discard it when my latest livecd build has finished
[11:37] <th> "KDE 3.5.3 supports cups 1.2"
[11:37] <th> ahhh :-)
[11:38] <stf^rocklinux> their changelog says so ;)
[11:38] <th> kde updates haven't been very hard...
[11:38] <th> do we need/want the cups update?
[11:39] <stf^rocklinux> It's already there, but I suggest not to include any updates.
[11:39] <stf^rocklinux> I mean KDE 3.5.3 is in SM
[11:39] <th> but our current pace is good.
[11:39] <th> and these two updates look alluring but still doable.
[11:40] <stf^rocklinux> well, we gotta release sometime. Updates tend to be tricky sometimes (and in an unpredictable way) :S
[11:41] <th> even for such small things like kde? ;->
[11:41] <th> i would not dare the x11 thing
[11:41] <stf^rocklinux> And I don't have much time hunting more bugs during the next weeks :(
[11:43] <stf^rocklinux> well, I admit kde updates have always been one of the least troublesomes, but I haven't checked the dependencies...
[11:45] <th> and i guess we should do the udev thing, no?
[11:46] <stf^rocklinux> I suggest to skip the updates, we're basically in a state of feature freeze imo, it would be a bad habit to update anything now.
[11:46] <th> ok
[11:46] <th> even kernel?
[11:47] <stf^rocklinux> hm, yes.
[11:48] <th> okay
[11:48] <th> so i'm just going through the personal and public things now
[11:50] <stf^rocklinux> ok
[11:50] <th> how about 2006060919220923600?
[11:50] <th> udev oss thing
[11:52] <th> should have no critical impact
[11:52] <th> if the thing itself works
[11:53] <stf^rocklinux> I've tested the udev rules here and they work as expected
[11:53] <th> and it's based on 092?
[11:54] <stf^rocklinux> yes
[11:54] <th> ok
[11:54] <stf^rocklinux> it's not perfect but loads oss compat modules for all added devices of the sound SUBSYSTEM
[11:54] <th> btw - did we finally fix the duplicate initilisation of loopback interface?
[11:55] <stf^rocklinux> no idea...
[11:55] <th> so do you get a :-( in your qemu on bootup?
[11:55] <stf^rocklinux> IIRC yes
[11:55] <stf^rocklinux> (network related)
[11:56] <th> this thing sucks from a PR point of view
[11:57] <stf^rocklinux> yeah, but after all we're the "admin-friendly distribution", and "warnings can be ignored" :)
[11:57] <th> gaaa
[11:57] stf^rocklinux (n=user@heim-033-18.raab-heim.uni-linz.ac.at) left irc: Read error: 104 (Connection reset by peer)
[11:57] <th> bye admin
[12:09] <th> vanilla r7663 build started
[12:14] stf^rocklinux (n=user@heim-033-18.raab-heim.uni-linz.ac.at) joined #rocklinux.
[12:20] stf^rocklinux (n=user@heim-033-18.raab-heim.uni-linz.ac.at) left irc: Read error: 104 (Connection reset by peer)
[12:20] stf^rocklinux (n=user@heim-033-18.raab-heim.uni-linz.ac.at) joined #rocklinux.
[12:23] <stf^rocklinux> th: it looks like that each of these two lines in /etc/init.d/system has an exit status != 0:
[12:23] <stf^rocklinux>         ip addr add dev lo || error=$?
[12:23] <stf^rocklinux>         ip route add 127/8 dev lo || error=$?
[12:24] <stf^rocklinux> I don't really know if they're needed or could be left out...
[12:24] <SMP> at some 2.6 version the kernel was changed so that lo already had that address assigned by the kernel
[12:25] <SMP> I'm trying to find out which one ...
[12:25] <stf^rocklinux> SMP: nevermind, as long as these lines are obsolete.
[12:25] <stf^rocklinux> :)
[12:26] <SMP> *sigh*
[12:26] <[raphael]> stf^rocklinux: just a question, does a linux 2.4 really work, what about devfs and devd?
[12:28] <stf^rocklinux> hm, I've switched to  linux26 relatively late, and we still have the devfs package (but you have to enable it in stone IIRC, it's not the default anymore)
[12:28] <stf^rocklinux> I think the first linux26 kernel that completely worked on my hardware was ~ 2.6.12
[12:29] <stf^rocklinux> (no picture with TV card problem)
[12:30] <stf^rocklinux> [raphael]: what do you mean with devd?
[12:31] <[raphael]> ... I'll give it one more try, with gcc 3.4 and devfs enabled, although switching compiler means a full rebuild
[12:31] <[raphael]> stf^rocklinux: devd: the devfs daemon, probably included(?) in the devfs package
[12:31] <SMP> that was called devfsd
[12:32] <SMP> "dev.d" was a 2.6 thing that existed maybe months
[12:32] <[raphael]> I see, so its different to FreeBSD (it's devd there AFAIK)
[12:32] <stf^rocklinux> never heard of devd before...
[12:32] stf^rocklinux (n=user@heim-033-18.raab-heim.uni-linz.ac.at) left irc: Read error: 104 (Connection reset by peer)
[12:32] <SMP> s,months,2 &,
[12:36] <daja77_> [raphael]: there are rtai patches for 2.6 for a long a time, i haven't tested them because I don't need rtai any longer, but i think they'll work, they have always been quite quick with supporting newer kernels
[12:37] <[raphael]> ic
[12:38] <daja77_> btw isn't it easier to port that driver to 2.6?
[12:45] <[raphael]> daja77_: I don't know, at least I have no knowledge about linux driver architecture, and not having this I prefer to learn about NetBSD drivers first
[12:46] <daja77_> ic
[12:46] <[raphael]> and I have a bad feeling about 2.6 since its not yet (interface) stable
[12:46] <[raphael]> and I had some frightening experiences with 2.6
[12:48] <daja77_> at least there are docs how to port from 2.4 to 2.6 now
[12:49] <[raphael]> ok... started a generic build (minimal package selection + devfs + bash3 + gcc34 + linux24) of rock-src svn 7663
[12:57] stf^rocklinux (n=user@heim-033-18.raab-heim.uni-linz.ac.at) joined #rocklinux.
[13:39] <th> [raphael]: please let us know of the results
[14:17] [raphael] (n=raphael@raphael.netpark.at) left irc: Read error: 104 (Connection reset by peer)
[14:17] [raphael] (n=raphael@raphael.netpark.at) joined #rocklinux.
[16:34] treo (n=xfman@C800a.c.pppool.de) joined #rocklinux.
[17:16] [raphael] (n=raphael@raphael.netpark.at) left irc: Read error: 104 (Connection reset by peer)
[17:26] [raphael] (n=raphael@raphael.netpark.at) joined #rocklinux.
[17:27] <[raphael]> th: sure
[17:28] <[raphael]> 102 builds total, 60 completed fine, 0 with errors.
[17:28] <[raphael]> ... so far
[17:34] |treo| (n=xfman@C800a.c.pppool.de) joined #rocklinux.
[17:47] treo (n=xfman@C800a.c.pppool.de) left irc: Read error: 113 (No route to host)
[18:18] treo (n=xfman@C800a.c.pppool.de) joined #rocklinux.
[18:37] |treo| (n=xfman@C800a.c.pppool.de) left irc: Read error: 113 (No route to host)
[19:12] |treo| (n=xfman@C800a.c.pppool.de) joined #rocklinux.
[19:14] |treo| (n=xfman@C800a.c.pppool.de) left irc: Client Quit
[19:29] treo (n=xfman@C800a.c.pppool.de) left irc: Read error: 110 (Connection timed out)
[20:13] <[raphael]> 102 builds total, 94 completed fine, 0 with errors.
[20:14] <[raphael]> 5-linux24 already built :)
[20:15] <stf^rocklinux> nice :)
[20:16] [raphael] (n=raphael@raphael.netpark.at) left irc: Read error: 104 (Connection reset by peer)
[20:16] [raphael] (n=raphael@raphael.netpark.at) joined #rocklinux.
[20:17] <[raphael]> stf^rocklinux: well, the thing is that I actually don't want to spend any time on the driver
[20:17] <[raphael]> so, if it works with that build then all is fine, at least for now
[20:18] <[raphael]> (this is also the reason why I don't want to spend time porting it to 2.6)
[20:22] <stf^rocklinux> [raphael: I see. You might need to explicitly enable the modutils package for linux 2.4 modules.
[20:23] <stf^rocklinux> (should be ok if you just add it and re-run Build-Target)
[20:28] <[raphael]> stf^rocklinux: hmm.... I thought the options only had the linux 2.6 modutils, but nothing for the 2.4 (built by default)
[20:28] <[raphael]> ?
[20:28] <[raphael]> or is it another "normal" package that I have to X ?
[20:29] <stf^rocklinux> yes, modutils (the linux26 package for module handling is called module-init-tools)
[20:30] <[raphael]> I see, thanks for letting me know (I'd be surprised if it can't load modules on startup, and I would be rather upset)
[20:31] <stf^rocklinux> np
[21:49] daja77 (n=daja77@dslb-088-072-032-124.pools.arcor-ip.net) joined #rocklinux.
[22:01] daja77_ (n=daja77@dslb-088-072-040-168.pools.arcor-ip.net) left irc: Read error: 110 (Connection timed out)
[23:01] Action: [raphael] checks the build...
[23:02] <[raphael]> th, stf^rocklinux: the build result is as follows (not yet "tested"): 102 builds total, 102 completed fine, 0 with errors.
[23:03] <[raphael]> oh... I forgot, the modutils still to do
[23:04] <[raphael]> ... stf^rocklinux: the modutils did get built (correct english tense?)
[23:42] [raphael] (n=raphael@raphael.netpark.at) left irc: "using sirc version 2.211+KSIRC/1.3.12"
[00:00] --- Sun Jun 11 2006