--- Log opened Mon Dec 20 00:00:41 2004 01:30 < jsaw> enlightenment dr16.7.2 01:38 < mnemoc> rehi 01:39 < mnemoc> rxr: where that came from? 01:39 < jsaw> hi mnemoc 01:39 < mnemoc> hi jsaw 01:39 < rxr> hi! 01:40 < mnemoc> hi rxr 01:40 < jsaw> hi rxr 01:40 < rxr> jsaw: do you commit the e16 update ? 01:40 < jsaw> yep. 01:40 < rxr> cool 01:40 < rxr> to bad I'm stuck in osx for the next hours ... - until we can ship this beta ... 01:41 < mnemoc> rxr: isn't this reasonable: - choice ROCKCFG_ABORT_ON_ERROR_STAGE 5 \+ choice ROCKCFG_ABORT_ON_ERROR_STAGE 4 \ ? <--- what was this? 01:41 < mnemoc> do you want to reduce the default to 4? 01:41 < rxr> yes 01:41 < rxr> too much is failign in 5 right now ... 01:42 < rxr> not that that would motive us fixing it, ... but I also want some usable builds on the fixup waya ... 01:43 < jsaw> mnemoc: the variable says "abort on error in stage" but the config and the script logic says: abort _after_ stage x 01:43 < mnemoc> it's abort until stage, or continue after stage 01:43 < rxr> for me it stopped at an error in stage 5 01:44 < mnemoc> yes 01:44 < rxr> I just would like to see 4 the default (for now) 01:44 < mnemoc> > 5 continue 01:44 < mnemoc> ok 01:45 < mnemoc> it has sense too becasue core packages are first built <5 01:45 < rxr> yep 01:45 < mnemoc> jsaw: what do you want to rename, variable, description, help or all of them 01:45 < mnemoc> ? 01:46 < CIA-9> rene * r5147 /trunk/scripts/config.in: * changed default "abort up to and including stage" to 4 01:47 < rxr> OT, should I commit the gtk+ and siblings update ? 01:47 < jsaw> actually I don't care. Just consistent. I somehow expected, if it is set to "5", it's not going to retry building a broken package. 01:48 < jsaw> but now that it is set to 4 as default, guess, rename the variable. 01:48 < mnemoc> you wanted continue on >= stage instead of continue on > stage ? 01:49 < mnemoc> what name do you propose? 01:49 < jsaw> I expected this behavious, but I was too lazy to read the config text. 01:49 < jsaw> s/STAGE/AFTER/ 01:50 < rxr> yes, the variable could get an name tweak ... 01:50 < mnemoc> ok, i'll do that 01:54 < mnemoc> yes! another good merge with svk :) 01:54 < CIA-9> mnemoc * r5148 /trunk/ (5 files in 2 dirs): * ROCKCFG_ABORT_ON_ERROR_STAGE changed to ROCKCFG_ABORT_ON_ERROR_AFTER 01:56 < mnemoc> jsaw: did you found why 1-gzip is failling on bootdisk? 02:04 < rxr> if I would not be busy with this "product" I would have taken a look 02:05 < rxr> my bootdisk target is at the same error - stalling 02:07 < mnemoc> i fully understand you 02:07 < mnemoc> but i try and try to fix it but it is over me :\ 02:07 < mnemoc> my two crossbuilds failed too, due to different reasons on 1-glibc :( 02:08 < jsaw> no, not yet. I only now that the diet call fails. It fails hard 02:09 < jsaw> 'cause execve returns 02:09 < jsaw> (in cmd_wrapper) 02:10 < jsaw> execvp even... 02:11 < jsaw> tuning cmd_wrapper to log the errno 02:11 < jsaw> now 02:12 < rxr> mnemoc: yes - some cross builds fail strangely ... 02:12 < rxr> this is a long known regression from rock times 02:12 < rxr> I thought my toolchain clenaup/rework would fix it - but it did not yet 02:13 < mnemoc> i was thinking in adding a -e 'code' to Build-Pkg to inject after reading and before buidling, what do you think? 02:13 < rxr> if you do not need the cross builds right now better let that work be delegated to me - ... 02:13 < jsaw> rxr: it does even fail on non-crossbuilds... 02:13 < rxr> jsaw: what do you mean? the current bootdisk issue? 02:14 < jsaw> oh, I misread the text. 02:14 < jsaw> I read 1-gzip for 1-glibc... sorry, me different universe... 02:14 < mnemoc> i got three problems on three different builds 02:14 < mnemoc> bootdisk -> 1-gzip, diet returning 250 02:14 < mnemoc> cross-amd64 -> 1-glibc, segfault on configure detecting suffix 02:15 < mnemoc> cross-g3 -> 1-glibc, linking, undefined symbols 02:15 < jsaw> rxr: then, yes, talking about the return code 250 (1-gzip), which is the cmd_wrapper return code. 02:16 < jsaw> i386-unknown-linux-gnu-gcc -c -DHAVE_UNISTD_H=1 -DVOID_CLOSEDIR=1 -DRETSIGTYPE=int gzip.c 02:16 < jsaw> cmd_wrapper: execvp(diet,...) - Bad address 02:17 < mnemoc> o_O 02:17 < jsaw> EFAULT filename points outside your accessible address space. 02:18 < mnemoc> PATH? 02:18 < jsaw> usually that refers to the variables passed 02:18 < rxr> jsaw: oh - than my arg copy messes memory up .. 02:19 < jsaw> I think so... 02:19 < jsaw> lemma check... 02:20 < mnemoc> oh, now i understand.... too hot here, my brain s fried :\ 02:20 < jsaw> newargv not NULL terminated... 02:21 < jsaw> works 02:21 < jsaw> adding newargv[c1] = NULL right in front of the resp. execvp 02:21 < jsaw> == 12/20/04 02:23:05 =[1]=> Finished building package gzip. 02:22 < mnemoc> =D 02:22 < mnemoc> jsaw: how did you got there? gdb? 02:22 < jsaw> reading the source, luke... :) 02:23 < jsaw> not really. 02:23 < mnemoc> :) 02:23 < jsaw> wait for the commit 02:24 < CIA-9> jsaw * r5149 /trunk/misc/tools-source/cmd_wrapper.c: 02:24 < CIA-9> * use incremental return codes (250...254) so in case of problems it 02:24 < CIA-9> becomes clear where cmd_wrapper fails. 02:24 < CIA-9> * show the error message in case an execvp fails 02:24 < jsaw> ups, my commit message forgot the important part: fix NULL termination of newargv 02:25 < jsaw> but I have to look for other parts which might not have been fixed... 02:26 < jsaw> oh, there's also a memleak. 02:26 < jsaw> (possible memleak I should add...) 02:28 < jsaw> That's nice: 02:28 < jsaw> /* Re-read parameter list. Don't free old stuff, we do an 02:28 < jsaw> exec() anyway ... */ 02:28 < rxr> that is not from me ... 02:29 < mnemoc> :D 02:29 < jsaw> it's okay, but *not nice* (TM) 02:29 < mnemoc> can be evil to free stuff you got allocated from outside? 02:30 < rxr> == 12/20/04 02:29:13 =[1]=> Finished building package gzip. 02:30 < mnemoc> maybe allocated on a function calling execve itself? 02:30 < mnemoc> maybe reused on that function? 02:31 < jsaw> mnemoc: newargv = malloc, and a bit later under different conditions it's again newargv = malloc(... 02:38 -!- rxr_ [~rene@p213.54.192.193.tisdip.tiscali.de] has joined #t2 02:38 -!- Topic for #t2: T2 | 2.1.0-beta RELEASED | The next generation of System Development Enviroments (SDE) | http://www.exactcode.de/t2 02:38 -!- Topic set by mnemoc [] [Sat Dec 18 15:39:34 2004] 02:38 [Users #t2] 02:38 [ _Ragnar_] [ daja77 ] [ jsaw ] [ nullslack] [ rxr ] [ sparc-kly] 02:38 [ CIA-9 ] [ hannes_] [ mnemoc] [ nzg ] [ rxr_] [ valentin ] 02:38 -!- Irssi: #t2: Total of 12 nicks [0 ops, 0 halfops, 0 voices, 12 normal] 02:38 -!- Channel #t2 created Sun Aug 8 21:15:33 2004 02:38 < jsaw> obviouls I hit Ctrl-C after actually everything was build already... 02:38 -!- Irssi: Join to #t2 was synced in 16 secs 02:39 -!- rxr [~rene@p213.54.197.71.tisdip.tiscali.de] has quit [Read error: 104 (Connection reset by peer)] 02:40 < jsaw> Homework problems are generally easier to do if you've: [snip] <- answer to a question on sci.optics *hehe* 02:40 < jsaw> 1) Paid attention in class 02:40 < jsaw> 2) Read the book 02:41 < sparc-kly> anyone need gmail invitation? 02:41 < jsaw> hmmm.... 02:41 < jsaw> hi sparc-kly 02:41 < sparc-kly> hi 02:42 < mnemoc> jsaw: just those two alternatives? 02:42 < jsaw> mnemoc: yes. 02:42 < mnemoc> :) 02:42 -!- sparc-kly [~sparc@64.237.130.173] has left #t2 ["Leaving"] 02:42 -!- sparc-kly [~sparc@64.237.130.173] has joined #t2 02:42 < mnemoc> o_O 02:42 < jsaw> sparc-kly: I'm from the why-not department... :) 02:42 < sparc-kly> 0_D 02:43 < sparc-kly> xchat crash :P 02:43 < rxr_> sparc-kly: my grilfriend also asked for them ... 02:43 * jsaw says: ladies first 02:43 -!- You're now known as rxr 02:44 < sparc-kly> rxr asked for what ? sorry remember my english sucks ;D 02:44 < rxr> I already wondered, how does one get this invitations to offer to other people ... 02:44 < sparc-kly> ahhh ok 02:44 < rxr> sparc-kly: to get an gmail invitation 02:44 < sparc-kly> give me email 02:45 < mnemoc> i think you start with an amount of invitations and you get new ones after success registrations 02:45 < sparc-kly> email and name please :D i send invitation now 02:46 < rxr> sparc-kly: see querry ... 02:47 < rxr> query even ... 02:47 < sparc-kly> ready i send one 02:47 < rxr> mnemoc: I have not seen any invitations in my account yet ... 02:47 < sparc-kly> :D 02:47 < rxr> sparc-kly: you got the text in the query ... 02:47 < rxr> ah - cool - thanks ,-) 02:48 < sparc-kly> i put rxr request . enjoy :P 02:48 < rxr> sparc-kly: how does one get invitations ? 02:49 < sparc-kly> wait long time 02:49 < sparc-kly> hehehehe 02:49 < mnemoc> rxr: like orkut, god has a pool of inivitations 02:49 < sparc-kly> i receive 10 today . 02:49 < mnemoc> he invites the people he knows 02:50 < mnemoc> and the tree starts to get expanded 02:52 < sparc-kly> t2 beta support distcc? 02:53 < jsaw> sadly not yet. but not to long a way to go... :) 02:53 < jsaw> s/to/too/ 02:53 -!- nullslack [~nullslack@203.131.109.114] has quit ["Leaving"] 02:57 < rxr> oh - indeed 6 gmail invites are at my account 02:57 < rxr> I logged in for the third time today .. 02:57 < sparc-kly> :P 02:57 < rxr> they are on the button left corner - I thought I would some mail telling me I have those .... 02:57 < rxr> sparc-kly: if you have someone I should invite for the one you sent to my girlfiend, just tell me ;-) 02:57 < rxr> jsaw: mnemoc: invites anyone? 02:58 < jsaw> yep! 02:58 < rxr> to your usual address? 02:58 < sparc-kly> gmail contest 02:58 < sparc-kly> :D 02:59 < jsaw> rxr: -> query 02:59 < mnemoc> rxr: i have many, tell me names and mail addresses and i send 02:59 < sparc-kly> i have 9 invitation 03:00 < rxr> mnemoc: you have many invites ? 03:01 < mnemoc> 8 03:01 < rxr> ic ... 03:01 < mnemoc> tell me names and i invite them 03:01 < sparc-kly> i win LOL 03:01 < mnemoc> yes :) 03:02 < rxr> just invited valentin and my brother myself .. 03:02 * rxr back hacking 03:03 < mnemoc> and susan? 03:03 < mnemoc> not invited? :) 03:03 < rxr> sparc-kly already invited her ... 03:03 < rxr> since I did not know I have invites ... 03:03 < mnemoc> =) 03:06 < mnemoc> btw, mnemoc@gmail.com 03:07 < rxr> rene.rebe_at_gmail.com 03:07 < sparc-kly> mubex@mubex.net MMmmMMmmmMMm :D 03:07 < mnemoc> gmail suppose to have a great spam filter :) 03:07 < rxr> I had one spam in my unused account ... 03:08 < mnemoc> Rébe or Rèbe ? 03:08 < rxr> ? 03:08 < mnemoc> the acent 03:08 < jsaw> s/b/n/ 03:09 < mnemoc> Réne Rebe ? 03:09 < mnemoc> no accent? 03:09 < mnemoc> i was convinced it has 03:09 < rxr> no - they are not allowed in mail addresses AFAIK 03:09 < mnemoc> but on your name yes :) 03:10 < jsaw> mnemoc: the accent is right, but it's on the last e on the first name... 03:10 < mnemoc> René Rebe :) 03:11 < jsaw> :) 03:11 < mnemoc> when you s/b/n/ i got confused 03:12 < jsaw> I'm also seduced to write René Rébe (due to verbalisation process in my mind) 03:12 < mnemoc> .oO( tooo hot.... my nouse is bleeding )o 03:13 < jsaw> mnemoc: you can send me a few Kelvin... 03:14 < mnemoc> i have 29C (23:13), do you want those.... 9 degrees? 03:14 < jsaw> actually I'd prefer 29K ... 03:15 < mnemoc> i'm not scientist, i use Cs :) 03:15 < jsaw> oh. K only because we're talking about temperature difference... 03:16 < mnemoc> ic 03:17 < jsaw> It's something like -1 to -3C here... 03:18 < mnemoc> he have that 1 or 2 times per year 03:18 < mnemoc> we* 03:18 < jsaw> *grummel* 03:18 < mnemoc> that's why we don't have heating systems 03:19 * jsaw prepares quantum teleportation experiment for a few million atoms 03:19 < mnemoc> :) 03:21 < jsaw> rxr: apropos glib/gtk 2.6, probably we should give a hint about the filename handling somewhere... 03:21 < jsaw> The assumption of GLib and GTK+ by default is that filenames on the 03:21 < jsaw> filesystem are encoded in UTF-8 rather than the encoding of the locale; 03:40 < rxr> jsaw: isn't that the case for some time now already? 03:40 < rxr> I always got complains about some non utf-8 files in my home directory from gtk+2 stuff .. 03:40 * rxr rebooting - osx USB subsystem screwed (as so often) 03:41 < jsaw> the announcement sounds different... 04:04 < rxr> re 04:05 < rxr> here I always got Warnings to stderr for those apps ... 04:05 < jsaw> ok. 04:07 < rxr> when do you commit the 16 upadate ? 04:07 * rxr rebooting again ... 04:10 < jsaw> while the 1-gzip is fixed I noticed, that diet uses still files from the host system. 04:11 < jsaw> and diet itself doesn't run cmd_wrapper... 04:13 < mnemoc> isn't DIETHOME set? 04:13 < jsaw> nope. 04:14 < jsaw> but the other problem is: the REMOVE/INSERT/APPEND stuff doesn't operate on the options diet generates... 04:14 < mnemoc> at least on ./debug.sh diet calls wrapper 04:15 < jsaw> really? 04:15 < jsaw> I tried to remove -lgcc, nothing... 04:15 < mnemoc> when i did the tests, diet i386-...-gcc blah.c got re-wrapped with dbug output etc 04:16 < mnemoc> REMOVE doens't remove INSERTed stuff btw 04:16 < jsaw> I want to remove -lgcc which is inserted by diet. 04:16 < mnemoc> it should work 04:17 < jsaw> how is cmd_wrapper called, thru exec sys call? 04:18 < mnemoc> cmd_wrapper is on patch 04:18 < mnemoc> path* 04:18 < mnemoc> if foo-gcc is called, wrapped is execed 04:19 < mnemoc> i wanted to add -e option to build-Pkg do help debug doing stuff like ./scripts/Build-Pkg -job 1-glibc -e "export GCC_WRAPPER_DEBUG=1" 04:20 < mnemoc> injected after post.conf files 04:20 < jsaw> at what point is cmd_wrapper invoked (I mean how)? 04:22 < mnemoc> every time, the first item of PATH is the path to a bunch of scripts which call the wrapper for the binary they are replacing 04:23 < mnemoc> if you use absolute path the wrapper is not called 04:23 < jsaw> the first path is the direct path to the diet binary itself... 04:24 < mnemoc> yes, but diet calls a wrapped gcc 04:25 < jsaw> according to my log, no 04:25 < mnemoc> diet gcc foo.c 04:25 < mnemoc> gcc is found on PATH on it's wrapped form 04:26 < jsaw> then I should see the debug info twice for the same source file... 04:26 < jsaw> but that's not there 04:26 < rxr> damn - still not rebooted . 04:27 < rxr> damn overworked ... 04:27 < mnemoc> uhm 04:28 < jsaw> hmm. maybe I should take a nap before having a second look. It worked with the 1-gzip thing... 04:30 < mnemoc> :) 04:30 < mnemoc> rxr: you are 4:30 hours late to your sleepline 04:31 < rxr> sleepline? what is that? 04:32 < jsaw> that's a horizontal line, actually a flat. mostly covered with soft fabric... 04:33 < mnemoc> rxr: deadline to sleep :) 04:33 * mnemoc wants to sleep too :) 04:39 < jsaw> gaah 04:39 < jsaw> Old Path: ...:...TOOLCHAIN/toosl.cross/wrapper:... 04:39 < jsaw> New Path: *no wrapper directory* 04:40 < jsaw> cmd_wrapper.c: 04:40 < jsaw> /* 04:40 < jsaw> * Remove the wrapper dir from PATH 04:40 < jsaw> */ 04:42 < rxr> well - I rearanged that code fragment 04:42 < rxr> because of this scenario: 04:42 < rxr> gcc 04:42 < rxr> wrapped to ccache 04:43 < rxr> executes gcc 04:43 < rxr> wraper again ... 04:43 < rxr> let me think a second why this did not happen perviously ... 04:43 < jsaw> but then diet calls gcc directly, not via the wrapper. 04:44 < rxr> why does it call it directly ? 04:45 < jsaw> because crosscc is in the path, and there is the real gcc binary 04:45 < jsaw> but it should call it via wrapper/*gcc, so that cmd_wrapper gets executed 04:46 < rxr> maybe revert my cmd_wrapper change and see how the path of execution runs ... 04:47 < jsaw> different fix, set NOLOOP and remove /wrapper/ after others are called... 04:55 < mnemoc> what about cleaning the env to keep the append, insert and remove but not the adds? 04:56 < mnemoc> others i mean 04:56 < rxr> jsaw: e16 update? 04:57 < rxr> currently I'm in linux - and would like to test it in parallel 04:57 < jsaw> the loop stems from the fact that wrapper/i586-unknown-linux-gnu-gcc re-sets the WRAPPER_* variables..., so removing sth. from WRAPPER_OTHERS doesn't work 04:58 < jsaw> rxr: just committed - but untested... 04:58 < CIA-9> jsaw * r5151 /trunk/package/e16/enlightenment16/enlightenment16.desc: * update e16 (DR16.7.1 -> DR16.7.2) 04:58 < mnemoc> and using another envvar to show it is a nested wrapping? 04:59 < mnemoc> and ignore wrapper_others in that casE? 04:59 < jsaw> we could recored previous wrappers in NOLOOP and remove the from OTHERS 04:59 < jsaw> record 04:59 < rxr> sounds good 04:59 < mnemoc> oh, i didn't read the NOLOOP part 05:04 < rxr> e16 gives 404 here 05:04 < jsaw> strange, I got 404 from the dl.sf.net/sourceforge/enli... path 05:04 < jsaw> the loadbalancing seems to be screwed... different path on different servers... 05:04 < rxr> hm 05:05 < rxr> or just not yet on all servers ... 05:05 < jsaw> maybe... 05:07 < mnemoc> i think it's the natural delay syncing servers 05:10 < rxr> yep 05:12 < jsaw> why is this line in wrapper/*gcc: 05:12 < jsaw> export CMD_WRAPPER_OTHERS="$CC_WRAPPER_OTHERS:$GCC_WRAPPER_OTHERS:$GCC3_WRAPPER_OTHERS" 05:13 < jsaw> oh, ic 05:16 < mnemoc> you can keep NOLOOP as sed expressions to do the filtering faster 05:17 < mnemoc> something like: export CMD_WRAPPER_OTHERS="( echo "$CC_WRAPPER_OTHERS:$GCC_WRAPPER_OTHERS:$GCC3_WRAPPER_OTHERS" | sed $NOLOOP )" 05:20 < rxr> a sed call per wrapper execution is unacceptable ... 05:21 < jsaw> no, trying to do this inside cmd_wrapper.c 05:21 < mnemoc> bash looping is even worse 05:21 < mnemoc> ok 05:22 < mnemoc> i'll better go to sleep, the hot air have me telling crap 05:22 < mnemoc> gn8 all :) 05:22 < mnemoc> good luck ;) 05:22 < jsaw> gn8 mnemoc 05:38 < rxr> n8 mnemoc 06:06 -!- hannes_ [ucbiv@rzstud3.stud.uni-karlsruhe.de] has quit [Remote closed the connection] 06:14 < jsaw> I also have to sleep, cu! 06:46 < rxr> now I can fully understand the motivation to program s.th. like the flying toasters screensaver .. 06:46 < rxr> I should do one with scanners ... 06:46 < rxr> flying out of windows ... 06:46 < rxr> grummeling 08:09 -!- mipe [~mipe@dsl10040.japo.fi] has joined #t2 08:24 < rxr> hi mipe 08:27 < mipe> hi rxr 08:28 < mipe> hmm... scripts/download -cfg system -required doesnt download any packages on fresh system. it just tested the mirrors and chose one but doesnt start to download 08:29 < rxr> hm 08:29 < rxr> did you run ./scripts/Config ? 08:29 < mipe> yeah 08:40 < mipe> no wonder it doesnt download ./scripts/Config --> show package list is empty 08:41 < rxr> ouhm 08:41 < rxr> sorry I'm programming right now ... :-( 08:42 < mipe> solved by installing gawk :) 08:44 < rxr> hehe 08:44 < rxr> I should add a check for that 08:46 < mipe> getting more errors on download script.... it gets html document text and complains about the file type doesnt match filename error 08:47 < mipe> and thats because it doesnt download the file but the file listing on mirror 08:49 < rxr> yes, I saw such stuff, too 08:49 < rxr> need to verify this soon - no idea yet why this happens now ... 08:51 < mipe> http://gsmp.tfh-berlin.de/mirror/t2-source/2.1/ 08:51 < mipe> thats the mirror i'm using. is there a way to force another mirror in use. just to check if its just that 08:51 < rxr> echo "none" > download/Mirror 08:52 < mipe> now it downloads 08:53 -!- nullslack [~nullslack@203.131.109.114] has joined #t2 08:53 < mipe> back later. gotta go to see dentist. ouch 08:54 < rxr> ouh - much luck 09:50 < nullslack> ping rxr 09:54 < rxr> dong nullslack ;-) 09:58 < nullslack> i have a partition for installing my build already...question is how can i install the bootloader on the root partition? 09:59 < nullslack> i was looking for liloconfig, but... 10:29 < rxr> re 10:29 < rxr> well you mean the MBR I think? 10:29 < rxr> I would just use your current systems lilo config and add an entry with your new partition 10:30 < nullslack> nope...the first sector of the root partition, i have a bootloader installed already at MBR 10:31 < nullslack> hmmm...brb 10:31 -!- nullslack [~nullslack@203.131.109.114] has quit ["Leaving"] 10:32 -!- mipe [~mipe@dsl10040.japo.fi] has quit ["brb"] 10:35 -!- mipe [~mipe@dsl10040.japo.fi] has joined #t2 11:10 < rxr> so 11:10 < rxr> soon in bed .. 12:20 < mipe> anyone awake who can help me on errors i get on Build-Target 12:20 < mipe> ./scripts/Build-Target -cfg system 12:20 < mipe> mkdir: dl-close.c:134: _dl_close: Assertion `map->l_direct_opencount > 0' failed. 12:24 -!- mipe [~mipe@dsl10040.japo.fi] has quit ["bbl"] 13:54 -!- Minto [~chatzilla@82-217-66-7.cable.quicknet.nl] has joined #t2 14:44 < mnemoc> moin! 14:44 < sparc-kly> moin all 14:44 < sparc-kly> :P 14:46 < mnemoc> moin sparc-kly 15:13 < jsaw> g'morning 15:15 < mnemoc> moin jsaw 15:15 < mnemoc> jsaw: does your patch solve the problem with diet and -lgcc ? 15:22 < jsaw> hi mnemoc 15:22 < jsaw> yes, besides a small change (where I fogot to export ...OTHERS_DONE). 15:22 < mnemoc> it looks ok, but works? 15:22 < mnemoc> ic 15:23 < jsaw> == 12/20/04 15:19:29 =[1]=> Finished building package linux24. 15:23 < jsaw> <- bootdisk 15:24 < jsaw> in 1-gzip: 15:24 < jsaw> first invocation: 15:24 < jsaw> Old Command: i386-unknown-linux-gnu-gcc -c -DASMV -DSTDC_HEADERS=1 -DHAVE_UNISTD 15:24 < jsaw> _H=1 -DDIRENT=1 -O gzip.c 15:24 < jsaw> ENVPREFIX = 'CMD' 15:24 < jsaw> OTHERS = 'diet:ccache' 15:24 < jsaw> INSERT = '-Os -pipe' 15:24 < jsaw> Old Command: i386-unknown-linux-gnu-gcc -include /scratch/src/t2/build/boot-2.1. 15:24 < jsaw> 0-beta2-x86-bootdisk-expert/usr/dietlibc/include/dietref.h -Os -pipe -c -DASMV - 15:24 < jsaw> DSTDC_HEADERS=1 -DHAVE_UNISTD_H=1 -DDIRENT=1 gzip.c -s -isystem /scratch/src/t2/ 15:24 < jsaw> build/boot-2.1.0-beta2-x86-bootdisk-expert/usr/dietlibc/include -D__dietlibc__ 15:24 < jsaw> ENVPREFIX = 'CMD' 15:24 < jsaw> OTHERS = 'diet:ccache' 15:24 < jsaw> OTHERS DONE = 'diet' 15:24 < jsaw> <- second 15:24 < jsaw> third: 15:24 < jsaw> Old Command: i386-unknown-linux-gnu-gcc -Os -pipe -include /scratch/src/t2/build 15:24 < jsaw> /boot-2.1.0-beta2-x86-bootdisk-expert/usr/dietlibc/include/dietref.h -pipe -c -D 15:24 < jsaw> ASMV -DSTDC_HEADERS=1 -DHAVE_UNISTD_H=1 -DDIRENT=1 -s -isystem /scratch/src/t2/b 15:24 < jsaw> uild/boot-2.1.0-beta2-x86-bootdisk-expert/usr/dietlibc/include -D__dietlibc__ -s 15:24 < jsaw> -E gzip.c 15:24 < jsaw> ENVPREFIX = 'CMD' 15:25 < jsaw> OTHERS = 'diet:ccache' 15:25 < jsaw> OTHERS DONE = 'diet:ccache' 15:25 < jsaw> and the fourth one is then actually doing the job 15:25 < jsaw> only problem: 15:26 < jsaw> APPEND/INSERT are append/inserted multiple times. 15:26 < mnemoc> any reason to APPEND/INSERT after the first round? 15:27 < jsaw> it's far from being a good solution. It just follows rxr's motto: "I just want to get it working as fast as possible" ... 15:27 < mnemoc> uhm... remove -O* insert -Os .... uhm... 15:28 < mnemoc> they have to be applied on every round :( 15:28 < jsaw> why? 15:29 < mnemoc> you need to REMOVE to remove -lgcc 15:29 < jsaw> but why do they "have to" be applied on every round? I think the last one is enough. 15:29 < mnemoc> if -O* were removed on first round and -Os inserted, -Os will get removed on the second round 15:30 < mnemoc> can you know the 'last' for sure? 15:30 < jsaw> oh. you meant "they are appplied" 15:32 < jsaw> mnemoc: I don't see a reason currently why the 'last' could eventually not be the last... ? 15:33 < mnemoc> can an OTHER not really execute the requested gcc? 15:37 < mnemoc> if you know every OTHER will really execute the whole chain, OTHERS==OTHERS_DONE is the last. 15:37 < jsaw> yes. 15:38 < jsaw> I should try "diet ccache distcc ...." 15:39 < jsaw> starts thinking, that a wrapper for diet, ccache and distcc would make much more sense... 15:39 < jsaw> s/^/me / 16:07 < mnemoc> jsaw: what have you desided? 16:18 < jsaw> that removing -lgcc does not work. I found a package (tar), that needs some symbols which are still hidden in libgcc... 16:19 < jsaw> I have to think about it... 16:19 < jsaw> (n*24h *g*) 16:19 < mnemoc> :) 16:20 < jsaw> looks like, using -fstack-protector must be forced on dietlibc... 16:20 < jsaw> if gcc is SSP patched... 16:25 < mnemoc> here gcc is always SSP patched 16:32 < jsaw> that's the point... 16:37 < mnemoc> so, you propose to make SSP patching only when SSP is choosen to be used, and in that case -fstack-protector dietlibc as expected? 16:37 < jsaw> actually I'd prefer creating a libgcc-nossp 16:38 < mnemoc> how that? 16:38 < jsaw> ... that is the question here. 16:44 < mnemoc> libgcc itself is a pain, duplicate it to have one unpatched, ufff... 16:51 < jsaw> actually I wonder why libgcc contains these symbols if no -fstack-protector is used :/ 16:51 < mnemoc> i think fixing that bug may be cleaner 16:51 < mnemoc> and easier 16:52 < mnemoc> OT: does init's btee work to you with SSP? 16:53 < jsaw> no idea... didn't ever try nor do I have sth. compiled with ssp currently 16:54 < mnemoc> ic 16:55 < mnemoc> here btee feels attacked by fsck :) 17:09 -!- mipe [~mipe@dsl10040.japo.fi] has joined #t2 17:15 < mipe> hi 17:17 < mnemoc> hi mipe 17:17 < mipe> i'm getting some build errors right after Build-Target call, wanna help? :) 17:18 < mnemoc> trunk:HEAD or other? 17:18 < mipe> trunk:HEAD 17:18 < mipe> trying to do amd64 build 17:20 < mnemoc> native? 17:21 < mipe> yes,prepare for spam :) 17:21 < mipe> mkdir: dl-close.c:134: _dl_close: Assertion `map->l_direct_opencount > 0' failed. 17:21 < mipe> ./scripts/Build-Pkg: line 260: 2924 Aborted mkdir -p $root/var/adm/flists 17:21 < mipe> mkdir: dl-close.c:134: _dl_close: Assertion `map->l_direct_opencount > 0' failed. 17:21 < mipe> ./scripts/Build-Pkg: line 261: 2925 Aborted mkdir -p $root/var/adm/cksums 17:21 < mipe> mkdir: dl-close.c:134: _dl_close: Assertion `map->l_direct_opencount > 0' failed. 17:21 < mipe> ./scripts/Build-Pkg: line 262: 2926 Aborted mkdir -p $root/var/adm/md5sums 17:21 < mipe> mkdir: dl-close.c:134: _dl_close: Assertion `map->l_direct_opencount > 0' failed. 17:21 < mipe> ./scripts/Build-Pkg: line 263: 2927 Aborted mkdir -p $root/var/adm/packages 17:21 < mipe> mkdir: dl-close.c:134: _dl_close: Assertion `map->l_direct_opencount > 0' failed. 17:21 < mipe> ./scripts/Build-Pkg: line 264: 2928 Aborted mkdir -p $root/var/adm/dependencies 17:21 < mipe> mkdir: dl-close.c:134: _dl_close: Assertion `map->l_direct_opencount > 0' failed. 17:21 < mipe> sorry for the spam :) 17:22 < mipe> thats what i get right after Build-Target call 17:25 < mnemoc> oh 17:26 < mnemoc> what are you running on that amd64? 17:27 < mipe> arch, but not the official one. rebuilt by friend of mine 17:27 -!- Minto [~chatzilla@82-217-66-7.cable.quicknet.nl] has quit [Read error: 110 (Connection timed out)] 17:29 < mnemoc> mkdir -p /home/foo/bar/blah/blah/blah ? 17:30 < mipe> works 17:32 < mnemoc> it should be something with fl_wrapper then 17:33 * mipe afk(bbl) 17:33 < mnemoc> me too 17:33 * mnemoc lunch 17:46 < rxr> ,pom 17:49 < rxr> hm - what have I typed there ... 17:49 < rxr> I meant moin ;-) 17:53 -!- sparc-kly [~sparc@64.237.130.173] has quit ["Leaving"] 18:23 < rxr> so - Download fixed ... 18:23 < CIA-9> rene * r5152 /trunk/scripts/Download: 18:23 < CIA-9> * fixed my Dowwnload adaptions to really parse the Mirror file and 18:23 < CIA-9> not try to download from a URL $mirror $mirrorver/$file ;-) 18:37 < mnemoc> a shifted moin :) 18:38 < mnemoc> rxr: did you saw that $cracp mipe gets running on amd64? 18:39 < mnemoc> rxr: did you finished your driver on time? 18:39 < rxr> well - this will become another long night ... 18:39 < mnemoc> :\ 18:40 < mnemoc> when is your deadline? yestarday? 18:40 < rxr> yes 18:40 < mnemoc> :( 18:41 < mnemoc> brb 18:49 < rxr> hm - I have a http URL that I can download with wget - but not with curl 18:49 < rxr> curl get's a 403 ... 18:53 -!- Minto [~chatzilla@82-217-66-7.cable.quicknet.nl] has joined #t2 18:54 < Minto> moin all 18:58 < rxr> oehm, people? 18:58 < rxr> the DVDRip site does reject curl with 403 ... 18:58 < rxr> using curl -A "Test" does make it work ... 19:17 < CIA-9> rene * r5153 /trunk/scripts/Download: 19:17 < CIA-9> * improved scripts/Download to set the user-agent to T2-downloader 19:17 < CIA-9> since some sites (e.g. the dvdrip server) do not like the -unknown- 19:17 < CIA-9> often present in the default curl identification: 19:17 < CIA-9> (curl/7.12.1_(i586-unknown-linux-gnu)_libcurl/7.12.1_OpenSSL/0.9.7d_zlib/1.2.1) 19:42 -!- Minto_ [~chatzilla@82-217-66-7.cable.quicknet.nl] has joined #t2 19:42 -!- Minto [~chatzilla@82-217-66-7.cable.quicknet.nl] has quit ["ChatZilla 0.9.61 [Mozilla rv:1.7.3/20040910]"] 19:42 -!- Minto_ is now known as Minto 19:43 -!- Minto [~chatzilla@82-217-66-7.cable.quicknet.nl] has quit [Client Quit] 19:44 -!- Minto [~chatzilla@82-217-66-7.cable.quicknet.nl] has joined #t2 20:53 < mnemoc> re 20:59 -!- mipe [~mipe@dsl10040.japo.fi] has quit ["bye"] 21:44 < rxr> re 21:44 < rxr> hi mnemoc 21:46 < mnemoc> hi rxr 21:46 < mnemoc> open("/opt/*/lib/libpango-1.0.so.0", O_RDONLY) = -1 ENOENT (No such file or directory) <--- hate 21:47 < rxr> ? 21:48 < mnemoc> strace -vv ld .... 21:48 < mnemoc> why is it using the '*' :\ 21:48 < rxr> no idea ... 21:48 < rxr> where do you get this ? 21:49 < mnemoc> inside clip 21:56 < rxr> ouhm 21:57 < mnemoc> -rpath= worked, but now i need clip to call ld with it 22:03 < mnemoc> LD_RUN_PATH=${LD_RUN_PATH} clip -es $@.prg -lclip-gtk2 <--- there is any nicer way to export form Makefile ? 22:11 < rxr> ? 22:14 < mnemoc> on a Makefile 22:14 < mnemoc> LD_RUN_PATH=/opt/gnome24/lig 22:14 < mnemoc> all: 22:14 < mnemoc> clip -es $@.prg -lclip-gtk2 22:14 -!- Minto [~chatzilla@82-217-66-7.cable.quicknet.nl] has quit [Read error: 110 (Connection timed out)] 22:14 < mnemoc> s/all:/foo: foo.prg/ 22:15 < mnemoc> that doesn't work 22:15 < mnemoc> but LD_RUN_PATH=${LD_RUN_PATH} clip -es $@.prg -lclip-gtk2 does 22:15 < mnemoc> it's terrible ugly 22:18 < rxr> mnemoc: I think there might bee an underlying problem in the way s.th. is build - and I do not know what clip does exactly ... 22:19 < rxr> some update work ... 22:19 < CIA-9> rene * r5154 /trunk/package/www/mozilla/mozilla.desc: * updated mozilla (1.7.3 -> 1.7.5) 22:20 < mnemoc> rxr: clip compiles .prg into .c and calls ld after that 22:20 < mnemoc> gcc and ld* 22:20 < rxr> ah 22:20 < CIA-9> rene * r5155 /trunk/package/gnome2/ (glib/glib.desc gtk+/gtk+.desc pango/pango.desc): 22:20 < CIA-9> * updated glib (2.4.8 -> 2.6.0) 22:20 < CIA-9> * updated gtk+ (2.4.14 -> 2.6.0) 22:20 < CIA-9> * updated pango (1.6.0 -> 1.8.0) 22:20 < mnemoc> according to strace ld is not expanding stuff on ld.so.conf 22:20 < rxr> yes 22:21 < mnemoc> open("/opt/*/lib/libpango-1.0.so.0", O_RDONLY) = -1 ENOENT (No such file or directory) <-- probe 22:21 < rxr> we had this problem before - it is nice that you see it that cleanly in your log 22:21 < rxr> I think we should fix this in ld - we already patch glibc's ld-config to glob the /etc/ld.so.conf entries .. 22:21 < rxr> when I had this problem I did not saw it that clearly in the logs ... - otherwise I would have fixed it at that time .. 22:22 < mnemoc> strace is a great friend :) 22:22 < rxr> maybe take a look if the rock people did s.th. regarding this problem 22:22 * rxr knows .. 22:22 * rxr might have been to sleepy in that night when I tracked it .. 22:23 < CIA-9> rene * r5156 /trunk/package/multimedia/dvdrip/dvdrip.desc: * updated dvdrip (0.50.16 -> 0.50.18) 22:24 < mnemoc> rxr: fake had no answer, so the problem is not fixed there :) 22:24 < rxr> well - this is so obvious ... 22:25 < rxr> when we patch ld-config to glob /etc/ld.so.conf obviously the linker needs this, too 22:25 < rxr> maybe I look into it as exercise this night 22:25 < rxr> my eyes needs something else than scanner bits to relax ... 22:26 < mnemoc> yep 22:26 < rxr> (especially when those unlucky devices freeze so easily ..) 22:26 < rxr> I have so many scanners - non where as touchy as the current top models ... 22:26 < rxr> one bit they did not expect and *boom* 22:27 < mnemoc> very robust scanners :\ 22:27 < rxr> yeah - but on the other side one recent model is rock solid, too 22:28 < rxr> valentin even crashed our macosx frontend during the initialization phase and it just worked thereafter .. 22:28 < mnemoc> dark ages on the middle? 22:28 < rxr> yeah - s.th. like that ... 22:28 < rxr> I can even freeze on of them by: 22:28 < rxr> lsusb 22:28 < rxr> lsusb 22:28 < rxr> lsusb 22:28 < rxr> replug 22:28 < rxr> lsusb 22:28 < rxr> lsusb 22:28 < rxr> hack 22:28 < rxr> hang even 22:29 < mnemoc> hang quering?? 22:29 < rxr> annoyingly enough it works under windows ... 22:29 < rxr> yep - usb port froozen after that ... 22:29 < rxr> same in linux _and_ macosx ... 22:29 < mnemoc> oh 22:29 < mnemoc> that's obviusly a kernel bug 22:30 < rxr> well - if there is a bug in the usb subsystem in linux _and_ osx (well - I somehow doubt this but, ...) in linux I have a chance to fix it ... 22:30 < rxr> I have no idea how to deal with that under osx ... 22:30 < rxr> aside calling apple ... 22:30 < mnemoc> does it hangs on bsd? 22:31 < rxr> I have no BSD ... 22:31 < rxr> but I install Windows this night here ... 22:31 < rxr> have to rip a HD out of my RAID 5 array before ... 22:31 < rxr> it is quite annoying to carry a scanner once a week over to susan just to do some usbsnooping there ... 22:32 < rxr> my arms usually are quite puffed out after the travel with a scanner companion in the public transport system ... 22:32 < mnemoc> sit or stand? 22:32 < rxr> and I fear one day the scanner got enough shocks from the way to stop working ... 22:32 < rxr> well - depends which way ... 22:32 < rxr> + some walk on both ends ... 22:33 < rxr> our commercial osx thing is at revision 60 ,-) *g* 22:33 < mnemoc> :) 22:33 < rxr> so /me leaving osx in favour to do some kword-ing, maybe linker hacking and more scanner i/o obervations on the OS where I can look what the kernel is doing ... 22:33 < rxr> mom 22:39 < rxr> so 22:43 < mnemoc> hi, Makefile OT question :-) there is any better way to export an envvar on a Makefile than this: LD_RUN_PATH=${LD_RUN_PATH} clip -es $@.prg -lclip-gtk2 ? 22:44 < rxr> our www. access is still on a quite nice level 22:44 < mnemoc> err 22:44 < mnemoc> sorry 22:46 < rxr> mnemoc: isn't it enought to run the whole Makefile with this ? 22:47 < mnemoc> FOO=bah make all <--- works 22:48 < mnemoc> make all FOO=bah <--- works 22:48 < mnemoc> but 22:48 < mnemoc> FOO=bah 22:48 < mnemoc> foo: foo.prg 22:48 < mnemoc> clip .... <--- doesn't work 22:48 < mnemoc> FOO=${FOO} clip ... <--- works 22:54 < rxr> The Linux binutils 2.15.94.0.2 is released 22:55 < rxr> should I commit it? 22:55 < mnemoc> HEAD is not stable enought to try to get a release soon, so i see no problem updating binutils :) 22:56 < rxr> we should get HEAD into good shape soon ... 22:56 < mnemoc> cmd_wrapper changes seem the have broken it :\ 22:57 < rxr> yeah - it is my fault .. 22:57 < mnemoc> it was necesary :) 22:57 < mnemoc> but i need you back :p 22:58 < mnemoc> but you need to eat too 22:59 < rxr> curl and libcurl 7.12.3 23:02 -!- maddin [~martin@pD9E738AA.dip.t-dialin.net] has joined #t2 23:03 < maddin> hi 23:03 < mnemoc> hi new-martin 23:04 < maddin> he he, better than _martin__ or __martin_ or so ... 23:05 < mnemoc> __martin, protected martin :) 23:06 < rxr> hi maddin 23:07 < maddin> Aehm, I don't understand. mnemoc 23:07 < maddin> hi rxr! 23:07 < mnemoc> protected: 23:07 < mnemoc> martin * __martin; 23:07 < rxr> jsaw: are you awake ? 23:08 < jsaw> (more ore less) 23:08 < jsaw> -e 23:09 < rxr> I just review the cmd-wrapper.diff ... 23:10 < rxr> I just wanted to know if you around to apply it soon ... 23:10 < jsaw> I am around. 23:11 < jsaw> there's one setenv(..._OTHERS_DONE,...) missing... 23:11 < rxr> #t, the night shift; nightturn channel ... 23:11 < rxr> ^-2 23:12 < jsaw> rxr: have a look at protectonly.dif <- that seems to be the solution to my dietlibc problems 23:12 < jsaw> this patch must be applied if STACK_PRO=0 23:12 < maddin> hmmm mnemoc, I'm confused, but I will go sleep now. 23:12 < jsaw> (probably) 23:12 < jsaw> hi maddin 23:12 < mnemoc> maddin: :) 23:13 < jsaw> hi mnemoc 23:13 < maddin> hi jsaw 23:13 < rxr> n8 maddin 23:13 < mnemoc> hi jsaw 23:13 < mnemoc> jsaw: what about diet, distcc and ccache wrappers? 23:14 < rxr> with the wrapper we have the problem that ccache and distcc will not work when both are enabled ... 23:14 < maddin> rxr, Wednesday is Christmas party. Free Gluehwein ;) 23:14 < maddin> gn8 all 23:14 < jsaw> that's way more work... but definitely the cleaner solution. 23:14 < rxr> maddin: ic ... - thanks 23:14 < jsaw> rxr: why? 23:14 < jsaw> diet + ccache works 23:15 < rxr> well - distcc will insert distcc: 23:15 < rxr> distcc gcc vb 23:15 -!- maddin [~martin@pD9E738AA.dip.t-dialin.net] has quit ["sleep"] 23:15 < rxr> then ccache insert itself: 23:15 < rxr> ccache distcc gcc vb 23:15 < rxr> I do not think ccache does like "distcc gcc" as first two(!) arguments 23:16 * daja77 wants a I hate gnome banner 23:16 < rxr> ? 23:18 < daja77> obscure build error here 23:18 < rxr> wrong distribution I guess ;-)# 23:19 < rxr> -> Compiler Cache Hits while pkg build: 100.00% (139 hits, 0 misses) 23:19 < rxr> == 12/20/04 23:10:45 =[9]=> Finished building package openh323. 23:19 < jsaw> :) 23:19 < jsaw> hi daja77 23:19 < rxr> seems ccache does work now ... ;-) 23:19 < jsaw> daja77: what's the problem? 23:19 < rxr> yeah - hi daja77 ;-) 23:19 < daja77> rxr: not really as it only happens on my machine 23:19 < daja77> failed to load "./stock_attach.png": Couldn't recognize the image file format for file './stock_attach.png' 23:19 < daja77> make[4]: *** [gnome-stock-pixbufs.h] Error 1 23:20 < daja77> on libgnomeui build 23:20 < jsaw> ??? 23:20 < daja77> i could paste you more if you like 23:21 < rxr> some basic lib or so build without png support ? 23:21 < rxr> on gentoo one would say set "use png" and rebuild 23:22 < rxr> ... 23:22 < daja77> pbg lib is there 23:22 < jsaw> check if libpixbufloader-png.so exits 23:23 < jsaw> /opt/gnome*/lib/*/*/loaders/ 23:23 -!- mnemoc_ [~amery@200.75.27.22] has joined #t2 23:24 < CIA-9> rene * r5157 /trunk/package/ (4 files in 2 dirs): 23:24 < CIA-9> * updated pwlib (1_6_5 -> 1_8_3) 23:24 < CIA-9> * updated openh323 (1_13_4 -> 1_15_2) 23:24 < daja77> it is there 23:25 < jsaw> o_O 23:26 < daja77> perhaps this is not in ldconfig 23:26 < jsaw> should not be in ldconfig. 23:26 -!- mnemoc [~amery@200.75.27.8] has quit [Operation timed out] 23:26 -!- mnemoc_ is now known as mnemoc 23:26 < jsaw> pixbuf knows (?) where its libs are. 23:26 < daja77> how could i check that 23:29 < rxr> ok - binutils release does not build with gcc-3.4 ... 23:29 < rxr> In file included from ../../bfd/elf32.c:22: 23:29 < rxr> ../../bfd/elfcode.h: In function `bfd_elf32_slurp_symbol_table': 23:29 < rxr> ../../bfd/elfcode.h:1162: error: duplicate case value 23:29 < rxr> ../../bfd/elfcode.h:1159: error: previously used here 23:29 < rxr> if such ab 23:29 < rxr> damn 23:29 < rxr> basic code is broken I do not push it into trunk ... 23:32 < daja77> i found a novell doc, saying try rebuilding gdkpixbuf on this error, did that ... 23:38 < jsaw> :) 23:38 < mnemoc> outch 23:38 < daja77> interesting that gdkpixbuf is no part of the official sources on release 23:39 < jsaw> That's Great (TM) 23:39 < daja77> *cough* 23:40 < daja77> strange that lib is two years old, they just kept it without breaking its api ... 23:43 < jsaw> rxr: http://lists.samba.org/archive/distcc/2004q3/002614.html 23:47 < rxr> interesting 23:51 * mnemoc has lot to learn 23:53 < rxr> mnemoc: university ? 23:54 < rxr> -> Compiler Cache Hits while pkg build: 33.03% (145 hits, 294 misses) 23:55 < mnemoc> nope, gcc,binutils,glibc,ccache,distcc,.... 23:55 < mnemoc> i know what but i need to learn how and why --- Log closed Tue Dec 21 00:00:41 2004