**** BEGIN LOGGING AT Wed Dec 04 02:59:58 2013 Dec 04 07:04:46 calling chmod from recipe file Dec 04 07:06:05 is it possible to call chmod from recipe file? Dec 04 07:39:52 hi i have been using poky with meta-atmel,i used qt4 when i try to build a rootfs it shows me this error http://pastebin.com/mwhF8uW8 can you help me Dec 04 08:08:18 How to make ssh_config readonly while packing to rootfs Dec 04 09:11:14 Hello! I'm running yocto on a gumstix - overo board on the dora branch. I'm developing an application that uses bluetooth, and i'm using bluez for this. I've had problems with a crash on both bluez4.101 and bluez5.11 . The bluez main developer recommended me to upgrade linux kernel version to 3.10.x. Dec 04 09:12:14 Is there a "simple" way of doing that in yocto, without messing every dependency up? (I'm quite new to yocto...) Dec 04 09:28:06 erija952_, if you're building linux-yocto kernel, you probably want to set PREFERRED_VERSION_linux-yocto variable Dec 04 09:28:44 hi! what package is "depmod" provided by? I want to opkg install kernel-module- on the target but postinstall complains that depmod is missing. Is there any dedicated IMAGE_FEATURE supporting that? Dec 04 09:28:51 erija952_, see http://www.yoctoproject.org/docs/1.1/poky-ref-manual/poky-ref-manual.html#var-PREFERRED_VERSION Dec 04 09:33:48 bukington: Thanks for the help! We just found out that there is quite alot of patches on the current kernel for our overo board, so we'll try something else first Dec 04 10:01:57 ok... my fault! I had an error in my image recipe. now /sbin/depmod is there as expected Dec 04 10:40:44 morning all Dec 04 12:02:36 How can I make ssh_config read only while packing to rootfs Dec 04 12:02:42 ?? Dec 04 12:23:48 luke88: are you using Linux 'install' command to put sshd_config to /etc/ssh ? if so you can just set proper permissions there Dec 04 12:31:59 trying to build an app called 'xpra'; it's built in a weird way - setup.py instead of Makefile Dec 04 12:32:22 so what do I do in compile and build steps just call that script Dec 04 12:32:46 unfortunatelly python from host is called instead of Yocto python-native Dec 04 12:33:14 what's the trick to force recipe to use Yocto's python instead of the global one? Dec 04 12:34:39 Hi, I could use a little help. Is there a way to RDEPEND on a busybox specific config? For example I would like to craete a recip, that depends on cron, but if I set RDEPEND to cron, then as I understand it will depend on the full version of cron, but in reality I would like to use busybox's internal cron. Dec 04 12:36:49 chocis: there is no built-in way to check for enabled busybox config options no Dec 04 12:38:02 chocis: bluelightning: python anonymous? :) Dec 04 12:38:03 thnx, ok, then what could be a solution or warning if someone includes my recipe which should depend on cron (in exapmle) Dec 04 12:38:40 Krz-: that would assume you can read it from somewhere without touching busybox's WORKDIR (which wouldn't be correct); I don't think it gets staged anywhere Dec 04 12:39:14 Krz-: in answer to your question, your recipe should inherit perlnative Dec 04 12:39:40 bluelightning: on top of that this magic setup.py uses not very common extension called 'cython' Dec 04 12:39:43 Krz-: but actually if the recipe uses python setuptools or distutils you should just inherit the class for that and that should take care of running setup.py Dec 04 12:39:52 bluelightning: is there any way to add extensions to python-native? Dec 04 12:40:21 Krz-: you'd need a separate recipe for that I think Dec 04 12:40:55 bluelightning: like python-cython-native? makes sense Dec 04 12:42:56 Krz-: there is already a python-cython recipe in meta-oe, presumably you'd just need to BBCLASSEXTEND it to native Dec 04 12:43:04 bluelightning: regarding 'setuptools' - I just inherit it and that's it? Don't I need to do sth like '$PYTHON /my/dir/setup.py'? Are all variables automatically set after inheriting ? Dec 04 12:43:41 Krz-: no, just inheriting should be enough Dec 04 12:44:40 bluelightning: I run yesterday that webbrowser - midori or whatever it is Dec 04 12:44:48 bluelightning: works nice, but crashes for some websites Dec 04 12:45:08 bluelightning: as for manual - they recommend using eglibc 2.18 :) (mine is 2.17 - dylan) Dec 04 12:45:37 bluelightning: so I copied eglibc 2.18 from dora to my layer Dec 04 12:45:51 bluelightning: didn't check it yet, but overall experience so far is very positive Dec 04 12:46:11 Krz-: sshd_config is being taken from openssh_6.1p1.bb of poky and then packed to rootfs Dec 04 13:13:44 hello Dec 04 13:14:10 from one day to the other, out of nowhere, im getting clean yocto build breaking: eglibc/eglibc_2.18.bb, do_compile) failed with exit code '1' Dec 04 13:15:23 it compiled fine before.. Dec 04 13:37:49 sledges: can you pastebin the full error? Dec 04 13:47:42 bluelightning: yocto/build/tmp/work/armv7a-vfp-neon-poky-linux-gnueabi/eglibc/2.18-r0/build-arm-poky-linux-gnueabi/shlib.lds:150: syntax error Dec 04 13:51:38 sledges: hmm... odd Dec 04 13:51:49 khem: any ideas? ^ Dec 04 13:53:32 luke88: take a look at 'do_compile_append' step inside openssh_6.1p1.bb file Dec 04 13:54:04 luke88: it does "install -m 0644 ${WORKDIR}/sshd_config ${S}" Dec 04 13:54:21 luke88: just figure out what chmod you want to set and do it there Dec 04 14:04:57 luke88: if you want read-only for everybody that would be '0444' instead of '0644' Dec 04 14:12:36 is there anywhere some good manual for all Yocto variables? Like ${WORKDIR}, ${S}, ${PN}, etc. I'd like to print them since I always forget ... Dec 04 14:17:48 bluelightning: how can this happen from same state? do online tarballs change? or version change? Dec 04 14:19:05 Krz-: the reference manual: http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#ref-variables-glos Dec 04 14:21:03 sledges: the build system is based around task signatures; if something that eglibc's do_compile depends upon is modified (i.e. a variable value or another task), then that task will be re-executed Dec 04 14:23:22 bluelightning: but i've removed build, and rebuilt Dec 04 14:23:31 build of 5 days old built core-image-minimal fine Dec 04 14:23:37 and the fresh new one of today doesnt Dec 04 14:24:07 sledges: so nothing changed in between times? Dec 04 14:24:11 no Dec 04 14:24:13 just time Dec 04 14:24:15 :| Dec 04 14:24:23 yes krz: we tried setting to 0444 but doesn't change permission Dec 04 14:24:49 sledges: ok, in this instance it's possible that it's a parallel build race (as suggested when googling for this error) Dec 04 14:24:57 sledges: which would mean it would work sometimes and not others Dec 04 14:24:57 ah Dec 04 14:25:06 now it failed two times in a row Dec 04 14:25:11 on same place Dec 04 14:25:33 i think i built kernel before Dec 04 14:25:37 and then core image Dec 04 14:25:39 this is where we need khem's advice really Dec 04 14:25:39 i could do that again Dec 04 14:29:41 bluelightning: wow there are quite few of them. will not fit on one sheet :| Dec 04 14:30:00 Krz-: well, some are much less important for normal usage than others Dec 04 14:35:57 bluelightning: to take advantage of BBCLASSEXTEND do I do 'python-cython.bbappend' or 'python-cython-native.bbappend' or 'python-cython-native.bb' in my layer? I hope I don't have to change meta-oe files. Dec 04 14:36:31 Krz-: the bbappend file name must match up with the recipe file name Dec 04 14:37:14 bluelightning: so python-cython.bbappend will "export" python-cython-native name eventually? Dec 04 14:37:32 Krz-: BBCLASSEXTEND = "native" is what makes that happen, yes Dec 04 14:39:35 bluelightning: cool, Yocto rocks Dec 04 15:34:30 Hi all, Any idea about this error? Error: udisks-systemd not found in the base feeds Dec 04 15:35:38 my build fails with udisks-systemd not found in the base feeds error? Dec 04 15:36:13 your base feed (the package feed in tmp/deploy/) doesn't contain a package called "udisks-systemd" Dec 04 15:36:29 so either you haven't built it, or udisks doesn't build a package called that Dec 04 15:38:09 rburton: Do I need to add udisks recipe for that? Dec 04 15:38:46 genuinely no idea, i've never built udisks and don't know what your building. the image shouldn't have failed earlier if you hadn't built udisks Dec 04 15:39:19 but you can try building udisks directly and seeing if that helps Dec 04 15:41:08 rburton: I am just building gumstix-console-image from gumstix-github-repo. previously I had old yocto version and I didn't get this error, but strange now it thows this. Dec 04 15:42:55 There are two udisks recipes available, which one should I include in my Image? (http://layers.openembedded.org/layerindex/branch/master/recipes/?q=udisks) Dec 04 15:49:23 There is a recipe of udisks in meta-oe, it got downloaded in /tmp/work , but gives this error on final build. Dec 04 17:53:45 OT, but damn I hate when a project checks in a lot of code with broken builds, which makes it nearly impossible to accurately bisect a problem Dec 04 17:53:48 * kergoth mutters Dec 04 18:17:40 behanw: ! Dec 04 18:21:28 mranostay, !?! Dec 04 18:22:23 behanw: dueling exclamation points!?!? :) Dec 04 18:22:43 It seemed the appropriate response. ;) Dec 04 18:22:50 ⸘‽ Dec 04 18:24:06 fancy Dec 04 18:25:35 can I set any env variables from a Yocto recipe? :) Dec 04 18:26:04 export FOO = "bar" -- now FOO is set to bar in the env of any shell tasks Dec 04 18:29:29 http://www.youtube.com/watch?v=Sz0o9clVQu8 Dec 04 18:35:27 kergoth: btw - bug 5627 Dec 04 18:35:28 Bug https://bugzilla.yoctoproject.org/show_bug.cgi?id=5627 enhancement, Undecided, ---, paul.eggleton, NEW , Detect and fail when S has been set incorrectly Dec 04 18:36:04 nice, that's been a really long standing annoyance Dec 04 18:36:57 kergoth: indeed, it was your mention of it a month or so ago that prompted me to file the bug ;) Dec 04 18:37:36 ah, right :) Dec 04 18:40:44 bluelightning: Hmm, if we remove ${S}/${B} from 'dirs', we'd have to figure out a different way to get bitbake to chdir there, either try hacking something with prefunc perhaps, or adding a new bitbake flag to differentiate dirs to create from dir to cd to. do_compile[cwd] ?= "${@d.getVarFlag('do_compile', 'dirs', True).split()[-1]}" or somesuch Dec 04 18:40:58 hm :) Dec 04 18:42:09 this is much earlier than do_compile though Dec 04 18:43:18 I couldn't seem to find out where it was first being created... even after do_fetch it seems to be there Dec 04 18:43:38 I just didn't dig deep enough obviously Dec 04 18:45:51 bluelightning: oh, I know what's doing that, in fact i think I even have a bug open for it. bitbake internally has a fallback to ${B} if the 'dirs' flag isn't set at all on a function Dec 04 18:46:01 very bad internal knowledge of oe Dec 04 18:46:23 i had a case where a do_unpack failed if the dest already existed, so it was racing with one of the sstate functions Dec 04 18:46:36 (yes, even prefuncs and stuff can create ${B} if they dont have dirs set..) Dec 04 18:46:37 whoops. Wrong channel. :) Dec 04 18:47:09 though, maybe richard fixed that one Dec 04 18:47:16 could be something else then, *shrug* :) Dec 04 18:47:32 ah, nope, it's still there it seems Dec 04 18:47:43 else: adir = d.getVar('B', True) Dec 04 18:47:46 in bb.build.exec_func Dec 04 18:48:34 bug 4634 Dec 04 18:48:36 Bug https://bugzilla.yoctoproject.org/show_bug.cgi?id=4634 normal, Medium, 1.6, richard.purdie, NEW , BitBake default 'dirs' in exec_func (${B}) causes build failures Dec 04 18:48:47 there it is, might need to fix that before 5627 Dec 04 18:49:14 kergoth: ah, thanks... I'll add it as a blocker Dec 04 18:49:24 np Dec 04 19:35:38 dumb question: how do you figure out the git branch from the yocto version number. Or vice versa. Dec 04 19:36:38 the git branch is the release's code name. presumably there's a page documenting the code names, or in the release notes, not sure Dec 04 19:39:21 That page/info is what I can't find Dec 04 19:40:01 google for yocto 1.5 release notes, https://www.yoctoproject.org/download/yocto-project-15, under version "10.0.0 "Dora" Dec 04 19:40:04 " Dec 04 19:40:09 works for one version at a time, anyway Dec 04 19:46:02 thanks. add the release notes to search and it gets what I wanted. Google foo is nice when it works. Dec 04 19:56:59 blloyd: heh, indeed. np Dec 04 22:26:16 hmm, Exception: KeyError: 'PKGV' in buildhistory_emit_pkghistory. odd Dec 04 23:09:34 kergoth: hmm, that sounds like it would be my fault :/ Dec 04 23:10:46 this is stock master, not sure if that has your latest patchset merged or not, though Dec 04 23:10:50 doesn't look like it Dec 04 23:11:01 it was merged, just yesterday Dec 04 23:11:13 ah, i'll make sure i'm current Dec 04 23:11:16 but why would PKGV not be present... Dec 04 23:11:32 ah, indeed. Dec 04 23:11:41 where is the keyerror? Dec 04 23:11:48 not a clue. something related to use of existing sstates with old pkgdata? *shrug* Dec 04 23:12:07 pkgv = pkgdata['PKGV'], just before 'Find out what the last version was' Dec 04 23:12:35 could be, but none of my changes were about ensuring PKGV is present Dec 04 23:12:39 perhaps that's the problem... Dec 04 23:12:57 this recipe does define its own PKGV, both the global unsuffixed and a number of individual packages, don't know if taht's a factor or not Dec 04 23:13:06 (it's meta-sourcery's external toolchain) Dec 04 23:13:24 * kergoth forces a build from scratch Dec 04 23:14:00 k, not realted to sstate, good to know Dec 04 23:14:26 * kergoth shrugs, gets back to work Dec 04 23:18:34 kergoth: can you double-check, does the pkgdata file for that package have PKGV_: rather than PKGV: ? Dec 04 23:19:31 well, check, not double-check :) Dec 04 23:23:17 okay, some of the pkgdata have just PKGV, others have PKGV_ Dec 04 23:23:36 ahh, right Dec 04 23:23:48 okay, every package that has a PKGV_ did indeed emit that variable, nt PKGV Dec 04 23:23:51 s/nt/not/ Dec 04 23:23:54 seems my code is a bit naive then Dec 04 23:25:48 seems a bit redundant to emit a suffixed var toa file that's already named after the package :) Dec 04 23:28:18 yes, I've never really understood that Dec 04 23:29:19 well, I guess it was probably designed to indicate where the value was set, i.e. for the package or the recipe Dec 05 00:02:12 I suspect its due to the way we read the data back in Dec 05 00:02:37 I'm not going to claim that is a good reason, it just evolved that way Dec 05 00:10:47 RP: I'll have a patch ready for the reading tomorrow Dec 05 00:11:38 bluelightning: thanks Dec 05 00:11:51 * RP just might have found a better way to make fortran build Dec 05 00:13:51 * bluelightning heads to bed **** ENDING LOGGING AT Thu Dec 05 02:59:58 2013