--- Log opened Mon Feb 06 00:00:34 2006
00:09 < morfoh> gn8
00:10 -!- morfoh [n=morfoh@p54BEFE86.dip.t-dialin.net] has left #t2 []
00:15 < CIA-9> aldas * r15310 /trunk/package/network/neon/ (neon.conf neon.desc): * updated neon (0.24.7 -> 0.25.4)
00:17 < CIA-9> aldas * r15311 /trunk/package/develop/swig/swig.desc: * updated swig (1.3.24 -> 1.3.27)
00:19 < CIA-9> aldas * r15312 /trunk/package/develop/apr/ (apr.conf apr.desc):
00:19 < CIA-9> * updated apr (0.9.7 -> 1.2.2)
00:19 < CIA-9> * deleted conf - not necessary anymore
00:21 < CIA-9> aldas * r15313 /trunk/package/develop/apr-util/ (apr-util.conf apr-util.desc): * updated apr-util (0.9.7 -> 1.2.2)
00:23 < CIA-9> aldas * r15314 /trunk/package/network/apache/ (8 files): * updated apache (2.0.55 -> 2.2.0)
00:27 < mnemoc> rehi
00:27 < mnemoc> .oO( Baldzius doing nasty things in public? )o
00:28 < Baldzius> a? :)
00:28 < Baldzius> i have all permissions :)
00:30 < mnemoc> but it's nasty anyway :)
00:31 < CIA-9> aldas * r15315 /trunk/package/database/postgresql/postgresql.desc: * updated postgresql (8.0.5 -> 8.1.2)
00:34 < CIA-9> aldas * r15316 /trunk/package/database/mysql/ (7 files): * updated mysql (4.1.16 -> 5.0.18)
00:35 * Baldzius still don't understand why it's nasty? :)
00:36 < mnemoc> doing multiple things beyond the edge is nasty
00:39 < Baldzius> hm
00:40 < mnemoc> but, keep going :) i'm not your mother to stop you :)
00:40 < Baldzius> 1. i have all permissions including yours :)
00:40 < Baldzius> 2. everything compiles except mod_mono
00:41 < Baldzius> 3. i have a feeling everything should work either :)
00:41 < mnemoc> :)
00:42 < Baldzius> and my feelings never 've lied before :)
00:45 < CIA-9> aldas * r15317 /trunk/package/ruby/mod_ruby/ (apache22.patch mod_ruby.conf mod_ruby.desc): * added mod_ruby/apache22.patch
00:47 < mnemoc> hehe
00:52 < CIA-9> aldas * r15318 /trunk/package/develop/subversion/ (5 files): * added subversion/libtool-fix.patch - libtool issue
00:54 < Baldzius> !> 4 out of 4 hunks FAILED -- saving rejects to file clip/clic.y.rej
00:54 < Baldzius> !> Due to previous errors, no 5-clip.log file!
00:54 < mnemoc> uhm?
00:54 < Baldzius> clip somehow fails iirc last ref it built
00:55 < mnemoc> both hotfixes failed on all hunks?
00:56 < mnemoc> remove them
00:56 < Baldzius> not sure if both
00:56 < Baldzius> testing
00:58 < Baldzius> hotfix_clip_clic.y.patch fails to apply
00:58 < Baldzius> but package fails
00:59 < Baldzius> !> clip.c:1006: error: 'CLK_TCK' undeclared (first use in this function)
01:00 < mnemoc> uhm
01:04 < mnemoc> $ ./merge.sh 14653
01:04 < mnemoc> == r14653 affected the following files ==
01:04 < mnemoc> package/develop/clip/clip.desc
01:04 < mnemoc> U package/develop/clip/clip.desc
01:04 < mnemoc> == revision 14653 merged (0) ==
01:04 < mnemoc> property 'mnemoc:mergelist' set on 'package/develop/clip'
01:04 < mnemoc> i love my helpers :)
01:07 < Baldzius> :)
01:11 < mnemoc> but the notebook doesn't like to do builds :(
01:11 < mnemoc> $ cat /proc/acpi/thermal_zone/THM/temperature
01:11 < mnemoc> temperature: 74 C
01:11 < mnemoc> temperature: 75 C
01:12 < Baldzius> i guess it's 1/2 of your room temp :)
01:13 < mnemoc> :)
01:13 < _Ragnar_> is mnemoc living in hell? :)
01:13 < Baldzius> damn :)
01:13 < Baldzius> hehehe sorry
01:13 < Baldzius> mistake :)
01:14 < mnemoc> 23°C outside according to weather.com
01:14 < Baldzius> here outside -20 inside 20 :)
01:14 < mnemoc> i like 16-18°C :(
01:15 < mnemoc> for tomorrow it's announced 29°C
01:15 < _Ragnar_> here it's 17
01:15 < _Ragnar_> :)
01:15 < mnemoc> nice :)
01:16 < mnemoc> do you live at heaven?
01:16 < _Ragnar_> *lol*
01:16 < Baldzius> -20 better :)
01:16 < Baldzius> == 02/06/06 00:38:42 =[5]=> Finished building package clip.
01:16 < Baldzius> mnemoc: -- ^^ should i or you? :)
01:17 < mnemoc> i did only: D package/develop/clip/hotfix_clip_clic.y.patch
01:17 < mnemoc> and 1.1.5-25 is building here
01:17 < mnemoc> == 02/05/06 22:20:15 =[9]=> Finished building package clip.
01:18 < Baldzius> hm but you sitting on 2.1?
01:18 < mnemoc> at office i have 2.1 with 1.1.5-25 .... i should have forgot to delete that patch
01:19 < Baldzius> on trunk CLOCKS_PER_SEC should be used instead CLK_TCK
01:19 < mnemoc> i commit svn rm, and you add that hotfix
01:20 < Baldzius> ok
01:20 < Baldzius> how to name it?
01:21 < CIA-9> amery * r15319 /trunk/package/develop/clip/hotfix_clip_clic.y.patch: * removed forgotten patch from clip because it's included upstream
01:21 < mnemoc> Baldzius: linux-2.6.15.patch ? :)
01:22 < Baldzius> no that CLOCKS_* stuff , like hotfix_blablabla.patch ? :)
01:23 < mnemoc> that's not a 'hotfix' imo
01:24 < Baldzius> you name it i'll commit :)
01:24 < mnemoc> what defines CLOCKS_PER_SEC ?
01:24 < Baldzius> i wish i knew :)
01:25 < mnemoc> grep -rn CLOCKS_PER_SEC usr/include
01:26 < Baldzius> This defines CLOCKS_PER_SEC, which is the number of processor clock
01:27 < mnemoc> this?
01:32 < Baldzius> /usr/include/bits/time.h:29: The macro `CLOCKS_PER_SEC' is the number per second of the value
01:32 < Baldzius> /usr/include/bits/time.h:32: The value of CLOCKS_PER_SEC is required to be 1 million on all
01:32 < Baldzius> /usr/include/bits/time.h:34:# define CLOCKS_PER_SEC 1000000l
01:32 < Baldzius> /usr/include/bits/time.h:37:/* Even though CLOCKS_PER_SEC has such a strange value CLK_TCK
01:32 < mnemoc> linux-2.6.15.patch :)
01:32 < Baldzius> hm strange name :)
01:32 < Baldzius> ok
01:33 < mnemoc> it's an API change
01:42 < CIA-9> aldas * r15320 /trunk/package/develop/clip/ (5 files): * added clip/linux-2.6.15.patch
01:47 < CIA-9> aldas * r15321 /trunk/package/develop/php/ (6 files): * updated php (5.0.5 -> 5.1.2)
02:42 -!- sparc-kly [n=G3@64.237.253.75] has quit ["Leaving"]
02:52 -!- sparc-kly [n=G3@64.237.253.75] has joined #t2
03:02 -!- sparc-kly_ [n=G3@64.237.244.94] has joined #t2
03:03 -!- ojh [n=omer@71-36-201-103.eugn.qwest.net] has joined #t2
03:23 -!- sparc-kly [n=G3@64.237.253.75] has quit [Read error: 110 (Connection timed out)]
04:54 -!- ojh [n=omer@71-36-201-103.eugn.qwest.net] has left #t2 []
08:10 -!- Baldzius_ [n=baldzius@85.206.97.85] has joined #t2
08:13 -!- Baldzius [n=baldzius@85.206.98.10] has quit [Read error: 110 (Connection timed out)]
08:18 < mtr_> moin
08:18 -!- mtr_ is now known as mtr
08:25 -!- otaku42 [i=otaku@madwifi/developer/otaku42] has joined #t2
08:25 < otaku42> hi
08:26 < otaku42> question: who would be the person to contact about a necessary fix in one of t2's packages? it's about http://www.t2-project.org/packages/madwifi.html
08:27 < _Ragnar_> me
08:29 < _Ragnar_> what's to fix?
08:32 < otaku42> _Ragnar_: Download: madwifi-2005-06-23.tar.bz2 cvs://:pserver:anonymous@cvs.sourceforge.net:/cvsroot/ madwifi madwifi -D 2005-06-23X
08:32 < otaku42> _Ragnar_: the cvs repository is deprecated.
08:33 < _Ragnar_> ah ok ... what's the official link?
08:33 < otaku42> _Ragnar_: the package should be adjusted to get its source out of the subversion repository, maybe from the madwifi-old branch, instead.
08:34 < otaku42> _Ragnar_: see http://madwifi.org/wiki/UserDocs/GettingMadwifi
08:35 < otaku42> _Ragnar_: more information about madwifi-old vs. madwifi-ng can be found here: http://madwifi.org/wiki/NewCodebase
08:35 < otaku42> _Ragnar_: if you plan to provide a madwifi-ng package, you should consider marking it as experimental (since it's still a fast-moving target)
08:36 < rxr> re
08:36 < _Ragnar_> ok
08:36 < otaku42> _Ragnar_: last but not least: the snapshot archive at http://snapshots.madwifi.org might be interesting for the purpose of packaging.
08:36 < _Ragnar_> ahh kewl
08:38 < _Ragnar_> thanks :)
08:38 < otaku42> _Ragnar_: you're welcome. just stumbled over the package information while looking about references to madwifi via google .)
08:39 < _Ragnar_> :)
08:39 < rxr> jsaw: mnemoc: the udev cdrom link problem appears to be due bugs in dietlibc setenv AFAICS
08:39 < rxr> jsaw: mnemoc: I contineu to debug it over the day
08:39 < rxr> jsaw: mnemoc: it might be even due stuff I implemented in dietlibc just for the sake of udev ...
08:40 < rxr> moin _Ragnar_ and otaku42
08:40 < otaku42> _Ragnar_: if you have questions, feel free to contact me via query or in #madwifi here on freenode
08:40 < otaku42> hi rxr
08:41 [Users #t2]
08:41 [@ChanServ ] [ jsaw ] [ mnemoc ] [ owl ] [ valentin_]
08:41 [ Baldzius_] [ karasz] [ mtr ] [ rxr ] [ _Ragnar_ ]
08:41 [ CIA-9 ] [ LMJ ] [ otaku42] [ sparc-kly_]
08:41 -!- Irssi: #t2: Total of 14 nicks [1 ops, 0 halfops, 0 voices, 13 normal]
08:43 < otaku42> _Ragnar_: i'm usually online during workdays between 7am and 5pm (CET = UTC + 1)
08:44 < _Ragnar_> :) kewl thanks a lot
08:44 < _Ragnar_> moin rene
08:49 < CIA-9> rene * r15322 /trunk/package/xorg/xproto/long64.patch:
08:49 < CIA-9> * fixed corg bug #1425, certain C issues on ppc64 - only halfly tested,
08:49 < CIA-9> commit for X.org reference
08:52 * rxr back to exam return - hopefully it starts now ...
08:52 < rxr> cu
08:53 < otaku42> i leave for now... have a nice timezone, all. bye.
08:53 -!- otaku42 [i=otaku@madwifi/developer/otaku42] has left #t2 ["Leaving"]
08:57 < CIA-9> mtr * r15323 /trunk/package/multimedia/swftools/ (. swftools.cache swftools.conf swftools.desc):
08:57 < CIA-9> Leonel Iv?\195?\161n Saafigueroa :
08:57 < CIA-9> * added swftools (0.7.0) - A collection of SWF manipulation and creation utilities
09:01 < _Ragnar_> ok test build running ... nini
09:32 < LMJ> moin moin
10:15 -!- rxr [n=rene@e178163077.adsl.alicedsl.de] has joined #t2
10:15 -!- Topic for #t2: T2 | 2.1.1.1 and 2.2.0-epsilon RELEASED! | The System Development Environment (SDE) | http://www.t2-project.org/ | Say hello and do not hesitate to ask us any questions that you may have. | http://www.rafb.net/paste/
10:15 -!- Topic set by mnemoc [] [Sat Jan 14 21:42:03 2006]
10:15 [Users #t2]
10:15 [@ChanServ ] [ jsaw ] [ mnemoc] [ rxr ] [ _Ragnar_]
10:15 [ Baldzius_] [ karasz] [ mtr ] [ sparc-kly_]
10:15 [ CIA-9 ] [ LMJ ] [ owl ] [ valentin_ ]
10:15 -!- Irssi: #t2: Total of 13 nicks [1 ops, 0 halfops, 0 voices, 12 normal]
10:15 -!- Channel #t2 created Sun Aug 8 19:15:33 2004
10:15 -!- [freenode-info] if you need to send private messages, please register: http://freenode.net/faq.shtml#privmsg
10:15 -!- Irssi: Join to #t2 was synced in 36 secs
10:21 < rxr> re
10:35 < rxr> puh
10:35 < rxr> at least one more mostly happy osx driver user ...
10:35 < rxr> damn commercial software have strange interesting problems ...
10:36 < jsaw> re
10:36 < rxr> moin jsaw
10:36 < rxr> jsaw: some hours ago I posted a note that udev problems are dietlibc problems
10:36 < jsaw> :)
10:36 * rxr just debugging
10:36 < jsaw> oh
10:38 < jsaw> how did you find out?
10:38 < rxr> debugging and logging the rule matching
10:38 < rxr> it claims every 2nd CDROM_* var that should be set is not set and treated empty
10:38 < rxr> and with glibc it works
10:38 < rxr> there is some setenv, putenv, cleanenv
10:38 < rxr> whatever messup in dietlibc
10:39 < rxr> but right now I debug why my test program segfaults in strtok ...
10:40 < rxr> jsaw: do you have some udev time today, or mostly busy already ?
10:40 < jsaw> mostly busy, but I might have some time tonight
10:41 < jsaw> (after Marlene's birthday party, today with Kindargarden friends...)
10:41 < rxr> hehe
10:41 < rxr> I would like to delegate trying to find rules for this tty* and such stuff to mimic what we had with devfs
10:42 < rxr> those are over 200 nodes in the dev/ root
10:42 < rxr> /dev/vc it was under devfs
10:43 < jsaw> dev/vc is there already
10:43 < rxr> hm
10:43 < rxr> /dev/tty* they are in udev
10:43 < jsaw> but only for [0-9] and [0-9][0-9]
10:44 < rxr> ah - sorry
10:44 < jsaw> KERNEL=="tty[0-9]*", NAME="vc/%n"
10:44 < rxr> all those nodes are confusing
10:44 < jsaw> hmm, these shouldn't be even in /dev
10:45 < rxr> I mean those with major 7
10:45 < rxr> vcs*
10:45 < rxr> no
10:45 < rxr> tty*
10:45 < rxr> damned
10:45 < rxr> major 3 they are ..
10:45 < rxr> so - finally
10:45 < jsaw> ah, yes
10:45 < rxr> those major 3 are many
10:46 < rxr> nearly 200 or so
10:46 < jsaw> [a-ep-z]*
10:46 < rxr> and major 2
10:46 < rxr> on devfs those are in pty
10:47 < jsaw> yep
10:47 < rxr> crw------- 1 root root 2, 0 Jan 1 1970 m0
10:47 < rxr> crw------- 1 root root 2, 1 Jan 1 1970 m1
10:47 < rxr> crw------- 1 root root 3, 0 Jan 1 1970 s0
10:47 < rxr> crw------- 1 root root 3, 1 Jan 1 1970 s1
10:47 < rxr> and so on
10:47 < jsaw> how were the pty's named in devfs?
10:47 < rxr> jsaw: do you have devs to compare ?
10:47 < rxr> moment
10:48 < jsaw> no
10:48 < rxr> http://dl.exactcode.de/devfs-naming.txt
10:48 < jsaw> debian rules:
10:48 < jsaw> devfs.rules:KERNEL=="ttyS[0-9]*", NAME="tts/%n"
10:48 < jsaw> devfs.rules:KERNEL=="ttyUSB[0-9]*", NAME="tts/USB%n"
10:49 < rxr> those are only the serial ports
10:49 < jsaw> oh, they do not even tackle tty[p-za-e]*
10:49 < jsaw> ok, forget it
10:49 < jsaw> *click*
10:49 < rxr> if we alone mimick those above they are onearly 400 nodes alone
10:52 < rxr> reload
10:52 < jsaw> are we going for full devfs naming?
10:52 < rxr> I rerun it to have more entries
10:52 < rxr> jsaw: I think no
10:52 < rxr> in fact some long devfs names did not turn out to be that useful
10:52 < rxr> and too many programs carry hardcodings in it
10:53 < rxr> I suggest to use the linux standard naming for readl hardware devices
10:53 < rxr> hd, sd, and so on
10:53 < rxr> they are not that verbose, but handly short and well known
10:53 < jsaw> ok
10:53 < rxr> all those massive pseudo stuff shoudl go to subfolder to not pollute the root
10:53 < jsaw> so only trying to keep /dev as clean as possible
10:53 < rxr> and this should also avoid most external stuff
10:53 < jsaw> ok
10:53 < rxr> e.g. a big devfsd compat name generator
10:54 < rxr> jsaw: ac
10:54 < rxr> k
10:54 < rxr> so - me back to debugging
10:54 < jsaw> go for it :)
10:54 < rxr> jsaw: if you could try those terminal whatever stuff it would be nice
10:54 < jsaw> yep, will try tonight
10:56 < jsaw> Error logs from desk-2.2.0-alpha-x86-64-athlon64-desktop:
10:56 < jsaw> 1016 builds total, 994 completed fine, 22 with errors.
10:56 < jsaw> looks better and better :)
10:56 < rxr> yep
10:56 < rxr> until I update gcc to 4.1 ,-)
10:56 < jsaw> hehe
10:56 < rxr> I'm still meditating whether to update to 4.1 for 2.2 or not ...
10:58 < jsaw> I think we should get the libdir != */lib straight before doing another big change
10:58 < rxr> yeah - to get most stable releases out and that to cebit we shold stabelize trunk now
10:58 < rxr> gcc-4.1 for 2.3 ...
10:59 < rxr> after all t2 is about a solid system to base on
10:59 < jsaw> yeah :)
10:59 < jsaw> yeah :)
10:59 < rxr> and thus we need go get udev under control again
10:59 < rxr> :-(
10:59 < jsaw> :/
11:01 < rxr> 22tok = strtok (copy, "=");
11:01 < rxr> (gdb) p tok
11:01 < rxr> $3 = 0xffffffffc204f250

11:02 < rxr> .-(
11:02 < rxr> ah!
11:02 < rxr> it is just because I had no #include
11:02 < jsaw> coffee time, brb
11:03 < jsaw> o.O
11:03 < rxr> and thus gcc assumed different calling convention or so ...
11:03 < rxr> int vs. char* size on x86-64 I assume
11:03 < rxr> f*ck
11:03 < rxr> another 45m wasted ...
11:09 < rxr> jsaw: just for your info, I get this in udev
11:10 < rxr> run_program: '/sbin/cdrom_id' returned with status 0
11:10 < rxr> import_keys_into_env: import 'ID_CDROM=1'
11:10 < rxr> name_list_key_add: adding 'ID_CDROM=1'
11:10 < rxr> ...
11:10 < rxr> udev_rules_get_name: process rule
11:10 < rxr> match_rule: ENV{'ID_CDROM'} is not set, treat as empty
11:10 < rxr> ...
11:10 < jsaw> huh
11:10 < rxr> some vars survive, half of them do not
11:11 < rxr> but as I said I'm already in dietlibc tracking it
11:11 < jsaw> sh*t
11:11 < rxr> jsaw: I tweaked the env stuff in the past, e.g. added clearenv
11:11 < rxr> and I know my dietlibc clearenv is dirty
11:11 < rxr> might be t2 patched dietlibc only ..
11:11 < rxr> patched to compile udev that is ...
11:12 < rxr> since clearenv is only needed by udev so far ...
11:13 < jsaw> uClibc sets __environ to NULL
11:13 < rxr> I do simillar stuff
11:13 < jsaw> read it :)
11:13 < rxr> but this leaks memory IIRC dietlibc other code pathes ...
11:13 < rxr> jsaw: uclibc ?
11:14 < jsaw> I always compare it ...
11:14 < rxr> yeah - I compared with glibc, which was more complex
11:14 < rxr> but I take a look
11:15 < jsaw> huh
11:15 < jsaw> rxr: dietlibc/putenv.c
11:15 < jsaw> static char **origenv;
11:15 < jsaw> if (!origenv) origenv=environ;
11:15 < jsaw> imo origenv is not 100% guaranteed to be NULL
11:16 < jsaw> eh, I mean dietlibc/lib/putenv.c
11:23 < jsaw> I don't get this line:
11:23 < jsaw> if (*string == **ep && !memcmp(string,*ep,len)) {
11:23 < jsaw> *string == **ep ????
11:26 < jsaw> also, the remove seems to leak memory, or?
11:26 < rxr> I set hm
11:27 < rxr> my system reboot due to critical cpu temperature
11:27 < rxr> in fact I think it was battery empty
11:27 < rxr> interesting to see my 2.6.16-rc1-mm5 kernel does such freaky stuff ...
11:27 < jsaw> :/
11:27 < rxr> and the latest udev mods do have again problems with firmware loading
11:27 < rxr> s
11:27 < rxr> after some tweadeling I plugged my ethernet cable into the notebook :-(
11:28 < rxr> Feb 6 12:15:48 localhost kernel: Critical temperature reached (101 C), shutting down.
11:28 < rxr> Feb 6 12:15:56 localhost exiting on signal 15
11:28 < rxr> but the laptop is not warm wat all - just battery was empty
11:28 < rxr> either this is a matching bug in the kernel or the BIOS sets up a rather strange MCE whatsoever ...
11:29 < rxr> anyway - back to dietlibc
11:29 < rxr> and then to firmware loading :-(
11:29 < jsaw> putenv is heavily flawed in dietlibc...
11:29 < rxr> and then I need to do osx driver work ..
11:29 < jsaw> it takes the pointer given to putenv and inserts it into the environment
11:30 < jsaw> no string copy whatsoever
11:30 < jsaw> dup* I mean
11:30 < rxr> The string pointed to by string becomes part of the envi-
11:30 < rxr> ronment, so altering the string changes the environment.
11:30 < rxr> man putenv
11:30 < rxr> I think that part is standard conforming
11:31 < jsaw> ok, still, (*string == **ep) seesm wrong to me
11:31 < rxr> jsaw: I take a look
11:31 < rxr> but here is the memleak: putenv is dietlibc
11:31 < rxr> when you putenv and then clearenv (with my naiv clearenv) it leaks memory
11:32 < rxr> since putenv has to allocate memory to produce the concatenated string
11:32 < rxr> glibc has ugly code to track this
11:32 < rxr> err setenv
11:32 < rxr> today is not my day
11:33 < rxr> too much udev in the morning and total confused again :-(((((
11:33 < jsaw> ...
11:33 < rxr> s/putenv/setenv/ in my above post
11:33 < jsaw> ah, now I see, setenv does the strdup
11:33 < jsaw> ok
11:34 < jsaw> ok, so, besides (*string == **ep), putenv seems to be correct
11:36 < rxr> what do you think is defect in that line?
11:36 < rxr> checks if it is already part of the environment
11:36 < rxr> ah
11:36 < rxr> no * in front of string?
11:36 < rxr> err
11:36 < jsaw> ah
11:36 < jsaw> I see now, thanks
11:37 < rxr> but I do not see anymore
11:37 < jsaw> too early in the morning...
11:37 -!- mtr_ [n=Michael@p54AFB670.dip0.t-ipconnect.de] has joined #t2
11:37 < jsaw> yes, comparison of the first character
11:37 < rxr> heh - look at what confusin I typed today already
11:37 < jsaw> :D
11:37 < rxr> jsaw: but why first char ?
11:37 < jsaw> old style
11:38 < rxr> old style ?
11:38 < rxr> why not just memcmp at all ...
11:38 < jsaw> prior to builtin memcmp in gcc, when it was actually a function call
11:38 < jsaw> one always compared the first characters first
11:38 < jsaw> then did the full memcmp call
11:38 < rxr> memcmp is in dietlibc anyway ...
11:39 < rxr> do you think it is just micro-optimization ?
11:39 < jsaw> if it is an explicit funtion call, comparing a[0] == b[0] first is faster
11:39 < jsaw> much faster
11:39 < jsaw> !!!
11:40 < rxr> we are on always slow env handling here - not molecule matching here ...
11:40 < jsaw> I did this in a hash table implementation too, I do not remember exactly, but I think average search time was more than 20% faster
11:40 < rxr> I think such stuff just hurts already confusing enough code
11:40 < jsaw> yes
11:40 < jsaw> as you said, not a time critical function... so
11:41 < jsaw> and I got confused too
11:41 < rxr> and it should be diet ,-)
11:41 < rxr> is the static origenv hurting ?
11:42 < jsaw> in connection with clearenv probably
11:43 < rxr> in theory we would need a list of explicitly allocated environment parts anyway - so clearenv can free them .-((
11:43 < jsaw> I don't see the necessity for origenv
11:43 -!- mtr [n=Michael@p54AFB005.dip0.t-ipconnect.de] has quit [Read error: 110 (Connection timed out)]
11:43 < jsaw> putting it after
11:43 < jsaw> if (tmp) {
11:44 < jsaw> char **origenv = environ;
11:44 < jsaw> should be sufficient
11:44 < rxr> this function is really PITA to read
11:44 < jsaw> yeah
11:44 < rxr> and I had fefes style of overly short names
11:44 < rxr> like tmp and a and b and such ...
11:44 < jsaw> static origenv is another micro optimization
11:44 < jsaw> imo
11:45 < jsaw> unnecessary too imo
11:46 < rxr> ok - I rewrite the function without those two optimizations and the one huring clearnenv (which udev uses)
11:46 < rxr> and at least one tmp -> whatever rename for readablity and test udev again ...
11:47 < jsaw> actually I do not see why he uses origenv altogether, now
11:47 < jsaw> environ==origenv?0:origenv
11:47 < jsaw> ---^ ???
11:47 < rxr> strange
11:47 < jsaw> origenv is never ever again changed
11:47 < rxr> he stores the first envion ever
11:47 < rxr> yes
11:48 < rxr> realloc can copy the memory, right?
11:48 < rxr> thus without clearenv this is already buggy alone, no ?
11:48 < jsaw> seems so, yes
11:48 < jsaw> The contents will be unchanged to the minimum of the old
11:48 < jsaw> and new sizes
11:48 < jsaw> man realloc --^
11:49 < rxr> the content
11:49 < rxr> but the memory layout might be anohter place
11:49 < jsaw> yep
11:49 < rxr> thus that alone is buggy in putenv
11:49 < rxr> or ?
11:49 < jsaw> yep, i think so too
11:49 < rxr> well: isn't it ?
11:49 < rxr> ok /me demystifing the function
11:50 < jsaw> :)
11:51 < rxr> s/tmp/value/
11:52 < rxr> sometimes I fear coders explicitly crypt their code to stay l33t leaders ...
11:53 < rxr> fefe is quite not responding on dietlibc list these days anyway - we have tons of patches - especially for embutils and fefe is not respong to any of them I sent upstream
11:53 < rxr> also not to most other posts (the few there are) - one even from Hrbert Poetzel
11:53 < rxr> +e
11:54 < rxr> wonder how much on his interest scala dietlibc is right now
11:55 < rxr> looks more like ENOCARE ... .-((
11:57 < jsaw> fork exactlibc :D
11:57 < rxr> nah
11:57 < rxr> put more than one cvs committer would be nice
11:57 < jsaw> yeah
11:58 < rxr> I do not need to fork every project in the work -ENOTIME
11:58 < rxr> and it would not exactly help the world while doing so
11:59 < rxr> hm
12:02 < rxr> ouh
12:02 < rxr> the assign code is wasting cycles like nothing
12:02 < rxr> relloc already preserves the content
12:02 < rxr> and then he does memcpy again?
12:02 < jsaw> ...
12:03 < rxr> he prepends and not append
12:03 < jsaw> better check the realloc too...
12:03 < rxr> thus the memcpy ...
12:03 < rxr> but, ... ??!?!?
12:03 < rxr> glibc does append
12:03 < rxr> with dietlibc my test program has the output reversed ..
12:03 < rxr> and thus not because the code is smaller and faster, no, it is doing a 2nd copy ?!?!?!?
12:04 < rxr> am I confused or is that so ?
12:05 < jsaw> it should even be a "memmove"
12:05 < jsaw> the areas may overlap if newenv == environ
12:05 < jsaw> ...
12:06 < jsaw> not may, _do_ overlap
12:07 < rxr> ok - so cleaned putenv works again for my test code
12:07 < rxr> let
12:07 < rxr> 's see how it react on udev access pattern
12:12 < rxr> works I think ,-)
12:12 < jsaw> :D
12:13 < rxr> create_node: symlink '/dev/cdrom' to node 'hdc' requested
12:13 < rxr> create_path: stat '/dev'
12:13 < rxr> create_node: creating symlink '/dev/cdrom' to 'hdc'
12:13 < rxr> create_node: symlink '/dev/cdrw' to node 'hdc' requested
12:13 < rxr> create_path: stat '/dev'
12:13 < rxr> create_node: creating symlink '/dev/cdrw' to 'hdc'
12:13 < rxr> create_node: symlink '/dev/dvd' to node 'hdc' requested
12:13 < rxr> create_path: stat '/dev'
12:13 < rxr> create_node: creating symlink '/dev/dvd' to 'hdc'
12:13 < rxr> create_node: symlink '/dev/dvdrw' to node 'hdc' requested
12:13 < rxr> create_path: stat '/dev'
12:13 < rxr> create_node: creating symlink '/dev/dvdrw' to 'hdc'
12:13 < jsaw> :D
12:13 < rxr> who writes how buggy the orig functions was to fefe?
12:13 < jsaw> hmm, I thought I commented out the dvdrw,cdrw lines?
12:14 < rxr> somehow it is not a nice task to hunt in detail how broken it was so fefe applies the new code ...
12:14 < rxr> maybe a "to enumerate how broken the current function is is left as an excercise for the reader"
12:14 < jsaw> lol
12:14 < rxr> jsaw: I have a local edited version
12:14 < jsaw> ic
12:14 < rxr> jsaw: saves me the trouble of writing the details report myself
12:15 < rxr> and my brain gets twisted with the orignal code too much
12:15 * jsaw understands that
12:16 < rxr> the if (tmp) or in my code if (value) also unneeded
12:16 < rxr> it if has no value, and thus to be removed, it is removed earlier above and then return()ed ...
12:16 < rxr> what do you think
12:17 < rxr> and if it is overwritten it returns immediatly as well ...
12:18 < jsaw> assume you remove a value not in the environ
12:18 < jsaw> then it falls through to the if (value)
12:18 < rxr> ah - good catch
12:20 < rxr> putenv.c | 20 +++++++++-----------
12:20 < rxr> 1 file changed, 9 insertions(+), 11 deletions(-)
12:21 < jsaw> huh
12:21 < jsaw> based on stats, must be pretty clean now :)
12:24 < rxr> I commit after the Build-Pkg dietlibc udev finished
12:25 -!- menomc [n=amery@200.75.27.10] has joined #t2
12:25 -!- mnemoc [n=amery@200.75.27.18] has quit [Nick collision from services.]
12:27 < CIA-9> jsaw * r15324 /trunk/package/gnome2/gst-plugins/ (4 files):
12:27 < CIA-9> * fix due to libdvdread update
12:27 < CIA-9> * copyright updates
12:27 < jsaw> Baldzius_: ---^
12:27 -!- menomc is now known as mnemoc
12:28 -!- Baldzius_ is now known as Baldzius
12:28 < Baldzius> :)
12:28 < Baldzius> hi jsaw, rxr
12:28 < Baldzius> jsaw: i am thinking about gst* updating to 0.10.*
12:29 -!- morfoh [n=morfoh@p54BEEEBB.dip.t-dialin.net] has joined #t2
12:29 < morfoh> moin
12:29 < Baldzius> hi morfoh
12:30 < morfoh> hi Baldzius
12:36 < rxr> moin morfoh
12:36 < rxr> morfoh: what kind of tape?
12:36 < rxr> morfoh: I have a ordinary tape here
12:36 < rxr> morfoh: any my farther has a ReVoX studio tape
12:36 < rxr> B77 or so
12:36 < rxr> jsaw: sometimes I get this compile error for udev extras on my laptop:
12:36 < rxr> !> scsi_serial.o: In function `prepend_vendor_model':
12:36 < rxr> !> scsi_serial.c:(.text+0x1e6): undefined reference to `sysfs_attr_get_value'
12:36 < rxr> !> scsi_serial.c:(.text+0x208): undefined reference to `sysfs_attr_get_value'
12:36 < rxr> !> scsi_serial.o: In function `scsi_get_serial':
12:36 < rxr> !> scsi_serial.c:(.text+0x8c6): undefined reference to `sysfs_attr_get_value'
12:36 < rxr> rm the .o and rerunning manually helps
12:37 < rxr> very strange
12:38 < jsaw> hmm, NOPARALLEL is there...
12:38 < rxr> yes, I said very strange
12:39 < rxr> morfoh: http://www.gbaudio.co.uk/data/b77.htm
12:39 < morfoh> moin rxr ... unf. I don't know exactly what kind of tape that is. I phoned with my mom yesterday, and she told me about the tape ... She will get the tape this week
12:40 < rxr> hah: http://www.reeltoreel.de/Revox/Anzeige14.htm
12:41 < rxr> "push button digital logic control of tape motion"
12:41 < rxr> maybe I should get my farther a A77 so I can potentially get his B77 ,-)
12:41 < rxr> guess they want $$$$$$$$ for those on ebay today
12:41 < jsaw> cu later
12:42 < rxr> jsaw: cu
12:42 < morfoh> hi and cu jsaw ;)
12:42 < rxr> http://cgi.ebay.de/REVOX-A77-Highspeed-2-Track-19-38-nach-IEC_W0QQitemZ7586231997QQcategoryZ19604QQrdZ1QQcmdZViewItem
12:42 < rxr> ^- heh - 66EUR right now ...
12:42 < rxr> not too bad for only 6h going
12:43 < morfoh> :)
12:44 < morfoh> rxr: does your dad is still using that equipment :)
12:44 < rxr> nope - it is deco nowadays ... ,-)
12:45 < rxr> his revox tube amp. equipment is deco - he has a yamaha 7 channel digital surround whatever in the living room
12:45 < morfoh> hehe :)
12:45 < rxr> but he does want to keep his deco ,-)
12:46 < morfoh> rxr: that was not the question ;)
12:46 < rxr> and I once said he would like to get the A77 instead of the B77 for his A series amplifier and tuner just for the matching of it ...
12:46 < rxr> and he ...
12:46 < rxr> the B77 is nice deco, so when I find a A77 I might get the B77 ,-)
12:50 < morfoh> Yeah :)
12:51 < rxr> and it would frizzle around way less than this chepo laptop line out ...
12:52 * rxr wonders how people can design such poor circuits with such high noise ratio ...
13:00 < morfoh> rxr: btw, did you found the problem on mnemoc's 2.2 mnemosyne iso ?
13:00 < rxr> morfoh: yes udev
13:00 < rxr> morfoh: and not really udev but dietlibc ...
13:00 < rxr> final commit soon
13:00 < rxr> asn in this hour or so
13:01 < morfoh> rxr: ah! cool :)
13:01 < morfoh> rxr: what specific problem does the dietlibc has on 2.1 ?
13:01 < rxr> no idea what the 2.1. diet has ...
13:02 < mnemoc> 0.28 iirc
13:02 < morfoh> rxr: so you just updated dietlibc ?
13:02 < morfoh> hi mnemoc
13:02 < mnemoc> hi morfoh, rxr :)
13:02 < rxr> morfoh: there is no upstream development of dietlibc right now
13:02 < morfoh> mnemoc: :)
13:02 < rxr> development is happening mostly in t2 ..
13:02 < mnemoc> yes, 0.28
13:03 < mnemoc> Bertl from vserver is also doing dietlibc-related development
13:07 < rxr> poetzel?
13:07 < morfoh> rxr: yeah ... good ol'Bertl :)
13:07 < rxr> yes, he had a hppa thing some weeks ago without any resonpse
13:08 < karasz> hello all
13:08 < karasz> a good day rxr, kommrad
13:08 < karasz> mnemoc: :)
13:09 < karasz> mnemoc: did you praqyed?
13:09 < karasz> even prayed..
13:09 < karasz> mnemoc: http://www.x5.ro/regressions/desk21/regressions.html
13:10 < morfoh> hi tovorish karasz :)
13:10 < karasz> not too bad I guess...
13:11 < karasz> so the java stuff i understand, cause i have no javac
13:11 < mnemoc> karasz: doesn't look bad
13:11 < karasz> the other 6 thou.... are kind of cryptic to me
13:11 < CIA-9> rene * r15325 /trunk/architecture/x86-64/archtest.out: * cleaned i386 and quitings in x86-64/archtest.out
13:12 < morfoh> rxr: if I take a look at fefe's company references, no wonder that he has no time for diet development anymore :p
13:13 < rxr> codeblue it was ?
13:13 < karasz> rxr should I svn up and restart the HEAD descktop?
13:13 < morfoh> rxr: yep
13:13 < rxr> karasz: nope
13:13 < karasz> kj
13:13 < rxr> karasz: those are just cosmetically
13:13 < mnemoc> karasz: no, it's ok. thanks :)
13:13 < karasz> mnemoc: ?
13:14 < rxr> oh yes his list got longer
13:14 < rxr> when I look at embutils and dietlibc bugs I wonder how much of his famour quality really stands
13:14 < mnemoc> karasz: a rebuild on 2.1 wont change anything
13:15 < karasz> mnemoc: i was talkin' to rxr abt my HEAD desktop, nor 2.1-test
13:15 < mnemoc> :)
13:15 < morfoh> rxr: securiy analysis for Microsoft Corporation :p
13:15 < rxr> oh
13:15 < karasz> mnemoc: if i can do anything else for 2.1-test, lemme know ;)
13:15 < karasz> as kommrad would say it `Anything for the cause!`
13:15 < mnemoc> :)
13:16 < karasz> other stuff
13:16 < karasz> mnemoc: i found some runit scripts for various services
13:16 < morfoh> karasz: what ?
13:16 < morfoh> karasz: smarden.org/runit/ ? :p
13:16 < karasz> mnemoc: http://old.bougyman.com/service/
13:17 < morfoh> oh
13:17 < morfoh> *click*
13:17 < mnemoc> brb
13:17 < karasz> not top qualit I am afraid...
13:17 < rxr> what the heck
13:17 < rxr> for some strange reason scsi_id is rebuild in the udev build
13:18 < karasz> kommrad if you are interested, i even got a runit for bincimap ;)
13:18 < morfoh> karasz: what do you mean with "not top quality" ?
13:19 < karasz> soe of the scripts I do not like very much, see lighttpd for example
13:19 < karasz> has some speciffic dirs in it which must be edited...
13:20 < morfoh> karasz: but that is not a big problem
13:20 < karasz> and the qmail scripts, well, ....
13:20 < rxr> heh
13:20 < rxr> btw. microsoft
13:20 < karasz> i wasn't able to get them goin'
13:20 < rxr> I had a long talk with various of those puppies at the linux world expo
13:21 < rxr> among others I told them what a crappy lousy company they are when they want 300 EUR from me when I as a driver developer notify them about application bugs that crash on certain response from a driver and that it was then never fixed
13:22 < rxr> the person said he would come back with a contact within microsoft so that could be better handled next time
13:22 < valentin_> at the linux world expo
13:22 < rxr> so far I did not got any signal from microsoft again
13:22 < rxr> echo "talk promisses" > /dev/null
13:22 < valentin_> re
13:22 < valentin_> damn
13:22 < rxr> and /dev/brain symlink to /dev/null ...
13:22 < rxr> hi valentin_
13:22 < valentin_> ignore my first sentence
13:22 < morfoh> hi valentin_
13:22 < valentin_> cut'n'paste accident
13:23 -!- valentin_ is now known as valentin
13:24 < valentin> rxr: rename gsmp to exactsound if you wish
13:24 < rxr> valentin: makes more sense, no ?
13:24 < rxr> valentin: your baby phone will get into it as well, no ?
13:24 < valentin> rxr: :)
13:25 < valentin> maybe i'd create an extra package for it
13:25 < morfoh> .oO( babyphone? )o :)
13:25 < valentin> yea, analog phones suck
13:25 < morfoh> valentin: btw, how are your girlies ? :)
13:25 < valentin> fine
13:25 < rxr> valentin: no- let's rather get the sound stuff more mature before packaging pats singular
13:25 < morfoh> :)
13:27 < rxr> parts
13:27 < rxr> valentin: uni today i guess ?
13:28 < valentin> yes
13:29 < rxr> # l /dev/{dvd,cd}*
13:29 < rxr> lrwxrwxrwx 1 root root 3 Feb 6 14:29 /dev/cdrom -> hdc
13:29 < rxr> lrwxrwxrwx 1 root root 3 Feb 6 13:21 /dev/cdrw -> hdc
13:29 < rxr> lrwxrwxrwx 1 root root 3 Feb 6 14:29 /dev/dvd -> hdc
13:29 < rxr> lrwxrwxrwx 1 root root 3 Feb 6 13:21 /dev/dvdrw -> hdc
13:29 < rxr> so
13:29 < rxr> all builds cleanly and all works fine now ...
13:29 < morfoh> rxr: :)
13:30 < CIA-9> rene * r15326 /trunk/package/filesystem/udev/ (udev.conf udev.desc):
13:30 < CIA-9> * removed explicit installing of the udev extras, that is broken and
13:30 < CIA-9> does occationally rebuild the tools with different options
13:30 < CIA-9> * removed PARALLEL flag from udev
13:30 < valentin> rxr: maybe you want to test this on kerstins machine ?
13:30 < rxr> nope
13:30 < rxr> valentin: I fixed it on kertins machine long ago
13:30 < valentin> where you have different devices for cd(rw) and dvd
13:30 < rxr> this is a new bug
13:30 < rxr> nah - that part will work and I can test here
13:30 < rxr> this is a totally new issue ...
13:30 < valentin> ok
13:31 < rxr> and in fact was lingering in dietlibc itself :-(((
13:33 < CIA-9> rene * r15327 /trunk/package/base/dietlibc/putenv.patch:
13:33 < CIA-9> * fixed dietlibc/putenv - and thus udev rule matching with external
13:33 < CIA-9> programs when env vars are set based on their output
13:38 < rxr> after exessive use reiser4 is stil fast
13:38 < rxr> svn st
13:38 < rxr> real0m43.163s
13:38 < rxr> user0m1.040s
13:38 < rxr> sys0m1.464s
13:38 < rxr> cached:
13:38 < rxr> real0m3.139s
13:38 < rxr> user0m0.848s
13:38 < rxr> sys0m0.480s
13:39 < rxr> valentin: beside the av3850 today the av220c2 arrived
13:39 < rxr> the av220c2 is exactly like the av220 but even faster
13:40 < rxr> 10 pages per minute faster
13:40 * rxr needs to optmize the driver the next days to get that speed improvement under linux ...
13:40 < rxr> currently the driver is not able to pull the data at that rate out of the device ...
13:42 < rxr> and respite some hard reboots and not wake up from suspend i have not lost a file on reiser4 yet .....
13:43 < rxr> and /me is off hunting lunch some time in the next minutes
13:44 < valentin> rxr: nice speed - however my only osx test machine has usb 1.0 :(
13:44 < valentin> have a nice meal
13:44 < rxr> yeah ...
13:45 < rxr> even with USB 2 our mac drive performance is 1/2 of the linux speed due odd USB subsystem in OS suX - as usuall ...
13:45 < morfoh> rxr: how do you meassure USB drive perfomance ?
13:46 < valentin> morfoh: transfer in mb/s ?
13:46 < rxr> morfoh: MB/s transfer speed ...
13:46 < rxr> dog slow compared to linux ...
13:46 < rxr> for no good reason
13:46 < rxr> same i/o access pattern - same driver i/o core ...
13:47 < valentin> morfoh: not to mention even with the same driver core
13:47 < rxr> but everything in OS X is dog slow and sugs and is full of bugs one has to work around ...
13:47 < morfoh> ic
13:49 < rxr> guess why we, despite on Apple hardware avoid to boot into the mirror work as seldom as possible ...
13:49 < rxr> when I get a driver issue ticked I continue my current t2 tinkering and eventually boot the other (wanna be) os later on ...
13:49 < morfoh> rxr: I've never seen you complaining about booting into OSX :p
13:49 < rxr> that reminds me - I have a issue to track today :-(
13:50 < rxr> morfoh: you are not onlien 24x7 ...
13:50 < rxr> online
13:50 < valentin> well, the only nice thing under osx is .. hm ... cannot think of any :)
13:50 < CIA-9> chris * r15328 /trunk/package/network/pound/pound.desc: * updated pound (1.9.5 -> 2.0.1)
13:51 < valentin> ah, yes - have a ppc flashplayer
13:51 < morfoh> valentin: :)
13:51 < rxr> valentin: is that the composition manager is slightly faster then on linux - but only due propper hardware accel and it will not be faste for too much longer
13:51 < valentin> and a javavm which is somewhat more performant than the one by ibm - but who cares about java
13:51 < rxr> but it has more rendering bugs than the X.org implementation ...
13:51 < valentin> definitly
13:52 < valentin> and the multitasking sucks...
13:53 < CIA-9> rene * r15329 /trunk/target/desktop/config.in:
13:53 < CIA-9> * changed the desktop target to build only the minimally needed
13:53 < CIA-9> xorg packages, e.g. not the worst legacy junk (might not be complete
13:53 < CIA-9> yet)
13:53 < rxr> so - /me lunch
13:53 < valentin> even their OSD emulator pops up with a 1 second delay
13:53 < valentin> cu rxr
13:53 < rxr> valentin: yes, this OSD is suprisingly unresponsive ...
13:54 < rxr> I gues mostly taken out of swap or so ..
13:54 < morfoh> rxr: good apetite ;)
13:54 < rxr> and the startup progress bar that draws purely based on "time needed last bootup" is the biggest joke ever
13:55 < valentin> i'm sure they patented this technique
13:55 < rxr> and that they ship x86 cpus without -64 extension in 2006 is the 2nd biggest joke ever
14:06 < mnemoc> re
14:07 < valentin> hi mnemoc
14:07 < mnemoc> hi valentin
14:08 < mnemoc> "With my changes to the rockinitrd it does. Unfortunately I had massive
14:08 < mnemoc> problems creating a patch due to submaster"
14:08 < mnemoc> -netrunner
14:08 < valentin> why ?
14:08 < valentin> i mean, i do not like SM, but what is the problem ?
14:09 < mnemoc> he doesn't say... but i assume consistency problems on the local sm thing
14:09 < valentin> ok, that is a real issue sometimes
14:10 < valentin> and that is why i prefer a single layer vcs
14:11 < mnemoc> they could also have used svk, which is far more mature than sm
14:12 < rxr> moin mnemoc
14:12 < valentin> they could even have done something with svn properties as rxr proposed in rock times
14:13 < valentin> e.g. a pro-vote property for each trunk revision
14:13 < mnemoc> moin rxr
14:13 < morfoh> wb mnemoc
14:13 < valentin> and then only take those revisions into stable branch which have positive vote
14:14 < mnemoc> that sounds nice
14:14 < mnemoc> ==[build_this_package:925 (last $?=0)> ldconfig
14:14 < mnemoc> ldconfig: Remove `/lib' from `/etc/ld.so.conf'
14:14 < mnemoc> ldconfig: Remove `/usr/lib' from `/etc/ld.so.conf'
14:14 < mnemoc> o_O
14:14 < rxr> ?
14:15 < rxr> yes, submaster became something I did not intend a bit in the beginning
14:15 < rxr> clifford purely hacked up his own dreams instead what we talked about when we wanted to open the tree to more people ..
14:15 < rxr> but that is history ...
14:16 < mnemoc> yep
14:18 < rxr> I once made the failure to merge a successful project back into rock - not a 2nd time ..
14:19 < rxr> pcre still fails on ppc64 :-(
14:19 < rxr> due to libtool brokenness :-((
14:31 < morfoh> rxr: btw, what is your meassured transfer rate on a USB2 drive, you mentioned before ?
14:32 < rxr> morfoh: hm - do not know off hand
14:32 < rxr> why do you ask ?
14:33 < mnemoc> checking dynamic linker characteristics... no
14:33 < mnemoc> checking if libtool supports shared libraries... no
14:33 < mnemoc> checking whether to build shared libraries... no
14:33 < mnemoc> checking whether to build static libraries... yes
14:33 < mnemoc> yuck yuck yuck....
14:33 < rxr> what is that ?
14:33 < mnemoc> popt against uclibc
14:33 < rxr> heh
14:33 < mnemoc> with dynamic support
14:33 < mnemoc> and keepalived fails because popt.so is not there :\
14:33 < morfoh> rxr: because I ran into problems with an external HD here
14:34 < rxr> storage devices archive a higher thruput than my scanner i/o core that is usually run in user-space land with higher i/o latency
14:36 < karasz> mnemoc: shouldn't freedt be enabled on mnemosyne by default?
14:37 < mnemoc> karasz: ??!
14:37 < karasz> err..., how do I put that...
14:37 < karasz> mnemosyne uses runit
14:38 < mnemoc> karasz: why? it will conflict with runit
14:38 < karasz> I got that ideea from a bunch of runit scripts wich require multilog
14:38 < mnemoc> karasz: change them to use svlogd
14:38 < karasz> and multilog is in freedt as i remember...
14:38 < karasz> oki
14:40 < morfoh> hell ... svn up definitely takes too much time on my external HDD
14:40 * morfoh installs a kernel with USB debugging enabled :/
14:40 < karasz> mnemoc: can yop check /opt/bincmap/share/service/bincimap/log/run ?
14:41 < mnemoc> i use a modified version of qmail-imapd from qmail-ldap
14:41 < rxr> morfoh: did the hardware combo worked before?
14:41 < karasz> yes that and bincimaps too uses multilog
14:42 < morfoh> rxr: yes ... it was quite fast some days before
14:42 < rxr> what was the change?
14:42 < rxr> kernel update ?
14:42 < morfoh> then I got some I/O errors from the scsi driver
14:42 < mnemoc> karasz: so? multilog is from daemontools, svlogd is much better than it
14:43 < karasz> but that is put there by Building bincimap on T2
14:43 < karasz> by mnemosyne
14:43 < morfoh> rxr: yes ... I installed a new kernel but same revision
14:43 < mnemoc> karasz: bincimap install it's sample scripts
14:43 < rxr> morfoh: hm
14:43 < morfoh> and same config ... at least I didn't changed things related to USB and SCSI
14:44 < mnemoc> karasz: an official run script would have been at /etc/opt/bincimap/bincimap
14:44 < CIA-9> rene * r15330 /trunk/target/desktop/config.in:
14:44 < CIA-9> * removed dynamic gnome dependency creation from the desktop target
14:44 < CIA-9> and added one more missing modular X base package
14:44 < mnemoc> karasz: # cat /service/qmail-imapd/log/run
14:44 < mnemoc> #!/bin/sh
14:44 < mnemoc> exec setuidgid qmaill svlogd -tt /var/qmail/log/qmail-imapd
14:44 < mnemoc> that's mine
14:45 < karasz> so that is ok, not something to patch...?
14:45 < mnemoc> karasz: you could patch it, but thing it's better to add the .tail files
14:46 < karasz> ic
14:46 < morfoh> rxr: wonderfull -->
14:46 < morfoh> SCSI error : <0 0 0 0> return code = 0x70000
14:46 < morfoh> end_request: I/O error, dev sda, sector 241588263
14:46 < morfoh> EXT3-fs error (device sda1): ext3_find_entry: reading directory #15090330 offset 0
14:46 < morfoh> Aborting journal on device sda1.
14:46 < morfoh> ext3_abort called.
14:46 < morfoh> EXT3-fs error (device sda1): ext3_journal_start_sb: Detected aborted journal
14:46 < morfoh> Remounting filesystem read-only
15:02 -!- sparc-kly__ [n=G3@64.237.240.250] has joined #t2
15:12 < karasz> re
15:12 < karasz> mnemoc: when ypu will have the time, i'd like som info on settin' up qmail ...
15:13 -!- sparc-kly__ [n=G3@64.237.240.250] has quit [Remote closed the connection]
15:14 * morfoh has to reboot again ... bbl
15:14 -!- morfoh [n=morfoh@p54BEEEBB.dip.t-dialin.net] has quit ["leaving"]
15:14 < mnemoc> karasz: start setting up the virtualization you want to use
15:14 < mnemoc> karasz: then qmail-send
15:14 < karasz> ?
15:14 < mnemoc> karasz: then qmail-smtp
15:15 < mnemoc> karasz: then pop, then imap
15:15 < mnemoc> karasz: and at the very very end que queue filterings
15:16 < karasz> :(
15:16 < mnemoc> ?
15:17 < karasz> i never set up any mail server :(
15:17 < mnemoc> qmail is not easy to set up if you don't understand it
15:17 < karasz> ack
15:17 < karasz> but i guess problems run deeper than qmail
15:17 < CIA-9> rene * r15331 /trunk/target/desktop/config.in:
15:17 < CIA-9> * added makedepend (for mesa) and mkfont* for the bitmap font packages
15:17 < CIA-9> to the desktop target
15:18 < karasz> maybe i lack some info on mailservers in general....
15:18 < mnemoc> that's why i give you that checklist, in that precise order
15:18 < karasz> virtualization=?
15:19 -!- sparc-kly_ [n=G3@64.237.244.94] has quit [Read error: 113 (No route to host)]
15:20 < mnemoc> karasz: where will your accounts be defined
15:21 < karasz> until now, on the mailserver, acount were created when user was created
15:21 < karasz> if that is what you implied...
15:23 -!- morfoh [n=morfoh@p54BEEEBB.dip.t-dialin.net] has joined #t2
15:23 < mnemoc> if your users will all be at /etc/passwd, there is no 'virtualization'
15:23 < morfoh> re
15:23 < karasz> that was the case until now
15:28 * morfoh booted the kernel with pci=noacpi but still I have some problems
15:28 < morfoh> there where also some ML threads which mentioned power issues
15:29 < morfoh> but now I have to do some kitchen cleaning :/
15:29 < morfoh> bbl
15:34 < mnemoc> karasz: frequently what people needs is vmailmgr
15:35 < mnemoc> karasz: /etc/passwd is too intrusive and ldap too complex for not-big enviroments
15:35 < rxr> so - I guess I soon stop the ppc64 desktop build and boot over in the mirror world ...
15:36 < karasz> enviroment is quite small
15:36 < karasz> max 20 users...
15:36 < karasz> maybe 30 at top
15:36 < mnemoc> karasz: do you want to give them accounts on your server? i doubt
15:36 < karasz> some of them...
15:36 < karasz> at least
15:36 < rxr> does anyone have recommendations for a good "large file" hex editor ?
15:37 < karasz> is that vmailmgr?
15:37 < karasz> or just some libs...
15:38 < mnemoc> vmailmgr is a package
15:38 < mnemoc> bglibs includes some libraries to manage vmailmgr database
15:39 < karasz> 2.1.1.1 has vmailmgr?
15:39 < mnemoc> i doubt
15:40 < karasz> it hasn't...
15:40 < karasz> but in the end i can live with /etc/passwd
15:40 < karasz> i set them up to /bin/nologin ...
15:40 < mnemoc> # echo t2-*/package/*/vmail*
15:40 < mnemoc> t2-trunk/package/mail/vmailmgr
15:41 < mnemoc> if you want /etc/passwd, go for it :)
15:41 < karasz> even login=/bin/false
15:48 < karasz> bbl
15:50 < morfoh> mnemoc karasz ... what about dirqmail ?
15:51 < mnemoc> morfoh: looks weird and nice at the same time
15:51 < mnemoc> morfoh: but i have never tried it
15:51 < mnemoc> morfoh: i prefer vmailmgr :)
15:52 < morfoh> hehe :)
15:52 < morfoh> mnemoc: never tried it neither, but I thought you did :p
15:57 < morfoh> Timing buffered disk reads: read(2097152) returned 4096 bytes
15:57 < morfoh> :(
15:58 < morfoh> on another system the external HDD is functioning .. already tested on a "gentoo laptop" running 2.6.12 :(
15:59 < morfoh> anyhow ... have to do some other work now :(
16:11 < karasz> re
16:12 < karasz> hmm, another issue
16:12 < karasz> i do not have messages file or the equivalent...
16:15 < mnemoc> /var/log/socklog/main/current
16:54 -!- misl [n=chatzill@82-217-66-150.cable.quicknet.nl] has joined #t2
16:54 < misl> hi folks
16:59 < morfoh> hi WMD :)
17:00 < misl> ?
17:01 < morfoh> misl: Weapon of Mass Destruction <-- you should know that :p
17:02 < rxr> jsaw: did freeglut fail for your lib64 build ?
17:02 < misl> why? I have I mass distruction t2 svn?
17:02 < rxr> hi misl ,-)
17:02 < misl> hi rxr, jsaw ..... morfoh too ;-)
17:03 < CIA-9> rene * r15332 /trunk/package/x11/freeglut/freeglut.conf:
17:03 < CIA-9> * fixed freeglut for lib64 architectures and removed -Werror due
17:03 < CIA-9> warnings on certain X versions and 64bit systems
17:05 < morfoh> misl: not yet ... afaik
17:09 < misl> morfoh: I am only a missile of minor distruction :)
17:10 < morfoh> misl: hehe :)
17:11 < morfoh> misl: powered by Sun's "MDK"
17:11 < karasz> MDK=minor distruction and kill?
17:11 < morfoh> Missile Development Kit
17:12 < karasz> well, i wasn't that far...
17:12 < morfoh> karasz: yep :p
17:17 < karasz> morfoh: wanna do smth similar with me?
17:17 < rxr> heh - I could not resist - I replied to one of Schillings latests mails
17:17 < rxr> I hope he does not come over cause I asked what good drugs there are in berlin ...
17:18 < mnemoc> http://lkml.org/lkml/2006/2/6/217/index.html
17:19 < mnemoc> :)
17:20 < rxr> ack ,-)
17:20 < rxr> that mail archive is fast ...
17:20 < mnemoc> :)
17:21 * rxr fears living too close to schilling to get phyical problems out of the flamewar ,-)
17:21 < mnemoc> how big is he? :)
17:21 < rxr> no idea ...
17:22 * rxr happy to never met him in this big metropole ...
17:22 < mnemoc> :)
17:22 < rxr> ah! - now I assume where this libX* not found issue comes from
17:23 < rxr> mnemoc: do you have a matrix connection in your brain - or how did you come up with the link so fast =
17:23 < rxr> ? even
17:24 < mnemoc> hehe
17:25 < mnemoc> i just was around here, read your comment and open lkml :)
17:25 < morfoh> rxr: I think mnemoc get's all mails from the kernel's ML as SMS :p
17:26 < rxr> morfoh: SMSed into the brain
17:26 < morfoh> rxr: ack :)
17:26 < rxr> via the matrix interconnect - that it must be
17:26 < morfoh> rxr: I think so too
17:26 < mnemoc> heheh
17:28 * karasz pours some cold water on his boilin' head
17:30 < morfoh> another nice to have would be, to process the mails via voice synthesizer and transnmitting it with an radio transmitter ... "Radio Schillix" :)
17:32 < rxr> jsaw: just for your info, with your libsuffix stuff for auto*
17:32 < rxr> jsaw: the binutils ld stuff internally calls it LIBPATH_SUFFIX:
17:32 < rxr> # Look for 64 bit target libraries in /lib64, /usr/lib64 etc., first.
17:32 < rxr> case "$EMULATION_NAME" in
17:32 < rxr> *64*) LIBPATH_SUFFIX=64 ;;
17:32 < rxr> esac
17:33 < mnemoc> commodore64?
17:33 < rxr> mnemoc: lib vs lib64 ?
17:34 < mnemoc> i was just commenting that greedy condition
17:35 < morfoh> rxr: btw, you should not name your patches crap ... you shouldn't give them extra ammo ;)
17:37 < rxr> morfoh: ?
17:37 < morfoh> your last mail on kernel ML ... "PS: Yes, I run a bastarized version of cdrecord that has a whole bunch of
17:37 < morfoh> crap patched away."
17:37 < morfoh> ah!
17:38 < morfoh> I should learn read :p
17:38 < morfoh> sorry ;)
17:52 < rxr> .oO
17:52 < rxr> for lib64 arches binutils does not open /etc/ld.so.conf and thus we get some stray build errors where I already fixed a few of them .-( because I thought they where due X11R7 :-((((
17:54 < mnemoc> bad rxr, bad
17:54 < rxr> that I silenced them or that I found yet the next issue ?
17:55 < mnemoc> for fixing a bug thinking it was another bug :)
17:56 < rxr> you are right - I better stop bughunting and leave that for your pleasure ,-)
17:57 < mnemoc> no..., don't repress your instincts
17:57 < mnemoc> that's bad for the soul
17:57 < rxr> damn - thought I would have find another one for the hunting season :-((
17:58 < mnemoc> another hunter or another prey?
18:00 < karasz> mnemoc: i officialy lost all my hair over qmail
18:00 < karasz> i will stop for now, cause i do not want to loose my skin too.
18:01 < rxr> this binutils ld shell code template processing is awful ...
18:01 < rxr> my oh my
18:01 < karasz> no more qmail for today ;)
18:01 < rxr> how shoudl one find in this mess why ld.so.conf is read on some system and not on others
18:01 < rxr> I declare this cruft unmaintainable
18:01 < karasz> tommorow is another day, despite kommrads fears ;)
18:01 < rxr> guess that's why it is at least broken on ppc64 ...
18:02 < mnemoc> karasz: qmail-start, just qmail-start. and follow it's logs and strace
18:03 < karasz> qmail-start is on my system an elf executable, why the hell all the net is crowded with a bash script named qmail-start????
18:03 < mnemoc> karasz: qmail-start is a binary
18:03 < karasz> yes
18:03 < mnemoc> karasz: which triggers are repeat signals to three children
18:04 < mnemoc> qmail-clean qmail-lspawn and qmail-rspawn
18:04 < mnemoc> first make sure qmail-lspawn works
18:05 < mnemoc> injecting mails locally and seen if they are properly delivered
18:05 < karasz> alert: cannot start: unable to read controls
18:05 < mnemoc> ehm
18:06 < karasz> buildin strace in the mean time
18:06 < mnemoc> start configuring your qmail :)
18:06 < mnemoc> me, rcpthosts, locals and defaultdelivery
18:07 < karasz> i only have defaultdelivery set to ./Maildir/
18:12 < mnemoc> that is ok on most cases, but doesn't work well with bincimap
18:12 < mnemoc> bincimap set to use imapdirs
18:13 < karasz> bincimap is gone
18:13 < mnemoc> what will you use?
18:14 < karasz> as you said qmail....
18:15 < rxr> has someone a x86-64 suse or readhat at hand ?
18:16 < mnemoc> karasz: on your design you have to consider how the whole solution will work
18:16 < mnemoc> karasz: for using bincimap i suggest you defaultdelivery=./IMAPdir/INBOX/
18:16 < karasz> that i have problems with...
18:17 < karasz> what i do not understand is that qmail is a whole solution or not....?
18:17 < karasz> last setup involved dovecot and postfix
18:18 < karasz> 2 daemons for mails
18:18 < mnemoc> i know them :)
18:18 < karasz> one for smpt and the other for imap/pop3
18:18 < mnemoc> dovecot is nice, but bincimap is better
18:18 < karasz> dovecot i hate
18:19 < karasz> since i lost 1/2 of my hair setting it up....
18:19 < mnemoc> postfix is nice, simpler and free... qmail is even simpler (when you understand it), cheaper and more reliable
18:19 < karasz> so except qmail do I need smth else?
18:19 < karasz> to send and receive...
18:20 < karasz> do i need binimap or dovecot or else?
18:20 < _Ragnar_> hihi
18:20 < mnemoc> qmail includes a pop
18:20 < mnemoc> if you will use /etc/passwd you don't need a virtualization
18:20 < mnemoc> and for imap, imo the best is bincimap
18:21 < karasz> mnemoc: you already told me that :)
18:21 < karasz> the question is do I need it or not?
18:22 < karasz> can I rely only on qmail for send and receive?
18:22 < mnemoc> as MTA? yes, sure
18:22 < karasz> good
18:22 < karasz> so i do not need anything else except spamassasin and clamd
18:24 < mnemoc> qmail-scanner
18:24 < mnemoc> to bind qmailqueue to spamassasin and clamd
18:25 < karasz> yup, that too
18:47 < karasz> root@expertweb:/usr/src/t2-2.1.1.1# qmail-start
18:47 < karasz> status: local 0/10 remote 0/20
18:47 < karasz> then waitin...
18:47 < mnemoc> mail root
18:48 < mnemoc> `mail root` i mean
18:48 < karasz> should I ctrl-C?
18:48 < mnemoc> nope
18:48 < mnemoc> let it run
18:48 < mnemoc> for ever and ever
18:48 < karasz> another console maybe?
18:48 < mnemoc> yes
18:48 < karasz> because now i do not have prompt
18:48 < karasz> oki
18:49 < karasz> mail root?
18:49 < karasz> mail :-> command not found ...
18:50 < mnemoc> mailx ?
18:51 < mnemoc> /var/adm/flists/mailx:mailx: bin/mail
18:51 < mnemoc> or mnemosyne has nail these days?
18:51 < mnemoc> yes, nail
18:51 < mnemoc> :)
18:52 < karasz> nail
18:56 < rxr> debugging the binutils linker is not much fun
18:58 < karasz> who the heck named that nail......?
18:59 < mnemoc> Author: Gunnar Ritter
18:59 < karasz> try to google it...
18:59 < mnemoc> but a symlink is needed
18:59 < mnemoc> http://nail.sourceforge.net
19:00 < karasz> nah, try to google for information...
19:00 < karasz> and scope it out from nail careing or cuttin or cosmetics...
19:00 < mnemoc> :)
19:01 < karasz> root@expertweb:~# nail root
19:01 < karasz> Subject: aaa
19:01 < karasz> EOT
19:01 < karasz> /usr/lib/sendmail: No such file or directory
19:01 < karasz> "/root/dead.letter" 9/199
19:01 < karasz> . . . message not sent.
19:01 < karasz> /usr/lib/sendmail?
19:02 < karasz> could that be the missing link?
19:02 < karasz> even symlink? ;)
19:03 < mnemoc> outch
19:03 < mnemoc> that needs a patch
19:03 < mnemoc> but yes, symlink it
19:03 < karasz> to qmail-what? send?
19:03 < karasz> or even the sendmail in qmail?
19:03 < mnemoc> nope, /usr/bin/sendmail
19:04 < karasz> k
19:04 < karasz> said EOT and exited...
19:05 < mnemoc> what qmail-start said about it?
19:05 < karasz> delivery 3: failure: Sorry,_no_mailbox_here_by_that_name._(#5.1.1)/
19:05 < karasz> status: local 0/10 remote 0/20
19:05 < karasz> triple bounce: discarding bounce/125922
19:05 < karasz> end msg 125922
19:06 < karasz> sorry
19:06 < karasz> new msg 125922
19:06 < karasz> info msg 125922: bytes 1401 from <#@[]> qp 1058 uid 26
19:06 < karasz> starting delivery 3: msg 125922 to local postmaster@expert-software.ro
19:06 < karasz> status: local 1/10 remote 0/20
19:06 < karasz> delivery 3: failure: Sorry,_no_mailbox_here_by_that_name._(#5.1.1)/
19:06 < karasz> status: local 0/10 remote 0/20
19:06 < karasz> triple bounce: discarding bounce/125922
19:06 < karasz> end msg 125922
19:07 < mnemoc> you forgot to configure the aliases
19:07 < karasz> in qmail/control?
19:07 < mnemoc> rtfm? :(
19:17 < misl> mnemoc: I think I merged all LIBTOOL QUIRKs now, although some need manual adjustion (got merge let and right files).
19:17 < misl> Now I have to build them all
19:18 < mnemoc> good luck :D
19:19 < misl> I already did a fresh reference build today. But I got more failures than I had yesterday :(
19:20 < misl> So I decided to first merge then all and then rebuild again.
19:21 < rxr> now I know why the #t2 irc log is that big each day ,-)
19:21 < rxr> #t2 supporting the World ,-)
19:21 < misl> rxr: uhh?
19:21 < rxr> misl: not you ,-)
19:23 < misl> rxr: that Iliad company (http://www.irextechnologies.com/shop/products/iliad.htm) is very sparse with information. They want me to wait till the introduction. They claim to already have some sort of a development kit. :(
19:24 < rxr> :-((
19:24 < misl> If they are not too expensive I might get me one when it is introduced :)
19:24 < rxr> misl: convince them to become an early adaptor ?
19:26 < mnemoc> rxr: that's why google love us
19:26 < misl> maybe I should try phoning them instead of e-mail.
19:26 < rxr> misl: ack
19:26 < misl> mnemoc: google loves ubuntu more :(
19:27 < mnemoc> misl: divide the love for the amount of users
19:27 < rxr> huh
19:27 < mnemoc> who wins?
19:27 < rxr> find_potential_libraries = 0,
19:27 < rxr> hm
19:27 < rxr> wonders if that is righht
19:27 < misl> mnemoc: How did google show its love to us?
19:29 < mnemoc> misl: 1) asking things to it and seen at top 10 answers most of the time
19:29 < mnemoc> misl: 2) pagerank
19:30 < rxr> mnemoc: our page rank is not really high unfortunatly ... :-(((
19:30 < rxr> not yet ,-)
19:30 < rxr> but indeed why appear often in the queries ...
19:30 < rxr> sometimes too often
19:30 < rxr> I search for solutions and only find my own pastes from the channel ... X-(
19:30 < misl> google t2 + linux top rank gives
19:30 < misl> http://linux.softpedia.com/get/System/Operating-Systems/Linux-Distributions/T2-Linux-2049.shtml
19:31 < misl> 188 downloads
19:32 < rxr> who feeds that site ?
19:33 * misl wondering too
19:34 < misl> Uhh? who or what is that?
19:34 < misl> http://lists.matureasskickers.net/pipermail/t2servers/2004-February/000148.html
19:36 < rxr> hopefully one of the "more users than we think" ,-)
19:36 < mnemoc> :)
19:37 < misl> rxr: what is this?
19:37 < misl> http://www.exactcode.de/products/drock/index.html
19:38 < misl> rxr: this line is cool
19:38 < misl> Last modified: _2004-10-18_ 13:42 Copyright © 2003 - _2005_
19:39 < mnemoc> autogenerated
19:40 < misl> mnemoc: still funny
19:40 < mnemoc> :)
19:40 < rxr> hm - this binutils patch search stuff seems to be longer broken
19:40 < rxr> appears also on an older plain i386 build
19:41 < rxr> T2 SDE 2.2.0-alpha (2005/08/10) - 20051102
19:41 < rxr> well *older*
19:41 < rxr> in t2 time measurement that is ,-)
19:42 < rxr> huh
19:42 < rxr> ROCK Linux 2.0.1 (2004/03/13)
19:42 < rxr> there it does not work as well
19:42 < rxr> f*ck
19:42 < misl> rxr: is this page still valid?
19:42 < misl> http://www.exactcode.de/products/drock/index.html
19:42 < misl> otherwise you might redirect it to t2. This link is the second entry when googling for "linux t2"
19:43 < rxr> misl: no this page is rotting
19:43 < rxr> due too many wild bugs in the open source world I have to hunt
19:43 < rxr> and ti should be renamed to exactdesktop or wo anyway ,-)
19:43 < rxr> not drock
19:44 < misl> I am just worried that searching for t2 ends up in a link to drock
19:44 < rxr> there was a time when this /etc/ld.so.conf lookup worked ...
19:44 < rxr> darn
19:47 < rxr> ROCK Linux 1.7-snapshot (2003/02/07)
19:47 < rxr> no luck eitgher
19:47 < rxr> either
19:47 < rxr> damn
19:47 < rxr> am I halucinating
19:47 < rxr> I'm so damn sure this worked - yet I can not find a system where it in fact does work
19:47 < rxr> grummeled
19:48 < misl> oh o. earlier I read something that rxr knows what drugs are available in Berlin and now he is halucinating.
19:48 * misl wonders what mushrooms he ate
19:49 < misl> :)
19:49 < rxr> r5206 | rene | 2004-12-24 00:02:52 +0100 (Fri, 24 Dec 2004) | 6 lines
19:49 < rxr> at that time I patched binutils
19:49 < rxr> and I'm damned sure it worked at that time
19:57 -!- madtux [i=miguel@pf0.hostarica.com] has joined #t2
19:57 < madtux> hi.
19:57 < misl> hi maddy :)
19:58 < rxr> moin miguel ,-)
19:58 < madtux> minty :)
19:58 < madtux> gday rene
19:58 < rxr> madtux: recently we discussed most probably to rm -rf the router target due to rotting and far superiour embedded target "technology"
19:58 < rxr> madtux: do you have some vote for this decision ?
19:59 < madtux> go ahead.
19:59 < rxr> heeh - ic ,-)
19:59 < madtux> i must admit router target is rather obsolete at this point.
19:59 < morfoh> madtux: hi pyrotux :)
19:59 < madtux> hey morfoh .... so did the neightboors shutup on their own or u followed my advice?
20:00 < morfoh> madtux: good that you say that, we didn't noticed that the router target is obsolete :p
20:00 < madtux> rxr, do u still have that Sun Monitor to give away?
20:00 < rxr> madtux: yes, why ?
20:00 < rxr> i hope you do not want me to ship it to .cr ...
20:00 < rxr> do you know someone in .de or .eu ?
20:00 < madtux> i have a friend who might want.
20:01 < rxr> in which pixel of the world ?
20:01 < madtux> i will talk to him and if he still needs one will have him contact you.
20:01 < morfoh> madtux: nope ... I decided not to burn my neighbors but I had to go downstairs because they played heavy metal at 5:30 or so
20:01 < madtux> rxr, augsburg.
20:01 < rxr> madtux: ah ,-)
20:01 < madtux> morfoh, heavy metal :) nice.
20:01 < rxr> madtux: they get a for free, but best exchanged at some fair or so ...
20:01 < misl> ahh, klamottenkiste
20:01 < rxr> since it is not really worth the shipping
20:02 < madtux> i like ur neightboors.
20:02 < madtux> rxr, yeah sure.
20:02 < morfoh> madtux: but not if you want to sleep and the music is directly beneath your head
20:02 < madtux> morfoh, sleeping is for the birds.
20:03 < morfoh> madtux: ic ... you want some problems today :p
20:03 < misl> morfoh is a bird sitting on two eggs :)
20:03 < morfoh> madtux: I mean ... I don't wonder because you're mostly looking for trouble :)
20:03 < mnemoc> one and a half
20:03 < morfoh> mnemoc: how do you know ?
20:03 < misl> :D
20:03 < mnemoc> you told me
20:04 < mnemoc> during your last crisis
20:04 < morfoh> mnemoc: I doubt that
20:04 < morfoh> mnemoc: whaaaaaaaaaaaaaaaat ?
20:04 < morfoh> ok ... I found a second person who is looking for trouble
20:05 < morfoh> I even have some better weapons against the second one
20:05 < mnemoc> you told me you were zoofilic-ing your rat and he bite one of your eggs
20:05 < morfoh> so madtux ... you can feel a bit more comfortable
20:05 < morfoh> mnemoc: nope ... that must been your "rat"
20:05 < madtux> morfoh, hehe
20:05 < morfoh> mnemoc: while you were dreaming
20:05 < misl> ladies and gentlemen, please place you bets
20:06 < madtux> what are the odds ?
20:06 < misl> in the blue corner we have raging morfoh
20:06 < morfoh> misl: and after I "inhaled" mnemoc I'll continue with you :p
20:06 < mnemoc> i don't have any rat, you do. and i'm married, you live with a rat
20:06 < misl> and in the red corner we have the might mnemoc
20:07 < misl> +y
20:07 < misl> poor rat :)
20:07 < mnemoc> ack
20:07 < mnemoc> poor rat living with nasty morfoh
20:07 < morfoh> ok ... I think I've no friends here anymore
20:07 < mnemoc> outch
20:08 < madtux> morfoh, u are still my friend.
20:08 < misl> that hurts :(
20:08 < mnemoc> almost like a rat biting your egg
20:08 < misl> hehe
20:08 < morfoh> misl: ic how it hurts you
20:08 < misl> oeps sorry morfoh
20:09 < misl> how?
20:09 * misl peeks into his webcam
20:10 < morfoh> mnemoc: you should better take care, because the rat will bite away some more important thing than your eggs in the near future :p
20:11 < mnemoc> i'll not expose my important things in front of the rat as you do :)
20:11 < madtux> mnemoc, you've actually seen it?
20:11 < madtux> *G*
20:11 < morfoh> ok ... you don't have to expose it anyway ... :p
20:11 < mnemoc> madtux: fortunely not yet
20:12 < morfoh> .oO( that's not fair ... )o
20:13 < mnemoc> morfoh: unfair is what madtux makes his dog to do
20:14 < morfoh> mnemoc: I don't want to know what he is doing with his dog
20:15 < madtux> I don't have dogs anymore... my wife kept them :(
20:15 < mnemoc> the worse part is that he sent me a picture o_O
20:15 < morfoh> madtux: you were married ?
20:16 < mnemoc> madtux: so go an get a new one
20:17 < madtux> morfoh, yes i was.
20:17 < morfoh> rxr: was the dietlibc fix you commited today solving the mnemosyne on 2.2 issue ?
20:17 < madtux> mnemoc, too soon to have anything besides my computers to create an emotional link with
20:18 < morfoh> madtux: but I guess you "burned" that poor woman :p
20:19 < madtux> morfoh, no. but lets not talk about this topic. i'm rather sensitive about it.
20:19 < madtux> Lets talk about that time that mnemoc socked off a horse
20:19 < mnemoc> madtux: go and get one. dogs are loyal.
20:20 < morfoh> madtux: I'm sorry
20:20 < madtux> morfoh, no problem. u didn't know
20:20 < morfoh> mnemoc: a horse ?
20:20 < morfoh> ouch ...
20:21 < rxr> morfoh: yes
20:21 < madtux> morfoh, this mnemoc guy can be nastry.
20:21 < mnemoc> :(
20:21 < morfoh> rxr: cool ... thanks :)
20:21 < rxr> morfoh: but for bootup /dev/cdrom I would recomment another cdrom rule that works without this cdrom_id helper
20:21 < rxr> morfoh: thus HEAD will not make mnemosyne work I think
20:21 < rxr> but a additional one line rule tweak would
20:21 < mnemoc> the only thing i have done with horses is playing polo when i was a kid
20:21 < rxr> I can commit in half an hour
20:22 < rxr> but I be off to susan in some minutes
20:22 < morfoh> rxr: I'll produce a new ISO for you ;)
20:22 < rxr> morfoh: nah
20:22 < morfoh> hehe ... *evil*
20:22 < rxr> not with that needed one line rule
20:22 < morfoh> rxr: just kidding ...
20:23 < morfoh> rxr: greetings to susan :)
20:26 < morfoh> mnemoc: checking for Xinerama support on XFree86... yes
20:26 < morfoh> checking Pango flags... configure: error:
20:26 < morfoh> *** Pango not found. Pango built with Cairo support is required
20:26 < morfoh> *** to build GTK+. See http://www.pango.org for Pango information.
20:26 < morfoh> mnemoc: gtk+ on mnemosyne 2.2
20:27 < mnemoc> morfoh: cairo and pango suppose to be there
20:28 < morfoh> # cat target/mnemosyne/pkgsel/Desktop/10-gtk.ask
20:28 < morfoh> #Description: GTK+
20:28 < morfoh> #Dependencies: X!=none
20:28 < morfoh> X gtk+
20:28 < morfoh> X pango
20:28 < morfoh> X glib
20:28 < morfoh> X pkgconfig
20:28 < morfoh> X atk
20:28 < morfoh> # and C++ bindings
20:28 < morfoh> X libsigc++
20:28 < morfoh> X glibmm
20:28 < morfoh> X gtkmm
20:29 < mnemoc> it's on X module iirc
20:30 < morfoh> oh
20:30 < mnemoc> .conf, because it's dynamic (2.2 only)
20:33 < morfoh> mnemoc: did you committed the cairo related changes ?
20:34 < morfoh> ah! there ...
20:34 < morfoh> damn I cannot read anymore :(
20:35 < _Ragnar_> what was the option to build the additional kernel modules only again? >.<
20:39 < mnemoc> _Ragnar_: grep DEBUG package/*/linux*
20:39 < mnemoc> _Ragnar_: grep DEBUG package/*/linux*/*
20:41 < morfoh> mnemoc: gtk+ found pango after rebuilding cairo and pango
20:42 < morfoh> ;)
20:47 < mnemoc> morfoh: prio order?
20:55 < _Ragnar_> mnemoc: thx didn't work tho >.>
20:56 < mnemoc> _Ragnar_: what?
20:56 < _Ragnar_> putting export SDEDEBUG_LINUX_SUBMODULES_ONLY='1'
20:57 < _Ragnar_> in my config
20:57 < mnemoc> not there
20:57 < mnemoc> export SDEDEBUG_LINUX_SUBMODULES_ONLY=1
20:58 < mnemoc> Build-Target
20:58 < _Ragnar_> duh
20:58 < mnemoc> or Emerge-Pkg
20:58 < mnemoc> config file is generated
20:58 < mnemoc> anything you hardcode there will disappear
21:04 < _Ragnar_> still don't honor the option tho
21:04 < mnemoc> ??
21:05 < _Ragnar_> still builds all the kernel
21:05 < jsaw> re
21:05 < mnemoc> don't you get some warnings in regard to SDEDEBUG_* ?
21:05 < mnemoc> wb jsaw
21:05 < _Ragnar_> those I get
21:05 < jsaw> hi mnemoc
21:05 < jsaw> SDEDEBUG_ what?
21:05 < jsaw> what warnings?
21:05 < _Ragnar_> but linux26 still merrily compiles everything
21:06 < mnemoc> jsaw: that was for _Ragnar_
21:06 < mnemoc> _Ragnar_: it configure it self, but build only postlinux.conf-s
21:07 < morfoh> wb jsaw
21:07 < _Ragnar_> ok
21:08 < jsaw> hi morfoh
21:08 < CIA-9> jsaw * r15333 /trunk/misc/target/functions.in:
21:08 < CIA-9> * in copy_and_parse_from_source, parse also "#!/*"
21:08 < CIA-9> -> then do chmod +x
21:08 < jsaw> hi _Ragnar_
21:09 < _Ragnar_> hi jsaw :)
21:09 < jsaw> rxr: workaround for libtool stupidity in binutils...?
21:12 < jsaw> rxr: is LIBPATH_SUFFIX really used outside the build tree in binutils???
21:14 < jsaw> mnemoc: on install disk, runit-shutdown's "killall5" says "killall5 is not implemented"
21:15 < mnemoc> jsaw: yes, i haven't implemented it yet :(
21:15 < jsaw> har har...
21:15 < mnemoc> would you?
21:16 < jsaw> nope... too many other things to fix...
21:16 < mnemoc> :\
21:17 < CIA-9> jsaw * r15334 /trunk/target/install/init:
21:17 < CIA-9> * create {console,null,zero} nodes
21:17 < CIA-9> * if no /dev/{cdrom*,floppy*}, try detecting based on
21:17 < CIA-9> sysfs' "removable" file (/sys/block/*/removable)
21:18 < mnemoc> jsaw: /dev/tty !
21:18 < mnemoc> jsaw: needed by 'kiss'
21:18 < jsaw> nope, done by udevstart, currently
21:19 < mnemoc> not here
21:19 < jsaw> but as you know...
21:19 < jsaw> udevstart is going to be replaced...
21:19 < mnemoc> it was
21:19 < jsaw> mnemoc: not on your sys?
21:19 < mnemoc> 084 doesn't include it
21:19 < jsaw> we don't have 084 yet ;)
21:19 < mnemoc> :)
21:20 -!- misl [n=chatzill@82-217-66-150.cable.quicknet.nl] has quit ["Chatzilla 0.9.69.3 [Firefox 1.5.0.1/2006011112]"]
21:20 < mnemoc> until nasty-baldzius decide to commit it :)
21:21 < jsaw> then he is obliged to fix all init scripts :]
21:22 < mnemoc> hehe
21:24 < jsaw> mnemoc: why don't you simply copy sysvinits killall5.c ?
21:24 < mnemoc> jsaw: it's not that simple
21:25 < jsaw> why not?
21:25 < mnemoc> it depends on other ugly .c files iirc
21:25 < jsaw> no
21:26 < jsaw> gcc killall5.c
21:26 < jsaw> -> a.out
21:26 < mnemoc> :)
21:26 < jsaw> and GPL...
21:28 < mnemoc> i'll have to add some priority to the next release of runit-shutdown
21:28 < mnemoc> pidof is also important to have
21:38 < jsaw> ln -sf ../sbin/killall5 $(ROOT)/bin/pidof
21:38 < jsaw> :)
21:39 < mnemoc> i know :)
21:40 < mnemoc> but i guess i'll do it based on psgrep as the others
21:46 < CIA-9> amery * r15335 /trunk/package/editors/pida/pida.desc: * updated pida (0.3.0 -> 0.3.1)
21:51 < _Ragnar_> >.<
21:52 < _Ragnar_> def doesn't work mnemoc
21:52 < _Ragnar_> fuck fuck fuck
21:52 < mnemoc> uhm
21:54 < _Ragnar_> can I at least make the kernel FAIL when the module does instead of erasing all traces of what went wrong on 'successful' build?
21:55 < mnemoc> i hope to, let me watch
21:55 < mnemoc> that 'tolerant' kernel build doesn't like me much
21:57 < _Ragnar_> it needs an OFF switch :)
21:57 * _Ragnar_ inserts a sleep 800000
21:57 < _Ragnar_> bbl lunch :)
21:59 < mnemoc> _Ragnar_: Build-Pkg -noclearsrc
22:31 < morfoh> re
22:32 < mnemoc> wb morfoh
22:32 < morfoh> hehe ... thx mnemoc :)
22:33 < morfoh> my mnemosyne 2.2 target already finished :)
22:33 < mnemoc> :)
22:33 < morfoh> but still have to download it :/
22:33 < morfoh> mnemoc: it's quite fat
22:33 < mnemoc> :(
22:34 < morfoh> with full X stuff and ...
22:34 < mnemoc> azazel?
22:34 < morfoh> and I couldn't resist to include e17
22:34 < morfoh> ;)
22:34 < mnemoc> ezazel :p
22:34 < morfoh> nope ... normal mnemosyne
22:34 < morfoh> sorry ;)
22:35 < mnemoc> take a look into azazel-only modules
22:35 < mnemoc> you could want some of those
22:35 < morfoh> but ezazel sounds nice :)
22:35 < morfoh> yeah ... thanks :)
22:35 < morfoh> I'll take a look
22:36 < mnemoc> btw, i have: http://www.rafb.net/paste/results/MV1enx86.html here.... but i'm not sure if it's needed
22:37 < morfoh> but why does it have runit-logacct then ?
22:37 < morfoh> hmmm ?
22:38 < mnemoc> for the fun of making inird more fat :p
22:38 < morfoh> hehe ... yeah ... fat is nice :p
22:52 < CIA-9> amery * r15336 /trunk/package/contrib/freedt/freedt.desc: * updated freedt (0.20 -> 0.21)
23:08 < morfoh> 2006-02-06: rshd privilege escalation vulnerability
23:08 < morfoh> The rshd server in Heimdal has a privilege escalation bug when storing forwarded credentials. The code allowes a user to overwrite a file with its credential cache, and get ownership of the file. 0.7.2 and 0.6.6 fixes this problem. The only workaround for this bug is to disable the rshd server program.
23:09 < morfoh> mnemoc: I'll update heimdal on trunk
23:09 < mnemoc> good luck
23:10 < morfoh> why ? any known issues ? but thanks :)
23:10 < morfoh> mnemoc: we have 0.6.3 on 2.1
23:10 < mnemoc> i guess i'll have to start a reference with updated heimdal soon
23:11 < morfoh> mnemoc: I can also update it to 0.6.6 and start a ref
23:12 < mnemoc> with heimdal enabled?
23:12 < morfoh> why not ?
23:12 < morfoh> we have to ... if we wanna do a regression test for it ;)
23:13 < morfoh> or is ther sth. I should know regarding a ref build with heimdal enabled ?
23:14 < mnemoc> of course
23:14 < mnemoc> i just asked
23:14 < mnemoc> because i haven't done that in almost a year
23:14 < morfoh> mnemoc: doing a ref build once a year is quite ok :p
23:15 < mnemoc> with heimdal :p
23:15 * mnemoc moving home
23:16 < morfoh> cu mnemoc ;)
23:17 < morfoh> mnemoc: as usual ... drive save :)
23:17 < morfoh> no stunts
23:26 < morfoh> Baldzius: gun boy around ?
23:26 < Baldzius> yep .. what happened? :)
23:27 < morfoh> sqlite --> 2006-Jan-31 - Version 3.3.3 stable ... have you seen this ? should we update or is there any reason to do not ?
23:27 < morfoh> ;)
23:29 < morfoh> Baldzius: just wanted to ask our master update robot :)
23:29 < Baldzius> don't know, i was runing ref build already when it was released so i cant test it now
23:29 < Baldzius> but you can update if you want :)
23:30 < morfoh> Baldzius: I've no problem with updating it :)
23:30 < Baldzius> good :)
23:33 < morfoh> hehe :)
23:42 < CIA-9> chris * r15337 /trunk/package/database/sqlite/sqlite.desc: * updated sqlite (3.2.8 -> 3.3.3)
--- Log closed Tue Feb 07 00:00:40 2006