<AustrianCurrent>
moto-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 packages
<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't
<AustrianCurrent>
want to have to touch bitbake file every time I update an application or library.
leon-anavi has quit [Quit: Leaving]
<AustrianCurrent>
moto-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 packages
<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't
<AustrianCurrent>
want 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.
<AustrianCurrent>
moto-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 packages
<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't
<AustrianCurrent>
want 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.
AustrianCurrent4 has joined #yocto
AustrianCurrent has quit [Quit: Client closed]
<AustrianCurrent4>
Also new to IRC chats, I apologize :(
<moto-timo>
AustrianCurrent: bitbake builds intermediate packages (ipk, deb, rpm) and uses those to stitch together the final image (in the case of rpm with dnf)
<moto-timo>
AustrianCurrent4: 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.
<AustrianCurrent4>
moto-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?
<AustrianCurrent4>
So 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?
<moto-timo>
AustrianCurrent4: 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.
<AustrianCurrent4>
moto-timo: Even if a nightly-built SDK is being used to build the RPMs via CPack?
<moto-timo>
AustrianCurrent4: 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.
<moto-timo>
AustrianCurrent4: 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.
<moto-timo>
AustrianCurrent4: the Yocto Way is to build everything from source. For a reason.
AustrianCurrent has joined #yocto
<AustrianCurrent>
moto-time: Interesting. So it's highly encouraged to use source builds. That's fair. I've seen layers like this https://github.com/conan-io/meta-conan that do similar things to what I'm trying to attempt but like you're saying it's a dark road
<moto-timo>
AustrianCurrent: 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.
<moto-timo>
AustrianCurrent: swtich to a new SoC or a new board? hosed.
<moto-timo>
AustrianCurrent: 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)
AustrianCurrent4 has quit [Ping timeout: 256 seconds]
<AustrianCurrent>
moto-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's
<moto-timo>
AustrianCurrent: 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.
<moto-timo>
AustrianCurrent: 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).
<moto-timo>
AustrianCurrent: 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.
* moto-timo
has strong opinions on certain things.
<AustrianCurrent>
Ah 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.
<moto-timo>
AustrianCurrent: 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 cases
<moto-timo>
AustrianCurrent: 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.
* moto-timo
on a bit of a high horse right now... so take this with a grain of salt
<AustrianCurrent>
Yeah just takes up some extra bandwidth I guess.
<moto-timo>
worklfow: edit library source, push commit, change SRCREV in bb, build, deploy to target
<moto-timo>
depending 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.
<moto-timo>
the extensible SDK was designed to allow a hybrid... you have an SDK but you also have _some_ of the bitbake tooling. Not perfect.
<AustrianCurrent>
Interesting
<moto-timo>
TBH, I spend _much_ less bandwidth on the metadata updates than I do on patching/upgrading components to newer versions or new functionality.
<AustrianCurrent>
I 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 creating
<AustrianCurrent>
a 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.
<AustrianCurrent>
I will look further into the devtool workflow though. I think this will solve a lot of my problems developing these recipes.
<moto-timo>
I look at layers as Lego(TM) building blocks... pick and choose what you need to make the CoolThing
<moto-timo>
in the long run, you are much better off re-using upstream anything that is well maintained than home grown... without question.
<moto-timo>
and the corollary is it is in your best interest to contribute to upstream
<moto-timo>
technical debt will be a noose around your neck that drags you to the poor house.
<moto-timo>
if 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_64
<AustrianCurrent>
Basically use proper install rules?
<AustrianCurrent>
for cmake I gues
<smurray>
AustrianCurrent: 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.
<moto-timo>
code like it is 1976... it will work. Code like a cool block chain bro and it will break.
<moto-timo>
smurray: rescues me from blathering on and on and on and on
* moto-timo
steps away
<AustrianCurrent>
Yep, 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 change
<smurray>
AustrianCurrent: 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 in
<AustrianCurrent>
So 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 smurray
<smurray>
AustrianCurrent: 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 parts
<AustrianCurrent>
smurray: Thanks, yeah that and potentially a SDK they can use to build their own layer on ours.
<smurray>
AustrianCurrent: yes, building a SDK that can build binaries to run on your target is also something you can do pretty easily
<moto-timo>
AustrianCurrent: you can also use an OTA solution like foundries.io, mender, updatehub, rauc, swupdate
* moto-timo
really steps away
<AustrianCurrent>
Thanks moto-timo and smurray. I will take this back to my team and try to persuade them off our possible road to doom
<smurray>
AustrianCurrent: good luck!
<AustrianCurrent>
Thanks!
AustrianCurrent has quit [Quit: Client closed]
ar__ has quit [Ping timeout: 268 seconds]
jclsn has quit [Ping timeout: 256 seconds]
jclsn has joined #yocto
qschulz has quit [Remote host closed the connection]
qschulz has joined #yocto
jclsn has quit [Ping timeout: 256 seconds]
jclsn has joined #yocto
Guest79 has quit [Ping timeout: 256 seconds]
jclsn has quit [Ping timeout: 252 seconds]
camus has joined #yocto
jclsn has joined #yocto
jclsn has quit [Ping timeout: 252 seconds]
sakoman has quit [Quit: Leaving.]
jclsn has joined #yocto
jclsn has quit [Ping timeout: 256 seconds]
jclsn has joined #yocto
jclsn has quit [Read error: Connection reset by peer]
jclsn has joined #yocto
sakoman has joined #yocto
rber|res has joined #yocto
RobertBerger has quit [Ping timeout: 256 seconds]
jclsn has quit [Quit: Ping timeout (120 seconds)]
jclsn has joined #yocto
jclsn has quit [Ping timeout: 240 seconds]
tcdiem has quit [Quit: Connection closed]
jclsn has joined #yocto
jclsn has quit [Ping timeout: 256 seconds]
jclsn has joined #yocto
jclsn has quit [Ping timeout: 256 seconds]
jclsn has joined #yocto
Starfoxxes has quit [Ping timeout: 268 seconds]
Starfoxxes has joined #yocto
amitk has joined #yocto
jclsn has quit [Ping timeout: 252 seconds]
jclsn has joined #yocto
jclsn has quit [Ping timeout: 268 seconds]
sakoman has quit [Quit: Leaving.]
camus has quit [Ping timeout: 240 seconds]
camus has joined #yocto
prabhakarlad has quit [Ping timeout: 256 seconds]
rber|res has quit [Ping timeout: 250 seconds]
RobertBerger has joined #yocto
alessioigor has joined #yocto
geoffhp has quit [Ping timeout: 252 seconds]
geoffhp has joined #yocto
alessioigor has quit [Client Quit]
geoffhp has quit [Read error: Connection reset by peer]
geoffhp has joined #yocto
tlwoerner has quit [Remote host closed the connection]
tlwoerner has joined #yocto
camus has quit [Ping timeout: 240 seconds]
camus has joined #yocto
rob_w has joined #yocto
frieder has joined #yocto
mvlad has joined #yocto
<cb5r>
What 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 😕
lucaceresoli has joined #yocto
mckoan|away is now known as mckoan
<mckoan>
good morning
goliath has joined #yocto
tre has joined #yocto
florian has joined #yocto
florian_kc has joined #yocto
florian has quit [Ping timeout: 256 seconds]
Schlumpf has joined #yocto
tnovotny has joined #yocto
jclsn has joined #yocto
<jclsn>
Guys, this is nuts
<jclsn>
I 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...
<jclsn>
I already tested the memory
<jclsn>
I will just build with the other machine now so I can work, but this is weird af
<LetoThe2nd>
yo dudX
dev1990 has joined #yocto
<qschulz>
o/
kroon has joined #yocto
leon-anavi has joined #yocto
<LetoThe2nd>
\o
jmlemetayer[m] has quit [Quit: You have been kicked for being idle]
Schiller has joined #yocto
<rburton>
jclsn: your machine is clearly haunted
<Schiller>
How 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.
<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().
<LetoThe2nd>
hmw[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?
<LetoThe2nd>
is there anything out in the wild for generating encrypted rootfs? or is it all internal-homebrew stuff at the moment?
pasherring has joined #yocto
<qschulz>
hmw[m]: CROPS, kas and pyrex (and probably others) have containers to build Yocto
lucaceresoli has quit [Remote host closed the connection]
lucaceresoli_ has joined #yocto
<Schlumpf>
Hi, does anyone know any examples how to use swupdate with single-copy approach with grub bootloader?
Schiller has quit [Quit: Client closed]
Schiller has joined #yocto
<Schiller>
in 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.
<rburton>
why do you need a root user?
<RP>
Schiller: you definitely do not need a root user
<Schiller>
and without i can't access /home/pokybuild3/git/... in step (Clobber build dir)
<RP>
Schiller: that guide says you setup the pokybuild user from the root user, it doesn't say pokybuild has to be root
<RP>
Schiller: /home/pokybuild3/git should be owned by pokybuild so that should be ok
<Schiller>
ok ill readd the user as root and will check again.
starblue has quit [Ping timeout: 245 seconds]
leon-anavi has quit [Remote host closed the connection]
leon-anavi has joined #yocto
starblue has joined #yocto
Dracos-Carazza has quit [Remote host closed the connection]
Dracos-Carazza has joined #yocto
frieder has quit [Ping timeout: 252 seconds]
<NishanthMenon[m]>
hmw[m]: check out crops/yocto
<hmw[m]>
Tnx qschulz and LetoThe2nd
selff has joined #yocto
prabhakarlad has joined #yocto
<RP>
ndec, qschulz, michaelo: docs changes are live and published. Hopefully this is a positive move overall! :)
<RP>
qschulz: I put the patch to remove some releases out for discussion
<ndec>
RP: that's great. it was long time overdue.. better move and fix than not to move ;)
<qschulz>
RP: :muscle:
<RP>
there is a stray 4.0.999 in the main menu :/
<selff>
hello everyone, im running an image with openvpn in rpi4. i enabled "AUTO_SYSTEM_ENABLE" in "openvpn_2.4.9.bb". 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 control
<selff>
process exited with error code.
<selff>
See "systemctl status openvpn@client.service" and "journalctl -xe" for details.
<selff>
but when I run it manually the vpn works.
<selff>
"openvpn --config /etc/openvpn/client_vpn_test_conf" works manually
frieder has joined #yocto
florian_kc is now known as florian
<ndec>
RP: only when you look at the 'dev' (4.0) version.. if you pick another one, the 4.0.999 is gone!
<RP>
ndec: right I think it is because dev (4.0) *is* 4.0.999
<RP>
ndec: I think a " and ourbranch != devbranch" addition to the config should solve that
<RP>
I've pushed something to hopefully sort that
<qschulz>
RP: why do we add ourseries to activereleaes line 202?
<qschulz>
RP: also I think we shouldn't have kirkstone in release_series since it's not out yet
<qschulz>
same for lts_releases
<qschulz>
or bitbake_mapping
<Schiller>
RP: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.
<rburton>
you only need root to create the new user
<rburton>
everything else should be done as pokybuild
<rburton>
well, the static tap nodes creation is a root task, but that should be done at boot.
<Schiller>
when i run want to start the janitor as pokybuild3 i already run into permission issues
<Schiller>
and when i sudo the janitor command i will run into permission issues during buildtime in step 1. (Clobber build dir)
<rburton>
hard to help with just 'permission problems'
<rburton>
everything should be happening as pokybuild
<rburton>
that user owns the home directory, the build trees, and the source trees
<selff>
Can anyone help with openvpn?
<Schiller>
so to clarify i should be able to run the janitor as pokybuild3 without any root privileges after a correct setup.
<Schiller>
i changed some paths in the ab-janitor file and now i manage to start a build.
<Schiller>
in 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?
<RP>
Schiller: correct, janitor should be fine as pokybuild3
<RP>
Schiller: I don't understand that since it should extend the steps needed as defined in the json file :(
<RP>
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?
<RP>
qschulz: we add it there so that the current release series is displayed in the switcher ?
<RP>
qschulz: kirkstone needs to be in release_series since devbranch is set to kirkstone and we need to be able to resolve that
<RP>
qschulz: setting devbranch to honister would just mean there is no "dev" entry in switchers which would be worse
Schiller54 has joined #yocto
Schiller has quit [Ping timeout: 256 seconds]
<Schiller54>
could it be any path setting or smth? It temporary creates a folder in my yocto-worker/beaglebone/build
<Schiller54>
and then it just stops even removing the beaglebone-folder in the yoctoworkers directory.
<Schiller54>
maybe i am missing some necessary software or my OS is not configured for this since i run linux mint. Any hints?
<RP>
Schiller54: I've given you the hints I have, I just don't understand why it would behave differently there for you :(
<Schiller54>
ok Thanks. I'll try the hole procedure inside Docker under another OS. Maybe then it'll work.
<RP>
Schiller54: did you compare the versions?
<Schiller54>
What do u refer to?
<RP>
Schiller54: 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?"
<RP>
obviously we should upgrade but that sounds like it could be "fun" and takes time
rob_w has quit [Remote host closed the connection]
selff has quit [Quit: Client closed]
jmiehe has joined #yocto
<jclsn>
I want to mirror all layers to our Gitlab
<jclsn>
Should I mirror the tags also?
<jclsn>
I would think that mirroring the branches would be sufficient
Schiller54 has quit [Quit: Client closed]
pgowda_ has joined #yocto
MrSaturn has joined #yocto
<MrSaturn>
Hi 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.
<RP>
jclsn: probably fine but does depend whether you have anything using the tags. You probably don't but we wouldnt know
<jclsn[m]>
RP: I don’t
sakoman has joined #yocto
xmn has joined #yocto
tnovotny has quit [Ping timeout: 256 seconds]
<MrSaturn>
hrmm.. 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.
<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?
<RP>
Can anyone think of a case that isn't valid?
tnovotny has joined #yocto
<qschulz>
RP: my non-native speaker brain didn't understand on the first read
<qschulz>
You are using a local hash equivalence server with an sstate mirror.
<qschulz>
is something I could suggest
<qschulz>
The warning message is a nice addition, but what should the user do in that case?
<qschulz>
This is something missing from the message I think
<qschulz>
Pointing to the documentation or variables to play with is already a good start
<RP>
qschulz: "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."
<RP>
qschulz: Longer but slightly more complete
<qschulz>
RP: looks good to me :)
kroon has quit [Quit: Leaving]
<RP>
qschulz: thanks for the tweaks, I've sent it out for review. Hopefully it will save people from scratching heads on sstate reuse
vmeson has quit [Quit: Konversation terminated!]
fitzsim has quit [Ping timeout: 240 seconds]
vmeson has joined #yocto
<qschulz>
RP: I hope too, this is something I was confused about when I was building vanilla poky
florian has quit [Read error: Connection reset by peer]
florian has joined #yocto
fitzsim has joined #yocto
<dacav>
hello.
<dacav>
I'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...
<dacav>
The modification is done in the kernel-source directory that yocto checks out
<qschulz>
dacav: how do you build?
<dacav>
In this directory I can see, for example, that yocto applied the patches in the do_patch phase.
<dacav>
qschulz: I build via something like `bitbake my-linux`
<dacav>
(In short, the kernel seems to lack certain symbols, that should be there according to the defconfig)
<qschulz>
dacav: bitbake has no knowledge of modification in the sources
<qschulz>
dacav: use devtool modify my-linux if you want
<dacav>
I'm not modifying the recipe. I'd like to change the sources in flight, without pushing a commit to a branch
<dacav>
Basically I'd like to mess around without spending time to a proper patch
<qschulz>
dacav: that's exactly what i mean, you're modifying the sources and not the recipe, which is not watched by bitbake
<qschulz>
dacav: use devtool modify
<dacav>
When 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?
<qschulz>
yup
<dacav>
aha!
<dacav>
So is `devtool modify` going to put me in the sources?
* dacav
tries
<qschulz>
it's going to fetch+patch the sources in a specific workspace
<qschulz>
where you'll be able to modify stuff
<qschulz>
and then use bitbake like you would normally do
<dacav>
OK! Sounds good
<dacav>
thank you qschulz, precious as always
<qschulz>
bitbake has some mechanism to watch over devtool workspaces changes (see externalsrc.bbclass specifically if I'm not mistaken)
<dacav>
OK. So now I have the kernel sources in two places, I believe
<dacav>
will yocto only rely on the one in workspace/sources/?
Tokamak_ has quit [Ping timeout: 240 seconds]
florian has quit [Read error: Connection reset by peer]
florian has joined #yocto
Tokamak has joined #yocto
camus has quit [Ping timeout: 268 seconds]
pgowda_ has quit [Quit: Connection closed for inactivity]
<rfs613>
dacav: 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...)
<moto-timo>
devtool creates a bbappend that points to workspace/sources until you “devtool finish” or “devtool reset” as I recall
<moto-timo>
You can also edit conf/bblayers.conf to remove the workspace… I do this when I want to absolutely certain
Tokamak has quit [Ping timeout: 240 seconds]
<LetoThe2nd>
moto-timo: there is no certainty in life!
Tokamak has joined #yocto
paulg has quit [Remote host closed the connection]
paulg has joined #yocto
<MrSaturn>
Alright, 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 0001
<qschulz>
MrSaturn: the name of the patch does not matter to bitbake
<qschulz>
it's the order in SRC_URI which provides the order in whcih the patches are applied
<khem>
LetoThe2nd: Heisenberg's principle 🙂
<MrSaturn>
qschulz: Ok, thanks. I will probably rename it because I am a bit OCD like that.
jmiehe has quit [Quit: jmiehe]
<qschulz>
MrSaturn: I feel you :)
<LetoThe2nd>
khem: 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?"
<khem>
only last question matters though
<khem>
others are higher order functions
<LetoThe2nd>
khem: yes, and sometimes, at least there is certainty (question 3)
* khem
has been doing some elm lately
<LetoThe2nd>
khem: as in, switching mail clients? ;-)
<khem>
no as in programming languages, its a functional programming language
<khem>
hence the higher order functions
<LetoThe2nd>
khem: yeah, just pulling your leg. i've done a lot of JS, and it is really quite handy/strong there.
tre has quit [Remote host closed the connection]
tnovotny has quit [Quit: Leaving]
Schlumpf has quit [Quit: Client closed]
davidinux has quit [Ping timeout: 240 seconds]
davidinux has joined #yocto
Minvera has joined #yocto
mckoan is now known as mckoan|away
vmeson has quit [Ping timeout: 260 seconds]
vmeson has joined #yocto
Mike123 has joined #yocto
Mike123 has quit [Quit: Client closed]
Mike23 has joined #yocto
Mike23 has quit [Client Quit]
Mike23 has joined #yocto
pasherring has quit [Quit: Leaving]
lucaceresoli_ has quit [Ping timeout: 260 seconds]
<dacav>
rfs613: 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 :)
<rfs613>
dacav: layers have priorities, try "bitbake-layers show-layers" and note the number at the far right of each line.
Mike23 has quit [Quit: Client closed]
GNUmoon has quit [Remote host closed the connection]
GNUmoon has joined #yocto
florian has quit [Ping timeout: 256 seconds]
frieder has quit [Remote host closed the connection]
Mike23 has joined #yocto
GNUmoon has quit [Ping timeout: 240 seconds]
florian has joined #yocto
GNUmoon has joined #yocto
<jonmason>
zeddii: you around?
Mike23 has quit [Quit: Client closed]
sakoman has quit [Quit: Leaving.]
florian has quit [Ping timeout: 240 seconds]
<jonmason>
zeddii: disregard
<RP>
jonmason: did we ever get anywhere with those arm tiny patches?
amitk has quit [Ping timeout: 240 seconds]
<jonmason>
RP: it's on my todo list to bottom out on what got pulled in for the yocto-kernel-cache, then revise them
<jonmason>
I did a rebuild yesterday to start, then got told/reminded I'm on swat this week :)
<jonmason>
I'll do my best to get something out tomorrow
florian has joined #yocto
<RP>
jonmason: fair enough, just thought about it the other day
<jonmason>
there is other stuff with hvc0 that needs to be figured out, but I can drop those patches
<jonmason>
essentially, without those being present, poky-tiny sprays errors on stdout forever as fast as it can
<jonmason>
err..with hvc0 being in the machine conf file, but not being present
<RP>
jonmason: I couldn't remember where we were at with them to be honest
<jonmason>
they 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 now
<RP>
jonmason: ah, yes, think I had to pull the patches as the kernel bits weren't there yet
Mike23 has joined #yocto
Mike23 has quit [Client Quit]
<MrSaturn>
Huh. 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.
<jonmason>
it did seem to match what was in there for the others
<RP>
it doesn't look like the usual server timeout tome
<abelloni>
I have to grabe something to eat, can you check?
<abelloni>
(hte logs)
<RP>
abelloni: the logs are there I think
<dacav>
rfs613: thanks
<RP>
nothing useful :/
<jonmason>
RP: 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 issue
<RP>
jonmason: was that the centos7 one?
<jonmason>
yes
<RP>
jonmason: I didn't get a conclusive answer but I think the copying times were very high, around 290s in a 300s timeout
<RP>
so I thought it was IO load related
Minvera has quit [Remote host closed the connection]
<smurray>
MrSaturn: I believe all the kernel recipes in meta-freescale are based on kernel-yocto.bbclass, so .cfg fragments should work with those
<jonmason>
RP: should I open a bug to track it or just mark it down to hw?
<RP>
jonmason: best ask abelloni what to do with that, whether there is an existing one
<RP>
abelloni, 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 exited
<MrSaturn>
smurray: 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.
<RP>
which match the start time in the log, translating the epoch value
<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 app.bb do git HEAD? we would like for each meta-foo commit to represent a known snapshot of application commits at that point
<jsbronder>
steev_: This still ends up pointing something at HEAD, but it might be helpful:
<jsbronder>
We have a virtual/app with two recipes that (R)PROVIDE it, app.bb and app-live.bb.
<jsbronder>
For nightlies, we build the app-live.bb recipes, which point at HEAD, for releases we build the app.bb recipes which point at an annotated tag.
<jsbronder>
The app-live.bb recipes also dump some `git describe` output in /etc so we can trace back.
<jsbronder>
steev_: With mild effort; you have the shas in /etc. Each app-live.bb recipe has something like:
<jsbronder>
APP_URI ?= "uri pointing to tip of master>"
<jsbronder>
SRC_URI = "${APP_URI}"
<jsbronder>
So, you can override APP_URI to point to whatever sha.
<JaMa>
moto-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 2022
<jsbronder>
That said, we archive the artifacts from each nightly for quite a while, so in reality I'd just go back and pull those.
<moto-timo>
JaMa: understood. I won't pester you about it anymore ;)
<moto-timo>
a few minor warnings about licensing changes and so on... plus a couple distutils3 changes... but anyway. I'll try to follow the community
<JaMa>
moto-timo: you can pester Rob Woolley of WindRiver or someone from Xilinx who was also interested in maintaining meta-ros ..
florian has quit [Ping timeout: 260 seconds]
mvlad has quit [Remote host closed the connection]
<moto-timo>
JaMa: good to know. There was also interest within Intel, but it never went anywhere with my direct team. And I have no visibility anymore ;)
Guma has joined #yocto
florian has joined #yocto
<JaMa>
moto-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 :)
<moto-timo>
JaMa: well, I hope you are moving on to better things! 🍻 🏎️
<jsbronder>
steev_: Honestly, if you care about reproducibility, you should be pulling from tags.
rfs613 has quit [Quit: restart]
rfs613 has joined #yocto
<steev_>
jsbronder: i understand, thanks
<Guma>
Hello 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.