**** BEGIN LOGGING AT Fri Nov 22 03:00:00 2013 Nov 22 09:50:42 morning all Nov 22 10:18:19 hi there. what is the difference between $FOO and ${FOO}? I am using like this SRCREV = "${FOO}" which does what i wanted, while SRCREV = "$FOO" does not.. i am curious to understand why.. Nov 22 10:19:25 the context Nov 22 10:19:44 in bitbake assignments you use ${FOO} Nov 22 10:20:18 $FOO in a variable value isn't going to do anything unless the variable value makes it into a shell function Nov 22 10:20:26 that's an immediate assignment? Nov 22 10:21:08 $FOO is shell, so you can see comedy postinsts which use both ${FOO} and $FOO Nov 22 10:21:11 the slight quirk is, if ${FOO} appears in a shell function and FOO is not set in bitbake's datastore, it will be left unexpanded and the shell will expand it instead Nov 22 10:21:16 because they'll get expanded differently Nov 22 10:21:25 bluelightning: oh, ouch Nov 22 10:21:38 bluelightning: presumably too late to change that crazy behaviour? Nov 22 10:21:50 ok. i see. i am setting the vars in bitbake, so i should be fine. Nov 22 10:21:55 so it's best to avoid ${...} in shell functions when you don't mean to refer to a bitbake variable Nov 22 10:22:09 in fact i have several recipes that come from the same SVN, i wanted to 'share' the SRCREV. Nov 22 10:22:17 (assuming the ... is just a straight variable name) Nov 22 10:24:18 rburton: yes, way too late unfortunately Nov 22 11:24:54 hi all Nov 22 11:26:24 hi pb_ Nov 22 11:26:45 morning bluelightning Nov 22 11:42:04 hi all, hi bluelightning , hi pb_ Nov 22 11:43:38 hi silvio_ Nov 22 13:29:00 hmm 2 builds from same metadata built on 2 servers with different umask have different permissions on many files, is it expected? Nov 22 13:29:23 which files? Nov 22 13:30:13 we have fixed one case when os.mkdir wasn't respecting selected permissions, because it respected umask Nov 22 13:30:16 http://git.openembedded.org/openembedded-core/commit/?id=f91226553e39439bfd17ab2b06c56cb8bf41061b Nov 22 13:30:53 a lot of them, let me find something from public layers or build core-image Nov 22 13:32:08 I did 2 identical builds with only system umask change between them and resulting files-in-image.txt files have 55642 changes, mostly from group permissions (umask changed from 0022 to 0002) Nov 22 13:32:18 that's definitely a bug Nov 22 13:32:41 there are some things that are meant to respect your umask (e.g. the files in sstate) but anything that goes into the image ought to be independent of that. Nov 22 13:32:59 what if some recipe just calls mkdir in do_install? Nov 22 13:33:12 base.bbclass sets umask to 022 before running do_install. Nov 22 13:33:28 (and do_package, and do_configure, and do_compile) Nov 22 13:33:32 ah ok Nov 22 13:33:45 let me find where those files were created Nov 22 13:33:51 so, either that is being defeated somehow, or your files are being created by some other task that isn't covered there. Nov 22 13:34:26 heh, they are different in git checkout already Nov 22 13:34:57 oh, they are files that get installed from a local file:/ URI? Nov 22 13:35:09 pb_: do you know if quboid is going to send out a patch for the remaining bundle_initramfs issue? Nov 22 13:35:21 :q! Nov 22 13:35:23 usp Nov 22 13:35:26 RP: oh, I thought he had. I will ask him. Nov 22 13:35:51 pb_: he sent out a version at the bottom of an email, I thought it was for discussion and the tested patch would follow? Nov 22 13:38:09 pb_: checked out from local clone in downloads/git2 Nov 22 13:38:43 mac_: pb_: do you know if quboid is going to send out a patch for the remaining bundle_initramfs issue? Nov 22 13:38:46 pb_: he sent out a version at the bottom of an email, I thought it was for discussion and the tested patch would follow? Nov 22 13:39:17 pb_: Ta. Nov 22 13:39:45 I should say that this is in dylan build Nov 22 13:40:38 I'll try to reproduce with master, but it looks like it's from git2 fetcher code Nov 22 13:40:38 PR: My testing of the bundle_initramfs sstate patch went fine but since we don't use the feature I was wary of posting the patch without anyone else testing it. Nov 22 13:40:51 RP: Would you like me to post it as an RFC patch? Nov 22 13:41:08 mac_: if you could remove that [nostamp] line I mentioned and send it out, yes please Nov 22 13:41:40 mac_: At this point its breaking all kernel builds from sstate so I will probably merge it and see if anyone complains Nov 22 13:41:54 RP: OK, I'll do that this afternoon. Thanks. Nov 22 13:42:54 pb_, mac_: thanks Nov 22 13:46:53 RP, pb_: It looks like 3baa63b4d588c3262254528b406ede265dd117bf has gone in the intervening time. It looks broken to me - do_kernel_link_vmlinux is only in kernel-yocto. :( Nov 22 13:47:16 oh, I did wonder about that. I got a conflict there when I did that merge a few minutes ago. Nov 22 13:48:10 Even if it weren't bogus it still wouldn't be enough because do_install can still race against do_bundle_initramfs since they both call into the kernel build system. Nov 22 13:48:45 So, perhaps we should revert that one and then apply mine which adds the task after do_install which should fix their problem too. Nov 22 13:49:55 mac_: that one isn't wrong per say, yours just fixes a load of other issues too Nov 22 13:51:02 RP: Really? But what about people not using kernel-yocto? Nov 22 13:51:23 mac_: that is a kernel-yocto specific task? ouch, that is nasty Nov 22 13:51:40 RP: Indeed. Nov 22 13:52:07 RP: I'll post a two patch series - one reverting that one and then my patch afterwards. I think that's the clearest thing to do for the history. Agreed? Nov 22 13:52:33 mac_: yes, sounds good Nov 22 13:52:43 mac_: I hadn't noticed that task was kernel-yocto specific Nov 22 13:52:57 We really need more eyes on patch review as I can't catch everything Nov 22 13:53:02 RP: I didn't initially either. Nov 22 13:53:52 mac_: it gets inserted before do_install so your patch should work fine with it Nov 22 13:54:03 RP: Yes. Nov 22 14:06:34 RP: Posted, except I appear to have ended up with the wrong email address in the signed-off-by lines. :( Nov 22 14:07:04 RP: I'll re-send if you and pb_ can't find anything else wrong with them. Nov 22 14:10:00 mac_: looks good, perhaps just add in the commit message that the nostamp was dropped since it was unnecessary and caused pointless rebuilds (we're happy enough to rely on the sstate checksum stamps to know when to rebuild) Nov 22 14:11:48 RP: OK, will do. Nov 22 14:25:34 RP: I re-worded the commit message quite a bit. Hopefully it's a bit clearer now. Nov 22 14:35:24 mac_: looks good, thanks. I'll take it for a spin in master-next Nov 22 14:37:13 RP: No problem. Nov 22 16:35:23 is anyone using the image-mklibs class? i quickly tried to enable it, and mklibs fails with some weird errors.. so before spending to much time there, i wanted to make sure that this is supposed to work.. Nov 22 16:37:27 ndec: i heard it's a bit broken when i asked what it was a few months back Nov 22 16:37:39 a bit ;-) Nov 22 16:38:51 possibly a british understatement Nov 22 16:39:11 rburton: in my case, an exception is raised since that file does not exist: lib/work/dylan-qt5.1/build/tmp/sysroots/qemuarm/lib/ld-linux.so.3 Nov 22 16:39:22 the leading 'lib' is clearly wrong. Nov 22 16:40:12 well, the linker name is wrong too. Nov 22 16:40:29 hmm, maybe that's just that.. i will look into it. Nov 22 17:22:17 rburton: ok... i got something that works... at least it doesn't crash anymore and it generates something (mklibs, that is). I found at least 2 problems, 1) the arm linker path is wrong (with armhf) in image-mklibs.bbclass, 2) mklibs doesn't add --sysroot when calling gcc, and that was causing issues in my 'multi' machine build. Nov 22 17:22:45 i will test the generated images, and send patches as appropriate next week. Nov 22 17:28:47 quit Nov 22 19:29:37 * kergoth wonders if fbset is of practical use Nov 22 19:40:22 kergoth: I've managed to use it in the past Nov 22 19:51:40 meta-oe has an fbset modes recipe. oe-core doesn't have fbset, but it does hvae busybox, which can have fbset. i wonder if the modes recipe should go in oe-core.. i think right now it just installs an empty file unless you provide a modes file in the bsp layer Nov 22 19:51:45 hmm Nov 22 19:53:51 seems like you would need that for some machines Nov 22 19:54:02 TI8168 for example Nov 22 21:21:34 anyone knows where the string returned by 'file' command is coming from? e.g. Nov 22 21:21:34 bin/busybox.nosuid: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.16, BuildID[sha1]=dc7c3a81b3ac90957018a7b255a72dc0e6b48a61, stripped Nov 22 21:21:57 i am getting an extra 'space' between LSB and executable... Nov 22 21:22:36 in dora as opposed to dylan... Nov 22 22:12:05 ndec: libmagic? Nov 22 22:12:54 mac_: hmm. from the host? Nov 22 22:13:25 when i run file xx on the host (my PC) for arm exec i built with OE with dylan or with dora, i don't get the same output. Nov 22 22:13:33 LSB executable vs LSB executable Nov 22 22:14:03 and we have a script in OE that does grep "LSB executable" ;-) Nov 22 22:14:52 see [OE-core] [PATCH 2/2] Fix grep pattern when mklibs collects executables in rootfs Nov 22 22:16:09 kergoth: ok, nice. that's needed on dora too. **** ENDING LOGGING AT Sat Nov 23 02:59:59 2013