<mcfrisk_>
Are rust and crates usable on kirkstone or should I give up and update to newer releases or master branch?
zpfvo has joined #yocto
<piie>
hey there, I'm kind of confused, how openssl project reacts on pushing a fix for a mem-leak. Would be happy to get any opinion on how Matt / I acted: https://github.com/openssl/openssl/pull/20317
<JaMa>
mcfrisk_: depends on what you need, I had to backport newer rust version from langdale and to generate SRC_URI with cargo-update-recipe-crates.bbclass I'm preparing recipes in mickledore (and then using them in kirkstone)
<JaMa>
piie: sounds strange, so those 23 lines in sslapitest.c weren't for you?
<piie>
JaMa: first I just pushed a on line fix with the free() call
<JaMa>
their policy on what is and isn't trivial very clear and they expain why
<piie>
and this was kind of refused without a test case. which is fine
<JaMa>
and I'm not a lawyer as well, so I agree it's annoying and strange, but they might be just very careful as it's openssl after all
<piie>
so I copy&pasted the test case as Matt was saying. And now the change isn't trivial anymore
<mcfrisk_>
JaMa: well my need is meta-security master branch and parsec-service, and just hit build failures on kirkstone. it looks like there are floating dependencies to something so I'm wondering if there are major problems with cargo/rust on kirkstone which are fixed in master..
<piie>
JaMa: what I don't get is, I found a bug in the openssl and provided a oneline fix. So I'd expect the openssl project is more than interested to fix this instead of requesting a test case to make the change non-trivial to get personal data from somebody...
<JaMa>
piie: understood, many people would just sign the CLA, so maybe they just expected you to do the same
<kanavin>
mcfrisk_, you should set up master builds and have be the primary integration point for your product development anyway
<piie>
JaMa: obviously. Thanks for sharing your view
<kanavin>
mcfrisk_, you'll generate far more interest if you can demonstrate the issue on master, and if the issue on master isn't happening, you can bisect to the point where it was fixed
zpfvo has quit [Ping timeout: 260 seconds]
<JaMa>
angry lawyer might be more dangerous than mem-leak :/
<mcfrisk_>
kanavin: I'm doing that as well... just wondering if rust and cargo support in kirkstone and master are in "working" state. There were no changes to meta-security master branch parsec-service recipe but it fails to build now with "error: failed to run custom build command for `tss-esapi v7.1.0`", at least with kirkstone poky, meta-openembedded, meta-arm...
<landgraf>
JaMa: bad lawyer (as well as layer :-) ) might be dangerous too
<piie>
JaMa: oh, that's a point. haven't looked at it from that angle
<piie>
then I hope they're not doing same thing for more serious bugs
<kanavin>
mcfrisk_, it's seen quite a lot of activity since kirkstone, so master is working, and as for kirkstone I simply don't care. If you want me to care, show the problem on master.
<piie>
luckily my finding for the openssl CVE-2021-3449 was able to be fixed really with a one-liner ;)
<JaMa>
:)
<kanavin>
piie, I'm with upstream on this one. You have to sign a CLA.
<piie>
kanavin: no, I can't
<kanavin>
piie, if you can't then you shouldn't be contributing to openssl or take work duties that require you to. Go and explain this to your manager.
prabhakarlad has joined #yocto
<piie>
kanavin: this is indeed the point. I have clear ok from my company to work on openssl and contribute. but I cannot sign privately on the CLA and to get company signing the CCLA is ongoing since months (you know, big companies and legalities)
<kanavin>
piie, that I can understand and agree with (not willing to sign a CLA privately). Still it's a problem of your company, not openssl's.
<piie>
kanavin: they could have applied the one-line fix, I provided in first place
Chocobo has quit [Ping timeout: 255 seconds]
<kanavin>
piie, if upstream asks you to sign a CLA, it's best not to argue that they shouldn't. you're just going to alienate the maintainers, and you want a healthy relationship with them.
<kanavin>
same goes for providing extra tests or generally addressing review concerns. It's ok to ask for clarity if you don't understand the review, it's not ok to question the review itself.
<piie>
thanks, good points, helps me to understand their view better. Although it's not matching my picture of how open source development was intended in first place
zpfvo has joined #yocto
<kanavin>
piie, I do agree that CLAs are not in the spirit of open source at all, and if your company publishes code, you should push hard to make it CLA-free project, or say that you're not doing it if CLAs are required.
<kanavin>
on the other hand, some important pieces like openssl, python, or qt are all asking for CLAs, so it's hard to avoid them as a contributor.
<kanavin>
I've even heard ridiculous positions like 'we do not allow our engineers to contributeto 3rd party projects if CLA is involved, but all our code must be published only with a CLA requirement for contributors'
<piie>
yes, understood. Thanks again, this really helped and I need some time to rethink my way of working in such constellations
<kanavin>
piie, yocto is completely CLA free :-)
<piie>
kanavin: so far I haven't found a bug in here ;)
<piie>
*there
<kanavin>
because we're awesome
<piie>
... and I'm not so deeply into yocto (yet) :D
goliath has joined #yocto
manuel__ has joined #yocto
florian has joined #yocto
ptsneves has joined #yocto
olani- has quit [Ping timeout: 246 seconds]
olani- has joined #yocto
gsalazar_ has quit [Ping timeout: 252 seconds]
amsobr has joined #yocto
gsalazar_ has joined #yocto
<Joel71>
Good day folks! I would like WIC to create fixed-size partitions, e.g 3.5gb. I'm also using --source=rootfs. What I get as a result is 3.5gb partitions (per lsblk) with the filesystem sized to rootfs with just whatever extra space I allow in yocto settings. How can I tell the filesystem to use the free space in the partition?
<Joel71>
So `--fixed-size=3500` does not seem to affect my rootfs. If I do `--size=3500` then that's just added on top of the size of rootfs.
camus1 has joined #yocto
camus has quit [Ping timeout: 246 seconds]
camus1 is now known as camus
<Joel71>
This is the right combo `--fixed-size 3600 --fsoptions "x-systemd.growfs"` which makes the fs grow to available block device size.
PhoenixMage has quit [Ping timeout: 255 seconds]
PhoenixM2ge has joined #yocto
<LetoThe2nd>
I've stumbled across a recipe that uses both ${localstatedir}/lib and ${libdir}. am i correct that the former is incorrect, the latter is correct, but on a non-multilib build they will usually match?
invalidopcode1 has quit [Ping timeout: 252 seconds]
ytarip is now known as piraty
starblue has quit [Ping timeout: 255 seconds]
starblue has joined #yocto
<LetoThe2nd>
Entei[m]: look at the tunes that are used. and please try to adjust your matrix client so it doesn't put half of your message behind links. i've looked those up two or three times now, but i find it quite annoying.
<Entei[m]>
LetoThe2nd: Sorry I am using the basic Element client
gsalazar_ has joined #yocto
nemik has quit [Ping timeout: 255 seconds]
nemik has joined #yocto
Chocobo has joined #yocto
Thorn has joined #yocto
invalidopcode1 has joined #yocto
Joel71 has quit [Quit: Client closed]
<LocutusOfBorg>
hello, question: I need to use meta-iotedge with hardknott, but layer is compatible only with dunfell
<LocutusOfBorg>
I added OVERRIDES = "meta-iotedge"
<LocutusOfBorg>
in my layer with higher priority BBFILE_PRIORITY_custom = "97"
<LocutusOfBorg>
ERROR: Layer meta-iotedge is not compatible with the core layer which only supports these series: hardknott (layer is compatible with dunfell)
<LocutusOfBorg>
still getting this error
derRichard has joined #yocto
<LocutusOfBorg>
(of course I added the bbappend in my layer to make it compatible with hardknott, but I don't want to touch meta-iotedge to just add one "hardknott" word)
<qschulz>
derRichard: probably not, you'll likely need STAGING_DIR in front I think
<qschulz>
maybe the paths are properly set for it to look into STAGING_DIR but I don't know enough :/
<derRichard>
ok. so i still have to set CONFIG_EXTRA_FIRMWARE_DIR at build time then. unless there is already a way. or am i the first guy that want to use CONFIG_EXTRA_FIRMWARE? (having firmware blobs directly in the kernel image)
<LocutusOfBorg>
I'm creating a meta-iotedge-compat
<LocutusOfBorg>
lets see
* qschulz
shrugs at derRichard
<derRichard>
:)
<JaMa>
LocutusOfBorg: you need to add it layer.conf of a layer which is parsed before meta-iotedge (later in BBLAYERS order)
olani- has quit [Remote host closed the connection]
Joel70 has quit [Quit: Client closed]
olani- has joined #yocto
roussinm has joined #yocto
manuel__ has quit [Ping timeout: 255 seconds]
<Entei[m]>
<LetoThe2nd> "Entei: look at the tunes that..." <- So I tinkered around a bit, found the file tunes file you mentioned. Tried making my own machine conf, which kept failing. so far now I just changed the `DEFAULTTUNE = "riscv64nc"`, Should that be enough?
<Entei[m]>
s/file//
manuel__ has joined #yocto
<DvorkinDmitry>
I'm building 5.10 kernel with Dunfell. Dunfell lacks the gcc-plugins. What methd is better? 1) to add patch for kernel.bbclass for gcc-plugins 2) to add something into my kernel recipe ? 3) to switch off gcc-plugins in my kernel (I try, but i don't see how), 4) use Kirkstone
<rburton>
(4) because newer==better, if that's an option
kscherer has joined #yocto
<qschulz>
DvorkinDmitry: fc2b9f7f99b993ec19d7f962f4e06ec70a5313ca in poky
<qschulz>
maybe candidate for a backport?
azcraft has quit [Remote host closed the connection]
<khem>
it does not happen all the time, so I guess its also related to certain hosts I assume
<RP>
khem: I was having a look at it. I think that libzstd was built against a newer libc system or against our uninative and the one in buildtools is too old. I was going to see if a newer buildtools helps the issue
frieder has quit [Remote host closed the connection]
florian_kc has joined #yocto
<khem>
actually let me fill you in a bit, libzstd is built from libzstd-native which gdb brings in as dependency
<khem>
for a reproducer I copied it over
<RP>
khem: I played with your reproducer :)
<JaMa>
kinky
<khem>
good
<RP>
khem: sadly a newer buildtools does not help :(
manuel__ has quit [Ping timeout: 248 seconds]
<DvorkinDmitry>
qschulz, thanks!
<khem>
RP: yeah, perhaps new-dt-binding patch I sent for binutils might help if its playing games with rpath
<qschulz>
DvorkinDmitry: obviously not tested, just found this to be an interesting commit, maybe there's more to backport :)
<khem>
but I am not sure
<khem>
JaMa: hmmm :))
manuel__ has joined #yocto
<RP>
khem: I ran the failing testcase under strace and it isn't good news
<khem>
RP: we could add -pthread to cmdline but that will link libpthread with binaries which dont need it as well
<khem>
ah good
<DvorkinDmitry>
qschulz, is this commit in Dunfell?
<RP>
khem: [pid 3557923] openat(AT_FDCWD, "/usr/lib64/iscsi/libpthread.so.0", O_RDONLY) = -1 ENOENT (No such file or directory)
<RP>
[pid 3557923] openat(AT_FDCWD, "/usr/local/oe-sdk-hardcoded-buildpath/sysroots/x86_64-pokysdk-linux/usr/x86_64-pokysdk-linux/lib64/libpthread.so.0", O_RDONLY) = -1 ENOENT (No such file or directory)
<RP>
[pid 3557923] openat(AT_FDCWD, "/usr/local/lib64/libpthread.so.0", O_RDONLY) = -1 ENOENT (No such file or directory)
<RP>
[pid 3557923] openat(AT_FDCWD, "/usr/local/oe-sdk-hardcoded-buildpath/sysroots/x86_64-pokysdk-linux/usr/lib64/libpthread.so.0", O_RDONLY) = -1 ENOENT (No such file or directory)
<khem>
I did look at the RUNPATHs in libzsts.so they did not look out of sorts to me
<khem>
RP: ah so the build time paths are still being looked at and not beeing relocated after buildtools tarball gets installed to new location I guess ?
<RP>
khem: that is my guess
<qschulz>
DvorkinDmitry: no, hardknott, the first release to support linux-yocto 5.10
<khem>
looks like that
<khem>
have you thought about using GCC_EXEC_PREFIX env var in SDK
<khem>
that can sort these sort of relocation issues
olani- has quit [Remote host closed the connection]
<tlwoerner>
how can i test oe-core's master-next when it says i need bitbake 2.3.1?
d-s-e has quit [Read error: Connection reset by peer]
<rburton>
bitbake's master commit right now is "bump to version 2.3.1"
<tlwoerner>
haha
<tlwoerner>
i just had to wait until morning
manuel__ has quit [Ping timeout: 246 seconds]
olani- has joined #yocto
d-s-e has joined #yocto
manuel__ has joined #yocto
<rburton>
khem: llvm sets -DCMAKE_BUILD_TYPE=Release. Is this because the default is a full-debug build which is really slow, or to not generate loads of debug symbols, or something else? I've a patch which makes the default RelWithDebug and I'm wondering what llvm and friends should do.
manuel__ has quit [Ping timeout: 255 seconds]
<khem>
rburton: purely for speeding up builds
<khem>
infact RelWithDebug is a better compromize if it works
<rburton>
i'll see what it does :)
vladest has quit [Remote host closed the connection]
vladest has joined #yocto
<khem>
problem with debug info is that its humongous in size
<rburton>
yeah that was my thought for llvm
<khem>
and not many will debug it
manuel__ has joined #yocto
<rburton>
hm i wonder if we should do release builds for native
otavio has quit [Ping timeout: 252 seconds]
nemik has quit [Ping timeout: 255 seconds]
nemik has joined #yocto
rfuentess has quit [Remote host closed the connection]
otavio has joined #yocto
mihai has quit [Quit: Leaving]
prabhakarlad has quit [Quit: Client closed]
<RP>
tlwoerner: that patch was in bitbake master-next FWIW
<RP>
rburton: debug was horribly slow and huge
<rburton>
yeah llvm-native does appear to be taking longer :)
ptsneves has quit [Ping timeout: 264 seconds]
camus has quit [Ping timeout: 246 seconds]
camus has joined #yocto
manuel__ has quit [Ping timeout: 255 seconds]
<roussinm>
rburton: About yesterday illegal instruction problem, I tried running gdb on qemu to find which intruction it was emitting an SIGILL, but gdb frames shows qemu-x86_64 and not really what has been executed. gdb stops at suspend/abort which is too far.
<rburton>
yeah that won't help, but qemu itself should be saying what the illegal instruction is
Joel69 has joined #yocto
<rburton>
RP: hm just learnt some stuff and now i'm more confused by cmake than i was before
<JaMa>
CMake surely has some CMP policy to make you even more confused again
<JaMa>
their backwards compatibility is nice and PIA at the same time
<roussinm>
rburton: qemu: uncaught target signal 4 (Illegal instruction) - core dumped that's pretty much the error I got.
<RP>
khem: if I copy sysroots/x86_64-pokysdk-linux/etc/ld.so.conf to sysroots/x86_64-pokysdk-linux/etc/etc/ld.so.conf in buildtools, things work
<rburton>
JaMa: if you don't set a build type then you get no build type so you don't get any bonus flags to the flags we already set, but we already pass -g -O2 in cflags anyway so release vs debug is meaningless as release mostly sets -O3 and debug mostly sets -g.
<rburton>
so setting release doesn't stop it building vast amounts of debug code
<rburton>
ah no our native cflags don't have -g in by default
<rburton>
god i hate building stuff sometimes
<RP>
rburton: I think we reasoned target debug was good, the tools, less useful in general
<roussinm>
rburton: I'm trying to add debug symbols to qemu-x86_64 but when they get to the recipe-sysroot-native they always get stripped. Even with: INHIBIT_PACKAGE_STRIP = "1"
<Entei[m]>
Anyone got solutions to getting an image without compressed ISA?
<Entei[m]>
Hey I tried making the `DEFAULTTUNE = "riscvq4nc"` in `meta/conf/machine/include/riscv/arch-riscv`. However my built image still comes with compressed instruction flag....
BrianMcKee has joined #yocto
zpfvo has quit [Quit: Leaving.]
<BrianMcKee>
Hello. I'm trying to create a u-boot_%.bbappend file and I can see that it's being ignored.
<BrianMcKee>
I googled around and found that this can happen if COMPATIBLE_MACHINE is not set, but I can't find anywhere to set that variable for u-boot. I was wondering if there could be another reason the bbappend could be skipped?
invalidopcode1 has quit [Remote host closed the connection]
invalidopcode1 has joined #yocto
seninha has quit [Remote host closed the connection]
PhoenixM2ge has quit [Ping timeout: 255 seconds]
PhoenixMage has joined #yocto
<khem>
RP: ah cool
<BrianMcKee>
Yesterday I asked some questions and got logged off, so I may have missed replies. Is there a yocto forum I could ask questions on so I wouldn't lose replies?
PhoenixMage has quit [Ping timeout: 255 seconds]
PhoenixM2ge has joined #yocto
PhoenixM2ge has quit [Ping timeout: 255 seconds]
PhoenixM1ge has joined #yocto
BrianMcKee has quit [Quit: Client closed]
<roussinm>
rburton: well I pretty much gave up on debugging this, upgraded the qemu recipe and now it works, sooooo success I guess...
<khem>
but if you use matrix bridge then it should be in your element clients history even if you have closed the app
florian_kc has joined #yocto
Minvera has joined #yocto
Thorn has quit [Ping timeout: 246 seconds]
olani- has quit [Ping timeout: 255 seconds]
kevinrowland has joined #yocto
<\dev\ice>
is it good or bad practise to place files not just files/some.conf but files/etc/some.conf?
amsobr has joined #yocto
amitk has quit [Ping timeout: 255 seconds]
<khem>
well, its upto you what you want under files/ bitbake will have to be told about the dir structure under it when you use those files
<khem>
I personally dont like deep dir structures
seninha has joined #yocto
nemik has quit [Ping timeout: 248 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 252 seconds]
nemik has joined #yocto
<rburton>
roussinm: upgrading and testing it was probably easier :) you don't need debug symbols of qemu anyway, you want to get the backtrace from the app its running to identify what instruction was failing