**** BEGIN LOGGING AT Thu Sep 10 07:36:15 2020 Sep 10 08:04:51 mihaix: yes, indeed ! prompts like "choose partition (sda):" Sep 10 08:05:11 Hello again every one, I hope you are all staying safe! Sep 10 08:09:01 hi dmation Sep 10 08:09:49 Hi Khem :) Sep 10 08:11:44 Out of interest how are people doing CI/CD with yocto? Sep 10 08:14:25 dmation: mckoan is doing: https://koansoftware.com/autobuilder2-talk-yocto-project/ (or at least they presented it :) ) Sep 10 08:15:27 PaowZ_: take a look at ./meta/recipes-core/initrdscripts/files/init-install.sh script, you could write and use a custom one Sep 10 08:15:52 most probably you're talking about the prompts from that script Sep 10 08:25:37 qschulz: Thanks for that link! I'm interested in integrating Yocto build in CI/CD as well! Sep 10 08:28:14 ditto, thanks Sep 10 08:30:08 qschulz: indeed, thank you! Sep 10 08:30:20 tks mihaix, will do ! Sep 10 08:31:00 dmation: however many users use Jenkins or Gitlab too Sep 10 08:32:46 Hi All, I am using a buildsystem based on Rocko and I am getting errors when I try to populate extensible SDK Sep 10 08:33:16 I have been playing with Jenkins... Sep 10 08:35:45 another issue I have, is that I am trying to use devtool to add source from our internal git repo. We are using bitbucket and it runs on our internal network on a specific port. Sep 10 08:35:59 dmation: interesting. Share your thoughts Sep 10 08:36:52 michaellarsen: if you don't give us more context, we won't be able to help you. which "errors" are you getting? which machine, which layers, which distro, etc... :) Sep 10 08:38:52 qschulz: sorry, I will be right back with more info. Sep 10 08:41:05 mckoan, I have only just begun down that road, It's ok, but I have to do a lot of scripting and work arounds to keep it running. I feel like a CD system that requires maintanace will not be maintained for long. Sep 10 08:41:09 michaellarsen: same for your devtool issue with bitbucket, you need to ask a question :D Sep 10 08:42:25 I might add that I build inside a docker container as we have some systems witch run under ubuntu 16 and others that run under ubuntu 18... Sep 10 08:43:01 *which, please excuse my grammar... Sep 10 08:44:42 dmation: internet search for "yocto continuous integration" will bring a bunch of presentations with details from various setups. feel free to ask for more details here as people are present... Sep 10 08:46:50 qschulz: got it. I will be back Sep 10 08:49:45 qschulz: Regarding my devtool issue. I think it relates to the fact that our bitbucket server is at port 7990. It seems that the git fetch mechanism is having a hard time understanding http://:7990/path/to/project/repo.git Sep 10 08:51:09 Mcfrisk, thank you. I have been watching at presentations on youtube. In particular the one from Tim Orling caught my attention [https://www.youtube.com/watch?v=l6NwYGbWO5s]. Having a system that can automagically test on target devices does appeal to me, however LAVA seems like overkill for my application. I was more curious about what people preferred and why. But I suppose that is like asking what programming language you prefer; it depends on what the Sep 10 08:51:09 application is. Sep 10 08:52:02 michaellarsen: the usual question is: have you tried on Yocto master? (in that case it should be super easy since it's only devtool add :) ) if it still does not work, then a bug report needs to be filled and/or more discussion can happen :) Sep 10 08:52:04 I will look into Autobuilder and ask if I have any specif questions Sep 10 08:53:58 once you have a large test lab with lots of HW variants then LAVA will help. Custom setups may need more maintenance in the long run... Sep 10 08:55:57 qschulz: I have not tried master, I will be trying that. Thanks. **** BEGIN LOGGING AT Thu Sep 10 09:23:04 2020 Sep 10 09:25:19 qschulz: I get the following error when I try to build/populate the extensible sdk, using -c do_populate_sdk_ext -> https://pastebin.com/bqgEDvGB Sep 10 09:28:12 I am on rocko and the corresponding bitbake 1.34 Sep 10 09:28:40 -c do_populate_sdk completes just fine Sep 10 09:46:44 * RP notes we have okayish builds of thud and warrior on the autobuilder again Sep 10 09:46:52 hmm.. does IMAGE_POSTPROCESS_COMMAND run before the rootfs image file exists in DEPLOY_DIR_IMAGE ? Sep 10 09:46:59 I guess I should sent out the patches and call that all done Sep 10 09:47:13 I'm trying to make a tarball containing the rootfs, the zImage, the initrd and a custom u-boot script Sep 10 09:47:32 using a IMAGE_POSTPROCESS_COMMAND on the rootfs recipe itself **** BEGIN LOGGING AT Thu Sep 10 09:49:35 2020 Sep 10 09:50:39 is it available in some other directory, but not yet in DEPLOY_DIR_IMAGE at this stage? Sep 10 09:51:46 xantoz: DEPLOY_DIR_IMAGE is populated after do_image_complete is done Sep 10 09:52:00 do_image_complete is the one executing your IMAGE_POSTPROCESS_COMMANDs Sep 10 09:54:52 right Sep 10 09:56:01 is the rootfs available at some other place during this stage? or do I need to figure out a way to run my code after do_image_complete? Sep 10 10:04:07 xantoz: according to https://www.yoctoproject.org/docs/current/mega-manual/mega-manual.html#var-IMAGE_POSTPROCESS_COMMAND, IMAGE_ROOTFS Sep 10 10:06:36 xantoz: I don't know if files from recipes' deploy task are available at that time Sep 10 10:06:38 I'm trying to use env vars in my local.conf like so: `SSTATE_MIRRORS = "${@os.getenv('MYENVVAR', '')}"` and then run `MYENVVAR=something bitbake -e | grep ^SSTATE_MIRRORS` but it comes up empty Sep 10 10:06:59 simonpe^^: https://www.yoctoproject.org/docs/current/mega-manual/mega-manual.html#var-bb-BB_ENV_EXTRAWHITE Sep 10 10:07:08 (probably) Sep 10 10:07:22 qschulz: oooooooh :D thx Sep 10 10:09:46 qschulz: Im not sure what "You must set this variable in the external environment in order for it to work." means though Sep 10 10:10:21 Does that mean BB_ENV_EXTRAWHITE=MYENVVAR MYENVVAR=hello bitbake ...? Sep 10 10:11:01 simonpe^^: BB_ENV_EXTRAWHITE can be set in your local.conf, then MYENVVAR can probably be read from there or if you have it exported in the current environment Sep 10 10:11:40 actually that didn't work, but if I set it in my shell environment it works Sep 10 10:12:35 simonpe^^: define "that" Sep 10 10:12:58 ah... passing MYENVVAR just before bitbake Sep 10 10:13:02 qschulz: isn't IMAGE_ROOTFS the rootfs files, and not the rootfs image file though? Sep 10 10:13:11 I want to have the rootfs image file in my tarball Sep 10 10:13:32 simonpe^^: I don't know how Yocto does it for MAHCINE (we use it this way) Sep 10 10:13:39 should I maybe be doing this in do_deploy_append instead? Sep 10 10:13:50 xantoz: or just go for an image type? Sep 10 10:14:01 for the tar ball? Sep 10 10:14:33 qschulz: that as in BB_ENV_EXTRAWHITE needs to be exported in the shell env before running bitbake, it can't be defined in the local.conf file Sep 10 10:15:10 what I'm trying to make, btw, is an "upgrade package" for a custom A/B banked system Sep 10 10:15:35 using wic to get the whole SD-card image, which is used for initial "factory" flashing Sep 10 10:17:00 xantoz: have an image type dependening on the wic image type Sep 10 10:17:16 IMAGE_CMD_ should be a good pointer Sep 10 10:17:30 simonpe^^: ok, thanks for the heads up Sep 10 10:17:52 simonpe^^: (there are many things we aren't doing right so I don't know if it's from us or a Yocto thing sometimes :/) Sep 10 10:19:56 (we = the company I work for) Sep 10 10:20:30 so an image that depends on the rootfs image? Sep 10 10:28:40 xantoz: why not use ready frameworks for update? swupdate for example does what you're planning to do Sep 10 10:31:11 zandrey: we're porting from a custom build, and need backwards compatibility Sep 10 10:31:47 custom image build system Sep 10 10:32:02 xantoz: no, an image **type** that depends on the wic image **type** Sep 10 10:32:16 hmm... I might need to study up on the concepts a bit better here Sep 10 10:33:38 xantoz: not saying it is correct but that's something I'd investigate Sep 10 10:33:43 xantoz: well... then i have nothing to suggest. ;) i would still look into available update frameworks, since it might be that you would not be able to hold on to "custom image build system" forever. at least - i was not able to. ;) Sep 10 10:34:02 oh, I already have looked a bit at mender etc. for inspiration Sep 10 10:34:30 there's a few custom things going in with the upgrade system in place as well, which I don't think at least mender was fully able to address, so Sep 10 10:34:49 it's also RPi based, so upgrades suck Sep 10 10:35:16 I don't think mender solves the problem that config.txt, for instance, can't be dual-banked... Sep 10 10:35:41 or that the rpi bootloader likes to do wierd tweaks to the DT during boot based on fun things like what HDMI port is connected Sep 10 10:36:02 (here's to hoping to graduating from the RPi soon) Sep 10 10:37:25 xantoz: looks like you've done your "due diligence" already :) Sep 10 10:38:43 well, a bit of it at least. there's still some sketchy parts, but the custom upgrade system has an A/B banked u-boot script that does the actual loading of the kernel etc. so endless DT tweaks should be able to be done at that stage should they be needed in the future Sep 10 10:39:03 just have to reverse-engineer what the pi bootloader does... Sep 10 10:41:15 question: is there any way to speed up the bitbaking of npm recipies? because the pace it's currently going at is insufferable Sep 10 10:45:07 and most of it is in the do_configure stage, I've had a cursory look at the npm.bbclass but nothing really stood out. Sep 10 10:50:30 nice to see sgw continuing the fine tradition of signing off patches using a previous employer's email Sep 10 11:03:21 Hi everyone, I'm very new to yocto .. just trying to follow a book but I'm getting some warnings while bitbaking a raspberry pi image.. then If I write created img to rpi nothing happens... Sep 10 11:03:29 can somebody help me? Sep 10 11:09:18 say what the warnings are and we might be able to help Sep 10 12:02:29 seems like I would be able to grab the rootfs image out of IMGDEPLOYDIR in IMAGE_POSTPROCESS_COMMAND **** BEGIN LOGGING AT Thu Sep 10 12:44:10 2020 Sep 10 13:01:47 RP: who looks like an idiot saying yesterday that thud is completely dead to his colleagues and receives ~30 patches the next day :D Sep 10 13:11:40 qschulz: hehe RP did it for thud and more; he is a patch machine Sep 10 13:19:41 qschulz: well, I did post about wanting to at least get things buildable and that most of the work has been done Sep 10 13:22:06 * RP has another 40 patch set for thud auto-builder-helper but needs to wait an hour to avoid the mailing list post limits :/ Sep 10 13:24:02 * qschulz faints Sep 10 13:24:20 RP: I only read Armin's mail quickly so maybe missed something Sep 10 13:24:35 RP: but it's good actually, a nice way to turn the page :) Sep 10 13:28:27 Has anyone heard of a class `go-mod`? An elastic beats meta-layer inherits from that class, but my yocto system doesn't find it. https://gitlab.com/dimtass/meta-elastic-beats/-/blob/master/recipes-devops/elastic-beats/elastic-beats.inc#L5 Sep 10 13:28:53 manuel1985: http://cgit.openembedded.org/openembedded-core/tree/meta/classes/go-mod.bbclass?h=master Sep 10 13:29:30 qschulz: this is basically getting things into some sane state so we don't "lose" the work we have lying around Sep 10 13:29:49 manuel1985: you need to base your proejct on dunfell Sep 10 13:30:12 manuel1985: yes, we added it recently Sep 10 13:31:39 Its been a few years since I sent out series like this :) Sep 10 13:31:53 kanavin_home: you've got competition :) **** BEGIN LOGGING AT Thu Sep 10 13:34:55 2020 Sep 10 13:39:06 qschulz, otavio: Thanks! Sep 10 13:40:29 Interesting that I didn't have opemembedded-core as metalayer Sep 10 13:43:40 manuel1985: i'm pretty sure poky/meta is openembedded-core Sep 10 13:43:54 and that without openembedded-core you can't build anything Sep 10 13:49:57 qschulz: I see. I thought its a seperate layer just as meta-openembedded. Sep 10 13:51:31 why is it that, when using a file:// SSTATE_MIRRORS, the SSTATE_CACHE directory ends up with (absolute) symlinks into the mirror ? Sep 10 13:53:09 manuel1985: it is separate, but it's also "merged" into poky/meta every now and then Sep 10 13:59:09 qschulz: Okay, got it. Some more questions regarding https://gitlab.com/dimtass/meta-elastic-beats/-/blob/master/conf/layer.conf: Here we have `LAYERDEPENDS_meta-elastic-beats = "core"`. I was wondering what `core` means. I mean, I suspected it refers to `openembedded-core` but I wasn't sure. Is it correct that `core` refers to `openembedded-core`, because it has `core` set as it's "internal" name with `BBFILE_COLLECTIONS += "core"` in it Sep 10 13:59:10 s `layer.conf`? https://git.openembedded.org/openembedded-core/tree/meta/conf/layer.conf#n6 Sep 10 14:00:07 Just trying to figure out how all these puzzle pieces fit together Sep 10 14:01:46 manuel1985: that makes sense to me Sep 10 14:04:15 Perfect ;) **** BEGIN LOGGING AT Thu Sep 10 14:28:50 2020 Sep 10 14:30:16 RP: but aren't those cherry-picked backports? :) Sep 10 15:05:46 Has anyone experience with building golang applications through a recipe? Does everything just "magically work", or does one take care of specific things? I would like to include https://gitlab.com/dimtass/meta-elastic-beats in my arm64 image. Sep 10 15:06:05 yeah it mostly works Sep 10 15:06:12 theres a go-helloworld in oe-core to demonstrate Sep 10 15:06:26 arm64 hosts might need master though unless i remembered to backport the fix to dunfell Sep 10 15:06:40 but if you're just arm64 target you're fine Sep 10 15:07:26 Hmmm I'm on zeus :) Sep 10 15:08:03 So not even on dunfell Sep 10 15:11:07 worked in zeus, iirc Sep 10 15:11:13 RP: glad to see my patch applied afer one year :-D Sep 10 15:11:27 RP: are you reworking AM2 ? Sep 10 15:11:31 AB2 Sep 10 15:30:55 kanavin_home: many of them, yes but many needed minor porting Sep 10 15:34:02 mckoan: no rework, just sorting out old branches Sep 10 15:34:23 mckoan: It was applied last year: http://git.yoctoproject.org/cgit.cgi/yocto-autobuilder-helper/commit/?id=5ba152e55688b27c745a787a5ca968bb058ebf25, this was just backporting to older branches Sep 10 15:39:34 RP: question, does the long login happen every boot or just first boot? Did you look at that in your initial investigations? Sep 10 15:42:13 sgw: not checked Sep 10 15:43:43 Ok thanks, something I will play with also. I realize that for the Autobuilder and testing it's just first boot typically, so that matters most Sep 10 15:45:08 sgw: right, its the autobuilder that is highlighting this Sep 10 16:54:18 Hi all. I'm using the latest Zeus release. I just got this error. Any guidance on how I can fix this? Sep 10 16:57:32 * check_data_file_clashes: Package ebtables wants to install file /data/mberger/build-compliance/strong-reciprocal/yocto/build/exos-x86-64/tmp/work/exos_x86_64-poky-linux/core-image-minimal/1.0-r0/rootfs/etc/ethertypes Sep 10 17:04:04 * armpit heheh sgw, I like your reply to Sep 10 17:28:36 armpit: reply to what? the systemd boot issue or my first patch in 2+ years! Sep 10 17:42:47 sgw, your from email was wind and reply email was to intel Sep 10 18:29:43 kergoth: name for split-usr seems to be usrmerge; i appended it to PKGCONFIG; make bitbake give lots of QA warnings, fine... what i'm wondering is that am i still going to get /{bin,sbin,lib} directories or bitbake has this baked into it to figure out, oh usrmerge is enabled so lets make those symlink? Sep 10 18:30:41 another question i have is regarding meta-arm-*, should i prefer say meta-arm-bsp over say meta-yocto-bsp? Sep 10 18:30:57 ... building for arm of course Sep 10 18:39:38 jrun: you'll want to set it in your DISTRO_FEATURES. and check the base-files recipe, its what sets up the baseline filesystem Sep 10 18:54:02 kergoth: not in bitbake.conf? Sep 10 18:54:09 i see this there: root_prefix = "${@bb.utils.contains('DISTRO_FEATURES', 'usrmerge', '${exec_prefix}', '${base_prefix}', d)}" Sep 10 18:54:35 that sets the default variables, but if there are compatible symlinks, they would be created in base-files. i don't know the answer Sep 10 18:54:40 that changes where things are installed, yes Sep 10 20:34:14 kergoth: found it https://github.com/rossburton/meta-ross/blob/master/classes/bbin.bbclass Sep 10 20:35:19 oh nice Sep 10 20:35:32 that huge todo sitting at the top though :) Sep 10 20:38:52 yeah.. i cheated with wks.in, i shoved the whole value into the metadata and expanded it when writing it and relied on the existing variable expansion tracking for it :) Sep 10 20:39:06 not exactly general purpose, though Sep 10 20:43:21 kergoth: It's such a useful cheat... I may have copied the concept on something else I've done recently :) Sep 10 21:03:48 nice :) Sep 10 21:17:23 What is the process that poky goes through to check binary exactness between builds? Sep 10 21:17:37 Any helper scripts or docs on this? Sep 10 21:34:03 rabbit9911: What do you mean by "binary exactness"? Sep 10 21:35:47 rabbit9911: There is a test that checks several of the packages in OE-core for binary reproducibility: https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/lib/oeqa/selftest/cases/reproducible.py **** BEGIN LOGGING AT Thu Sep 10 23:29:35 2020 **** BEGIN LOGGING AT Fri Sep 11 02:54:30 2020 **** ENDING LOGGING AT Fri Sep 11 02:59:57 2020