**** BEGIN LOGGING AT Fri May 01 02:59:57 2020 May 01 04:20:32 New news from stackoverflow: Reverse-engineering a robot; need some help running scripts without command line access [closed] May 01 05:50:46 New news from stackoverflow: How to add Sudouser in Yocto May 01 12:13:28 Should PERSISTENT_DIR be shared between two build dirs (we use two build dirs using the same metadata on two machines to speedup builds. I was wondering if it is safe/a good idea to share PERSISTENT_DIR between them). May 01 13:06:50 Probably the question should be more, is it safe to share PERSISTENT_DIR? May 01 13:18:22 sanger: No I don't think you can share the (simutaneously May 01 13:18:30 (simultaneously at least) May 01 13:25:39 I'd be curious what your goal is with that. It's unlikely to have much of a performance benefit, unless you have a lot of autorev recipes and also change the bb srcrev cache policy May 01 13:32:33 kergoth: I want to make sure the autorev recipes use the same ref... May 01 13:33:08 kergoth: I do not care which one, I care that they use the same basically. May 01 13:33:27 Are these automated builds? May 01 13:33:51 JPEW: particular reason why? May 01 13:33:53 kergoth: yes May 01 13:33:56 there are multiple options depending on your requirements. there's a script to collect autorev srcrevs and write them to a .conf that you can include, for example, to lock them down before any of the builds begin May 01 13:34:16 sagner: https://github.com/openembedded/openembedded-core/blob/master/scripts/buildhistory-collect-srcrevs May 01 13:34:17 kergoth: oh, that sounds like a good alternative, do you have some pointers? May 01 13:34:23 emits SRCREV_pn-foo = "bar" lines May 01 13:35:04 kergoth: interesting, will have a look at that May 01 13:35:08 hmm, although, that one requires buildhistory, so that might require that a first build be done first, that might not be ideal May 01 13:35:11 * kergoth ponders May 01 13:35:51 in theory sharing persistent_dir might be viable, it's just sqlite, i'd wonder if *all* of its contents are save to be shared though. perhaps examine their contents with the sqlite cli May 01 13:36:27 that said, the idea of doing an up front lock down does seem viable even if that particular script isn't, all you'd need is a bitbake -p and then extract the current values of SRCREV from the affected recipes May 01 13:36:44 kergoth: yeah that is a bit unfortunate. Also, we have different build configurations, and some use different recipes with autorev... So I would have to make sure that I ran one build of all the different configuration first to collect all autorevs May 01 13:36:58 i'd check to see exactly when buildhistory writes the srcrev info. if it's at parse time, it'd be viable May 01 13:37:03 ah May 01 13:37:04 fair point May 01 13:37:25 i kind of hate autorev at this point, it's a pain despite the benefits for active development workflows :) May 01 13:37:26 sagner: Ya, I think it's something that could possible work, but its certainly not tested. Hard to know if any asumptions about exclusive access were made May 01 13:37:47 Hi, I'm trying to create a sdk with libxml2, so I added IMAGE_INSTALL += " libxml2 " to core-image-minimal.bbappend and did bitbake core-image-minimal -c populate_sdk. When I install the resulting poky-glibc-x86_64-core-image-minimal-armv7a-vfp-machine-toolchain-3.1.sh , I can't find the libxml headers in the sysroot. What am I missing May 01 13:38:03 kergoth: I really like devupstream... except that is breaks devtool May 01 13:39:06 devupstream is the one that makes the git development version into a bbclassextend variant? May 01 13:39:09 that does have promise May 01 13:40:03 kergoth: Almost. It makes a virtual class of the recipe that uses git while the stable one can use a tarball/whatever: e.g.: https://github.com/Igalia/meta-webkit/blob/master/recipes-browser/wpewebkit/wpewebkit_2.28.2.bb May 01 13:40:26 Pairs well with: https://github.com/Igalia/meta-webkit/blob/master/conf/include/webkit-bleeding.inc May 01 13:41:03 In other words, devupstream doesn't imply AUTOREV, but you can combine them together easily May 01 13:42:15 that's nice, no need for _git recipes floating around anymore May 01 13:42:26 kergoth: right May 01 13:42:44 its so close but not quite there May 01 13:42:51 you can't combine devupstream+native May 01 13:43:24 We've also used it optionally pull bleeding edge for some oe-core recipes in a bbappend May 01 13:43:47 oh, huh, didn't think about that. it'd be nice to have a generic way to handle that, but allowing every extended variant to combine would be a potential explosion of combinations May 01 13:43:56 hmm May 01 13:44:02 kergoth: have a think and come back with an idea :) May 01 13:44:14 step one would be stopping native being treated specially May 01 13:44:33 (native and nativesdk are implemented quite differently) May 01 13:44:53 that reminds me, i really hate that native sets prefix=. i get why, so we can search and replace it, but i still hate it May 01 13:46:06 kergoth: bitbake -p seems not enough for openembedded-core/scripts/buildhistory-collect-srcrevs, I guess srcrevs are only resolved after fetch? May 01 13:46:24 they are resolved at parse time, i think just buildhistory hooks later to write it May 01 13:47:37 Is this the right place to ask for a short help question trying to create a crosscompile SDK? May 01 13:48:19 Or is another channel more appropriate May 01 13:49:15 kergoth: yeah you are right, they are in cache/bb_persist_data.sqlite3. I think I try just sharing this sqlite database, and then get the hases at the end of the build from there. May 01 13:49:51 tsjsieb: are you using yocto to create the sdk? May 01 13:50:04 yes, Hi, I'm trying to create a sdk with libxml2, so I added IMAGE_INSTALL += " libxml2 " to core-image-minimal.bbappend and did bitbake core-image-minimal -c populate_sdk. When I install the resulting poky-glibc-x86_64-core-image-minimal-armv7a-vfp-machine-toolchain-3.1.sh , I can't find the libxml headers in the sysroot. What am I missing May 01 13:51:30 tsjsieb: the first thing i'd do is bitbake -e core-image-minimal | grep IMAGE_INSTALL= to make sure your change took effect and you didn't do something silly like put the bbappend int he wrong place (i've been there :) May 01 13:54:14 that does contain the libxml2 I've added, and the image also contains the .so May 01 13:57:37 it's (as far as I can see now) only the content of the libxml2-dev package I'm missing, when I install the created sdk May 01 15:18:35 RP: https://git.openembedded.org/openembedded-core-contrib/log/?h=kraj/morty I am able to build core-image-sato for qemumips on ubuntu 18.04 now :) May 01 15:18:57 RP: sadly there is no uninative support in daisy I think May 01 15:19:09 otherwise I could try that out too May 01 15:57:53 NOTE: Previous bitbake instance shutting down?, waiting to retry... May 01 15:57:57 sigh, not again May 01 15:58:25 can't do a build at all at the moment May 01 16:15:35 hello does exist a website providing Yocto pre-built toolchains and images? May 01 16:16:54 this looks outdated http://downloads.yoctoproject.org/ May 01 16:16:56 Guestiii, Like the ones at http://downloads.yoctoproject.org/releases/yocto/ ? May 01 16:18:29 halstead that's perfect. Thank you May 01 16:20:19 I feel like I saw this go by in release notes once but can't remember. What is the "new" replacement for pn-depends.dot? How do I find something like the RDEPEND graph? May 01 16:36:03 khem: nice! We'll have to collect together some of this stuff. I was wondering about seeing how much we could make buildable on the autobuilder even May 01 16:55:11 kanavin_home: good news is I've fixed the SIGILL issues. We're now seeing a spate of testimage_virgl_gtk_sdl failures :/ May 01 17:14:08 RP: that is weird, there is nothing in master-next that is obviously linked to it May 01 17:14:23 RP: I can try to reproduce maybe? May 01 17:14:24 kanavin_home: right, I don't understand :/ May 01 17:14:37 kanavin_home: I'd welcome any help understanding what broke May 01 17:15:08 kanavin_home: I'm trying master with a cache invalidation now but its going to take a while and its maint time on the AB which will delay things May 01 17:33:45 kanavin_home: master worked so it is something in -next May 01 17:35:03 RP: right, I started a build with master too just now, will then try -next, and bisect as needed May 01 17:35:40 kanavin_home: thanks. I'd best hold off doing anything with those patches until we figure this out May 01 17:37:23 RP: btw, would you be ok changing some maintainers.inc entries to 'community maintenance '? The specific effect is that AUH patches for those will go straight to the list. May 01 17:37:52 some maintainers are just gone, or never reacting, so I'd start with those May 01 17:38:25 kanavin_home: lets discuss that on the list May 01 17:38:53 RP: right, sure May 01 17:39:16 kanavin_home: is there a list of those recipes? I'd be open to taking some over May 01 17:39:39 smurray: http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/conf/distro/include/maintainers.inc May 01 17:40:11 if you list yourself there, AUH will be sending you monthly upgrade patches (or info that there's a new version that couldn't be auto-upgraded). May 01 17:40:22 your task is then to send the patch to oe-core list. May 01 17:40:23 kanavin_home: right, but it's the ones that are in need of replacement maintainers that I'd be interested in May 01 17:40:47 kanavin_home: in the past it's sort of looked like everything had someone signed up May 01 17:41:17 smurray: all of the python3 stuff May 01 17:41:42 kanavin_home: heh, aka the "fun" stuff May 01 17:42:50 smurray: also @windriver.com people aren't doing that great job lately May 01 17:44:58 kanavin_home: okay, I'll look at the last few AUH mails to the list to see what looks feasible and see how people respond to your suggestion re the community marking May 01 17:46:02 smurray: thanks May 01 17:50:25 kanavin_home: just curious, do you test your updates on the autobuilder before submission, or locally with a set of configs? May 01 17:57:06 smurray: AUH tests that they build on a range of targets May 01 17:57:40 I don't generally test at runtime, only for some specific things May 01 17:58:09 smurray: I don't actually have AB access, so leave that to RP May 01 17:59:20 kanavin_home: could be arranged :) May 01 18:00:44 kanavin_home: ah, right. I guess I was thinking more of the case of non-auto-generated updates May 01 18:01:00 RP:"runqemu - ERROR - Failed to run qemu: qemu-system-x86_64: could not configure /dev/net/tun (tap1): Operation not permitted" - how can I run qemu on the worker machines? May 01 18:01:52 smurray: for those I test that they at least build :) and if they're native tools, then that they still work. May 01 18:02:19 kanavin_home: okay May 01 18:02:24 "runqemu - INFO - Acquiring lockfile /tmp/qemu-tap-locks/tap0.lock failed: [Errno 13] Permission denied: '/tmp/qemu-tap-locks/tap0.lock'" May 01 18:08:16 kanavin_home: you'll have to sudo -iu pokybuild May 01 18:08:59 kanavin_home: keep in mind its maintenance right now so workers will be rebooting May 01 18:15:58 RP: right, I have to restart the build as that user then - I made a separate directory in pokybuild home May 01 18:18:21 zeddii: I hadnt realized, were looking good on the ELC schedule page May 01 18:21:42 kanavin_home: ok, cool May 01 18:50:21 RP: master passed on debian10. Running master-next now. May 01 19:14:53 RP: master-next also passed on debian10 May 01 19:17:14 :D May 01 19:22:56 RP: so I can only guess the build on AB where all three selftests failed had some kind of poisoned cache item :-/ May 01 19:27:17 kanavin_home: pick the abi bump off the top of master-next ? May 01 19:27:40 kanavin_home: sorry, I missed context May 01 19:28:01 kanavin_home: that is troublesome. Which deian10 was this? May 01 19:40:46 RP: debian-ty-1. I can try on fedora to get a second confirmation May 01 19:41:38 RP: the selftest ran on a different debian10 I think May 01 20:10:37 fedora30-ty-2 won't let me in :-/ May 01 20:41:19 kanavin_home: this was a complete build from scratch so there shouldn't have been any interference :/ May 01 21:24:51 RP: hmm, we should get a bitbake -p to dump a list of available targets for shell completion to use eventually :) May 01 21:25:59 kergoth: memres would make that work a lot better May 01 21:26:42 agreed **** ENDING LOGGING AT Sat May 02 02:59:58 2020