<JaMa>
khem: have you seen some kernels failing to build with gcc-13 on https://github.com/torvalds/linux/blob/master/include/linux/nospec.h#L58 ? hammerhead/kernel-source/include/linux/compiler_types.h:357:45: error: call to '__compiletime_assert_322' declared with attribute error: BUILD_BUG_ON failed: sizeof(_s) > sizeof(long)
<JaMa>
khem: it's in custom 6.1.0 kernel, but I haven't seen any changes in this area in vanilla nor this custom
<JaMa>
and I've verified that reverting the gcc-13 upgrade allows to build it again.. will check preprocessor tomorrow, so just in case you remember something right away
<Haxxa>
Looking at a device which runs yocto linux and every service runs as root, is this normal for yocto linux?
<Haxxa>
Or has the device manufacturer simply made this design decision?
AKN has joined #yocto
amitk has joined #yocto
_whitelogger has joined #yocto
davidinux has joined #yocto
amitk_ has joined #yocto
AKN has quit [Ping timeout: 268 seconds]
rob_w has joined #yocto
alessioigor has joined #yocto
demirok has joined #yocto
goliath has joined #yocto
AKN has joined #yocto
AKN_R has joined #yocto
AKN has quit [Ping timeout: 252 seconds]
AKN_R has quit [Ping timeout: 260 seconds]
louson has quit [Ping timeout: 260 seconds]
louson has joined #yocto
Schlumpf has joined #yocto
frieder has joined #yocto
<mcfrisk>
Haxxa: quite normal. configuration can be changed. yocto runs many things with defaults of the open source SW component and if they have not changed the service to run as non-root user, then things run as root
<Haxxa>
mcfrisk, Okay but this is for a PLC controlling Gas mains, I have been asked to assess if this is bad practice or not. I'm leaning towards it been bad practice
<LetoThe2nd>
yo dudX
amitk__ has joined #yocto
amitk has quit [Ping timeout: 248 seconds]
mckoan|away is now known as mckoan
<mckoan>
good morning
<mcfrisk>
Haxxa: yes running service as root is bad. fixing that requires tuning udev rules to set permissions for non-root users and to configure userspace side to use them (add the user, make sure systemd/init scripts use them). A lot of the bugs in this require testing which can be HW and use case specific and thus is hard to do by default.
BrianL has quit [Ping timeout: 260 seconds]
rfuentess has joined #yocto
goliath has quit [Quit: SIGSEGV]
mrnuke has quit [Read error: Connection reset by peer]
zpfvo has joined #yocto
kroon has joined #yocto
wooosaiiii has quit [Quit: wooosaiiii]
wooosaiiii has joined #yocto
Jham has joined #yocto
StephCC has joined #yocto
amitk_ has quit [Remote host closed the connection]
kroon has quit [Quit: Leaving]
manuel1985 has joined #yocto
mvlad has joined #yocto
DA92_CC has joined #yocto
StephCC has quit [Ping timeout: 252 seconds]
StephCC has joined #yocto
DA92_CC has quit [Ping timeout: 260 seconds]
DA92_CC has joined #yocto
goliath has joined #yocto
StephCC has quit [Ping timeout: 252 seconds]
goliath has quit [Client Quit]
goliath has joined #yocto
AKN has joined #yocto
amitk has joined #yocto
<JaMa>
khem: have you seen opencv triggering ICE with gcc-13? seen it on arm, doesn't trigger it on x86_64, opencv/4.6.0-r0/git/3rdparty/carotene/src/in_range.cpp:175:1: internal compiler error: in cselib_subst_to_values, at cselib.cc:2148
nemik has quit [Ping timeout: 260 seconds]
nemik has joined #yocto
xmn has quit [Ping timeout: 268 seconds]
florian has joined #yocto
xmn has joined #yocto
leon-anavi has joined #yocto
Schlumpf has quit [Ping timeout: 260 seconds]
seninha has joined #yocto
DA92_CC has quit [Quit: Leaving]
StephCC has joined #yocto
DA92_CC has joined #yocto
StephCC has quit [Ping timeout: 248 seconds]
DA92_CC has quit [Ping timeout: 248 seconds]
mihai has quit [Quit: Leaving]
azcraft has joined #yocto
Schlumpf has joined #yocto
nucatus has joined #yocto
StephCC has joined #yocto
<nucatus>
this might be a silly question, but I'm struggling with making it work. I create a user in my image recipe:
<nucatus>
inherit extrausers
<nucatus>
EXTRA_USERS_PARAMS = "\
<nucatus>
useradd \
<nucatus>
--system \
<nucatus>
--home ${MY_USER_D} \
<nucatus>
--create-home \
<nucatus>
--shell /sbin/false \
<nucatus>
myuser; \
<nucatus>
"
<nucatus>
but when I'm trying to chown in a recipe, it fails
<nucatus>
pkg_postinst:${PN}() {
<nucatus>
chown -R myuser ${MY_USER_D}
<nucatus>
}
<nucatus>
am I doing it wrong?
<nucatus>
ERROR: my-image-1.0-r0 do_rootfs: Postinstall scriptlets of ['myrecipe'] have failed. If the intention is to defer them to first boot, then please place them into pkg_postinst_ontarget:${PN} ().
<nucatus>
I'm running this on kirkstone in a kas (3.2) container
xmn has quit [Ping timeout: 246 seconds]
<LetoThe2nd>
nucatus: as the user is created later (in the image), obviously a package recipe cannot use it earlier. suggestion: create the user in a recipe that your package can depend on.
<LetoThe2nd>
nucatus: then you can also skip all of the postinst magic, AFAICS
<nucatus>
LetoThe2nd: I guess this makes sense. However, my use case is to create a user in one recipe and then use it in other recipes as well. This is why I thought the "image wide" meaning in the documentation was referring to.
<nucatus>
I was clearly wrong...
azcraft has quit [Remote host closed the connection]
azcraft has joined #yocto
<nucatus>
I tried also the route to create the user in the recipe "A" and then make the "B" and "C" recipes, where the user is used, depend on the recipe "A".
starblue has quit [Ping timeout: 252 seconds]
<nucatus>
The issue I'm facing here is that the ownership in the final rootfs is messed-up (wrong user owns the intended dir).
<nucatus>
The idea of having a recipe where the user is employed depend on a recipe where the user is created use to work in dunfell, but after the kirkstone upgrade, this fails
<qschulz>
nucatus: IIRC you can create the same user in multiple recipes
<qschulz>
and we have a bug for users defined in one recipe that cxannot be used in another, even with proper DEPENDS
<nucatus>
@qschulz: is there a link to that bug so we can track its evolution?
OnkelUlla has quit [Remote host closed the connection]
OnkelUlla has joined #yocto
<KareemZarka[m]>
hi , so I'm trying to add a test case to oe-selftest inside of wic.Wic .
<KareemZarka[m]>
the test simply creates a partition using wks file and wks command then verifies that the kernelImage was not installed to that partition. However when I try to access that partition using ```with open(out[0], "r") as f: content = f.read()``` I get an error UniCodeDecoderError , can someone help me out figure out why ?
<landgraf>
KareemZarka[m]: please do not use multiline messages here
<kayterina[m]>
Hello, "bitbake --no-setscene myimage" causes some recipes from poky to fail at compiling which do not fail when build with setscene. For example, nspr_4.29 fails to compile a test and bzip2 sometimes builds an empty .so . I doubt there is an error in these sources, so what else can I look into?
<kayterina[m]>
I am running bitbake in a docker container.
<KareemZarka[m]>
rburton: my goal is to check if the within the partition I created there's some file name , do I really need to open with rb ?
<rburton>
KareemZarka[m]: thats not what your test is doing
<rburton>
you can't open() a disk image and expect to get a list of filenames
<KareemZarka[m]>
rburton: right , I'm not really keen on python , would I need to mount the disk image then simply check for the names?
<KareemZarka[m]>
KareemZarka[m]: or is there any other trick to achive that ?
<rburton>
you can't mount as you're not root. if the filesystem is fat32 then you can use mcopy (see the other wic tests(
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
wooosaiiii1 has joined #yocto
<KareemZarka[m]>
<rburton> "you can't mount as you're not..." <- right mount doesnt work here ... sorry to nagg but can you elaborate on mcopy ?
<KareemZarka[m]>
are you refering to wic copy ?
<rburton>
that works yes
wooosaiiii has quit [Ping timeout: 256 seconds]
wooosaiiii1 is now known as wooosaiiii
OnkelUlla has quit [Remote host closed the connection]
invalidopcode1 has quit [Remote host closed the connection]
invalidopcode1 has joined #yocto
Thorn has quit [Ping timeout: 252 seconds]
davidinux has quit [Ping timeout: 252 seconds]
davidinux has joined #yocto
mvlad has joined #yocto
Schlumpf has quit [Quit: Client closed]
goliath has quit [Quit: SIGSEGV]
mborzecki has quit [Quit: You have been kicked for being idle]
Thorn has joined #yocto
tepperson has joined #yocto
<tepperson>
anybody know anything about enabling fortran support on yocto master? I'm getting a configure error that GNU fortran is not working for the gcc-runtime recipe
manuel1985 has quit [Ping timeout: 252 seconds]
<JaMa>
FORTRAN variable still works for me
<tepperson>
i am getting "libgfortran was skipped: libgfortran needs fortran support to be enabled in the compiler". I added FORTRAN=",fortran" to my local.conf
<JaMa>
tepperson: check with bitbake-getvar but IIRC FORTRAN variable needs to be used with an override to have any effect
LocutusOfBorg has quit [Ping timeout: 260 seconds]
AKN has joined #yocto
<tepperson>
ah it seems i needed "FORTRAN:forcevariable = ",fortran"" in my local.conf
<khem>
it would be good to generate a preprocessed file of the failing source and send my way
<khem>
it seems clang16 glibc 2.37 binutils 2.40 and gcc13 all are coming with releases in 2-3 months window, its lot of foundational components moving together
aleblanc[m] has joined #yocto
<khem>
compiler segfault is always a compiler bug no matter what the input is, so we need to fix it regardless
<khem>
JaMa: btw. is it using -O2 ? or -O3
amitk__ has quit [Ping timeout: 255 seconds]
sakoman has quit [Quit: Leaving.]
Thorn has quit [Ping timeout: 246 seconds]
<JaMa>
khem: yes, that's why I keep it just as temporary work around (to unblock the builds to find out what else needs to be fixed)
<JaMa>
the <cstdint> is pain, 50+ internal recipes fail due to that change
<JaMa>
much fewer due to <system_error> or more missing <string> etc
<BrianL>
khem I think that I got my recipe back to where I had it a week ago, which is to say, installing *some* files but not to every location. Do you think that you could illuminate for me why only the nativesdk is getting populated (/sysroots/cortexa72-cortexa53-xilinx-linux) but not the host side (/sysroots/x86_64-petalinux-linux). I realize that
<BrianL>
this is probably a menial question, but I'm apparently only really good at breaking my build, not actually accomplishing my goals with it...
azcraft has quit [Remote host closed the connection]
<BrianL>
I mean /usr/include/finalcut is making it to the former, but not the latter path
<khem>
JaMa: yeah <cstdint> change is a painful one but its a good one exposes some bugs especially around exceptions
<khem>
BrianL: you need to stage install whatever this recipe needs to export as artifacts and this will then work across native/nativesdk/target versions of this recipe
<khem>
native is generally tools and wont have development libs/headers since these are only needed during build but you might want some of these tools in your SDK for that nativesdk version is used
<khem>
taget portion is needed for cross building a package/app against your SDK
<khem>
JaMa: OK -fsched2-use-superblocks is supposed to be used with -fsched-insn2 which is part of -O2 so it should be fine to use
<BrianL>
khem Ok, thanks. I'll see if I can't figure out how to get that done then.
<khem>
so its a compiler issue we can report back to community
<BrianL>
khem if you know of a recipe you could refer to me to, that'd be great. If not, thank you for your help just the same.
<khem>
yeah IMO ensure your do_install is complete
<khem>
its copying needed bits to ${D}
<BrianL>
khem it ends up properly copied, all the files (I assume through do_populate_sdk) to the cortexa72-cortexa53-xilinx-linux sysroot, but not to the host side. Thanks
alessioigor has joined #yocto
alessioigor has quit [Client Quit]
seninha has quit [Quit: Leaving]
<tepperson>
aynone have tips for building pytorch ?
kscherer has quit [Quit: Konversation terminated!]
Thorn has joined #yocto
Xagen has quit [Read error: Connection reset by peer]
Xagen has joined #yocto
<BrianL>
khem Thanks for your help. Can I buy you a beer?