<Guest85>
how to add gstreamer1.20 with dunfell fro riscv
Guest85 has quit [Ping timeout: 250 seconds]
goliath has joined #yocto
rfuentess has joined #yocto
linfax has joined #yocto
rber|res has joined #yocto
mckoan|away is now known as mckoan
rob_w has joined #yocto
frieder has joined #yocto
Martin42 has joined #yocto
Kubu_work has joined #yocto
Thorn has quit [Quit: If you think nobody cares, try missing a few payments]
<Martin42>
Good morning community, can someone help me to understand how I compile a package split manually? For example "systemd-journal-remote" from systemd.bb? If I try to bitbake it directly I get this error: "bitbake systemd-journal-remote ERROR: Nothing PROVIDES 'systemd-journal-remote'. Close matches: systemd RPROVIDES systemd-journal-remote"
klugology has joined #yocto
klugology has quit [Client Quit]
zpfvo has joined #yocto
mkazantsev has joined #yocto
ptsneves has joined #yocto
ptsneves has quit [Client Quit]
ptsneves has joined #yocto
ptsneves has quit [Remote host closed the connection]
mkazantsev has quit [Ping timeout: 272 seconds]
<kanavin>
mischief, devtool has no maintainer. If you want to fix things, patches are welcome.
mkazantsev has joined #yocto
mkazantsev has quit [Client Quit]
ptsneves has joined #yocto
<kanavin>
Martin42, bitbake builds recipes, not packages. You need to run bitbake systemd
ptsneves has quit [Client Quit]
ptsneves has joined #yocto
prabhakarlad has joined #yocto
prabhakar has joined #yocto
florian has joined #yocto
ptsneves has quit [Ping timeout: 276 seconds]
<Martin42>
kanavin thanks, but how do I enable that package to be built?
<Xogium>
INIT_MANAGER = "systemd" in your distro config or local.conf if you haven't made your own distro yet
<Xogium>
this will switch to systemd and you should get pretty much all of it including the journald remote tool
<Xogium>
as far as I understand anyway
<kanavin>
I think just 'bitbake systemd' should produce the package. If this doesn't happen, you need to look into log.do_configure/log.do_compile for systemd
<Xogium>
I mean it should but if you want that journal remote tool, then it kind of make sense to use systemd as init manager
Saur_Home has quit [Quit: Client closed]
<Xogium>
I'm not sure if you can just install the remote journal stuff
Saur_Home has joined #yocto
mvlad has joined #yocto
<Martin42>
Xogium thanks, systemd is already enabled and works as init manager in my custom image.
<Xogium>
ah
<Xogium>
hmm, it must be a feature one has to turn on in some way
<Martin42>
kanavin I found my error, you have to enable the PACKAGECONFIG:append = " microhttpd" to enable the journal-remote package.
<kanavin>
yeah, I thought it's something non-default
<Xogium>
yeah, my bad ! ^^
<Xogium>
well, at least I tried to help
<Martin42>
Xogium I didn't read the recipe carefully enough ^^ the packageconfig is not "journal-remote", rather its the microhttpd dependency which triggers the package ^^
<Xogium>
yeah, that makes sense
<Xogium>
I hadn't thought of that either, tbh
<Martin42>
Thanks kanavin and Xogium for your help :-)
<kanavin>
Martin42, just want to stress again reading the configure/compile logs for recipes is an essential yocto skill, otherwise you're going to be puzzled like this all the time
<kanavin>
and systemd source tree would probably also reveal what conditions need to hold true for building that item, particularly meson config files
<derRichard>
is there a good way to get TARGET_SYS for the lib32 multilib variant within a recipe? i need both TARGET_SYS for 64-bits and 32-bits in a recipe.
<Martin42>
kanavin thanks for the recommondations!
<kanavin>
derRichard, it helps if you explain why
<derRichard>
kanavin: i need to set CONFIG_CROSS_COMPILE_COMPAT for a kernel build
<RP>
derRichard: there is all_multilib_tune_values() but I worry about telling you that since it is quite heavy overhead
<derRichard>
looks like i'm the first one that needs arm64's CONFIG_COMPAT_VDSO in yocto :-D
<kanavin>
derRichard, TARGET_SYS can be obtained with ${TARGET_SYS}, no?
<kanavin>
ah, you need them both
<derRichard>
exactly
<derRichard>
so, CONFIG_CROSS_COMPILE has to be TARGET_SYS and CONFIG_CROSS_COMPILE_COMPAT TARGET_SYS(lib32)
JerryM has joined #yocto
<derRichard>
RP: thanks for the hint, all_multilib_tune_values() looks handy :-)
<RP>
derRichard: try not to rely on it too much :/
<RP>
I say this as someone who knows how it actually works
<derRichard>
RP: :-S
<derRichard>
what would be a sane way to get CONFIG_CROSS_COMPILE_COMPAT set?
<RP>
good question, that function call probably does make sense to be honest. I'd just be wary of using it too much
<RP>
MULTILIB_VARIANTS and some other variables are setup by the core multilib classes but whether anything there is usable for your case I'm not sure
<RP>
and that isn't the actual libdir. You could put "lib64" in /usr/lib32 :)
florian_kc has joined #yocto
paulg has joined #yocto
xmn has quit [Quit: ZZZzzz…]
xmn has joined #yocto
Vonter has quit [Ping timeout: 256 seconds]
Vonter has joined #yocto
Vonter has quit [Read error: Connection reset by peer]
<RP>
thanks for the patch, I didn't think we tested that anywhere now
<derRichard>
RP: i kind of expected to get full paths to gcc's via all_multilib_tune_values(d, 'GCC') :-D
<derRichard>
STAGING_BINDIR_TOOLCHAIN looks more useful
<RP>
derRichard: GCC is a bitbake variable and that function expands the variable in each multilib context
<RP>
so yes, if you want the paths...
<derRichard>
in my case all_multilib_tune_values(d, 'GCC') returns an empty string.
<RP>
derRichard: the recipe defines GCC iirc ?
<RP>
so if you don't define it, that would be expected
<derRichard>
hm. there seems to be more magic involved than i have expected
<RP>
derRichard: you took that from the packagegroup-cross-canadian recipe, which has GCC = "gcc-cross-canadian-${TRANSLATED_TARGET_ARCH}"
<RP>
that code then says to expand that variable in each multilib context an return the result
<derRichard>
ah, i should have read what all_multilib_tune_values() actually does. :-S
<RP>
recipes can't normally look into each other's context. That function does some horrible magic to try and get multiple multilib values
alperak has joined #yocto
<JaMa>
RP: maybe github killed it a bit later than announced 2014-01-08 so it started to fail just now
<JaMa>
2024 even
<RP>
JaMa: yes, quite likely, I just found the timing fun :)
<JaMa>
everytime I run selftest something new starts failing :)
<JaMa>
that's why I don't run it so often
<RP>
JaMa: I think in this case you were unlucky! We do test on the AB continually
<JaMa>
yeah I'm not saying that selftest is broken most of the time, just that I break something just by running it :)
Saur_Home has quit [Quit: Client closed]
Saur_Home has joined #yocto
florian_kc has quit [Ping timeout: 268 seconds]
jclsn has quit [Ping timeout: 256 seconds]
jclsn has joined #yocto
lexano has joined #yocto
frieder has quit [Ping timeout: 272 seconds]
<RP>
JaMa: a good skill for QA :)
prabhakarlad has quit [Ping timeout: 250 seconds]
Martin42 has quit [Quit: Client closed]
<JaMa>
anyone familiar with npm and shrinkwrap to discuss a new selftest for npmsw fetcher?
* RP
sends the "delete BBFILE_PRIORITY" patch
<JaMa>
that was quick from crazy idea to usable patch :)
<RP>
JaMa: I'm trying to resist just merging it now :)
<JaMa>
that's crazy -> and the circle is closed :)
leon-anavi has joined #yocto
<RP>
JaMa: what surprises me on this on a bit is that I've yet to have someone say they dislike the idea
<JaMa>
will need to rename our BBFILE_PRIORITY support in mcf to BBLAYERS_POSITION or something :)
<RP>
JaMa: yes, I was wondering about that
<JaMa>
most people who will complain later don't read ML (or at least not as often as us here)
<RP>
I've decided I'm not worrying about them, they're the ones who will be "abusing" this anyway
<JaMa>
but in the end P_V works well when BBFILE_PRIORITY is dropped, so this is much easier to avoid than BBPATH order
<JaMa>
as there is no priority for .bbclass and .inc file other than right order or abusing BBMASK even more (than we have to thanks to evil BSP vendors)
florian has quit [Ping timeout: 264 seconds]
<RP>
JaMa: right, one step at a time. That is a different discussion and not so straight forward
<JaMa>
agreed
<JaMa>
FWIW: I've sent the fixes for OSE WARNINGS and they will be in the next OSE release (not sure when)
<RP>
JaMa: great, thanks!
ykrons has quit [Ping timeout: 240 seconds]
alperak has quit [Quit: Client closed]
florian has joined #yocto
ykrons has joined #yocto
frieder has joined #yocto
mvlad has quit [Read error: Connection reset by peer]
mvlad has joined #yocto
Minvera has joined #yocto
pidge has joined #yocto
ykrons has quit [Ping timeout: 272 seconds]
frieder has quit [Ping timeout: 268 seconds]
thomas_34 has joined #yocto
<thomas_34>
Hi guys, has someone also trouble with pseudo-natvie do_fetch? WARNING: pseudo-native-1.9.0+gitAUTOINC+c9670c27ff-r0 do_fetch: Failed to fetch URL git://git.yoctoproject.org/pseudo;branch=oe-core, attempting MIRRORS if available
<rburton>
try again, and if it continues to fail read the actual log.do_fetch
<thomas_34>
Yes, Sir! :)
<thomas_34>
rburton after 5-8 minutes it runs through. The do_fetch log is pretty long (800 lines). There are a lot of failed attempts. Do you want the log?
alperak has joined #yocto
<rburton>
did it fail again?
<thomas_34>
WARNING: pseudo-native-1.9.0+gitAUTOINC+c9670c27ff-r0 do_fetch: Failed to fetch URL git://git.yoctoproject.org/pseudo;branch=oe-core, attempting MIRRORS if available
<thomas_34>
This is the warning I got at second execute of bitbake
ykrons has joined #yocto
<rburton>
read the log and find the error where it failed. a lot of it is verbose logging of patch resolution and stuff and can be skimmed
<thomas_34>
rburton: Here is the first thing: fatal: unable to connect to git.yoctoproject.org: git.yoctoproject.org[0: 38.129.16.172]: errno=Connection timed out
<thomas_34>
After that it tries to use a bunch of mirrors, until it finds something working.
<rburton>
you need to use : not _ in the SYSTEMD_SERVICE override
<Guest73>
Ah ok oops oversight … so sorry
<Guest73>
So SYSTEMD_SERVICE_${PN} becomes SYSTEMD_SERVICE:${PN}
<Guest73>
What about SYSTEMD_AUTO_ENABLE?
<rburton>
you're enabling globally so it doesn't matter
mvlad has quit [Read error: Connection reset by peer]
mvlad has joined #yocto
frieder has joined #yocto
Martin42 has quit [Quit: Client closed]
Guest73 has quit [Quit: Client closed]
<yocton>
rburton: how long do you usualy give to the NVD to update a CVE before handling the CVE with CVE_STATUS?
<rburton>
yocton: a week before poking them with a sharper stick
* yocton
go buy a stick sharpener
<yocton>
rburton: thanks!
frieder has quit [Ping timeout: 272 seconds]
prabhakar has quit [Ping timeout: 276 seconds]
<RP>
yocton: the cve summary was really nice, thanks
jmd has joined #yocto
<yocton>
RP: I'm glad you like it! :). That's 9 CVEs were we can do something (I'm on it)
<RP>
yocton: I figured there were some issues in there, particularly the qemu ones. thanks :)
Guest73 has joined #yocto
Guest73 has quit [Client Quit]
rob_w has quit [Remote host closed the connection]
jmiehe has joined #yocto
<Ad0>
seems like have work ahead of me working with the new append/remove stuff
<Ad0>
did anyone make a script to change the syntax? :D
<Ad0>
scripts/contrib/convert-overrides.py
<Ad0>
damn it modified all the source files as well...
<landgraf>
JaMa: same here. I've managed to break almost everything during my first week at new job just by running/using in readonly mode. Fixing it now :D
speeder has joined #yocto
simonew has joined #yocto
Xagen has joined #yocto
<simonew>
yocton, I saw your mail on the lists for the CVEs and your plannend actions => I can take some of those. Just say which you started, or I could take CVE-2023-52356(tiff), CVE-2023-38559 ghostscript, binutils with CVE-2023-25584 and glibc on master (CVE-2023-6246)
speeder has quit [Ping timeout: 246 seconds]
<yocton>
simonew: I can gladly give you the glibc update :)
<yocton>
I'm currently spamming the NVD
<simonew>
hihi :) ok so you will take for the NVD and CVE_STATUS?
<simonew>
I will then see what I can get done for stuff were ports are needed
mvlad has quit [Quit: Leaving]
mvlad has joined #yocto
<Ad0>
I get "No recipes in default available for" for I know they exist !
<Ad0>
in my layer: /recipes-bsp/bootfiles/bootfiles.bbappend - in the meta-raspberrypi: meta-raspberrypi/recipes-bsp/bootfiles/rpi-config_git.bb
<Ad0>
oops I see it now lol
<Ad0>
it has been renamed to rpi-bootfiles.bb
<yocton>
Looks like CVE_STATUS will only be necessary if the NVD does not update in the next few (2?) weeks. I'll take pinging the NVD for CVE-2023-6246/glibc (if necessary).
Saur_Home has quit [Quit: Client closed]
Saur_Home has joined #yocto
<simonew>
For glibc/ CVE-2023-6246 a fix on master is not needed as we have 2.39 on master since 5 hours. Should we update dunfell?
Dr_Who has joined #yocto
speeder has joined #yocto
<simonew>
Ok dunfell is not affected as well, so glibc CVE requires no further action.
<simonew>
yocton, I would then check tiff now
otavio has quit [Ping timeout: 276 seconds]
speeder has quit [Ping timeout: 260 seconds]
<yocton>
simonew: okay. I still have a pair of NVD mail to send
goliath has quit [Quit: SIGSEGV]
<yocton>
simonew: I'll try the qemu backport for CVE-2023-6693
jmiehe has quit [Quit: jmiehe]
<simonew>
yocton, ok then I believe besides linux-yocto and the other qemu points all is already splitted? Most seem issues with NVD... CVE_STATUS one can set mid feb if NVD does not update
<yocton>
simonew: did you do something for tiff?
* JaMa
got first build failure due to BBFILE_PRIORITY but is still happy to add P_V to avoid it
<simonew>
yocton, yeah test is ongoing, patch comes if ok
<simonew>
The rest of the issues have no fix (merged upstream). About linux-yocto I do not know how the approach would be
<yocton>
simonew: yeah, that's it for today :)
<yocton>
for linux-yocto the approach is usualy to wait until this is fixed on the stable branches we use
<simonew>
yocton, ok then let's wait. We can do so same next week, if wanted
<yocton>
Once this is fixed, it is picked up by a script made by Ross that update CVE_STATUS for them (We pretty much have given up on NVD having a clean database for kernel)
rfuentess has quit [Read error: Connection reset by peer]
otavio has joined #yocto
linfax has quit [Ping timeout: 260 seconds]
eicke has joined #yocto
<yocton>
simonew: CVE-2023-6693/qemu fix has already been backported by upstream (<3), I've sent the NVD change request :). And that's it for today. (I most likely won't be able to do the same next week but you never know...)
<yocton>
simonew: I'll wait for your tiff patch and send an update on list. Thank you :-)
eicke has quit [Client Quit]
sakman has quit [Ping timeout: 264 seconds]
eicke_ has joined #yocto
<simonew>
yocton: Ok, I can take over the list as you did today for master next week. The rest we'll see
<simonew>
Aaand I have a random question now: is anyone actually running syzkaller on a yocto based distro. I see there is a recipe for it in meta-openembedded, are there any public instances for it?
manuel1985 has joined #yocto
prabhakar has joined #yocto
prabhakarlad has joined #yocto
manuel1985 has quit [Client Quit]
jmd has left #yocto [ERC 5.4 (IRC client for GNU Emacs 28.2)]
prabhakarlad has quit [Ping timeout: 250 seconds]
eicke_ has quit [Ping timeout: 268 seconds]
jmiehe has joined #yocto
simonew has quit [Ping timeout: 255 seconds]
jmiehe has quit [Quit: jmiehe]
mckoan is now known as mckoan|away
sakman has joined #yocto
benkard has joined #yocto
prabhakarlad has joined #yocto
mulk has quit [Ping timeout: 276 seconds]
benkard is now known as mulk
vladest has quit [Remote host closed the connection]
<RP>
dl9pf: what might be interesting is to do a "bitbake XXX -S none" save locked-sigs.inc, remove the priorities, then run it again and compare the locked-sigs.inc
<RP>
dl9pf: that would say which recipes actually changed hash as a result of the change
<RP>
where XXX is world or something
<Ad0>
do I have to do do_install:append:machine now or does do_install:append_machine still work in kirkstone ?
<JaMa>
RP: FWIW: I've found 3 recipes which used to have newer PV in our layers, but now they are older and not easy to upgrade (but easy to continue using the older one with P_V) and now getting similar issues with .bbappend ordering as dl9pf reported (causing real build issues)
<Ad0>
it seems like I have to use : on machine as well
<Ad0>
"A convert-variable-renames.py script is provided to convert your recipes and configuration, and also warns you about the use of problematic words. The script performs changes and you need to review them before committing. An example warning looks like:
<JaMa>
and convert-variable-renames.py is something different
<Ad0>
ok
<Ad0>
I think I will just do it by hand but it can lead to huge problems
jmd has quit [Remote host closed the connection]
<JaMa>
the script is very good start, but expect some false-positives there as well, so better to commit the changes from the script in separate commit and then adjust by manual changes on top
<JaMa>
so that you can re-run the script as many times as needed easily
florian_kc has quit [Ping timeout: 272 seconds]
<Ad0>
JaMa, I went through it by hand , luckily my layer isn't huge
jpuhlman- has quit [Ping timeout: 252 seconds]
<Ad0>
seems to be improvements in optimizations for bitbake though! like it doesn't fetch and configure the kernel each time i do a small change
goliath has joined #yocto
jpuhlman has joined #yocto
<Ad0>
dhcp-server is gone from kirkstone, omg I don't need this right now haha
vladest has quit [Quit: vladest]
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
florian_kc has joined #yocto
<gmorell>
W 2
prabhakarlad has quit [Ping timeout: 250 seconds]
Saur_Home has quit [Quit: Client closed]
Saur_Home has joined #yocto
vladest has joined #yocto
Haxxa has quit [Quit: Haxxa flies away.]
Saur_Home has quit [Client Quit]
Saur_Home has joined #yocto
Haxxa has joined #yocto
Vonter has quit [Ping timeout: 272 seconds]
Vonter has joined #yocto
JerryM has quit [Quit: Konversation terminated!]
simonew has joined #yocto
jsbronder has quit [Quit: WeeChat 3.8]
jsbronder has joined #yocto
<alimon>
RP, rburton: hi, :), i sent some small patches for ptest-runner to fix small security checks
<alimon>
who is handling integration these days?,
Vonter has quit [Ping timeout: 272 seconds]
Saur_Home has quit [Quit: Client closed]
Vonter has joined #yocto
Saur_Home has joined #yocto
jmd has joined #yocto
Kubu_work has joined #yocto
leon-anavi has quit [Quit: Leaving]
sakman1 has joined #yocto
yudjinn has joined #yocto
<yudjinn>
hello, is there a good way to force a recipe to use a specific MACHINE?
<yudjinn>
I have one recipe that needs a different MACHINE set, and it'd be nice in my CI to build them all at the same time
sakman has quit [Ping timeout: 272 seconds]
sakman1 is now known as sakman
Guest-fermion has joined #yocto
<Guest-fermion>
Hello, we have to create images for different product variants. From a HW point of view they are basically all compatible but the SW should behave in different ways
<Guest-fermion>
Im leaning towards a run time management of this differences
<Guest-fermion>
Is there a traditional way this is handled in Yocto projects_
<Guest-fermion>
?
<JaMa>
runtime management (or at least separate configuration) is much better than building a lot of stuff MACHINE_ARCH and then building most of the image separately for each MACHINE just because they should behave slightly differently
<JaMa>
if you can have all the functionality on all the targets, then single binary which runs on multiple products is best
<Guest-fermion>
I agree with you JaMa, I think the added cost of handling the extra complexity of different releases is more
<JaMa>
if you cannot e.g. have some extra features from higher-end product on lower-end because someone will hack it to run on lower-end, then I would try to get away with different images (having different packages for each target) but still building most of the stuff just once
<JaMa>
and only if your developers cannot figure out how to do either of these, then you can add #ifdefs in code and burn in hell (like we do) :)
Saur_Home has quit [Quit: Client closed]
Saur_Home has joined #yocto
<Guest-fermion>
:)
<neverpanic>
Or give that particular case some extra thought and bind the functionality to a hardware security module that does a cryptographic check before it enables functionality, but that's less safe and can be bypassed, too.
vladest has quit [Remote host closed the connection]
vladest has joined #yocto
<Guest-fermion>
I'm considering using ConditionPathExists on System D. At least for development builds
<Guest-fermion>
But I have not experience this before
simonew has quit [Quit: Konversation terminated!]
<Guest-fermion>
Thanks for your comments :)
Guest-fermion24 has joined #yocto
<manuel_>
This is not yocto-related but I think of all the IRC channels I'm in, this is the one that could give me an answer most likely:
<manuel_>
In `htop`, the bars at the top show a continous load on each of my 4 cores of 25% approx
<manuel_>
Yet in cpu-load sorted list below, the cpu-heaviest process has only very little load
<manuel_>
I mean, the math doesn't add up
alessioigor has quit [Ping timeout: 264 seconds]
mischief has quit [Ping timeout: 240 seconds]
<manuel_>
I can't see any processes that are causing the load the top bars exhibit
mischief has joined #yocto
<rburton>
alimon: do you want to handle the integration? :)
sakman1 has joined #yocto
<neverpanic>
manuel_: do you have kernel threads visible in htop? might be cpu usage by the kernel.
<manuel_>
neverpanic, Don't think so. The bars are each approx 50% green (= 'normal', whatever that means) and red ('kernel')
sakman has quit [Ping timeout: 252 seconds]
sakman1 is now known as sakman
<manuel_>
neverpanic: Displaying kernel threads now. Still doesn't add up.
<manuel_>
I'm even running `htop` with root privilegues
amitk has quit [Ping timeout: 264 seconds]
<manuel_>
Oh it is a kernel thread, you're right.
Vonter has quit [Ping timeout: 272 seconds]
Vonter has joined #yocto
goliath has quit [Quit: SIGSEGV]
GNUmoon has quit [Remote host closed the connection]
GNUmoon has joined #yocto
Guest-fermion24 has quit [Ping timeout: 250 seconds]
Guest-fermion has quit [Ping timeout: 250 seconds]
olani- has joined #yocto
Xagen has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
sakman1 has joined #yocto
sakman has quit [Ping timeout: 272 seconds]
sakman1 is now known as sakman
sakman has quit [Ping timeout: 272 seconds]
Kubu_work has quit [Quit: Leaving.]
ykrons has quit [Ping timeout: 276 seconds]
<RP>
"Expat 2.6.0 released, includes security fixes" - anyone fancy sending an upgrade patch?
<RP>
they don't look too serious but
<tgamblin>
RP: looking at it. Seems to be blowing up on do_install_ptest_base
* tgamblin
delves
chep has quit [Ping timeout: 256 seconds]
ykrons has joined #yocto
mvlad has quit [Remote host closed the connection]
chep has joined #yocto
<RP>
tgamblin: thanks! Feel free to leave a message on how you get on