T2 IRC Log: 2008-10-03

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 Fri Oct 03 00:00:10 2008
08:51 < Ragnarin> who messed up pygtk? :P
08:53 < rxr> .oO
08:53 < rxr> maybe me in some random major gnome version bump ?
08:55 < Ragnarin> seems it's putting crap into /etc/profile.d/pygtk
10:26 < CIA-8> rene * r30672 /trunk/package/security/strongswan/strongswan.desc: * a little strongswan meta data text polishing
10:32 < CIA-8> rene * r30673 /trunk/package/graphic/babl/ (. babl.cache babl.desc): * added babl (0.0.22) - A dynamic, any to any, pixel format translation library
10:42 < CIA-8> rene * r30674 /trunk/package/base/sysvinit/system.init: * let udevsettle wait for /dev population in the initrd-less system fallback, likewise
10:49 < CIA-8> rene * r30676 /trunk/package/gnome2/gst-plugins-base/gst-plugins-base.desc: * updated gst-plugins-base (0.10.20 -> 0.10.21)
10:49 < CIA-8> rene * r30675 /trunk/package/python/gst-python/gst-python.desc: * updated gst-python (0.10.12 -> 0.10.13)
10:49 < CIA-8> rene * r30677 /trunk/package/gnome2/gstreamer/gstreamer.desc: * updated gstreamer (0.10.20 -> 0.10.21)
10:50 < CIA-8> rene * r30678 /trunk/package/gnome2/gkrellm/gkrellm.desc: * updated gkrellm (2.3.1 -> 2.3.2)
10:51 < CIA-8> rene * r30679 /trunk/package/network/mdnsresponder/mdnsresponder.desc: * updated mdnsresponder (107.6 -> 108.6)
12:05 -!- mpp [n=user@i538749B9.versanet.de] has joined #t2
12:32 < rxr> cu later
--- Log closed Fri Oct 03 12:32:24 2008
--- Log opened Fri Oct 03 13:13:05 2008
13:13 < rxr> rehi
13:31 < CIA-8> rene * r30680 /trunk/package/textproc/uni2ascii/ (. uni2ascii.cache uni2ascii.desc): * added uni2ascii (4.11) - A tool that converts between Unicode and various ASCII representations
13:41 < mpp> anyone already suffering from tcp sockstress dos ?
13:42 < rxr> i hope not :-)
13:42 < mpp> i hope so
13:42 < mpp> !
13:43 < mpp> it's time to demonstrate that what goes wrong - it's on us who invented it.
13:43 < mpp> could be fun
13:43 < mpp> poweroff@planet.earth
13:43 < mpp> :-)
13:43 < mpp> anyways
13:44 < mpp> rsync is still in progress rxr
13:44 < mpp> looks like it'l take a month or so for all the iso's synced
13:46 < rxr> I fear not
13:46 < rxr> we just exchanged the server hwardware
13:46 < rxr> hardware
13:46 < rxr> probably the rsync was just interrupted ..
13:46 < rxr> could you re-run :-)
13:46 < rxr> that is continue it :-)
13:46 < rxr> sorry
13:47 < rxr> but server hw update was overdue :-)
13:47 -!- mpp_ [n=user@i538742C3.versanet.de] has joined #t2
14:02 -!- mpp [n=user@i538749B9.versanet.de] has quit [Read error: 110 (Connection timed out)]
14:40 -!- mpp_ is now known as mpp
15:25 -!- koan [n=koan@unaffiliated/koan] has quit [Read error: 104 (Connection reset by peer)]
15:25 [Users #t2]
15:25 [@ChanServ] [ CIA-8 ] [ hikenboot] [ mtr ] [ Stealth]
15:25 [ axionix ] [ dsoul ] [ mpp ] [ Ragnarin] [ TobiX ]
15:25 [ bfg ] [ felanha] [ mqueiros_] [ rxr ]
15:25 -!- Irssi: #t2: Total of 14 nicks [1 ops, 0 halfops, 0 voices, 13 normal]
15:32 -!- koan [n=koan@unaffiliated/koan] has joined #t2
15:33 < rxr> http://www.spreadfirefox.com/
15:34 -!- koan [n=koan@unaffiliated/koan] has quit [Read error: 104 (Connection reset by peer)]
15:37 -!- koan [n=koan@unaffiliated/koan] has joined #t2
16:45 -!- koan [n=koan@unaffiliated/koan] has quit [Read error: 104 (Connection reset by peer)]
16:51 -!- koan [n=koan@unaffiliated/koan] has joined #t2
16:54 -!- koan [n=koan@unaffiliated/koan] has quit [Read error: 104 (Connection reset by peer)]
16:56 -!- koan [n=koan@unaffiliated/koan] has joined #t2
17:27 < rxr> hm - somehow the local modifications in my WC are only growing ... 401 modified added files, now ...
17:28 < CIA-8> rene * r30682 /trunk/scripts/functions.in: * log used cmake option as we do for other build styles
17:28 < CIA-8> rene * r30683 /trunk/package/contrib/rrdtool/rrdtool.conf: * fixed rrdtool to install the documentation into $docdir
17:28 < CIA-8> rene * r30681 /trunk/scripts/functions.in: * specify AS in the makeopts during cross build
17:47 < rxr> hm - our big box with openvz again deadlocked to death on some mount code path ...
17:47 < rxr> I guess I'm going to sheeld this crappy openvz code by running it in smaller kvm instances ...
17:48 < rxr> somehow this "patching every kernel entry code openvz piece of junk" is apparently not so trustworthy ...
18:18 < CIA-8> rene * r30684 /trunk/package/security/botan/botan.conf: * fixed botan to install documentaion into $docdir
18:25 < CIA-8> rene * r30685 /trunk/package/security/botan/botan.conf: * fixed botan to honor parts of $libdir (e.g. commonly lib64)
18:28 < CIA-8> rene * r30686 /trunk/package/textproc/libxml/libxml.conf: * fixed libxml not to pollute /doc and install into it's $docdir
18:32 -!- dsoul [i=darksoul@insomniac.pl] has quit [Read error: 113 (No route to host)]
18:39 < CIA-8> rene * r30687 /trunk/package/textproc/libxslt/libxslt.conf: * fixed libxslt to honor $docdir, likewise
18:40 < CIA-8> rene * r30688 /trunk/package/textproc/libxml/libxml.conf: * simplified libxml $docdir glue code
18:41 < mtr> bfg: docbookx build fine, but I haven't done a full rebuild, only re-scheduled changes pkgs with -newdelete
18:41 < mtr> bfg: docbookx only has a few deps in the cache file: 00-dirtree bash bzip2 coreutils diffutils gcc grep libxml sed sysfiles tar unzip
18:42 < mtr> bfg: does this match with yours?
19:00 < CIA-8> rene * r30689 /trunk/scripts/functions.in:
19:00 < CIA-8> * supply a global docdir variable to make, fixes a lot of packages
19:00 < CIA-8> not to install a versioned directory on their own guessing but
19:00 < CIA-8> honor what T2^W the target supplies (supplying --docdir= to
19:00 < CIA-8> configure does not work globally, as many configure script
19:00 < CIA-8> choke on it and if they don't, often doen#t honor it anyway)
19:05 < CIA-8> rene * r30690 /trunk/package/base/sysstat/sysstat.conf: * fixed sysstat to honor the $docdir
19:37 < CIA-8> rene * r30691 /trunk/package/graphic/imagemagick/ (docdir.patch imagemagick.conf): * fixed imagemagick to honor --docdir in configure and supply it
20:59 -!- dsoul [i=darksoul@insomniac.pl] has joined #t2
21:00 < felanha> rxr: is it possible that the python dl changed yesterday after you created the chksum?
21:39 < bfg> mtr: at least libxslt is missing in the cache file for docbookx (else nothing important, as far as i can tell immediately)
21:45 < mpp> hey ..
21:46 < mpp> i need a file Modules.symvers
21:46 < mpp> in ther kernel tree
21:46 < mpp> how do i generate this ?
22:02 < bfg> build the kernel
22:02 < rxr> it's generated after all modules whre built
22:02 < rxr> felanha: yes, possible - but I need to check / did not yet notice
22:02 < rxr> cu later
22:15 < mpp> yeah but the modversion is deactivated by t2
22:26 < bfg> mpp: you can activate it with a custom kernel config
22:26 < mpp> yes
22:26 < mpp> it's always the same c**p with vmware
22:26 < bfg> I did it on my box and it worked quite well
22:27 < mpp> yes i mean that vmware is always troublesome with the kernel tree
22:27 < bfg> jep... it was the same for me with vmware :)
22:27 < mpp> right
22:27 < bfg> vmware server 2.0 runs fine here, the 1.x version has troubles with libxcb
22:28 < mpp> :-)
22:28 < mpp> i am also on ther 2.0
22:28 < mpp> trying out see how it performs in comp to 1.0.x
22:28 < bfg> the 1.x version has better support for using the native display server
22:29 < mpp> okay.
22:29 < mpp> i'll be using it remotely
22:29 < bfg> else I would say, if you use your vmware instances as servers, then the 2.0 may be better
22:29 < mpp> thought so.
22:32 < bfg> for the kernel-sources it may be nice to include files like modules.symver and other things. this could make it easier to build 3rd party modules which are not part of T2 (or can not be integrated because of license restriction)
22:32 < mpp> i agree.
22:33 < mpp> i speculate that rxr would reply something like : ..... better activate it in the target
22:33 < mpp> :-)
22:33 < bfg> mmmm I am not sure. the module sumvers matches the installed modules. so it would be ok to have it there :)
22:34 < bfg> and it will be only part of the kernel source tree which is optional to build
22:34 < mpp> the only reason why it's missing because it's deactivated in the vanilla tree
22:34 < mpp> agree
22:34 < bfg> yes, and it is not that easy to filter out the useful files from the kernel tree, when the it is built
22:35 < mpp> same old story ...
22:35 < bfg> generally you don't need all the compiled .o files and so (i think so)
22:36 < mpp> anyways - t2 is cool , so there is a learning curve on handling some cases
22:36 < mpp> but that's tiny compared to the benefit a dev get's out of it
22:36 < mpp> !
22:36 < mpp> :-)
22:36 < bfg> that's true :)
22:36 < bfg> and once you are used to it, it is not that hard :)
22:37 < bfg> because it keeps mostly all to the standard build procedures
22:37 < mpp> that's what i found out also .
22:37 < mpp> yep thats policy of t2
22:37 < bfg> and that's good so :)
22:39 < bfg> sure, some things would be nice, but it's questionable whether it is worth the effort. e.g. the possibility to split generated packages into a dev/bin/doc package. may be nice. but I guess there are too many packages which need special handling for this. so far too much effort to maintain all this extras.
22:39 < mpp> hmm..
22:39 < mpp> i rebuilt the kernel inside the target
22:39 < mpp> but still no module.symver file there
22:40 < bfg> you did also a make modules ?
22:40 < mpp> ahm..
22:40 < bfg> (or whatever is required to build the modules)
22:40 < mpp> actually i rebuilt the target with -job 5-linux26
22:41 < mpp> so it should have rebuilt it all
22:41 < bfg> ah you did it in the build env.
22:41 < mpp> yes
22:41 < bfg> the modules.symver is only in the build tree available. it does not et packaged anywhere in T2
22:41 < mpp> i know
22:42 < mpp> but it's not in the built tree allthough CONFIG_MODVERSIONS is used to build
22:42 < mpp> maybe i hit the wrong option there
22:42 < bfg> mmm.. it should be in the temporary generated src.xxxx.linux-26/..... folder :)
22:43 < mpp> could you have a look at your own config
22:43 < mpp> maybe i missed something
22:43 < bfg> I activated the option to include the kernel source in the generated package. installed the source on the target. copied the kernel config T2 used to build the kernel into /usr/src/linux/.... and issued ah make on the target machine
22:43 < bfg> then I had the modules.symvers on the target
22:44 < mpp> ah.
22:44 < mpp> i'll try that one BUT
22:44 < mpp> it should had been build inside the build/.....
22:44 < bfg> there is no other way to keep modules.symvers in the build-environment, than hacking the package/base/linux26 /package/base/linux24 configs
22:44 < mpp> i see
22:45 < bfg> no it's not in the build it's in the t2-trunk-build-root/src.xxxx.linux26/....
22:46 < bfg> so you could break the kernel build after all modules are built and then you will find it in the left over src.xxxx.linux26 folder
22:46 < mpp> which get's rm'ed immediatly after the build finished :-)
22:46 < bfg> jep
22:46 < mpp> allright
22:48 < bfg> you could add some code to the package config of the kernel to include module.symvers to the package, after the kernel is built and source-packaging is enabled :)
22:48 < mpp> of course
22:49 < bfg> but I guess there are some more files missing then, like /usr/src/linux/include/{some generated header files according to config}
22:51 < mpp> that's probably right.
22:56 -!- mpp [n=user@i538742C3.versanet.de] has quit ["good night - good fight"]
--- Log closed Sat Oct 04 00:00:23 2008