T2 IRC Log: 2009-01-05

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.

« prev | next »

--- Log opened Mon Jan 05 00:00:05 2009
00:43 -!- wtracy [n=wtracy@natusers1.stennerglenstudents.com] has quit [Remote closed the connection]
00:59 -!- wtracy [n=wtracy@natusers1.stennerglenstudents.com] has joined #t2
01:30 -!- synchris [n=synchris@ppp-94-65-175-154.home.otenet.gr] has quit [Read error: 110 (Connection timed out)]
01:31 -!- synchris [n=synchris@ppp-94-65-146-15.home.otenet.gr] has joined #t2
02:10 -!- gw [n=gw@2001:44b8:62:7f0:21b:63ff:fe01:f18d] has quit ["Leaving"]
02:19 -!- wtracy [n=wtracy@natusers1.stennerglenstudents.com] has quit [Remote closed the connection]
03:11 -!- synchris [n=synchris@ppp-94-65-146-15.home.otenet.gr] has quit [Remote closed the connection]
07:12 -!- wtracy [n=wtracy@natusers1.stennerglenstudents.com] has joined #t2
08:35 [Users #t2]
08:35 [@ChanServ] [ dsoul] [ LMJ ] [ mtr] [ Stealth] [ wtracy ]
08:35 [ CIA-22 ] [ koan ] [ mqueiros_] [ rxr] [ TobiX ] [ |beowulf|]
08:35 -!- Irssi: #t2: Total of 12 nicks [1 ops, 0 halfops, 0 voices, 11 normal]
09:17 < CIA-22> rene * r31695 /trunk/package/emulators/kvm/07-qemu-macmodel.patch: * converted kvm/07-qemu-macmodel.patch to use C99 initializers
09:43 -!- wtracy [n=wtracy@natusers1.stennerglenstudents.com] has quit [Remote closed the connection]
09:53 -!- mpp [n=chatzill@alpha695.server4you.de] has joined #t2
09:53 < mpp> moin moin
09:59 -!- wtracy [n=wtracy@natusers1.stennerglenstudents.com] has joined #t2
10:00 < rxr> moin moin mpp
10:19 < CIA-22> rene * r31696 /trunk/package/textproc/iso-codes/iso-codes.desc: * updated iso-codes (3.5 -> 3.5.1)
10:22 < CIA-22> rene * r31697 /trunk/package/graphic/libraw/libraw.desc: * updated libraw (0.6.4 -> 0.6.5)
10:22 < CIA-22> rene * r31698 /trunk/package/perl/perl-extutils-pkgconfig/perl-extutils-pkgconfig.desc: * updated perl-extutils-pkgconfig (1.11 -> 1.12)
10:22 < CIA-22> rene * r31699 /trunk/package/mail/postfix/postfix.desc: * updated postfix (2.5.5 -> 2.5.6)
10:25 < CIA-22> rene * r31700 /trunk/package/develop/git/git.desc:
10:25 < CIA-22> Martin Papadopoulos :
10:25 < CIA-22> * updated git (1.6.0.6 -> 1.6.1)
10:38 < CIA-22> rene * r31701 /trunk/package/base/busybox/busybox.desc: * updated busybox (1.13.1 -> 1.13.2)
10:40 < CIA-22> rene * r31702 /trunk/package/filesystem/libburn/libburn.desc: * updated libburn (0.5.8.pl00 -> 0.6.0.pl00)
10:41 < mtr> moin
10:41 < mpp> moin mtr
10:42 < mtr> hi mpp
10:42 < rxr> hi mtr
10:42 < mpp> has anyone built the kernel 2.6.28 on trunk successfully ?
10:42 < rxr> happy new year mtr
10:43 < mpp> the aufs and r8169 patches fail on my side
10:43 < rxr> (the one who updated it?)
10:43 < mpp> that would be .... rxr :-) ?
10:43 < rxr> nope :-)
10:43 < rxr> I usually wait for the llinux26 upodate for at least the .1 or .2 to be out :-)
10:43 < mpp> right ...
10:43 < mpp> makes sence
10:44 < rxr> (and saves workload porting third party add-ons myself, and rely on the upstream teams to do so :-)
10:44 < mpp> yeah k
11:59 < mtr> hmm, I do not agree to your delayed kernel update strategy
11:59 < mtr> .1 or .2 always have been minor fixes only
12:00 < mtr> and didn't help failing third party modules
12:06 < mtr> mpp: in general 2.6.28 builds and runs fine
12:07 < mtr> mpp: you're right, the aufs module fails, but the r8169 patch is no longer necessary and was removed with the update .28, changeset v31651
12:08 < rxr> mtr: well most latest major kernels had major breakage, and the .1 / .2 time allows third party stuff to update
12:09 < rxr> mtr: but I don't care just update as early as you like :-)
12:09 < rxr> mtr: I just use the former versions during that time :-)
12:09 -!- mqueiros_ [n=mqueiros@217.70.71.72] has quit [Client Quit]
12:10 < mtr> yes, we talk about trunk:HEAD, and only have been more restrictive for the stable branch
12:11 < mtr> ... in the past
12:13 < mtr> already some days ago it came to mind that it might be good to have a new recent stable branch
12:13 < mtr> maybe to branch off 7.1 from trunk now ... ?
12:15 < mtr> this might help to fix a lot of build errors, to clean up the kde3 things for example
12:20 < mpp> is the aufs used e.g in the rescue target ?
12:20 < mpp> if i don't need it - i would rather kick it out of my local repo to get the building done
12:22 < rxr> aufs is the better, lightwight etc. unionfs
12:22 < rxr> it is supost to be the default for the live initrd setup
12:22 < rxr> aufs cleaner and less code to work with and usually more stable etc. and quicker updates to new kernels
12:25 < mpp> k so until aufs works i'll stick with 2.6.27.10
12:25 < mpp> i need the rescue target to build
12:31 < rxr> sometimes despite major changes such third party stuff is patchable within 30m or so to build again
12:32 < rxr> (+/- locally available skills)
13:28 < mtr> we still have two obsolete wifi drivers, since .24 in mainline:
13:28 < mtr> ipw3945 and at76c503a
13:28 < rxr> svn rm
13:29 < mtr> ok
13:31 < CIA-22> mtr * r31703 /trunk/package/network/ipw3945/:
13:31 < CIA-22> * remove obsolete ipw3945 driver package: chipset support is
13:31 < CIA-22> covered by mainline iwlwifi driver
14:11 < koan> rxr: I have this error building t2 trunk on Debian Lenny: http://www.mail-archive.com/t2@t2-project.org/msg00845.html
14:15 < koan> it's in util-linux in stage 1
14:36 < rxr> hm
14:46 < koan> I see you have already encountered this error in an earlier version, apparently it has reappeared
14:51 < rxr> strange
14:51 < rxr> I belive you can successful continue the build in any case by touching the associated log file
14:51 < rxr> (the package will be build natively in stage 5)
14:52 < koan> ok I'll try
16:20 -!- wtracy [n=wtracy@natusers1.stennerglenstudents.com] has quit [Remote closed the connection]
16:34 -!- mpp [n=chatzill@alpha695.server4you.de] has quit ["ChatZilla 0.9.84 [Firefox 3.0.4/2008111317]"]
18:15 -!- mpp [n=mpp@i538742B4.versanet.de] has joined #t2
19:38 < rxr> mpp: regarding your ntpd change to set the time first
19:38 < rxr> can't we just use one invocation with -g, and without the -q (which is quit immediately)
19:38 < rxr> so ntpd -g -c ... ?
19:38 < rxr> (which is actually like OS X runs it :-)
19:39 < rxr> 14 ?? Ss 0:00.64 /usr/sbin/ntpd -n -g -p /var/run/ntpd.pid -f /var/db/ntp.drift
19:39 < rxr> ^- OS X
19:53 < mpp> ahm actually no
19:53 < mpp> as far as i read the docs
19:53 < mpp> hold on a sec
19:54 < mpp> sorry - the -q option was only recommended
19:54 < mpp> i think we could remove the -q
19:55 < rxr> would you have a second and a spare box / VM to mis-set the clock and review if just a single invocation with -g has the effect you wanted ?
19:55 < mpp> ill do so right away - ill report or send mail to the list :-)
19:56 < rxr> :-)
19:57 < mpp> the man page says that if a second glitch occurs beyond the 1000s limit the daemon exit's anyway.
19:58 < mpp> so i see no pratical reason for heaving the -q . i just copied that from other distro scripts .
20:00 < mpp> okay so the practical reason is simple - if we don't set the time once sane and exit - the nptd daemon takes a long time to adjust the clock drift.
20:00 < mpp> this could take up to 10 maybe 15mins
20:01 < mpp> so all processes are having 'false' timestamps.
20:01 < mpp> adjusting the clock once and quiting seems reasonable
20:01 < mpp> but i guess this is to decide from case 2 case
20:01 < mpp> ?
20:02 < mpp> hm...
20:02 < mpp> i don't have a final decission ...
20:03 < mpp> but having the clock sanitized asap might be of importance to not disturb other processes
20:03 < mpp> i'll leave that up to you .
20:04 < rxr> if leaving out -q does not set the clock immediate then it makes sense to keep it
20:04 -!- synchris [n=synchris@ppp-94-65-146-15.home.otenet.gr] has joined #t2
20:04 < mpp> it takes a while - i just checked
20:05 < mpp> in a vm it could take far more than 15mins - probably a bad idea to leave the clock unsanitized for that long
20:05 < mpp> on my native host it took about 5 mins to make the first adj . etc utc stuff
20:06 < mpp> does it hurt to have it run twice ?
20:06 < mpp> on the vm it's still running the wrong time
20:08 < mpp> actually it would make sence to set init priority of ntpd more earlier
20:09 < mpp> but on the other hand clock drift and adjustment on a running system could cause probs anyways
20:09 < mpp> who knows for sure..
20:20 < mpp> rxr: maybe you can help me out with a small problem
20:21 < mpp> i have a programm that requires : libstdc++-libc6.2-2.so.3
20:21 < mpp> how can i build this old stuff on t2?
20:21 < mpp> i already tried the libstdc++ package but it's not the right library..
20:29 < rxr> we only have one backward compat version that is for older flash and acroread versions etc.
20:29 < rxr> no idea where that stdc++ verion is from
20:30 < rxr> you could create an other copy of the libstdc++ comat package using exactly that g++ package ...
20:30 < mpp> hm ....
20:30 < mpp> good idea
20:30 < mpp> is that g++2.2 ?
20:32 < mpp> gee . its 2009 and major hw manuf provide tools linked against those old lib's . no comment !
20:32 < mpp> :-(
20:37 < mpp> anyways - i'll drop the ldd output just in case someone has hint :
20:37 < mpp> http://pastebin.com/mde2f542
20:42 < rxr> hm
21:06 -!- mpp [n=mpp@i538742B4.versanet.de] has quit ["ChatZilla 0.9.84 [Firefox 3.0.3/2008092510]"]
21:16 -!- mqueiros [n=mqueiros@217.70.71.72] has joined #t2
21:35 -!- wtracy [n=wtracy@natusers1.stennerglenstudents.com] has joined #t2
23:09 -!- synchris [n=synchris@ppp-94-65-146-15.home.otenet.gr] has quit [Read error: 110 (Connection timed out)]
23:09 -!- synchris [n=synchris@ppp-94-65-146-15.home.otenet.gr] has joined #t2
--- Log closed Tue Jan 06 00:00:12 2009