**** BEGIN LOGGING AT Mon Jul 06 03:00:57 2020 **** BEGIN LOGGING AT Mon Jul 06 03:06:49 2020 **** BEGIN LOGGING AT Mon Jul 06 06:28:57 2020 **** BEGIN LOGGING AT Mon Jul 06 06:42:32 2020 Jul 06 06:46:46 good morning Jul 06 06:53:48 Morning Jul 06 07:19:34 good morning new age dudes! Jul 06 07:35:05 Letothe2nd: LOL Jul 06 07:54:36 mckoan: bascially it refers to https://youtu.be/_ZwkQIBp4TA?t=53 Jul 06 08:08:04 Would it be possible to tell google not to provide as first hit a link to an old outdated bitbake manual when searching for "bitbake manual" ? Jul 06 08:23:25 kroon: if you find a way, please do so. Jul 06 08:23:44 Letothe2nd, one solution would be to remove it Jul 06 08:23:47 I think Jul 06 08:24:01 or at least move it Jul 06 08:25:51 which breaks all the links, and at the same time just re-loads the problem. disagreed. Jul 06 08:37:23 @koon,@Lethothe2nd how about a redirect? Jul 06 08:37:35 RobertBerger: nope Jul 06 08:37:54 The issue is if you're looking for documentation that disappeared Jul 06 08:38:05 if Google finds you the correct page, you want to go on that page Jul 06 08:38:23 and not be redirected to master branch which does not have this information anymore (maybe for good reasons) Jul 06 08:38:45 I guess the most sensible strategy would be to add a banner at the head like "This is not the current version, click here if you want to see it" like boost and cmake are doing it. Jul 06 08:38:46 RobertBerger: also, some anchors change their names Jul 06 08:39:00 Letothe2nd: yes that would have been my suggestion as well.. Jul 06 08:41:15 qschulz: hi5 Jul 06 08:42:58 I am not a web person, but just did a redirect to the latest and greatest bitbake manual: http://rlbl.me/bb-man Jul 06 08:43:24 Can you please tell me what I just broke? Jul 06 08:44:09 RobertBerger: nothing, but google wont index it. Jul 06 08:44:45 RobertBerger: and if we change the existing, indexed links to redirects, then those who specifally link to anchors of older manuals are borken. Jul 06 08:45:04 RobertBerger: plus, we already have such a redirect, namely the current one. Jul 06 08:45:06 RobertBerger: and technically, that means the old pages aren't accessible anymore Jul 06 08:45:38 because I don't think there's a "redirect only if coming from Google" HTTP code :)? Jul 06 08:46:25 it would already be enough of G would pick the current version. and what i'm witnessing is that this even is based on personal history... Jul 06 08:46:37 OK I see the problem. We need a new link which goes on top of Google which points to the latest and does not replace the exiting one. Jul 06 08:47:27 the link is: https://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html Jul 06 08:47:44 Letothe2nd: what's the difference between current and latest? Jul 06 08:47:49 its just not on top of google, and unless we pay for SEO etc, i don't see it will end up there. Jul 06 08:48:02 or that? https://www.yoctoproject.org/docs/latest/bitbake-user-manual/bitbake-user-manual.html Jul 06 08:48:02 qschulz: latest is master, current is released AFAIK **** BEGIN LOGGING AT Mon Jul 06 10:24:07 2020 Jul 06 10:42:18 Hi, I have a quick question! I am using Yocto Project 2.6 Thud, and I am wondering if there is a specific Docker version that suits this version? Can I use it with Docker 18.09.9? Jul 06 10:44:24 sara8: use with docker as in? Jul 06 10:45:12 sara8: Thud uses 18.09.0 Jul 06 10:45:22 sara8: http://layers.openembedded.org/layerindex/branch/thud/recipes/?q=docker Jul 06 10:45:54 sara8: and is provided by meta-virtualization Jul 06 10:46:23 mckoan: that implies we're talking about docker being installed *into* the built system, which is not so clear for me. hence the question Jul 06 10:47:32 I want to use docker to run my container built with yocto, sorry for being unclear Jul 06 10:47:37 Letothe2nd: I thought that if it were related to the Host shouldn't be a matter of YP version Jul 06 10:48:18 sara8: so you want to run docker on the host, and build something with yocto that runs inside docker, right? Jul 06 10:48:50 Correct :) Jul 06 10:49:02 sara8: docker version really doesn't matter, then. Jul 06 10:49:10 sara8: and see https://youtu.be/jPbcQEffzJo for some good inspiration Jul 06 10:50:06 sara8: plus https://elinux.org/images/6/62/Building-Container-Images-with-OpenEmbedded-and-the-Yocto-Project-Scott-Murray-Konsulko-Group-1.pdf Jul 06 10:50:23 mckoan: /me shouts BINGO! Jul 06 10:50:57 Alright, thanks Letothe2nd and mckoan ! I will use 18.09.9 :) Jul 06 10:51:27 And thanks for the links Letothe2nd! Jul 06 10:51:32 have fun **** BEGIN LOGGING AT Mon Jul 06 11:49:32 2020 Jul 06 11:56:48 Is it possible to use INCOMPATIBLE_LICENSE and have it per image recipe? Use case is that I'm building one production image that shall be GPLv3 free and one test image with same config. Wondering if INCOMPATIBLE_LICENSE_pn- can do it. Jul 06 11:59:20 pbergin: supported only starting from dunfell IIRC Jul 06 12:02:52 ok. I'm on thud in this proj. Have to look if it is simple to backport. Do you have a feeling? Jul 06 13:36:43 I have changing siginfo for rm_work with diffsig saying just: Variable RM_WORK_EXCLUDE value changed from '' to 'None' - in one case local.conf has RM_WORK_EXCLUDE = "", in the other RM_WORK_EXCLUDE is never defined Jul 06 13:36:54 shouldn't those be equivalent and generate the same siginfo ? Jul 06 13:39:59 Hi, what is a good documentation link to read about how to setup disk partitions during yocto build of a yocto distro image? Jul 06 13:40:37 fbre: you might want to have a look at wic tool? Jul 06 13:41:07 also, it seems strange that touching RM_WORK_EXCLUDE for unrelated recipes would change the siginfo for all recipes' do_rm_work, isn't it ? Jul 06 13:42:47 qschulz: good hint. I googled with "yocto wic tool" and got a link to documentation which contains this chapter: https://www.yoctoproject.org/docs/2.3/dev-manual/dev-manual.html#creating-partitioned-images Do you mean this one? Jul 06 13:45:10 fbre: probably, yes. Might want to change 2.3 with your Yocto release number Jul 06 13:46:14 ok, thanx. I wasn't aware of the magic buzzword 'wic tool' to look for such things Jul 06 13:47:30 RP: today at the office: upgrading to "dunhill" Jul 06 13:48:04 LetoThe2nd: fell from the hill ? Jul 06 13:49:16 plus my brain always replaces "gatesgarth" with "glenfarclas" Jul 06 13:49:52 that's understandable, cheers :) Jul 06 13:50:57 LetoThe2nd: they're at least unique enough names people still know what you mean :) Jul 06 13:51:14 LetoThe2nd: although "glen" would put you on the other side of the border Jul 06 13:51:38 rburton: someday we might have to do trailcentres :) Jul 06 13:51:49 hehe Jul 06 13:54:33 If you really want to confuse people name a release or two after Welsh towns Jul 06 13:55:32 paulbarker: ++ Jul 06 13:55:33 isn't that what gatesgarth stands for already ? *now* I'm confused :D Jul 06 13:56:16 Gatesgarth is in England. Jul 06 13:57:04 Wales, England... who makes the difference form this side of the Channel :) Jul 06 13:57:06 * yann hides Jul 06 13:58:00 Llanfair­pwllgwyngyll­gogery­chwyrn­drobwll­llan­tysilio­gogo­goch (the longest single word place name in Europe) is a small town in Wales. Perfect name for a release branch Jul 06 14:04:26 paulbarker: I suspect I would be banned from choosing release names after that :) Jul 06 14:15:08 zeddii: did something get messed up with the linux-yocto repo? Jul 06 14:19:02 not that I know of. or were you looking at my broken autobuilder run ? :D Jul 06 14:21:48 zeddii: somehow it impacted mine Jul 06 14:22:12 zeddii: https://autobuilder.yoctoproject.org/typhoon/#/builders/83/builds/1122/steps/10/logs/warnings Jul 06 14:23:25 unless AUTOREV is involved .. you shouldn't have seen anything. @jonmason was looking for v5.4.50 so I was doing a release build of it, and forgot to push the tags and SRCREVs before starting it, my new run with the push is chugging along fine now. Jul 06 14:24:26 zeddii: right, so how did that make revs go missing in my build? :( Jul 06 14:25:05 that, I can't say. is it continuing to do that ? or is it happier now ? the push was fastforward (of course), so nothing should have been lost. Jul 06 14:25:30 zeddii: it seems to be running now Jul 06 14:25:58 that is very strange indeed. I was just double checking the revs and yah, the old ones are still there. how on earth did it pollute like that. hmm. Jul 06 14:29:13 zeddii: I wonder if the mirror tarball is stale and it fetched and unpacked that as it couldn't find the revs your build wanted? Jul 06 14:30:11 that does sound plausible. I can't think of any other way the bad revs could have crossed like that. Jul 06 15:53:58 @zeddii all my fault ;-) Jul 06 15:56:27 heheh. it's all green now, so I'll send SRCREVs later today. Jul 06 15:58:17 I just know what's going to happen. I'm going to fix meta-kernel to work with our BSPs, they'll say "why bother changing to tat when we can use yocto-linux" and then we'll switch to that. But I know the way my luck is, if I don't do meta-kernel then they'll want that one instead. Jul 06 15:58:53 I shall not express any comments/opinions on that subject. Jul 06 16:00:50 because we all know it Jul 06 16:01:59 I'm almost ready to alpha release my "config-blame" for the .config though. so that's good, I hacked on it during ELC. Jul 06 16:02:13 ah, that is cool Jul 06 16:02:25 and explains why you weren't paying attention to the sessions ;-) Jul 06 16:03:40 I was listening :D Jul 06 16:12:19 jonmason: I'm not happy about this orange on the autobuilder from meta-arm. rburton is aware too ;-) Jul 06 16:13:27 ah crap. the git hook has me again on git.yoctoproject.org Jul 06 16:13:42 halstead: the fix you did for linux-yocto, is needed on linux-yocto-dev as well. Jul 06 16:14:03 I of course realize this *after* I deleted the old branches Jul 06 16:14:50 zeddii: I'll make that change for a bit. Jul 06 16:14:59 Just a few minutes. Jul 06 16:15:32 no worries. it isn't super urgent. the people who let me know of CI/CD failures need a patch from me anyway, so they have to wait. **** BEGIN LOGGING AT Mon Jul 06 16:18:57 2020 Jul 06 16:21:00 zeddii, linux-yocto-dev is all set now. Jul 06 16:23:57 confirmed it works. thanks! Jul 06 16:27:47 RP, No. I'm not sure how the order is determined. It doesn't seem to be fifo. Jul 06 16:28:16 zeddii, Do you need me to leave it this way or can I switch it back to the default hook? Jul 06 16:28:22 halstead: I worry its our allocator code change :/ Jul 06 16:28:37 in theory, now that those blobs are pushed, they'll never need to be pushed again, so the hook won't fire. Jul 06 16:29:02 zeddii, I'll go back to the default. We ca always disable if needed in the future. Jul 06 16:29:05 halstead: I guess I abort that build and try again... Jul 06 16:29:48 RP, Will it queue eventually or has it been like that for way too long? Jul 06 16:31:11 halstead: I don't know Jul 06 16:31:31 halstead: I think it would have run if it was going to by now Jul 06 16:33:26 RP, I agree. I tried restarting a worker to see if that would prompt anything but it did not. Jul 06 16:39:00 halstead: I've queued a new build. I'll leave the other running just to see what happens Jul 06 16:46:19 * halstead nods. Might prove interesting. Jul 06 16:57:40 adelcast: `opkg --offline-root /tmp/foo some/*ipk` makes use of /tmp/foo/etc/opkg.opkg.conf onces that is installed, breaking some path handling. is that considered a bug? Jul 06 16:58:25 (given that *ipk is a bunch of packages including opkg.ipk which contains the conf file) Jul 06 17:00:35 i worked around it by speciying --tmp-dir by now, but that one took me a short while to bisect Jul 06 17:35:36 Piraty: yes, its expected behavior....-o is akin to a chroot Jul 06 17:36:25 its used on OE to build the image, whatever opkg.conf you have on the opkg.ipk it is placed on the offline root and used on subsequent operations Jul 06 17:39:25 rburton: Looks like I didn't have notifications set for new issues on meta-kernel *facepalm* Jul 06 17:57:45 clearly it is monday. I'm not able to get devupstream to do what I want. shouldn't I just be setting my preferred version to the devupstream variant ? that's what I glean from the docs. Jul 06 18:17:08 has anyone had to deal with non-ancient clang versions and edk2 on msm platforms? pulling hairs with crappy build system mixing host and native compilers, gcc, clang and no sane way to set CFLAGS etc Jul 06 18:48:43 Hi there, I'm trying to build a yocto image on a NixOS host. I've gotten this to work in varying degrees multiple times, but yocto changes added new breakages (which is fine, NixOS is not a supported build environment). Right now my build is failing during the configure script of m4-native, when it tries to test the compiler. I noticed that the configure script does not get the environment variables I set, even those I added to BB_ENV_EXTRAWHITE. Is there some Jul 06 18:48:43 way to prevent the environment variables being cleared for builds? Jul 06 18:59:54 sigh, msm edk2 I have is a old, hacked fork of https://github.com/tianocore/edk2 with no fixes ever applied... Jul 06 19:08:46 does bbmulticonfig invalidate my sstate cache? Jul 06 19:09:45 Guest47888: I don't think it should Jul 06 19:10:11 Guest47888: If you think it is, try diffing the signatures to see why Jul 06 19:10:52 pbb: why not just use CROPS or pyrex? Jul 06 19:14:42 LetoThe2nd: I didn't know about Pyrex, I'll have a look. Thanks. Jul 06 19:14:49 I use Tuperware Jul 06 19:17:47 armpit: too little metal. **** BEGIN LOGGING AT Mon Jul 06 19:24:35 2020 Jul 06 19:29:58 adelcast: 'akin to a chroot' well yeah, that's what i expected. in fact, my expectation is that is uses the path as found in opkg.conf relative to / in offline-root, not in host. Jul 06 19:29:58 the experienced case is: the conf file specicies a special tmp_dir which exist in offline-root but not on host. installation of ipk fails exactle one package after opkg because that dir doesn't exist on the host Jul 06 19:30:31 when you say 'akin to chroot' i expect it to use an offline-root prefix at least Jul 06 19:30:46 no uchroot or sth involved i guess? (didn't look it up too much yet) Jul 06 19:50:46 JPEW: ok. i am trying to fix our slow ass build system Jul 06 19:51:08 i'm hoping that using multiconfig with one multiconfig per machine will make it much faster than doing each machine serially... Jul 06 19:54:28 Guest47888: not suer about that. Jul 06 19:54:54 Guest47888: It might to some extent. Jul 06 19:55:07 i don't see where you expect the gains to come from, unless you are not using shared sstate cache at the moment. Jul 06 19:55:27 ^^ Oh, right, thats correct Jul 06 19:56:13 it does about the same amount of parsing, it does the same amount of reuse... Jul 06 20:02:17 our build system is dumb because the build dir is thrown away Jul 06 20:02:31 some genius thought it was a great idea to use containers Jul 06 20:03:19 i am in the process of trying to make optimizations but there's layers of crap Jul 06 20:03:20 Guest47888: I use a container.... but it bind mounts in the build directory Jul 06 20:03:26 jenkins, docker, aws Jul 06 20:05:16 ah i remember. you're the guy that was like "we cannot wipe tmp and reuse sstate because $swguy said so", right? Jul 06 20:06:03 JPEW: i'd rather call you mister container when it comes to this :) Jul 06 20:09:21 LetoThe2nd: no Jul 06 20:09:42 i didn't have any involvement in the original setup of this stuff on jenkins.. but that guy just left :) Jul 06 20:10:45 Guest47888: then there is at least one person with a similarly whacked setup on the planet, who was around here about two weeks ago. Jul 06 20:11:27 Drop the aws and that sadly describes our CI Jul 06 20:12:23 Although.... We just build each product (machine) in parallel Jul 06 20:12:32 i don't remember the exact details, i just remember that somebody around here sounded awfully familiar, but basically self-inflicted pain. Jul 06 20:15:32 Guest47888: I was emboldened just a few days ago and decided to figure out how I would build a aws + Jenkins CI system from the ground up.... I actually really like what I came up with. Kinda wish our local CI was in AWS Jul 06 20:18:08 LetoThe2nd: I need to figure out if I can use pyrex as the container engine for kas.... I think it would be an unstoppable force :) Jul 06 20:30:08 JPEW: certainly doable. but not anymore today, for me :P Jul 06 20:35:17 JPEW: have any learnings to share? Jul 06 20:35:31 JPEW: are you using jenkins parallel blocks? or multiconfig? Jul 06 20:36:17 you say that you are mounting in the build dir to reuse tmp and parse cache, how do you ensure that parallel builds dont trample each others tmp dir? Jul 06 20:37:18 we have 8 machines currently, so i'm interested to hear about methods of making it faster to build Jul 06 20:45:33 Guest47888: In think in general, you will get the best performance by running builds in parallel Jul 06 20:45:59 Guest47888: It's somewhat orthagonal to using multiconfig Jul 06 20:46:53 Guest47888: I don't have multiple builds sharing a tmp dir. Even when I use multiconfig to build multiple products at once, each one has a unique tmp dir Jul 06 20:47:07 But they all use the same sstate and dl cache Jul 06 20:47:59 Guest47888: I would start with just building the 8 in parallel. After that, figure out a way to get them to share sstate / dl dir Jul 06 20:51:49 hi Jul 06 20:52:24 JPEW: you mean using parallelism outside of bitbake? Jul 06 20:52:30 e.g. jenkins-based parallelism? Jul 06 20:53:04 we already do share sstate/dwnloads to some degree, also by bind-mounting into containers Jul 06 20:53:50 jonmason: yt ? Jul 06 20:54:38 i have set the docker environment crops - but can not run sudo command as it asks for a password when i follow the instructions, do you know the password or how to overcome the password issue? Jul 06 20:54:52 khem: yes? Jul 06 20:55:00 Guest47888: Yes, having jenkins launch multiple builds in parallel Jul 06 20:55:22 jonmason: patch for using dynamic layers is still pending are you guys considering to fix this issue Jul 06 20:55:24 Guest47888: Matix, parallel pipeline, separate jobs, choose your poison :) Jul 06 20:56:47 JPEW: my poisin is 'no', preferrably. i detest jenkins and would prefer to avoid any logic in it Jul 06 20:57:15 Hi Folks, I have a fetcher question. I have 2 different git repos in SRC_URI and they require different SRCREV hashes. If I set SRCREV for the primary and then use rev= in the URL for the secondary git, the primary seems to be fetched OK, but the secondary fails due to a check in the fetcher that validates SRCREV == rev as a sanity check (which makes sense), but now I am not sure how to reconcile it Jul 06 20:58:12 Guest47888: Ah, fair enough :) Jenkins is all I really know.... but having used a few different methods I'm partial to Pipelines and describing all the config in a Jenkinsfile in the repo Jul 06 20:58:39 sgw1: use SRCREV_foo = "SHA1" SRCREV_bar = "SHA2" Jul 06 20:58:42 sure, we have that too Jul 06 20:58:43 sgw1, I think you can name them Jul 06 20:58:53 what khem said Jul 06 20:59:00 Guest47888: Gives you pretty much the same thing as most other ci (gitlab-ci, travis, whatever) where the job description lives with the code Jul 06 20:59:13 JPEW: but our previous build system had so much logic encoded into jenkins it was not feasible to even try to make a build locally Jul 06 20:59:29 and groovy/jenkins groovy bindings are total crap Jul 06 20:59:36 Ok, let me give that a try, it's been a while, I need to reload my bitbake cache ;-)! Jul 06 21:00:01 Guest47888: Ya, being able to build locally what Jenkins does remotely is always a problem.... containers help there Jul 06 21:00:21 Although it sounds like you've had trouble with those also Jul 06 21:00:47 i also hate containers. :-) Jul 06 21:01:38 Guest47888: Any reason why? Jul 06 21:01:46 in my previous job i worked on an OS meant for server container deployments using docker.. so i got a bad taste for it Jul 06 21:01:50 sgw1: you need to use subpath and name keywords on src_uri for this to work and also ensure to define SRCREV_FORMAT = "foo_bar" to make sure bitbake can include them in signatures Jul 06 21:02:46 now i work on embedded routers (now with yocto of course) but can't escape containers in the build system Jul 06 21:06:40 khem: I'll discuss it with rburton tomorrow, as he's gone for the day Jul 06 21:13:15 jonmason: k, thanks let me know what you guys decide, I would like to unbreak yoe distro based on whateever you guys decide Jul 06 21:14:00 khem: we're arguing semantics of implementation, but agree that it needs to happen Jul 06 21:14:36 khem: armpit: thanks that was the trick. Jul 06 21:30:38 Guest47888: Well, FWIW, the project doesn't mandate that you use containers, it tests on a lot of different hosts for that reason. If you really want to avoid the contianers, look at the recent work with the buildtools tarball Jul 06 21:39:07 i know, it's only in jenkins we do that Jul 06 21:39:16 i and most other people just use a plain ubuntu host. Jul 06 21:40:06 JPEW: how do you ensure your containers get unique workdirs while also reusing them? Jul 06 21:44:15 Hello! I have recently started trying out eSDK builds in an enterprise setting (read old yocto - thud, almost). I have been getting a warning such as Jul 06 21:44:17 ERROR: When reparsing .../core-image-minimal.bb.do_populate_sdk_ext, the basehash value changed from 5fbdca49002cb10d09e7bea964f17fcc to e9acb0cf002fb8249e57aed6b7f1fdbd. The metadata is not deterministic and this needs to be fixed. Jul 06 21:45:42 I do not see any DATETIME or such variables from the build environment, is there a reason I am missing that I should be looking for? and what is this hash value of and at what stages does it get reparsed? Jul 06 21:48:13 Guest47888: I bind in my local workspace to the container, so it's operating on my "local" filesystem Jul 06 21:48:34 Much like if I wasn't using a container, I can't run multiple builds simultaneously out of the same workspace Jul 06 21:53:37 hmm.. yeah, not going to work for automated builds. Jul 06 21:54:28 Guest47888: Why? We do it for our automated builds? Jul 06 21:56:46 JPEW: i am confused by what you mean by 'I bind in my local workspace to the container' then Jul 06 22:00:55 Guest47888: I'm not executing the git fetch command and such in the container, those all happen on my host. Our container just wraps the bitbake commands so that they run in the container: https://github.com/garmin/pyrex Jul 06 22:01:26 But it does that by bind mounting your local existing workspace and build directory into the container Jul 06 22:01:52 For the most part, our users (and CI scripts) can't really tell it's running in a container over just running bitbake locally Jul 06 22:02:47 The advantage here is that our users are using the same container as our CI, so it's easier to reproduce the setup Jul 06 22:04:13 Guest47888: Any, it's supper time, so I have to go. Good luck! Jul 06 22:08:51 Piraty: ah, I see, you are talking about the tmp_dir setting....yeah, its not using offline root and it probably should, could you open a bugzilla ticket? Jul 06 22:10:08 JPEW: thanks **** BEGIN LOGGING AT Tue Jul 07 02:51:46 2020 **** ENDING LOGGING AT Tue Jul 07 02:59:58 2020