WebHosting Paid by #1Payday.Loans
[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: https://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]> https://ar.linux.it/software/index.html#ocan [10:00] <[raphael]> there is another one, but its not maintained anymore: https://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 127.0.0.1/8 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