**** BEGIN LOGGING AT Fri Jan 25 02:59:58 2019 Jan 25 03:55:11 bunch of oldies here pff Jan 25 06:53:09 New news from stackoverflow: How to run yocto developed raspberry pi image in qemu? Jan 25 09:04:24 Hi, if i would have the yocto generated sysroot to be used in separate "make", is there a recipe to generate it ? Jan 25 09:07:51 angelo_ts: can you try to rephrase? i'm not sure i understand the question Jan 25 09:17:49 LetoThe2nd, ok. Mainly. how can i export properly the yocto-generated sysroot ? Jan 25 09:18:52 angelo_ts: bitbake $YOURIMAGE -c populate_sdk generates an sdk that brings all the toolchain to run on the host plus a fitting target sysroot Jan 25 09:18:59 so thats the most obivous option Jan 25 09:23:45 LetoThe2nd, ok many thanks. I am looking for a confortable way of working in development phase. Imaging this is the proper one. Jan 25 09:25:05 angelo_ts: its an option. Jan 25 09:25:21 i personally favor devtool modify, but it depends Jan 25 09:26:38 We are using read-only /usr. I noticed that Python is rather slow... Using strace shows that it tries to open new bytecode files but can't write them (since /usr is ro). Jan 25 09:27:20 docker-compose takes 12.5 seconds to print help. If I remount /usr rw, the second time docker-compose takes only 4 seconds... Jan 25 09:28:01 There are pyc files preinstalled by OE, but it seems that python3 on the target does not like them? Any idea? Jan 25 09:44:49 LetoThe2nd, many thanks Jan 25 10:32:33 there will be anyone of you and openembedded / fosdem ? Jan 25 10:32:58 Crofton|work: ^^^^^^ Jan 25 10:47:32 angelo_ts: you are right, looks like this year we forgot to open a dedicated page http://www.openembedded.org/wiki/FOSDEM_2018 Jan 25 10:49:49 mckoan: we never forget anything. we just priotize some things so low that they never happen! Jan 25 10:49:50 created just now https://www.openembedded.org/wiki/FOSDEM_2019 Jan 25 10:50:01 LetoThe2nd: LOL Jan 25 10:53:40 very nice :) thanks. I may bring a m68k/coldfire board with kernel built by Yocto, just need to setup things properly Jan 25 10:54:38 sounds quite necrophile (SCNR) Jan 25 10:54:48 angelo_ts: be careful to state that you built the kernel and all artefacts using OE which is part of the Yocto umbrella :-D Jan 25 10:55:19 -ella, -ella, -ella... Jan 25 10:55:28 ROTFL Jan 25 10:55:40 sry, trying to get rid of my office frustration Jan 25 10:55:41 jalla jalla Jan 25 10:55:50 :) Jan 25 10:59:15 angelo_ts: BTW here we are a bit OT, the OE chat is #OE Jan 25 11:00:12 ok good to know there is an #oe channel, thanks Jan 25 11:00:17 mckoan: I'm not sure it matters that much Jan 25 11:01:00 RP: yes indeed Jan 25 11:01:07 RP: dark matter, maybe Jan 25 11:01:28 LetoThe2nd: if its dark, how would we know it exists though? Jan 25 11:01:37 LetoThe2nd: good to see you are feeling the TGIF spirit Jan 25 11:01:43 mckoan: totally Jan 25 11:02:05 RP: https://www.youtube.com/watch?v=zSkGtW-fQ3s Jan 25 11:34:27 angelo_ts, yes and there will be a stand Jan 25 11:34:57 paulbarker, ^^^ Jan 25 11:35:56 Crofton|work, ok thanks, it seems the very 1st, AW 1 (you you and OE are all together) Jan 25 11:36:55 well will be certainly be there around Jan 25 11:43:47 RP: do you know how sstate cache cleanup on the autobuilder is performed? Jan 25 12:16:55 Hi. I would like to remove some compile options for ptest package. How can I do that? EXTRA_OECMAKE_remove-ptest doesn't seems to work. Any ideas? Jan 25 12:17:20 kanavin: atime, if its not accessed for a while we remove it Jan 25 12:20:02 RP: right, I guess the chance for it being accessed just at the wrong moment is not exactly zero, but very close to it Jan 25 12:24:47 kanavin: its not perfect, I don't know how to do anything better though Jan 25 12:25:17 kanavin: the main issue is bitbake's delay between checking if these things exist, then fetching them Jan 25 12:25:42 yeah, this came up in the discussion here - I'm pushing for a 'NFS that all builders contribute to' approach, instead of 'weekly generation of cache available via http' they do now Jan 25 12:26:20 they are scared of builders all writing and reading to the cache at the same time, I had to reassure that the appropriate locking is in place Jan 25 12:28:02 kanavin: the fallbacks are also safe, if it didn't exist at fetch, it would show a setscene error but then just rebuild the thing Jan 25 12:28:25 whether that should be an error or a warning has been a long debated question Jan 25 12:28:53 they were worried about things like several builders writing to the same file or a builder reading from an incomplete file Jan 25 12:29:22 kanavin: the code is carefully written for that Jan 25 12:29:29 (we move the files into position) Jan 25 12:30:14 RP: yep, but even then there is file locking in place, right? Jan 25 12:30:36 kanavin: no, why would you need that? Jan 25 12:31:12 kanavin: we write the artefact to a temp file, then rename it into the right place. That means the operation is atomic. You either see it or you don't Jan 25 12:31:50 kanavin: DL_DIR has locking, sstate doesn't need it Jan 25 12:32:09 RP: but I see the file lock calls in sstate.bbclass around those operations Jan 25 12:32:48 if several builders are writing to the 'same' sstate object at the same time, how is that handled? is tmp file name additionally randomized? Jan 25 12:33:01 kanavin: the tempfile is random Jan 25 12:33:52 kanavin: lockfiles in sstate.bbclass are for something totally different, not SSTATE_DIR Jan 25 12:34:14 kanavin: they're where we have a shared directory like sysroot used to be Jan 25 12:34:21 pkgdata still is shared Jan 25 12:35:17 right, thanks :) I'll have to correct myself then Jan 25 12:35:42 kanavin: sstate_create_package() is the key function which could race Jan 25 12:36:00 kanavin: its shell code and uses mktemp to get a unique name and ends with the atomic mv Jan 25 12:36:38 RP: I see, thanks again Jan 25 13:05:16 Jan 25 16:14:36 kanavin: i've a hunch that changing pkg_postinst_ontarget isn't causing a rebuild Jan 25 16:15:16 rburton: could well be Jan 25 16:15:34 it should only start from do_package() though Jan 25 16:19:18 rburton: as there seems to be no progress with various attempts to update python3, I have started a python-sanity project :) Jan 25 16:19:40 similar to perl, rewrite recipe from scratch, taking in pieces and patches which are proven to be necessary Jan 25 16:20:00 also, no separate python3-native Jan 25 16:20:05 rburton: open bug Jan 25 16:20:12 rburton: I have a patch Jan 25 16:20:53 rburton: http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/t222&id=b569103e9217a211a641b52cababfdf3dc9591bf Jan 25 18:30:54 does bitbake/oe/yocto require both python 2 and 3 ? if so, is the intent to migrate everything to 3 ? Jan 25 18:32:57 everything should move to python3 Jan 25 18:33:04 pretty sure bitbkle is already py3 Jan 25 18:37:20 ok Jan 25 18:41:51 kroon: only 3 is required on the host. we often have to build python 2 to run tools needed by the buildsystems of the projects we build, of course Jan 25 18:42:56 kergoth: oh, ok.. iirc the bitbake sanity checker told me to install python2 Jan 25 18:43:12 bitbake/oe sanity checker Jan 25 18:44:05 hm, possibly still require it on the host for all the cases wher ea reciope needs it for the build prcoess but doesn't dep on python2-native Jan 25 18:55:37 New news from stackoverflow: How set git project to release recipe in Yocto by 'devtool finish' command? Jan 25 19:46:40 kroon: 2 is needed for some recipes that assume py2 is present Jan 25 19:46:52 eventually that will fade away but not yet Jan 25 19:47:28 rburton: ok Jan 25 20:43:50 AB is ready for more builds. Jan 25 20:49:10 I'm trying to make a native recipe for a binary i need. It builds fine and the build/temp/work/x86.../image directory is as expectected. But nothing is showing up in the recipe-sysroot-native directory of my recipe that depends on it Jan 25 20:55:30 armpit: Planning any thud builds soon? Jan 25 20:56:00 armpit: (On the AB) Jan 25 20:56:58 Well, I say as expected, the binary is located at ../image/usr/bin , whereas other native builds seem to have a different image folder than non-native recipes. Jan 25 20:57:20 tar for instance: ../image/yocto/cci/build/tmp/work/x86_64-linux/tar-native/1.29-r0/recipe-sysroot-native/usr/bin/tar-native/tar Jan 25 20:57:30 tar is a special case. Jan 25 20:57:45 but it sounds like you didn tinherit native Jan 25 20:58:14 don't look to any recipe with a 'replacement-native' PROVIDES as an example, they're not usual Jan 25 20:58:18 i did inherit native Jan 25 20:59:30 without seeing the actual recipe there's a limit to what we can do for you Jan 25 20:59:37 but the first thing is to make sure it actually obyes our paths Jan 25 20:59:49 it needs to install to ${D}${bindir}, not ${D}/usr/bin Jan 25 21:01:08 the cmake file for this binary is really complex. Jan 25 21:01:38 the recipe is very simple though, inherit cmake pkgconfig native Jan 25 21:02:22 a couple EXTRA_OECMAKE arguments and that's it Jan 25 21:05:03 kergoth, should I just override the do_install and install my binary manually? Jan 25 21:07:13 ideally you'd fix the underlying cmake buildsystem to obey standard cmake paths, which our bbclass already adjusts, but that'd be one option to hack it for now Jan 25 21:08:46 Ok, i'll see what I can do, thanks for the info. Jan 25 21:42:36 so in the cmake files I'm seeing "install blah ver RUNTIME DESTINATION /usr/bin" I changed these to "install blah ver RUNTIME DESTINATION bin", seems to work now!! Thanks Jan 25 22:05:16 anything special I need to for an autotools project to generate intl/ during configure, besides inheriting autotools and gettext ? Jan 25 22:28:12 EXTRA_AUTORECONF_remove = "--exclude=autopoint" and depend on gettext-native seems to do the trick .. **** ENDING LOGGING AT Sat Jan 26 02:59:57 2019