mvlad has quit [Remote host closed the connection]
otavio has quit [Ping timeout: 268 seconds]
otavio has joined #yocto
otavio has quit [Ping timeout: 268 seconds]
otavio has joined #yocto
otavio has quit [Ping timeout: 268 seconds]
otavio has joined #yocto
scott_ has joined #yocto
nateglims has quit [Quit: Client closed]
otavio has quit [Ping timeout: 260 seconds]
otavio has joined #yocto
otavio has quit [Ping timeout: 268 seconds]
otavio has joined #yocto
sakoman has quit [Quit: Leaving.]
otavio has quit [Ping timeout: 268 seconds]
otavio has joined #yocto
lukma has quit [Ping timeout: 268 seconds]
camus1 has joined #yocto
camus has quit [Ping timeout: 260 seconds]
camus1 is now known as camus
otavio has quit [Ping timeout: 260 seconds]
otavio has joined #yocto
lukma has joined #yocto
scott_ has quit [Ping timeout: 268 seconds]
camus1 has joined #yocto
camus has quit [Remote host closed the connection]
camus1 is now known as camus
xmn has quit [Quit: ZZZzzz…]
vd has quit [Quit: Client closed]
vd has joined #yocto
dlan has quit [Ping timeout: 265 seconds]
camus1 has joined #yocto
camus has quit [Ping timeout: 260 seconds]
camus1 is now known as camus
dlan has joined #yocto
pgowda_ has joined #yocto
deurzen has joined #yocto
deurzen_ has joined #yocto
scott_ has joined #yocto
camus1 has joined #yocto
vladest has quit [Remote host closed the connection]
camus has quit [Ping timeout: 260 seconds]
camus1 is now known as camus
camus has quit [Ping timeout: 260 seconds]
camus has joined #yocto
alessioigor has joined #yocto
GNUmoon has joined #yocto
deurzen_ has quit [Quit: Leaving]
deurzen has quit [Quit: Leaving]
Schlumpf has joined #yocto
camus1 has joined #yocto
camus has quit [Ping timeout: 260 seconds]
camus1 is now known as camus
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
alessioigor has quit [Remote host closed the connection]
alessioigor has joined #yocto
alessioigor has quit [Remote host closed the connection]
alessioigor has joined #yocto
alessioigor has quit [Remote host closed the connection]
alessioigor has joined #yocto
alessioigor has quit [Client Quit]
scott_ has quit [Ping timeout: 260 seconds]
manuel1985 has quit [Quit: Leaving]
goliath has joined #yocto
<hmw[m]>
hi, when i boot my target weston seems to crash ( westonlog )"caught signal 15" and i get could not load cursor 'dnd-move'/'dnd-copy' errors
rob_w has joined #yocto
camus1 has joined #yocto
camus has quit [Ping timeout: 260 seconds]
camus1 is now known as camus
mckoan|away is now known as mckoan
hpsy has joined #yocto
kroon has joined #yocto
<kroon>
Hi. Is anyone familiar with the ucm-imx8m-plus board from CompuLab ? I don't understand which Yocto versions and which bsp-layers I am supposed to use.
<JosefHolzmayrThe>
yo dudX
matthiasklein has joined #yocto
scott_ has joined #yocto
dtometzki has quit [Ping timeout: 260 seconds]
zyga-mbp has joined #yocto
fleg has joined #yocto
nad has joined #yocto
xantoz has quit [Ping timeout: 260 seconds]
goliath has quit [Quit: SIGSEGV]
zpfvo has joined #yocto
zpfvo has quit [Ping timeout: 260 seconds]
zpfvo has joined #yocto
pgowda_ has quit [Quit: Connection closed for inactivity]
zpfvo has quit [Ping timeout: 260 seconds]
zpfvo has joined #yocto
zyga-mbp has quit [Read error: Connection reset by peer]
zyga-mbp has joined #yocto
zyga-mbp has quit [Read error: Connection reset by peer]
<qschulz>
no it is not necessary to authenticate stuff after the BootROM has authenticated the first part of your chain of trust
<qschulz>
which is probably the U-Boot SPL?
<qschulz>
however, failing to authenticate stuff at any point in the chain of trust obviously breaks this chain of trust and you have an unsecure device, by design
<qschulz>
which is usually not what you want when you want to use secure boot
manuel1985 has joined #yocto
<coldspark29[m]>
Yeah, but it is so horrible to get this to work using NXP's HAB
<qschulz>
It's the equivalent of saying: do I really need to close the windows on the ground floor if I have a locked door with a unique key?
<qschulz>
coldspark29[m]: welcome to vendor BSP world :)
<coldspark29[m]>
Yeah I get the point
<coldspark29[m]>
Just a bit frustrated here
<qschulz>
I can understand
<qschulz>
If it can help you, NXP aren't among the worst companies in terms of BSP :)
<qschulz>
s/isn't/aren't/
<coldspark29[m]>
Yeah, I asked on the forum if it is possible to sign a kernel FIT image as a whole with HAB and they were like "No, it isn't". Great, how is it possible then?
<coldspark29[m]>
Oh you say there are worse. Great ^^
<coldspark29[m]>
For Yocto I am so going mainline uboot
<mckoan>
coldspark29[m]: do you have the link to the answer?
zpfvo has quit [Ping timeout: 268 seconds]
zpfvo has joined #yocto
<coldspark29[m]>
mckoan: Yeah I guess my question was too short
<coldspark29[m]>
Suggesting that HAB can only boot authenticate FIT images when you fiddle with the source code
<coldspark29[m]>
And then you also find things like this
<manuel1985>
qschulz: Whick company makes the best bsps?
<manuel1985>
Cause you said NXP are not amongst the worst.
<manuel1985>
Which company sucks the least?
<JosefHolzmayrThe>
TI and NXP are quite ok-ish, IMHO
<coldspark29[m]>
In my experience TI is king haha
nad has quit [Quit: Client closed]
<coldspark29[m]>
Well but in the TI forum you get an extended answer from one of their engineers within less than a day
scott_ has joined #yocto
<qschulz>
manuel1985: Dare I say the company I work for :p ? No but honestly I had a good time with NXP compared to Allwinner, Amlogic and Qualcomm. Their datasheets are exceptionally good, well-written and complete. I'm fortunate enough to not have had to deal with their engineers too much so can't say if they are better than others in that regard
<manuel1985>
Thanks guys, will keep that in mind.
<hpsy[m]>
does "devtool deploy-target" not deploy the dependencies? I deployed a new application but it is missing the libraries that are in its DEPENDS
Schlumpf has quit [Quit: Client closed]
<JosefHolzmayrThe>
hpsy: nope, it doesn't
<hpsy[m]>
Josef Holzmayr (TheYoctoJester): Ok, thanks.
jatedev has quit [Quit: Client closed]
<coldspark29[m]>
mckoan: Another question: Is it possible to use the normal U-Boot authentication with the uboot-imx fork? If yes, I would just use that
<coldspark29[m]>
* normal U-Boot kernel authentication with, * use that instead of HAB
nad has joined #yocto
scott_ has quit [Ping timeout: 268 seconds]
<kanavin_>
RP: I sorted upstream-status: pending patches by size and slowly working down the list starting from the biggest and skipping toolchain items (gcc/glibc and friends)
<kanavin_>
(submitting) one patch per day keeps the tech debt away
<kanavin_>
I hope we can eliminate at least those over 4K bytes in size, the rest is a very long tail, but easier to maintain due to their smaller sizes hopefully
<rburton>
kanavin_: patch-a-day is really satisfying, i did that a few years ago for some time
<kanavin_>
rburton, yes, it's important to not wear oneself out with this, one patch per day seems like a good amount
<kanavin_>
especially if upstream starts making a fuss :)
<kanavin_>
rburton, also there are patches which are actually not upstreamable
<RP>
kanavin_: I love the idea, I've been trying to do something a little similar although I didn't think of doing it by size, I was going by most patched recipes! :)
<sveinse>
What would it take to implement a scheme where the build logs were preserved alonside the sstate cache? One downside is that once an artifact is fetched from the sstate cache, it is not possible to get its build logs any more, right?
<kanavin_>
RP, looking at strictly the patch sizes, the toolchain is where most of the biggest ones are, I'm sure khem is well aware
<kanavin_>
rburton, e.g. there are pending patches for bdb. or zip :)
<rburton>
yeah they're not going upstream are they
<kanavin_>
I'll mark them as inappropriate when I get to them
<rburton>
time to write a webapp to provide a random pending patch
<RP>
kanavin_: I figured I knew more of the history of the libtool/gcc ones and they've long since needed better documentation and cleanup
<kanavin_>
rburton, if we had a working patchbot, it could also nag people if they add pending patches and <insert criteria>
<kanavin_>
criteria could be: you've exceeded your quota for adding pending patches over the past 24 months ;)
<RP>
kanavin_: patchwork is being worked on and will come back, hopefully soon
<kanavin_>
sveinse, you can easily reproduce the logs, but generally if you want to save them that needs to be done as a separate step after bitbake invocation but before erasing the build dir
Guest81 has quit [Quit: Client closed]
<rburton>
kanavin_: haha harsh
<qschulz>
RP: I hear no complaints for my untested autobuilder patches so I assume they work just fine :)
<RP>
qschulz: I'm hoping you checked the site was updated as expected? :)
<sveinse>
kanavin_: yeah, somehow the logs must be bound to the specific sstate artifact, so when reinstating the sstate artifiacts, it's easy to fetch the right logs
matthiasklein has quit [Quit: Client closed]
<RP>
JaMa: are you looking at the github url issue or should I do that?
<kanavin_>
sveinse, perhaps you could make it a research project: add the logs to the artifact tarball itself
<sveinse>
kanavin_: yeah, I'll need to dig into the sstate generation steps in bb to see if it can be done
<JaMa>
RP: git:// ? I'm fixing it in various places to revive my CI jobs (most of them failed over night)
<JaMa>
it will need to be updated in all the recipes for all OE releases, so it would be nice to get some agreement on ML first
paulg has quit [Ping timeout: 268 seconds]
<RP>
JaMa: I mean the https change for github. I'm thinking I should tweak the script
<qschulz>
RP: yup they look ok, just need this honister patch so the branch is fixed :)
<JaMa>
RP: do you plan to backport explicit branch names to older branches as well?
<JaMa>
RP: because the explicit branches aren't really mandatory, right? while protocol=https is now for github repos
<RP>
JaMa: no, I don't think we should do that. We could use the same script to change older branches though, or we might consider url rewriting. I've long since wanted the fetcher to handle parameter rewrites
<RP>
JaMa: correct. I think we may just want to tweak the fetcher
frieder has joined #yocto
<JaMa>
to adjust protocol transparently? that might work with github where the url is otherwise identical, but when I replaced all git:// with https:// for metadata URLs I got hit by git.yoctoproject.org adding /git in the URL
<RP>
JaMa: we're only talking about github though?
vladest has joined #yocto
<JaMa>
correct, I've just updated it everywhere for consistency
zyga has quit [Ping timeout: 260 seconds]
vladest1 has joined #yocto
vladest has quit [Ping timeout: 268 seconds]
vladest1 is now known as vladest
vladest1 has joined #yocto
frieder has quit [Remote host closed the connection]
vladest has quit [Ping timeout: 260 seconds]
vladest1 is now known as vladest
vladest has quit [Remote host closed the connection]
xmn has quit [Ping timeout: 268 seconds]
paulg has joined #yocto
vladest has joined #yocto
lucaceresoli has joined #yocto
paulg has quit [Ping timeout: 268 seconds]
pgowda_ has joined #yocto
dtometzki has joined #yocto
nad has quit [Quit: Client closed]
scott_ has joined #yocto
xantoz has joined #yocto
paulg has joined #yocto
GNUmoon has quit [Ping timeout: 276 seconds]
prabhakarlad has quit [Quit: Client closed]
paulg has quit [Ping timeout: 260 seconds]
paulg has joined #yocto
marc1 has quit [Ping timeout: 245 seconds]
GNUmoon has joined #yocto
camus has quit [Ping timeout: 260 seconds]
camus has joined #yocto
marc1 has joined #yocto
prabhakarlad has joined #yocto
prabhakarlad has quit [Quit: Client closed]
nad has joined #yocto
nad has quit [Client Quit]
<zeddii>
RP: since 5.15 was tagged for LTS support a couple of days ago, I'll bring it in as a reference in the next few days. We can drop 4.14 in a month or so, and then I'll bring in something newer as well for the spring release (in case you have anyone asking).
<RP>
zeddii: sounds good, thanks for the info! :)
paulg has quit [Ping timeout: 268 seconds]
camus1 has joined #yocto
prabhakarlad has joined #yocto
* zeddii
runs another script update to meta-virt
* zeddii
thanks RP for the automation :D
paulg has joined #yocto
* RP
tries to remember what he was doing before the github emails came in
camus has quit [Ping timeout: 260 seconds]
camus1 is now known as camus
<zeddii>
hah. I read that and realized that I'd do that before getting to 5.15, which is why I messaged to remind myself :D
vermaete has joined #yocto
<vermaete>
If a recipe needs a command (e.g. 'timeout'). That's part of coreutils, but I prefer to use the one for busybox.
<vermaete>
How to add this as a RDEPENDS in the recipe?
<vermaete>
Not possible, I guess...
<RP>
vermaete: it is why we've ended up with things like VIRTUAL-RUNTIME_getopt
<RP>
vermaete: there isn't a good solution here :/
<vermaete>
RP: thanks. More reading to go.
<vermaete>
BTW: i'm missing the mega manual :-(
kroon_ has quit [Read error: Connection reset by peer]
kroon_ has joined #yocto
<JosefHolzmayrThe>
RP: before github mails: drinking. after github mails: more drinking.
<JaMa>
have someone see bitbake-diffsigs failing with "zstd: /*stdin*\: unexpected end of file" ?
<JaMa>
RP: who is working on patchwork? there was some linter submitted for meta-oe repo, maybe these people can find some common ground to integreate it with patch-test or what was the name of the automatic reviews for oe-core patches https://github.com/openembedded/meta-openembedded/pull/465
FredO has joined #yocto
jatedev has joined #yocto
<RP>
JaMa: that sounds like using an old siginfo with the new zstd format?
<RP>
JaMa: I meant halstead was trying to bring the infrastructure back up. The code is a different question, maybe moto-timo?
<JaMa>
old siginfo.. maybe, this sstate-diff directory should be newly created, but maybe it wasn't, will redo the test
<smurray>
the meta-renesas / meta-rcar ones will likely be the ones that are slow to get fixed :/
sakoman has joined #yocto
Granjow has quit [Ping timeout: 260 seconds]
<smurray>
fun! ;)
Granjow has joined #yocto
kayterina has joined #yocto
Guest31 has joined #yocto
<dvorkindmitry>
smurray, so what is the plan? I am using dunfell now. How can I quickly solve the problem?
<smurray>
dvorkindmitry: in your own layers, either change git://github.com to https://github.com or add ;protocol=https. For upstream layers maintainers will need to push updates
<smurray>
dvorkindmitry: for gitsm://github.com it'd need to be adding ;protocol=https, I think
kayterina has quit [Ping timeout: 260 seconds]
rob_w has quit [Quit: Leaving]
kroon_ has quit [Quit: Leaving]
<JaMa>
don't change git:// to https:// in SRC_URI!!! that's the fetcher name which needs to stay git:// just add protocol=https or change it from protocol=git to protocol=https if it's there already, there is migration script from RP on ML which does exactly this
<JaMa>
protocol=ssh is fine
<JaMa>
and if you cannot change the recipes quickly, then use the bitbake changes from RP for bitbake fetcher to do it automagically for you
<smurray>
JaMa: thanks
mvlad has joined #yocto
<Granjow>
Hi there, I have a question about creating a distro layer. I'd like to base it on the Poky distribution but I don't understand which configuration files I have to copy. When copying eta-poky/conf/distro/poky.conf to my distro conf file, bitbake complains about "Uninative selected but not configured correctly", which I see is defined in the meta layer.
<gourve_l>
hi! I have a virtual/recipe problem. I use opkg. I have 2 recipes: recipe-A and recipe-B which provide virtual/recipe. I created an image with recipe-A embedded and deployed it on some machines. Now, I'd like to replace recipe-A with recipe-B on the embedded targets automagically through a package update (opkg update/upgrade). Does anyone have an idea? Because changing PREFERRED_PROVIDER_virtual/recipe seems
<gourve_l>
not enough.
Schlumpf has quit [Quit: Ping timeout (120 seconds)]
<Granjow>
Why is that happening? Do I need to copy other configuration files? Is there a better way (like extending the poky distro conf rather than just copying the files)?
<rburton>
tgamblin: v2 of my imgtool patch sent, thanks for the comprehensive review :)
<tgamblin>
rburton: PR is in for merge to master :)
<rburton>
thanks
<rburton>
looking forward to ripping some pieces out of meta-arm
<mckoan>
gourve_l: not sure that PREFERRED_PROVIDER has an impect on the final virtual package
<mckoan>
*impact
<Granjow>
mckoan: thanks, build is running already again! :) Wouldn't that be a good addition to the docs?
vmeson has quit [Quit: Konversation terminated!]
<gourve_l>
mckoan: in fact, I don't see any virtual package. I see packages A and B providing the virtual/package (description in the file "Packages"), but no virtual package. But on target I can "opkg install --force-reinstall virtual/recipe" and it will reinstall recipe-A
<dvorkindmitry>
what protocol is better to use for private github.com repos access with the key?
<mckoan>
gourve_l: did you call bitbake package-index ?
<qschulz>
dvorkindmitry: ssh?
<dvorkindmitry>
qschulz: so better ssh://github.... ?
vmeson has joined #yocto
<gourve_l>
yes I did
<qschulz>
dvorkindmitry: no, git://github.com/[...];protocol=ssh
<JaMa>
dvorkindmitry: that doesn't work, you need to use protocol=ssh
<dvorkindmitry>
thanks, all!
<qschulz>
git:// is just a way for bitbake to know which fetcher to use
<mckoan>
gourve_l: no clue
<qschulz>
in that case, git
<gourve_l>
mckoan: I have a doubt now, does package-index build the files Packages* only?
<mckoan>
gourve_l: how do you feed the target system packages?
<smurray>
RP: the warning in bitbake might need a little more logic, I'm seeing a lot of: "WARNING: URL: %s uses git protocol which is no longer supported by github. Please change to ;protocol=https in the url."
Xagen has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<vmeson>
err: my bad: Project 'OSTC/OHOS/meta-python-mixin' was moved to 'distro/meta-python-mixin'. Please update any links and bookmarks that may still have the old path.
<vmeson>
agherzan: I take that back, I think I have the right URL...
goliath has quit [Quit: SIGSEGV]
vd has joined #yocto
<frosteyes>
vd: did not see your questions yesterday - regarding nvme.
<agherzan>
We restructured the git instances due to Eclipse Foundation donation.
<agherzan>
vmeson: updated
FredO has joined #yocto
camus has joined #yocto
Granjow has quit [Quit: leaving]
<mckoan>
which piece of code is responsible to call toolchain-scripts class ?
<mckoan>
RP: could you give me some indication to understand the workflow ^^^
<mckoan>
starting from populate_sdk how do you get to toolchain-scripts?
<mckoan>
I can't find a clear sequence of function calls
<moto-timo>
agherzan: the other fields are e.g. "file base" which are awkward because they use %branch% or %path% variables... the easiest thing is to look at another layer and copy-past. And pick a layer with the same web UI front end, so the full URLs are similar pattern.
<agherzan>
That makes sense moto-timo
tre has quit [Remote host closed the connection]
<moto-timo>
agherzan: I updated with the new URL... is the mailing-list/chat link different now too?
<agherzan>
I've updated too :)
<michaelo>
Oops, sorry, I missed the weekly engineering meeting because of the different daylight switching dates between Europe and the USA
<agherzan>
Yes, the mailing list remained the same moto-timo
<agherzan>
For now at least
GNUmoon has quit [Ping timeout: 276 seconds]
<moto-timo>
agherzan: it looks correct now, but if you have any questions feel free to ping me or bluelightning or halstead
<agherzan>
thanks, will do moto-timo
vladest has quit [Ping timeout: 260 seconds]
GNUmoon has joined #yocto
dgriego has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<moto-timo>
agherzan: URL in Contributing section of README.md needs to be updated as well
vladest has joined #yocto
dgriego has joined #yocto
davidinux has quit [Quit: WeeChat 2.8]
goliath has joined #yocto
<agherzan>
good catch moto-timo - I've fixed it
pgowda_ has quit [Quit: Connection closed for inactivity]
GNUmoon has quit [Ping timeout: 276 seconds]
leon-anavi has quit [Quit: Leaving]
GNUmoon has joined #yocto
<RP>
mckoan: I think toolchain-scripts is inherited by recipes which create the files and put them in packages
<RP>
mckoan: or by things like the meta-environment recipe
florian has quit [Quit: Ex-Chat]
kayterina has quit [Remote host closed the connection]
<RP>
smurray: I did break that bb.warn line didn't I? :/
<RP>
smurray: fix pushed
<ecdhe>
Can I have a DEPENDS pin a specific version of a package? I'd like to pin dtc-native at version 1.5.0 but I don't care if other recipes use an older or newer version
<mckoan>
ecdhe: DEPENDS = "dtc-native (>= 1.5.0)"
<ecdhe>
thanks mckoan!
<Saur>
Does that even work for DEPENDS? It is typically used for RDEPENDS...
<Saur>
Normally you rely on making sure the version of the recipe is the one that you want.
<rburton>
ecdhe: that doesn't work
<rburton>
you can't use versions in DEPENDS
<ecdhe>
I could set a preferred provider but I'm really not looking to perform a global override
<ecdhe>
I just need v1.5.0 for this one dtbo
<Saur>
Easiest then is probably to create a dtc-1.5 recipe that you can depend upon for your work.
<zeddii>
_1
<zeddii>
+1 even
zpfvo has quit [Quit: Leaving.]
<mckoan>
rburton: do yiu mean that versions in DEPENDS are no longer supported?
<ecdhe>
Saur: dtc-1.5_1.0.0.bb?
<Saur>
AFAIK, you can specify versions in DEPENDS, but they will be ignored.
<Saur>
ecdhe: dtc-1.5_1.5.0.bb
<ecdhe>
ahh, yes
<Saur>
Since dtc uses a dtc.inc, it should be trivial to do.
<ecdhe>
Just update the SRCREV and the licence check
<rburton>
mckoan: never have been supported
<Saur>
Just copy dtc-<version>.bb and change the SRCREV and LIC_FILES_CHKSUM as appropriate. You will also have to specify the path to dtc.inc as ${COREBASE}/meta/recipes-kernel/dtc/dtc.inc since I assume you will do this in your own layer rather than in meta.
bps2 has quit [Read error: Connection reset by peer]
manuel1985 has quit [Remote host closed the connection]
goliath has quit [Quit: SIGSEGV]
manuel_ has quit [Ping timeout: 268 seconds]
dev1990 has joined #yocto
Xagen has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Xagen has joined #yocto
paulg has quit [Read error: Connection reset by peer]
paulg has joined #yocto
sakoman has quit [Quit: Leaving.]
davidinux has joined #yocto
bps3 has quit [Ping timeout: 268 seconds]
zyga-mbp has joined #yocto
aldrich has joined #yocto
Guest79 has joined #yocto
<aldrich>
Sorry if this has been posted -- is anyone hitting ` The unauthenticated git protocol on port 9418 is no longer supported.` errors in their git:// fetcher? (On dunfell)
zyga-mbp has quit [Client Quit]
Guest31 has quit [Quit: Client closed]
Guest61 has joined #yocto
<JPEW>
aldrich: I think github is dropping support for git protocol, but I don't know if that's the specific error you get from it
<aldrich>
JPEW, most of the recipes using the git:// fetcher are throwing this error. Has anyone hit this yet?
<aldrich>
Just came up (at least for me), our CI/CD was green this morning