**** BEGIN LOGGING AT Wed Dec 18 03:00:35 2019 Dec 18 04:42:26 kergoth: I was wondering if there is an option to use bz2 or xz for sstate archives ? Dec 18 07:03:13 Anyone using python3 inside yocto environment? Why I get ImportError: No module named 'runpy' if runpy is a builtin? Dec 18 07:19:05 stuom1: which form of python3 do you have installed? there's quite a lot of package splitting going on Dec 18 07:24:23 LetoThe2nd it's from python3-pip from openembedded-core Dec 18 07:43:41 stuom1: sorry, i'm no python user, just happen to know that there's a lot going on, for example here: https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/recipes-devtools/python/python3_3.7.5.bb#n312 Dec 18 09:15:41 Hmm, anyone have experience with changing psplash graphics? Dec 18 11:24:56 RP, we really should get to the bottom of missing do_unpack tasks :( Dec 18 11:42:16 kanavin: has it happened again? Dec 18 11:42:40 RP, yes, all of the gettext failures in your email are due to that Dec 18 11:42:51 (I replied there) Dec 18 11:43:02 kanavin: ok, sorry :( Dec 18 11:44:12 kanavin: I wonder why it gets exposed there in particular :/ Dec 18 13:09:35 Is anyone else seeing issues with meta-oe and poky on zeus branches? It appears like meta-oe is expecting features_check, when poky still has distro_features_check Dec 18 13:09:59 am I doing something stupid? Dec 18 13:10:04 sounds like meta-oe master not zeus Dec 18 13:10:12 or someone merged the wrong patches to zeus Dec 18 13:10:51 I'm trying to write some scripts to be super lazy Dec 18 13:10:56 bitbake-layers layerindex-fetch meta-oe -b zeus Dec 18 13:11:02 that is correct? Dec 18 13:12:35 yes, the meta-openembedded using the command above was on master Dec 18 13:23:18 sounds like a bug Dec 18 13:25:55 hi, where can i read about how it work the "state-cache mirror" ? Dec 18 13:33:01 angelo__: its in the docs. one sec, I had it up yesterday Dec 18 13:34:11 angelo__: https://www.yoctoproject.org/docs/current/mega-manual/mega-manual.html#setting-up-effective-mirrors Dec 18 13:34:48 that being said, I found the DL_DIR much more effective Dec 18 13:35:28 jonmason: DL_DIR is a must Dec 18 13:35:46 qschulz: totally Dec 18 13:36:34 Is there an easy way to prepopulate the sstate cache with a pubic nightly build or something? Dec 18 13:36:43 err..public Dec 18 13:37:00 jonmason: that's what the sstate-cache mirror is for AFAIK Dec 18 13:37:29 qschulz: yes, but that would be a local mirror, right? Dec 18 13:38:02 however, this is heavily dependent on all your build machines to have the same HOSTTOOLS (I think they're part of the hash or something). So same distribution for everyone (apparently some people use containers for that) Dec 18 13:38:05 I'm running with SSTATE_DIR, which seems to be superior for local builds (due to the constant updating) Dec 18 13:38:33 jonmason: SSTATE_MIRRORS Dec 18 13:38:43 https://wiki.yoctoproject.org/wiki/TipsAndTricks/TeamWorkflows Dec 18 13:39:23 basically SSTATE_DIR but behind a webserver Dec 18 13:39:29 I *think( Dec 18 13:39:33 *think* Dec 18 13:39:37 qschulz: that link is perfect...it's referencing http://sstate.yoctoproject.org/ Dec 18 13:40:08 jonmason: yup, though... it means it'll ping the servers for each recipe and task with your IP address Dec 18 13:40:35 I don't know how much data is sent in the request but for some comapnies the name of a software is enough :) Dec 18 13:40:37 assuming that server has bandwidth, it'd be better to fetch it all Dec 18 13:40:57 this script is more for a fresh setup Dec 18 13:41:25 DL all the sources, DL the sstate, add the layers, and go Dec 18 13:42:14 but it does assume that DL is faster than compiling Dec 18 13:42:26 jonmason: böring Dec 18 13:42:39 LetoThe2nd: hahahaha Dec 18 13:42:40 jonmason: Y U NO wall of text, scrolling and compiling? Dec 18 13:45:37 jonmason: same for icecc, you need fast network to benefit from it Dec 18 13:46:25 jonmason: you could technically have this SSTATE_MIRRORS replicated in all offices so that it's local and really fast. Dec 18 13:46:38 also, SSTATE_MIRRORS is RO while SSTATE_DIR is rw Dec 18 13:53:34 jonmason: that would work only if you build poky distro. if you start making config changes then most likely the sstate cache will be invalidated anyways.. Dec 18 13:54:37 Are packages available in SSTATE_MIRRORS pulled into the local SSTATE_DIR? For our developers it would be easier to do an overnight build to populate a local SSTATE_DIR that having to download the packages from SSTATE_MIRRORS for every workspace, but if SSTATE_MIRRORS populates SSTATE_DIR then it should be ok. Dec 18 13:54:50 jonmason: rburton : the '-b branch' in layerindex-fetch is used when searching in the layerindex , but it's not used when cloning the branch locally. Dec 18 13:54:59 ndec: poky without weird stuff in conf/local.conf even. And building the same machines (qemu ones only I guess?) Dec 18 13:55:21 ndec: sounds like a bug :) Dec 18 13:55:31 exactly.. there is little benefits if you start making config changes.. Dec 18 13:55:33 -b BRANCH, --branch BRANCH Dec 18 13:55:33 branch name to fetch Dec 18 13:55:43 rburton: arguably it's a feature ;) Dec 18 13:56:07 hmm. do we really say that? let me check.. Dec 18 13:56:14 yeah that's --help for fetch Dec 18 13:57:28 hpsy: I don't understand your point? Make one build server populates what's behind the SSTATE_MIRRORS and then all devs benefit from it? Dec 18 13:58:13 rburton: well, we fetch from layerindex using this 'branch'. it's used for constructing the URL in layerindex, e.g. http://layers.openembedded.org/layerindex/branch//layers/ Dec 18 13:58:29 so we really 'fetch' that branch from the layerindex ;) Dec 18 13:58:29 hpsy: though I have to say, I just know the helicopter view of that thing, we don't use it Dec 18 13:59:33 hpsy: SSTATE_MIRRORS is a mirror for SSTATE_DIR, so it will look for files in SSTATE_MIRRORS first, then it will look in SSTATE_DIR Dec 18 14:00:15 i don't think a copy from SSTTE_MIRROR to SSTATE_DIR is done Dec 18 14:01:43 qschulz: Almost all of our developers work remotely, so decreasing network operations is desirable, it is Ok to pull once from SSTATE_MIRRORS, but not for every time they have a new workspace or delete their tmp directory Dec 18 14:02:21 ndec: Ok, Thanks Dec 18 14:02:34 ndec: are you arguing that the behavior of not actually getting that branch is expected Dec 18 14:02:56 hpsy: I see, I always forget remote work actually exists :) Dec 18 14:04:08 jonmason: i am not sure. i suppose it can be interpreted either way. maybe something for Paul to confirm. Dec 18 14:10:24 jonmason, late but thanks ! Dec 18 14:11:45 is there a way i can verify a EXTRA_IMAGE_FEATURES += "read-only-rootfs" worked when build has finished ? Dec 18 14:11:46 kanavin: its interesting it appears to fail reproducibly, at least with the current state on the bulders Dec 18 14:12:52 RP, so you can take it from there? Dec 18 14:12:59 I was worried it's one of those heisenbugs Dec 18 14:13:51 "In computer programming jargon, a heisenbug is a software bug that seems to disappear or alter its behavior when one attempts to study it." Dec 18 14:28:12 Hi, iam trying rauc for updates. But i always get "Nothing RPROVIDES 'mtd-utilsrauc'". Is there some advice for fixing this? Dec 18 14:29:46 kanavin: well, people are running other builds so it may disappear :/ Dec 18 14:31:09 GeneralStupid: https://github.com/rauc/meta-rauc/tree/master/recipes-core/rauc doesn't seem to require this Dec 18 14:31:29 GeneralStupid: if you are on some custom form of rauc, look at their layer if there's more magic to be done. Dec 18 14:31:47 GeneralStupid: Looks like your are missing a space in your description or need to use "+=" instead of _append. Dec 18 14:35:37 angelo__: if the build finished, its fine. rootfs fails if there are postinsts left to run on first boot Dec 18 14:36:34 florian: oh, good pick! Dec 18 14:38:07 florian: i will try, i dont get the difference between _append and += Dec 18 14:38:33 LetoThe2nd: Well... I seem to be used to this kind of issues :) Dec 18 14:39:26 GeneralStupid: In this case its quitle likely that the only relevant difference for you is that += automatically adds a space while _append doesn't. Dec 18 14:39:39 GeneralStupid: += adds a space before. thats the not most important, but most visible distinction. Dec 18 14:43:26 RP: core-image-full-cmdline and core-image-sato passed the reproducible build test? Dec 18 14:45:28 whoop whoop Dec 18 14:45:38 shocked that pod was the last piece Dec 18 14:45:49 rburton: pöd Dec 18 14:46:00 with more döts, its more evil Dec 18 14:46:33 https://en.wikipedia.org/wiki/Metal_umlaut Dec 18 14:46:53 JPEW: they did so I've enabled :) Dec 18 14:49:20 RP: w00t! Dec 18 14:51:27 LetoThe2nd: okay :) Dec 18 14:52:50 rburton: I've been chipping away at it for a while now :) Dec 18 14:53:07 * JPEW wishes upstream nasm would take my patch... Dec 18 14:53:12 JPEW: Its a great milestoe Dec 18 14:53:32 JPEW: they have an objection? Is that hpa? Dec 18 14:53:59 RP: No objection AFAIK, I think they just don't check their bugzilla very often :) Dec 18 14:54:13 did someone here use rauc? Dec 18 14:54:28 and another important question... Is someone using a NAND qspi flash? Dec 18 14:54:41 RP: Are the other images that are worth targeting as a next step? Dec 18 14:54:50 the company i worked before we usually used NAND qspi flashes Dec 18 14:55:08 JPEW: next step is the -sdk image Dec 18 14:55:29 JPEW: after that world (domination) Dec 18 14:55:45 RP: right :) Dec 18 14:56:22 RP: Whats in the AB world build right now besides oe-core? Dec 18 14:56:31 JPEW: it is just core Dec 18 14:56:39 "just" Dec 18 14:56:48 * RP can't cope with this level of failures Dec 18 14:56:56 does _% in bbappend filename stand for a version wildcard? Dec 18 14:57:17 GeneralStupid: yes Dec 18 14:57:41 GeneralStupid: Yes. you can also do e.g. _1.% for a more specific wildcard Dec 18 14:58:21 RP, JPEW : thanks, good to know :) Dec 18 15:21:50 RP: hashequiv failures or other? Dec 18 15:22:22 JPEW: just the general load Dec 18 15:22:48 JPEW: trying to rewrite the fetcher upsteam urls tests to remove a new source of failures on the AB, then I can think about the hashequiv issues being seen Dec 18 16:05:21 Hmmm, ok Dec 18 16:05:27 Past one hurdle, stuck in another Dec 18 16:05:49 why is my boot logo displaced? Dec 18 16:06:39 It should be a test image; red on white background Dec 18 16:07:13 The letter TEST in big red letters Dec 18 16:07:24 or word TEST :P Dec 18 16:07:36 It shows up as Gray and pixels are displaced Dec 18 16:07:38 :( Dec 18 16:08:30 wertigon: is the display known good and only the splash distorted? Dec 18 16:08:50 Yeah exactly Dec 18 16:08:56 in that case, double-check the exact image format that you can pass in Dec 18 16:09:16 size, color depth, palette, the whole shbang Dec 18 16:09:26 It's like every line gets an extra offset by two pixels Dec 18 16:10:03 And the splash image is gray Dec 18 16:10:20 Looking to see if it's BPP Dec 18 16:10:59 All letters are leaning towards the right Dec 18 16:11:09 and the first T overflows to the other side a bit Dec 18 16:11:13 go check the image format Dec 18 16:12:09 I use gdk-pixbuf-csource --macros test.png > psplash-poky-img.h Dec 18 16:13:00 Hmm, yeah could be that I use a different red than #ff0000 Dec 18 16:30:02 Ok, so the logo was #ff000f Dec 18 16:30:13 Let's see what happens now with the recompile Dec 18 16:40:49 Nope, still gray Dec 18 16:40:51 :( Dec 18 16:43:03 Last try, trying one more trick and then I shall give up for now... Dec 18 16:47:11 Nope, that was even worse XD Dec 18 16:47:21 Now I get rainbow puke instead Dec 18 16:47:29 4bpp ain't the solution then Dec 18 16:48:30 psplash, y u do this -_- Dec 18 16:48:44 Ah well, have a good night y'all! Dec 18 17:53:59 wow qtwebkit compile log is 163M, I wonder whats happening with other large cmake based projects, I guess we should make VERBOSE a knob and then set it to 0 by default instead of making it 1 Dec 18 17:54:29 so one who is debugging can set VERBOSE=1 in recipe Dec 18 18:30:19 ok, have a patch to "fix" the layerindex-fetch issue from earlier today Dec 18 20:06:01 kergoth, moto-timo: Have either of you had a chance to try out the Pyrex beta3? I think we might be getting close to a 1.0.0 release Dec 18 21:26:18 JPEW: on the (short) list Dec 18 21:26:30 moto-timo: Ok, thanks! Dec 18 21:26:31 JPEW: I looked at a bunch of the code though and like what I see Dec 18 21:28:05 hello. i am looking for some general advice on how to build variants of images with just very small config changes. right now i have an application recipe that includes a config file. i'd like to be able to build different images for different customers where one of those config vars is different for each one, but everything else is the same. any recommendations on how to best do this? Dec 18 21:30:20 i tried to create other copies of the application recipe with the config changes and then new images that include those customized recipe copies. but then the build complains about files common to them being accessed or written by multiple packages and bitbake doesn't seem to like it. it also seems wasteful copying all that code for just one-line changes. thanks in advance for any advice or suggestions Dec 18 22:25:30 nemik: one application recipe and then multiple configuration recipes? Dec 18 22:25:54 only very old bitbakes complain about multiple independent recipes that ship the same file Dec 18 22:43:30 khem: people wonder why I complain about things like this :/ Dec 18 22:44:04 rburton: this is morty, so yea that might be the case? unfortunately it's an SDK provided by a vendor and too risky for me to try to upgrade that part of it Dec 18 22:45:16 RP: disabling VERBOSE also improved build times a nit Dec 18 22:45:36 khem: less IO definitely helps for cases like that Dec 18 22:45:45 RP:https://git.openembedded.org/openembedded-core-contrib/commit/?h=yoe/mut&id=ee0e70a5e5dbb5748c780ac2a74194bd32911f5e Dec 18 22:46:31 khem: can you put a comment in the class about how to enable it? Dec 18 22:47:00 khem: saves people trying to figure it out again Dec 18 22:47:16 good idea Dec 18 22:47:40 I am still testing it out with/without and see it keeps working in all cases Dec 18 23:13:13 nemik: morty is very unsupported, i recommend you complain to the vendor Dec 18 23:40:53 RP: do we have plans to use xz or some other compression for sstate ? Dec 18 23:41:24 RP: clangs sstate archive is 5+ GB and takes 15 mins for be generated with tgz Dec 19 00:38:24 Hello everyone. I am pretty new to the yocto project. I find it confusing that when I `source ./oe-buildenv-internal mybuild`, I get a mybuild/conf/bblayers.conf. This is confusing to me since I expected what layers to use would be a configuration I provided, not a build artifact. I did find the bblayers.conf.sample template, but having to modify my checked out poky repository to add a layer feels incorrect to me. Dec 19 00:41:10 Does anyone know how I am supposed to add layers to a zeus checkout without modifying the source? Dec 19 00:43:34 Sorry, I meant `source ./oe-init-build-env mybuild` Dec 19 00:44:16 One person I asked literally recommended making my own script that calls oe-init-build-env, and then uses `sed` to add my layers to the generated bblayers file. There has to be a more appropriate way. Dec 19 01:43:42 Hmm @mischief taught me about the TEMPLATECONF variable. That helped a lot. Now at least I know where things start :) **** ENDING LOGGING AT Thu Dec 19 03:00:12 2019