T2 IRC Log: 2004-12-20
This is the log as captured by an IRC bot in the channel. The statements are those of the individual people and might not neccessarily reflect the policy and legal rules as set forth by the T2 SDE Project.
--- 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
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