**** BEGIN LOGGING AT Wed Feb 06 02:59:58 2013 Feb 06 08:06:41 good morning Feb 06 09:15:01 Can anyone tell me how to use a newer version of u-boot, is it determined by the kernel version?? Feb 06 09:20:53 morning all Feb 06 09:21:32 shiftee_: the u-boot version is determined by whatever version(s) of the available u-boot recipe are available Feb 06 09:22:06 see meta/recipes-bsp/u-boot/ Feb 06 09:22:53 Thanks, So basically it's down to the version of poky, yes?? Feb 06 09:26:08 shiftee_: out of the box, yes Feb 06 09:26:35 shiftee_: you can easily provide an additional recipe with a different version and select it with PREFERRED_VERSION_u-boot = "xxx" Feb 06 10:47:24 mihai: are you working on adding tests to autobuilder? Feb 06 10:55:23 Zagor: sort of, I have some w.i.p. on that Feb 06 10:56:39 mihai: we should talk. we have automatic ptests running in autobuilder at enea today. Feb 06 10:58:21 Zagor: sure, we could talk Feb 06 10:58:27 so we're interested in helping shape the future of autobuilder tests Feb 06 10:58:31 Zagor: excellent! Feb 06 10:58:55 Zagor: i was going to look at adding ptest support for libpng. do you have anything resembling documentation for how to do ptests? Feb 06 10:59:11 Zagor: did any of the ptests reached oe-core, or are there any plans to do so? Feb 06 10:59:36 rburton: I only have this very basic wiki page: https://wiki.yoctoproject.org/wiki/Ptest Feb 06 10:59:50 mihai: a couple are in oe-core already Feb 06 11:00:03 Zagor: i wonder if we should patch automake so that it adds a target for building the test binaries Feb 06 11:00:19 rburton: I/we did that already :) Feb 06 11:00:21 oh! Feb 06 11:00:24 ha Feb 06 11:00:42 did you approach upstream automake with it? Feb 06 11:01:11 Zagor: that wiki page is great, thanks Feb 06 11:01:40 rburton: yes. Stefano was mildly sceptical. he doesn't want anything new for "old" serial tests and rather wants everyone to rewrite as parallell test. Feb 06 11:02:01 I explained that is quite a long term goal, but didn't get much further Feb 06 11:03:09 possibly his new stance will make a retake on that have a better chance Feb 06 11:03:36 Bagder: perhaps Feb 06 11:03:51 but I'm not overly optimistic about that Feb 06 11:04:13 Zagor: is this patch in oe-core? can't see a patch to automake Feb 06 11:04:22 oh, hang on, i'm on the danny branch still! Feb 06 11:05:32 i can't see why he'd reject it, it's just adding some granular steps - the build will be the same Feb 06 11:06:12 here is the mail thread: http://lists.gnu.org/archive/html/automake/2012-11/msg00024.html Feb 06 11:06:43 that rejection piece should probably be linked from the wiki page Feb 06 11:07:13 ah, because you're reusing the run code Feb 06 11:10:41 also, it turns out the suggested "make -f -" workaround is illegal in make. two definitions of the same target is not allowed. Feb 06 11:26:04 otavio: there? Feb 06 11:37:23 rburton: Hi Feb 06 11:37:26 :) Feb 06 11:37:59 otavio: your fsl-arm layer danny branch has a udev_173.bbappend, but danny has 164. predicably, broke the danny test build last night Feb 06 11:38:18 i'd suggest removing it entirely as it just changes the src uri Feb 06 11:39:00 the fsl-ppc build exploded too, so i guess that's the same problem Feb 06 11:41:16 rburton: I'll look at it Feb 06 11:45:47 otavio: see the danny-next builds on the yocto autobuilder Feb 06 12:23:14 mihai: ptest for bash, glib and dbus are available in master Feb 06 12:24:51 Zagor: ok, thanks Feb 06 12:28:42 and I will submit a few more soon Feb 06 13:28:04 kergoth: finished bb-contents, and rebased. feel free to review/merge contents and log if you want Feb 06 13:29:13 oh, i should sort the packages Feb 06 13:32:56 that's better. Feb 06 13:39:46 Migration from LOCALCOUNT to AUTOINCs failed! Feb 06 13:39:54 making it more verbose would be nice.. Feb 06 14:48:13 rburton: cool, will do Feb 06 14:50:03 rburton: merged, thanks Feb 06 14:51:28 am I supposed to do something other than set TCLIBC = "uclibc" to build with uclibc? when I do just that, gettext fails to build (patch) in master. Feb 06 14:52:58 JaMa: which python versions are you seeing the PR server hangs on? Feb 06 14:53:11 2.7.3 Feb 06 14:53:32 rburton: Hmm, might want to think about examining the actual binary packages rather than package-split, or add the ability to unpack them back into package-split, for the shared state case.. of course, buildhistory for packages suffers from the same limitation, so it's not a big deal Feb 06 14:53:36 RP: from gentoo as well as 2.7.3 in ubuntu 12.04 Feb 06 14:53:50 JaMa: I wish I could reproduce it :/ Feb 06 14:54:28 rburton: hrm, nevermind, maybe its a nonissue. nicely done on these commands, they'll both be handy Feb 06 14:54:39 rburton: will have to think about using bold or color in some of the other subcommands, use of bold is nice Feb 06 14:54:52 am planning on adding match highlighting to search one of these days Feb 06 14:55:47 RP: it doesn't seem important where I hit Ctrl+C, I've seen it hanging after interrupting when parsing, preparing runqueue, running runqueue or even not interrupting it at all (in really long build) Feb 06 14:56:17 I've never seen it on my 12.04 systems, unfortunately :\ Feb 06 14:56:27 must be timing sensitive Feb 06 14:56:42 kergoth: using PR Service? Feb 06 14:56:48 My system was a 12.04 until recently and I've not seen it... Feb 06 14:56:48 yeah Feb 06 14:57:18 well, i'm using local automatically started, don't know if pr server configuration is an issue Feb 06 14:57:31 Makes you wonder if we'd be better off in python 3 at this point. 2.6/2.7 do seem to have a few threading/process issues :( Feb 06 14:57:32 also I'm using | tee for new knotty to look like old knotty Feb 06 14:57:58 kergoth: I'm also using local automatically started Feb 06 15:07:08 http://stackoverflow.com/questions/12984003/status-of-mixing-multiprocessing-and-threading-in-python Feb 06 15:07:22 PRserver is using threading Feb 06 15:12:44 hmm Feb 06 15:13:33 RP: so running standalone PR service could be work around (at least to test that hangs are gone)? Feb 06 15:13:49 JaMa: yes, that would at least narrow the problem down Feb 06 15:14:31 JaMa: it would point strongly at threading breaking somehow Feb 06 15:14:46 OK I'll change it after current build is finished Feb 06 15:15:00 NOTE: Running task 8217 of 25028, don't wait for it :) Feb 06 15:15:13 JaMa: ;-) Feb 06 15:16:27 JaMa: need help? any steps to repro? I have some gentoos around me Feb 06 15:19:34 mihai: I don't know what's cruical to repro, but I see it on my gentoos as well as my ubuntoos :) Feb 06 15:19:59 mihai: but it's this bug https://bugzilla.yoctoproject.org/show_bug.cgi?id=3742 Feb 06 15:20:00 Bug 3742: major, Medium, 1.4, richard.purdie, NEW , bitbake hangs forever when PR serv is enabled Feb 06 15:20:54 JaMa: oh, I though it was specific to gentoo Feb 06 15:21:01 thanks, I'll look over it Feb 06 15:30:26 hi everybody! Anybody here has experience of running any 3D application besides Vivante samples in /opt/viv_samples on a i.MX6? Feb 06 15:50:51 so, who wrote the core of systemd.bbclass? Feb 06 15:54:53 kergoth: we appear to start two PRservers for a start. The wrapper in server/process.py is wrong (there are two server_main() calls) Feb 06 15:55:14 rburton: Andreas Muller Feb 06 15:55:23 heh, that's not good Feb 06 15:56:29 kergoth: lots of puzzling debug output until I realised that :/ Feb 06 15:56:41 kergoth: for a while it looked like there were two cookers too Feb 06 15:56:41 rburton: and otavio Feb 06 15:57:37 rburton: http://lists.linuxtogo.org/pipermail/openembedded-devel/2012-February/037960.html Feb 06 15:59:14 thanks Feb 06 15:59:40 JaMa: you might want to try http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/t1&id=1a62bd827cf3866e826152cebbfe727f2b7d5db3 instead of the separate PR server Feb 06 15:59:57 JaMa: feedback on whether it helps or not would be appreciated. It rips out the threading usage Feb 06 16:00:15 RP: ok Feb 06 16:00:16 thanks Feb 06 16:06:20 RP: hmm even before I've tried this patch, PR service stopped working (after last oe-core upgrade - maybe unrelated) Feb 06 16:08:05 PR says in log: NOTE: PRServer: started! DBfile: /OE/oe-core/cache/prserv.sqlite3, IP: 127.0.0.1, PORT: 56653, PID: 25035 Feb 06 16:08:22 but all packages are showing errors like ERROR: Package version for package initramfs-module-mdev went backwards which would break package feeds from (0:1.0-r2.5 to 0:1.0-r2) Feb 06 16:08:25 :/ Feb 06 16:08:59 and now I haven't dumped cache/prserv.sqlite3, it's still there and with right values Feb 06 16:09:06 s/now/not/ Feb 06 16:09:16 -t Feb 06 16:17:48 JaMa: I wonder if my package.bbclass changes broke things? Feb 06 16:22:07 RP: maybe, I've only merged 6 top patches from bitbake and oe-core changes from afternoon Feb 06 16:23:06 JaMa: Pretty sure recent package.bbclass changes are at fault Feb 06 16:24:23 RP: and with that bitbake patch it does not show PR service starting or stopping Feb 06 16:26:50 hmm update_font_cache failing on 3 from 6 MACHINEs I'm building, netbase install on 1 (qemux86-64), PR service on all :) Feb 06 16:37:45 heh: Feb 06 16:37:46 NOTE: recipe netbase-1_5.0-r0: task do_package_write_ipk: Started Feb 06 16:37:46 NOTE: recipe netbase-1_5.0-r9: task do_package_write_ipk: Succeeded Feb 06 16:37:55 sweet! Feb 06 16:38:28 and r9 is not result of PR service, it's from PRINC in BSP layers where I removed it an hour ago Feb 06 16:52:38 JaMa: a fix on master should help some of this Feb 06 16:53:06 JaMa: autobuilder is showing fontcache issues too :( Feb 06 17:17:21 RP: interesting with fontcache is that those 3 machines are not the same ARCH (2 cortexa8, 1 armv4t) and other cortexa8 machine built fine.. Feb 06 17:28:19 RP: and netbase install issue is probably another MACHINE_ARCH -> TUNE_PKGARCH transition issue :/ Feb 06 17:51:39 JaMa: that patch I mentioned above breaks the logging for the PR service, just for reference Feb 06 18:09:54 RP: ah ok then, I'm rebuilding now with fix for PR values, then I'll try to hit it with Ctrl+C few times Feb 06 18:38:56 Hi all, I'm learning about the Yocto ADT. I've been able to install the ADT and Eclipse plugin, and build/run a simple hello world app. Now I'm wondering how to integrate it with the rest of yocto. How can I add layers that might include custom libraries that my app might depend upon? Feb 06 18:39:40 Do I do that in the normal yocto environment, then follow the instruction to generate a sysroot from yocto? Feb 06 18:41:23 and can I take a project I've done with the ADT and and it spit out a recipe that I can drop into a yocto layer? Feb 06 18:42:43 I guess I don't understand the work flow at the intersection of the ADT and normal ole yocto Feb 06 19:19:00 I guess put another way, I'd like to customize an ADT rootfs with additional packages to enable folks to easily develop apps using those packages. Feb 06 19:19:48 I'll try the "build system derived toolchain" Feb 06 19:21:03 or maybe I can use the stand-alone toolchain, but point it to a different rootfs? Feb 06 20:12:56 OK, I think I've figured out something that will work on those lines with the runqemu-extract-sdk Feb 06 20:14:09 new question :) What are the rules governing what can follow an _append? I see ..._append_libc_uclibc, ..._append_armv6, ..._append_virtclass-native Feb 06 20:14:32 mainly, I want to add some appends that get executed only if I'm not building for qemu Feb 06 20:15:04 or, that get executed only if I'm building for Feb 06 20:16:53 Garibald1: not-for-qemu is hard Feb 06 20:17:06 well actually Feb 06 20:17:15 SOMETHING="do this" Feb 06 20:17:19 SOMETHING_qemuall = "" Feb 06 20:17:28 that works (master required for qemuall) Feb 06 20:19:05 let me explain what I want, maybe there's a better way. I'm working on building a rootfs for an lxc vm and I need to tune what startup scripts are run. I don't, for example, want networking, udev, rtc manipulation stuff to happen. Feb 06 20:19:29 but I don't want to blindly remove those things, because I also want to test with qemu Feb 06 20:20:32 so far it's removing /etc/rc?.d/S* scripts, and tweaks to /etc/inittab Feb 06 20:21:44 you can override the start scripts by messing with INITSCRIPT_PARAMS_pn-foo Feb 06 20:21:52 something along the lines of this might work, entirely untested though Feb 06 20:22:17 yeah, I have done that, but I need INITSCRIPT_PARMS_pn-foo_notqemu :-) Feb 06 20:22:28 INITSCRIPT_PARAMS_pn-udev = "disable" Feb 06 20:22:30 INITSCRIPT_PARAMS_pn-udev_qemuall = "defaults" Feb 06 20:22:43 ahh Feb 06 20:22:54 might work! Feb 06 20:23:22 yeah, I understand. You said I'd need master... master for bitbake? Feb 06 20:23:32 master oe-core Feb 06 20:23:38 ah Feb 06 20:23:48 if you can't do that, you can just replicate _qemuall for each of the qemus you are likely to run Feb 06 20:23:56 if you'll only really run qemux86, use that Feb 06 20:24:07 qemuall is just a catchall for any qemu machine Feb 06 20:24:12 yeah, I'd be doing qemux86 only Feb 06 20:24:32 let me give that a shot Feb 06 20:25:51 could I also have USE_VT = "0" and USE_VT_qemux86 = "1" Feb 06 20:26:02 for instance Feb 06 20:26:06 yes Feb 06 20:26:08 nice Feb 06 20:33:26 RP: it's much better with that PRserv patch, killed with Ctrl+C few times, small backtrace is shown but that was always shown (at least here) http://paste.debian.net/232298/ Feb 06 20:34:11 rburton: so I can do do_install_append() and do_install_append_qemux86() and the former will be used for everything but qemux86 and the latter will be used only for qemux86, right? Feb 06 20:34:39 or will the former be used for _everything_ and the latter also used for qemux86 Feb 06 20:37:00 or, can I define my own machine and just do do_install_append_mymachine Feb 06 20:37:17 and have an lxc machine Feb 06 20:44:36 Garibald1: defining your own machine is almost certainly the right thing to do Feb 06 20:44:48 yeah, makes sense Feb 06 20:44:59 erm, not sure what happens in your append situation Feb 06 20:45:23 eh, if I add the new machine I won't need both Feb 06 20:45:26 I htink Feb 06 20:59:46 well, my build is off, we'll see how it goes :) Feb 06 21:00:20 rburton: thanks again for you help Feb 06 21:00:57 hrm... how do I require core-image-minimal.bb from another layer? Feb 06 21:01:04 some path I need to provide? Feb 06 21:02:08 ah... just the path under whatever layer it is in Feb 06 21:02:13 dvhart: you mean 'inherit core-image-minimal' ? Feb 06 21:02:23 (i.e., w/o the .bb) Feb 06 21:02:46 wait, core-image-minimal is a recipe or a class? Feb 06 21:03:07 I'm confusing myself, you said 'require' not 'inherit' :) Feb 06 21:18:52 Garibald1, yeah, require, which uses the bb - the problem was just you need to preface it with the path after the top level layer meta dir Feb 06 21:19:03 (if doing so in a separate layer or dir) Feb 06 21:19:23 that's good to know. I think I tried that once and failed and didn't persue it further Feb 06 21:19:26 target qemu failing for someone today? Like this: | libcacard/.libs/cac.o: could not read symbols: File in wrong format Feb 06 22:01:14 denix, found the BlackPole github thing and the dmidecode recipe - any objection to that recipe going into oe-core? Feb 06 22:02:11 dvhart: dmidecode is already in meta-oe Feb 06 22:02:55 JaMa, ok.... same question Feb 06 22:11:51 I think it should stay in meta-oe, it's not core enough Feb 06 22:18:52 I guess what defines "core enough" isn't very clear to me Feb 06 22:30:46 JaMa: thanks for the feedback, looks like we're poking in the right direction at least Feb 06 22:31:15 kergoth: Any ideas on how to make python logging from a daemonized process into the main bitbake logger? Feb 06 22:31:34 kergoth: or should I just ensure they make the disk log file I wonder... Feb 06 22:32:12 can somebody point me to the docs for how caching works when you add your own tasks (ie. when it knows to re-run them or not). I added a new task to my recipes and it's always re-running that task and all subsequent tasks. I added my_task[dirs] = "..." and now it's not re-running my task, but it still re-runs the following tasks. Feb 06 22:32:56 RP: It would be great to show at least starting/stopping message even if it shows main process before starting/killing PRserv daemon Feb 06 22:33:13 JaMa: agreed, that shouldn't be hard Feb 06 22:40:39 RP: disk would work, or you could just use a Queue to pass the log events back, but then you'd have to worry about potential blocking from the child Feb 06 22:40:40 hmm Feb 06 22:46:15 morning Feb 06 22:50:15 RP: I've probably found issue with font cache.. It's missing /usr/bin/crossscripts/qemuwrapper in some sysroots here Feb 06 22:50:50 JaMa: ah, that sounds like a promising lead Feb 06 22:53:08 I always have something.. now it's reparsing all recipes after each build Feb 06 22:53:52 no metadata change, only bitbake -c cleansstate qemuwrapper-cross; bitbake qemuwrapper-cross and both are parsing all recipes Feb 06 23:03:41 I'm looking for an example of a bbappend file that removes packaged files from a base layer Feb 06 23:04:11 as an example, I want to omit the speaker-test wav files from the alsa-utils package Feb 06 23:13:07 alternatively, modify the RDEPENDS for alsa-utils to leave out alsa-utils-speakertest entirely Feb 06 23:18:51 RP: cache broken by one of our patches from today, details on ML Feb 06 23:20:51 thaytan: I would suggest installing the individual alsa-utils-xxxx packages rather than the main alsa-utils package (which is actually empty) Feb 06 23:21:18 JaMa: thanks, will look in a minute Feb 06 23:21:26 * RP suspects sleep won't be for a while Feb 06 23:26:25 JaMa: which ML? Feb 06 23:26:44 RP: bitbake-devel Feb 06 23:28:46 hmm somehow I've sent it with bitbake-devel in Cc: not in To:, bounced it now to be sure Feb 06 23:29:35 RP: here it is http://paste.debian.net/232345/ Feb 06 23:29:48 JaMa: thanks, email isn't appearing :/ Feb 06 23:30:20 JaMa: ah, we need to ignore BB_ORIGENV Feb 06 23:37:33 JaMa: fix pushed for this, thanks for summarising it nicely Feb 06 23:38:18 yocto has anything to set timezone? Feb 06 23:38:45 because there is no /etc/timezone installed Feb 06 23:46:06 JaMa: master hopefully looks better with the changes pushed Feb 06 23:50:03 RP: thank you very much Feb 06 23:50:51 only mystery is missing qemuwrapper in some cases, I don't see what's wrong with that, after manual cleanup all stamps are correct Feb 06 23:53:59 JaMa: not looked at that issue yet Feb 06 23:57:13 JaMa: Do you image targets overwrite DEPENDS? Feb 06 23:57:28 JaMa: I'm wondeirng if the DEPENDS in image.bbclass is getting trampled Feb 06 23:57:43 JaMa: if the dependency went missing, it wouldn't get built... Feb 07 00:08:22 RP: that was first thing I've checked in bitbake -e and dependency was there Feb 07 00:08:58 RP: even the stamp files were probably there because when I've tried to build it manually it finished with all tasks not needed to run Feb 07 00:09:46 RP: and I was busy with other stuff to check sstate-control files and stamps before cleaning it to check if cleansstate is enough to build new image Feb 07 00:09:58 maybe you still have it on some autobuilder slaves Feb 07 00:10:45 JaMa: There are a number of fontcache issues here but not that one exactly afact Feb 07 00:11:30 I see Feb 07 00:19:42 In my pool of miscellaneous things I sort of want: Is there a reasonable way for a configuration file to cause a message to be displayed at some reasonable top-level point? As a quick proof-of-concept, I did one which adds a BANNER_MESSAGES[...] idiom, with messages stored there being displayed in the base.bbclass BuildStarted handler, and it didn't strike me as highly intrusive. Feb 07 00:20:31 Idea being, it is occasionally the case that there's a configuration file which has implications that a user might want to know about, but there's not a nice clean way to arrange for messages to be shown in some reasonably obvious place, like up with the build attributes stuff. Feb 07 00:20:36 Or there is and I haven't found it yet. Feb 07 00:29:58 anyone played with lxc here **** ENDING LOGGING AT Thu Feb 07 02:59:58 2013