--- Log opened Mon Nov 29 00:00:48 2004
--- Day changed Mon Nov 29 2004
00:00 < jsaw> re
00:00 < rxr> hi jsaw 
00:00 < jsaw> hi rxr
00:01 < jsaw> rxr: why do you think the open wrapper thing is mostly noise?
00:02 < rxr> because it rewrites the whole function - and the author itself wrote on the list that he most probably changed too much and just changing the calling convention of the function should be enough
00:03 < jsaw> ah. ok. because I thought both calls, the replacement function and the the wrapper function variable def has to be changed to be really on the safe side... (see some lines above, me talking with mnemoc and mtr)
00:04 < jsaw> but what's really correct now?
00:04 < rxr> we need to take a closer look ...
00:04 < rxr> maybe you want ? ;-)
00:04 < jsaw> I have an idea but no box to test... :)
00:04 < rxr> implement it - send a diff and we can discuss and test if it does cause regressions so for us ..
00:05 < rxr> valentin: now that I think about it - maybe it is the cause for the random undebugable seg-fault in my sparc64 build ? ...
00:08 < valentin> rxr: hm - but i guess fake or some other rockers would have experienced that, too ?
00:08 < rxr> do they have s 64bit user-land build?
00:08 < rxr> and it does not happen for all packages - i might have just ignored them ...
00:09 < jsaw> patch almost ready...
00:09 < valentin> we need to create a patch for that bug anyway in case we want to support x86_64
00:09 < valentin> so we just can try out on your sparc
00:09 < rxr> it does not hit x86 alone
00:09 < rxr> in theory powerpc should also be affeacted, sinve va_args are also passed in registers ...
00:10 < rxr> as in most RISC arches I guess
00:10 < rxr> but fake might have built s.th. totally f*cked up - or nothing at all
00:10 < rxr> since the -fPIC thinkg for the preload .so's is long fixed in t2 - and now the rockers get's it thru the x86_64 patches ..
00:11 < rxr> he can never have done a 64 bit sparc build without it ...
00:11 < rxr> or he just hacked it to build without submitting a fix ...
00:14 < mnemoc> rxr: ifstream gets stalled opening a FIFO :(
00:14 < mnemoc> how can i give it flags?
00:14 < rxr> ouhm
00:15 < valentin> which flags do you want ?
00:16 < rxr> the linuxrc problem gets quite problematic
00:17 < jsaw> patch sent
00:17 < rxr> it works only after Build-Target runs when the native tools are set up as tools to be used
00:17 < mnemoc> NDELAY or NONBLOCKING
00:18 < rxr> when you start Build-Target and no chrooted stuff has to be done the tools stuff is setup differently to just use the cross tools - and those fail ...
00:18 < rxr> of course the run that works is defect since the native tools are used when it in fact can be a cross build and should always be build as such
00:18 < rxr> and the cross code-path is broken due to getting the wrong headers in ...
00:19 < rxr> but - I work on it ..
00:19 < rxr> this guy is crazzy:
00:19 < rxr> http://members.home.nl/gis/
00:20 < valentin> mnemoc: i fear doing nonblocking io with ifstream is not considered by the standard - maybe there is a gnu extention in our stl, but ...
00:20 < jsaw> hi valentin , mnemoc btw
00:20 < valentin> hi jsaw
00:20 < jsaw> the hl2 mod is quite old!
00:20 < jsaw> see first image, _2003_
00:20 < mnemoc> valentin: thanks 
00:21 < jsaw> (I saw it on mini-itx afaicr)
00:21 < valentin> mnemoc: can you have nonblocking io with fopen(...) ?
00:22 < mnemoc> valentin: i hope that work inside a c++ world
00:22 < rxr> jsaw: there was some crazzy via cluster - have you seen it? did we had the link here?
00:22 < jsaw> rxr: oh yeah (and you complaint about the crappy netgear switch...)
00:23 < valentin> mnemoc: you can use all the glibc c functions as well
00:23 < jsaw> valentin: fcntl on fileno(f)
00:23 < valentin> jsaw: ok
00:24 < valentin> mnemoc: consider using a combination of plain c file read and stringstreams to solve that
00:25 < mnemoc> i'll have to do my best :) i am 4 days late :p
00:26 < valentin> .oO
00:28 < jsaw> what do you guys think about the fl_wrapper patch?
00:30 < jsaw> http://www.vent-box.com/img/platform.jpg
00:30 < jsaw> <- that's a toaster, isn't it?
00:30 < rxr> looks ugly ...
00:31 < rxr> not your patch - the toaster ;-)
00:31 < jsaw> phew...
00:32 < rxr> I really wonder why the open man-page does not specify them as va_list functions - when the actual /usr/include headers, too ...
00:32 < jsaw> oh, I forgot creat..
00:33 < jsaw> oh no, no va_list
00:33 < valentin> that toasters keyboard sucks
00:33 < jsaw> rxr: not posix standard?
00:34 < rxr> no I do not have the standard here - do you have it ?
00:34 < jsaw> me too not, that's why I was asking...
00:34 < rxr> I once google from them - but did not found them ...
00:34 < rxr> if you can locate them ;-)
00:35 < jsaw> I could locate them: I know alan cox has 'em... :)
00:35 -!- sparc-kly [~sparc-kly@65-23-199-247.prtc.net] has quit ["Leaving"]
00:36 < rxr> if he sends it over  ...
00:36 < rxr> jsaw: why do you extract b - wasn't there some way to pass the remaining options down ...
00:36 < jsaw> he's a straight guy, he would not (it's something to pay for iirc)
00:37 < rxr> really? it is an open standard, isn't it .... ?
00:37 < jsaw> hmmm...
00:37 < rxr> I really wonder why the functions are ... at all ...
00:38 < jsaw> what do you mean with "wasn't there some way to pass the remaining options down"
00:38 < rxr> s.th. in the way of orig_open (bla, va_list);
00:38 < rxr> so you do not need to bother to extract b ...
00:39 < jsaw> I want to be sure it exist (...uclibc...)
00:39 < jsaw> +s
00:39 < rxr> what?
00:39 < rxr> hm - dietlibc also has them "int open(const char* pathname,int flags, ...) __THROW:"
00:40 < jsaw> the fact that the man page doesn't list "vopen(const char* pathname,int flags, va_list ap)" explicitly
00:41 -!- CIA-9 [~CIA@to.je.spocco.com] has joined #t2
00:42 < jsaw> actually it's not even in glibc... so, there's no way to pass it otherwise
00:47 < rxr> hm - there really isn't? :-(
00:47 < rxr> why don't you always exact mode?
00:48 < rxr> ah - now I now why the man-page confused me ..
00:48 < rxr> it lists the two possible calling convetions explicitly ...
00:49 < rxr> int open(const char *pathname, int flags);
00:49 < rxr> int open(const char *pathname, int flags, mode_t mode);
00:50 < jsaw> not always, because I shouldn't access the stack if there's nothing in there... could I?
00:51 < rxr> hm - I like C:
00:51 < rxr>        If  there  is  no  next argument, or if type is not compatible with the
00:51 < rxr>        type of the actual next argument (as promoted according to the  default
00:51 < rxr>        argument promotions), random errors will occur.
00:51 < rxr> so you really can not know in this case if the caller gave a mode or not ..
00:54 < rxr> for even more correctness you could patch the control flow
00:54 < rxr> to only pass b to open when it was specified by the callee ..
00:55 < rxr> although I do not think it is neccessary
00:55 < jsaw> that's not all, try "va_arg(ap, char)" and watch the warnings:
00:55 < jsaw> test.c:11: warning: `char' is promoted to `int' when passed through `...'
00:55 < jsaw> test.c:11: warning: (so you should pass `int' not `char' to `va_arg')
00:55 < rxr> yeah
00:56 < jsaw> what do you mean with "control flow"?
00:56 < jsaw> ah
00:56 < jsaw> as it is ignored if O_CREAT is not given, I think it's not necessary...
00:56 < jsaw> but...
00:57 < jsaw> is the stack pointer save if arguments to "..." are ignored?
00:57 < jsaw> safe
00:57 < rxr> I do also think I should not make a difference 
00:58 < rxr> yep - afaics the va stuff should clean all this up ...
00:59 < rxr> since: "In the C calling convention subprogram parameters are pushed on the stack by the caller from right to left. The caller itself is in charge of cleaning up the stack after the call."
00:59 < jsaw> from libc:
00:59 < jsaw>   if (oflag & O_CREAT)
00:59 < jsaw>     {
00:59 < jsaw>       va_list arg;
00:59 < jsaw>       va_start(arg, oflag);
00:59 < jsaw>       mode = va_arg(arg, int);
00:59 < jsaw>       va_end(arg);
00:59 < jsaw>     }
01:00 < jsaw> now sending a new patch...
01:00 < rxr> do you test it at all (e.g. just compiling it) or is it totally untested?
01:02 < jsaw> for now, just compiling. I had tested this in somewhere else. (I had a similiar idea like cliffords shadowfs some time ago and created a more universal wrapper creator.)
01:02 < rxr> cool
01:02 < rxr> I realled got shocked when I read on the rock list archive that clifford seems to plan to uuuse his entire shadow thing to do flist creation ...
01:02 < jsaw> sth. like "I want function x wrapped..." -> "ioe-wrapper.sh x" and it creates a c file with the wrapper...
01:04 < jsaw> but it's stuck currently, no enough time. My idea was (after the slackware guy complaint about the gnome DESTDIR usage), to also have an exec wrapper, that could bend, change etc. environment variables on demand...
01:04 < rxr> I should consume some food ...
01:07 < rxr> I'm going to fix Build-Target to resetup to use the cross tools after the pkg_loop
01:08 < rxr> and then rework the cross compiler include injection to not alter the specs file ...
01:09 < rxr> oh - wait - I modified the wrong sepcs file
01:09 < rxr> mom
01:12 < rxr> jsaw: yep - your -isystem specs mod does not have an effect on this at all ..
01:12 < rxr> jsaw: you did not tried it yourself?
01:13 < jsaw> nope, but I wrote that I did not test it (!), it was just a (wild) guess...
01:13 < rxr> but this (TARGET_SYSTEM_ROOT) looks promissing ... ,-)
01:13 < jsaw> or maybe I just said this on irc (then mea culpa)
01:13 < rxr> I continue after an egg bread ... - cu 
01:14 < rxr> yep - in the mail you wrote you had no time to test ...
01:14 < jsaw> new patch for fl_wrapper.c sent...
01:14 < rxr> I hoped you had some results in the meantime - but I tested anyway and id produces the same result ....
01:15 < jsaw> I didn't have a boot target ready so far... :(
01:20 < rxr> another pro of minimalist - it doesn't rewrite the Subject - as mailman does - at least as configured over at ROCK Linux ...
01:22 < mnemoc> at least on rock's minimalist, subjects as: Foo (was: re: bar) were cutted to: re: bar)   
01:25 < rxr> yep - quite annoying
01:25 < rxr> not - not minimalist - mailman does it ...
01:26 < mnemoc> i'm sure that was minimalist :)
01:27 < rxr> I think the other way round
01:27 < rxr> you are on the list - you could test it ;-)
01:27 < mnemoc> nah :)
01:28 < rxr> test foo
01:28 < rxr> test bar
01:28 < rxr> ;-)
01:28 < mnemoc> hehe
01:28 < rxr> ah no 
01:28 < rxr> Re: test bar
01:28 < rxr> of course ...
01:42 < mnemoc> can i clean an stringstream?
01:44 < rxr> isn't it .clear()?
01:45 < mnemoc> doesn't work :
01:45 < mnemoc> :(
02:03 < rxr> sorry me was busy ...
02:03 < rxr> your_sstream = ""; will do, right ?
02:04 < valentin> mnemoc: i think rxr is right
02:04 < mnemoc> nope
02:04 < valentin> no ?
02:04 < valentin> mom
02:04 < mnemoc> can't convert const char * blah blah
02:05 < rxr> .str("");
02:05 < mnemoc> :\
02:06 < valentin> or use a local variable
02:06 < mnemoc> i created a second stringstream... i only needed two
02:06 < mnemoc> valentin: local empty string?
02:06 < valentin> i just meant a variable that is valid in a specific block only
02:07 < valentin> but that can be quite inefficient
02:07 < rxr> .str(""); is the official method to clear it ...
02:07 < mnemoc> rxr: oh
02:07 < rxr> "If you want to remove the current contents from the stream. youcan use the function str() to assing new contents to the buffer:
02:07 < rxr> strm.str("");
02:07 < rxr> "
02:10 < rxr> nowdays I have some C++ books on the table to answer mnemocs questions ...
02:10 -!- rxr changed the topic of #t2 to: T2 | the system development environment | http://www.exactcode.de/t2 | C++ people around, too
02:11 < rxr> I modified the gcc.conf to not use specs uglyfing ...
02:11 < rxr> == 11/29/04 02:09:11 =[1]=> Finished building package kiss.
02:11 < rxr> == 11/29/04 02:09:29 =[1]=> Finished building package gzip.
02:11 < rxr> == 11/29/04 02:10:54 =[1]=> Finished building package bash.
02:11  * valentin thinks he should go to bed now
02:11 < rxr> and builts the linuxrc ;-)
02:12 < valentin> gn8
02:12 < rxr> n8 valentin 
02:14 < CIA-9> rene * r4877 /trunk/package/base/gcc/gcc.conf: 
02:14 < CIA-9> * fixed gcc.conf to not mangle the specs file (ROCK relict) but use
02:14 < CIA-9>  --with-sysroot=$root/ to specify the system environment for the
02:14 < CIA-9>  cross compiler
02:14 < CIA-9> * removed the obsolete create_links function on the way
02:23 < mnemoc> rxr: your .str(""); worked.... thanks a loT: D
02:23 < rxr> good ;-)
02:23 < rxr> I just committed crap :-( 
02:23 < mnemoc> description looks nice
02:26 < rxr> had a wrong conditional in it ... :-(
02:26 < rxr> retesting ...
02:28 -!- _martin_ [~martin@brln-d9ba2709.pool.mediaWays.net] has quit [Read error: 110 (Connection timed out)]
02:32  * rxr soon in bed
02:37 < CIA-9> rene * r4878 /trunk/package/base/gcc/gcc.conf: * fixed my previously commited fix: really pass --with-sysroot
02:44 < rxr> ok - so far no regressions due to my specs adaptions removal ...
02:45 < mnemoc> 8 stages to go :)
02:45 < rxr> cool
02:46 < rxr> and it fixes the consecutive run bug we had before
02:46 < mnemoc> we will see
02:46 < rxr> although we still need to fix Build-Target to setup to use the cross compiler in this case ...
02:46 < rxr> I tested all stage combinations code-pathes now manually
02:46 < jsaw> fl_wrapper patch?
02:47 < rxr> let's see if it really withstands a full build
02:47 < rxr> jsaw: nope linuxrc diet build fix ...
02:47 < jsaw> just wondering if you had it applied while fixing linuxrc build
02:47 < rxr> but you excelent fl_wrapper work will be tested thereafter
02:48 < rxr> you fixed s.th. for the linuxrc build?
02:48 < jsaw> I tried to..., but you (and your computer) were faster... :)
02:49 < mnemoc> :)
02:50 < jsaw> the reason I'm asking for the fl_wrapper patch is the uclibc thing actually. I had a proposal to get the symbols either from "libc.so.6" or from a library specified by env variable FLWRAPPER_LIBC.
02:52 < jsaw> would've been easier to create a diff if it was applied... /me lazy
02:52 < rxr> I can test and apply it if you really want me to in the next 15 minutes
02:53 < jsaw> no no, get a bit sleep... (but I'm actually extremely curious, if this fixes a few problems with your sparc build....)
02:55 < mnemoc> we will see _tomorrow_ after rene sleeps
02:55 < jsaw> yep.
02:55 < rxr> yep, me too ;-)
02:56 < rxr> I test the patch on my iBook (va_arg passed in regs) and give you a commit it signal when it builds a package successfully ...
03:03 < rxr> jsaw: the log of an in-system rebuild of xmms looks perfect so far
03:03 < rxr> please feel free to apply the fl_wrapper patch ;-)
03:04 < jsaw> okay.
03:06 < mnemoc> jsaw: i can do i you want to sleep too
03:06 < jsaw> mnemoc: that would be nice, thanks!
03:06 < mnemoc> :)
03:07 < mnemoc> both?
03:07 < mnemoc> jsaw: both?
03:08 < jsaw> for now only the varargs thing.
03:08 < jsaw> (second version)
03:08 < mnemoc> ok
03:13 < CIA-9> mnemoc * r4879 /trunk/misc/tools-source/fl_wrapper.c: 
03:13 < CIA-9> Jurgen "George" Sawinski:
03:13 < CIA-9>  * fix problem of fl_wrapper and x86_64 where arguments are passed in registers.
03:14 < rxr> my full rebuild install disk build just entered stage-1 ...
03:15 < mnemoc> weren't you sleeping?
03:16 < rxr> showered and thoothbrushed ...
03:17 < rxr> n8 all
03:18 < jsaw> gn8 rxr.
03:19 < jsaw> after writing some more lines for my thesis I'll also leave...
03:20 < mnemoc> gn8 rene
03:31 -!- mtr [~michael@H99e6.h.pppool.de] has quit [Read error: 110 (Connection timed out)]
03:31 -!- mtr [~michael@Hb397.h.pppool.de] has joined #t2
03:40 < rxr> == 11/29/04 03:26:30 =[1]=> Finished building package gzip.
03:40 < rxr> so my gcc adaptions got further than -isystem proposed my jsaw ...
03:40 < rxr> I guess it will fully built ...
03:41  * rxr switching the light off - cu
03:46 -!- Sparc-kly|G4 [~sparc@65-23-199-247.prtc.net] has quit [Read error: 238 (Connection timed out)]
03:59 < jsaw> leaving too, cu!
04:12 -!- sparc-kly [~mubex@65-23-199-247.prtc.net] has joined #t2
04:18 -!- _martin_ [~martin@brln-d9ba264a.pool.mediaWays.net] has joined #t2
04:28 -!- kensai [~kensai@64.237.129.108] has joined #t2
05:30 -!- kensai [~kensai@64.237.129.108] has quit ["Leaving"]
09:51 -!- Corlis [Corlis@p3E9E6B1E.dip.t-dialin.net] has joined #t2
09:51 < Corlis> holladiho
09:52 < Corlis> hui, colorful building process... neat
09:53 < Corlis> hrm. but why pink... urgh
11:07 -!- nzg [~tschmidt@p508EBFFD.dip.t-dialin.net] has joined #t2
12:20 < rxr> hehe
12:20 < rxr> moin all - hi Corlis 
12:21 < Corlis> guggug
12:25 -!- tschmidt_ [~tschmidt@pD95F88BE.dip.t-dialin.net] has joined #t2
12:25 -!- tschmidt_ [~tschmidt@pD95F88BE.dip.t-dialin.net] has quit [Read error: 104 (Connection reset by peer)]
12:28 < rxr>  /.:
12:28 < rxr> Developers: E17 Available From CVS
12:28 < rxr> "As stated by Rasterman on his site, Enlightenment 0.17's window manager is now available on CVS, which means you can build e17 completely from it, as it is, and give it a try. Of course, it's still work in progress, and lacking in several areas, but it is usable, and looks as gorgeous as ever.
12:30 < rxr> http://enlightenment.org/pages/enlightenment.html
12:30 < rxr> time to updte our e17 repository
12:39 < valentin> very proud anouncement
12:41 < rxr> Gnumeric 1.4.0 Released
12:41 < rxr> ^- valentin - do you wanna update it ?
12:43 -!- nzg [~tschmidt@p508EBFFD.dip.t-dialin.net] has quit [Read error: 110 (Connection timed out)]
12:44 < valentin> gnumeric or e17 ?
12:44 < rxr> gnumeric
12:44 < rxr> e17 with all the libs getting them compiled is not that much fun and a longer process ...
12:45 < valentin> ok, i try to compile it - though the build process will be interupted when i travel to AH
12:49 < valentin> the download works :)
12:50 < valentin> but it is slow
12:50 -!- nzg [~tschmidt@pD95F88BE.dip.t-dialin.net] has joined #t2
12:54 < valentin> the download is too slow for curls
12:54 < rxr> ouhm
12:54 < rxr> restart it - it will append to the file continuing the download
12:54 < valentin> i know
12:55 < valentin> how can i pass Download options via Emerge-Package ?
12:55 < rxr> ouhm - maybe not possible - go imlement it ,-)
13:13 < valentin> this damn download never finishes
13:13 < valentin> need to look for a mirror
13:13  * valentin away now
13:22 -!- nzg [~tschmidt@pD95F88BE.dip.t-dialin.net] has quit [Read error: 104 (Connection reset by peer)]
13:46 -!- nzg [~tschmidt@pD95F88BE.dip.t-dialin.net] has joined #t2
13:50 < Corlis> anyone tried out xpde?
13:52 < rxr> npe
13:52 < rxr> nope - even
13:52 < rxr> this was the Win-XP GUI clone, wasn't it?
13:57 < Corlis> yup
14:08 < rxr> http://exactcode.de/rene/sco-we-own-all-your-code-pay-us-all-your-money.png
14:08 < rxr> just for the case sco manages to fix the craked homepage today ;-)
14:17 < jsaw> re
14:17 < rxr> hi
14:17 < jsaw> hi rxr 
14:18 < jsaw> sco.... 
14:18 < jsaw> hi Corlis 
14:18 -!- kensai [~kensai@64.237.129.108] has joined #t2
14:18 < valentin> re
14:19 < jsaw> hi valentin 
14:19 < valentin> hi jsaw
14:20 < Corlis> moin jsaw
14:20 < valentin> wow -the gnumeric download works again
14:20 < jsaw> To view the archive please input WSSWebinar as the "Meeting ID" and 4KX236 as the "Password".
14:20 < jsaw> ...
14:20 < rxr> ?
14:21 < jsaw> somewhere on the sco.com website
14:21 < rxr> hehe - yeah ;-)
14:22 < Corlis> rofl, thought was a joke... but they really have that logo on their site...
14:24 < rxr> yep - but the site was cracked ...
14:24 < rxr> you even see the "hacked by xyz" in the picture
14:24 < Corlis> oops
14:24 < jsaw> oh yeah, right...
14:24 < Corlis> it's monday :P
14:27 < rxr> Corlis: do you like xpde of why did you ask about it ?
14:36 < jsaw> have you seen this: http://www.hypergallery.co.uk/funny/scohacked ?
14:44 < Corlis> rxr: no, just was asking if someone of you tried that out, it might be interesting for users who say "Nah, I need to have a clear gui like windows has" :P
14:44 < Corlis> didn't try it out yet
14:53 < rxr> well - as "clean" as the windows GUI is ...
15:02 < jsaw> rxr: binutils-2.15.94.0.1.tar.bz2
15:07 < rxr> ach - shit
15:07 < rxr> damn rock scripts ..
15:08 < rxr> jsaw: ok - thanks - testing on powerpc
15:10 < rxr> after 2.1-final the damn scripts dir will be frozen into bug-fix only mode ....
15:23 < CIA-9> mnemoc * r4880 /trunk/package/develop/clip/clip.desc: * clip updated (1.1.12-44 -> 1.1.12-83)
15:23 < rxr> cxxfilt_instname.patch does not apply anymore
15:23 < mnemoc> hi
15:23 < rxr> hi
15:23 < mnemoc> rxr: can you grab clip's patch from my site? :)
15:24 < rxr> it does not download?
15:24 < mnemoc> yep, but not with curl
15:24 < mnemoc> their server doesn't support PASV
15:25 < rxr> hm - I try
15:25 < rxr> you can post the URL already for the case it does not download ...
15:25 < mnemoc> http://www.geeks.cl/rock-download/mirror/c/clip-patch-1.1.12-83.tbz2
15:27 < rxr> weee
15:27 < rxr> I might just have fixed all cross build regressions (including those present in ROCK for over a year) and removed more of cliffords ugly hacks on the way ;-)
15:29 < mnemoc> uhm? with the specs thing?
15:30 < rxr> yep - specs is already gone
15:30 < rxr> and now ugly symlinking got rippeed, too ;-)
15:30 < rxr> yeah!
15:30 < rxr> built!!!!
15:30 < rxr> I bet this fixes all cross builds that fail due to missing gcc builtin symbols ...
15:31 -!- Sparc-kly|G4 [~sparc@65-23-199-247.prtc.net] has joined #t2
15:32 < rxr> ah - mom - need to review one more missing piece for the big huray
15:34 -!- Corlis [Corlis@p3E9E6B1E.dip.t-dialin.net] has quit [" Try HydraIRC -> http://www.hydrairc.com <-"]
15:35 < rxr> yep - seems to be all fine ;-)
15:37 < rxr> now I only need to fix the Build-Target code to revert t
15:38 < rxr> back to the cross compiler after the pkgloop to complete my toolchain cleanup including linuxrc.c fixup ..
15:42 < jsaw> seems we will also have a uclibc target ready for 2.1 ... :)
15:42 < rxr> ;-)
15:43 < jsaw> rxr: btw cross compiling. How do you usually do fund raising (e.g. a AMD64 or so)?
15:43 < CIA-9> rene * r4881 /trunk/package/base/ (binutils/binutils.conf gcc/gcc.conf): 
15:43 < CIA-9> * fixed the new --with-sysroot usage (includign passing the correct
15:43 < CIA-9>  system root and using it for the real cross compiler) and also added
15:43 < CIA-9>  it to binutils
15:43 < CIA-9> * removed obsolete library symlink hacking
15:44 < rxr> jsaw: well - if I do not pay it myself?
15:44 < rxr> I talk to represantatives at fairs ...
15:44 < mnemoc> hi jsaw 
15:44 < jsaw> right, if you don't want to pay anything...
15:44 < jsaw> hi mnemoc 
15:44 -!- Sparc-kly|G4 [~sparc@65-23-199-247.prtc.net] has quit [Read error: 60 (Operation timed out)]
15:53 -!- kensai [~kensai@64.237.129.108] has quit ["Leaving"]
15:54 < rxr> haha linux-kernel: "i want help about kernel recompile "
15:57 < mnemoc> was he kicked?
15:57 < rxr> hehe ;-) a bit ...
16:00 < rxr> "A single tense is not enough to get help  ;) "
16:05 < rxr> jsaw: binutils passes basic powerpc checks - I apply it ..
16:08 < CIA-9> rene * r4882 /trunk/package/base/binutils/ (binutils.desc cxxfilt_instname.patch): 
16:08 < CIA-9> * updated binutils (2.15.91.0.2 -> 2.15.94.0.1) - seems to work again
16:08 < CIA-9>  on powerpc (.92. had regressions on powerpc) - cxxfilt_instname.patch
16:08 < CIA-9>  patch seems to be obsolete
16:09 < rxr> yeah - fixed cross build toolchain continues to bulid quite nicely
16:09 < jsaw> now, only gcc has to be fixed for the .rodata <-> linkonce thing
16:09 < rxr> yeah ;-)
16:10 -!- sparc-kly [~mubex@65-23-199-247.prtc.net] has quit [Read error: 110 (Connection timed out)]
16:10 < rxr> and Build-Target be fixed to fall back to the cross toolchain and not use the variables as left over from the last package built ....
16:10 < rxr> jsaw: do you take the linkonce thing?
16:12 -!- madtux [~mike@200.91.101.97] has joined #t2
16:12 < madtux> hello
16:12 < rxr> hi madtux !!!
16:12 < madtux> hello rene :)
16:12 < rxr> how are you these days?
16:12 < madtux> doing great
16:13 < madtux> i was sick
16:13 < madtux> but i'm fully recovered
16:13 < madtux> and with plenty of time for t2
16:13 < jsaw> rxr: well, I'm waiting for the gcc ppl to supply a patch...
16:13 < rxr> oh - did not know you have been sick - nice to see you recovered ...
16:13 < rxr> there have been somee proposed patches ...
16:14 < rxr> madtux: would be nice to see you back @ fun over here ;-)
16:14 < madtux> well i only need one thing to get started
16:14 < madtux> let me have an iso that i can load on mylaptop so i can keep on working like nothing and develop at the same time
16:14 < madtux> :)
16:15 < rxr> laptop is x86 ?
16:15 < rxr> than an ISO could be finished tomorrow ...
16:15 < rxr> I'm in the progress to fix all the remaining details to tag 2.1-beta ...
16:15 < madtux> rxr: ack
16:16 < rxr> if tomorrow + time to upload is early enough ;-)
16:16 < madtux> rxr: if you have something i can load on my ultras then count me into helping lots with sparc stuff
16:16 < madtux> rxr: sure it is
16:17 < rxr> well - a full Ultra ISO has to wait some more days ...
16:17 < rxr> but if you like to, you could get a dump of the HD some time soon
16:18 < jsaw> hi madtux, and bye, cu all l8r
16:18 < madtux> hello and bye jsaw 
16:19 < madtux> rxr: of course
16:19 < madtux> rxr: i just need something to make new isos and debug on my ultras.. those are not critical
16:19 < madtux> laptop is
16:20 < rxr> have you already taken a look into all the many t2 changes?
16:20 < madtux> no i'm about to do this now
16:22 < rxr> Addison-Wesley will be doing new printings of C++ Coding Standards and Exceptional C++ Style next week
16:24 < rxr> quite interesting:
16:24 < rxr> http://pluralsight.com/blogs/hsutter/
16:25 < madtux> rxr: i will be looking forward to see this
16:25 < madtux> :)
16:27 < madtux> rxr: are u looking forward to have a t2 version for pda's ?
16:28 < rxr> yes - in theory ..
16:29 < madtux> i know its easier to say it than actually doing but i've been just thinking about the world of possibilities that t2 coudl reach if we start getting involved in some embedded projects / systems
16:29 < rxr> right now my time quota for t2 is quite overextended ... - but when I have free time for extreme fun stuff, I plan to add a very tiny target that builds a 4MB system for my Psion Revo ...
16:30 < rxr> yes - I know - I already did embedded system for cPCI telecommunicatoin system for US cell-h
16:30 < rxr> phone stuff ...
16:30 < madtux> :)
16:30 < madtux> u know already that fun is @ embbeded :)
16:30 < rxr> but those are only partly embedded - basically you can throw a normal glibc based powerpc system onto those ...
16:30 < madtux> yeah
16:31  * madtux checking out svn trunk
16:31 < rxr> for the Revo with 16MB ram - for the filesystem and the running applications you really have to use dietlibc exclusively and just put the bare bone stuff onto it ...
16:31 < madtux> rxr: are you looking forward ro really make exact code linux/freesoftware based company?
16:31 < rxr> such a system for the 37Mhz ARM box has a image size of 4MB ... ;-)
16:32 < rxr> yep - mostly ...
16:32 < rxr> we plan to earn money with our GSMP and T2 based stuff - hope this works out ...
16:32 < rxr> but right now I'm making up a quite nice contract about a MacOSX driver for an image processing core I already have hre ...
16:32 < madtux> define we
16:33 < rxr> well - exactcode ... - is not just me
16:33 < rxr> at least valentin is as much involved as I - with other people already in the mind for later joining - if i
16:33 < rxr> it starts to grow ...
16:33 < madtux> :)
16:34 < rxr> or better not "if" but "when" ;-)
16:34 < madtux> sounds much better
16:35 < rxr> when 2.1-beta is out I have to put back some time spent on t2 due to the commercial contract that will generate the money to pay the rent ...
16:36 < madtux> :)
16:36 < rxr> which does mean of course that I have the time for the usual maintenance work - not just for day and night debugging seassions or sparc fights ...
16:36 < rxr> but there are 7 more people with commit rights - so this will not stall t2 in any way ...
16:36 < rxr> after all we are not as centralized as this other project ...
16:37 < rxr> btw, look at the nice stats:
16:37 < rxr> http://svn.exactcode.de/
16:37 < madtux> i'm looking at them :)
16:38 < rxr> how much absense of "thy only write accessor in cheif" can stall other projects" ;-)
16:38 < rxr> madtux: if you plan to contribute regularly and use t2 and such you get write acces of course, too
16:39 < madtux> i intend to
16:39 < madtux> i'm currently reading everything so i can find url to subscribe the mailing list and all
16:39 < rxr> well - after some patches showing you are doing "the right thing(tm)" just ask for it ;-)
16:39 < rxr> http://www.exactcode.de/t2/contact.html
16:40 < madtux> danke
16:42 < madtux> subscribing
16:44 < madtux> -- you have subscribed to T2 successfully.
16:44 < madtux> :)
16:45 < mnemoc> ya era hora
16:46 < madtux> :P
16:57 < rxr> I just improved the package matrix a bit ..
16:57 < rxr> regenerate running
16:58 < madtux> mm.. ok updating my trunk
16:58 -!- nullslack [~nullslack@203.190.73.220] has joined #t2
16:58 < madtux> nullslack: :)
16:58 < nullslack> madtux, ;) is this the reason why you've PM me lol
17:00 < madtux> maybe :)
17:00 < nullslack> just found out about t2 today
17:00 < madtux> just checking nullslack = sed ?
17:01 < nullslack> who's sed?
17:01 < madtux> sandra "eule" dismar?
17:02 < nullslack> hehehe sorry bro....how did you came up with that? is this the nick that she's using also?
17:02 < madtux> null :)
17:02 < madtux> ah nevermind.. then let me introduce myself
17:02 < madtux> I'm Miguel who are you?
17:03 < nullslack> are u one of the developers of t2?
17:03 < madtux> not yet.. but i'm looking forward to become one
17:03 < nullslack> so have u tried t2 already?
17:03 < rxr> nullslack: developers are around, too ;-) - just ask your question(s) 
17:04 [Users #t2]
17:04 [ _martin_] [ daja77] [ mnemoc   ] [ nzg    ] [ valentin] 
17:04 [ _Ragnar_] [ jsaw  ] [ mtr      ] [ praenti] 
17:04 [ CIA-9   ] [ madtux] [ nullslack] [ rxr    ] 
17:04 -!- Irssi: #t2: Total of 13 nicks [0 ops, 0 halfops, 0 voices, 13 normal]
17:04 < madtux> nullslack: but u can find me on the top of the rocklinux devs gallery :)
17:04 < nullslack> rxr, thanx,,,but it will be really annoying because i am really starting out
17:04 < rxr> no problem at all ;-)
17:04 < nullslack> thnx!!!
17:05 < rxr> nullslack: may I ask where you found t2 today?
17:05 < nullslack> rxr, distrowatch
17:06 < madtux> nullslack: the only dump question is the one is not asked
17:06 < madtux> :)
17:06 < rxr> hm - distrowatch? have not seen us there yet ...
17:06 < madtux> checking
17:07 < nullslack> madtux, thnx...
17:07 < rxr> ah - there it is ;-)
17:07 < madtux> besides.. we are nice people
17:07 < madtux> we like to help 
17:07 < madtux> :)
17:08 < madtux> but you have to be patient as sometimes we are busy or so to answer right away
17:08 < madtux> right rxr ?
17:08 < rxr> think so ;-)
17:08 < rxr> nullslack: you found us in the list of to be included dists, right?
17:08 < nullslack> http://distrowatch.com/weekly.php?issue=20041129#1
17:08 < nullslack> on the waiting lists
17:09 < rxr> cool - yes! Thanks!
17:11 < rxr> ok - the package matrix now includes links to the T2 sources ... :
17:11 < rxr> http://www.exactcode.de/t2/packages/binutils.html
17:11 < nullslack> guys i don't mean to be personal...but why did t2 fork from rock? because right now i am about to start rock but then i've found out about t2 and it is up to date and it has xorg..so...just curious.
17:12 < rxr> nullslack: this is mostly explained on the t2 project site ...
17:12 < madtux> :)
17:12 < rxr> nullslack: in fact I was one of the rock core architect for years and the one bringing rock a stable 2.0 series ...
17:13 < rxr> personal view:
17:13 < rxr> rock linux is centralized - everything goes over clifford's hands
17:13 < rxr> what he does not like does not go in - and when he has some visions hi
17:14 < rxr> he implements them even if everyone else disagrees and it renders the tree useless for weeks ...
17:14 < rxr> and if he is away - vacation or whatever - you see no commits at all (write access one model)
17:14 < rxr> aside from that ROCK Linux 2.1 and up get full of obscure features and code pathes noone is ever able to keep working and maintained ...
17:15 < rxr> the ugly package forking and splitting is just the start - then comes pseudo cross native hacks and so on ...
17:15 < rxr> and the tone under the rock developers is quite unfriendly  and so on and so on
17:16 < rxr> but most of it can be read on the t2 page ...
17:16 < nullslack> u mean some of the rock dev are arrogant?
17:16 < rxr> one could say this to my summary above, too
17:16 < rxr> but yes - they are ..
17:17 < madtux> errr... rxr Don't you think that Documentation/TEAM should be updated?
17:17 < nullslack> hmmm...how many rock dev are developing in t2?
17:17 < madtux> as well as Documentation/COPYING
17:17 < rxr> madtux: yes - removed
17:17 < mnemoc> 4-5?
17:17 < rxr> Documentation is intended to be removed ...
17:17 < madtux> rxr: all of it?
17:18 < nullslack> ic..so how many devs are left with rock?
17:18 < mnemoc> rxr: move it to obsolete/
17:19  * madtux looks at package ... FINALLY! a real package repository distribution..
17:19 < madtux> :)
17:19 < nullslack> so..rxr = rene?
17:20 < mnemoc> yes
17:20 < madtux> mm.. target/mnemosyne
17:20 < CIA-9> rene * r4883 /trunk/Documentation/ (COPYING README TEAM): * some basic Documentation update and removal
17:20 < rxr> we can not remove or it that easily - the scripts access stuff in Documentation/Developers/*
17:21 < rxr> this always suck - but what do you do when clifford wanted it this way ..
17:21 < rxr> we migrate the stuff away when we have timem and need ...
17:21 < madtux> hello CIA-9 
17:21 < madtux> rxr: i will look at it and try to propose a solution :)
17:21 < rxr> well the solution is to place the stuff in misc ...
17:22 < madtux> ok
17:22 < rxr> e.g. the REGISTER file is used and the PKG-FORMAT or so in the scripts ...
17:22 < CIA-9> rene * r4884 /trunk/ (COPYING Documentation/COPYING): * moved COPYING into the top level directory
17:22 < rxr> this data files just need to be placed in the misc directory .. not Documentation ...
17:22 < madtux> rxr: i'm about to launch a build suggestions?
17:22 < madtux> as in target and so
17:22 < nullslack> rxr, typo in the handbook..introduction: "clifford wold"
17:23 < rxr> nullslack: oh - thanks - fixed in the sources ...
17:24 < rxr> madtux: what?
17:24 < madtux> rxr: i want to run a fresh build.. is 2.1.0-beta stable enough?
17:25 < madtux> any know issues? comments? etc
17:25 < mnemoc> madtux: absolutly :)
17:25 < rxr> yep - should be
17:25 < rxr> mnemoc: I reworked the cross toolchain tonight - so better do not yet say absolutely ...
17:25 < rxr> but well - I fixed all regressoins this morning and it should be stable again ;-)
17:26 < rxr> we only have one remaining C++ related gcc-3.4.x regressoins concerning heavy template usage ... you can ingore normally for now (onoly 
17:26 < rxr> only stlport and ooo affected mostly)
17:26 < rxr> and a bootdisk target Build-Target issue which will work for you but needs a proper fix - I'm working on it ... aside from that it is very stable and 2.1-beta or so tagged tomorrow ...
17:27 < madtux> okis
17:27 < madtux> then i will lauch the build
17:29 < rxr> nullslack: to judge what to use maybe just dive thru the rock linux mailing list or so ... and get an overview about them ...
17:30 < nullslack> rxr, i have gone there already and asked a couple of questions...blindcoder and netrunner was there to help me. but i never get to chat with clifford.
17:31 < rxr> in irc I guess?
17:31 < nullslack> rxr, is blindcoder one of the devs also?
17:32 < rxr> well - to soem degree ;-)
17:33 < mnemoc> rxr: rxr: can you take a look into http://svn.geeks.cl/atarigo/game.cc:100 (AskInt) ?
17:33 < CIA-9> rene * r4885 /trunk/package/base/ (binutils/binutils.desc gcc/gcc.desc): 
17:33 < CIA-9> * added a propper binutils patch and injected my name as maintainer
17:33 < CIA-9>  for gcc and binutils
17:33 < mnemoc> rxr: that $thing stalls if text is entered :(
17:33 < rxr> mnemoc: one thing 
17:34 < rxr> in C++ it is often faster and considered better style to use pre-increment
17:34 < rxr> especially for iterators ...
17:34 < rxr> so ++i or ++j ...
17:34 < mnemoc> ok
17:35 < rxr> the post increment has to craete a temporary oject to hold the value ... and the compiler does not always optimize all unused away ...
17:35 < rxr> hm - looks ok - I test it here ..
17:38 < rxr> hm - quick guess the "\n" left over is not good ;-)
17:38 < nullslack> one reason i like to build my own distro is updates...is t2 capable fo this? i mean can i update the package personally, even if t2 hasn't done so? i don't like to depend on the updates coming from the distro maintainers ;)
17:39 < rxr> well - sure you can update it in your private tree ...
17:40 < rxr> but when you do a "svn up" the next time you might get some conflict ...
17:40 < rxr> updates in t2 are pretty easy - often just the version bump in the .desc file ...
17:40 < rxr> it would be most convienient for you when you actually submit updates ...
17:40 < rxr> when you contribute more than one patch per months or so you can even just get svn write access ...
17:41 < rxr> (the big difference to rock linux ...)
17:41 < nullslack> rxr, i mean whenever there's some security issues.
17:41 < mnemoc> rxr: removing \n doesn't help :\
17:41 < rxr> I know
17:41 < rxr> mnemoc: I work on it ..
17:42 < rxr> nullslack: then just drop the .patch file in the pacakge directory and rebuild the package ...
17:42 < rxr> optimally send us the patch, too - and/or commit immidiately
17:43 < nullslack> rxr, hmmm...but the patch will be coming from the package maintainer...i am not capable of building one ;(
17:43 < rxr> you asked about your own updates when there is a security problem
17:44 < rxr> so when apache d
17:44 < rxr> foundation releases a security patch I was talking about the fact that you can just drop it into the T2 apache package source directory and rebuild apache ...
17:44 < rxr> when you do not want to wait for our apache maintainer to notice the patch and inject it into t2 ...
17:45 < rxr> a t2 package source looks like this:
17:45 < rxr> http://svn.exactcode.de/t2/trunk/package/network/apache/
17:45 < rxr> overview here:
17:45 < rxr> http://www.exactcode.de/t2/packages/apache.html
17:46 < mnemoc> rxr: adding a cin.clear() _before_ the ignore solves the problem
17:46 < rxr> well - but that is a bad hack ...
17:47 < rxr> I guess it fails in your code because
17:47 < rxr> after the ignore the stream is in EOF state ...
17:49 < mnemoc> http://www.augustcouncil.com/~tgibson/tutorial/iotips.html#directly <-- nice page
17:50 < rxr> hm - ok - then do it that way ;-)
17:51 < mnemoc> i added the clear() and worked before finding that page :)
17:57 < rxr> cool - I do not know the star trek episode broadcasted right now over here ...
17:59 < mnemoc> there is an automated way to revert different that svn diff -r(n-1)-(n) | patch -Rp0 ?
18:00 < rxr> svn merge -r(n)-(n-1)
18:00 < mnemoc> thanks
18:03 < nullslack> rxr, what's t2's goal?
18:04 < rxr> the big overview goal - or the roadmap for the next year?
18:05 < nullslack> rxr, the fix goal
18:06 < rxr> in short:
18:07 < rxr> a _stable_, flexible System Development Environment that supports buildin whole systems based on open source kernels (so to be come Hurd, BSD, OpenDarwin) or in-system package builds (so to come MacOSX and Solaris) using a flexiable, _maintainable_ and professionally sorted source base
18:08 < rxr> where _stable_ and _maintainable_ are the big points I think we already differ quite a lot from ROCK
18:08 < rxr> this all in a normal Open Source colaboration fully decentralized
18:09 < nullslack> cool!!! 
18:10 < nullslack> i have downloaded alpha3...can it be built even if i'm not using devfs?
18:11 < rxr> yes
18:11 < rxr> but I recomment to use a svn checkout ...
18:11 < rxr> we did so much since alpha3 ...
18:12 < nullslack> ic...i can do it thru http right?
18:12 < rxr> yes
18:12 < rxr> you have a svn client installed?
18:13 < nullslack> btw, i've read that rock must be built in an environment with devfs?
18:13 < nullslack> rxr, no svn
18:13 < nullslack> so i've downloaded rock-bbs to build from it
18:13 < rxr> nullslack: this information is false - I fixed this already in ROCK a year ago ...
18:14 < rxr> where did you read this? I guess not in n
18:14 < rxr> my handbook ...
18:14 < nullslack> rxr, no...i think somewhere in the rock 2.0.3
18:15 < rxr> well - one big missing point in ROCK always was documentation
18:16 < rxr> I filled it with the handbook - although they removed the link to the handbook since it was renamed to t2 ;-)
18:16 < rxr> http://www.augustcouncil.com/~tgibson/tutorial/iotips.html#directly
18:16 < rxr> oops - rong
18:16 < rxr> http://www.exactcode.de/products/t2-handbook/
18:17 < nullslack> yeah i noticed...first time i've looked in the site, i've asked myself...what happened to the handbook?
18:17 < rxr> it is also still valid for most of ROCK - except all the 2.1 brokenness I stopped documenting ...
18:19 < nullslack> how difficult it is to build a package which is not in t2's lists?
18:21 < mnemoc> rxr: have you used signals to public methods?
18:21 < rxr> signals?
18:21 < rxr> nullslack: since T2 is pretty much FHS and LSB conform you just can run
18:21 < rxr> the usual ./configure ; make ; make install - cycle ...
18:21 < mnemoc> alarm(SIGALRM,function)
18:22 < rxr> and it is pretty easky to package those packages in t2, you just need to add some tags into a .desc file ...
18:22 < rxr> mnemoc: you can not do this IIRC - since you have no this pointed 
18:22 < rxr> pointer to the relevant object ...
18:22 < mnemoc> damn
18:23 < rxr> google for it ..
18:23 < rxr> just construct some trampoline ...
18:23 < mnemoc> i'm doing that last 30 minutes
18:23 < mnemoc> trampoline?
18:23 < nullslack> i wish there's a step-by-step from the handbook ;)
18:24 < rxr> for adding packages or for building t2 ?
18:24 < mnemoc> rxr: i'll try...
18:25 < nullslack> rxr, for adding new packages ;)
18:25 < rxr> well - valentin started a tutorial ...
18:26 < nullslack> now i am getting more excited about this
18:26 < nullslack> ;)
18:26 < rxr> but it is not yet ready ..
18:27 < rxr> this is the start ...
18:27 < rxr> http://www.exactcode.de/t2/pkgtutorial.html
18:28 < rxr> but it is not such a problem to finish that soon and add an in-depth section to the handbook if there is demand
18:28 < nullslack> rxr, btw, is t2 still only for sysv init?
18:29 < rxr> nope - we have more inits ... ;-)
18:29 < rxr> mnemoc et al might like to elaborate on it ;-)
18:29 < nullslack> rxr, because i prefer the bsd ones...i'm a slackware fanatic ;)
18:30 < nullslack> die-hard!
18:30 < mnemoc> rxr: i will
18:31 < nullslack> rxr, so i can build a distro with a bsd init...right?
18:33 < rxr> hm - right now I think no - but there are alternative minimal inits available ...
18:33 < rxr> but you are free to add the relevant pieces to get a bsd init ...
18:33 < mnemoc> i was thinking in some kind of dos' .ini
18:33 < mnemoc> defining needed stuff
18:34 < mnemoc> compiling it to selected init
18:34 < mnemoc> and applying the style after that
18:35 < rxr> yes - the .init files are intendet to be the base for other styles to be generated - just that it did not get as ascalable as I wished ...
18:36 < nullslack> how i wish that bsd init gets included from the Config ;)
18:36 < rxr> nullslack: what do you exactly mean?
18:36 < mnemoc> rxr: that's why i want to compile .uinit files (micro init)
18:37 < nullslack> rxr, from what i understand the build uses sysv init...am i right?
18:37 < nullslack> rxr, i mean after the build
18:38 < nullslack> rxr, i just wanted it to be simple...just like the bsd init...specially if i'm building a server only distro
18:39 < rxr> nullslack: right now there are more init's in t2 than sysvinit, there is at least runit and minit or so ...
18:40 < rxr> nullslack: if you want some more lightweight init in t2 you are free to add it - and even get support from us ...
18:40 < mnemoc> runit and sysvinit operative, minit just built
18:40 < rxr> mnemoc: what do you mean with .uinit ?
18:40 < mnemoc> rxr: something like .desc files
18:41 < mnemoc> rxr: to be compiled into a .init
18:42 < rxr> well .init is the intended base ... it just does not scale enough ... - it is on my todo to exapand this ...
18:49 < mnemoc> .uinit _will_ scale
18:50 < rxr> you do not nned to rename it ...
18:52 < mnemoc> yes, because the approach is different
18:52 < mnemoc> and i need pre-compiled inits for system, and other complex scripts
18:53 < mnemoc> you will see
18:53 < rxr> ok ;-)
18:53 < mnemoc> but i need to finish the go player first
18:57 -!- nzg [~tschmidt@pD95F88BE.dip.t-dialin.net] has quit ["Verlassend"]
18:57 < rxr> please do this after -beta(1) ...
18:58 < nullslack> rxr, maybe the irc chan on the hanbook should be changed to #t2 ...page 22
18:58 < rxr> hehe
19:02 < rxr> nullslack: changed it in the source - however it will take some days until it will be online
19:04 < nullslack> ;) and it will also take me a couple of days to run t2
19:06 < rxr> ?
19:09 < nullslack> rxr, i'm still trying to digest the handbook ;)
19:11 < nullslack> rxr, first is that i would like to build a bootable minimal base package...and build from there...server, desktop, etc..
19:11 < CIA-9> rene * r4886 /trunk/target/bootdisk/x86/build.sh: * fixed bootdisk/x86/build.sh for the new -dist kernel ending
19:11 < rxr> then checkout the source (via svn)
19:12 < rxr> and configure to build a general t2 and additional apply the "minimal" package preselection tempalte from the experts menu
19:12 < CIA-9> rene * r4887 /trunk/target/bootdisk/config.in: 
19:12 < CIA-9> * fixed the bootdisk/config.in to use the new (unversioned) config
19:12 < CIA-9>  option to disable java in gcc
19:13 < nullslack> rxr, what target should i chose?
19:13 < rxr> you can choose generic as target
19:15 < nullslack> rxr, generic will build all packages right?
19:15 < rxr> yep - and this is why you can select the minimal package preselection template to just build the minimal packages
19:19 < nullslack> rxr, ok..saw it! thnx
19:29 < CIA-9> rene * r4888 /trunk/package/gnome2/gnumeric/gnumeric.desc: * updated gnumeric (1.3.91 -> 1.4.0)
19:33 [Users #t2]
19:33 [ _martin_] [ CIA-9 ] [ jsaw  ] [ mnemoc] [ nullslack] [ rxr     ] 
19:33 [ _Ragnar_] [ daja77] [ madtux] [ mtr   ] [ praenti  ] [ valentin] 
19:33 -!- Irssi: #t2: Total of 12 nicks [0 ops, 0 halfops, 0 voices, 12 normal]
19:55 < rxr> ok - me preparing evening meal - and then I have to prepare the talk I have to hold tomorrow - about tri-states ...
20:21 -!- CIA-9 [~CIA@to.je.spocco.com] has quit [Remote closed the connection]
21:00 -!- rxr_ [~rene@p213.54.210.226.tisdip.tiscali.de] has joined #t2
21:00 -!- Topic for #t2: T2 | the system development environment | http://www.exactcode.de/t2 | C++ people around, too
21:00 -!- Topic set by rxr [] [Mon Nov 29 02:10:27 2004]
21:00 [Users #t2]
21:00 [ _martin_] [ daja77] [ madtux] [ mtr      ] [ praenti] [ rxr_    ] 
21:00 [ _Ragnar_] [ jsaw  ] [ mnemoc] [ nullslack] [ rxr    ] [ valentin] 
21:00 -!- Irssi: #t2: Total of 12 nicks [0 ops, 0 halfops, 0 voices, 12 normal]
21:00 -!- Channel #t2 created Sun Aug  8 21:15:33 2004
21:00 -!- [freenode-info] why register and identify?  your IRC nick is how people know you.  http://freenode.net/faq.shtml#nicksetup
21:00 -!- Irssi: Join to #t2 was synced in 10 secs
21:05 -!- rxr [~rene@p213.54.229.162.tisdip.tiscali.de] has quit [Nick collision from services.]
21:05 -!- You're now known as rxr
21:07 < rxr> with reworked cross-toolchain:
21:07 < rxr> Error logs from install-2.1.0-beta-x86-pentium-mmx-32-bootdisk-expert:
21:07 < rxr> 160 builds total, 160 completed fine, 0 with errors.
21:07 < mnemoc> :D
21:10 < nullslack> rxr, what packages usually are downloaded my the minimal template? and what's the total size?
21:14 < nullslack> cvs -z9 -Q -d :pserver:anoncvs@sources.redhat.com:/cvs/glibc co -P -D 2004-08-01 libc
21:14 < nullslack> 118M downloaded from CVS archive (download finished)
21:15 < nullslack> hmmm...is it really 118 MB?
21:15 < mnemoc> expanded
21:15 < mnemoc> plus CVS garbage
21:15 < madtux> 0_o
21:15 < mnemoc> ./CVS/
21:16 < madtux> ok
21:16 < nullslack> ic...cause i check it out and it's only 13 MB
21:16 < mnemoc> uhm
21:18 -!- CIA-9 [~CIA@to.je.spocco.com] has joined #t2
21:18 < nullslack> whoaaa....how many kernels will the minimal template download? i have 2.6.8.1 then 2.6.9 and it stop complaining that the link is too slow now it's downloading 2.4.28 ;(
21:18 < nullslack> i mean stop downloading
21:22 < rxr> those thee ..
21:23 < rxr> three even
21:23 -!- mtr [~michael@Hb397.h.pppool.de] has quit [Remote closed the connection]
21:23 < nullslack> rxr, total size of download?
21:23 < nullslack> i even got dietlibc
21:23 < rxr> 2.4 and 2.6 and the 2.6.8.1 are for the kernel headers to be used for user-space applications - the headers of recent kernel (2.6.9 and up) are quite broken for that purpose - this is why we still use 2.6.8.1 for that ..
21:24 < rxr> dietlibc is tiny ;-)
21:24 < rxr> nullslack: no idea - how much it will download - maybe around 300MB or so ?
21:25 < nullslack> whoaaa....that's minimal lol
21:26 < mnemoc> nullslack: it's unmaintained
21:26 < rxr> mnemoc: nope it isn't ...
21:26 < mnemoc> o_O
21:26 < rxr> nullslack: well - the kernels gcc and glibc alone are quite a lot
21:26 < rxr> mnemoc: I fixed the templates basically some days ago ...
21:27 < nullslack> curl: (22) The requested URL returned error: 404 -- is this ok?
21:27 < rxr> depends ...
21:27 < rxr> for which file is it? binutils?
21:27 < nullslack> INFO: download from mirror failed, trying original URL -- but it says this
21:27 < nullslack> rxr, all files
21:27 < rxr> all files?
21:28 < rxr> which mirror did you got?
21:28 < nullslack> yes
21:28 < nullslack> it says the original url
21:29 < rxr> the Download test for mirror sites at the beginning
21:29 < rxr> and then it tries to fetch the files from the mirror - and only tries the original URL as fallback
21:29 < rxr> what does cat download/Mirror yield ?
21:31 < nullslack> b/  d/  g/  l/
21:31 < nullslack> oh sorry!!! http://nexus.tfh-berlin.de/~t2/source/2.1
21:31 < rxr> ah - ok - this mirror does not yet include all files ...
21:32 < rxr> this is known - and solved soon (disk space outage - and it is not our box ...)
21:32 < nullslack> i'll kill the download now ;(
21:32 < rxr> why?
21:33 < rxr> the files are fetched from the orignial sites then ...
21:34 < nullslack> oh! damn! you're right! ;(
21:34 < nullslack> i just killed it!
21:34 < rxr> restarting will continue to download only the missing ...
21:35 < rxr> not all the downloaded stuff again ;-)
21:36 < nullslack> rxr, thnx...but am i right...a total of 16 packages only? ;
21:36 < rxr> ?
21:37 < nullslack> doing CTRL-C only aborts each package...am i right? the last one is memtest
21:37 < rxr> yes - due to the nature of this shell script it will only kill the current download - if you hit it twice quickly it will kill the script ...
21:38 < nullslack> oh...so it is more than 16
21:49 < CIA-9> rene * r4890 /trunk/package/x11/xorg/xorg.desc: 
21:49 < CIA-9> * fixed xorg to use the real release tarballs - not the pre-release
21:49 < CIA-9>  once we got the checksum for in the .desc file
22:02 < rxr> rebuilding the install target just for retesting my infrastructure work again ;-)
22:05 < nullslack> install target?
22:06 < rxr> well - named bootdisk ;-)
22:06 < rxr> the "code" generating only the stuff needed for the "installer"
22:07 < nullslack> hmmm...installer?
22:27 < rxr> when you create a bootable CD or DVD out of T2 ...
22:48 < CIA-9> rene * r4891 /trunk/package/base/glibc/glibc.conf: 
22:48 < CIA-9> * fixed glibc stage 0 header installation for our new toolchain
22:48 < CIA-9>  (install into the system root - not the tools directory ...)
22:48 < rxr> ^- vital - please "svn up"
22:52 < madtux> svn uping
22:54 < jsaw> re
22:54 < rxr> hi jsaw !
22:54 < jsaw> hi rxr 
22:55 < jsaw> seems like I'm gonna ./scripts/Cleanup -full real soon...
22:56 < jsaw> ¡hola madtux!
22:57 < mnemoc> .oO( espero en un par de años merecer un saludo tan efusivo como ese )o
22:57 < jsaw> hi mnemoc 
22:58 < jsaw> and now the translation please...
22:58 < jsaw> efusivo = ?
22:58 < rxr> you wanna Cleanup -full ?
22:59 < jsaw> rxr: well not immediately, I have created a few ISOs from current (HEAD-30 or so).
23:00 < jsaw> I want to try "--enable-shared" globally
23:01 < rxr> forget my "fix" above ...
23:01 < mnemoc> jsaw: i hope to deserve in a couple of years a greeting as warm as that 
23:01 -!- praenti [~praenti@mail.obster.org] has quit [Read error: 104 (Connection reset by peer)]
23:01 -!- praenti [~praenti@mail.obster.org] has joined #t2
23:02 < rxr> mnemoc: ?
23:02 < jsaw> mnemoc: just disappear for a couple of month, and voilá..
23:02 < mnemoc> :D
23:02 < jsaw> rxr: he meant the ¡! thing
23:02 < mnemoc> i was joking
23:03  * rxr first need to find out which key-combination yields the spanish (and so on) rotated ! ...
23:03 < rxr> aside from cut'n pasting yours ....
23:04 < jsaw> <win-left> ! !
23:05 < rxr> no win key on the apple keyboard ... ;-)
23:05 < rxr> (and on my rs6k keyboard I have tux keys ,-) just to joke a bit ...
23:06 < mnemoc> ¿y la interrogación?
23:07 < jsaw> rxr: it's just the key you define for "Composed" characters
23:07 < jsaw> but *damn* I forgot how I set it up...
23:08 < rxr> oh - yeah the compose key - do not have it on my normal workstations - just ISO_Level3_Shift
23:08 < rxr> only my sparcs have the native compose key on the keyboard ...
23:09 < jsaw> yeah, but you can define whatever key you want. Before that I usually had it on the right Control key.
23:09 < rxr> I know ..
23:10 < rxr> (the xkb modification part)
23:28 < rxr> ok - one more "tiny" regression to fix - better not yet start a build ...
23:28 -!- kensai [~kensai@64.237.129.108] has joined #t2
23:39 < rxr> ok - I think I fixed that regression
23:39 < rxr> == 11/29/04 23:39:16 =[0]=> Finished building package gcc.
23:40 < jsaw> I'll test stlport after binutils/gcc is rebuilt and hope ...
23:41 < CIA-9> rene * r4892 /trunk/package/base/glibc/glibc.conf: 
23:41 < CIA-9> * fixed the glibc stage-0 installation rework to install the headers
23:41 < CIA-9>  into .../usr/include (not .../include)
23:41 < CIA-9> * fixed the stage-0 post installation fixup to use .../usr (not the
23:41 < CIA-9>  old tools location)
23:41 < rxr> in fact all this changes already make the file layout and bootstrap of t2 simpler and less error-prone ...
23:41 < rxr> already pointing into the direction of cleanups for cross compile everything ;-)
23:41 < mnemoc> uhm
23:41 < rxr> pointing not doing it ...
23:42 < mnemoc> =)
23:42  * mnemoc aborting his build
23:42 < rxr> I just fix our (rock inherited) bugs and cleanup the code and layout on the way
23:42 < rxr> wait a moment with the restart
23:43 < jsaw> still in the "rock-inheritet,rxr-created" bugs phase ;) ?
23:44 < CIA-9> rene * r4893 /trunk/package/base/dietlibc/dietlibc.conf: 
23:44 < CIA-9> * fixed dietlibc to install the stage-0 headers into the system root
23:44 < CIA-9>  not the tools directory ...
23:44 < rxr> jsaw: did you saw the "cross" bulid of ROCK in pre 1.7 versions before I really implemented it?
23:45 < jsaw> rxr: no - and actually I don't want to know... :p
23:45 < rxr> you applied some patches from various bugzillas to fix the linkonce bug?
23:46 < rxr> jsaw: we had tons of copied headers in arch/$arcg/include since clifford thought they can not be "generated"
23:46 < jsaw> rxr: no, not yet. The messages from bugzilla are somewhat "opposite"
23:46 < rxr> and we had cool uuencoded .a files of some libs some guru meant are needed for gcc to be build ...
23:46 < jsaw> There seems to no *real* fix yet.
23:47 < jsaw> But maybe the new binutils is a bit less strict.
23:47 < jsaw> So, I'll wait for gcc/binutils.
23:47 < jsaw> If stlport or root compiles, I don't have to do anything for now...
23:47 < rxr> and the cross compiler was not built using the normal scripted build system - but with one mostly hardcoded Build-CrossCC script ..
23:48 < jsaw> mooo
23:48 < rxr> you should deflate some 1.4.0 or so and smile - when you have some free minute ;-)
23:49 < jsaw> :D
23:49 < rxr> too much ROCK history in brain ...
23:49 -!- kensai [~kensai@64.237.129.108] has quit ["Leaving"]
23:51 < jsaw> das faellt _*ueberhaupt nicht*_ auf... ;-) (sorry no idea how to translate)
23:52 < jsaw> rxr: I will unpack 1.4 in a calm minute.
23:52 < jsaw> definitely.
23:53 < jsaw> <- has to repair some broken toys (of and by daughter), disappearing in some dark corner of the lab but continue listening...
23:55 < rxr> you can continue listening in dark corners of the lab? do you have some text-to-speach running there ;-?
23:55 < jsaw> no. but that's actually an extremely good idea!!!
23:56 < jsaw> (the explanation is, if I switch of the light at my work place -> it is a dark corner *hehe*)
23:56 < jsaw> no really, I run by my desktop once in a while, because there are two lab rooms in opposite direction...
23:57 < jsaw> rxr, do you know how usable rsynth/flite are?
23:59 < rxr> I think I never was able to listen to rsynth because it does only produce noise on my iBook - most probably endian issues
23:59 < rxr> flite is quite ok - about the quality of the MacOSX integrated speech output (which is also not that good)
--- Log closed Tue Nov 30 00:00:53 2004