bonalais has quit [Quit: Connection closed for inactivity]
otavio has quit [Remote host closed the connection]
<tlwoerner>
RP: good! an go ahead and remove recipes-core/initscripts/initscripts-1.0/GPLv2.patch and recipes-kernel/modutils-initscripts/files/PD.patch too ;-)
jclsn1007 has joined #yocto
otavio has joined #yocto
lowfi has joined #yocto
ecdhe has quit [Read error: Connection reset by peer]
ecdhe has joined #yocto
neverpanic has quit [Quit: reboot]
neverpanic has joined #yocto
jclsn1007 has quit [Ping timeout: 260 seconds]
jclsn1007 has joined #yocto
jclsn1007 has quit [Ping timeout: 272 seconds]
geoff_ has quit [Ping timeout: 246 seconds]
jsbronder has quit [Quit: WeeChat 3.3]
jclsn1007 has joined #yocto
camus has joined #yocto
jsbronder has joined #yocto
jclsn1007 has quit [Ping timeout: 240 seconds]
jclsn1007 has joined #yocto
sakoman has quit [Quit: Leaving.]
jclsn1007 has quit [Ping timeout: 272 seconds]
jclsn1007 has joined #yocto
jclsn1007 has quit [Ping timeout: 246 seconds]
sakoman has joined #yocto
jclsn1007 has joined #yocto
jclsn1007 has quit [Ping timeout: 240 seconds]
jclsn1007 has joined #yocto
jclsn1007 has quit [Ping timeout: 246 seconds]
jclsn1007 has joined #yocto
bonalais has joined #yocto
lowfi has quit [Quit: Leaving]
sakoman has quit [Quit: Leaving.]
lowfi has joined #yocto
xmn has quit [Ping timeout: 256 seconds]
amitk has joined #yocto
alessioigor has joined #yocto
alessioigor has quit [Client Quit]
kroon has joined #yocto
Circuitsoft has joined #yocto
lowfi has quit [Quit: Leaving]
prabhakarlad has joined #yocto
mckoan|away is now known as mckoan
Schlumpf has joined #yocto
bonalais has quit [Quit: Connection closed for inactivity]
mvlad has joined #yocto
tnovotny has joined #yocto
Wouter0100 has quit [Read error: Connection reset by peer]
Wouter0100 has joined #yocto
selff has joined #yocto
<selff>
hello everyone, have a nice day. i asked a question about ap and wpa yesterday, but i couldnt find an answer. im sharing it again today, maybe someone can help.
<selff>
i want to use both wpa and ap in my image. when i run hostapd service in runtime, it switches to AP mode without any problems and read the "hostapd.network" settings. when i want switch to wpa, i follow these steps:
<selff>
enable "wpa_supplicant@wlan0" and disable "hostapd", reboot. when i run the "wpa_supplicant@wlan0" service, it does not switch to wpa mode.
<selff>
even though hostapd is closed, wpa uses the "hostapd.network" file which is contain ap ip etc. idk why but wpa is reading "hostapd.network" instead of "wlan.network".
<selff>
in short wpa_supplicant@wlan0 service reads hostapd.network instead of wlan.network.
dev1990 has joined #yocto
dacav has quit [Ping timeout: 256 seconds]
camus has quit [Read error: Connection reset by peer]
<LetoThe2nd>
need to decide on the correct permutation of these: "work on u-boot for an iMX7 board", "drink", "curse each and everything". suggestions?
janvermaete[m] has quit [Quit: You have been kicked for being idle]
gsalazar_ has joined #yocto
gsalazar_ has quit [Remote host closed the connection]
gsalazar has quit [Ping timeout: 272 seconds]
tomzy has joined #yocto
tomzy has quit [Client Quit]
tomzy72 has joined #yocto
tomzy72 has quit [Client Quit]
tomzy has joined #yocto
tomzy has quit [Client Quit]
mojuser has joined #yocto
bonalais has joined #yocto
ardo has quit [Read error: Connection reset by peer]
ardo has joined #yocto
arturkow has joined #yocto
arturkow has quit [Client Quit]
ardo has quit [Read error: Connection reset by peer]
bonalais has quit []
bonalais has joined #yocto
ardo has joined #yocto
goliath has joined #yocto
<LetoThe2nd>
what flag does wic need in order to create an empty FS?
<LetoThe2nd>
something like --fixed-size 50M --fstype=ext4 ?
dtometzki has joined #yocto
selff has quit [Quit: Client closed]
amitk has quit [Ping timeout: 260 seconds]
prabhakarlad has quit [Ping timeout: 250 seconds]
kroon has quit [Ping timeout: 260 seconds]
kroon has joined #yocto
<LetoThe2nd>
have you ever seen a situation where u-boot , specifically u-boot-fslc happily builds, no errors, no nothing, but no artifacts are generated in the Yocto build? Manually building outside works nicely
amitk has joined #yocto
prabhakarlad has joined #yocto
<qschulz>
LetoThe2nd: wdym by "no artifacts are generated"?
<qschulz>
nothing in the deploy directory or nothing in the build directory?
<LetoThe2nd>
qschulz: the former, primarily. still investigating.
<qschulz>
LetoThe2nd: are you sure there's a do_deploy task?
<qschulz>
is the deploy task called?
arturkow has joined #yocto
<LetoThe2nd>
will try to find out
arturkow has quit [Quit: Client closed]
arturkow has joined #yocto
arturkow has quit [Client Quit]
arturkow has joined #yocto
arturkow has quit [Client Quit]
<LetoThe2nd>
what do people buy for personal builders these days? still threadrippers?
<rburton>
most likely the best bang-per-buck still
<rburton>
but you know you want to get a mac studio and boot asahi on it to benchmark that ;)
<LetoThe2nd>
k
<LetoThe2nd>
nope.
<rburton>
bah
<LetoThe2nd>
been using an old phenom x2 at the moment, but that really needs upgrading
<LetoThe2nd>
1) looked at prices. 2) decided it will probably be just a run of the mill ryzen
<rburton>
yeah prices are not great
<qschulz>
LetoThe2nd: if you're going for overkill, I've read that the new i9 12th gen are pretty good
<LetoThe2nd>
qschulz: the overkill days are gone, i'm back to common sense ;-)
<qschulz>
LetoThe2nd: then probably Ryzen product line which should have more cores than Intel at similar price points
<qschulz>
(note that Intel MB are notably more expensive than Ryzen compatible ones for some reason)
camus has quit [Ping timeout: 260 seconds]
<qschulz>
LetoThe2nd: though note that most Ryzen CPUs don't have integrated GPU (the G and GE product line does have it though, AMD calls them APUs)
<LetoThe2nd>
qschulz: yeah, 5700g sounds like a good one to get.
<qschulz>
so either go for G product line (last letter in the CPU product ID) or think about buying a small graphics card
camus1 is now known as camus
<LetoThe2nd>
I even have one lying around here. but that means more hw, e.g. more power consumption.
<qschulz>
LetoThe2nd: I know I know, been looking for CPUs to replace my old server at home but don't want to increase the power consumption really..
<qschulz>
quite a difficult task to find 35W CPUs with integrated graphics today :)
<rburton>
get a mac mini and boot asahi on it ;)
<rburton>
i wonder if anyone makes thunderbolt sata docks that take four disks
<qschulz>
rburton: no thank you :)
<qschulz>
don't have time to debug things on my server, it needs to work :)
<qschulz>
and I had a Mac mini at work running Linux (intel based, old one), graphics glitches every now and then
<rburton>
well if its a server it will be headless, right? :)
<qschulz>
rburton: well.. no :p
<qschulz>
want to replace my RPi running Kodi/LibreElec with the server
<qschulz>
and also hope to be able to replace my desktop (which I very rarely use) with it
<qschulz>
but I've yet to understand if it is possible and how to share GPU+VPU among different containers/KVM
<qschulz>
and now the 5600GE I'm after is impossible to find
<qschulz>
rburton: is it you who has a microserver gen8 too?
<qschulz>
I remember reading a tweet, either you or paul
<qschulz>
and looking for ARM based replacement
<qschulz>
well.. maybe #yocto isn't the best place for this kind of discussion but it's rather calm today :)
<LetoThe2nd>
everybody is busy day drinking and preparing bad jokes for tomorrow.
kroon has quit [Quit: Leaving]
MrSaturn has joined #yocto
<MrSaturn>
silly question: If I do a "devtool build" where does the binary go?
<qschulz>
MrSaturn: ${B}
vladest has quit [Quit: vladest]
vladest has joined #yocto
<MrSaturn>
Alright, odd. I think something isn't working quite right in the recipe.
<MrSaturn>
Is there a way I can make this work with both bitbake and devtool? https://pastebin.com/xPgS5PGc When I do a devtool modify, then a bitbake build it can not find the logo.
<qschulz>
rburton: the only Aarch64 consumer board that was "suitable" for NAS was the Helios64 IIRC, but they shutdown last year
<MrSaturn>
rburton: The layer already has a 'SRC_URI += "file://company.bmp"' line. It looks like that task is move the logo to a specific location. This isn't my layer, so I am guessing at intention.
<MrSaturn>
In devtool, "company.bmp" is in a directory called "oe-local-files"
ar__ has joined #yocto
codavi has joined #yocto
ar__ has quit [Ping timeout: 250 seconds]
xmn has joined #yocto
sakoman has joined #yocto
<rburton>
MrSaturn: someone didn't know that you can tell the fetcher where to put a file, that's all
<rburton>
a new task is overkill
<LetoThe2nd>
qschulz: the u-boot boot is weird. builddir is empty other than the .scmversion file.
<RP>
JPEW: there is also an asyncio event loop issue in there :(
<RP>
kergoth: I mean the KeyError re: sys.modules
<kergoth>
I'm wondering if sys.modules and sys.path are actually just dicts or another type, if assignment could cause an issue vs clearing and updating the dict
<kergoth>
RP: ^
<kergoth>
don't really know
gsalazar has joined #yocto
<RP>
kergoth: Yes, that is what I'm wondering too. I'm pretty sure sys.path is just a list but sys.modules' contents might not copy well :/
<kergoth>
Module import handling is voodoo to me, I should probably read up on that more
Schlumpf has quit [Quit: Client closed]
<kergoth>
I'd try clearing and updating sys.modules and see if that changes the behavior
<kergoth>
I do wonder how these things are affected by multiconfig builds, since it's global state set by metadata which isn't global
<kergoth>
guessing layers wouldn't change with that so probably fine
dvorkindmitry has joined #yocto
<dvorkindmitry>
Is there a way to install SYSTEMD_SERVICE machine-specific, like SYSTEMD_SERVICE:${PN}:myarch = "ssss.service" ?
<qschulz>
dvorkindmitry: if this does not work you can always do SYSTEMD_SERVICE:${PN} = "${SSSS_SERVICE}" and have SSSS_SERVICE:myarch = "ssss.service"
<kergoth>
overrides work fine with any variable. they don't work on flags, but variables are fine
<kergoth>
Hmm when will kirkstone be branching? Wonderinga bout submitting stuff that doesn't belong in the release
<dvorkindmitry>
qschulz, kergoth, thank you to both of you. looks like it work
tnovotny has quit [Remote host closed the connection]
<RP>
kergoth: not sure I want to think about multiconfig in this context!
<dvorkindmitry>
why machine-specific SRC_URI should be written like SRC_URI:append:mymachine, while SYSTEMD_SERVICE:${PN}:mymachine ?
<smurray>
the latter isn't an append?
<smurray>
i.e. it overrides the definition. If you did that for SRC_URI you'd lose the presumably non-machine-specific default value
<manuel1985>
'Subprocess output:x86_64-poky-linux-objcopy: Unable to recognise the format of the input file' <--- how can I skip this check? The file in question is a downloaded rust executable
<kergoth>
RP: looks reasonable
<kergoth>
I wonder if we couldn't subclass and use importlib.machinery.PathFinder to search our own bbpath-based-path directly rather than mucking about with sys.path. I also wonder if we could change sys.modules or import behavior in our python eval so it doesn't persist in bitbake's global sys.path and sys.modules.
<kergoth>
long term
<RP>
kergoth: yes, I think we do need to improve this longer term, probably with layer.conf syntax too
* RP
notes kirkstone branches are now available
<RP>
they're not diverging yet but available
<kergoth>
ah, okay, so no need to hold off on post-kirkstone submissions?
<RP>
kergoth: just make them clearly not for kirkstone
<amahnui[m]>
Hello rburton: I have set up freebsd tho I never successfully set up a de but I will begin setting up my coding environment while trying to set it up the de
<MrSaturn>
Sorry about the accidental paste. Just to make sure I understand: to fetch a file and put it in a specfic location, you do "SRC_URI +=..." then you need to put something in do_unpack?
<rfs613>
MrSaturn: only if you have some very esoteric unpacking needs. Normally the existing yocto handles all formats you're likely to encounter.
<MrSaturn>
rfs613: I have a file that I need to put in ${S}/tools/logos. Can this be accomplished without a do_unpack_append?
<rfs613>
MrSaturn: I think you may be confusing the unpack with the install
<MrSaturn>
rfs613: Perhaps. The file needs to be inplace before compilation
<rburton>
MrSaturn: yes it can. i pointed you at the precise bit of the documetation that tells you how earlier today
<rburton>
the default location is WORKDIR
<rburton>
but you can change that, to ${S}/tools/logos
<MrSaturn>
rburton: oh shoot. I think I understand. I had to read it a third time. SRC_URI += "file://mfg.bmp;subdir=${S}/tools/logos"
<rburton>
yes
<MrSaturn>
Sorry I am daft. I missed that it was a parameter in the URL
<MrSaturn>
Holy cow that worked. Let's see if devtool does the trick now.
<MrSaturn>
Ok, this is madness. I am going to reach out to them and ask them their workflow.
<MrSaturn>
Now when I do a devtool build I get a "subdir argument isn't a subdirectory of unpack root"
<amahnui[m]>
<amahnui[m]> "Hello rburton: I have set up..." <- Hello rburton: please I can't find the issue tracker for yocto project
<rburton>
bugzilla.yoctoproject.org
<amahnui[m]>
rburton: Thank you
ferlzc has joined #yocto
<ferlzc>
Hi, I created a recipe that's builds a library. I compile the library on the do_compile() and afterward I installed it using the following:do_install () {
<ferlzc>
the other one is: I need to use this library in another recipe, but during the makefile I can seem to find the .h that I link for
<rburton>
did you DEPEND on ulf or whatever you named the library recipe?
<ferlzc>
for some reason the only way I found .h was using -I${TMPDIR}/sysroots-components/core2-64/lib-omneulf-client/usr/include, which is not a good solution
<rburton>
yeah don't do that
<rburton>
if you DEPENDed on ulf then its in the recipe's private sysroot
<ferlzc>
I did DEPEND the library on the new recipe
<rburton>
are you manually compiling the app?
<rburton>
because you're probably driving the compiler wrong
<ferlzc>
no I'm patching an Makefile
<rburton>
even worse: the makefile is probably terrible
<rburton>
makefiles are typically terrible and wrong
<rburton>
specifically, its probably ignoring LDFLAGS from the environment
<rburton>
writing a proper makefile is hard. people think its easy, hack one up, and then wonder why people building distributions get annoyed at the makefiles.
<ferlzc>
i'm patching those /opt/omne/lib which is bad
<rburton>
I'm assuming it doesn't define COMPILE.cc itself?
<ferlzc>
can you tell me more on how not to ignore the LDFLAGS on this Makefile ?
<rburton>
well, does it define COMPILE.cc or does it use the default?
<ferlzc>
it uses the default
<rburton>
the default COMPILE.cc does respect CXX CXXFLAGS CPPFLAGS so it *should* work
<rburton>
read the tmp/****/recipename/temp/log.do_compile to see what compiler flags are being passed.
<rburton>
it should be passing --sysroot pointing at the recipe sysroot for the recipe, which should contain an include/ulf.h
<rburton>
its its now quarter to 8 so im going to see my kids. hope someone else can help when you have more info. always hard to debug secret recipes though.
<khem>
OK is there some hard define for CXX in makefile ?
<rburton>
oh do you need EXTRA_OEMAKE = "-e"?
<rburton>
to force it to pull from the environment
<rburton>
always forget that we don't force make to do that anymore
<rburton>
its only been what, five years
bonalais has quit [Quit: Connection closed for inactivity]
<ferlzc>
yes there is some hard define for CXX on the file, like so:CC=gcc
<ferlzc>
CCC=g++
<ferlzc>
CXX=g++
<rfs613>
sakoman: available for a quick chat about CVE backports in dunfell?
<sakoman>
rfs613: yes
<rfs613>
great! so I notice there are a lot (92 according to last metrics email)
<rfs613>
quite a few of them also exist in other branches
<rfs613>
do we have a requirement to fix them in newer branches before they can go in dunfell?
<rfs613>
I'm finding it challenging to switch between branches, to verify a fix works in all of them
<sakoman>
There is a requirement that fixes go first to master before dunfell and the other branches
<sakoman>
Then it is up to the branch maintainers to take them if possible
<sakoman>
In reality, with different versions in the various branches it is pretty rare to be able to cherry-pick
<khem>
master is must as sakoman says
<sakoman>
When kirkstone is out and I am maintaining two LTS branches I'll probably try really hard to get the fixes in both after master
<khem>
we need to ensure its either fixed in master via virtue of new version being in master or apply the patch to master and ask for a backport to related branches
<rfs613>
indeed, but the effort of finding the patch, applying it, adding the approprate tags etc, sort of makes sense to try and do it for all branches. Otherwise I end up re-doign the same work again.
<khem>
yeah LTSs would matter
<sakoman>
But the reality is that many CVEs only exist in older branches and not in master since they have more recent package versions
<sakoman>
So more often than not CVE fixes for dunell don't have a master fix since they don't exist there
<zeddii>
That's always fine as well. AS long as someone shows the version in master doesn't have a given problem, a cherry-pick/patch to an older branch is fine.
<sakoman>
rfs613: I and other maintainers would love to see you do the patches for all currently supported branches
<sakoman>
But please test that the patches not only apply but build in those older branches :-)
<rfs613>
sakoman: my only challenge is workflow, keeping multiple branches up-to-date, testing that the CVE fix at least builds on each branch... it slows down the cycle significantly. And I find it mentally challenging to jump between branches a lot, get my wires crossed.
<rfs613>
having fewer active branches would of course help... dunfell, kirkstone, master would be nice ;-)
<sakoman>
rfs613: I totally understand! The important branches at this point would be master, kirkstone, and dunfell
<khem>
practically yes
<rfs613>
ok, so as I am focused on dunfell for now, maybe I'll just note which other branches a fix might be applicable to (it's pretty easy to check while I'm in there), but leave the actual work of fixing honister/hardknott (if applicable) to someone else.
<khem>
yeah knowing that other branches would need this fix too would be good atleat release maintainer will know
<rfs613>
the patches would have [dunfell] tag, so other branch maintainer might not look at them
<sakoman>
rfs613: honister and hardknott just have one to two months of active maintenance left so it is a short term problem
<sakoman>
rfs613: I know that for dunfell I look at all CVE patches in master and do a quick evaluation as to whether they exist in dunfell and whether a cherry-pick is possible
<rfs613>
my other question relates to timing w.r.t releases, do we have a preference on when to submit (esp) CVE fixes?
<sakoman>
rfs613: for CVEs the answer is always ASAP :-)
<sakoman>
I try to do some each week independent of whether a release is imminent or not
<sakoman>
Though at release time it does go to zero since I'm occupied with the release
<khem>
sakoman: on this note when is 3.1.16 planned ? there are some important openssl fixes on dunfell since 3.1.15
<sakoman>
khem: from the weekly status update:
<sakoman>
YP 3.1.16 build date 2022/04/25YP 3.1.16 Release date 2022/05/06
<khem>
ok thanks
<rfs613>
i've just posted CVE-2022-0204 for dunfell. In the comments after the shortlog, I put info about the other branches. Feedback on the formatting, usefulnes, etc welcomed.
Wouter0100 has quit [Quit: Ping timeout (120 seconds)]
Wouter0100 has joined #yocto
Minvera has joined #yocto
<RP>
Nice, first ever oe-selftest pass with BB_SERVER_TIMEOUT set
<rfs613>
hmm, this is odd, I used "b4" to download my patch (in another copy of poky). It said it applies clean to current tree, and yet when I do the 'git am' on the .mbx file, it complains that the patch is corrupt.