goliath has quit [Remote host closed the connection]
prabhakarlad has joined #yocto
GNUmoon has quit [Ping timeout: 276 seconds]
troth has quit [Ping timeout: 256 seconds]
GNUmoon has joined #yocto
troth has joined #yocto
roussinm has quit [Quit: WeeChat 3.3-dev]
xmn has quit [Ping timeout: 250 seconds]
Tokamak has quit [Ping timeout: 268 seconds]
troth has quit [Ping timeout: 256 seconds]
geoffhp has quit [Quit: Leaving]
Tokamak has joined #yocto
troth has joined #yocto
dtometzki has joined #yocto
jpuhlman_ has joined #yocto
jpuhlman has quit [Killed (osmium.libera.chat (Nickname regained by services))]
jpuhlman_ is now known as jpuhlman
GNUmoon has quit [Ping timeout: 276 seconds]
GNUmoon has joined #yocto
beneth has joined #yocto
dtometzki has quit [Read error: Connection reset by peer]
dtometzki has joined #yocto
GNUmoon has quit [Ping timeout: 276 seconds]
wyre_ is now known as wyre
vd has quit [Ping timeout: 256 seconds]
rob_w has joined #yocto
Wouter0100 has quit [Ping timeout: 256 seconds]
rfuentess has joined #yocto
<dvorkindmitry>
what standard global variable I can use to refer to the current layer name in the recipes?
creich has quit [Quit: Leaving]
creich has joined #yocto
GNUmoon has joined #yocto
rob_w has quit [Ping timeout: 256 seconds]
mariusz has joined #yocto
<JosefHolzmayrThe>
yo dudX
luc4 has joined #yocto
rob_w has joined #yocto
Wouter0100 has joined #yocto
michalkotyla has quit [Ping timeout: 256 seconds]
<wyre>
where you'll place an useradd recipe?
<wyre>
recipes-bsp?
mariusz has quit [Ping timeout: 240 seconds]
<wyre>
maybe something like recipes-system? 🤔
Flumpy33 has joined #yocto
Flumpy33 is now known as Sion
<JosefHolzmayrThe>
i would place it with the application stack that actually requires/uses said user.
<wyre>
JosefHolzmayrThe, but ... couldn't I create a general purpose user?
<wyre>
to avoid using root
<JosefHolzmayrThe>
wyre: whats the point of a generic user on an embedded system?
<JosefHolzmayrThe>
usually its rather a "i want my stuff to run as this user". where "my stuff" is exactly the application stack that I just referred to.
<wyre>
I guess I was thinking in security/stability concerns ...
<JosefHolzmayrThe>
wyre: things don't become more secure just because you add a random non-root user.
michalkotyla has joined #yocto
<JosefHolzmayrThe>
running things as non-root increases security. so you have to look and decide what runs as non-root, and make those do so. and when you're doing that, you're already in the perfect place to add the users as needed.
zpfvo has joined #yocto
luc4 has quit [Read error: Connection reset by peer]
luc4 has joined #yocto
michalkotyla has quit [Ping timeout: 268 seconds]
leon-anavi has joined #yocto
nerdboy has quit [Ping timeout: 256 seconds]
nerdboy has joined #yocto
nerdboy has joined #yocto
nerdboy has quit [Changing host]
michalkotyla has joined #yocto
<wyre>
I see, thank you JosefHolzmayrThe 😊
<wyre>
I was thinking in usual general purpose distros
<qschulz>
Tartarus: honestly, I would say no. It encourages people to not point to licenses in the source code which defeats the whole purpose of LIC_FILES_CHKSUM
<qschulz>
you still need to point to a file or a section of a file expliciting it is of the license listed in LICENSE, but the content of the deployed license will be of the one in LICENSE_PATH IIRC. This is useful when you add a license which isn't already present in any layer, then the build system complains about a non-existing license or something like that
<qschulz>
dvorkindmitry: ah, it was said already, just didn't read the whole backlog :p
zpfvo has quit [Ping timeout: 252 seconds]
zpfvo has joined #yocto
mckoan|away is now known as mckoan
zpfvo has quit [Ping timeout: 252 seconds]
alicef_ has joined #yocto
zpfvo has joined #yocto
alicef has quit [Ping timeout: 256 seconds]
Schlumpf has joined #yocto
GillesM has joined #yocto
GillesM has quit [Remote host closed the connection]
alicef_ has quit [Quit: install gentoo]
zpfvo has quit [Ping timeout: 252 seconds]
zpfvo has joined #yocto
alicef has joined #yocto
zpfvo has quit [Ping timeout: 245 seconds]
zpfvo has joined #yocto
lucaceresoli has joined #yocto
alicef has quit [Quit: install gentoo]
ziga has joined #yocto
pgowda_ has joined #yocto
<ziga>
Hey! I have a desktop C++ application that uses libraries "libqwt-qt5" and "libboost". It is a QT5 application that I compile and run with "qmake" and then "make". It compiles and works perfectly on Debian 11. Now I want to include my application in "poky". Can somebody give me some advice where to start? I assume I have to first create layers that will compile and install "libboost" and "libqwt-qt5". But I also need a layer that it will
<ziga>
include QT5 in "poky". Are my goals okay or should I do something else? I think that layer for QT5 already exists so probably I can just include it...
<qschulz>
ziga: I highly recommend watching the tutorials on Yocto project youtube channel and read as much of the documentation at docs.yoctoproject.org to not be too lost when starting
<JosefHolzmayrThe>
the livecoding video on pagaging even features boost IIRC
zpfvo has quit [Ping timeout: 240 seconds]
zpfvo has joined #yocto
<ziga>
I watched the entire Holzmayr's playlist and created my notes. So I am a beginner already... I just don't want to start in the wrong direction and loose too much time. So QT5-meta can be solved with an already existing layer "meta-qt5" (thank you qschulz). I also checked and it looks like "libqwt-qt5" is part of this layer (https://github.com/meta-qt5/meta-qt5/tree/master/recipes-qt/qwt) I also remembered (thank you Josef) that you use "boost"
<ziga>
in multiple videos (numbered 15 & 17). Is "qmake" build system also well supported with Yocto like "cmake", "make", "meson" & "autotools" are?
alicef has joined #yocto
zpfvo has quit [Ping timeout: 245 seconds]
zpfvo has joined #yocto
<JosefHolzmayrThe>
ziga: I think meta-qt might provide a qmake class.
<ziga>
Okay. It looks like "meta-qt5" is all I need! This looks promising.
alicef has quit [Read error: Connection reset by peer]
GNUmoon has quit [Ping timeout: 276 seconds]
camus has quit [Remote host closed the connection]
camus has joined #yocto
florian has joined #yocto
GNUmoon has joined #yocto
alicef has joined #yocto
alicef has quit [Client Quit]
alicef has joined #yocto
td has joined #yocto
dlan has quit [Ping timeout: 250 seconds]
<td>
Hi,
<td>
I found the problem that when I'm building for example patch-native from sstate-cache from different directory its binary is linked against the old dynamic loader causing "bad ELF interpreter: No such file or directory". In fact ldd on patch binary shows the buildtools path that was used in the previous build, not in current build. Is such issue
<coldspark29[m]>
qschulz: Is it normal that menuconfig looks this weird with Pyrex?
<qschulz>
coldspark29[m]: don't know, I'm not using menuconfig with bitbake usually
<coldspark29[m]>
qschulz: How else to use it? I want to change the kernel defconfig. The Variscite Wiki says to use that
<coldspark29[m]>
I would rather edit it with Vim anyway
<coldspark29[m]>
Need to deactivate some modules that are already included
<JosefHolzmayrThe>
that can happen if the terminal isn't playing nice with ncurses. just carry on, nothing bad will happen.
prabhakarlad has quit [Quit: Client closed]
<coldspark29[m]>
JosefHolzmayrThe: I know that nothing bad will happen, but it doesn't span over the whole screen and I don't find what I am looking for anyway. I would rather use xconfig
<coldspark29[m]>
But that doesn't work
<JosefHolzmayrThe>
"/" will let you search
<qschulz>
coldspark29[m]: I use menuconfig from the Linux kernel git repo checked out at the correct commit
<qschulz>
don't use vim to change defconfig
<qschulz>
coldspark29[m]: I guess it's something to do with the number of columns in the terminal
<coldspark29[m]>
qschulz: I never had problems on my host though
<coldspark29[m]>
I will check out mainline Linux and test
<coldspark29[m]>
So no issues on my host with mainline Linux
<coldspark29[m]>
So either a bitbake or Pyrex problem
<coldspark29[m]>
Unfortunatley I can't test bitbake on my host, because it says glibc-2.34 was missing
zpfvo has quit [Ping timeout: 240 seconds]
zpfvo has joined #yocto
zpfvo has quit [Ping timeout: 240 seconds]
zpfvo has joined #yocto
zpfvo has quit [Ping timeout: 268 seconds]
zpfvo has joined #yocto
michalkotyla has quit [Ping timeout: 256 seconds]
goliath has joined #yocto
luc4 has quit [Read error: Connection reset by peer]
luc4 has joined #yocto
michalkotyla has joined #yocto
rob_w has quit [Ping timeout: 240 seconds]
rr12zer has quit [Ping timeout: 256 seconds]
GNUmoon has quit [Remote host closed the connection]
GNUmoon has joined #yocto
rob_w has joined #yocto
<RP>
Saur: Is there something I'm missing about this proposed fetcher from axis?
davidinux has quit [Ping timeout: 256 seconds]
michalkotyla has quit [Ping timeout: 240 seconds]
karl has quit [Remote host closed the connection]
karl has joined #yocto
davidinux has joined #yocto
michalkotyla has joined #yocto
<Saur>
RP: I have not been involved in that work, but as far as I understand the idea is to let a layer repository be a superrepo. I.e., say we have a recipe foo.bb that uses the submodule: fetcher, then the repository used by the foo recipe is a submodule _of the layer repository_. I.e, for any given version of the layer repository the version of the foo repository is also well defined.
michalkotyla_ has joined #yocto
michalkotyla has quit [Ping timeout: 268 seconds]
<qschulz>
this looks like it's something that repo should be doing, not bitbake?
<qschulz>
(repo in Google Repo tool)
<Saur>
qschulz: The idea is if you have 1000s of recipes, you only want to fetch the submodules for the recipes that you actually build.
<Saur>
And you do not want to fetch them at all if you build from sstate.
<frosteyes>
coldspark29[m]: I have had similar problems inside docker etc. A solution for me have been to set TERM=screen as environment variable.
<coldspark29[m]>
frosteyes: In Docker or the host?
<frosteyes>
like docker exec -it -e TERM=screen yocto bash
<coldspark29[m]>
So it should be fixed in Pyrex I guess. qschulz ?
zpfvo has quit [Ping timeout: 240 seconds]
<frosteyes>
If I connect to a docker container named yocto and start bash with TERM set to screen for the environment variable. screen then handle the ncurses part.
zpfvo has joined #yocto
zpfvo has quit [Ping timeout: 268 seconds]
zpfvo has joined #yocto
<qschulz>
coldspark29[m]: on your host, can you do echo $TERM?
<coldspark29[m]>
xterm-256color
<qschulz>
coldspark29[m]: do you not have a TERM has an unrecognized value of... when starting the container?
<qschulz>
I had the issue with alacritty
<coldspark29[m]>
qschulz: What do you mean?
<coldspark29[m]>
Not sure
<coldspark29[m]>
I use Konsole
<coldspark29[m]>
KDE for life
zpfvo has quit [Ping timeout: 268 seconds]
zpfvo has joined #yocto
<qschulz>
coldspark29[m]: when you source the pyrex script or execute a bitbake command, is there a warning message somewhere?
<coldspark29[m]>
qschulz: No haven't seen anything
<coldspark29[m]>
When sourcing I don't remember. Let me check
<coldspark29[m]>
No nothing
camus has quit [Ping timeout: 256 seconds]
camus has joined #yocto
<qschulz>
ok, then it might just be a missing package or something
<RP>
Saur: oh, I see. So the idea is a the layer itself has submodules pointing at the actual source code. That is horrible :(
<rburton>
do we support out of tree fetchers yet
<rburton>
and i feel this is a good reason to enable them if not :)
<coldspark29[m]>
<qschulz> "ok, then it might just be a..." <- Should I make an issue?
<RP>
rburton: crate fetcher is a working example
<Saur>
RP: I didn't say I liked the idea, because I find it horrible as well...
<qschulz>
coldspark29[m]: I don't know, I'm just a user of Pyrex :)
<qschulz>
I contributed/complained about a thing or two to make it work with zsh and podman but that's it
<rfs613>
coldspark29[m]: I'm not using pyrex, but I see similar issue as you when trying to run menuconfig via bitbake.
<rfs613>
changing TERM between screen/xterm and -256color does not change the behaviour
<rfs613>
but running "make ARCH=arm menuconfig" directly in the kernel source dir works correctly.
prabhakarlad has joined #yocto
<coldspark29[m]>
Any idea how to reset environment variables in U-Boot? It doesn't load my default variables on boot. When I enter `env default -a`, I get the defaults, but they are not loaded on boot. I already tried `saveenv`
<coldspark29[m]>
<rfs613> "coldspark29: I'm not using pyrex..." <- But Docker I assume?
mvlad has joined #yocto
<qschulz>
coldspark29[m]: the board file can override environment variables at boot, but you'll have more luck on #u-boot
<coldspark29[m]>
But I hate IRC haha
<coldspark29[m]>
I don't get how it works
claussenj has joined #yocto
claussenj has quit [Client Quit]
coldspark29 has joined #yocto
<coldspark29>
Test
<coldspark29[m]>
Ah interesting
<coldspark29[m]>
This is a Matrix bridge
<Tartarus>
Yeah, there's a bridge for a few OE/Yocto related IRC channels
<coldspark29[m]>
It is creeping me out in IRC that you can't see previous messages
<coldspark29[m]>
It is like talking to a dark cave
<coldspark29[m]>
A dark cave with some connection information written on the wall of course
<JPEW>
Ugh, we have a vendor layer that include all the source code in the layer itself and pulls it in with externalsrc; its' constantly causing problems :(
<JPEW>
I'm not a fan of perpetuating that pattern
<smurray>
JPEW: heh, that's worse than the giant repo scheme with lots of use of file://../../.. that I've seen
luc4 has quit [Read error: Connection reset by peer]
GNUmoon has quit [Ping timeout: 276 seconds]
camus1 has joined #yocto
camus has quit [Ping timeout: 256 seconds]
camus1 is now known as camus
luc4 has joined #yocto
vd has joined #yocto
pgowda_ has quit [Quit: Connection closed for inactivity]
florian has quit [Quit: Ex-Chat]
<vd>
is it a good practice to have uppercase distro/machine features? I want to easily identify custom (company) features but a prefix can be a bit cumbersome. What are the general recommendations for such custom features?
<rburton>
do that if you want i guess
GNUmoon has joined #yocto
<vd>
when you need to "harden" an image for releases or customer-faced systems, do you usually define an hardened machine configuration or an hardened distro (or distro feature)?
<vd>
(assuming it cannot be done at the image level because there are some kernel/bootloader/distro-wide implications for example)
<rburton>
distro
<vd>
makes sense
prabhakarlad has joined #yocto
<vd>
rburton with e.g. a distro class overrides and a few :df-hardened overrides in recipes
<vd>
and same for development with e.g. a "debug" distro override
<rburton>
personally, if you've a distro, just harden by default
<vd>
rburton: I see, you prefer to explicit the debug state
<vd>
would it make sense to define a "dev" variant for the machine you're working on or a dev distro variant often suffice?
grma has quit []
grma has joined #yocto
<qschulz>
vd: do NOT start a machine name with an uppercase letter
<rfs613>
does the prefix "mc:k3r5" in front of many recipies have some significance? some kind of namespace maybe?
<qschulz>
honestly, I've banned uppercase letters and underscores just to be on the safe side
<qschulz>
rfs613: it's multiconfig syntax
<rfs613>
qschulz: ah, thanks.
<qschulz>
vd: ah never mind, read machine conf instead of machine features
<vd>
I feel like development/debug/release profile (or whatever you name it) is more than just a distro feature, but more a combined machine/distro feature. e.g. a development environment must be enabled on both a developer-friendly hardware as well as being a software (distro) choice
Minvera has quit [Remote host closed the connection]
Minvera has joined #yocto
<RP>
zeddii: I assume I can remove that python3 module you added for the kernel? I don't think it is actually needed and it saves me trying to resolve the license issue
<RP>
zeddii: ah, I just saw qschulz's reply :( Why is this not building in places I'd expect then? :/
<RP>
oh, probably as it only needs the native version. That would explain things
troth has joined #yocto
otavio has quit [Remote host closed the connection]
rfuentess has quit [Remote host closed the connection]
sakoman has joined #yocto
coldspark29 has quit [Remote host closed the connection]
coldspark29 has joined #yocto
otavio has joined #yocto
tlwoerner has quit [Ping timeout: 268 seconds]
tlwoerner has joined #yocto
prabhakarlad has quit [Quit: Client closed]
lucaceresoli has quit [Ping timeout: 240 seconds]
<sgw>
RP: is there a way to limit a warning to one time from anonymous python? kind of like the kernel's warn_once()?
<sgw>
short of touching some file to check and slow everything down!
amitk_ has joined #yocto
amitk has quit [Ping timeout: 268 seconds]
davidinux has quit [Ping timeout: 256 seconds]
dev1990 has joined #yocto
<rburton>
sgw: you can set a unique variable in d as a token
mvlad has quit [Remote host closed the connection]
<sgw>
rburton: I guess that's an option, is there an existing pattern to replicate?
dmoseley has quit [Ping timeout: 240 seconds]
dmoseley has joined #yocto
leon-anavi has joined #yocto
<RP>
sgw: no existing pattern I know of
<sgw>
RP thanks
kanavin has quit [Remote host closed the connection]
kanavin has joined #yocto
marka has quit [Ping timeout: 268 seconds]
marka has joined #yocto
<wyre>
hi guys, could I set the password in a separate file for dealing with root setting password?
<wyre>
but ... I wouldn't like to set the pass in the recipe file because I'm doing scv with git
<wyre>
so I guess I could do the recipe to fetch the password form a separate file, right?
<Saur>
wyre: That page is a bit obsolete. The nonstandard -P option has been removed again. Use -p instead, which takes a hashed value.
<wyre>
I see
<wyre>
tyvm Saur 😉
<wyre>
Saur, with md5 for example?
<Saur>
wyre: I just updated the wiki page.
<sgw>
wyre: Where are you setting the EXTRA_USERS_PARAM? In your local.conf, which you are maintain with GIT?
<sgw>
You could have your local.conf include another file containing the EXTRA_USERS_PARAM variable if needed.
<sgw>
Saur: you beat me to it! I would have updated it you did not, I also like the python solution vs adding the mcrypt package.
<Saur>
sgw: :)
Minvera has quit [Remote host closed the connection]
Minvera has joined #yocto
<wyre>
Saur, thank you again 😊
Minvera has quit [Quit: Leaving]
kriive has quit [Remote host closed the connection]
ahs3 has quit [Remote host closed the connection]
<khem>
marc1: it did not build for non fsl socs so even though it is a generic kind of, it perhaps is not tested for other socs so point was to limit it to where its tested
<wyre>
what's apt package for?
<wyre>
apparently 'apt' command is not able though I've included it in my image recipe ..
<khem>
marc1: regardless its Freescale/NXP I.MX Chip image deploy tool
camus1 has joined #yocto
camus has quit [Remote host closed the connection]
camus1 is now known as camus
<wyre>
Saur, I think you can also use 'openssl passwd -5 <your pass>', btw