ldericher has quit [Read error: Software caused connection abort]
tlwoerner has quit [Read error: Software caused connection abort]
shoragan has joined #yocto
zwelch has quit [Read error: Software caused connection abort]
ldericher has joined #yocto
tlwoerner has joined #yocto
nemik has quit [Ping timeout: 252 seconds]
nemik has joined #yocto
florian_kc has joined #yocto
zwelch has joined #yocto
iokill has quit [Read error: Software caused connection abort]
florian_kc has quit [Ping timeout: 255 seconds]
iokill has joined #yocto
Habbie has quit [Ping timeout: 268 seconds]
<PhoenixMage>
If I want to add a new SBC defconfig for u-boot is it enough to add it as a SRC_URI or do I need to do_compile_prepend() and copy it to the correct location?
Vonter has quit [Ping timeout: 252 seconds]
Vonter has joined #yocto
nemik has quit [Ping timeout: 272 seconds]
nemik has joined #yocto
xantoz has joined #yocto
nemik has quit [Ping timeout: 252 seconds]
nemik has joined #yocto
Dracos-Carazza has quit [Ping timeout: 246 seconds]
olani has joined #yocto
olani- has joined #yocto
Habbie has joined #yocto
kscherer has quit [Quit: Konversation terminated!]
bryanb has quit [Read error: Software caused connection abort]
bryanb has joined #yocto
<PhoenixMage>
Ended up using SRC_URI along with apply=no and subdir=${S}/configs not sure if thats good/accepted practice or not
lexano has quit [Ping timeout: 252 seconds]
svuorela has quit [Read error: Software caused connection abort]
lexano has joined #yocto
davidinux has quit [Ping timeout: 255 seconds]
svuorela has joined #yocto
davidinux has joined #yocto
goliath has quit [Quit: SIGSEGV]
amitk has joined #yocto
iokill has quit [Ping timeout: 252 seconds]
iokill has joined #yocto
starblue has quit [Ping timeout: 248 seconds]
starblue has joined #yocto
nemik has quit [Ping timeout: 272 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 248 seconds]
nemik has joined #yocto
xantoz has quit [Ping timeout: 252 seconds]
xantoz has joined #yocto
prabhakarlad has quit [Quit: Client closed]
jclsn has quit [Ping timeout: 276 seconds]
jclsn has joined #yocto
xmn has quit [Ping timeout: 272 seconds]
amitk has quit [Ping timeout: 252 seconds]
lexano has quit [Ping timeout: 252 seconds]
amitk has joined #yocto
lexano has joined #yocto
nemik has quit [Ping timeout: 248 seconds]
nemik has joined #yocto
drewfustini has quit []
drewfustini has joined #yocto
nemik has quit [Ping timeout: 252 seconds]
nemik has joined #yocto
sakoman has quit [Quit: Leaving.]
iokill has quit [Ping timeout: 252 seconds]
iokill has joined #yocto
starblue has quit [Ping timeout: 252 seconds]
starblue has joined #yocto
mk41 has quit [Quit: mk41]
olani- has quit [Ping timeout: 272 seconds]
olani has quit [Ping timeout: 272 seconds]
olani has joined #yocto
olani- has joined #yocto
alessioigor has joined #yocto
alessioigor has quit [Client Quit]
lexano has quit [Ping timeout: 252 seconds]
lexano has joined #yocto
camus has quit [Ping timeout: 248 seconds]
camus has joined #yocto
rfuentess has joined #yocto
nemik has quit [Ping timeout: 248 seconds]
nemik has joined #yocto
kroon has joined #yocto
nemik has quit [Ping timeout: 252 seconds]
nemik has joined #yocto
<PhoenixMage>
FYI, the classes anchor doesnt work as expected in the documentation 4.1.3 Classes is #classes as is 5 Classes and so any links for to 4.1.3
<PhoenixMage>
The is for the Kirkdale all in one manual
iokill has quit [Ping timeout: 252 seconds]
iokill has joined #yocto
kroon has quit [Quit: Leaving]
tlwoerner_ has joined #yocto
tlwoerner has quit [Ping timeout: 272 seconds]
<LetoThe2nd>
yo dudX - reality check for my guesswork. is is possibly that " addtask mymagic after do_install before do_populate_sysroot " in a systemd bbappend messes up the task order such that a race is created?
<JaMa>
well depends on what your magic does
<LetoThe2nd>
JaMa: just a sed on a .service.
<RP>
LetoThe2nd: are you expecting that change to be packaged?
<RP>
LetoThe2nd: i.e. do you mean do_package, not do_populate_sysroot ?
<LetoThe2nd>
RP: yes. i guess that this change (running the sed) was running concurrently to do_package, and hence the tar error that i witnessed yesterday occurred.
<RP>
LetoThe2nd: that would make sense
<RP>
LetoThe2nd: it is why people tend to append do_install
tlwoerner_ has quit [Ping timeout: 272 seconds]
<LetoThe2nd>
RP: ... which is what i also advised and seems to have fixed it. it just was not occurring in my build, but my coworkers, and i blame it on different states of sstate and core count.
tlwoerner has joined #yocto
<RP>
LetoThe2nd: sstate is almost certainly innocent. It would just be the different speeds of the machines
<LetoThe2nd>
RP: understood, thanks!
zpfvo has joined #yocto
<JaMa>
anyone else seeing "error[E0405]: cannot find trait `FnOnce` in this scope" build failures with today's oe-core? seeing it in python3-bcrypt python3-cryptography <= this got "resolved" by rebuilding libstd-rs
Schlumpf has joined #yocto
<JaMa>
RP: kanavin_: FYI: looks like libstd-rs doesn't work well when rebuilding in the same WORKDIR (as the "broken" one had more files, possibly from previous build) https://pastebin.com/ikFWA8X8
leon-anavi has joined #yocto
nemik has quit [Ping timeout: 272 seconds]
nemik has joined #yocto
frieder has joined #yocto
davidinux has quit [Ping timeout: 248 seconds]
davidinux has joined #yocto
nemik has quit [Ping timeout: 252 seconds]
nemik has joined #yocto
lexano has quit [Ping timeout: 252 seconds]
lexano has joined #yocto
mckoan|away is now known as mckoan
camus has quit [Ping timeout: 252 seconds]
camus has joined #yocto
rfuentess_ has joined #yocto
manuel1985 has joined #yocto
rfuentess has quit [Ping timeout: 252 seconds]
mvlad has joined #yocto
prabhakarlad has joined #yocto
Payam has joined #yocto
zpfvo has quit [Quit: Leaving.]
zpfvo has joined #yocto
<RP>
JaMa: that sounds like a good lead since the autobuilder wouldn't hit that
ptsneves has joined #yocto
florian_kc has joined #yocto
ptsneves has quit [Ping timeout: 268 seconds]
florian_kc has quit [Ping timeout: 252 seconds]
nemik has quit [Ping timeout: 255 seconds]
nemik has joined #yocto
<JaMa>
leon-anavi: were some of the build issues with python-3.11 re module looking like this? "re.error: global flags not at the start of the expression at position 1"
<JaMa>
leon-anavi: chromium-91 build fails like this, I was going to test if your patches fix this
<leon-anavi>
no, not as far as I remember. I had issues with re missing from the images that include python packages with RDEPENDS on python3-core.
<leon-anavi>
This is how I've spotted the re issue.
<JaMa>
ok, this is python3-native
tlwoerner_ has joined #yocto
<leon-anavi>
ah, ok, I don't know for python3-native. I didn't test this in particular yesterday.
nemik has quit [Ping timeout: 272 seconds]
nemik has joined #yocto
<leon-anavi>
JaMa, do you get this error with my patch for the python manifest which fixes the re issue?
tlwoerner has quit [Ping timeout: 252 seconds]
<JaMa>
leon-anavi: without your patch, wanted to investigate a bit more before triggering another long chromium build
<leon-anavi>
I know what you mean. I've just compiled chromium for i.mx8 :)
<JaMa>
it doesn't seem to fail in newer chromium-94 but comparing related python scripts doesn't show any useful diff, so it might be that the 2 builds I was looking at don't even have src/tools/metrics/ukm enabled in one of them
florian has joined #yocto
<leon-anavi>
hm
lexano has quit [Ping timeout: 252 seconds]
Payam has quit [Quit: Client closed]
lexano has joined #yocto
kriive has joined #yocto
<kriive>
Hey everyone, how do you remotely connect to your Yocto devices, once they're out of the factory? SSH? Custom made apps?
<kriive>
For debugging purposes
starblue has quit [Ping timeout: 272 seconds]
starblue has joined #yocto
<mckoan>
kriive: ssh
<kriive>
mckoan: with SSH certificates or with SSH keys? Key management always makes me brrr
<qschulz>
kriive: LetoThe2nd will be happy to present the solution mender.io commercially provides for that scenario
<qschulz>
I don't have experience with any solution because we don't allow SSH connection to our products, so I will remain silent now :)
<manuel1985>
kriive: Not doing that yet, but what I'm planning to do is to have the devices establish a ssh remote tunnel to some server I own at the press of a button.
<manuel1985>
using ssh keys. Didn't comprehend SSH certificates yet.
<PhoenixMage>
Why is the u-boot recipe "u-boot" rather then say "u-boot_2022.01" in kirkstone for example? eg, I have to bitbake u-boot rather then bitbake u-boot_2022.01?
nemik has quit [Ping timeout: 252 seconds]
<PhoenixMage>
Something to do with ignoring _*?
<qschulz>
PhoenixMage: u-boot is the recipe name, 2022.01 is the recipe version
<qschulz>
BPN and PV respectively
<qschulz>
this allows to have multiple recipes for the same SW but with different versions at the same time, in the same or different layers
<qschulz>
and then in your dependencies you have u-boot instead of u-boot_2022.01 for example, which is much easier on maintenance level
<qschulz>
how to pick between versions is done via the PREFERRED_VERSION_u-boot variable to be put in a configuration file
<PhoenixMage>
Ah thanks, that last was the missing piece
nemik has joined #yocto
nemik has quit [Ping timeout: 252 seconds]
nemik has joined #yocto
Payam has joined #yocto
<leon-anavi>
JaMa, ok. I can't open the link because I doesn't have access to this page. I guess I will need to do some registration.
<JaMa>
if there is something like recently added cargo-update-recipe-crates.bbclass I would give it a try on some other go recipe
<manuel1985>
qschulz: sstate-cache doesn't seem to handle changes of NO_RECOMMENDATIONS well. When flipping that switch from 1 to 0 bitbake reports lots of errors about installed but unpackaged files. Deleting the sstate-cache reliably fixes them.
<manuel1985>
So I'm looking for an alternative to wiping the whole sstate-cache but want to delete only the parts of that image.
<manuel1985>
be right back
<qschulz>
manuel1985: NO_RECOMMENDATIONS does not impact whether a file is packaged or not
chep has joined #yocto
<qschulz>
it impacts whether a package is brought in the final image
<JaMa>
unless they do something silly with it and if they do, they should fix that instead of spreading the issue to sstate handling as well
<qschulz>
so there's an issue somewhere that needs to be fixed, the sstate-cache issue is probably a side-effect or consequence of that issue
<qschulz>
JaMa: too fast for me :)
<JaMa>
you've beaten me about NO_RECOMMENDATIONS not affecting packaging :)
<sakoman>
JaMa: yes, I know. We were testing in parallel. I'll fix that before I send for review
<JaMa>
perfect, thanks
<manuel1985>
qschulz: I agree there is an issue to be fixed, but I'm able to dive into bitbake enough to do that
<manuel1985>
hence my request to delete only parts of the sstate-cache used by that particular image
Payam has quit [Ping timeout: 260 seconds]
<manuel1985>
qschulz: Perhaps the variable in question was LICENSE_CREATE_PACKAGE rather than NO_RECOMMENDATIONS.
<manuel1985>
The files complained about were license files
<sakoman>
JaMa: Yes, I'll grab the second one too -- I'm still catching up on the flood of patches in master from Richard's return. And juggling three branches :-)
zpfvo has quit [Ping timeout: 252 seconds]
<zeddii>
JaMa: it's a hacky python script that I have. Get me about 90% of the way to a recipe, and then I have to debug all the corner cases manually.
xcm_ has joined #yocto
zpfvo has joined #yocto
dlan_ is now known as dlan
dlan has quit [Quit: leaving]
dlan has joined #yocto
florian has quit [Quit: Ex-Chat]
hcg has quit [Quit: leaving]
<qschulz>
manuel1985: we've had people complain about broken builds with missing license files lately on IRC (maybe on the ML too?)
<qschulz>
manuel1985: but having a minimal reproducer reported on the ML or bugzilla would be really great!
<JPEW>
Ya, I don't think that needs to be exported
<RP>
JPEW: I'll send a patch. Doesn't change much but we may as well get rid of stuff we don't need in the env
<JPEW>
for sure
<fray>
it was exported as some programs used that as their internal DATETIME..
<fray>
it MIGTH have been the value for DATETIME in the compiler too, but I don't remember if it was something else
<RP>
fray: SOURCE_DATE_EPOCH, sure, not _FALLBACK
mvlad has quit [Remote host closed the connection]
<vvn>
I wish to set the PV dynamically, not from the source code revision, but from the content of a file in the source. Which task/variable should I edit to do so?
<RP>
vvn: that isn't very easy since bitbake expects to parse PV before it fetches/unpacks
<fray>
I seem to remember finding a script that knew about _FALLBACK as well.. but last time I looked was over a year ago
<rburton>
vvn: you can set PV to 0 and then set PKGV at runtime. that's madness, don't do that.
<RP>
fray: I only see references in meta/lib/oe/reproducible.py
<fray>
ok..
<rburton>
fwiw, google suggests its only used in our code
florian_kc has quit [Ping timeout: 252 seconds]
Habbie has quit [Ping timeout: 246 seconds]
florian_kc has joined #yocto
<vvn>
rburton: RP: it's bad, but it's for a funky private weird case, so all good. Which task should I append to do d.setVar('PKGV', <content of file foo>)?
<fray>
vvn I've had to do that beefore.. anonymous python was the only way I could do that.. but that assumed the file existing ebfore do_fetch..
<RP>
vvn: look at what the kernel code does for meta/classes-recipe/kernel.bbclass:# KERNEL_VERSION is extracted from source code.
Habbie has joined #yocto
<RP>
I'm fairly sure that ends up in PKGV somewhere
<RP>
vvn: it will likely be hours of fun making it work properly
<fray>
Ahh forgot about that.. I knew it was used for verification PV == KERNEL_VERSION
seninha has quit [Quit: Leaving]
* landgraf
misses YP bug triage meetings and hates new job :(
<vvn>
thanks I'll look into that
<vvn>
if you think about any simpler way to inject the content of a source file in PV somehow, let me know :)
<JaMa>
vvn: look at meta-openembedded/meta-oe/classes/gitpkgv.bbclass
leon-anavi has quit [Quit: Leaving]
<JaMa>
vvn: or meta-openembedded/meta-oe/classes/gitver.bbclass
<JaMa>
one of them runs in ${S}
<jonmason>
zeddii: would you object to having ACPI enabled in efi.cfg?
<zeddii>
check the git history on those fragments, we've bounced back and forth on that a few times.
florian_kc has quit [Ping timeout: 252 seconds]
<jonmason>
no problem, I'll make a bigger mess then ;-)
<jonmason>
err...I mean, make no messes or problems for anyone...yeah, that's the ticket
Estrella__ has joined #yocto
Estrella___ has quit [Ping timeout: 248 seconds]
nemik has quit [Ping timeout: 272 seconds]
nemik has joined #yocto
goliath has joined #yocto
amitk has quit [Ping timeout: 246 seconds]
nemik has quit [Ping timeout: 255 seconds]
nemik has joined #yocto
sakoman has quit [Quit: Leaving.]
nemik has quit [Ping timeout: 255 seconds]
nemik has joined #yocto
goliath has quit [Quit: SIGSEGV]
nemik has quit [Ping timeout: 248 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 252 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 246 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 248 seconds]
nemik has joined #yocto
goliath has joined #yocto
nemik has quit [Ping timeout: 248 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 252 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 272 seconds]
nemik has joined #yocto
florian_kc has joined #yocto
kevinrowland has joined #yocto
<kevinrowland>
I have two very similar MACHINEs that both use the same image recipe. However, on one MACHINE I want to add an additional application to the IMAGE, via IMAGE_INSTALL. Where should I encode that? Should I add IMAGE_INSTALL_append = " special-app-for-machine-2" in machine-2.conf? Or should I use overrides and do IMAGE_INSTALL_append_machine-2 = "
<kevinrowland>
special-app-for-machine-2" in my image recipe? Is there any technical difference, or is it just a style preference?
<Saur[m]>
kevinrowland: Either works. However, there are differences. The most important one is that if you add it to `machine-2.conf`, then it will be added for all images you build. That can of course be avoided if you instead to `IMAGE_INSTALL_append_pn-your-image-name = " special-app-for-machine-2"`.
<kevinrowland>
Ahh of course, thanks. I'll probably keep it in the image recipe and use the MACHINE override, that feels right to me
<Saur[m]>
It's also a question of where you want to keep track of machine differences, together with the machine configuration so they are all in one place, or together with the image recipe so you can see there what may go into different images you build.
<kevinrowland>
Yep, I personally prefer to keep things like KBUILD_DEFCONFIG, the device-tree variable whose name I forget, and my U-Boot config in the machine configuration. Then put MACHINE-specific differences to IMAGE_INSTALL in the image recipe.. just feels better to me. I'll ask my team too of course :)
Estrella_ has quit [Ping timeout: 272 seconds]
Estrella___ has joined #yocto
kscherer_ has quit [Quit: Konversation terminated!]
Estrella__ has quit [Ping timeout: 252 seconds]
goliath has quit [Quit: SIGSEGV]
olani- has quit [Ping timeout: 255 seconds]
olani has quit [Ping timeout: 255 seconds]
chep has quit [Read error: Connection reset by peer]
chep has joined #yocto
Hazza has quit [Ping timeout: 272 seconds]
Haxxa has joined #yocto
chep has quit [Read error: Connection reset by peer]
chep has joined #yocto
kevinrowland has quit [Ping timeout: 260 seconds]
nemik has quit [Ping timeout: 248 seconds]
nemik has joined #yocto
starblue has quit [Quit: WeeChat 3.0]
nemik has quit [Ping timeout: 252 seconds]
nemik has joined #yocto
<mischief>
is there a way to disable network access during the configure/compile (or other) tasks?
goliath has joined #yocto
<JaMa>
mischief: yes and it's disabled by default in newer releases
<abelloni>
JaMa: speaking of which, I think your latest patch is failing on the AB but I'm going to confirm that soon
nemik has quit [Ping timeout: 272 seconds]
<mischief>
JaMa: looks neat, but i wonder if it will work under our build setup..
nemik has joined #yocto
starblue has joined #yocto
nemik has quit [Ping timeout: 272 seconds]
nemik has joined #yocto
ecdhe has quit [Ping timeout: 248 seconds]
florian_kc has quit [Ping timeout: 252 seconds]
florian_kc has joined #yocto
ecdhe has joined #yocto
kevinrowland has joined #yocto
<kevinrowland>
I don't see a way to apply kconfig fragments to U-Boot's configuration if those fragments are in the U-Boot source tree. It looks like they can come from SRC_URI only, and therefore are expected to live in a metadata layer, according to find_cfgs() in cml1.bbclass. Is there some technical or philosophical reason for that?
alimon has quit [Ping timeout: 252 seconds]
<PhoenixMage>
Is it the wic image that is usually able to be dd'ed on to an SD or eMMC?