Wednesday, 2022-03-23

AustrianCurrentmoto-timo: That's fair. Thanks, I have tried to do my homework and doing a lot of reading. But I think I might I have a fundamental misunderstanding that's making this question challenging to Google (or at least phrase appropriately). I understand Yocto seems to be fundamentally about building from source. It uses bitbake files to create packages00:01
AustrianCurrent(usually via pulling from revision control) that get added to a final image that gets flashed onto a board. However, what if I want to circumvent the bitbake build system and use dnf at *build* time to resolve dependencies. I don't necessarily want dnf in the image. I understand I will have to create recipes to facilitate this though, but I don't00:01
AustrianCurrentwant to have to touch bitbake file every time I update an application or library.00:01
*** leon-anavi <leon-anavi!~Leon@> has quit IRC (Quit: Leaving)00:02
AustrianCurrentmoto-timo: That's fair. Thanks, I have tried to do my homework and doing a lot of reading. But I think I might I have a fundamental misunderstanding that's making this question challenging to Google (or at least phrase appropriately). I understand Yocto seems to be fundamentally about building from source. It uses bitbake files to create packages00:02
AustrianCurrent(usually via pulling from revision control) that get added to a final image that gets flashed onto a board. However, what if I want to circumvent the bitbake build system and use dnf at *build* time to resolve dependencies. I don't necessarily want dnf in the image. I understand I will have to create recipes to facilitate this though, but I don't00:02
AustrianCurrentwant to have to touch bitbake file every time I update an application or library. Edit: This could be a product of not understand efficient development in Yocto though.00:02
AustrianCurrentmoto-timo: That's fair. Thanks, I have tried to do my homework and doing a lot of reading. But I think I might I have a fundamental misunderstanding that's making this question challenging to Google (or at least phrase appropriately). I understand Yocto seems to be fundamentally about building from source. It uses bitbake files to create packages00:02
AustrianCurrent(usually via pulling from revision control) that get added to a final image that gets flashed onto a board. However, what if I want to circumvent the bitbake build system and use dnf at *build* time to resolve dependencies. I don't necessarily want dnf in the image. I understand I will have to create recipes to facilitate this though, but I don't00:02
AustrianCurrentwant to have to touch bitbake file every time I update an application or library. Edit: This could be a product of not understand efficient development in Yocto though.00:02
*** AustrianCurrent4 <AustrianCurrent4!~AustrianC@2601:152:4d00:84b0:69f6:45c7:4a09:ac8a> has joined #yocto00:03
*** AustrianCurrent <AustrianCurrent!> has quit IRC (Quit: Client closed)00:03
AustrianCurrent4Also new to IRC chats, I apologize :(00:03
moto-timoAustrianCurrent: bitbake builds intermediate packages (ipk, deb, rpm) and uses those to stitch together the final image (in the case of rpm with dnf)00:03
moto-timoAustrianCurrent4: you can set up a "package feed" to expose your rpms as a dnf repo to install packages on the target... it's not trivial but can be done. You can also use e.g. devtool deploy target to send a particular update to the target board. Some folks prefer to use TFTP or NFS during development time to make this all easier/faster.00:05
AustrianCurrent4moto-timo: Interesting, can these RPMs be 2nd party (to Yocto) and RPMs I build via CPack or rpm or do they have to be create via bitbake?00:07
AustrianCurrent4So the package feed seems to be a dnf repo derived from Yocto build artifacts. However, can you plop a custom built or 3rd party RPM in it and expect Yocto to pick it up?00:08
moto-timoAustrianCurrent4: I call those third party RPMS... they _might_ work... but not likely. Very brittle. The reason is that you are not in control of gcc, glibc, libraries, etc. that were used to make those 3rd party rpms. Yocto Project/Open Embedded bootstraps itself from a minimal set of host tools and then owns everything beyond that. Everything is consistent.00:09
AustrianCurrent4moto-timo: Even if a nightly-built SDK is being used to build the RPMs via CPack?00:10
moto-timoAustrianCurrent4: and rpm is not universal. It has a pedigree. Many many factors go into whether it will be compatible with your architecture, specific board, specific version of libraries/applications. It is a road to madness.00:10
moto-timoAustrianCurrent4: if you are using a Yocto built SDK (or eSDK "extensible SDK") then you will have better luck. I don't personally have any experience with CPack so I cannot claim any knowledge. I have experience with Fedora's modularity, Flatpack and snaps. All of them are a road to pure unabashed insanity. You will only go down a path of seeming compatibility to find that the bridge behind you is on fire and you have no where to go.00:12
moto-timoAustrianCurrent4: the Yocto Way is to build everything from source. For a reason.00:12
*** AustrianCurrent <AustrianCurrent!~AustrianC@2601:152:4d00:84b0:7912:542f:b4aa:6017> has joined #yocto00:15
AustrianCurrentmoto-time: Interesting. So it's highly encouraged to use source builds. That's fair. I've seen layers like this that do similar things to what I'm trying to attempt but like you're saying it's a dark road00:15
moto-timoAustrianCurrent: all the stars must be aligned for that to work. Everything must be ABI/API compatible. Once some binary only change happens you are hosed. Dead in the water with no rope.00:17
moto-timoAustrianCurrent: swtich to a new SoC  or a new board? hosed.00:17
moto-timoAustrianCurrent: meanwhile, with properly curated Yocto Project layers... a switch to a new SoC could be as simple as MACHINE="foo" -> MACHINE="bar". Done. (Not always that simple)00:18
*** AustrianCurrent4 <AustrianCurrent4!~AustrianC@2601:152:4d00:84b0:69f6:45c7:4a09:ac8a> has quit IRC (Ping timeout: 256 seconds)00:19
AustrianCurrentmoto-timo: Okay, so to not have to touch a bitbake file every time I patch a library, I should still make a bitbake file but use the AUTOREV and make sure I version my so's00:19
moto-timoAustrianCurrent: when I first started on this path, I had 9 SKUs to worry about. I knew there was no way that I could do that with e.g. Buildroot and stay sane.00:19
moto-timoAustrianCurrent: I do not recommend AUTOREV except for early development. Just get your git foo in shape and keep the SRCREV updated (or the sha256sum of the tarball or whatever).00:20
moto-timoAustrianCurrent: AUTOREV forces a fetch for parsing. It slows everything to a crawl and if there is ANY glitch in networking you are completely hosed. Done. No way out.00:20
* moto-timo has strong opinions on certain things.00:21
AustrianCurrentAh haha, gotcha. So I guess that goes back to my fundamental problem, I want to be able to push out minor and patch bumps that maintain ABI compatibility without having to edit a bitbake file.00:22
moto-timoAustrianCurrent: you can use for instance "devtool upgrade" to make the workflow simpler to update recipes... it's not perfect but it works well in some use cases00:23
moto-timoAustrianCurrent: why? what is the aversion to editing the bitbake file? It is just part of your "source". Yeah, it's metadata. Just keep your source trees and your metadata in sync. It's not that much effort IMHO.00:24
* moto-timo on a bit of a high horse right now... so take this with a grain of salt00:24
AustrianCurrentYeah just takes up some extra bandwidth I guess.00:25
moto-timoworklfow: edit library source, push commit, change SRCREV in bb, build, deploy to target00:25
moto-timodepending on your team size you can use "devtool modify" to edit the source library... likely that isn't going to fit the bill, but it might.00:26
moto-timothe extensible SDK was designed to allow a hybrid... you have an SDK but you also have _some_ of the bitbake tooling. Not perfect.00:27
moto-timoTBH, I spend _much_ less bandwidth on the metadata updates than I do on patching/upgrading components to newer versions or new functionality.00:28
moto-timoout of date, but
moto-timoand also (me)
AustrianCurrentI guess I have a team full of people who like to use shared libraries, so it I guess to them it feels like extra effort to support a recipe for every library and have to increment every patch. However, I think that's because it's early development. I do have a dependency with a fairly complex build process that I am sort of concerned about creating00:33
AustrianCurrenta recipe with because it needs npm and java-runtime. It's easy to build and package myself. But I do see meta-nodejs and meta-java are things.00:33
AustrianCurrentI will look further into the devtool workflow though. I think this will solve a lot of my problems developing these recipes.00:34
moto-timoI look at layers as Lego(TM) building blocks... pick and choose what you need to make the CoolThing00:35
moto-timoin the long run, you are much better off re-using upstream anything that is well maintained than home grown... without question.00:35
moto-timoand the corollary is it is in your best interest to contribute to upstream00:36
moto-timotechnical debt will be a noose around your neck that drags you to the poor house.00:36
moto-timoif those shared libraries are autotools, meson, cmake... etc. well behaved build systems, devtool add and devtool upgrade will likely JustWork(TM) out of the box. As long as you don't have crutches of things like PLATFORM=$(shell uname -m) or similar... those things are not cross-compile friendly. Everything in OE/YP is cross-compiled... even x86_64  on x86_64 for x86_6400:41
AustrianCurrentBasically use proper install rules?00:42
AustrianCurrentfor cmake I gues00:42
smurrayAustrianCurrent: developers wanting to build shared libs on their dev machines and then piecing them together in some ad hoc build process is a recipe for disaster down the road in production.00:43
moto-timocode like it is 1976... it will work. Code like a cool block chain bro and it will break.00:43
moto-timosmurray: rescues me from blathering on and on and on and on00:44
* moto-timo steps away00:44
AustrianCurrentYep, everyone wants to use RPMs because it's how we managed dependencies before; however, this is the first time on a true embedded system so it's quite the change00:44
smurrayAustrianCurrent: Chris Simmonds has given some talks on the pros/cons of using OE/Yocto versus Debian, maybe look for those, as he addresses some of what I suspect you're interested in00:46
AustrianCurrentSo I assume to give a customer something that you build from source, to do it the yocto way we would have to deliver a layer of binaries. I will watch those talks on YT, thanks smurray00:48
smurrayAustrianCurrent: it depends on what your deliverable is, if you build a h/w product with upgradeable firmware, then you build images and give them to people somehow for upgrades, and Yocto can also be used to build source drops for meeting license requirements for the FOSS parts00:50
AustrianCurrentsmurray: Thanks, yeah that and potentially a SDK they can use to build their own layer on ours.00:52
smurrayAustrianCurrent: yes, building a SDK that can build binaries to run on your target is also something you can do pretty easily00:53
moto-timoAustrianCurrent:  you can also use an OTA solution like, mender, updatehub, rauc, swupdate00:53
* moto-timo really steps away00:54
AustrianCurrentThanks moto-timo and smurray. I will take this back to my team and try to persuade them off our possible road to doom00:55
smurrayAustrianCurrent: good luck!00:56
*** AustrianCurrent <AustrianCurrent!~AustrianC@2601:152:4d00:84b0:7912:542f:b4aa:6017> has quit IRC (Quit: Client closed)00:57
*** ar__ <ar__!~akiCA@user/akica> has quit IRC (Ping timeout: 268 seconds)01:18
*** jclsn <jclsn!> has quit IRC (Ping timeout: 256 seconds)01:19
*** jclsn <jclsn!> has joined #yocto01:25
*** qschulz <qschulz!> has quit IRC (Remote host closed the connection)01:32
*** qschulz <qschulz!> has joined #yocto01:35
*** jclsn <jclsn!> has quit IRC (Ping timeout: 256 seconds)01:36
*** jclsn <jclsn!> has joined #yocto01:42
*** Guest79 <Guest79!~Guest79@2601:644:8102:f530:39a3:f627:7e38:45ce> has quit IRC (Ping timeout: 256 seconds)01:44
*** jclsn <jclsn!> has quit IRC (Ping timeout: 252 seconds)01:48
*** camus <camus!~Instantbi@2409:8a1e:911f:3780:ca5b:76ff:fe31:2c58> has joined #yocto01:48
*** jclsn <jclsn!> has joined #yocto01:50
*** jclsn <jclsn!> has quit IRC (Ping timeout: 252 seconds)01:57
*** sakoman <sakoman!> has quit IRC (Quit: Leaving.)02:03
*** jclsn <jclsn!> has joined #yocto02:03
*** jclsn <jclsn!> has quit IRC (Ping timeout: 256 seconds)02:18
*** jclsn <jclsn!> has joined #yocto02:20
*** jclsn <jclsn!> has quit IRC (Read error: Connection reset by peer)02:25
*** jclsn <jclsn!> has joined #yocto02:25
*** sakoman <sakoman!> has joined #yocto02:26
*** rber|res <rber|res!~rber|> has joined #yocto02:32
*** RobertBerger <RobertBerger!~rber|> has quit IRC (Ping timeout: 256 seconds)02:34
*** jclsn <jclsn!> has quit IRC (Quit: Ping timeout (120 seconds))02:47
*** jclsn <jclsn!> has joined #yocto02:47
*** jclsn <jclsn!> has quit IRC (Ping timeout: 240 seconds)02:52
*** tcdiem <tcdiem!> has quit IRC (Quit: Connection closed)02:53
*** jclsn <jclsn!> has joined #yocto02:59
*** jclsn <jclsn!> has quit IRC (Ping timeout: 256 seconds)03:09
*** jclsn <jclsn!> has joined #yocto03:13
*** jclsn <jclsn!> has quit IRC (Ping timeout: 256 seconds)03:18
*** jclsn <jclsn!> has joined #yocto03:25
*** Starfoxxes <Starfoxxes!~Starfoxxe@2a02:8070:5390:d00:12bf:48ff:feb8:38c8> has quit IRC (Ping timeout: 268 seconds)03:33
*** Starfoxxes <Starfoxxes!~Starfoxxe@2a02:8070:5390:d00:12bf:48ff:feb8:38c8> has joined #yocto03:35
*** amitk <amitk!~amit@> has joined #yocto03:45
*** jclsn <jclsn!> has quit IRC (Ping timeout: 252 seconds)03:51
*** jclsn <jclsn!> has joined #yocto03:52
*** jclsn <jclsn!> has quit IRC (Ping timeout: 268 seconds)04:02
*** sakoman <sakoman!> has quit IRC (Quit: Leaving.)04:37
*** camus <camus!~Instantbi@2409:8a1e:911f:3780:ca5b:76ff:fe31:2c58> has quit IRC (Ping timeout: 240 seconds)04:48
*** camus <camus!~Instantbi@2409:8a1e:911f:3780:ca5b:76ff:fe31:2c58> has joined #yocto04:56
*** prabhakarlad <prabhakarlad!> has quit IRC (Ping timeout: 256 seconds)05:04
*** rber|res <rber|res!~rber|> has quit IRC (Ping timeout: 250 seconds)05:39
*** RobertBerger <RobertBerger!~rber|> has joined #yocto05:39
*** alessioigor <alessioigor!~alessioig@> has joined #yocto05:54
*** geoffhp <geoffhp!> has quit IRC (Ping timeout: 252 seconds)05:57
*** geoffhp <geoffhp!> has joined #yocto05:58
*** alessioigor <alessioigor!~alessioig@> has quit IRC (Client Quit)05:58
*** geoffhp <geoffhp!> has quit IRC (Read error: Connection reset by peer)06:00
*** geoffhp <geoffhp!> has joined #yocto06:01
*** tlwoerner <tlwoerner!> has quit IRC (Remote host closed the connection)06:44
*** tlwoerner <tlwoerner!> has joined #yocto06:44
*** camus <camus!~Instantbi@2409:8a1e:911f:3780:ca5b:76ff:fe31:2c58> has quit IRC (Ping timeout: 240 seconds)07:03
*** camus <camus!~Instantbi@> has joined #yocto07:03
*** rob_w <rob_w!> has joined #yocto07:17
*** frieder <frieder!> has joined #yocto07:21
*** mvlad <mvlad!~mvlad@2a02:2f08:4114:c500:24d7:51ff:fed6:906d> has joined #yocto07:27
cb5rWhat can be the cause of a bitbake task "hanging"? DEBUG shows loads of "Marking task ... as buildable" and after about 2 mins it just stops. - Then the running tasks (all qt* do_prepare_recipe_sysroot / do_compile) keep on running forever @ no CPU load. RAM is empty (just rebooted the machine) and available storage is more than enough 😕07:27
*** lucaceresoli <lucaceresoli!~lucaceres@> has joined #yocto07:31
*** mckoan|away is now known as mckoan07:35
mckoangood morning07:35
*** goliath <goliath!~goliath@user/goliath> has joined #yocto07:54
*** tre <tre!> has joined #yocto07:57
*** florian <florian!> has joined #yocto08:17
*** florian_kc <florian_kc!> has joined #yocto08:20
*** florian <florian!> has quit IRC (Ping timeout: 256 seconds)08:24
*** Schlumpf <Schlumpf!~Schlumpf@> has joined #yocto08:25
*** tnovotny <tnovotny!> has joined #yocto08:27
*** jclsn <jclsn!> has joined #yocto08:35
jclsnGuys, this is nuts08:38
jclsnI completely reinstalled my laptop with a new Ubuntu. When I build on another machine with the same tools, shell etc. I can boot the kernel. When I build on this laptop, it kernel-panics...08:39
jclsnI already tested the memory08:39
jclsnI will just build with the other machine now so I can work, but this is weird af08:40
LetoThe2ndyo dudX08:46
*** dev1990 <dev1990!> has joined #yocto08:48
*** kroon <kroon!> has joined #yocto08:49
*** leon-anavi <leon-anavi!~Leon@> has joined #yocto08:50
*** jmlemetayer[m] <jmlemetayer[m]!~jmlemetay@2001:470:69fc:105::1:830> has quit IRC (Quit: You have been kicked for being idle)09:00
*** Schiller <Schiller!> has joined #yocto09:08
rburtonjclsn: your machine is clearly haunted09:14
SchillerHow do i implement the runqemu-gen-tapdevs correctly in my YPAutobuilder environment to bypass the root permissions. What i want is that on controller start that script gets run so the given User has privileges.09:21
kayterina[m]Hello. I get error "omitting directory" from do_install(). Is it because I try to install -m a folder structure? It is a .tar.gz that I want to copy over to the target, I untar it in do_compile().09:47
hmw[m]is there a build container for dunfell ?09:47
LetoThe2ndkayterina[m]: the canonical way is using cp:
LetoThe2ndhmw[m]: depends on what you call "build container". there is crops, there is pyrex, there is kas - all are container solutions that can build a dunfell release. there is my personal one at theyoctojester/devcontainer-local-yoep, but it might need tuning for you. so what do you need in particular?09:49
LetoThe2ndis there anything out in the wild for generating encrypted rootfs? or is it all internal-homebrew stuff at the moment?09:56
*** pasherring <pasherring!~pasherrin@2001:8a0:ec55:b200:5503:ae3e:b9f0:5eaa> has joined #yocto10:01
qschulzhmw[m]: CROPS, kas and pyrex (and probably others) have containers to build Yocto10:03
*** lucaceresoli <lucaceresoli!~lucaceres@> has quit IRC (Remote host closed the connection)10:05
*** lucaceresoli_ <lucaceresoli_!~lucaceres@> has joined #yocto10:05
SchlumpfHi, does anyone know any examples how to use swupdate with single-copy approach with grub bootloader?10:10
*** Schiller <Schiller!> has quit IRC (Quit: Client closed)10:12
*** Schiller <Schiller!> has joined #yocto10:22
Schillerin the YPAutouilder it is necessary to have a User with root privileges. What is the recommended way for this task? Simply changing the UID in /etc/passwd to 0 would make my User root.10:33
rburtonwhy do you need a root user?10:46
RPSchiller: you definitely do not need a root user10:48
Schillerit is stated here
Schillerand without i can't access /home/pokybuild3/git/... in step (Clobber build dir)10:49
RPSchiller: that guide says you setup the pokybuild user from the root user, it doesn't say pokybuild has to be root10:50
RPSchiller: /home/pokybuild3/git should be owned by pokybuild so that should be ok10:51
Schillerok ill readd the user as root and will check again.10:51
*** starblue <starblue!> has quit IRC (Ping timeout: 245 seconds)10:54
*** leon-anavi <leon-anavi!~Leon@> has quit IRC (Remote host closed the connection)10:55
*** leon-anavi <leon-anavi!~Leon@> has joined #yocto10:56
*** starblue <starblue!> has joined #yocto10:56
*** Dracos-Carazza <Dracos-Carazza!~Dracos-Ca@> has quit IRC (Remote host closed the connection)10:57
*** Dracos-Carazza <Dracos-Carazza!~Dracos-Ca@> has joined #yocto10:57
*** frieder <frieder!> has quit IRC (Ping timeout: 252 seconds)10:59
NishanthMenon[m]hmw[m]: check out crops/yocto11:01
hmw[m]Tnx qschulz  and LetoThe2nd11:01
*** selff <selff!~selff@> has joined #yocto11:05
*** prabhakarlad <prabhakarlad!> has joined #yocto11:05
RPndec, qschulz, michaelo: docs changes are live and published. Hopefully this is a positive move overall! :)11:05
RPqschulz: I put the patch to remove some releases out for discussion11:06
ndecRP: that's great. it was long time overdue.. better move and fix than not to move ;)11:06
qschulzRP: :muscle:11:07
RPthere is a stray 4.0.999 in the main menu :/11:07
selffhello everyone, im running an image with openvpn in rpi4. i enabled "AUTO_SYSTEM_ENABLE" in "". i also put the existing client_vpn_test.conf file in /etc/openvpn. however, the service cannot run the config. when "openvpn@client.service" is run, it prints the following error: job for openvpn@client.service failed because the control11:10
selffprocess exited with error code.11:10
selffSee "systemctl status openvpn@client.service" and "journalctl -xe" for details.11:10
selffbut when I run it manually the vpn works.11:10
selff"openvpn --config /etc/openvpn/client_vpn_test_conf" works  manually11:11
*** frieder <frieder!> has joined #yocto11:11
*** florian_kc is now known as florian11:12
ndecRP: only when you look at the 'dev' (4.0) version.. if you pick another one, the 4.0.999 is gone!11:13
RPndec: right I think it is because dev (4.0) *is* 4.0.99911:14
RPndec: I think a " and ourbranch != devbranch" addition to the config should solve that11:16
RPI've pushed something to hopefully sort that11:18
qschulzRP: why do we add ourseries to activereleaes line 202?11:23
qschulzRP: also I think we shouldn't have kirkstone in release_series since it's not out yet11:24
qschulzsame for lts_releases11:24
qschulzor bitbake_mapping11:25
SchillerRP:I did setup the hole thing again as root (added user cloned repos etc.). As what User should i start the Autobuilder manually. Either way (pokybuild3 or root) i'll run in some path or permission problems.11:40
rburtonyou only need root to create the new user11:42
rburtoneverything else should be done as pokybuild11:42
rburtonwell, the static tap nodes creation is a root task, but that should be done at boot.11:42
Schillerwhen i run want to start the janitor as pokybuild3 i already run into permission issues11:43
Schillerand when i sudo the janitor command i will run into permission issues during buildtime in step 1. (Clobber build dir)11:44
rburtonhard to help with just 'permission problems'11:44
rburtoneverything should be happening as pokybuild11:44
rburtonthat user owns the home directory, the build trees, and the source trees11:45
selffCan anyone help with openvpn?11:47
Schillerso to clarify i should be able to run the janitor as pokybuild3 without any root privileges after a correct setup.11:48
Schilleri changed some paths in the ab-janitor file and now i manage to start a build.12:13
Schillerin step 9 (Check run-config steps to use) i get the generated json file but no tasks other tasks are run. It just stops without creating a build. Any suggestions?12:14
RPSchiller: correct, janitor should be fine as pokybuild312:15
RPSchiller: I don't understand that since it should extend the steps needed as defined in the json file :(12:16
RPSchiller: I wonder if something changed in a more recent buildbot version? You could compare the version you're using for the controller with what we use on the autobuilder?12:16
RPqschulz: we add it there so that the current release series is displayed in the switcher ?12:17
RPqschulz: kirkstone needs to be in release_series since devbranch is set to kirkstone and we need to be able to resolve that12:18
RPqschulz: setting devbranch to honister would just mean there is no "dev" entry in switchers which would be worse12:19
*** Schiller54 <Schiller54!> has joined #yocto12:20
*** Schiller <Schiller!> has quit IRC (Ping timeout: 256 seconds)12:20
Schiller54could it be any path setting or smth? It temporary creates a folder in my yocto-worker/beaglebone/build12:21
Schiller54and then it just stops even removing the beaglebone-folder in the yoctoworkers directory.12:22
Schiller54maybe i am missing some necessary software or my OS is not configured for this since i run linux mint. Any hints?12:24
RPSchiller54: I've given you the hints I have, I just don't understand why it would behave differently there for you :(12:25
Schiller54ok Thanks. I'll try the hole procedure inside Docker under another OS. Maybe then it'll work.12:26
RPSchiller54: did you compare the versions?12:27
Schiller54What do u refer to?12:28
RPSchiller54: where I said "Schiller: I wonder if something changed in a more recent buildbot version? You could compare the version you're using for the controller with what we use on the autobuilder?"12:29
Schiller54i dont quite understand. I got the build-essentials from if u mean that.12:32
RPSchiller54: in your autobuilder UI, click on "About" on the menu on the left and let me know the version of buildbot?12:33
Schiller54Buildbot versionBuildbot version: 3.3.0:12:34
RPSchiller54: I wonder what happens if you use an older buildbot version?12:39
RPSchiller54: I worry something changed in a newer buildbot which broke that code somehow12:39
Schiller54which one should i use?12:39
RPSchiller54: 2.8.1 to match more closely to
Schiller54ok ill try thanks.12:40
RPobviously we should upgrade but that sounds like it could be "fun" and takes time12:41
*** rob_w <rob_w!> has quit IRC (Remote host closed the connection)12:57
*** selff <selff!~selff@> has quit IRC (Quit: Client closed)13:03
*** jmiehe <jmiehe!~Thunderbi@user/jmiehe> has joined #yocto13:03
jclsnI want to mirror all layers to our Gitlab13:05
jclsnShould I mirror the tags also?13:05
jclsnI would think that mirroring the branches would be sufficient13:05
*** Schiller54 <Schiller54!> has quit IRC (Quit: Client closed)13:08
*** pgowda_ <pgowda_!> has joined #yocto13:28
*** MrSaturn <MrSaturn!> has joined #yocto13:32
MrSaturnHi All. This is a really stupid question: What is the correct way to modify a u-boot configuration in Yocto? I have tried using "devtool modify ..." but that just creates a source directory, without the existing configuration. "devtool menuconfig u-boot" shows that do_menuconfig is not supported.  I am looking to create a patch for the defconfig.13:34
RPjclsn: probably fine but does depend whether you have anything using the tags. You probably don't but we wouldnt know13:37
jclsn[m]RP: I don’t13:38
*** sakoman <sakoman!> has joined #yocto13:53
*** xmn <xmn!> has joined #yocto14:00
*** tnovotny <tnovotny!> has quit IRC (Ping timeout: 256 seconds)14:01
MrSaturnhrmm.. even in the source directory that devtool creates. If I "make <machine>_defconfig" then "make menuconfig" ... changes ... "make savedefconfig" then "git status" it shows no changes.14:01
RP"WARNING: You are using an sstate mirror but a local hash equivalence server. This will likely mean no sstate will match from the mirror." - is that message clear enough?14:02
RPCan anyone think of a case that isn't valid?14:02
*** tnovotny <tnovotny!> has joined #yocto14:04
qschulzRP: my non-native speaker brain didn't understand on the first read14:04
qschulzYou are using a local hash equivalence server with an sstate mirror.14:04
qschulzis something I could suggest14:05
qschulzThe warning message is a nice addition, but what should the user do in that case?14:05
qschulzThis is something missing from the message I think14:05
qschulzPointing to the documentation or variables to play with is already a good start14:06
RPqschulz: "WARNING: You are using a local hash equivalence server but have configured an sstate mirror. This will likely mean no sstate will match from the mirror. You may wish to disable the hash equivalence use (BB_HASHSERVE), or use a hash equivalence server alongside the sstate mirror."14:08
RPqschulz: Longer but slightly more complete14:08
qschulzRP: looks good to me :)14:15
*** kroon <kroon!> has quit IRC (Quit: Leaving)14:24
RPqschulz: thanks for the tweaks, I've sent it out for review. Hopefully it will save people from scratching heads on sstate reuse14:53
*** vmeson <vmeson!> has quit IRC (Quit: Konversation terminated!)14:54
*** fitzsim <fitzsim!> has quit IRC (Ping timeout: 240 seconds)14:55
*** vmeson <vmeson!> has joined #yocto14:57
qschulzRP: I hope too, this is something I was confused about when I was building vanilla poky14:57
*** florian <florian!> has quit IRC (Read error: Connection reset by peer)14:57
*** florian <florian!> has joined #yocto14:58
*** fitzsim <fitzsim!> has joined #yocto15:09
dacavI'd like to verify some properties of the kernel that yocto builds, e.g. if a certain .c file is compiled or not.  In order to do so, I'm trying to put some garbage in the file, and I would expect bitbake to fail.  It does not fail...15:10
dacavThe modification is done in the kernel-source directory that yocto checks out15:11
qschulzdacav: how do you build?15:11
dacavIn this directory I can see, for example, that yocto applied the patches in the do_patch phase.15:11
dacavqschulz: I build via something like `bitbake my-linux`15:11
dacav(In short, the kernel seems to lack certain symbols, that should be there according to the defconfig)15:12
qschulzdacav: bitbake has no knowledge of modification in the sources15:12
qschulzdacav: use devtool modify my-linux if you want15:12
dacavI'm not modifying the recipe.  I'd like to change the sources in flight, without pushing a commit to a branch15:13
dacavBasically I'd like to mess around without spending time to a proper patch15:13
qschulzdacav: that's exactly what i mean, you're modifying the sources and not the recipe, which is not watched by bitbake15:14
qschulzdacav: use devtool modify15:14
dacavWhen you say it has no knowledge of the modification in the sources, do you mean that it will not re-build it because it does not detect a change on the remote git repo, so it assumes no change has been done, so it will not invalidate the cached binary?15:14
dacavSo is `devtool modify` going to put me in the sources?15:15
* dacav tries15:15
qschulzit's going to fetch+patch the sources in a specific workspace15:15
qschulzwhere you'll be able to modify stuff15:15
qschulzand then use bitbake like you would normally do15:15
dacavOK! Sounds good15:15
dacavthank you qschulz, precious as always15:15
qschulzbitbake has some mechanism to watch over devtool workspaces changes (see externalsrc.bbclass specifically if I'm not mistaken)15:16
dacavOK.  So now I have the kernel sources in two places, I believe15:23
dacavwill yocto only rely on the one in workspace/sources/?15:24
*** Tokamak_ <Tokamak_!~Tokamak@> has quit IRC (Ping timeout: 240 seconds)15:28
*** florian <florian!> has quit IRC (Read error: Connection reset by peer)15:29
*** florian <florian!> has joined #yocto15:29
*** Tokamak <Tokamak!~Tokamak@> has joined #yocto15:29
*** camus <camus!~Instantbi@> has quit IRC (Ping timeout: 268 seconds)15:29
*** pgowda_ <pgowda_!> has quit IRC (Quit: Connection closed for inactivity)15:34
rfs613dacav: yes. If you look at conf/bblayers.conf you will see that devtool has added the workspace/sources as a layer. (This caught me by surprise when I remove the workspace and bitbake started complaining...)15:35
moto-timodevtool creates a bbappend that points to workspace/sources until you “devtool finish” or “devtool reset” as I recall15:39
moto-timoYou can also edit conf/bblayers.conf to remove the workspace… I do this when I want to absolutely certain15:40
*** Tokamak <Tokamak!~Tokamak@> has quit IRC (Ping timeout: 240 seconds)15:57
LetoThe2ndmoto-timo: there is no certainty in life!15:58
*** Tokamak <Tokamak!~Tokamak@> has joined #yocto16:00
*** paulg <paulg!> has quit IRC (Remote host closed the connection)16:01
*** paulg <paulg!> has joined #yocto16:05
MrSaturnAlright, I may have come up with something... after running "savedefconfig" I copy it to the old _defconfig, git add, git commit, then run "devtool finish". The only issue remaining is that I have 4 other patches in the layer, and it sets the number of the latest patch as 000116:07
qschulzMrSaturn: the name of the patch does not matter to bitbake16:09
qschulzit's the order in SRC_URI which provides the order in whcih the patches are applied16:10
khemLetoThe2nd: Heisenberg's principle 🙂16:11
MrSaturnqschulz: Ok, thanks. I will probably rename it because I am a bit OCD like that.16:11
*** jmiehe <jmiehe!~Thunderbi@user/jmiehe> has quit IRC (Quit: jmiehe)16:12
qschulzMrSaturn: I feel you :)16:13
LetoThe2ndkhem: a famous German comedian said: "the three questions about life: where do i come from? where to i go? where do i get the next beer?"16:18
khemonly last question matters though16:18
khemothers are higher order functions16:19
LetoThe2ndkhem: yes, and sometimes, at least there is certainty (question 3)16:19
* khem has been doing some elm lately 16:19
LetoThe2ndkhem: as in, switching mail clients? ;-)16:20
khemno as in programming languages, its a functional programming language16:20
khemhence the higher order functions16:20
LetoThe2ndkhem: yeah, just pulling your leg. i've done a lot of JS, and it is really quite handy/strong there.16:21
*** tre <tre!> has quit IRC (Remote host closed the connection)16:51
*** tnovotny <tnovotny!> has quit IRC (Quit: Leaving)16:55
*** Schlumpf <Schlumpf!~Schlumpf@> has quit IRC (Quit: Client closed)16:57
*** davidinux <davidinux!~davidinux@> has quit IRC (Ping timeout: 240 seconds)17:05
*** davidinux <davidinux!~davidinux@> has joined #yocto17:07
*** Minvera <Minvera!~Minvera@user/Minvera> has joined #yocto17:18
*** mckoan is now known as mckoan|away17:44
*** vmeson <vmeson!> has quit IRC (Ping timeout: 260 seconds)17:48
*** vmeson <vmeson!> has joined #yocto17:53
*** Mike123 <Mike123!> has joined #yocto18:14
*** Mike123 <Mike123!> has quit IRC (Quit: Client closed)18:20
*** Mike23 <Mike23!> has joined #yocto18:21
*** Mike23 <Mike23!> has quit IRC (Client Quit)18:21
*** Mike23 <Mike23!> has joined #yocto18:21
*** pasherring <pasherring!~pasherrin@2001:8a0:ec55:b200:5503:ae3e:b9f0:5eaa> has quit IRC (Quit: Leaving)18:22
*** lucaceresoli_ <lucaceresoli_!~lucaceres@> has quit IRC (Ping timeout: 260 seconds)18:30
dacavrfs613: thanks.  I wonder on what basis it will take the precedence... maybe (?) by the fact that the layer is listed in the last position?  I'll experiment some later :)18:31
rfs613dacav: layers have priorities, try "bitbake-layers show-layers" and note the number at the far right of each line.18:33
*** Mike23 <Mike23!> has quit IRC (Quit: Client closed)18:45
*** GNUmoon <GNUmoon!~GNUmoon@gateway/tor-sasl/gnumoon> has quit IRC (Remote host closed the connection)18:53
*** GNUmoon <GNUmoon!~GNUmoon@gateway/tor-sasl/gnumoon> has joined #yocto18:53
*** florian <florian!> has quit IRC (Ping timeout: 256 seconds)18:55
*** frieder <frieder!> has quit IRC (Remote host closed the connection)18:55
*** Mike23 <Mike23!> has joined #yocto18:55
*** GNUmoon <GNUmoon!~GNUmoon@gateway/tor-sasl/gnumoon> has quit IRC (Ping timeout: 240 seconds)19:04
*** florian <florian!> has joined #yocto19:07
*** GNUmoon <GNUmoon!~GNUmoon@gateway/tor-sasl/gnumoon> has joined #yocto19:08
jonmasonzeddii: you around?19:10
*** Mike23 <Mike23!> has quit IRC (Quit: Client closed)19:16
*** sakoman <sakoman!> has quit IRC (Quit: Leaving.)19:17
*** florian <florian!> has quit IRC (Ping timeout: 240 seconds)19:20
jonmasonzeddii: disregard19:39
RPjonmason: did we ever get anywhere with those arm tiny patches?19:48
*** amitk <amitk!~amit@> has quit IRC (Ping timeout: 240 seconds)20:02
jonmasonRP: it's on my todo list to bottom out on what got pulled in for the yocto-kernel-cache, then revise them20:06
jonmasonI did a rebuild yesterday to start, then got told/reminded I'm on swat this week :)20:06
jonmasonI'll do my best to get something out tomorrow20:07
*** florian <florian!> has joined #yocto20:15
RPjonmason: fair enough, just thought about it the other day20:22
jonmasonthere is other stuff with hvc0 that needs to be figured out, but I can drop those patches20:24
jonmasonessentially, without those being present, poky-tiny sprays errors on stdout forever as fast as it can20:25
jonmasonerr..with hvc0 being in the machine conf file, but not being present20:25
RPjonmason: I couldn't remember where we were at with them to be honest20:25
jonmasonthey worked, khem said there was unnecessary stuff in there, and I needed to pull it out.  since I was waiting on the kernel configs to get it, I sat on it.  But I did an update the other day and seems like they are in there now20:27
RPjonmason: ah, yes,  think I had to pull the patches as the kernel bits weren't there yet20:27
*** Mike23 <Mike23!> has joined #yocto20:30
*** Mike23 <Mike23!> has quit IRC (Client Quit)20:35
MrSaturnHuh. I am looking at some freescale kernel recipes. It looks like it copies the defconfig into ${B}/.config and other layers just dump config fragments to the end of the config. Is this a normal pattern? It makes maintining patches to the config file painful.20:44
abelloniRP: jonmason thinks is a bitbake server timeout, this was going to also be my first thought but I don't remember how we triaged the previous time we have seen that20:48
*** prabhakarlad <prabhakarlad!> has quit IRC (Quit: Client closed)20:48
RPabelloni: hmm. Do we still have the logs?20:48
abelloniit was yesterday, so possibly20:49
jonmasonit did seem to match what was in there for the others20:49
RPit doesn't look like the usual server timeout tome20:50
abelloniI have to grabe something to eat, can you check?20:51
abelloni(hte logs)20:51
RPabelloni: the logs are there I think20:51
dacavrfs613: thanks20:51
RPnothing useful :/20:51
jonmasonRP: any idea why systemtap tests would fail in master-next?  I see nothing in the queued patches that is related, and I don't see any open bugs about it being a known issue20:56
RPjonmason: was that the centos7 one?21:00
RPjonmason: I didn't get a conclusive answer but I think the copying times were very high, around 290s in a 300s timeout21:00
RPso I thought it was IO load related21:01
*** Minvera <Minvera!~Minvera@user/Minvera> has quit IRC (Remote host closed the connection)21:01
smurrayMrSaturn: I believe all the kernel recipes in meta-freescale are based on kernel-yocto.bbclass, so .cfg fragments should work with those21:01
jonmasonRP: should I open a bug to track it or just mark it down to hw?21:02
RPjonmason: best ask abelloni what to do with that, whether there is an existing one21:02
jonmasonabelloni: is the offender21:03
RPabelloni, jonmason: I did dig a little into that timeout in the buildbot UI and it is odd. The bitbake-cookerdaemonlog says the build ran for 10 mins and the server exited21:03
RPWe can get the timestamps of the step from
MrSaturnsmurray: do you have any advice for working with fragments like that? I am used to using devtool + patches. It seems like there must be a workflow I am unfamiliar with here.21:04
RPwhich match the start time in the log, translating the epoch value21:04
smurrayMrSaturn: take a look at
MrSaturnsmurray: thanks!21:05
*** GNUmoon <GNUmoon!~GNUmoon@gateway/tor-sasl/gnumoon> has quit IRC (Ping timeout: 240 seconds)21:15
*** florian <florian!> has quit IRC (Ping timeout: 260 seconds)21:18
*** steev_ <steev_!> has joined #yocto21:25
steev_hi, i am trying to setup a yocto build environment at my workplace. one thing we are struggling with is how to version our application recipes during the development cycle. could someone please point me to some common techniques which don't have us point our do git HEAD? we would like for each meta-foo commit to represent a known snapshot of application commits at that point21:27
jsbrondersteev_: This still ends up pointing something at HEAD, but it might be helpful:21:30
jsbronderWe have a virtual/app with two recipes that (R)PROVIDE it, and
jsbronderFor nightlies, we build the recipes, which point at HEAD, for releases we build the recipes which point at an annotated tag.21:31
jsbronderThe recipes also dump some `git describe` output in /etc so we can trace back.21:32
jsbronderThere's also externalsrc ( but I came up with the above before I knew about its existence.21:33
*** florian <florian!> has joined #yocto21:37
steev_jsbronder: thanks. so if you ever wanted to reproduce a build from last Wednesday, how would you do it?21:40
JaMamoto-timo: I no longer work on meta-ros, not sure if OSRF already moved the maintenance to someone else21:40
moto-timoJaMa: ok. I didn't know that. Thank you for the heads up.21:40
moto-timoFWIW I got galactic building on kirkstone... no idea how useful/functional it is21:41
jsbrondersteev_: With mild effort; you have the shas in /etc.  Each recipe has something like:21:42
jsbronderAPP_URI ?= "uri pointing to tip of master>"21:43
jsbronderSRC_URI = "${APP_URI}"21:43
jsbronderSo, you can override APP_URI to point to whatever sha.21:43
JaMamoto-timo: it was working fine on oe master as of 2021-12-06 when I did the last update, at least the LAYERSERIES_COMPAT needs to be changed after that, but I haven't built anything with meta-ros in 202221:44
jsbronderThat said, we archive the artifacts from each nightly for quite a while, so in reality I'd just go back and pull those.21:44
moto-timoJaMa: understood. I won't pester you about it anymore ;)21:44
moto-timoa few minor warnings about licensing changes and so on... plus a couple distutils3 changes... but anyway. I'll try to follow the community21:45
JaMamoto-timo: you can pester Rob Woolley of WindRiver or someone from Xilinx who was also interested in maintaining meta-ros ..21:45
*** florian <florian!> has quit IRC (Ping timeout: 260 seconds)21:45
*** mvlad <mvlad!~mvlad@2a02:2f08:4114:c500:24d7:51ff:fed6:906d> has quit IRC (Remote host closed the connection)21:45
moto-timoJaMa: good to know. There was also interest within Intel, but it never went anywhere with my direct team. And I have no visibility anymore ;)21:46
*** Guma <Guma!~Guma@> has joined #yocto21:47
*** florian <florian!> has joined #yocto21:48
JaMamoto-timo: first fileserver which I was using for meta-ros sstate died, then LGE left OSRF TSC and then I've left LGE, so me still having any permissions on meta-ros repo on github is just administrative delay :)21:49
moto-timoJaMa: well, I hope you are moving on to better things! 🍻 🏎️21:50
jsbrondersteev_: Honestly, if you care about reproducibility, you should be pulling from tags.21:50
*** rfs613 <rfs613!> has quit IRC (Quit: restart)21:54
*** rfs613 <rfs613!> has joined #yocto21:55
steev_jsbronder: i understand, thanks21:55
GumaHello Everyone. I am testing my first Yocto build on my board. After booting, I added the account manually for now. Later I can focus on integrating it into Yocto the build. The issue I am puzzled by is that when I log in to this account "adb shell" or "ssh" simple error "socket: Permission denied when I try to ping any server. Do I have to add a new user to some group? I can ping just fine as root.22:00
*** sakoman <sakoman!> has joined #yocto22:05
abellonijonmason: this is 1448622:06
jonmasonabelloni: thanks22:13
RPjonmason, abelloni: I don't think is  1420122:15
abelloniRP: I guess we should create a new bug then22:16
jonmasonNo problem.   I'll open one when I get home tonight.22:18
*** GNUmoon <GNUmoon!~GNUmoon@gateway/tor-sasl/gnumoon> has joined #yocto22:18
RPjonmason, abelloni: I'll just go ahead since I have the context and links handy22:21
RPjonmason, abelloni:
*** GNUmoon <GNUmoon!~GNUmoon@gateway/tor-sasl/gnumoon> has quit IRC (Remote host closed the connection)22:28
*** Tokamak <Tokamak!~Tokamak@> has quit IRC (Ping timeout: 240 seconds)22:35
*** GNUmoon <GNUmoon!~GNUmoon@gateway/tor-sasl/gnumoon> has joined #yocto22:39
*** Tokamak <Tokamak!~Tokamak@> has joined #yocto22:39
*** florian <florian!> has quit IRC (Ping timeout: 260 seconds)22:43
*** Guma <Guma!~Guma@> has quit IRC (Quit: Good Night Everyone...)22:51
*** leon-anavi <leon-anavi!~Leon@> has quit IRC (Quit: Leaving)23:38
*** geoffhp <geoffhp!> has quit IRC (Remote host closed the connection)23:52

Generated by 2.17.2 by Marius Gedminas - find it at!