Hi all, Since a lot of communication about rock happens in #rocklinux@irc.openprojects.net we decided to include a summary in the rolling rock. This is the first rolling Rock irc summary. We hope you have fun with it. Constructive comments and corrections are welcome. Flames are being piped directly to /dev/null . * 2002-04-14 This is the day where the logs start. There was a little discussion between th, tsa and rxr about the sf respository (in german so I do not include it here). th was submitting his changes to sf cvs till now but will swich to the private respository of huebi. rxr states that the 1.5 sf cvs tree is bit outdated and tsa comments that as of huebi is having his own cvs tree 1.5 should be removed from sf. rxr says that the only problem is to convince Pjotr to it. * 2002-04-15 Little discussion about the irc logs layout and irc stats ... and that's it. At least till [03:53]. Then irrelevant chat till [13:59]. After that armijn complains about his problems with sparc64 port that he also stated in his e-mail to the rock-ports mailinglist so I will not repeat it. Armijn also asks if somebody does have a glibc 2.1 machine to test if his assumptions that rocklinux-1.5 links to the wrong glibc are true. After [14:14] started the normal irrelevant chat ;-) about god and the world and cheeting huebi and irc statistics and stuff like that. [18:10] armijn posted an artickle (http://www.uwyn.com/resources/gentoo_departure.html) about the departure of Geert Bevin from gentoo. (Note: Geert was once rocklinux developer and left us for gentoo) Some discussion about the 1.5 build process: [18:44] < rxr> does 1.5 need still the NFS mounts for builds, too? [18:44] < armijn> rxr: not necessarily [18:44] < rxr> armijn: but it is still the prefered way - in contrast to the slow copy mode? [18:45] < Mike1> armijn: implying = implicar [18:45] < esden> rxr: you can choose between nfs mount and copy [18:45] < Mike1> armijn: nah i am not implying anything [18:45] < esden> but mount -bind is not implemented yet [18:45] < rxr> esden: ok - so nothing changed since ROCK-1.4 in this area? [18:45] < esden> rxr: I do not know if it will be ever implemented Some another discussion about the lcd support in rock and an event in Costa Rica where Mike1 needs help: [18:48] < esden> rxr: I have already told you about that some time ago ... this is the feature that you can display your compile information on a matrix character lcd display ... connected to your parallel or serial port [18:48] < armijn> oh yeah, that is a feature that should be standard! [18:49] < esden> haha armijn [18:49] < armijn> you will need an LCD display to build ROCK, as much as you need DevFS [18:49] < esden> it is a gimmic ... [18:49] < armijn> why not make it a subdistro :) [18:49] < esden> but i like it ... [18:49] < esden> you do not have to make fun of me all the time :-( [18:49] < armijn> aww, why not? I enjoy it so much... [18:50] < armijn> remember I'm evil. [18:50] < Mike1> There will be a 4 day event by august here and i was thinking about having a ROCK Linux Stand, is anyone interested in coming over to COsta Rica by that time to have a vacation and give me a hand? [18:50] < armijn> what event? [18:50] < esden> armijn: yess that is sure that you are evil .... [18:50] < jonath]an[> Mike1: what? [18:51] < rxr> esden: We shold not integrate it into the core scripts, but provide hooks, that are called per packge and error notifiing about the progress ;-) [18:51] < Mike1> its a whole computing thing named CompuExpo [18:51] < esden> rxr: I know ... [18:51] < esden> rxr: in 1.5 it will be hardcoded [18:51] < esden> in 1.7 it will be made using hooks [18:51] < jonath[an]> ahh [18:51] < Mike1> it has been growinf and getting better with the time so i think it would be cool to have a stand with some sparcs and pcs over there [18:52] < esden> I spoke about it with clifford Mike statement to why rocklinux is cool to work on: [18:58] < Mike1> personal opinion there is no distro like rock linux, one of the best thing is that we can decide things and have a lot of control, together we can make awesome improvements that a single person would never do [18:58] < Mike1> its nice to be heard and be able to do great stuff for this kind of projects, i don't think i will ever go away from rock Several people agreed. Some further discussion and thats it. [23:20] fake joined us finally !!! ;-) Some discussion followed about # man women and # info women and suddanly the day ended ;-) * 2002-04-16 After a while of fun Bevin came in afternoon: 17:37 < Bevin> praenti_fh: I was just hoping to catch armijn here 17:37 < Bevin> praenti_fh: been wondering which package manager rock is now going to default on 17:37 < Bevin> praenti_fh: and yes, I'm not maintaining the rock packages I wrote a few months ago anymore 17:38 < praenti_fh> i see. because i will maintain some of your old packages 17:38 < Bevin> praenti_fh: good :-) After 18:30 was a lot of discussion in several topics, cliff arrived and told about _build-time_ dependencies: 18:47 <@clifford> ok - looks like the dependencies are working now. 18:47 <@esden> good ... i will have to take a look on it ... 18:47 <@clifford> the next step will be the creation of the *.cache files. 18:48 <@clifford> Every package will have a *.cache file next to *.desc and *.conf. 18:48 <@clifford> The *.cache files are auto-generated and contain information from a "reference build" like the dependencies. 18:49 <@esden> hmm good that is what I thought you want to do ... 18:49 <@clifford> Using the cache file we can generate at every time in the build a list of packages which can be build . 18:50 < rxr> I thouhg about this, too 18:50 < SMP> hi Clifford 18:50 < rxr> how will you mark dependencies and optionals ? 18:50 <@esden> hi SMP 18:51 < rxr> moin SMP 18:51 < netcrow> hi SMP 18:51 < SMP> @ are chic? ;) 18:51 <@clifford> rxr: I will not do it. If a package is not present in the "Packages" file, a dependency to it will be . 18:52 < rxr> ok - this might work. 18:52 <@clifford> the "reference build" will be a special target containing all packages and configured in a way to produce as much dependencies as possible. 18:52 < rxr> ok 18:53 <@clifford> on possible problem will be the compiler. 18:53 < rxr> why? 18:53 <@clifford> If if e.g. use gcc2 in the reference build and make a icc based build later, all packages will depend on gcc2 and noone on icc. 18:54 < rxr> hm. but this dependency is not important 18:54 < rxr> since all packages depend on the compiler - and this dependency is misleading anyway 18:54 < rxr> becasue X does not need gcc2 to run 18:54 <@clifford> sure it is. You must not build any package from stage 2 or higher before you have built the c compiler in the lower stages. 18:54 < rxr> (thinking of the install case, where you select X11 ...) 18:54 < SMP> rxr: we're talking _build time_ dependencies 18:55 <@clifford> rxr: so we can auto-detect the build order independend of the package priority and so build multiple packages in paralell. 18:56 < rxr> clifford: yes - I know 18:56 <@clifford> esden: btw - the latest snaps do contain an 'strace' based fl_wrapper replacement. So we can make e.g. dietlibc based builds and still have something like an flist wrapper. 18:56 <@esden> ahh good 18:56 < rxr> but since the dependency generating process is the same I only wanted to add that some dependencies are not that interesting for some cases 18:57 <@esden> clifford: i think that i will put the dietlibc on top of my todo list now ... 18:58 <@esden> clifford: so we can create installdisks and Create-CD ... 18:58 <@clifford> rxr: at the moment, only the build-time dependencies are interesting to me. We can also use them for the installation process and we _need_ them for the cluster builds. 18:58 < rxr> clifford: btw. have you fixed the dependency generating in the latest snap? 18:59 <@esden> we need stuff to feed the smp machine @ lrz ;-) 18:59 <@esden> and / or the cluster they can offer ... ;-) 18:59 < rxr> clifford: ah I see they are fixed ;-) 19:00 <@clifford> yes. The flpaese requires some command-line options now and I've forgott to add them when callinf flparse for creating the dependencies. 19:01 <@clifford> esden: yes - sooner or later we will need install-disks in 1.7 .. 19:01 < rxr> clifford: how many cases of dependency-name translation cases do we have? Only glibc gcc? 19:02 <@esden> yepp ... that is why it is advancing to the top of my todo list ... and it is pretty huge at the moment .. :-( 19:02 <@clifford> Hmm .. mostly everything which could be replaced with an alternate package. Compilers, libraries, etc. 19:03 <@clifford> Currently we have something like thos for the c-compiler and the libc only (gcc2/gcc3 and glibc/dietlibc). 19:06 <@esden> hmm it seems that the dependency lists will become pretty huge and complex ... when we get more choice possibilitys ... like gclibc or something comparable 19:06 <@esden> I mean uclibc 19:06 <@esden> not gclibc 19:07 < rxr> there is also this hackerlab-libc (or what it was called) out ... 19:08 <@esden> rxr: there are tons of such stuff ... so you can build tons^tons of different systems out of it .... 19:10 < rxr> so how to solve the name translation? let the coosen package set some "gcc2 libc" variable? 19:12 <@clifford> rxr: The best would be if one package could list it's alternate packages and whenever a packge depends on that package it automatically depends on all the alternate packages. 19:12 <@clifford> (imo) 19:12 < rxr> but this way you would have to code all alternatives into each 19:13 < rxr> transforming the dependency into a generic one in the first place might be cleaner ? 19:14 < rxr> hm star is from Joerg Schilling - this makes the package very unatractive ... 19:14 <@clifford> rxr: we could do that as meta-layer in the .desc files. But i would translate it to the full list of packages in the dependency cache. Clifford and Rene had a discussion about how the rescue, xyz and install disk might create their ISO and floppy images, Wolf said that solution could be add "distributions" wich are a collection of targets, like an target is a collection of packages. Although and Cliff said it would be pretty dirty. So, Rebe though about a a target, as one target distribution which generate some kind of image "/" files to be used, and the generic target creates the packages and an ISO and the install disks targets will create floppy and rescue image; but problem here woulb be that the generic targets will need the install-disk target to the boot image. Rene was talking to himself for some time. Later, hackbard bring us a new idea around 23:00, he was introducing something like FAI in Debian for RockLinux, http://www.informatik.uni-koeln.de/fai/. This system allow to download precompiled packages to a virgin cluster and and start a installation on them from a server. Hackbard is working on this in his University, that's why he wanted to post this to #rocklinux. Around 23:30 Mike told us he got a new U5 30 mins ago and then log finished. * 2002-04-17 The day started with some discussion about sf cvs (neverending subject): [00:09] < tsa> hm...i'm curious what will become with sf cvs.. [00:10] < tsa> pjotr really is what i would call a hardliner. [00:10] < esden> yepp seems so ... [00:10] < tsa> i guess he won't acccept any changes on the current sf cvs setpu [00:10] < tsa> setup [00:11] < esden> he defined rxr mail as flame ... this was a pretty extreme mail "core dump sf cvs" ... but it was no flame ... [00:12] < tsa> yes..i know [00:12] < esden> tsa: we will seee .... [00:12] < rxr> Hm? Did a new flame of Pjotr arrived? [00:12] < tsa> i don't understand his opinion on Rene and his disrespect for other people's hard work... then a new idea was born: [00:13] < huebi> Perhaps SMP is willing to host th Rock-CVS [00:13] < th> that would be cool [00:13] < tsa> huebi: sounds good. then some hot discussion about that cvs sux and that sf cvs is bad structured and that nearly noone knows cvs perfictly. [00:40] < th> but in spite of this... perhaps we could provide huebi with a faster cvs-server? [00:51] < SMP> th: do it on ns0 - get free transfer ;)) [00:51] < th> SMP: deal [00:51] < th> SMP: so i'll setup a new ip for that. [00:52] < SMP> th: well we can do that - but [00:53] < SMP> th: huebi will send me a RAID kit for rocklinux.de. it may be wise to use it for the CVS, too ;9 [00:53] < th> yes [00:53] < th> we have a machine for that? [00:54] < SMP> th: yup, world.wronline.de, already running {sources,bitkeeper,www,download}.rocklinux.de ;) Then some technical details about the future cvs server followed. But in the end SMP is getting the raidkit from huebi and th is then setting a cvs on this box.