cambrian_invader has quit [Ping timeout: 246 seconds]
dkl has quit [Ping timeout: 246 seconds]
dlan has quit [Remote host closed the connection]
cambrian_invader has joined #yocto
Estrella_ has quit [Ping timeout: 258 seconds]
dlan has joined #yocto
davidinux has quit [Ping timeout: 258 seconds]
Estrella_ has joined #yocto
davidinux has joined #yocto
Ablu has quit [Ping timeout: 240 seconds]
Ablu has joined #yocto
starblue has quit [Ping timeout: 258 seconds]
starblue has joined #yocto
camus has joined #yocto
dkl_ has quit [Quit: %quit%]
jclsn has quit [Ping timeout: 258 seconds]
dkl has joined #yocto
jclsn has joined #yocto
Perflosopher has quit [Quit: Ping timeout (120 seconds)]
Perflosopher has joined #yocto
Daanct12 has joined #yocto
Daanct12 has quit [Client Quit]
Danct12 has quit [Read error: Connection reset by peer]
Danct12 has joined #yocto
davidinux has quit [Ping timeout: 246 seconds]
davidinux has joined #yocto
Daanct12 has joined #yocto
Danct12 has quit [Ping timeout: 258 seconds]
geoff_ has quit [Quit: Leaving]
Danct12 has joined #yocto
Daanct12 has quit [Ping timeout: 258 seconds]
OnkelUlla has joined #yocto
Estrella__ has joined #yocto
Estrella___ has joined #yocto
Estrella_ has quit [Ping timeout: 246 seconds]
Estrella has quit [Ping timeout: 244 seconds]
l3s8g has joined #yocto
mvlad has joined #yocto
Saur has quit [Ping timeout: 260 seconds]
vladest has quit [Ping timeout: 240 seconds]
manuel__ has quit [Ping timeout: 240 seconds]
rfuentess has joined #yocto
goliath has joined #yocto
mckoan|away is now known as mckoan
<mckoan>
good morning
rfuentess has quit [Read error: Connection reset by peer]
rfuentess has joined #yocto
mbulut has joined #yocto
vladest has joined #yocto
mbulut has quit [Client Quit]
linfax has joined #yocto
Schlumpf has joined #yocto
Kubu_work has joined #yocto
slimak has joined #yocto
<LetoThe2nd>
yo dudX
luc4 has joined #yocto
zpfvo has joined #yocto
Iwans has joined #yocto
manuel__ has joined #yocto
Iwans has quit [Client Quit]
Daanct12 has joined #yocto
mvlad has quit [Remote host closed the connection]
Iwans has joined #yocto
pabigot has quit [Ping timeout: 240 seconds]
prabhakarlad has joined #yocto
florian has joined #yocto
Iwans has quit [Quit: Client closed]
pabigot has joined #yocto
mvlad has joined #yocto
mvlad has quit [Client Quit]
mvlad has joined #yocto
<mcfrisk>
There is a lot of overlap between MACHINE_FEATURES and DISTRO_FEATURES. Should general purpose SW features check for both to enable support if either one is has the config option, like "alsa", "rtc", "efi" etc. Enabling support is one thing but most SW also works if actual HW doesn't have it.
leon-anavi has joined #yocto
gilles2 has joined #yocto
antoineVM has joined #yocto
gilles2 has quit [Client Quit]
younes has joined #yocto
antoineVM has quit [Quit: Client closed]
<LetoThe2nd>
does RRECOMMENDS allow for non-existing targets? e.g. build the recommendation if a matching provider is there, and skip/ignore if not?
antoineVM has joined #yocto
<mcfrisk>
Is there be a way for layers to register machine and distro features? I'd be interested in an "all yes" build config
zpfvo has quit [Ping timeout: 244 seconds]
manuel_ has joined #yocto
manuel__ has quit [Ping timeout: 244 seconds]
pabigot has quit [Ping timeout: 244 seconds]
zpfvo has joined #yocto
davidinux has quit [Ping timeout: 258 seconds]
davidinux has joined #yocto
pabigot has joined #yocto
tnovotny has joined #yocto
antoineVM has quit [Quit: Client closed]
<rburton>
no
<rburton>
LetoThe2nd: yes
<LetoThe2nd>
rburton: hmm. coworker says stuff was complaining. but now I've hooked him on packageconfig anyways.
<rburton>
packageconfig is probably better
Iwans has joined #yocto
rfuentess has quit [Remote host closed the connection]
rfuentess has joined #yocto
rfuentess has quit [Read error: Connection reset by peer]
rfuentess has joined #yocto
<Iwans>
Hello. Which version of Python package added to RDEPENDS will be installed by pypi?
<Iwans>
My recipe needs httplib2==0.20.4 and recipe in master is 0.22.0 so I wondered if pypi will try to install version available in meta-python or correct one.
<rburton>
pypi isn't used
<rburton>
it will use the version of the recipe that you have in your layers
<Iwans>
even when inheriting pypi class?
<rburton>
yes, look at the class. that's just for fetching the source.
<rburton>
you're actually assuming that pip is used to install, and it isn't
<rburton>
pypi being a website, not an install tool
<Iwans>
I assumed it used pip.
<Iwans>
So if I want to use older version then I have to change SRC_URI in .bbappend file or can I override or somehow specify it in my recipe?
starblue has quit [Ping timeout: 258 seconds]
pasherring has joined #yocto
starblue has joined #yocto
manuel_ has quit [Ping timeout: 248 seconds]
<rburton>
you'l need to provide a recipe for the older version
<rburton>
though i'd be very suspicious of a recipe which needs a specific version of a library
<Iwans>
It's recipe for gsutil, in setup.py in requires they have "httplib2==0.20.4" (everywhere else they use >=)
<rburton>
terrifying, frankly
Guest98 has joined #yocto
<Guest98>
hi,
<Guest98>
I want to replace the file(nvgpu.ko) with my own file. but, i couldn't figure out how to do it in the recipe.
<rburton>
easiest to apply the patch to the kernel sources so it builds the module with the fixes in
<Guest98>
rburton thank you! i will write.
<Guest98>
try*
manuel_ has joined #yocto
younes has quit [Quit: Client closed]
Guest98 has quit [Ping timeout: 245 seconds]
manuel__ has joined #yocto
manuel_ has quit [Ping timeout: 255 seconds]
rber|res has joined #yocto
Guest98 has joined #yocto
zpfvo has quit [Ping timeout: 255 seconds]
CosmicPenguin_ has joined #yocto
diamondman___ has joined #yocto
tleb_ has joined #yocto
raghavgururajan_ has joined #yocto
rhadye_ has joined #yocto
smurray_ has joined #yocto
jonesv_ has joined #yocto
Guest51 has joined #yocto
PhoenixMage has quit [Ping timeout: 260 seconds]
PhoenixMage has joined #yocto
zpfvo has joined #yocto
Guest30 has joined #yocto
diamondman__ has quit [*.net *.split]
CosmicPenguin has quit [*.net *.split]
rhadye has quit [*.net *.split]
smurray has quit [*.net *.split]
lukma has quit [*.net *.split]
fullstop has quit [*.net *.split]
risca has quit [*.net *.split]
jonesv has quit [*.net *.split]
tleb has quit [*.net *.split]
raghavgururajan has quit [*.net *.split]
smurray_ is now known as smurray
diamondman___ is now known as diamondman__
rhadye_ is now known as rhadye
CosmicPenguin_ is now known as CosmicPenguin
jonesv_ is now known as jonesv
tleb_ is now known as tleb
jonesv has quit [Read error: Connection reset by peer]
tleb has quit [Read error: Connection reset by peer]
raghavgururajan_ has quit [Write error: Connection reset by peer]
Guest98 has quit [Ping timeout: 245 seconds]
raghavgururajan has joined #yocto
jonesv has joined #yocto
raghavgururajan has quit [Changing host]
raghavgururajan has joined #yocto
tleb has joined #yocto
lukma has joined #yocto
fullstop has joined #yocto
risca has joined #yocto
Guest51 has quit [Quit: Client closed]
lexano has joined #yocto
tgamblin has joined #yocto
rfuentess has quit [Remote host closed the connection]
rfuentess has joined #yocto
belsirk has joined #yocto
<ernstp>
so the final version of the packges output from the build are generally ${PKGV}-${PKGR}. But I guess this is technically up to the packaging class?
rfuentess has quit [Ping timeout: 255 seconds]
rfuentess has joined #yocto
Daanct12 has quit [Ping timeout: 260 seconds]
belsirk has quit [Ping timeout: 240 seconds]
<RP>
ernstp: PKGV is defined as the final version
<ernstp>
RP: from package_deb.bbclass: fields.append(["Version: %s-%s\n", ['PKGV', 'PKGR']])
<luc4>
Hello! I built an image for my board, but I noticed that the build flags are incorrect (or at least not the best). I would like to build with these flags: -march=armv8-a -mtune=cortex-a53 -mfpu=crypto-neon-fp-armv8. I found this tune: -march=armv8-a -mtune=cortex-a53 -mfpu=crypto-neon-fp-armv8. Is this what I should use? Can I set that I want 32bit and not 64bit?
<ernstp>
luc4: According to the Raspberry Pi foundation, there are limited benefits to using the 64-bit version for the Pi 3 due to the fact that it only supports 1GB of memory; however, with the Pi 4, the 64-bit version should be faster.
<luc4>
ernstp: no, I want 32bit
<luc4>
but I would like armv8a instead of armv7
<ernstp>
luc4: I guess most people just stuck with 32-bit since the release due to that. that's the background anyway! but of course it can be changed
<ernstp>
luc4: set your MACHINE = "raspberrypi3-64"
<luc4>
ernstp: but I'd need 32bit
<ernstp>
RP: I mean that all the 3 standard built in packaging classes set the version to ${PKGV}-${PKGR}
<ernstp>
luc4: read that again!
<luc4>
ernstp: "Machine configuration for the RaspberryPi 3 in 64 bits mode", which part?
<RP>
ernstp: how does the debian package manager parse the Version field though? I mean that I'd suspect PKHR is being injected as a revision where possible
linfax has quit [Ping timeout: 258 seconds]
<ernstp>
luc4: it's I who should read again! ok, armv8 but still 32-bit. I guess you could create your own machine definition somewhere and set the flags exactly like you want
<luc4>
ernstp: I know I can, I did it years ago. I was trying to find a better way, cause I had to fork 3 repos to do it.
<ernstp>
RP: it's not exactly like Yocto so.. for the package "version", that's the version
xmn has joined #yocto
<luc4>
ernstp: ops, sorry, I pasted the wrong text above. I meant that I found this tune: tune-cortexa53-crypto. Should I use this?
<luc4>
ernstp: but I suspect this is 64bit
<ernstp>
RP: perhaps better to start with the "problem". What causes an new package version to be created? A: PKGV and PKGR. And PKGE or course if it's set.
<ernstp>
it creates a new package file with the new version, new file name etc
<JPEW>
No package file found for /usr/lib/libchalk_derive-f4d6e50ab3565138.so in rust; SPDX found: ... usr/lib/libchalk_derive-adea65fd7ba2b9ed.so
<JPEW>
So, the file is there but has a different hash(?) at the end
<RP>
JPEW: right, so there is a mismatch between the files generated and the SPDX manifest being used
<RP>
JPEW: of course rust isn't reproducible
<RP>
so basically we can't use sstate with rust?
Guest10 has joined #yocto
<Guest10>
Hello
<JPEW>
mmm: Setscene task /home/pokybuild/yocto-worker/qemuarm64-armhost/build/meta/recipes-devtools/rust/rust_1.70.0.bb:do_packagedata became valid
<JPEW>
A few lines up
<RP>
JPEW: I think hashequiv won't work with rust
<RP>
perhaps we drop rust from core since nobody seems to be able to fix reproducibility
<JPEW>
I'm a little confused as to why do_package is marked as the same when the file names differ?
<RP>
JPEW: I guess we need to work out exactly how the issue gives rise to this but I'm pretty sure it will be related
JerryM has joined #yocto
<JPEW>
related to what?
<RP>
one input hash will have given two different outputs
<RP>
the sdpx input hash could have then been mapped to that input and it assumed it would match the outputs when it only matches one of them?
<RP>
related to the fact rust isn't reproducible
<JPEW>
mmm, got it. The hash equiv code assumes that if you have one input that produces multiple outputs, the output differences are trivial. In most cases the same files name are produced each time, but rust doesn't do that
<Guest10>
Quick question. Is it possible to create package.ipk from a recipe, but not install it on target rootfs?
<JPEW>
Guest10: Ya, you can do that
<RP>
Guest10: definitely, we do that a lot
<JerryM>
I can set INCOMPATIBLE_LICENSE, but is there a way to set something like COMPATIBLE_LICENSE instead?
Guest62 has joined #yocto
Iwans has quit [Quit: Client closed]
<JPEW>
RP: Definetly worth a chat on the call tomorrow I think
<Guest10>
could you point me in the right direction
<Guest62>
hello need to find libmpi_cxx.so.20 and can't find a recipe that produces it, any clue?
<RP>
JPEW: yes :/
<Guest10>
because i would like to start bitbake my-image-rootfs and it should create .ipk from a recipe and transfer that uninstalled ipk in a certain directory on rootfs
<RP>
Guest10: just generate your ipk as normal but add a custom rootfs function which copies it in?
<Guest62>
that file is in the libopenmpi2.deb on ububtu
<Guest10>
ok, but how to stop that .ipk from installing automatically on rootfs?
<Guest10>
because we managed to transfer ipk to target, but it still installs binaries on target
<RP>
Guest10: only things in IMAGE_INSTALL are actually installed ?
<Guest10>
so i should add IMAGE_INSTALL_remove = " my_package"
mckoan is now known as mckoan|away
<Guest10>
and it shouldn't install on target automatically?
<JPEW>
Guest10: Ya, it needs to not be in IMAGE_INSTALL
<Guest10>
but how will bitbake engine recognize my recipe if it isn't in IMAGE_INSTALL
<JPEW>
Guest10: And instead you'll want the package (not recipe!) in RDEPENDS:${PN} (maybe.... I've not tried this)
<RP>
Guest10: just don't add it. you do need to make sure you have something like do_rootfs[depends] += "myrecipe:do_package_write_ipk"
<JPEW>
^^ or that :)
<RP>
i.e. add a dependency manually
<Guest10>
RP thank you, will try!
<JPEW>
RP: Well, at least we know the problems are related for sure now; Did we add a way to disable HE for a specific recipe?
<RP>
JPEW: perhaps :/
<RP>
JPEW: or we remove rust :}
<JPEW>
RP: No Comment :)
<RP>
JPEW: paulg will be along to tell me not to :)
<Guest49>
Hello - I have some questions about the meta-security/meta-integrity layer (i.e. am trying to build with IMA/EVM) - is this the best place to ask ? There is a security mailing list but it appears to be comprised CVE announcements.
<Guest62>
hello need to find libmpi_cxx.so.20 and can't find a recipe that produces it, any clue?
<RP>
Guest49: there or the yocto list would seem appropriate
<JPEW>
I think it would have to be a global exclusion list, since the list is needed at parts time
<JPEW>
s/parts/parse/
<mcfrisk>
Guest49: drop the question here, there might be answers
<Guest49>
There's a comment in there about signing with CA certs and passing these to the kernel - it referenced a fairly old 3.x kernel until recently and now mentioned 6.1 I think that update is saying it's been tested with 6.1 not that it requires 6.1.
<Guest49>
Later on there's a comment about not being able to sign with CA keys and have no trusted keys on-device using appraisal with EVM and I wanted to check if that was a legacy comment in the doc ?
<Guest10>
one question, in what variable should I add recipes, so it would create IPK, but not install it on target
<Guest10>
from what i knew, if you wanted your recipe to be in bitbake server, you should add it to IMAGE_INSTALL_append
<mcfrisk>
Guest49: likely an old comment there
<Guest49>
I'm aiming at a build I can sign the binaries/.so libraries in (excluding some of the metadata like inode number etc..) where I can pass the CA/certs into the kernel via initrd at boot so hoping that's possible/supported.
<JerryM>
JPEW: I can't tell if that comment was addressed to me.. :(
<JPEW>
JerryM: It was not sorry
<Guest49>
Thanks mcfrisk - I suspected as much - if/when I get something working I'll submit a patch for the docs.
<mcfrisk>
Guest49: I would not exclude dmverity, IMA/EVM may not be fast enough in real life.
<RP>
mcfrisk: did you have any insights on the openssh log btw?
<mcfrisk>
RP: just the details in https://bugzilla.yoctoproject.org/show_bug.cgi?id=15178 so it looks like "sudo: unable to execute /usr/bin/env: Broken pipe" is messing ssh stderr and breaking the tests. No idea still where/why we see that.
<RP>
mcfrisk: ok, fair enough, thanks!
<Guest49>
Thanks mcfrisk
<neverpanic>
Guest10: Just make sure something has that recipe in DEPENDS, that should be enough.
<neverpanic>
Note that if you specifically need .so.20, that might be a very old version
Guest10 has quit [Quit: Client closed]
Guest10 has joined #yocto
otavio has quit [Ping timeout: 258 seconds]
Guest10 has quit [Client Quit]
goliath has quit [Quit: SIGSEGV]
antoineVM has quit [Ping timeout: 245 seconds]
<Guest62>
neverpanic probably openmpi, indeed, found the mpich recipe but it does not produce that file
rber|res has quit [Quit: Leaving]
vladest has joined #yocto
<JerryM>
does anyone have an idea how to achieve something like COMPATIBLE_LICENSE?
<rburton>
JerryM: you basically want to list the allowed licenses instead of listing the disallowed?
amitk has joined #yocto
<rburton>
have a look at base.bbclass for the INCOMPATIBLE_LICENSE logic, it should be fairly simple to write your own class
younes has quit [Quit: Client closed]
luc4 has quit [Ping timeout: 246 seconds]
<JerryM>
rburton: yes, so that I will be notified of potentially 'new' licenses when they ar eincluded
<rburton>
sounds like about ten lines of py
<JerryM>
I'll have a look at the base.bbclass, thanks
<rburton>
break down LICENSE, for each license check if in ALLOWED_LICENSES, if not then warn
<JerryM>
I'll have a go at it
xmn has quit [Quit: ZZZzzz…]
zpfvo has quit [Ping timeout: 258 seconds]
xmn has joined #yocto
rfuentess has quit [Read error: Connection reset by peer]
rfuentess has joined #yocto
l3s8g has joined #yocto
zpfvo has joined #yocto
* paulg
would delete both rust and sstate just to be sure there were no lingering issues
tnovotny has quit [Remote host closed the connection]
otavio has joined #yocto
zpfvo has quit [Remote host closed the connection]
prabhakarlad has quit [Quit: Client closed]
khem has joined #yocto
goliath has joined #yocto
JerryM has quit [Quit: Konversation terminated!]
florian has quit [Quit: Ex-Chat]
rfuentess has quit [Remote host closed the connection]
<Saur>
Bah, JerryM just left. I was going to suggest that we actually have an image bbclass that handles COMPATIBLE_LICENSES. Might be a good idea to upstream it...
<khem>
RP: it will help making case for new SOCs :)
<khem>
do you see the point
<RP>
khem: yes, I like the idea
<RP>
khem: just need someone to write the tooling
<khem>
RP: I built an image with new sstate mirror with CDN that Michael wanted to test, and ran testsuite with it. and I saw the openssh failure but when I did build locally I did not see it. I wonder if its related to a case when built from sstate
<khem>
I think sstate with fast download will be amazing, although your internet provider might send you an email at end of month about you exeeding the data limits :)
<halstead>
If we have a corrupted file that needs to be removed from sstate that is now a much more complicated process.
<khem>
yes, published sstate is almost like a binary feed
<khem>
the sstate in this case is good I think. The testcase is failing which is known so I was trying to narrow it down
<RP>
halstead: it is easier just to invalidate that hash on the build side
<RP>
khem: the openssh failure likely isn't sstate related
<khem>
RP: yeah I think so as well
<RP>
khem: it looks to be a race around pipes. See the bug
<vvn>
what is the correct kernel task to copy a local .dts in the source before build?
leon-anavi has quit [Remote host closed the connection]
<khem>
Configure I would guess
Haxxa has quit [Quit: Haxxa flies away.]
alessioigor has quit [Read error: Connection reset by peer]
l3s8g_ has quit [Remote host closed the connection]
alessioigor has joined #yocto
Haxxa has joined #yocto
alessioigor has quit [Client Quit]
slimak has joined #yocto
Kubu_work has quit [Quit: Leaving.]
Notgnoshi has quit [Ping timeout: 258 seconds]
schtobia has quit [Quit: Bye!]
schtobia has joined #yocto
brrm has quit [Ping timeout: 240 seconds]
brrm has joined #yocto
mvlad has quit [Remote host closed the connection]
olani has quit [Ping timeout: 240 seconds]
Saur has quit [Ping timeout: 255 seconds]
Saur has joined #yocto
olani has joined #yocto
olani- has joined #yocto
vmeson has quit [Quit: Konversation terminated!]
mikeD has joined #yocto
mike_D1 has joined #yocto
<mike_D1>
new to Yocto, going through quick start "https://docs.yoctoproject.org/brief-yoctoprojectqs/index.html". When running the bitbake command, I'm getting this python error:ImportError: cannot import name 'MutableMapping' from 'collections'
<mike_D1>
After looking in the pythons collections library, v3.11.5, MutableMapping, KeysView, ValuesView, ItemsView, are not listed as part of the library.
<mike_D1>
Not sure where to look next or what needs updating?
<mike_D1>
Host system id Debian bookworm.
prabhakarlad has joined #yocto
<RP>
mike_D1: which branch/release are you using? That sounds like it might be an old release
<mike_D1>
Not sure RP, Just trying to follow the instructions on the above web page..
<RP>
mike_D1: which branch did you check out?
<mike_D1>
RP The web page listed nicledore, also I put in zeus for the git checkout command.