goliath has quit [Remote host closed the connection]
goliath has joined #yocto
goliath has quit [Remote host closed the connection]
goliath has joined #yocto
<Guest89>
Hello everyone. My colleagues and me are trying to set up a Yocto build environment that uses the downloads/sstate-cache dirs in a common NFS share. In order to let one add files to directories created by other, we added BB_DEFAULT_UMASK = "002" to our local.confs . This worked well at first, but when building a complete image BitBake fails with
<Guest89>
several errors "X conflicts between attempted installs of Y and Z", where X is a rootfs directory. Turns out that X was created with permissions 775 instead of 755, so it seems the new umask "leaks" into the rootfs. Did we use the wrong variable or is it a BitBake bug? Thanks for any info!
mbulut has joined #yocto
Guest89 is now known as egueli
mbulut_ has joined #yocto
mbulut_ has quit [Client Quit]
leon-anavi has joined #yocto
mbulut has quit [Ping timeout: 255 seconds]
Max86 has joined #yocto
mvlad has joined #yocto
<mckoan>
egueli: AKA Guest89: AFAIK and IIRC Yocto sstate doesn0t work with NFS
<egueli>
mckoan I wish I knew that before... any idea why doesn't it work exactly? note that the tmp directory is local, only downloads & sstate-cache are in NFS
<Max86>
Hello!,
<Max86>
i'm currently building a function that generate an id and append it to the /etc/os-release file on every build.
<Max86>
The function is working without any problems, but the build fails with "path mismatch [1 link]: ino ... db".
<Max86>
This problem is only when i modify existing files
<Max86>
Why is this happening? Is there a file hash check?
<RP>
egueli: we do use NFS for sstate and downloads on the autobuilder so it can and does work
<RP>
egueli: is that an older release? We did make some umask fixes a while ago
<RP>
mckoan: FWIW we can run sstate and downloads over NFS
<egueli>
RP working on Mickledore
<RP>
egueli: that is new enough to have what I was thinking of
<RP>
egueli: oh, you changed BB_DEFAULT_UMASK? :/
<egueli>
RP I had to, otherwise if user A creates a directory there, user B cannot add a cache entry because of 755 permissions
<RP>
egueli: there is a bug open in bugzilla about pseudo not creating sstate files with the right permissions in some cases iirc. We've not narrowed it down or managed to fix that one yet and I suspect that is what you're running into. Changing the overall umask will have other side effects
<egueli>
I might have found a workaround: add entries to fs-perms.txt to clarify what are the expected directory permissions
olani- has quit [Ping timeout: 240 seconds]
<egueli>
I then ran "-c cleansstate" on all the affected recipes and... I just got a successful build 😀
<RP>
egueli: you really want to fix the pseudo/sstate issue separately to the main umask values or you'll be chasing a ton of issues everyone else doens't see
<egueli>
@RP: do you have a reference for that bug?
Vonter has joined #yocto
<RP>
egueli: I looked but I can't find it. Perhaps it was closed as fixed? :/
<egueli>
RP: no worries, thanks for the heads-up anyway
<RP>
egueli: please reopen if you can describe how to reproduce it
egueli has quit [Quit: Client closed]
Guest89 has joined #yocto
Guest89 is now known as egueli
<egueli>
RP: will try, cheers
OnkelUlla has joined #yocto
florian_kc has joined #yocto
prabhakarlad has quit [Quit: Client closed]
<egueli>
RP: if I understand correctly from the bug, BitBake is supposed to make sstate-cache entries with 775 by default? i.e. without using BB_DEFAULT_UMASK ?
schtobia has quit [Quit: Bye!]
schtobia has joined #yocto
florian_kc is now known as florian
<Rich_1234>
If I want to launch a full-screen application on boot (akin to Windows kiosk mode). Is launching the program as a daemon as part of an sysvinit script e.g. add (/etc/init.d/myscript) generally the way to go?
ptsneves has joined #yocto
<mckoan>
Rich_1234: yes
<Rich_1234>
mckoan thanks, I just wanted to check before I spent too much time on that
olani- has quit [Remote host closed the connection]
starblue has joined #yocto
<rburton>
Rich_1234: depends on the context of the system. an init script will run as root and not neccessarily have permission to access the x/wayland server. if you're running a graphical session start the thing in there. systemd also has user sessions and user startup units which are better too.
<Rich_1234>
rburton just to clarify, do you mean if I make init.d/myscript and I had weston I would basically add weston-start to myscript? Or you mean something like add a cron job on start to just launch the app when weston has finished loading. I may take a look at systemd also ty
<rburton>
Rich_1234: if you're using weston then i'd recommend switching to systemd, bringing up weston in a user session and starting your app the same way
otavio has joined #yocto
<Rich_1234>
rburton thanks, I will give that a go
frieder has quit [Ping timeout: 240 seconds]
prabhakarlad has joined #yocto
florian_kc has joined #yocto
<rburton>
yocton:
<rburton>
whoops
varjag has joined #yocto
<RP>
egueli: I think our intent was to use the user's umask
frieder has joined #yocto
egueli has quit [Quit: Client closed]
GNUmoon2 has joined #yocto
tgamblin has joined #yocto
tnovotny has joined #yocto
Chocky1 has joined #yocto
Chocky2 has joined #yocto
Chocky has quit [Ping timeout: 264 seconds]
<Rich_1234>
Why does setting INIT_MANAGER to systemd add a dependency of xwayland, I feel like I am missing something here. The systemd recipe https://layers.openembedded.org/layerindex/recipe/300915/ doesn't seem to list x as a dependency unless something like libxkbcommon defaults to using x11 over wayland
Chocky1 has quit [Ping timeout: 260 seconds]
Chocky2 has quit [Ping timeout: 248 seconds]
Danct12 has quit [Read error: Connection reset by peer]
Daanct12 has quit [Quit: WeeChat 4.1.1]
xmn has joined #yocto
<Rich_1234>
nevermind, I think it must have been a mistake in my local.conf
Vonter has quit [Ping timeout: 260 seconds]
Vonter has joined #yocto
DvorkinDmitry has joined #yocto
<DvorkinDmitry>
is there are any recommendations/recipes to have encrypted rootfs for Yocto?
<mcfrisk>
any hints how to handle private keys and password related secrets in builds? I'm trying to avoid magic tar balls and env variables
Danct12 has joined #yocto
Danct12 has quit [Client Quit]
Guest38 has joined #yocto
Guest38 is now known as egueli
frieder has quit [Ping timeout: 272 seconds]
diecore has joined #yocto
<diecore>
Hello! When I try to build the kernel with bitbake virtual/kernel using a custom recipe for the kernel, build complains and gives me errors because -std=c99 or c11 is not enabled. How can I add it ?
<LetoThe2nd>
diecore: "the build complains"?
frieder has joined #yocto
tnovotny has quit [Quit: Leaving]
Danct12 has joined #yocto
<rburton>
diecore: sounds like your custom recipe is broken, not the compiler
<diecore>
:LetoThe2nd :rburton The build complains if my module is written with c99 style if not all are OK
rfuentess has quit [Remote host closed the connection]
<diecore>
for example if I have the variable declariation inside for loop which is allowed in c99
<KanjiMonster>
probably easiest solution is to not do that and just follow the kernel code style ;p
<diecore>
We have 2023 and we still writing code in the kernel like C90 ?
emdevt__ has quit [Quit: Leaving]
<rburton>
diecore: you could just extend the CFLAGS
<KanjiMonster>
yeah, placing a CFLAGS += -std=c99 in your module's Makefile should work
<KanjiMonster>
but if you ever want to contribute your code, you will need to adapt to kernel style
Tyaku has joined #yocto
goliath has quit [Quit: SIGSEGV]
<Tyaku>
Hello, I have questions about Java applications in Yocto: Currently we have a recipe that generate a .jar and the .jar is executed directly in the image using "java" application. To make it working we use a runtime dependancy on "openjdk-8". The problem of this is that "openjdk-8" takes a lot of space.
<Tyaku>
So we are looking for alternatives to reduce the disk usage for the unique JAVA application that we need to run
<rburton>
wouldn't you use the JRE not the JDK for target?
<Tyaku>
I found graalvm that seems to work in ubuntu, this software can be used to generate a binary from a JAR file, the binary is like 10Mo in our case. I didn't try this on yocto yet so I don't know if it works and I didn't check the licences too.
<Tyaku>
But I would like to know if there is know alternatives like this in yocto*
<Tyaku>
rburton, we use the jdk, but the jre should work and reduce some size
<Tyaku>
So, the openjdk-8 takes 128,8 Mo on the rootfs, the openjre-8 takes 89.6Mo, this is still to much. Tommorow I will check what is in meta-java, if there is a solution like GraalVM that permits to "build" a java application as binary with embedded JVM, as minimal as possible (so with only required features)
<Tyaku>
If not, I will try to use GraalVM to check if it works and what kind of "size" we can get. In a Ubuntu computer the executable takes just 10Mo and doesn't require externals stuffs.
<Tyaku>
Also I have a dummy question, nothing to see with it.
<Tyaku>
It's about "licencing". In my company we are not good with it. We would like to know, if it is real that when we use some software or libraries in a yocto image, the user must be able to upgrade the software/library when he want or not ? Because I eard this somewhere
<Rich_1234>
Tyaku Our company isn't the best at licencing either. Something like LGPL, the user must be allowed to upgrade the software component that is LGPL'd, e.g. if you use a specific QT version, you must then allow the user to update that QT version which may cause problems with safety critical devices. Then there is GPLv2 and GPLv3. All more confusing
<Rich_1234>
than the good old MIT licence
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
<rburton>
Tyaku: that's 4e of the LGPL i imagine. lots of ifs in there...
<rburton>
i imagine you're a 4d1 user of LGPL code, that is "dynamically linking"
mckoan is now known as mckoan|away
<rburton>
the fun is the installation information clause in the GPL
florian_kc has quit [Ping timeout: 248 seconds]
Kubu_work has quit [Quit: Leaving.]
florian has quit [Quit: Ex-Chat]
varjag has quit [Quit: ERC (IRC client for Emacs 27.1)]
<Tyaku>
Yep, but changing a shared library at runtime in a "personnal computer" is one thing but doing it on an embedded device with yocto/openwrt means: the user need to have access to ssh/serial console or be able to flash a custom image. I don't know any company allowing this.
<Tyaku>
For the 4.e, maybe in case of a yocto project, we must simply provide the yocto project used to build, with local.conf and all the layers being used for the build, but who do it ?
<Tyaku>
I mean "providing the sources of the yocto project being used is enough to provide 'Provide Installation Information'", but is too much for a company.
<Tyaku>
Not only for the sources, but more for the necessary to provide a way for the user to "enter" in the device;
radanter has quit [Remote host closed the connection]
<LetoThe2nd>
I just had a meeting with some people who boasted that they landed a deal because their customers switched to Yocto. Then they asked me why anybody is still doing that, because you know, why not just buy something off the shelf. And when I said "selling a device with Linux on it effectively makes you a Linux distributor", they jaw-dropped.
<moto-timo>
did we ever implement the OVF (open virtual format) VM format? I know we still have vmdk, but VirtualBox on Ubuntu 22.04 only seems to recognize .ovf
Bardon has joined #yocto
mvlad has quit [Remote host closed the connection]