WebHosting Paid by #1Payday.Loans

[00:00] menomc (n=amery@200.75.27.92) joined #rocklinux.
[00:00] mnemoc (n=amery@200.75.27.10) left irc: Nick collision from services.
[00:02] Nick change: menomc -> mnemoc
[01:00] blindcod1r (n=blindcod@tor/session/x-74177a571ddd6de6) joined #rocklinux.
[01:00] blindcoder (n=blindcod@tor/session/x-18abb57fc9d70758) left irc: Nick collision from services.
[01:00] Nick change: blindcod1r -> blindcoder
[01:09] nookie (n=nookie@M1808P000.adsl.highway.telekom.at) left irc: "Lost terminal"
[01:11] nookie (n=nookie@M1808P000.adsl.highway.telekom.at) joined #rocklinux.
[01:36] sparc-kly (n=mubex@64.237.241.16) joined #rocklinux.
[01:49] nookie_ (n=nookie@M293P000.adsl.highway.telekom.at) joined #rocklinux.
[02:04] nookie (n=nookie@M1808P000.adsl.highway.telekom.at) left irc: Read error: 110 (Connection timed out)
[03:32] link_ (n=link_@237.103.76.83.cust.bluewin.ch) joined #rocklinux.
[03:58] link_ (n=link_@237.103.76.83.cust.bluewin.ch) left irc: "Lost terminal"
[06:11] sparc-kly_ (n=mubex@64.237.245.27) joined #rocklinux.
[06:28] sparc-kly (n=mubex@64.237.241.16) left irc: Read error: 110 (Connection timed out)
[08:21] BoS_ (n=BoS@dslb-088-072-033-009.pools.arcor-ip.net) left irc: Remote closed the connection
[08:21] BoS (n=BoS@dslb-088-072-038-082.pools.arcor-ip.net) joined #rocklinux.
[09:20] fake (n=fake@rapidnetworks.de) got netsplit.
[09:31] fake (n=fake@rapidnetworks.de) got lost in the net-split.
[09:48] nookie (n=nookie@M351P014.adsl.highway.telekom.at) joined #rocklinux.
[10:05] nookie_ (n=nookie@M293P000.adsl.highway.telekom.at) left irc: Read error: 110 (Connection timed out)
[10:41] <blindcoder> moin
[11:47] [raphael] (n=raphael@raphael.netpark.at) joined #rocklinux.
[12:12] netrunner (n=andreas@anvame.net) left irc: Read error: 110 (Connection timed out)
[12:14] netrunner (n=andreas@anvame.net) joined #rocklinux.
[12:23] maledot (n=dot@host91-126.pool8251.interbusiness.it) joined #rocklinux.
[12:24] maledot (n=dot@host91-126.pool8251.interbusiness.it) left #rocklinux ("Sto andando via").
[12:26] blindcod1r (n=blindcod@tor/session/x-00e5d8afb1adc877) joined #rocklinux.
[12:27] blindcoder (n=blindcod@tor/session/x-74177a571ddd6de6) left irc: Nick collision from services.
[12:27] Nick change: blindcod1r -> blindcoder
[14:12] clifford (n=clifford@213-229-1-138.sdsl-line.inode.at) joined #rocklinux.
[14:58] dominik_ (i=dominik@2002:d5ef:d074:1:0:0:0:1) joined #rocklinux.
[15:16] dominik_ (i=dominik@2002:d5ef:d074:1:0:0:0:1) left irc: "leaving"
[15:18] demian (n=Jonathan@201.206.44.210) left #rocklinux.
[15:25] madtux (i=miguel@pf0.hostarica.com) joined #rocklinux.
[15:26] [raphael] (n=raphael@raphael.netpark.at) left irc: "using sirc version 2.211+KSIRC/1.3.12"
[17:25] <esden> bopp
[17:32] <madtux> plop
[18:05] nookie (n=nookie@M351P014.adsl.highway.telekom.at) left irc: Read error: 110 (Connection timed out)
[18:12] sparc-kly__ (n=mubex@64.237.244.104) joined #rocklinux.
[18:16] [raphael] (n=raphael@raphael.netpark.at) joined #rocklinux.
[18:18] <[raphael]> clifford: ping
[18:18] <clifford> pong.
[18:19] <[raphael]> so... today I got a bit frustrated with Kontact (the one included in KDE 3.5) basically setting up those crypto modules
[18:19] <[raphael]> and... blindcoder asked for someone to take care of a x86_64 installation anyway
[18:19] <[raphael]> so ... this is your chance to convince me to install ROCK on my main computer, instead of the currently running NetBSD 3.0
[18:20] <[raphael]> I have built and tested a recent crystal target
[18:20] <clifford> ahhh! another x86_64 installation would be great!
[18:20] <[raphael]> some comments I have sent to the list about it anyway
[18:20] <[raphael]> do you already have a x86_64 machine for ROCK?
[18:21] <[raphael]> The cryptography also does NOT work in ROCK
[18:21] <clifford> not really.
[18:21] <[raphael]> by the way
[18:21] <blindcoder> [raphael]: how does crypto not work?
[18:21] <clifford> clemy is maintaining ROCK foer x86_64 but has almost no time
[18:21] <blindcoder> my /home tells me differently
[18:21] <[raphael]> but the S/MIME encryption works, but not the normal gnupg encryption
[18:21] <blindcoder> ah, gnupg
[18:22] <blindcoder> [raphael]: that might be a priority problem
[18:22] <blindcoder> [raphael]: check if gnupg and gpgme are built before kontact
[18:22] <[raphael]> blindcoder: in kmail, the security settings (Sicherheit -> Krypto-Module)
[18:22] Action: blindcoder fires up kmail
[18:22] <[raphael]> well... I "think" it's doable in crystal, at least with much less hassle as with NetBSD right now
[18:23] <[raphael]> in NetBSD I do get the GpgME / OpenPGP (gpg) encryption to work just fine
[18:23] <blindcoder> [raphael]: AFAICS it's a priority problem, let me double-check
[18:23] <[raphael]> and now I installed gnupg-devel with gpgsm enabled
[18:24] <[raphael]> which, horray, now gives me also the S/MIME (gpgsm) option in KMail
[18:24] <[raphael]> but, Kmail crashes when even just selecting an S/MIME encrypted mail
[18:24] <[raphael]> and that's just NOT fun
[18:24] <[raphael]> so I have two options - build my own KDEPIM with debugging enabled and fixing that problem here
[18:24] <[raphael]> or... take another road
[18:24] <blindcoder> hmm
[18:24] <[raphael]> install ROCK
[18:24] <blindcoder> from the priorities it shoud be fine
[18:25] <[raphael]> basically this encryption thing is not that much of importance, but it's getting a stone to roll... maybe
[18:25] <blindcoder> it is a problem IMO
[18:25] <blindcoder> even though I'm using mozilla/enigmail
[18:26] <[raphael]> blindcoder: yes, it is, and MUST be fixed of course
[18:26] <[raphael]> basically I'm interested in ROCK because of a few very nice infrastructure items
[18:26] <[raphael]> so, the packaging way that ROCK has is the best I have seen so far
[18:27] <[raphael]> although it's missing ... well, packages (being rather small yet)
[18:27] daja77 (n=daja@dslb-088-072-040-152.pools.arcor-ip.net) left irc: Read error: 104 (Connection reset by peer)
[18:27] <[raphael]> but I think that ROCK can be promising in the long run
[18:27] <blindcoder> [raphael]: creating new packages is quite easy, so if that's all :)
[18:28] sparc-kly_ (n=mubex@64.237.245.27) left irc: Read error: 110 (Connection timed out)
[18:28] <blindcoder> personally I can't be of much help this week since I'm only at my parents with just a 8kB/sec connection :(
[18:28] <SMP> we don't need another 5000 unmaintained, hardly-working packages ...
[18:28] <[raphael]> yes, I know... but, there is also other stuff that "does not work" on ROCK, which works very well somewhere else (like NetBSD)
[18:29] <blindcoder> SMP: I wasn't aware that we already had 5k packages ;)
[18:29] <[raphael]> the kernel that is currently built by the crystal target (2.6.14.2) really sucks
[18:29] <[raphael]> it has just a wrong configuration and fails to boot ANY of my machines
[18:29] <[raphael]> with a beautiful kernel panic
[18:29] <[raphael]> so, I'm a bit frustrated (honestly) about Linux kernel quality lately
[18:30] <blindcoder> yeah, I should finally get off my lazy ass and do a decent kernel configuration :(
[18:30] <[raphael]> and, being used to bsd systems I'm probably too used to things just working
[18:30] <[raphael]> blindcoder: yes, you should
[18:30] <blindcoder> the current auto-config has a few... issues
[18:30] <[raphael]> it's not good having a default config that doesn't work on many machines
[18:31] <blindcoder> [raphael]: well, it did work on any of my machines, to be true
[18:31] <[raphael]> I (by luck!!!) found a working kernel configuration for my old K6-2
[18:31] <[raphael]> (I did the installation with an older ROCK rescue... don't know which one, but it had a 2.6.8 kernel, which worked)
[18:31] <[raphael]> so... I'm a bit concerned about ROCK quality as well
[18:32] <[raphael]> basically ROCK is the only linux I'm willing to deal with, as it gives me enough power
[18:32] <[raphael]> but if it's to be on my main system (again) then I have a few requirements... also for the future
[18:32] <blindcoder> you were trying on the x86_64 machine?
[18:33] <[raphael]> blindcoder, your mail to the list today gave me some more hopes that ROCK is going into a right direction
[18:33] daja77 (n=daja@dslb-088-072-037-157.pools.arcor-ip.net) joined #rocklinux.
[18:33] <[raphael]> blindcoder: no!!! I'm not trying on my doing-all-in-one-netbsd-machine
[18:33] <blindcoder> [raphael]: it's "just" a more verbose thing of https://doc.rocklinux.org/wiki/TopicsCCC2005
[18:34] <blindcoder> [raphael]: what kind of hardware is in that machine you were trying on?
[18:34] <[raphael]> this machine is doing tons of stuff all at the same time, from web server, to router (well, until recently) and desktop and www/imap/dns/.../.../...* stuff
[18:34] <blindcoder> ah, okay
[18:34] <[raphael]> and ALL THIS would need to be possible with ROCK
[18:34] <blindcoder> I've never done dns, but all the other stuff
[18:34] <[raphael]> I was a complete NetBSD noob in the summer when I set it up, but I was used to FreeBSD and thought well, netbsd might be a good thing to know
[18:35] <blindcoder> on scavenger.homeip.net, on pallas.crash-override.net and my laptop
[18:35] <[raphael]> so that's what I chose and have since then raised a marvelous overall system
[18:35] <blindcoder> true :)
[18:35] <blindcoder> nice
[18:35] <blindcoder> okay, time for dinner, my parents are calling
[18:35] <[raphael]> even with a wonderful backup script, that I have written recently
[18:35] <blindcoder> I'll eb back tomorrow, I think
[18:35] <blindcoder> sweet :)
[18:36] <blindcoder> I do my backing up with taper
[18:36] <blindcoder> okay, so I'm off
[18:36] <[raphael]> aha, ok, then I need someone to answer some more questiosn
[18:36] <[raphael]> bye blindcoder, enjoy
[18:36] <[raphael]> thanks so far
[18:37] <[raphael]> Now, NetBSD and FreeBSD (at least) can be updated very well
[18:38] <[raphael]> and this is sth very important for a system (I would say)
[18:38] <[raphael]> ROCK can now be updated as well, yes, I know
[18:38] <[raphael]> but it's a "new" feature which still has to prove itself (I hope it will)
[18:38] <clifford> [raphael]: I have tried a current crysal with qemu and it worked fine. what exactly was the problem with the kernel?
[18:38] <[raphael]> bsds tend to have a rather clean working-out-of-the-box base system
[18:39] <[raphael]> clifford: I didn't find out exactly
[18:39] <[raphael]> but I turned off various options and then it didn't panic anymore
[18:39] <[raphael]> I can send you both configurations though, maybe you can spot the issue
[18:39] <[raphael]> (both configurations: the original one and the one I have created that worked)
[18:40] <[raphael]> uhm... the system doesn't exist anymore, been replaced by netbsd because Kolab2 does NOT install on ROCK Linux
[18:40] <[raphael]> which is sad (I might work on that though in the future)
[18:41] <[raphael]> clifford: I think my major requirement of ROCK is that it has to be cleanly updateable
[18:41] <[raphael]> and it shouldn't have unexpected kernel panics
[18:41] <clifford> yes, i can understand that. ;-)
[18:41] <[raphael]> that is, the base system should work, also after updates. I know this is harder to realise (especially test) with a Linux distribution, but it's important
[18:42] <[raphael]> what I'm actually very fond of is mkpkg
[18:42] <[raphael]> that's really a cool tool
[18:42] <[raphael]> so I guess that all comes down to maintainability
[18:42] <[raphael]> of running systems
[18:43] <[raphael]> clifford: back to a former question: do you already have an AMD64 build host?
[18:43] <clifford> not really.
[18:43] <[raphael]> and what I'm missing in BSD is DRI (direct rendering interface)
[18:43] <[raphael]> so you could use one...
[18:43] <clifford> clemy has done a lot of work with amd64 but is busy with his job right now.
[18:44] <[raphael]> well, FreeBSD has DRI support, but it's slower than on Linux
[18:44] <[raphael]> clifford: I cannot promise you much time
[18:44] <[raphael]> either
[18:44] <clifford> but a friend of mine has done an amd64 build lately.
[18:44] <[raphael]> does it work? since.... if I do a cross build I can only build the first stage and then have to finish it on my amd64
[18:44] <[raphael]> which involves ... risks :)
[18:45] <clifford> .. he is doing a lot of 3d stuff and told me today that this is working fine in his build.
[18:45] <[raphael]> (of downtime that is)
[18:45] <clifford> (this = DRI for 3d)
[18:45] <[raphael]> clifford: do you have a GCC 4 available somewhere?
[18:46] <[raphael]> or does anyone have a gcc 4 based system available?
[18:46] <clifford> daja77 is doing a lot of gcc4 related work
[18:46] <clifford> trunk is not ready for complete gcc4 based systems (many packages still fail)
[18:47] <[raphael]> ok... cause I recently added something to the G System that does NOT work with GCC 3.4
[18:47] <[raphael]> it does with 3.3
[18:47] <[raphael]> and I "don't know" if it works with 4.0
[18:47] <[raphael]> clifford: what do you think of the Linux kernel stability in general
[18:48] <[raphael]> sound didn't work with my build
[18:48] <clifford> well, afaics we will switch to gcc4 as default compiler within the next months..
[18:48] <[raphael]> which is... bad
[18:48] <clifford> did you try re-running "udevstart" after loading the sound driver?
[18:48] <[raphael]> I'm not sure, I don't know udev at all
[18:49] <[raphael]> I left Linux before the time of udev and usually tried to stick to systems with devfs before that
[18:49] <[raphael]> which means: I don't know in when you start udev and when you load kernel modules
[18:49] <[raphael]> in what order
[18:49] <clifford> udev is one of the moving targets in TRUNK right now.
[18:50] <[raphael]> what I really love is the flexibility of installing ROCK
[18:50] <clifford> .. so it also is one of the prblem areas at the moment. :-(
[18:50] <[raphael]> I actually did NOT manage to do any "normal" rock installation recently, I always had to use rescue discs, command line, manual mine -i -R ... etc
[18:50] <[raphael]> ok
[18:50] <[raphael]> Well, I can't live long without a working system
[18:51] <[raphael]> I have now (for a few months now) a second machine that runs crystal
[18:51] <[raphael]> the one I got from you, if you remember
[18:51] <[raphael]> that now serves as a build host for 32 bit systems
[18:52] <clifford> so you only had the kernel and install problems for the 64bit system?
[18:52] <[raphael]> so... what about kernel stability? What is the trend right now? I saw that there are quite a few new features
[18:52] <[raphael]> I didn't even try the 64 bit system
[18:52] <[raphael]> no, I had it with an AMD K6-2 system
[18:52] <[raphael]> the problems that is
[18:53] <[raphael]> and with the Athlon (32 bit) system that already runs rock
[18:53] <[raphael]> both couldn't boot the cd
[18:53] <[raphael]> (a default bootdisk target)
[18:54] <clifford> you built that your own, right? from which svn version (or date)?
[18:54] <[raphael]> maybe I should get a list of requirements together first, then come back to you, check what works (or is supposed to work) with ROCK
[18:54] Action: [raphael] is checking svn info...
[18:55] <[raphael]> 6744
[18:55] <[raphael]> with a few patches applied
[18:55] <[raphael]> mainly for KDE
[18:55] <[raphael]> nothing kernel related
[18:55] <clifford> ah. this is before the ccc fixes.
[18:55] <[raphael]> yes, that's for sure
[18:56] <[raphael]> 2005-12-15 12:57:17 +0100 (Don, 15 Dez 2005)
[18:56] <clifford> I've changed nothing in the kernel config, but added many fixes in the bootdisk in general after the updates which went to r6744.
[18:56] <[raphael]> by the way, I had an appointment on 30th Dec., so coming to ccc was out-of-the-question
[18:57] <clifford> current head revision is r6946..
[18:57] <[raphael]> I was running ROCK on my main desktop PC until summer 2004
[18:57] <[raphael]> then switched to FreeBSD
[18:57] <[raphael]> what I remember of that time is that I spent... much time building new systems and fixing things
[18:57] <[raphael]> and... I spent most time on my laptop anyway (also running rock at that time)
[18:58] <[raphael]> which basically works fine, a few glitches here and there
[18:58] <clifford> I will do some test installs with the 22c3 iso on real hardware this week. Maybe I can reproduce the problems.
[18:59] <[raphael]> hmm... thinking about it it is even an option to go install FreeBSD (apart from sticking to netbsd)
[19:00] <[raphael]> but rock is, after all, the most flexible thing I know
[19:00] <[raphael]> which is better for a development system
[19:00] <[raphael]> it just works fine mv current /opt/kde out of the way and see how a different version works
[19:00] <[raphael]> that's not as easy with the netbsd things
[19:00] <[raphael]> bsd things
[19:01] <[raphael]> clifford: what I require of ROCK is a promise for stability
[19:01] <[raphael]> I know you can't make such promises
[19:01] <[raphael]> which means: there are too many external circumstances that you can't control
[19:02] <clifford> well, this is definitely where we want to go. But I can't make such promises in TRUNK
[19:03] <[raphael]> now that I think of it there is also a different interest in ROCK
[19:03] <[raphael]> for just the thing ROCK is - a distribution build kit
[19:04] <[raphael]> since I might need some specialized install sets in the future
[19:05] <[raphael]> blindcoder once mentioned trunk is always stable
[19:05] <[raphael]> :)
[19:05] <[raphael]> oh what fun
[19:07] <clifford> at least it is more stable that it was some years ago and I don't want to do any plain ROCK stable series anymore in the future.
[19:07] <[raphael]> yes :) I didn't mean to make fun of this, I was just making fun of the whole situation
[19:07] <clifford> however, e.g. a crystal rock release will always be based on a specific well-tested trunk revision.
[19:07] <[raphael]> [my] whole situation that is...
[19:09] <clifford> so, what are we going to do now?
[19:09] <clifford> I will do some test installs with current bootdisk builds and you will send me a detailed error report for the bootdisk problems?
[19:10] <[raphael]> clifford: I can't send you much details, I can give you the two kernel configurations
[19:10] <clifford> that would help already.
[19:10] <[raphael]> yes... will send them to the list
[19:10] <clifford> ok.
[19:11] <[raphael]> clifford: uhm... by the way, BSD port systems have various nice features totally missing/unimplemented in ROCK
[19:11] <[raphael]> the same applies the other way round
[19:11] <clifford> e.g. ?
[19:11] <[raphael]> updating
[19:12] <[raphael]> maybe that's already working fine with ROCK, I don't know
[19:12] <[raphael]> and dependency handling
[19:12] <[raphael]> if I update a specific package I can make sure all dependent ports are rebuilt
[19:12] <[raphael]> etc.
[19:12] <[raphael]> dependency listing in both ways
[19:13] <[raphael]> e.g. what packages depend on this particular package
[19:13] <[raphael]> what [installed] packages
[19:13] <[raphael]> on the other hand: rock generates dependencies automatically
[19:13] <clifford> yep. there are some TODOs in that area..
[19:13] <[raphael]> and i REALLY like the feature of those autofilelists
[19:14] <clifford> *g*
[19:14] <[raphael]> in BSD ports all files/dirs are explicitely listed
[19:14] <[raphael]> and there is this mkpkg
[19:14] <[raphael]> for which I didn't find (neither really search) a replacement
[19:14] <clifford> I have to go now (in fact I'm already to late).
[19:14] <[raphael]> and mkpkg already makes up for tons of yet missing packages in ROCK
[19:14] <clifford> cu tomorow.
[19:14] <[raphael]> clifford: ok, I don't want to keep you from your duties
[19:14] <[raphael]> bye for now
[19:14] <[raphael]> thx
[19:14] <clifford> afk.
[19:46] <owl> moin
[20:12] <esden> hrm ... once more hi
[20:13] <[raphael]> hi :)
[20:13] <owl> hi esden :)
[21:59] sparc-kly__ (n=mubex@64.237.244.104) left irc: Remote closed the connection
[22:46] [raphael] (n=raphael@raphael.netpark.at) left irc: Read error: 104 (Connection reset by peer)
[22:46] [raphael] (n=raphael@raphael.netpark.at) joined #rocklinux.
[23:33] kasc_ (n=kasc@dslb-084-060-127-144.pools.arcor-ip.net) joined #rocklinux.
[23:42] kasc (n=kasc@dslb-084-060-112-006.pools.arcor-ip.net) left irc: Read error: 110 (Connection timed out)
[23:42] Nick change: kasc_ -> kasc
[00:00] --- Tue Jan  3 2006