<qschulz>
maybe that can help you have less to do backport for your environment support on Rockchip boards?
enok has joined #yocto
Guest62 has joined #yocto
Daanct12 has joined #yocto
Daanct12 has quit [Client Quit]
Daanct12 has joined #yocto
<Guest62>
The dependency resolution for the nativesdk currently (Mickledore) no longer works for me. My image includes a recipe "foo" that has a DEPENDS on "bar". Under Kirkstone I had the build dependencies in the nativesdk. All DEPENDS are missing under Mickledore. Is the problem known? Is there any way to check which packages end up in the SDK? I'm
<Guest62>
slightly overwhelmed trying to isolate the error.
florian has joined #yocto
enok has quit [Ping timeout: 240 seconds]
enok has joined #yocto
<landgraf>
JaMa: the one which runs as part of do_rootfs triggers pseudo mismatch errors. The only thing postinst does is creating symlinks under ~/.config/systemd :-/
albrod has quit [Ping timeout: 250 seconds]
<landgraf>
nvm. found the reason.
alperak has joined #yocto
alperak_ has joined #yocto
alperak has quit [Client Quit]
alperak_ is now known as alperak
mario-go` has quit [Changing host]
mario-go` has joined #yocto
mario-go` is now known as mario-goulart
florian_kc has joined #yocto
enok71 has joined #yocto
enok has quit [Ping timeout: 272 seconds]
enok71 is now known as enok
starblue has quit [Ping timeout: 272 seconds]
starblue has joined #yocto
destmaster has joined #yocto
albrod has joined #yocto
dmoseley has joined #yocto
enok has quit [Ping timeout: 264 seconds]
enok has joined #yocto
pabigot has quit [Remote host closed the connection]
enok has quit [Ping timeout: 246 seconds]
rob_w has quit [Remote host closed the connection]
albrod has quit [Ping timeout: 250 seconds]
pabigot has joined #yocto
enok has joined #yocto
enok71 has joined #yocto
lexano has joined #yocto
enok has quit [Ping timeout: 256 seconds]
enok71 is now known as enok
rfuentess has joined #yocto
tgamblin__ has joined #yocto
tgamblin__ is now known as tgamblin
DvorkinDmitry has joined #yocto
tgamblin_ has quit [Ping timeout: 252 seconds]
<DvorkinDmitry>
I have two machines: x0.conf and x1.conf. in both I have WKS_FILE = "sd-${MACHINE}.${LAYERSERIES_CORENAMES}.wks.in". when building the image running: MACHINE=X bitbake myimg
<DvorkinDmitry>
while building the first image I have executed do_write_wks_template task in my temp/, for second - I have not. Something is badly cached. How handle this?
<DvorkinDmitry>
branch: Kirkstone. Seems bitbake thinks it templated the WKS file already
<DvorkinDmitry>
but the WKS templates are different: sd-x0.kirkstone.wks.in and sd-x1.kirkstone.wks.in
<destmaster>
On do_image_ubifs I'm getting this error: Error: min. I/O unit was not specified (use -h for help)
<destmaster>
these values work fine on building with Dunfell but, porting my image to Kirkstone I'm getting the error
pabigot has quit [Remote host closed the connection]
mbulut has joined #yocto
sev99 has quit [Quit: Client closed]
albrod has joined #yocto
enok has quit [Ping timeout: 264 seconds]
<qschulz>
does anyone know how we're supposed to handle proprietary software with SPDX? e.g. what kind of license identifier we should be using? how does it go with sbom tools in your experience?
Chaser has joined #yocto
<DvorkinDmitry>
qschulz, LICENSE = "Proprietary"
destmaster has quit [Remote host closed the connection]
<qschulz>
DvorkinDmitry: thanks, I should have mentioned that I'm looking for what to put in the source code, not the recipe itself, so it's a bit off-topic for Yocto but I know we have people with a lot of knowledge in SPDX here so wanted to try my luck ;)
tlwoerner_ has joined #yocto
tlwoerner has quit [Remote host closed the connection]
chep has quit [Ping timeout: 268 seconds]
|Xagen has joined #yocto
chep has joined #yocto
leon-anavi has quit [Quit: Leaving]
Xagen has quit [Ping timeout: 255 seconds]
|Xagen has quit [Ping timeout: 264 seconds]
Daanct12 has quit [Quit: WeeChat 4.2.2]
Guest62 has quit [Quit: Client closed]
Guest1337 has joined #yocto
<Guest1337>
Hello. Is there anyway of creating a recipe that fetches an artifact from gitlab repository?
xmn has joined #yocto
Chaser has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
zpfvo has quit [Ping timeout: 264 seconds]
<kanavin>
Guest1337, what's the protocol for the fetching? http
<Guest1337>
this is how i usually fetch my private repos
<kanavin>
that's about correct, so what's the problem?
<Guest1337>
I want to fetch pipeline artifacts, not the whole repository.
<qschulz>
Guest1337: can you actually fetch artifacts through SSH? Outside of Yocto I mean
<kanavin>
if pipeline artifacts are accessible over ssh, then there is a ssh:// fetcher too that you can use in SRC_URI
<Guest1337>
Didnt found anything about it :( I think its possible using a token tho
<kanavin>
ls bitbake/lib/bb/fetch2/
<qschulz>
Guest1337: only Premium and Ultimate Tier for downloading via HTTP with token though
Guest55 has joined #yocto
<qschulz>
Guest1337: but otherwise, put the http link there and give the token and add ';downloadfilename=e=artifacts.tar.gz' after the URL
<qschulz>
Guest1337: also you probably want to look into making sure the token is not part of the sstate-cache so people with different token could reuse the same cache, but no clue how to do it or if it's even possible (after all, it'll modify the SRC_URI value :/)
zpfvo has joined #yocto
Xagen has joined #yocto
<Guest55>
hello
<Guest55>
I am pretty sure I faced some common newbie issue
<Guest55>
I have a recipe which builds libraries and binaries based on Makefile as a source
<Guest55>
The issue is that linkage fails because in recipe-sysroot absent libc runtime file like crti.o crtibeginS.o etc... IN the recipe itself I have DEPENDS += glibc and RDEPENDS:${PN} += libc
<Guest55>
what I am missing? I pass vars CC, CFLAGS etc via EXTRA_OEMAKE
<Guest1337>
qschulz looks like a harder problem than I thought
<qschulz>
Guest55: LDFLAGS as well? Are you sure the Makefile isn't forcibly setting those variables to something else? e.g. using = instead of ?=
<qschulz>
Guest1337: you also have to make sure the job artifact will never be deleted, otherwise you won't be able to rebuild older Yocto builds, and that's usually pretty bad
<Guest55>
I will check, but I am curious why crti.o is abasend in recipe-sysroot directory itself
<qschulz>
Guest55: true, does anything actually build this? e.g. can you find a recipe that install crti.o in the sysroot (a simple find should work?)
<Guest55>
yes, I have a lot of recipes which depends on glibc and contains these files *.o in their own recipe-sysroot
<qschulz>
Guest55: check that the DEPENDS value is actually what you think it is, e.g. with bitbake-getvar -r <your-recipe> DEPENDS
<Guest55>
affter I call "cleanall cleansstate" and rebuild recipe - it workded as expected
<Guest55>
but I call just cleanall many times - and nothing
<qschulz>
what's the exact call you're making?
<Guest55>
it successfully compiled after call cleanall and then cleansstate
<Guest55>
but what is strange for me, previously I called just cleanall(because I thought it call internally cleansstate) and after rebuild the recipe I didn'c runtime glibc dependency
<Guest55>
some magic, thank you anyway for your help
<qschulz>
Guest55: be aware that bitbake -c <task> <recipe> only runs the task for that recipe, and not any of its dependencies
dmoseley has quit [Ping timeout: 240 seconds]
tlwoerner_ has quit [Quit: Leaving]
tlwoerner has joined #yocto
tealbird has joined #yocto
thomas_34 has quit [Ping timeout: 250 seconds]
goliath has quit [Quit: SIGSEGV]
vladest has quit [Ping timeout: 268 seconds]
<tlwoerner>
qschulz: i was side-tracked but finally got around to testing. adding the DM_SQ_ALIAS configs and Ben's patch aren't enough. looks like we'll have to update u-boot, or use the mixin (preference for the mixin)
<qschulz>
tlwoerner: yeah rather use the mixin instead of backporting manually too many patches or keeping our own 2024.04 in meta-rockchip
<qschulz>
tlwoerner: I think moto-timo will be happy to have (more) users of that mixin as well ;)
<moto-timo>
qschulz: yeah, please do not reinvent the wheel over and over again in other layers.
ldywicki has joined #yocto
<tlwoerner>
any idea when u-boot is scheduled to be updated for 2024.04?
<tlwoerner>
oh wait, 2024.04 isn't enough for us
<moto-timo>
What do you mean, the mixin is already at v2024.04
<moto-timo>
well, we don't have an rc1 for the next release yet do we?
<moto-timo>
2024.04 released last week 2024-04-02
<tlwoerner>
moto-timo: upstream u-boot has already released 2024.04, but the recipe in master oecore is still at 2024.01
<moto-timo>
tlwoerner: is master open to new recipes? we haven't finished releasing scarthgap yet!
<qschulz>
tlwoerner: you can always use that mixin as base and add a select few patches
mbulut has quit [Ping timeout: 252 seconds]
<moto-timo>
I'll send the upgrade for master
albrod has quit [Quit: Client closed]
<tlwoerner>
qschulz: for meta-rockchip i could just pick a random commitid on u-boot master and build from there until such a point as u-boot 2024.07 is released
<tlwoerner>
going through and trying to find all the patches required on top of 2024.04 isn't worth it
_sfo has joined #yocto
<tlwoerner>
this way it's 1 build/test cycle, otherwise it could be dozens before i get it right
<moto-timo>
tlwoerner: once we have an -rc1 for 07 I would be willing to put it on the mixin layer. I don't really want to deal with the churn of random commits for a _git recipe
<tlwoerner>
yes, and `next` is too messy
<qschulz>
tlwoerner: up to you, i'm sadly staying on our downstream recipe anyway, don't have the bandwidth right now to check U-Boot for every release/rc :/
Chaser has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
<moto-timo>
upgrade for master sent
<moto-timo>
I won't touch `next` with a ten foot pole unless it is a customer contract and direct request. I don't have that kind of bandwidth.
<moto-timo>
as usual, it looks like wangmy sent the upgrade already.
nerdboy has quit [Ping timeout: 240 seconds]
sakoman has joined #yocto
rfuentess has quit [Remote host closed the connection]
<moto-timo>
"the merge window will close and -rc1 will be released on the 22nd of April"
arielmrmx has quit [Read error: Connection reset by peer]
<moto-timo>
So I can add that to the mixin layer (preferrred version would remain v2024.04) after EOSS.
vladest has joined #yocto
<moto-timo>
the mixin layer should continue to work until master branches and sets ONLY "styhead" in LAYERSERIES_COMPAT
nerdboy has joined #yocto
nerdboy has quit [Changing host]
nerdboy has joined #yocto
<rburton>
ROS WITH A ZEE :)
* zeddii
cannot endorse any zee's
<qschulz>
is there any plan to have a Yocto conference around the time there's the Open Source Summit in Europe?
<rburton>
there's an ELC at OSS
<rburton>
so it would make sense to have a mini yocto day as usual
<qschulz>
rburton: *mini* ELCE :)
<qschulz>
rburton: yup, hence why I'm asking, so I can warm up the management people for my bundled request :)
<qschulz>
FYI, there may be a Media Summit as well
<rburton>
I guess LetoThe2nd is the person to ask but he's at EW right now
<qschulz>
yeah nothing urgent :) just wanted to start the conversation :)
<RP>
qschulz: I did see plans to do something. I don't know how far along they are as there were a number of last minute changes to the event
mbulut_ has quit [Quit: Leaving]
<qschulz>
RP: yeah, stirred a few things in a few communities the announcement of this mini ELCE
enok has quit [Ping timeout: 252 seconds]
florian_kc has quit [Ping timeout: 264 seconds]
applepi has joined #yocto
<applepi>
Is there any chance anyone here is familiar with chrony and using a PPS? I'm working on an embedded Linux board (ARM Xillinx), and I've got a pulse per second (PPS) signal coming in on a GPIO. We do NOT have a whole GPS or anything like that. Just a PPS on one GPIO. I'm building this Linux via yocto, and have the device tree configured to
<applepi>
create a pps-gpio device using that pin. Yocto is configured to build chrony. Once everything is built and loaded, I can verify that the PPS is being *seen* via ppstest - however, if I slightly nudge the frequency to try to verify the clock is being disciplined via the PPS, I cannot make it drift. How can I force a bit of drift to make sure
<applepi>
that this is actually working?
frieder has quit [Remote host closed the connection]
florian has quit [Quit: Ex-Chat]
sev99 has joined #yocto
enok has joined #yocto
pretec has quit [Quit: Leaving]
applepi has quit [Ping timeout: 250 seconds]
dankm has quit [Remote host closed the connection]
dankm has joined #yocto
tlhonmey has joined #yocto
applepi has joined #yocto
Guest29 has joined #yocto
<Guest29>
"wifi" in DISTRO_FEATURES, "wpa-supplicant" and "kernel-modules" in IMAGE_INSTALL, systemd in INIT_MANAGER and DISTRO_FEATURES but still wlan0 interface not working on RPI3B-64 and I'm getting this error from wpa_supplicant@wlan0 service: