**** BEGIN LOGGING AT Wed Apr 10 02:59:58 2013
Apr 10 06:39:29 <mattnie> morning @ all
Apr 10 07:47:29 <mckoan> good morning
Apr 10 08:45:14 <mckoan> gmacario: hello
Apr 10 08:45:33 <mckoan> gmacario: what is the user and password for foton-image?
Apr 10 09:00:33 <bluelightning> morning all
Apr 10 09:07:12 <mckoan> gm bluelightning, all
Apr 10 09:08:22 <bluelightning> hi mckoan
Apr 10 09:42:59 <void-dev> mckoan: foton-image user/password is root/root
Apr 10 09:46:18 <mckoan> void-dev_: thx
Apr 10 11:21:43 <mattnie> is it normal if i just disable "network support" in menuconfig the kernel will not build? Should menuconfig not normaly also disable the dependencies?
Apr 10 11:22:51 <david-e_> Hi, I'm a newbie trying to package tcllib for which I haven't found any existing recipe
Apr 10 11:22:57 <david-e_> I've packaged it for Windriver (pre-yocto) and buildroot where I had to pass ac_cv_path_tclsh="$(HOST_DIR)/usr/bin\
Apr 10 11:23:09 <david-e_> I've tried to set EXTRA_OECONF = "ac_cv_path_tclsh=${bindir}/tclsh" but I still get http://pastebin.com/Ma4dHY8y ;\ any help would be greatly appreciated!
Apr 10 11:31:54 <mcfrisk> mattnie: it's a bug if kernel modules don't declare that they depend on networking. kernel.org guys fix these fast but vendors might not.
Apr 10 11:36:02 <bluelightning> david-e_: does your recipe inherit autotools?
Apr 10 11:36:19 <david-e_> bluelightning: it does
Apr 10 11:36:28 <bluelightning> hmm
Apr 10 11:36:36 <bluelightning> kind of looks like the var isn't even being expanded
Apr 10 11:37:47 <david-e_> bluelightning: just in case I did anything THAT stupid, here's my recipe http://pastebin.com/4rmgTbcG
Apr 10 11:40:28 <bluelightning> david-e_: note that ${bindir} will just be /usr/bin ... if you want bindir within the native sysroot you would need to use ${STAGING_BINDIR_NATIVE}
Apr 10 11:40:53 <bluelightning> hopefully that path isn't also stored and used on the target...
Apr 10 11:41:55 <david-e_> bluelightning: still getting the same error. I was looking for that var with no success... thanx!
Apr 10 11:44:52 <bluelightning> david-e_: likely to be some kind of bug in the autotooling for tcllib itself then
Apr 10 11:45:10 <bluelightning> david-e_: it could be that it's not prepared to be autoreconf'd (which we always do)
Apr 10 11:45:32 <david-e_> bluelightning: ok, thanx for the tip
Apr 10 11:47:08 <david-e_> bluelightning: as an ugly workaround I might try to avoid autoreconf by using a makefile
Apr 10 11:47:39 <bluelightning> david-e_: if you want to disable the autoreconf you can supply your own do_configure that just calls oe_runconf
Apr 10 11:48:06 <david-e_> bluelightning: great, thanx a lot\!
Apr 10 11:48:51 <bluelightning> (better than calling ./configure yourself because it'll still ensure all the right arguments get passed to configure including what you put in EXTRA_OECONF)
Apr 10 11:50:41 <schramae> hi. i have a custom useradd package based on the useradd example. problem is that it does not get rebuilt when i change stuff, e.g. replace a binary file that simply gets installed within the recipe. i even tried "bitbake -c clean -C INVALIDATE_STAMP" with no success, the RPM still contains the old version of the file. what could be that cause of this and/or is there another way to completely clean the cache of a certain recipe?
Apr 10 11:51:43 <bluelightning> schramae: which version of bitbake are you using?
Apr 10 11:52:09 <bluelightning> also INVALIDATE_STAMP is meant to be a placeholder for a command (task name without do_, same as with -c)
Apr 10 11:54:04 <schramae> bluelightning: BB_VERSION = "1.16.0"
Apr 10 11:54:12 <schramae> from 1.3 release
Apr 10 11:55:21 <bluelightning> schramae: ok, you probably don't have this fix then: http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?h=danny&id=98292d1ef1cb44cf96f0a28fbca6439eda55ce1b
Apr 10 11:55:45 <bluelightning> at least, if you used -f or -C to try to make it do anything
Apr 10 11:56:03 <bluelightning> though changing a file pointed to by SRC_URI should always force a rebuild
Apr 10 11:56:25 <bluelightning> (unrelated to whether that fix is applied or not)
Apr 10 11:59:06 <schramae> strangely not. i added the binary via SRC_URI and then replaced it with a new version. it even does not get rebuild when changing other parts of the recipe and the resulting RPM has an old timestamp and seems to be completely reconstructed from cache. i will try "-f" and have a look at the patch
Apr 10 11:59:49 <mattnie> mcfrisk: thank you.. it is a hard and long way to get familiar with yocto and the embedded world :)
Apr 10 12:01:10 <bluelightning> schramae: that is concerning...
Apr 10 12:02:09 <schramae> bluelightning: sortof. no success with "-f", will try the patch
Apr 10 12:02:41 <bluelightning> schramae: I'd try to reproduce it but unfortunately I'm debugging something else at the moment
Apr 10 12:03:18 <schramae> bluelightning: np, i'm going to investigate a bit
Apr 10 12:05:54 <david-e_> bluelightning: managed to compile by overriding do_install() with  "oe_runmake install DESTDIR=${D} TCLSH_PROG=${STAGING_BINDIR_NATIVE}/tclsh"
Apr 10 12:06:09 <david-e_> not too happy with it but is ok as a starting point:)
Apr 10 12:07:08 <bluelightning> david-e_: ah ok... that's probably fine I guess
Apr 10 12:08:16 <david-e_> bluelightning: don't see why setting ac_cv_path_tclsh worked with buildroot and not with oe but that's another story
Apr 10 12:34:47 <bluelightning> david-e_: I'm not sure either I'm afraid
Apr 10 12:35:13 <bluelightning> but the answer will be somewhere in the autotooling of tcllib, of that I am fairly confident
Apr 10 12:58:16 <schramae> bluelightning: i can't apply the patch as is because there are too many changes and i'm afraid i'm going to break sth. else when replacing the whole make_stamp function. so now i did "-f" and manually deleted all cached files in the build dir containing the package name. "funny" thing is that it still gets reconstructed from cache. is there sth. else i can delete to really wipe the cache?
Apr 10 12:58:42 <bluelightning> schramae: bitbake -c cleansstate recipename
Apr 10 13:00:11 <schramae> bluelightning: ERROR: Task do_cleanstate does not exist for target useradd
Apr 10 13:00:21 <bluelightning> schramae: cleansstate not cleanstate
Apr 10 13:03:35 <schramae> bluelightning: that works, it gets rebuilt and the timestamps changed to current date, but the binary is still the old one. now i really feel being mocked... o_O
Apr 10 13:04:13 <bluelightning> ???!
Apr 10 13:04:25 <bluelightning> can I see your recipe?
Apr 10 13:04:45 <schramae> of course, mompl
Apr 10 13:07:02 <JaMa> I cannot find it now, but does RDEPENDS_(virt)class-native make sense? IMHO no, but still some recipes have it
Apr 10 13:09:15 <bluelightning> JaMa: I think there is some handling of "runtime" dependencies for native packages; I don't fully understand it myself
Apr 10 13:09:23 <bluelightning> s/packages/recipes
Apr 10 13:13:10 <mattnie> Does someone tested https://community.freescale.com/docs/DOC-93619 this patches with yocto?
Apr 10 13:14:16 <schramae> bluelightning: http://pastebin.com/1qYTCZ9L
Apr 10 13:19:51 <bluelightning> schramae: hmm... you don't have two copies of the file under different paths by any chance?
Apr 10 13:20:19 <bluelightning> schramae: you can look at log.do_fetch to see the list of paths it looked in to find the file
Apr 10 13:25:18 <bluelightning> JaMa: any suggestions re the busybox bbappend in meta-oe?
Apr 10 13:26:41 <JaMa> not really, I don't know much about that one
Apr 10 13:27:12 <bluelightning> JaMa: few people do it seems :(
Apr 10 13:27:16 <schramae> bluelightning: i checked, the custom installer is only present once and this is the newer version. it does not show up in do_fetch.log, only in do_install.log. but it does not exist within the tmp/work path, so install should fail at all. and the rest of do_install() from the .bb still contains old code as well
Apr 10 13:28:16 <bluelightning> schramae: and you're positive this is the recipe that's being built? there isn't another copy somewhere else?
Apr 10 13:28:36 <bluelightning> the way it's apparently behaving doesn't make a lot of sense...
Apr 10 13:31:20 <schramae> i checked, the recipe only exists once. and i was wrong about it showing up in do_install.log, that was an old one. but the installer shows up in build/.../useradd-1.0-r1/image/... and is contained in the RPM as well
Apr 10 13:52:28 <rburton> anyone got any tips for buying a cheap but fast usb3 memory stick?
Apr 10 13:52:35 <rburton> discovered my build machine has usb3 slots at the back
Apr 10 13:58:03 <Zagor> rburton: I recently bought a Corsair USB 3.0 Voyager S. crazy fast.
Apr 10 13:59:07 <rburton> and only a tenner for the 8gb model
Apr 10 13:59:09 <mattnie> i use a corsair flash voyager gt.. very fast and robust.. i am using it since about one year every day and it is still working :)
Apr 10 13:59:12 <kergoth> Anyone run into gettext version issues with m4 vs Makefile.in.in when doing a non-gplv3 build? it seems there may be an issue using 0.18 gettext-native and gettext-minimal-native but 0.16 gettext, but I'm not certain
Apr 10 13:59:29 * kergoth is a gettext noob, mostly
Apr 10 13:59:30 <Zagor> apparently the "GT A" models are even faster
Apr 10 13:59:45 <Zagor> but quite a bit pricier
Apr 10 14:00:41 <Zagor> or, uh, seems to vary a lot. oh well..
Apr 10 14:01:07 <rburton> "Flash Voyager GT USB 3.0 is even faster, with data transfer rates of up to two times the speed of standard USB 3.0 drives, "
Apr 10 14:01:17 <rburton> well that doesn't actually mean anything
Apr 10 14:01:47 <rburton> damn, they get a lot faster as they get bigger
Apr 10 14:01:58 <rburton> so the 8gb only writes at 12mb/s, where as the 32gb writes at 40mb/s
Apr 10 14:02:21 <Zagor> 64 GB is listed as 110 MB/s ...
Apr 10 14:02:33 <mattnie> http://www.everythingusb.com/corsair-flash-voyager-gt-usb-3.0-flash-drive-21419-2.html
Apr 10 14:03:01 <mattnie> i have the 32gb version
Apr 10 14:05:03 <Zagor> yikes, 250 MB/s. for real? http://pricespy.co.uk/category.php?l=s122492917&o=eg_209#prodlista
Apr 10 14:06:10 <Zagor> my "crazy fast" corsair appears quite slow in comparison :-)
Apr 10 14:06:36 <rburton> i doubt 250mb/s
Apr 10 14:07:20 <mattnie> can be possible :) there is no limitation by the actual technology usb3/ssd ... so why not?
Apr 10 14:07:23 <rburton> but that's a great website!
Apr 10 14:08:20 <Zagor> kingston claims it. "Max Sequential Read/Write speeds: 250/250 MB/s" http://www.kingston.com/us/usb/bootable/
Apr 10 14:08:55 <Zagor> I agree it sounds a lot
Apr 10 14:10:02 <rburton> well just ordered the lexar at 150mb/s
Apr 10 14:10:10 <rburton> lets see what it can actually do when writing a 500mb image
Apr 10 14:16:03 <denisATeukrea> hmmm I wonder about SSDs, are they afordable nowadays like for 1TB?
Apr 10 14:16:35 <denisATeukrea> (that much space is needed for building stuff)
Apr 10 14:17:39 <rburton> denisATeukrea: if you want SPEEEEED put tmpdir in a tmpfs
Apr 10 14:18:06 <rburton> (with the sstate and downloads on persistent media)
Apr 10 14:18:13 <denisATeukrea> ok
Apr 10 14:18:29 <denisATeukrea> I've already 7200RPM *  2
Apr 10 14:18:32 <rburton> you'll want rm_work
Apr 10 14:18:46 <denisATeukrea> ah yes what about rm_old_work?
Apr 10 14:20:29 <denisATeukrea> I know putting everything in ram does work and is way faster
Apr 10 14:20:47 <denisATeukrea> but since there is filesystem cache
Apr 10 14:21:01 <denisATeukrea> I wonder why filesystem cache isn't that fast
Apr 10 14:22:36 <rburton> denisATeukrea: pseudo will even turn off sync operations for performance
Apr 10 14:22:51 <denisATeukrea> ok
Apr 10 14:23:48 <rburton> denisATeukrea: i notice my fs cache, because it will build several packages without any IO and then suddenly write frantically for several seconds
Apr 10 14:24:19 <denisATeukrea> ok
Apr 10 15:00:58 <mattnie> does anyone here have a imx6qsabresd?
Apr 10 15:19:49 <JaMa> dylan branched now? :)
Apr 10 15:20:19 * JaMa first to be there... 
Apr 10 15:26:53 <mattnie> http://git.yoctoproject.org/cgit/cgit.cgi/poky/log/?h=dylan :)
Apr 10 15:31:57 <rburton> yay
Apr 10 15:32:37 <denisATeukrea> it's the next branch like danny and denzil?
Apr 10 15:34:00 <rburton> yes
Apr 10 15:34:14 <denisATeukrea> ok
Apr 10 15:34:15 <rburton> http://wiki.yoctoproject.org/wiki/Releases
Apr 10 15:34:15 <denisATeukrea> thanks
Apr 10 15:36:44 <mattnie> but it is still in stabilization .. isn't it?
Apr 10 15:37:20 <rburton> yeah
Apr 10 15:37:40 <rburton> branching pre-release isn't unusual
Apr 10 15:42:53 <RP_> The branches will probably remain in sync for now
Apr 10 15:53:14 <bluelightning> khem: ping
Apr 10 16:00:39 * kergoth sighs at gettext
Apr 10 16:05:47 <bluelightning> kergoth: don't just sigh, stab it :p
Apr 10 16:06:00 <zecke> hehe
Apr 10 16:06:12 <kergoth> if only that helped
Apr 10 16:06:22 <otavio> RP_: If those are going to be kept in sync, why to branch?
Apr 10 16:06:37 <otavio> RP_: (curious)
Apr 10 16:08:31 <kergoth> gettext-minimall-native and gettext-native are both 0.18, but gettext is 0.16, in this context, and some things seem to be unhappy about this
Apr 10 16:08:34 * kergoth digs
Apr 10 16:13:16 <bluelightning> hmm, I wonder why they aren't the same version?
Apr 10 16:36:29 <JaMa> BTW: is anyone still seeing bitbake hangs with bitbake/master?
Apr 10 16:39:36 <rburton> JaMa: nope
Apr 10 16:43:16 <RP_> JaMa: no and nothing major has changed in there recently...
Apr 10 16:43:49 <RP_> otavio: means we can test building the branch in its final location, lets the docs people test the final naming etc
Apr 10 16:44:08 <RP_> It shouldn't matter much however reality can be different
Apr 10 16:52:47 <JaMa> RP_: I was seeing them before you fixed PR service logging, then it was fine for some time and at least since https://bugzilla.yoctoproject.org/show_bug.cgi?id=3978 I see them from time to time (1 build from 10 or something like that) unfortunatelly also with pool changes reverted
Apr 10 16:52:49 <yocti> Bug 3978: normal, Undecided, ---, richard.purdie, RESOLVED FIXED, Infinite hang in bitbake parse if you have certain types of parse errors
Apr 10 16:53:57 <RP_> JaMa: I don't understand the cause of this :(
Apr 10 16:54:59 <JaMa> it doesn't seem very related to metadata (I see it in 4 completely different setups)
Apr 10 16:55:21 <JaMa> but because it's not very often I don't know how to find reliable reproducer for it
Apr 10 16:55:46 <JaMa> it's like that "Argument list too long" error with only one argument when trying to build world-image :/
Apr 10 17:02:20 <RP_> JaMa: right, it makes it hard for others to help since we can't reproduce locally :/
Apr 10 18:48:03 <SlashV> does anyone know of a way to stop bitbake from dumping error logs to the console?
Apr 10 18:49:06 <kergoth> do you mean the tail of the task log when a task fails?
Apr 10 18:49:15 <kergoth> that's controlled by BBINCLUDELOGS
Apr 10 18:50:05 <SlashV> It doesn't really appear to be a tail. My problem is that it takes forever for really big logs.
Apr 10 18:50:21 <SlashV> But I'll have a look at BBINCLUDELOGS. thx
Apr 10 18:50:57 <kergoth> BBINCLUDELOGS_LINES, iirc, is a fixed # of lines to display from the end
Apr 10 18:51:03 <kergoth> can probably use that to limit it
Apr 10 19:09:22 <khem> is someone using yocto on large systems e.g. 256 cores+ I would be interested in
Apr 10 19:09:57 <khem> basically not a typical resource constrained embedded system
Apr 10 19:09:59 <SlashV> kergoth: thx, that worked.
Apr 10 19:26:44 <pidge> otavio: want to do a dylan branch for me? I want to get an rc built out starting in about 10 minutes.
Apr 10 19:26:54 <otavio> pidge: sure
Apr 10 19:26:57 <pidge> ty
Apr 10 19:28:27 <pidge> is Luo around? I don't remember his irc nick?
Apr 10 19:28:29 <otavio> pidge: yw
Apr 10 19:29:00 <otavio> pidge: never talked to him by IRC
Apr 10 19:29:19 <pidge> ok. sending an email. I'll pull from his master for now.
Apr 10 19:29:21 <otavio> pidge: done
Apr 10 20:07:54 <JaMa> oe-core/LICENSE says Poky :/ "Different components of Poky are under different licenses"
Apr 10 20:08:03 <JaMa> shouldn't it be changed to something else?
Apr 10 20:08:35 <JaMa> it also lists bitbake and meta-extra directories which are not there..
Apr 10 20:08:36 <JaMa> bitbake/COPYING (GPLv2)
Apr 10 20:08:36 <JaMa> meta/COPYING.MIT (MIT)
Apr 10 20:08:36 <JaMa> meta-extras/COPYING.MIT (MIT)
Apr 10 22:46:18 <thaytan> denix: argh @ ti81x disappearing
Apr 10 22:47:03 <denix> thaytan: yeah, sorry
Apr 10 23:04:50 <thaytan> denix: I'm not sure what to do with it
Apr 10 23:04:59 <thaytan> the old meta-ti snapshot we had works well enough
Apr 10 23:05:19 <thaytan> so we could probably just keep using that
Apr 10 23:05:52 <denix> thaytan: see the commit description - http://git.yoctoproject.org/cgit/cgit.cgi/meta-ti/commit/?id=c586bd9a663c6b77478b7b38ff771f6b8360edea
Apr 10 23:06:19 <thaytan> denix: *nod*, I found it
Apr 10 23:06:49 <thaytan> debating whether I'm a) up to the task of maintaining or b) if we need it kept up to date at all or can go with a snapshot
Apr 10 23:07:03 <denix> thaytan: if you are willing to maintain it, feel free - either in your own layer or even ask to get it back to meta-ti. it's just we don't have resources here for that platform
Apr 10 23:07:28 <denix> thaytan: understood. let me know if you decide one way or another
Apr 10 23:07:46 <thaytan> cool
Apr 11 01:10:51 <ka6sox> what port does bitbake-prserv run on if you have a public server?
Apr 11 01:15:07 <ka6sox> I understand this is the form: bitbake-prserv --host <ip> --port <port> --start ...but is there a convention on port?
**** ENDING LOGGING AT Thu Apr 11 02:59:59 2013