T2 IRC Log: 2008-09-01

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 Sep 01 00:00:04 2008
00:05 -!- mqueiros [n=mqueiros@217.70.71.161] has joined #t2
09:47 < CIA-8> rene * r30294 /trunk/package/graphic/gle-graphics/gle-graphics.desc: * updated gle-graphics (4.0.12 -> 4.1.2b)
09:54 < CIA-8> rene * r30293 /trunk/package/gpe/blueprobe/ (blueprobe.desc install.patch): * updated blueprobe (0.18 -> 0.19)
09:56 -!- mpp [n=user@i53877E3C.versanet.de] has joined #t2
09:56 < mpp> good morning people :-)
09:57 < CIA-8> rene * r30290 /trunk/package/develop/ctalk/ctalk.desc: * updated ctalk (0.0.68a -> 0.0.69a)
09:57 < CIA-8> rene * r30289 /trunk/package/perl/perl-net-ldap/perl-net-ldap.desc: * updated perl-net-ldap (0.36 -> 0.37)
09:57 < CIA-8> rene * r30288 /trunk/package/emulators/yabause/yabause.desc: * updated yabause (0.9.6 -> 0.9.7)
09:57 < CIA-8> rene * r30287 /trunk/package/textproc/iso-codes/iso-codes.desc: * updated iso-codes (3.2 -> 3.3)
09:58 < CIA-8> rene * r30286 /trunk/package/python/pyrexc/pyrexc.desc: * updated pyrexc (0.9.8.4 -> 0.9.8.5)
10:23 -!- mpp_ [n=user@i53876743.versanet.de] has joined #t2
10:28 -!- mpp__ [n=user@i5387694F.versanet.de] has joined #t2
10:41 -!- mpp [n=user@i53877E3C.versanet.de] has quit [Read error: 110 (Connection timed out)]
10:44 -!- mpp_ [n=user@i53876743.versanet.de] has quit [Read error: 110 (Connection timed out)]
11:01 -!- mpp [n=user@i53876FAD.versanet.de] has joined #t2
11:01 < mpp> hey there
11:04 -!- mpp__ [n=user@i5387694F.versanet.de] has quit [Read error: 110 (Connection timed out)]
11:12 < mpp> .
11:12 < mpp> ge my dsl is up and down today
11:42 -!- Dallur [n=earl@fgfw.basis.is] has left #t2 []
12:17 -!- mqueiros [n=mqueiros@217.70.71.161] has quit []
12:21 -!- Baldzius [n=Baldzius@87.198.192.226] has joined #t2
12:21 < Baldzius> moin
12:23 < rxr> hi Baldzius
12:23 [Users #t2]
12:23 [@ChanServ] [ CIA-8 ] [ felanha] [ mpp ] [ rxr ]
12:23 [ axionix ] [ dsoul ] [ koan ] [ mtr ] [ TobiX]
12:23 [ Baldzius] [ Enqlave] [ LMJ ] [ Ragnarin]
12:23 -!- Irssi: #t2: Total of 14 nicks [1 ops, 0 halfops, 0 voices, 13 normal]
12:23 < Baldzius> hey rxr
12:23 < Baldzius> waz up?
12:24 < rxr> work .-)
12:40 < Baldzius> :)
13:03 < mpp> moin
13:04 < rxr> moin mpp
13:04 < mpp> so hows the weather in the office in berlin ?
13:04 < mpp> lol
13:04 < mpp> ;-)
13:05 < rxr> ok and warmer than the last colder days, except sunday was warm already, likewise
13:05 < rxr> and yours ?
13:06 < mpp> nice and chilly
13:07 < rxr> .-)
13:08 < mpp> ill grab some kaffeine
13:09 < rxr> :-)
13:13 < mpp> hm... lecker
13:14 < rxr> lol
13:15 < mpp> yep
13:15 < mpp> so the t2-project is getting hughe and package maintenance consumes alot of time
13:15 < mpp> yours actually
13:16 < rxr> not necessarily
13:16 < rxr> we have a nightly tracker mailing "potential" updates to the t2-updates mailing list
13:16 < mpp> ill read through the docs to see how packaging is done on t2
13:17 < rxr> form there it's only some light cut'n paste work to scripts/Update-Pkg, and a consecutive scripts/Create-ErrList -cfg reference -newremove ; scripts/Build-Target -cfg reference test build
13:17 < mpp> yeah i mean more in terms of automated building certain targets and see if they build clean
13:17 < mpp> thep Update-Pkg does what exactly..
13:17 < rxr> compared to the major jumps the Debian, Fedora et al. maintainer needs to do for an update that rather efficient work todo ..
13:17 < mpp> is it like Build-Target -job X-pkg
13:17 < rxr> it updates the package'.s, downloads the new file and patches in the new checksum
13:18 < mpp> okay
13:18 < rxr> it will not build it
13:18 < mpp> what about creating new packages
13:18 < mpp> ill have to read the docs today
13:18 < rxr> but some light janitor task help of also doing packages and/or hunting updates our auto-tracker does not find is welcome anytime .-)
13:18 < mpp> i have some packages id like to upstream to the source tree
13:19 < mpp> so thats todays task
13:19 < koan> how does your autotracker work? it scrapes the project's website?
13:19 < mpp> i came up with this issue cause generic minimal desktop has some packet build errors
13:20 < mpp> specially kde / qt4
13:20 < rxr> it checks the packages'd [D] tags files for files with a higher version
13:20 < mpp> sadly cause i love to build that one
13:20 < rxr> mpp: yes, trunk has still some KDE4/Qt4 polishing todo
13:20 < rxr> btw. KDE4.1 does not yet run for me, does not find any mime type, and thus does not even display a HTML site in Konqeroer
13:21 < rxr> (that worked at the time of KDE-4.0.2 or so ... really strange)
13:21 < rxr> did not yet had time to hunt that
13:21 < mpp> of course
13:21 < rxr> btw. the update tracker source lives in source/UpdateList.cc
13:21 < mpp> gui is kinda low priority for me anyways
13:21 < rxr> it's C++ from some "can we use C++ for parts of the build system experiement)=
13:21 < rxr> of course KDE-3 just works in our stable 7.0 series ...
13:22 < rxr> and when 8.0 is ready KDE4 will work, likewsie :-)
13:22 < rxr> so - cu - need some food
13:22 < mpp> mahlzeit ! :-)
14:18 -!- hwinkel [n=hwinkel@port-87-193-170-219.static.qsc.de] has joined #t2
14:45 < mpp> back again :-)
14:56 < mpp> hey rxr i could not find how the structure for a package directory should
14:56 < mpp> be - any docs on that ?
14:58 < rxr> it's mostly the .desc tag
14:58 < rxr> err tags in the .desc file
14:59 < rxr> http://www.t2-project.org/handbook/html/t2.package.html
15:05 < Baldzius> rxr: svn is down
15:05 < mpp> funny thing about ntpd - i have this package build in the rescue target
15:06 < mpp> on the running rescue i need to make ldconfig before because of some .so library
15:07 < rxr> .oOhm
15:07 < rxr> [Mon Sep 01 15:06:39 2008] [error] [client 192.168.2.3] (20014)Internal error: Berkeley DB error for fil
15:07 < rxr> esystem '/home/svn/t2/db' while opening 'transactions' table:\nCannot allocate memory
15:09 < Baldzius> nice
15:09 < rxr> ouhm - whatever that was db recovered
15:11 < Baldzius> cool
16:00 < mpp> found the ldconfig
16:00 < mpp> issue
16:01 < mpp> binutils had to rebuilt to regenerate the ld.so.cache int the rootfs/etc/
16:01 < mpp> t2 makes u wanna dance :-)
16:05 < rxr> hm ?
16:05 < rxr> never had an issue with ldconfig and ld.so.cache what have you done ?
16:07 < mpp> i had the ntp package rebuild
16:07 < mpp> libreadline as dependency
16:07 < mpp> so the binutils package was already there
16:08 < mpp> so the ld.so.cache did not get refreshed in the build target
16:08 < mpp> but i solved it now
16:08 < mpp> i guess
16:08 < mpp> iam building thee rootfs
16:08 < mpp> as we speak
16:09 < mpp> hmm.
16:09 < mpp> it did make it to build/px.../etc but not to build/px.../TOOLCHAIN/rootfs/etc/
16:10 < mpp> the build/.../TOOLCHAING/rootfs is beeing refreshed right ?
16:11 < mpp> i guess i am missing something about the build process on that part.
16:11 < mpp> i don't exactly know how the initramfs is build
16:12 < mpp> i guess its from the build/xxx/ -> build/TOOLCHAIN/rootfs/
16:12 < mpp> but thats a guess
16:13 < mpp> hm..
16:13 < mpp> were does the ld.so.cache get build in the Build-Target process .. ?
16:13 < mpp> i gotta figure out ...
16:17 < rxr> in cross builds not at all, on native builds often after every package
16:18 < rxr> for image post processing it is usually also updated via ldconfig
16:18 < mpp> hmmm...
16:18 < mpp> seems like it does not...
16:19 < mpp> but when i started the build process for the target from scratch it did generate the ld.so.cache
16:20 < rxr> if you find a reproducable pattern let me know and I'll "fix" it :-)
16:22 < mpp> seems like only some packages do ldconfig
16:26 < mpp> question is :
16:27 < mpp> should the ld.so.cache file be present only in the runnig system or already in the TOOLCHAIN
16:27 < mpp> as i see it the 00-cron job does ldconfig
16:28 < mpp> the other fact is that the ld.so.cache file did not get refreshed in the running rescue machine
16:30 < rxr> ldconfig should be run in the t2 build already for native builds after a new .so was installed
16:31 < mpp> i agree
16:31 < rxr> it's historically also run in the nightly cronjob to make sure newly installed libraries, or auto-update libraries are in the cache
16:31 < mpp> so ill dig throug my build tree and see why it doesn't get rebuild
16:31 < mpp> is the TOOLCHAIN/rootfs build first or last ?
16:32 < mpp> i mean in the rescue target
16:32 < mpp> okay so heres news
16:32 < mpp> i just rebuild cron and the ld.so.cache did get generated on the target
16:35 < mpp> so the TOOLCHAIN/rootfs/etc did not get updated with the ld.so.cache
16:35 < mpp> how can i force the rootfs to be rebuilt ?
16:36 < rxr> the rootfs is build last
16:36 < rxr> you did rebuild cron with -job 5-cron ?
16:36 < mpp> i figured so
16:36 < mpp> no actually 3-cron
16:37 < mpp> its what the rescue target has as default package job level
16:44 < rxr> yeah - ok
16:44 < rxr> the -job stuff only rebuilds this single thing
16:44 < rxr> the image output is run only on the end of a full build
16:44 < rxr> so to re-build that you need to run Build-Target without any -job specifier
16:44 < mpp> ill check
16:44 < rxr> if there is nothing left to build, e.g. no package, like cron, than this will only re-build the rootfs / whatever image output after some seconds of tracking what to build
16:47 < mpp> okay Build-Target did not refresh the rootfs accordingly
16:50 < mpp> i wiped the rootfs and reBuild-Targett
16:50 < mpp> the rootfs is filled up again
16:50 < mpp> but without ld.so.cache
16:50 < mpp> this is funny
16:50 < mpp> what day is it
16:51 < mpp> 1.April ;-)
16:53 -!- n6pfk [n=urk@c-76-104-40-104.hsd1.va.comcast.net] has joined #t2
17:00 < mpp> looks like the ld.so.cache is in some kind of exclusion list at least thats what the /targate/share/initrd/build.sh suspects
17:03 < rxr> hm
17:04 < rxr> hm - ok - maybe it is not part of any package
17:04 < rxr> I think it is not explicitly skipped
17:04 < mpp> that could be
17:05 < mpp> what about the target/share/initrd/build.sh
17:05 < mpp> i mean thats the one which sync the rootfs
17:06 < rxr> yes
17:06 < mpp> and for a reason the ld.so.cache is not copie in that step
17:06 < mpp> allthoug it's pretty straightforward
17:06 < rxr> do you see that it is skipped there somewhere ?
17:07 < mpp> not in the scripts itself
17:08 < mpp> only thing that can happen is that the procedure generating the exclude list puts it on that one
17:08 < mpp> il digg into it
17:10 < mpp> there is aline
17:10 < mpp> with fox x in sbin/ldconfig
17:10 < rxr> as you can see ldconfig is run within the chroot
17:10 < rxr> that should generate the ld.so.cache
17:10 -!- n6pfk [n=urk@c-76-104-40-104.hsd1.va.comcast.net] has quit [Read error: 113 (No route to host)]
17:11 < rxr> maybe the rsync does not copy it and it is not in the "copy list" because the file is not tacked by T2 since it is a run-time file not belonging to any package
17:11 < rxr> but the chroot ldconfig should create it
17:11 < mpp> i agree so far
17:12 < mpp> the automake file does some things
17:12 < mpp> which don't look to create ld.so.cache
17:19 < mpp> btw a nice and easy tweak for speeding up build process somethin is to mount the ext3 filesystem with commit=120
17:25 < mpp> allright making progress
17:29 -!- Baldzius [n=Baldzius@87.198.192.226] has quit ["Leaving"]
19:46 -!- hwinkel [n=hwinkel@port-87-193-170-219.static.qsc.de] has quit [Connection timed out]
20:53 -!- mqueiros_ [n=mqueiros@217.70.71.161] has joined #t2
21:10 -!- |beowulf| [i=1014@sourcemage/mage/beowulf] has joined #t2
21:11 < |beowulf|> hi
21:18 -!- hwinkel [n=hwinkel@p54B6AE23.dip0.t-ipconnect.de] has joined #t2
23:40 -!- mpp [n=user@i53876FAD.versanet.de] has quit ["Ex-Chat"]
--- Log closed Tue Sep 02 00:00:09 2008