**** BEGIN LOGGING AT Thu Oct 22 02:59:58 2015 Oct 22 07:26:02 good morning Oct 22 07:27:24 morning Oct 22 08:06:41 morning all Oct 22 08:19:36 hi bluelightning, all Oct 22 08:19:42 hi mckoan Oct 22 11:43:06 khem: hello Oct 22 11:43:23 khem: did you see the error I posted in the mailing list? Oct 22 11:45:57 https://github.com/kraj/meta-jetson-tk1/blob/master/recipes-bsp/binary-drivers/linux-driver-package_21.4.0.bb installs some udev rules for nvidia devices. will that work with a angstrom systemd image? Oct 22 11:46:06 with only what's in the recipe now, I mean Oct 22 11:53:59 tasslehoff: it should Oct 22 11:54:48 otavio: good. something else is wrong then :) Oct 22 11:56:25 tasslehoff: I said, should ;-) Oct 22 11:57:00 otavio: I combined it with the results of my own investigations :) Oct 22 12:13:17 hi, about the shell functions embedded in recipes ; are we sure that BitBake is always using Bash, or can it vary ? Oct 22 12:22:54 hi Oct 22 12:25:13 Tarnyko: they're executed with /bin/sh IIRC so shouldn't use bashisms Oct 22 12:26:18 jku: thanks. Apparently, some bashisms are syntaxely-accepted but ignored :) Oct 22 12:29:29 a question: a recipe that inherits image bbclass is always being rebuilt no matter if there were changes or not, is there a way to change that behaviour for a specific image recipe? so it only gets built when some of its deps really have changed? Oct 22 12:31:36 mit "at" meinst du at daemon? Oct 22 12:31:40 oops wrong window Oct 22 12:37:28 After compiling new package I run "bitbake upload-packages" and then the sort.sh script. what are the best practices I should follow for bumping versions and stuff so the devices see my new packages as upgrades? Oct 22 12:41:00 tasslehoff: I use prserver and always bitbake package index before uploading the stuff to a "repository/feed" server, that works for me Oct 22 12:41:45 es gab mal ein bug das simultan mehrere at jobs gequeued wurden, aber die waren dennoch nicht leer Oct 22 12:41:49 oops wrong window again, dammit Oct 22 12:41:57 sorry :) Oct 22 12:42:31 Jin^eLD: don't you mean Scheiße? :) Oct 22 12:42:57 Jin^eLD: ok. need to look at prserver and bitbaking package index then :) Oct 22 12:43:20 ( translation of Jin^eLD via google, fyi: there was even a bug that simultaneously were at several jobs queued, but they were not yet empty :) ) Oct 22 12:43:50 I'm used to worse translations by google hehe, this one isn't even that bad Oct 22 12:44:11 tasslehoff: I curse in various languages, but scheisse would also be appropriate =) Oct 22 12:44:36 tasslehoff: for prserv I think you only need PRSERV_HOST = "localhost:0" Oct 22 12:44:41 in your local.conf Oct 22 12:46:21 tasslehoff: and at least for my own packages I also always bump PR in the recipe when modifying stuff, not sure if its really needed though and if prserv would take care of this anyway Oct 22 12:46:55 Jin^eLD: I had that already. do you use upload-packages.bb to upload? Oct 22 12:47:19 no, I was actually not aware of it at all, we simply rsync the deploy dir Oct 22 13:14:27 Jin^eLD: do you use Angstrom? Oct 22 13:15:01 no, poky, well I also do use angstrom but a version thats a couple of years old (don't ask) Oct 22 13:15:51 on the ancient one we maintain the PRs manually, on poky we use prserv Oct 22 13:30:00 soo.. any hints on my image question? Oct 22 13:30:04 anyone? :) Oct 22 13:31:07 Jin^eLD: it should already work like that; which version of the build system are you using? Oct 22 13:32:18 BitBake Build Tool Core version 1.28.0 Oct 22 13:32:23 yocto jethro branch Oct 22 13:32:53 the image sets an initramfs task to nostamp, wouldn't that mean that stuff always gets rebuilt because of that? Oct 22 13:33:16 image.bbclass:do_bundle_initramfs[nostamp] = "1" Oct 22 13:33:44 ah yes, it would Oct 22 13:34:15 but I can override that in a recipe I guess? Oct 22 13:34:31 I'll just try :) Oct 22 13:36:06 it's possible but tricky Oct 22 13:36:13 but is that really what's causing this? Oct 22 13:36:30 do_bundle_initramfs comes *after* do_rootfs, not before, so it wouldn't be retriggering do_rootfs Oct 22 13:36:53 Jin^eLD: ^ Oct 22 13:41:36 hmm Oct 22 13:41:43 let me have another closer look at it Oct 22 13:42:50 what am I looking for btw? would I already see via -e if something tells it to build another image? Oct 22 13:45:24 Jin^eLD: you wouldn't necessarily be able to see in -e Oct 22 13:45:42 Jin^eLD: what tasks exactly are running? only do_rootfs or also other tasks? Oct 22 13:46:49 whats the best way to track the tasks? just by looking in workdir/temp or watching the build? Oct 22 13:47:08 log.task_order seems useful Oct 22 13:47:19 you can see the tasks that ran in the last build by looking at the cooker log in tmp/logs/ Oct 22 13:48:20 uhh.. these are named by timestamps Oct 22 13:49:11 ok I think I found it Oct 22 13:49:14 ls -ltr ;) Oct 22 13:49:34 we probably could do with a symlink in there to the latest though Oct 22 13:50:56 from what I can see it goes something like that: Oct 22 13:50:56 do_rm_work, do_rootfs, do_build, do_rm_work, do_rm_work_all Oct 22 13:52:18 oh, rm_work Oct 22 13:52:26 that's probably what's doing it Oct 22 13:52:48 to check that you could set RM_WORK_EXCLUDE = "your-image" Oct 22 13:53:21 well, += just in case it's set somewhere else as well Oct 22 13:53:34 ok let me try, but one question though - rm_work does not seem to have that effect on "regular" packages? Oct 22 13:54:40 i.e. an ipk won't get rebuilt because of that Oct 22 13:54:42 but an imgae will? Oct 22 13:57:06 Jin^eLD: images are quite different from regular recipes though Oct 22 13:57:26 it did the trick, thank you! Oct 22 13:57:29 I'm not a regular user of rm_work so I can't say for sure if it's definitely the cause, but it's easy to test Oct 22 13:57:31 ah ok Oct 22 13:57:37 I first tried to do it directly inside a recipe, that did not work, but setting it in local.conf did it Oct 22 13:57:42 you could argue that's a bug Oct 22 13:57:55 should I? :) Oct 22 13:58:09 the fact that rm_work forces rebuilding the image, I mean Oct 22 13:58:14 ah Oct 22 13:58:26 well, that indeed Oct 22 13:58:33 it was not obvious at all that this was the reason Oct 22 13:58:41 and I was looking in all the wrong places Oct 22 13:58:53 do you suggest bugzilla or ml? Oct 22 13:59:16 bugzilla I would say Oct 22 13:59:29 btw when you say you set it in a recipe do you mean the image recipe itself? Oct 22 13:59:47 yes, I tried that first because I wanted to keep the logic in the recipe Oct 22 14:00:04 RM_WORK_EXCLUDE += "${PN}" Oct 22 14:00:16 that did not do it, only local.conf did Oct 22 14:00:23 with the recipes name as string Oct 22 14:00:48 hmm, that is interesting Oct 22 14:01:05 you mean that should have worked also? Oct 22 14:01:13 setting it in the recipe directly, I mean Oct 22 14:05:06 bluelightning: what component is it, bitbake or meta-yocto? I never seem to pick the right one... Oct 22 14:06:39 FWIW, it's almost never meta-yocto Oct 22 14:06:46 :) Oct 22 14:06:48 OE-Core, perhaps Oct 22 14:07:28 as to whether setting it in the recipe ought to have worked, I'm not sure... it looks like possibly it should have but I've not read the class too closely Oct 22 14:08:10 I'll have a separate look at that, I guess these are two different issues anyway Oct 22 14:21:08 Jin^eLD: btw, it was you who sent a patch a while back to implement multi-kernel support right? Oct 22 14:22:10 yes Oct 22 14:22:16 I think I'll have another go at this Oct 22 14:22:27 are you still using that? Oct 22 14:22:38 but I wanted to talk to someone first, first reaction was a hesitation in regard to fearing to break other stuff Oct 22 14:22:43 yes, I do Oct 22 14:22:57 but I chaned it currently in a way that I simply copied the classes Oct 22 14:23:00 and altered them Oct 22 14:23:09 instead of hacking it into the existing ones Oct 22 14:23:16 thats a bit easier to maintain when updating poky Oct 22 14:23:26 ah, ok, so the changes would need to be rebased then Oct 22 14:23:52 depending on which it will go... Oct 22 14:24:06 if people are OK with integrating it into the main classes then I would have to adapt some things Oct 22 14:24:08 https://git.digitalstrom.org/dss-oe/dss-oe/tree/master/yocto/dS/meta-digitalstrom-devel/classes Oct 22 14:24:20 *altkernel*.bbclass are the files Oct 22 14:24:49 I also had to tune/rename a couple of .inc files for the kernel Oct 22 14:25:16 so basically my "alternative" kernel does not inherit the stock kernel class, but inherits my "altkernel" class Oct 22 14:25:39 ah ok Oct 22 14:26:03 what would you suggest in terms of getting it upstream? Oct 22 14:26:36 separate classes means a lot of code duplication; at the same time the concerns of breaking stuff for everyone by changing the stock classes is also legit Oct 22 14:27:08 it also required more hacks to get the names right when using one class for alls scenarios Oct 22 14:27:52 I'm really not sure how to go about this, but I'd very much like to have it merged upstream at some point Oct 22 14:31:23 well, we probably need more tests for the kernel classes; that way we'd be able to tell if something had regressed Oct 22 14:32:02 so the overall direction would be to again try merging it into one class and resubmitting to the ml? Oct 22 14:33:07 I kind of think we'd want to have it in the one class, but then I'm probably not the best person to ask since I fairly rarely have to deal with the kernel build process directly Oct 22 14:33:36 I wanted to get some thoughts from RP but did not manage to catch him "awake" on IRC yet Oct 22 15:18:29 Jin^eLD, bluelightning: We definitely want to change the current class Oct 22 15:18:42 * RP is just lacking bandwidth to think about that issue in depth atm Oct 22 15:19:17 RP: when would be a good time to bother you with that? :) Oct 22 15:19:39 I want to prevent starting in a wrong direction Oct 22 15:20:32 Jin^eLD: I'm not Richard, but I'd say post an RFC on the list again after the 2.0 release (which should happen very soon) Oct 22 15:23:23 right, after 2.0 is done would be best Oct 22 15:23:55 ok, then I'll try to merge stuff from my separate classes back into the stock *kernel* classes and try my luck on the ML again Oct 22 15:25:50 ugh - sorry folks, I suck at computers and just spammed the oe-core list with a 52 patch series instead of my ~7 actual changes Oct 22 15:25:58 * joshuagl decides he should call it a day Oct 22 15:26:44 joshuagl: ah, now I know your IRC nickname ;) my mailbox was exploding :> Oct 22 15:27:42 I made changes on top of jethro and let the scripts compare it to master - my bad Oct 22 15:29:31 joshuagl: you want confirm=always on if it isn't already ;) Oct 22 15:30:01 oops Oct 22 15:30:24 * joshuagl hangs head a little further down Oct 22 15:30:33 somehowI think that should be the default Oct 22 15:32:15 I think it did ask me but I wasn't paying enough attention Oct 22 15:32:30 I *did* want to send patches to the list, after all Oct 22 15:32:52 can't blame the tools here, most defintely me Oct 22 15:33:28 could be your branch wasn't configured to track jethro, so the script chose the wrong default, i think it uses git's tracking info to choose that, anyway Oct 22 15:33:30 not sure, though Oct 22 15:35:06 it's ok, you can just call me an idiot :-) Oct 22 15:35:11 heh :) Oct 22 15:35:52 * joshuagl decides not to try and send the patches again until tomorrow Oct 22 15:36:46 that will give rburton time to disagree with me *and* call me an idiot before I send another iteration Oct 22 15:44:11 belen, congratulations, also on being Saturday Oct 22 15:45:15 joshuagl, that takes time :) Oct 22 15:45:36 joshuagl: haha Oct 22 15:46:07 Crofton|road: and congratulations to you too :) Let's see if we can work out how to use the damned camera this time Oct 22 16:08:41 otavio: no Oct 22 17:09:13 hmm, I wrote a .bbclass with a shell function and I used addtask to hook it in... and its not being executed, what am I missing? Oct 22 17:12:36 addtask accepts the name without do_, but the function needs the do_. also, make sure your deps make sense Oct 22 17:12:44 adding a task won't make it run by default unless you specify with -c Oct 22 17:12:53 unless you add it before another task that's already being built Oct 22 17:13:07 I did: addtask do_upload after do_rootfs Oct 22 17:13:22 oh crap Oct 22 17:13:26 the do.. Oct 22 17:13:30 :) Oct 22 17:13:58 I always mix that up Oct 22 17:14:34 yeah, common issue :\ Oct 22 17:15:14 actually I was aware of it but did not see it until I pasted the addtask line here Oct 22 17:15:26 hm, it still did not work though Oct 22 17:15:43 you didn't hook it into the default deps, as i just said Oct 22 17:15:54 you'd have to -c upload Oct 22 17:16:03 if you want it run by default, you'd have to add 'before do_build' Oct 22 17:16:08 wait, but is do_rootfs not part of the default deps? Oct 22 17:16:10 (do_build being the default task) Oct 22 17:16:23 yes, but do_rootfs doesn't depend on do_upload, it's the other way around Oct 22 17:16:26 I need it to run after do_rootfs Oct 22 17:16:36 all 'after' means is that the thing after depends on the thing before Oct 22 17:16:40 it won't magically run when that runs Oct 22 17:17:04 as i said, tasks won't run by default unless one of the tasks already being run depends on it Oct 22 17:17:06 so do_rootfs runs before do_build as well? Oct 22 17:17:11 it does, read image.bbclass Oct 22 17:18:34 indeed... I see it now Oct 22 17:19:16 yep, adding the "before" did the trick, thank you Oct 22 17:23:58 np Oct 22 17:42:19 am I wrong or is it the case that if some command in a shell task returns non zero exit code then my script gets nuked before I can even check the retcode of my call and act upon it? Oct 22 17:43:00 and is there a way to work around that? because otherwise I can't do what I am supposed to... Oct 22 17:43:33 from what I can see it's trapped by bb_exit_handler Oct 22 17:44:22 no, bb_exit_handler just shows info about teh failure Oct 22 17:44:26 set -e is what makes it exit on non-zero Oct 22 17:44:43 you can either disable that, or use a boolean operation to capture it Oct 22 17:45:01 i.e. ret=0; false || ret=$? Oct 22 17:45:19 sincet here s a|| there, the failure of false won't exit the script, it'll run the other part instead Oct 22 17:45:49 hmm I'd have to do that on quite a lot of occasious Oct 22 17:45:53 how do I disable -e? Oct 22 17:46:06 and can I disable it only for my task? Oct 22 17:46:21 *occasions Oct 22 17:47:49 ndec, did you have a patch to update mesa? I built with llvmpipe, but it segafulta Oct 22 17:48:08 Jin^eLD: set +e Oct 22 17:48:33 oh, you mean just in the task directly... did not think of that :) Oct 22 17:48:36 yes Oct 22 17:48:48 but it'll affect the entire shell process afaik, so if that function calls others, those would keep that setting Oct 22 17:48:53 so keep that in mind Oct 22 17:48:56 i dont think its function-local Oct 22 17:49:12 ok, thank you Oct 22 17:49:12 but it will be isolated to the task, clearly, since each task gets its own shell script Oct 22 17:49:14 np Oct 22 17:50:08 all worked fine now, thanks one more time :) Oct 22 17:50:09 l8r Oct 22 17:50:30 np Oct 22 17:55:09 kergoth: any plans for scale presentation maybe? Oct 22 18:52:18 I just got laughed out because we use llvm-3.3 Oct 22 18:52:45 with mesa and llvmpipe backend Oct 22 19:03:45 any llvm gurus around? Oct 22 19:05:14 khem, ping Oct 22 19:05:29 I need to use llvm-3.7 in oe-core Oct 22 19:05:40 to test a mesa issue Oct 22 19:21:50 Crofton: hmm Oct 22 19:22:09 Dont we have a version in meta-oe Oct 22 19:22:13 any suggestions how to proceed Oct 22 19:22:18 only for 3.3 Oct 22 19:22:21 use meta-clang Oct 22 19:22:26 to build it Oct 22 19:22:43 so add meta-clang and things shoudl work Oct 22 19:22:45 but disable the TOOLCHAIN choosing clang Oct 22 19:22:53 there is theis LLVM verison variable Oct 22 19:22:55 not straight out of box Oct 22 19:23:12 since meta-clang is more about clang then just llvm Oct 22 19:23:16 yeah Oct 22 19:23:21 I went through there Oct 22 19:23:21 but it does build llvm Oct 22 19:23:37 currentlyy looking at the llvm recipe in meta-oe Oct 22 19:23:38 which you could use Oct 22 19:23:56 you need to disable it becoming default compiler Oct 22 19:24:21 so it just builds and done nothing else Oct 22 19:24:54 who do I do that? Oct 22 19:26:50 in meta-clang itself or local.conf Oct 22 19:27:08 set TOOLCHAIN = "gcc" Oct 22 19:27:15 in local.conf Oct 22 19:27:23 k Oct 22 19:28:01 it would be nice to get 3.7 into meta-oe Oct 22 19:28:11 especially if this solves my problem Oct 22 19:38:55 ok added meta-clang and set toolchain var, now lets see what happens when i run bitbake llvm Oct 22 19:40:07 ERROR: Nothing PROVIDES 'llvm'. Close matches: Oct 22 19:40:08 lvm2 Oct 22 19:40:08 llvm3.3 Oct 22 19:53:01 Crofton: llvm update is for the issue we both had? Oct 22 19:53:24 hmm. no. that's when you tried llvmpipe, i guess. Oct 22 19:56:36 llvmpipe segfaults on glxgears Oct 22 19:56:48 the suggestion is try llvm-3.7 Oct 22 19:57:57 I copied the llvm3.3 reciep to 3.7 and hacked a little Oct 22 19:58:11 I'lls let you guys works Oct 22 19:58:23 worst is license file checksom changed and it is in .inc file Oct 22 20:12:46 hi folks, just sent the patch fixing VLC build if "freerdp" is built in the same image : http://lists.openembedded.org/pipermail/openembedded-devel/2015-October/103990.html Oct 22 20:13:06 ERROR: debugedit failed with exit code 256 (cmd was '/home/balister/e300-oe-build/build/tmp-glibc/sysroots/x86_64-linux/usr/lib/rpm/bin/debugedit' -b '/home/balister/e300-oe-build/build/tmp-glibc/work/armv7ahf-vfp-neon-oe-linux-gnueabi' -d '/usr/src/debug' -i -l '/home/balister/e300-oe-build/build/tmp-glibc/work/armv7ahf-vfp-neon-oe-linux-gnueabi/llvm3.7/3.7.0-r0/debugsources.list' '/home/balister/e300-oe-build/build/tmp-glibc/work/arm Oct 22 20:13:06 v7ahf-vfp-neon-oe-linux-gnueabi/llvm3.7/3.7.0-r0/package/usr/bin/llvm3.7.0/arm-oe-linux-gnueabi-llc'): Oct 22 20:13:06 /home/balister/e300-oe-build/build/tmp-glibc/sysroots/x86_64-linux/usr/lib/rpm/bin/debugedit: canonicalization unexpectedly shrank by one character Oct 22 20:13:20 rpm wtf? Oct 22 20:14:32 otavio: is Qt5.5 working for the i.mx6q? Oct 22 21:48:32 otavio: quick follow up on my own query. looks like andreas posted a patch to fix the latest Qt5.5 platform configuration style **** ENDING LOGGING AT Fri Oct 23 02:59:58 2015