<BhsTalel>
amahnui[m] Can you give me more information about that?
<amahnui[m]>
BhsTalel: It is an internship program that runs twice a year and there is currently a contribution period for those who's application for the program were approved. outreachy.org is their website
<vvn>
smurray: kergoth: BhsTalel: I get it (maybe). Something along the lines of REQUIRED_DISTRO_FEATURES += "systemd luks btrfs" in the machine configuration, then my distro must enable them and activate the corresponding service packages.
<amahnui[m]>
I thought you were applting for this current cohort
Bardon has quit [Ping timeout: 260 seconds]
BhsTalel has quit [Ping timeout: 250 seconds]
Bardon has joined #yocto
BhsTalel has joined #yocto
davidinux has joined #yocto
Starfoxxes has quit [Ping timeout: 248 seconds]
Starfoxxes has joined #yocto
BhsTalel has quit [Ping timeout: 250 seconds]
bps2 has quit [Remote host closed the connection]
bps2 has joined #yocto
jclsn0 has quit [Ping timeout: 246 seconds]
bps2 has quit [Ping timeout: 256 seconds]
jclsn0 has joined #yocto
jclsn0 has quit [Ping timeout: 256 seconds]
jclsn0 has joined #yocto
starblue has quit [Ping timeout: 248 seconds]
starblue has joined #yocto
jclsn0 has quit [Ping timeout: 268 seconds]
sakoman has quit [Quit: Leaving.]
creich_ has joined #yocto
jclsn0 has joined #yocto
creich has quit [Ping timeout: 260 seconds]
jclsn0 has quit [Ping timeout: 256 seconds]
jclsn0 has joined #yocto
jclsn0 has quit [Ping timeout: 272 seconds]
sakoman has joined #yocto
jclsn0 has joined #yocto
jclsn0 has quit [Ping timeout: 248 seconds]
jclsn0 has joined #yocto
jclsn0 has quit [Ping timeout: 256 seconds]
jclsn0 has joined #yocto
bonalais has quit [Quit: Connection closed for inactivity]
jclsn0 has quit [Ping timeout: 256 seconds]
jclsn0 has joined #yocto
xmn has joined #yocto
jclsn0 has quit [Ping timeout: 268 seconds]
jclsn0 has joined #yocto
akiCA has joined #yocto
amitk has joined #yocto
jclsn0 has quit [Ping timeout: 268 seconds]
codavi has joined #yocto
akiCA has quit [Ping timeout: 256 seconds]
jclsn0 has joined #yocto
codavi has quit [Ping timeout: 248 seconds]
BhsTalel has joined #yocto
jclsn0 has quit [Ping timeout: 268 seconds]
jclsn0 has joined #yocto
prabhakarlad has joined #yocto
sakoman has quit [Quit: Leaving.]
xmn has quit [Quit: ZZZzzz…]
cambrian_invader has quit [Ping timeout: 272 seconds]
cambrian_invader has joined #yocto
BhsTalel has quit [Quit: Client closed]
kevinrowland has quit [Quit: Client closed]
prabhakarlad has quit [Quit: Client closed]
prabhakarlad has joined #yocto
marcus_ has joined #yocto
<marcus_>
Is it possible to build multiple images and include those in the same wic file?
rob_w has joined #yocto
mike_87 has joined #yocto
mike_87 has left #yocto [#yocto]
frieder has joined #yocto
leon-anavi has joined #yocto
mckoan|away is now known as mckoan
kroon has joined #yocto
mckoan has quit [Ping timeout: 240 seconds]
mckoan has joined #yocto
<mckoan>
marcus_: yes, see yocto multiconfig feature or presentations online
GillesM has joined #yocto
<marcus_>
mckoan: thank you
<marcus_>
just to make sure that it is what I'm looking for. I want to create two images, one used as initrd which I want to include into the second image
simonew has joined #yocto
rfuentess has joined #yocto
<LetoThe2nd>
marcus_: yes, that is a valid usecase.
<LetoThe2nd>
and yo dudX
<LetoThe2nd>
for the record: the gdk-pixbuf build error was caused by using ubuntu 22.04 as build host. it might already be fixed there though, the container is a bit dated.
<marcus_>
Can I add a whole image to IMAGE_BOOT_FILES ?
camus has quit [Quit: camus]
camus has joined #yocto
<LetoThe2nd>
marcus_: don't see are prohibitive reason.
dev1990 has joined #yocto
ecdhe_ has joined #yocto
manuel1985 has joined #yocto
ecdhe has quit [Ping timeout: 246 seconds]
manuel1985 has quit [Remote host closed the connection]
manuel1985 has joined #yocto
Schiller has joined #yocto
BhsTalel has joined #yocto
Schiller41 has joined #yocto
Schiller has quit [Ping timeout: 250 seconds]
manuel1985 has quit [Remote host closed the connection]
manuel1985 has joined #yocto
manuel_ has joined #yocto
manuel1985 has quit [Ping timeout: 246 seconds]
gsalazar has joined #yocto
florian has joined #yocto
<LetoThe2nd>
we're seeing almost full rebuilds lately without metadata updates. Anybody else witnessing such?
gsalazar has quit [Ping timeout: 260 seconds]
<JaMa>
LetoThe2nd: yes, I'm seeing the same, I think global warming is caused by oe-core :)
<LetoThe2nd>
JaMa: also no pointer yet?
<RP>
I was thinking of trying 22.04 too :/
gsalazar has joined #yocto
<LetoThe2nd>
RP: it worked well except for gdk-pixpuf. I've rebuild the container and will give it a spin laters. Will let you know.
<JaMa>
LetoThe2nd: I assume you're not using uninative with 22.04, right?
* JaMa
is using 22.04 with uninative, but libstdc++ pinned on older version
<JaMa>
haven't seen gdk-pixbuf error yet
<LetoThe2nd>
for the rebuild thing? no. its my coworkers reporting it "happening roughly once a day", so we're suspecting date leaking in somewhere.
gsalazar has quit [Ping timeout: 256 seconds]
<LetoThe2nd>
JaMa: one dev reports using crops, and uninative "probably not", e.g. not actively enabled it.
gsalazar has joined #yocto
<qschulz>
LetoThe2nd: uninative is enabled by default IIRC
<manuel_>
Can anyone rephrase this sentence for me? "Because the RRECOMMENDS variable applies to packages being built, you should always attach an override to the variable to specify the particular package whose usability is being extended."
<manuel_>
It's explaining why I should use the overlay syntax. This is given as an example: RRECOMMENDS:${PN}-dev += "wireless_package_name"
<manuel_>
In the FILES_${PN}-dev variable, is the "_" also an override? So basically this tells me that RRECOMMENDS works the same as the FILES variable do in terms of override
Samiha has quit [Quit: Client closed]
<JaMa>
yes it works the same and it should be FILES:${PN}-dev
<JaMa>
':' is override separator used since honister (backwards compatible with dunfell, gatesgarth, hardknott as well if you have recent bitbake revision)
<JaMa>
older releases were using '_' as separator
<JaMa>
there are some cases where _ is part of variable name (not used as override separator), new syntax makes this more clear
stanf has joined #yocto
<RP>
JaMa: is it worth asking the opkg maintainer about that?
<JaMa>
RP: the = operator in RDEPENDS? I was hoping to get confirmation that this works correctly in rpm
<JaMa>
if it's the correct behavior at all
<RP>
JaMa: I think it does work in rpm but I guess we should confirm
<JaMa>
it happens only for rootfs task with ptest included which might not be covered by autobuilder
GNUmoon has quit [Remote host closed the connection]
<manuel_>
JaMa: Thanks! Was having lunch and came back only now
gsalazar has joined #yocto
xmn has joined #yocto
<vvn>
kergoth: hi -- poking you as you're a feature user ;-) if I get it right, would you add something like IMAGE_CLASSES += "${@bb.utils.contains('COMBINED_FEATURES', 'foo', 'foo-img-class', '', d)}" in your distro, instead of forcing IMAGE_CLASSES += "foo-img-class" in either the machine or distro conf, or polluting the distro with IMAGE_CLASSES:append:foomach = " foo-img-class"?
gsalazar has quit [Ping timeout: 260 seconds]
<vvn>
smurray: ^ to conclude yesterday's conversation, I think that's how you "cleanly" split your bsp and distro requirements without too much noise.
<RP>
kanavin: I'll leave that with you then, thanks!
<kanavin>
RP: I figured it out. Apparently some host distro shells write out the above snippet verbatim, e.g. do not convert \n to newlines
<kanavin>
I changed that to installing a proper file from SRC_URI
<RP>
kanavin: there is a way to do that more portably with printf iirc but src_uri is easier
<LetoThe2nd>
when sharing SSTATE over NFS as described in https://wiki.yoctoproject.org/wiki/Enable_sstate_cache, the usual way to update the shared one is to rsync the locally generated one back after the build is done, right?
<RP>
LetoThe2nd: if you have write you can just set SSTATE_DIR to there?
<qschulz>
LetoThe2nd: just set SSTATE_DIR to the nfs mountpoint and people will just populate it?
zen_coder has joined #yocto
sakoman has joined #yocto
<zen_coder>
Hello, I have created a meta toolchain ("bitbake meta-toolchain") in yocto and would like to add some more components to it, e.g. "xorg" (akaX11) How can I do this?
<LetoThe2nd>
RP: qschulz: I always thought this is not allowed for concurrent builds?
<JaMa>
locks will prevent overwritting the same file concurrently
<LetoThe2nd>
zen_coder: any reason why you went with the meta-toolchain target over an image derived (e)SDK?
<RP>
JaMa: no locks for sstate! Just atomic moves
<RP>
LetoThe2nd: SSTATE_DIR and DL_DIR are special and can be shared
<JaMa>
ah sorry, locks for shared DL_DIR, right?
<LetoThe2nd>
RP: ah kay, thanks
<RP>
JaMa: yes
<zen_coder>
LetoThe2nd: I need a toolchain for cross compilation, as slim as possible. And small enought for me to add necessary package as requested
<JaMa>
LetoThe2nd: we were using rsync after build long time ago and switching to shared SSTATE_DIR significantly helped with build times (especially when multiple similar builds were triggered on different builders)
<LetoThe2nd>
zen_coder: is the meta-toolchain target actually *noticeable* smaller? i mean, i kinda doubt it. and the image derived one would exactly match the shipped libraries on the target.
<JaMa>
RP: rburton: rpm was able to install python3-cryptography-ptest, at least I've noticed one not-closed package.manifest in log.do_rootfs while testing it
<rfs613>
when I cherry-pick a fix from master to older branch, do I keep the existing Signed-off-by's ?
<JPEW>
rfs613: Yes
<rfs613>
JPEW: thanks!
GLumen_ has joined #yocto
GLumen__ has joined #yocto
GLumen_ has quit [Ping timeout: 256 seconds]
<RP>
JaMa: There might even have been a bug opened for that in the last week so I'd love a fix :)
<RP>
JaMa: what is really interesting to me is that IMAGE_INSTALL:append = " python3-cryptography python3-cryptography-vectors" works with ipk but IMAGE_INSTALL:append = " python3-cryptography-ptest" does not
<JaMa>
the PV dependency is only on PN-ptest package, right?
<RP>
JaMa: ah, that would explain it then :)
<RP>
JaMa: I was just about to go and look at that
<JaMa>
not sure how rpm compares them, but it installed the ptest package even after bumping vectors PR to r1
<JaMa>
the package.manifest close() fix already sent, will try to find bug reference for it
gsalazar has quit [Remote host closed the connection]
gsalazar has joined #yocto
<jclsn[m]>
How can I have Bitbake pass Artifactory credentials without adding it to the URL?
<jclsn[m]>
I have SOURCE_MIRROR_URL = "https://$ARTIFACTORY_USER:$ARTIFACTORY_TOKEN@artifactory.server:443/artifactory/test_repo/yocto-mirror/" in my local.conf
gsalazar has quit [Remote host closed the connection]
gsalazar has joined #yocto
xen38 has joined #yocto
xen38 has quit [Client Quit]
SpicyChimera has joined #yocto
<SpicyChimera>
Hello everyone. Can I ask you a few questions regarding Yocto?
<vvn>
SpicyChimera: don't ask to ask
<jclsn[m]>
SpicyChimera: Sure
gsalazar has quit [Ping timeout: 272 seconds]
<SpicyChimera>
I'm kinda new to Yocto but the company I'm doing my internship at wants to use it on their board - a Variscite DART-MX8M-PLUS. They are gonna use it for Computer Vision stuff. Do I need to rebuild every time I need to "install" a package? If so, is there a way to save some time?
<LetoThe2nd>
SpicyChimera: everything that can be reused will be reused, so unless you're doing changed deeper in the application stack consecutive rebuilds of the image will be considerably faster.
<LetoThe2nd>
SpicyChimera: the keyword is SSTATE here
<rburton>
SpicyChimera: you can use package management to just install on the target
<jclsn[m]>
Hmm so I could figure out how to generate the right wget command now. Guess I have to work with PREMIRRORS instead of SOURCE_MIRROR_URL
jmiehe has quit [Remote host closed the connection]
gsalazar has quit [Ping timeout: 268 seconds]
jmiehe has joined #yocto
<jclsn[m]>
No SOURCE_MIRROR_URL should provide the PREMIRRORS, but when I use BB_FETCH_PREMIRRORONLY it doesn't work
SpicyChimera has quit [Quit: Connection closed]
<RP>
JaMa: I tested with the deb backend and that also shows an error so rpm works, ipk and deb do not
<jclsn[m]>
It only tries to fetch from Artifactory when I add BB_NO_NETWORK = "1", but even if I allow it with BB_ALLOWED_NETWORKS, it doesn't work
<RP>
JaMa: Looks like this part of the design of debian :(
<RP>
JaMa: an exact version specification needs to include the PR in our terms (or it is assumed to be 0 whilst ours is r0)
GLumen__ has quit [Remote host closed the connection]
GLumen__ has joined #yocto
<dvorkindmitry>
I need sys/io.h in SDK. what package generates it?
GLumen__ is now known as GLumen
<rburton>
dvorkindmitry: that's a x86 specific header, so is your target x86?
<dvorkindmitry>
rburton, no, it is ARM
<rburton>
then your SDK won't have sys/io.h
kevinrowland has joined #yocto
<manuel_>
I
frieder has quit [Remote host closed the connection]
<kergoth>
vvn: yeah, that seems like a good approach to me. That sort of thing is how best to handle it, avoids hardcoding machine or distro references in one another
<vvn>
kergoth: I understand better now, thank you. If I may ask, how would you configure the distro to enable hardware acceleration for the BSP beaglebone for example? This requires PREFERRED_PROVIDER_virtual/gpudriver = "ti-sgx-ddk-km" and a few other providers that aren't set by default.
<kergoth>
I'd make all of that conditional on a feature in MACHINE_FEATURES, then it's up to you if you want that feature to be default for a certain machine or machine variant or if you want the distro to append to MACHINE_FEATURES. it crosses the boundaries, but it's sometimes necessary, and is still better than hardcoding machine or distro references. Personally i'd probably create a machine that includes the non-accelerated machine and
<kergoth>
then enables the machine feature, but your call
BhsTalel has joined #yocto
<vvn>
kergoth: I see. But this is confusing as I thought the machine features are supposed to be invariant, describing "what features I have", compared to the distro features describing "what features I want".
<kergoth>
It's true, but it's fuzzy when it's about enabling a function of the machine/bsp. Ideally you'd probably obey combined features instead of machine features in the machine layer, if it's a non-default machine feature, but I'm not sure if that's commonly done or not.
<kergoth>
This stuff should probably be in a guide to BSP/machine layer construction :)
<kergoth>
aka "Vendors: here's how to improve your layers to not be a hot mess" :)
<vvn>
there is a "gpu" machine features for that, but somehow you need to say "I want to use it". There is the "hwcodecs" image features, but the preferred providers must be set at the distro level. I guess we must introduce "hwaccel" distro feature maybe and have the BSP enable their GPUs by default?
<vvn>
So beaglebone.conf for example sets all providers to ti-sgx-ddk-{k,u}m, then default-distrovars.inc or a core include file like that sets these providers to "mesa" or such generic packages if the feature isn't combined
<kergoth>
Yeah, you have a few options for how to express that desire to use the feature. Either you use a machine variant that enables it, or obey the distro's preference on it. I think either are reasonable options
<kergoth>
afaik
<rburton>
RP: posted an improvement for the meta-virt autobuilder run. i propose we enable it for master runs to keep zeddii on his toes ;)
<rburton>
its deliberately lean so its something that actually works and can be incrementally expanded over time
rfuentess has quit [Remote host closed the connection]
<vvn>
kergoth: is it safe to reference DISTRO_FEATURES in the machine configuration, given the source order?
<vvn>
that seems weird
gsalazar has joined #yocto
<RP>
rburton: did you mention this to zeddii?
<rburton>
we've spoken
<rburton>
he can veto making it run by default, I haven't sent anything to make that happen yet
<rburton>
on-demand runs are still better than what we have currently
<RP>
JaMa, rburton: "fix" for the python3-crypto issue on deb/ipk
<RP>
^^^
<rburton>
ewww
<rburton>
the alternative is to revert the dependency
<rburton>
i was just trying to be clever
<RP>
rburton: it doesn't change the fact that this is just broken
* RP
wishes he had some better idea but this was the best I could come up with
<kergoth>
vvn: it can be done as long as no forced immediate expansion is done. I.e. ${@} is evaluated when it's used, not where it's defined, so source order isn't an issue. And yes, it does feel a little odd to go that route. I'd probably have a 'beaglebone-hwaccel' machine variant myself. but it's personal preference. i'd still make it a feature so it's easier to enable and disable, though
<RP>
rburton: -helper change added
<RP>
rburton: when you say "enable for master runs", you mean a-full?
<rburton>
yes
<RP>
rburton: will be interesting to only do that on master. We'd need to remove the meta-virt entry from the other helper branches
<RP>
rburton: I'm not even trying to make something "only master" in the autobuilder2 code
<rburton>
hah fair enough
<rburton>
well the change i did was low impact and should be easily backported...
<rburton>
now to figure out why testimage doesn't work
<RP>
rburton: I guess that is for me to try then? :)
<rburton>
not at all
<zen_coder>
LetoThe2nd: where do I put this variable TOOLCHAIN_HOST_TASK? In which file?
<BhsTalel>
Hello, can anyone explain to me (uninative) and (yocto-uninative.inc), I am not getting its definition and use case.
<BhsTalel>
Thanks
<zen_coder>
I mean TOOLCHAIN_TARGET_TASK
<RP>
rburton: it doesn't cherry-pick to hardknott FWIW, it does to honister
<RP>
BhsTalel: it allows you to share native sstate between different distros and OSes
<BhsTalel>
RP So if I want native builds run faster I include uninative in my distro ?
<zen_coder>
what are the package names in yocto for X11 and OpenGL? I need to add the Qt depedencies to make toolchain
leon-anavi has quit [Quit: Leaving]
* rfs613
thinks it's time to switch from using poky to separate repos. It's too hard to watch all the branches (-next, -nut) via poky. Any advice/tips on how to set this up, or otherwise how to arrange for development?
<rfs613>
also any pointers to articles/blog/FAQ about tools to manage the repos (repo/kas/etc) would be appreciated
<rburton>
i find kas a lot easier than repo for controlled builds
florian has quit [Ping timeout: 260 seconds]
<rburton>
but for local hacking, i have hand-controlled repos because that's easier
<rfs613>
hmm okay, I have hand-controlled ones now (but using the poky-aggregate), and finding it's tedious to go and make sure they are all aligned.
<vvn>
kergoth: board variants can be tricky with the MACHINEOVERRIDES order, but they are definitely simpler to manage once you figure it out. I'm using a 'bbb' variant too at the moment. I'll try to come up with something simple for the BSP vendors.
<BhsTalel>
For local work, hand-controlled repos are easier, for automation I think KAS is okay, but I think repo provides more control
<rfs613>
I could script this I suppose but it seems like it is common enough situation that there should be an obvious solution
<rburton>
if the job is 'update all these repos to this branch' then that's either a few lines of sh, or a little kasfile which you tell it to just fetch and not build anything
<vvn>
rfs613: to make sure your repos are aligned, kas is the best, since it ensures that your repos match the configure refspec plus your patches on top of them.
<rburton>
you've not really said what your goal is though, so it's hard to comment
<rburton>
for local hacking i have hand controlled branches because its only occasionally that they're actually on upstream branches, normally they're on local feature branches
<vvn>
The repo patching is huge for me and it's why I stick with kas, even though it has its flaws.
<rfs613>
rburton: true, I have not been very specific, because I am mentally still trying to figure it out ;-)
<rfs613>
but take for example the vim update patch which i posted today and then realized RP already did it.
<sotaoverride>
how do we tell the am image recipe to make a rootfs read only?
<rfs613>
normally I have been searchign CVEs in the mailing lists to see if they are addressed on dunfell.
<Saur[m]>
rfs613: So far no one has found a common solution to that problem. For what it's worth, we use `repo` and I like it. We also have a Git submodules alternative, but it is horrible to work with IMHO.
<rfs613>
(and that I don't have locally, because I am using poky rather than separate repos)
<rfs613>
I wonder if someone has collected pro/con lists for each of these approaches.
<vvn>
rfs613: there's no perfect too because it depends on your usage. As a build system developer, I like kas because it allows me to applied patches on top of my layers. It's handy to cherry-pick upstream patches or stage the one I want to contribute back. For a software developer it won't really matter.
<rburton>
rfs613: of course you don't want to do local builds with the staging branches like dunfell-nut as they might be broken: the point is that they're in testing
<kergoth>
kas really needs to get the ability to load plugins from layers at some point, that'd open up a lot of flexibility
<rburton>
kergoth: it used to, paulbarker removed it :)
<rburton>
i also want to add it back
<BhsTalel>
I like how KAS provides a way to patch layers and it is useful to test patches on layers before committing them to upstream, but I noticed that KAS made lot of developers, some of them are my coworkers) uses patches in production, which make the project cannot be built without KAS.
<rburton>
kergoth: my imaginary fork of kas has out-of-tree plugin support
<kergoth>
heh :)
<rburton>
BhsTalel: yeah that's bad form. i only use layer patches for short term workarounds. if they're hanging around then just have a proper fork of the layer.
<vvn>
yeah but kas as a strong bias on reproducibility, so loading plugins, out-of-tree stuffs etc. isn't gonna happen
<kergoth>
I don't think that would prevent reproducibility
<kergoth>
having the ability to add new commands for your product or distro would be invaluable
<vvn>
I hate the fact that it is too intruisive, overriding the bblayers.conf and local.conf and not working well with other default config files, but that's the reason why
<vvn>
ho and I use kas for its container too, I'm never building yocto on my host machine.
<BhsTalel>
For my projects I always choose between `repo` or `git submodules` for developers, after that one KAS file is used for the pipeline.
<vvn>
Given the bitbake built-in fetcher, supporting patches and all, it's too bad that we cannot come up with a layer.bbclass or something
<vvn>
describing source, patches, dependencies to other layers, all that using usual bitbake recipes.
<kergoth>
vvn: there used to be an oe fork that provided a 'oe bakery' tool, it was an 'oe' command on the host that could clone a repo that would hold a .conf that defined a variable in standard bitbake format the list of layers as urls, and would do the layer setup
<kergoth>
oe-lite was the project
<kergoth>
I always rather liked that idea
<kergoth>
then 'oe build', etc called out to the underlying bits that it cloned before
<kergoth>
oe clone git://foo && cd foo && oe build foo; or the like
<kergoth>
vvn: there's an item in the yocto proejct future dirctions page to address this, providing a definitive mechanism for layer cloning and management
<kergoth>
but it's non-trivial and requires knowledge of both project history and the use cases and alternative projects
<vvn>
I totally understand that it's a tricky topic
<vvn>
but I would still love to see all these OE-Core crappy init env scripts gone :)
<kergoth>
I don't think anything is going to meet all needs, we just need something that's good enough for most. those with more specific needs can extend or use something else
<kergoth>
I do think the plugin capability is going to be key to allow for such extension
mckoan is now known as mckoan|away
<rfs613>
for me it would be great to have at least one officially supported way... because right now the next step is unclear, I have to go research each of these tools to see how they work, if they fit my use case, etc. Repeat for each new potential contributor...
<kergoth>
I think kas isn't *too* far off from what we need, just might want to leverage our existing file format if possible, and make it more extensible
BhsTalel30 has joined #yocto
<kergoth>
yep, it's a definite barrier and adds to our already steep learnign curve ;)
<vvn>
kergoth: true, similarly to buildroot, you want a stable building base you can base your project on, which reads your layer recipes, fetch them all and build.
<vvn>
kergoth: yeah but forcing the use of local.conf only, forcing the non-bitbake syntax, it just abstracts bitbake too much
<kergoth>
I would like a clone command that does the initial clone of the repo that holds the .yaml/.conf to start things off, rather than having to clone that initial layer or project and run kas
<vvn>
it's one of these tools that make users know how to use kas but not bitbake, this is what I hate about it.
florian has joined #yocto
<kergoth>
Yeah, that's a good point. Encourages a lack of knowledge of the underlying tools
<kergoth>
Too much
<BhsTalel30>
I am developing a generic class for service management (systemd, init.d, busybox), so any recipe can inherit the class and set the service files only and the class handles everything like:
<kergoth>
Adding ease of use is one thing, but you can't avoid learning the underlying tooling
<BhsTalel30>
SERVICE_FILES[sysvinit] ...
<BhsTalel30>
I already done the systemd part
<BhsTalel30>
What do you think ?
BhsTalel has quit [Ping timeout: 250 seconds]
<vvn>
I want a non-intrusive tool which just bootstraps an OE-Core based project, not wraps everything. i.e. expect the user to call bitbake.
<kergoth>
I wouldn't mind the ability to add extra commands to wrap underlying commands, but it shouldn't hide the details. I'd actually like it to show the underlying command being run, even
<kergoth>
i.e. 'oe build target' prints '> bitbake target' after setting up the environment
<kergoth>
just to avoid the need to source something into your current shell
<kergoth>
(if desired)
<kergoth>
but it should be additional, not required
BhsTalel has joined #yocto
<kergoth>
i'd like to see proper completions generation and stuff too. `eval $(oe init zsh); bitbake foo`
<kergoth>
no reason it couldnt do that at the same time it adjusts PATH and all
<vvn>
kergoth: like everytimes you have a variable issue, one says "run bitbake -e recipe and grep". Ho well ok, let me type ./kas-container shell ./project.yml -c 'bitbake -e recipe'
<kergoth>
actually you could make the easiest method of adding new subcommands to the tool just a list of aliases defined in its .conf file. 'SUBCOMMANDS[modify] = "devtool modify"' or the like
BhsTalel30 has quit [Ping timeout: 250 seconds]
<kergoth>
ugh yes there's a fair bit of necessary boilerplate with kas that'd be nice to avoid
<vvn>
exactly
<kergoth>
just assume the project config path if it's not explicitly set, etc
<vvn>
BhsTalel: with your class, how do you configure manager-specific bits like Wants=foo.service Before=bar.service or WantedBy=some.target?
jmiehe has quit [Quit: jmiehe]
<BhsTalel>
vvn The .service files are provided by the developer, I am just automating the `FILES_${PN} , SYSTEMD_SERVICES, etc` files of the service classes and handling `do_install` also
willo has quit [*.net *.split]
willo has joined #yocto
simonew has quit [Quit: Client closed]
florian has quit [Ping timeout: 268 seconds]
vvn has quit [Quit: WeeChat 3.5]
vvn has joined #yocto
manuel_ has joined #yocto
<rfs613>
kergoth: you mentioned "oe" commands a few times, like "oe init zsh"... I don't see this in my yocto. Where does it come from?
vvn has quit [Quit: WeeChat 3.5]
<kergoth>
It doesn't exist, we're brainstorming
<rfs613>
ah, very good
<kergoth>
were talkinga bout theoretical alternatives for layer adn repo management and configuration
vvn has joined #yocto
<rfs613>
ok, and earlier you said you'd like to start with cloning a repo that only has .yaml/.conf files. I'm a bit puzzled because that is exctly how it seems it should work today, for both repo and kas.
<BhsTalel>
Maybe a simple idea like "Pass a layers conf file to the build source file, and then the sh file fetches them and setups up bblayers.conf and local.conf accordingly"
<BhsTalel>
So, just the developer needs to clone poky only, and then pass the conf file for it.
<rfs613>
actually there's a better link in the reference manual
marc2 has joined #yocto
<fabian>
ERROR: Setscene task /home/{user}/yocto/sources/poky/meta/recipes-extended/cronie/cronie_1.5.5.bb:do_populate_sysroot in both covered and notcovered.
<fabian>
Hi all, does anybody know how to fix the "both covered and notcovered" issue? I only saw it recently after recompiling with the dunfell-branch.
<rfs613>
fabian: I got that the other day, 600 times, once for each recipe. But it only happened once, and have not seen it again.
<fabian>
Ok thanks! I will re-run after this initial run and see if it disappears.
Guest94 has joined #yocto
Guest94 has quit [Client Quit]
vvn has quit [Quit: WeeChat 3.5]
vvn has joined #yocto
vvn has quit [Quit: WeeChat 3.5]
vvn has joined #yocto
florian has joined #yocto
cambrian_invader has quit [Ping timeout: 246 seconds]
cambrian_invader has joined #yocto
fabian has quit [Quit: Client closed]
<smurray>
khem: the recent tweak to the wxwidgets package config stuff breaks if one has wayland + opengl in DISTRO_FEATURES (w/o x11): https://paste.debian.net/1237163/
<smurray>
khem: it's not clear to me if the fix is to change the no_gui package config conflicts or not...
rob_w has quit [Read error: Connection reset by peer]
manuel_ has quit [Ping timeout: 248 seconds]
Minvera has quit [Remote host closed the connection]
amitk has quit [Ping timeout: 268 seconds]
GNUmoon has joined #yocto
florian has quit [Ping timeout: 268 seconds]
* moto-timo
immediately starts spamming zeddii at arm dot com
<vvn>
smurray: lol I came to the channel to mention exactly this... Having the same no_gui issue
<moto-timo>
zeddii: your warranty for your car has expired! Urgent! You must buy new coverage!
<vvn>
btw is this a standard distro feature or yet another arbitrary chosen feature from a package?
<moto-timo>
vvn: you speak as if there is some cosmic council of sages that has everything figured out. We're all just doing the best we can. Patches welcome.
<vvn>
moto-timo: I mean that additional user features are fine, but machine/distro/image features must be standard and could even end up listed on layers.openembedded.org
<vvn>
moto-timo: nothing to take personal here :)
<moto-timo>
vvn: my skin has grown very thick in the last decade.
<vvn>
I guess it's a good thing
<moto-timo>
vvn: but as almost the only person (some folks at WR as well) that is actually trying to maintain layers.openembedded.org I cry foul frequently.
<moto-timo>
"you" (universal you) use these tools for free and don't contribute a thing. Guess what happens?
* moto-timo
apologizes for being in a FOSS is in trouble mood
<vvn>
layers.openembedded.org is very nice, I use it all the time to look recipes location or have a quick web view of the source
<vvn>
moto-timo: and here you assume that everyone who complains don't contribute back. Nice.
<vvn>
Sure that skin is that thick? ;)
<moto-timo>
vvn: thick skin still exudes some bodily fluids
<moto-timo>
Like many of our core infrastructure tools, we do not have a maintainer. period.
<moto-timo>
Any code left alone for 2+ years will bit rot. This I can assure you.
<vvn>
moto-timo: hmm sorry if 'arbitrary chosen feature' pissed you off initially, but I don't really see the point you're trying to make here
<zeddii>
moto-timo. I deserved that troll!!
<moto-timo>
vvn: very simple. you use layers.openembedded.org. How is that being kept alive?
<moto-timo>
zeddii: yup.. trolling happens and is normal.
* moto-timo
is being trolled now.
<vvn>
moto-timo: ok but why the attack about the layer index?
<zeddii>
ahah buggers. are using my bad email address on that thread. Now I'm getting to enjoy all the bounces.
<moto-timo>
vvn: I am not attacking you. I am trying to scream at the universe that please support us in keeping it going. Who contributed last? Look at the repo and then come back.
<moto-timo>
zeddii: I am going to start selling you insurance on all your emails.
* moto-timo
sighs and thinks about cocktails.
<zeddii>
vvn. I'd suggest that there's no sense talking about any features / additions to the layer index, when it hasn't even been getting maintained properly for what it currently does. which is what moto-timo is yelling at the universe about :)
<zeddii>
in between trolling me that I can't type my own email address properly :)
* moto-timo
pushed commits that haven't been reviewed since January.
* moto-timo
considers yoga instead of cocktails
<zeddii>
moto-timo. do you have push privs ? I'd say "ship it!" :)
<moto-timo>
SHIP IT
<moto-timo>
I also have super secret privs to burn down the instance.
* moto-timo
will not ever do that intentionally.
<moto-timo>
Also, CROPS. do you use it? guess who maintains it?
* moto-timo
should _really_ shut up now.
<vvn>
zeddii: ho I see. Well I'm not asking for this, I just mentioned the layer index as an example for listing standard features. Forget about the example if that is a problem.
<moto-timo>
IRC has absolutely no nuance of body language or tone... we only have that because we meet IRL at conferences.
<moto-timo>
I have been the receiver of some harsh criticism by zeddii over beers at ELC San Diego 2016... and we are still closer friends than ever.
<moto-timo>
BhsTalel: other than that I guess it would be the issues on the repos in https://github.com/crops
* moto-timo
really wishes wxwidgets just worked
<BhsTalel>
Thanks , I will take a look
<khem>
smurray: vvn: I do Not have a no-x11 build on Jenkins or ci I think it’s perhaps good to enable no-gui for all the non-x11 profiles
* moto-timo
creates a new garbage collecting memory protected language with trainning wheels: 'zeddii"
<moto-timo>
khem: that is an excellent idea
<vvn>
khem: I'm trying with no_gui added to distro features. But does "gui" has a special meaning for wxwidgets? Because have wayland but no_gui seems weird
<smurray>
khem: any thoughts on what the proper fix would be?
* moto-timo
contemplates the meaning of "no_gui" when discussing GUI widgets
<vvn>
no_gui does conflict with opengl so it's a no-go
BhsTalel44 has joined #yocto
<smurray>
well, that's what happens to be in the recipe, we've no idea if that's actually correct until someone looks at wxwidgets
<vvn>
moto-timo: hence my initial note on a package choosing to handle a "no_gui" feature ;)
<smurray>
my guess is it's to run against a framebuffer
BhsTalel has quit [Ping timeout: 250 seconds]
<moto-timo>
vvn: this is like all the GNOME recipes requiring x11 perhaps... don't look behind the curtain
<moto-timo>
lol
<smurray>
but I was out sick today for the most part, and likely won't look at it tomorrow unless I'm feeling a lot better. Locally I just rolled went back to an older commit to keep the test build I was trying work
<smurray>
s/went//
<vvn>
smurray: I'm reverting 6c422af now
<khem>
smurray: I have to look at the code for more insights I am in transit
<smurray>
khem: k, no worries
<BhsTalel44>
I am newcomer, can anyone share with me the git repo you are working on ? Or where I can follow your work. I am intending to contribute once I understand the patching and committing flow
<vvn>
BhsTalel44: if you have a fix for this (other than reverting it) that'd be a great contribution ;)
<BhsTalel44>
I am trying to understand the issue ...
<moto-timo>
BhsTalel44: we work in many repos, but mostly you are likely to have already been using them to build your Yocto Project based images
<moto-timo>
BhsTalel44: git.yoctoproject.org and git.openembedded.org are the two main trunk servers we use... and then many others which perhaps layers.openembedded.org is a best place to get a feel for the magnitude of the known universe
<moto-timo>
BhsTalel44: we communite mostly via the lists.yoctoproject.org and lists.openembedded.org and then the #yocto and #oe channels on Liberachat.
<moto-timo>
s/communite/communicate/
<moto-timo>
BhsTalel44: but many of us have been working together for more than a decade, have met in person over drinks and dinner at conferences, etc. So some unspoken familiarity and sibling teasing happens.
BhsTalel44 has quit [Quit: Client closed]
* vvn
watches moto-timo sign-up to yoga classes
<moto-timo>
🤣
<moto-timo>
Back when I was first contributing to OE I did 90-minute _intense_ yoga sessions on Saturday mornings... good times