fitzsim has quit [Remote host closed the connection]
sgw has joined #yocto
fitzsim has joined #yocto
xmn has joined #yocto
jclsn7 has quit [Ping timeout: 272 seconds]
jclsn7 has joined #yocto
jclsn7 has quit [Ping timeout: 240 seconds]
camus has quit [Ping timeout: 256 seconds]
jclsn7 has joined #yocto
camus has joined #yocto
camus has quit [Ping timeout: 240 seconds]
camus has joined #yocto
starblue has quit [Ping timeout: 272 seconds]
starblue has joined #yocto
jclsn7 has quit [Quit: Ping timeout (120 seconds)]
jclsn7 has joined #yocto
sakoman has joined #yocto
camus1 has joined #yocto
camus has quit [Ping timeout: 240 seconds]
camus1 is now known as camus
jclsn7 has quit [Ping timeout: 256 seconds]
jclsn7 has joined #yocto
camus has quit [Ping timeout: 256 seconds]
camus has joined #yocto
jclsn7 has quit [Ping timeout: 256 seconds]
jclsn7 has joined #yocto
jclsn7 has quit [Ping timeout: 272 seconds]
jclsn7 has joined #yocto
jclsn7 has quit [Ping timeout: 256 seconds]
jclsn7 has joined #yocto
jclsn7 has quit [Ping timeout: 256 seconds]
jclsn7 has joined #yocto
jclsn7 has quit [Ping timeout: 256 seconds]
jclsn7 has joined #yocto
GNUmoon has quit [Remote host closed the connection]
GNUmoon has joined #yocto
sakoman has quit [Quit: Leaving.]
wooosaiiii has quit [Remote host closed the connection]
wooosaiiii has joined #yocto
amitk has joined #yocto
xmn has quit [Ping timeout: 256 seconds]
pgowda_ has joined #yocto
GNUmoon has quit [Ping timeout: 240 seconds]
Guest77 has joined #yocto
Guest77 has quit [Client Quit]
alessioigor has joined #yocto
alessioigor has quit [Client Quit]
Etheryon has joined #yocto
Habbie has quit [Ping timeout: 240 seconds]
Habbie has joined #yocto
GNUmoon has joined #yocto
rob_w has joined #yocto
leon-anavi has joined #yocto
tgamblin has quit [Ping timeout: 240 seconds]
tgamblin has joined #yocto
rfuentess has joined #yocto
goliath has joined #yocto
mckoan|away is now known as mckoan
<mckoan>
good morning
Schlumpf has joined #yocto
Guest76 has joined #yocto
<Guest76>
Hi there, I just want to double check, it seems that kirkstone is the future LTS, can you confirm that Dunfell will be LTS just as long as Kirkston, up to April 2024?
<landgraf>
Guest76: or Kirkstone LTS will be extended (if there will be demand) afaik
<mckoan>
Guest76: yes, it is writtend in the docs Dunfell will be LTS up to 2024
<Guest76>
Yes I saw that in the releases page, it was just to double check!
<mckoan>
landgraf: this is a question for RP
goliath has quit [Quit: SIGSEGV]
<landgraf>
mckoan: right.
<Guest76>
For new project on IMX6, you would go for Dunfell right? It's what's currently integrated by NXP.
<Guest76>
My client asked me to integrate IMX6 on Yocto Kirkston, I'm not really sure that this is worth the effort
<Guest76>
considering that both are LTS up to april 2024 and that NXP will probably do a much better job at integrating their SoCs in Yocto right?
<Guest76>
(I'm a one man company x])
frieder has joined #yocto
manuel1985 has joined #yocto
<mckoan>
Guest76: NXP is not following LTS policy
<Guest76>
Oh right? They are currently on Dunfell, I've never experienced being in a non LTS version with a BSP from NXP.
<Guest76>
There's probably a delay though
<mckoan>
Guest76: official NXP support is based on Zeus and Hardknott
<mckoan>
Guest76: NXP Community support is following thw YP roadmap
<mckoan>
Guest76: ask to your NXP FAE
mvlad has joined #yocto
<Guest76>
I'm on community version anyway
<Guest76>
thanks for the clarification though
<RP>
Guest76: We don't know if kirkstone will be extended or not, dunfell will certainly not go any longer. I'd recommend using the latest you can
<Guest76>
ok thanks a lot :)
Emantor[m] has quit [Quit: You have been kicked for being idle]
lucaceresoli has joined #yocto
florian has joined #yocto
dev1990 has joined #yocto
goliath has joined #yocto
Thorn_ has quit [Ping timeout: 240 seconds]
Thorn has joined #yocto
pasherring has joined #yocto
frieder has quit [Remote host closed the connection]
frieder has joined #yocto
frieder_ has joined #yocto
frieder has quit [Read error: Connection reset by peer]
frieder_ has quit [Remote host closed the connection]
frieder has joined #yocto
frieder has quit [Read error: Connection reset by peer]
frieder has joined #yocto
testology has joined #yocto
testology has left #yocto [#yocto]
<LetoThe2nd>
yo dudX
<qschulz>
o/
<LetoThe2nd>
\o
GNUmoon has quit [Ping timeout: 240 seconds]
GNUmoon has joined #yocto
dlan has quit [Ping timeout: 256 seconds]
dlan has joined #yocto
pgowda_ has quit [Quit: Connection closed for inactivity]
starblue has quit [Ping timeout: 256 seconds]
starblue has joined #yocto
dev1990_ has joined #yocto
dev1990 has quit [Ping timeout: 252 seconds]
mandateless[m] has joined #yocto
rfuentess has quit [Remote host closed the connection]
ds81 has joined #yocto
pgowda_ has joined #yocto
mckoan is now known as mckoan|away
pabigot has quit [Remote host closed the connection]
pabigot has joined #yocto
GNUmoon has quit [Ping timeout: 240 seconds]
GNUmoon has joined #yocto
georgem has joined #yocto
Schlumpf has quit [Quit: Client closed]
lehmrob has joined #yocto
pasherring has quit [Remote host closed the connection]
pasherring has joined #yocto
turquoisetree has joined #yocto
sakoman has joined #yocto
<turquoisetree>
Hello guys, I am trying to enable uinput, but if I say ":~# modinfo uinput" on the target, it will just error out: "modinfo: ERROR: Module uinput not found."
<turquoisetree>
What am I missing?
<turquoisetree>
Isn't it sufficient to enable CONFIG_INPUT_UINPUT?
<qschulz>
turquoisetree: 1) for modinfo to work, uinput needs to be built as a module
<qschulz>
so "m" in Kconfig/defconfig/.config
<qschulz>
2) if your kernel driver is "y", then it's built-in the kernel and nothing special needs to be done to have it included
<turquoisetree>
I see, thank you. It is set to "y"
<qschulz>
if it's "m", you need to include the kernel module package to your image. oe-pkgdata-util find-path '*uinput*' should give you some clue which package should be brought in
<qschulz>
worst case scenario, you can always add kernel-modules to your image and all modules will be added to your image
<turquoisetree>
What confuses me is that I can read events, but not inject them.
<turquoisetree>
I have tried it with pythons evdev package with no success.
<turquoisetree>
Any idea how I could test, that uinput is correctly "set-up"?
xmn has joined #yocto
codavi has joined #yocto
ar__ has joined #yocto
codavi has quit [Ping timeout: 256 seconds]
mandateless[m] has left #yocto [#yocto]
rfuentess has joined #yocto
Etheryon has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
rob_w has quit [Remote host closed the connection]
YoussefAllagui[m has joined #yocto
Guest76 has quit [Quit: Connection closed]
lucaceresoli has quit [Ping timeout: 240 seconds]
lehmrob has quit [Quit: WeeChat 3.4]
turquoisetree has quit [Quit: Client closed]
sgw has quit [Ping timeout: 240 seconds]
pasherring has quit [Read error: Connection reset by peer]
frieder has quit [Remote host closed the connection]
turquoisetree has quit [Quit: Client closed]
dev1990_ has quit [Ping timeout: 256 seconds]
dev1990_ has joined #yocto
dev1990_ has quit [Read error: Connection reset by peer]
dev1990_ has joined #yocto
sgw has joined #yocto
manuel1985 has quit [Quit: Leaving]
florian has quit [Quit: Ex-Chat]
<agherzan>
JaMa: The usecase I had with the TCLIBC ?= was to be able to override its value from shell env.
<agherzan>
So the idea was to be able to provide a default value in the distro configuration but also let the user override that with a shell env definition through BB_ENV_EXTRAWHITE
<RP>
Saur[m]: sgw: I've put some patched into master-next to try and move things forward, still debugging them though
<agherzan>
Now being forced to `=` - as per the side effect of the move - I can't provide that ability anymore because the distro file will override any cmdline definition/env variable.
geoffhp has joined #yocto
rfuentess has quit [Remote host closed the connection]
pgowda_ has quit [Quit: Connection closed for inactivity]
goliath has joined #yocto
Ebeneezer_Smooge has joined #yocto
cb5r has joined #yocto
<sgw>
Morning RP: I see you and Saur[m] have been busy! Did you see my v3 patchset of 2 for the re-work, given the other changes, I probably need to rebase it against master-next
<RP>
sgw: not sure. master-next is broken though :(
pasherring has quit [Remote host closed the connection]
cb5r_ has joined #yocto
cb5r has quit [Ping timeout: 245 seconds]
cb5r_ is now known as cb5r
ds81 has quit [Quit: leaving]
lucaceresoli has joined #yocto
florian has joined #yocto
lucaceresoli has quit [Quit: Leaving]
<Saur[m]>
RP: If you are removing the generic support for wildcards in the license lists, is there any real reason to keep those pseudo wildcards for "GPL-3.0*" and "LGPL-3.0*"? To me they are more confusing than beneficial since previously "GPL-3.0*" would have expanded to "GPL-3.0-only GPL-3.0-or-later GPL-3.0-with-autoconf-exception GPL-3.0-with-GCC-exception". And I can imagine all sorts of variants of "*GPL-3*", "*GPL-3.0*", "*GPL-3.0", etc being in
<Saur[m]>
use.
ar__ has quit [Read error: Connection reset by peer]
<khem>
I think there is a use of having something on top level to ignore/include all or none of GPL3 family of licenses
<Saur[m]>
Well, it is not match harder to write "GPL-3.0-only GPL-3.0-or-later LGPL-3.0-only LGPL-3.0-or-later" than "GPL-3.0* LGPL-3.0*".
<Saur[m]>
much harder*
<khem>
nothing is harder, once you know about things, but many folks do not know about such nuances, and they keep changing too
<Saur[m]>
Well, with RP's latest changes, there is now an error message if you use any pattern in the incompatible licenses except "GPL-3.0*" and "LGPL-3.0*". But with that error message in place I think we could just as well remove the remaining two as well. Especially as at least I find it confusing that "GPL-3.0*" now will expand to "GPL-3.0-only GPL-3.0-or-later" rather than "GPL-3.0-only GPL-3.0-or-later GPL-3.0-with-autoconf-exception
<Saur[m]>
GPL-3.0-with-GCC-exception" as it did before.
dev1990_ has quit [Quit: Konversation terminated!]
sakoman has quit [Quit: Leaving.]
florian has quit [Ping timeout: 240 seconds]
leon-anavi has quit [Quit: Leaving]
dev1990 has joined #yocto
<rfs613>
beginner question... building core-image-minimal ... I see it compiling sqlite3, various X11-related stuffs including libx11, perl, ... is this normal for "minimal" ?
<derRichard>
rfs613: yes. please note that not everything that gets build is also installed on the final rootfs
<Saur[m]>
rfs613: It is quite common to have to build more than what is needed for the image you are building. Consider a recipe foo that in addition to the main package foo also produces a package called foo-scripts. This latter package contains some Perl scripts and thus depends on perl. Regardless if you are going to install foo-scripts in your image, bitbake has to build it and thus has to build its dependencies.
<rfs613>
ok, but this has an interesting "side-effect" for CVE checking: on the first build, a whole lot of extra stuff may get built, and CVEs therein get reported. On subsequent builds (when you clean out "tmp" but keep sstate_cache) it only seems to do CVE checks on the packages actually installed.
florian has joined #yocto
alessioigor has joined #yocto
alessioigor has quit [Client Quit]
<derRichard>
rfs613: i fear the cve checking logic is not perfect (yet)
cb5r has quit [Ping timeout: 272 seconds]
<khem>
well a lot of these packages are needed to build the target packages, so if you see a bunch of native recipes in build thats what it is doing
<rfs613>
derRichard: it seems the checking currently happens alonside the unpack/patch steps... I wonder if it could instead be triggred by the do_install somehow?
<derRichard>
dunno :)
<rfs613>
khem: the -native ones are fairly easy to ignore in the cve-check output... but I certainly watched it build libx11 for the target, and dozens more, none of which are in the resulting filesystem
<khem>
rfs613: if your distro is including ptest in distro_feature then it pulls in some perl packages which create a huge set of dependencies even it will try to build target toolchain etc. I would suggest to add DISTRO_FEATRUES:remove = "ptest" and try
<rfs613>
also to be clear, I'm not looking for a quick fix here, I am more curious if others have the same concern about cve-check, and whether we want to try an see if it can be improved.
<rfs613>
I'd offer patches but my python is still pretty weak, and I think there needs to be some idea of what the correct behaviour should be, before I make any attempts to implement...
<khem>
yeah it will be good to be more objective and consistent with the check no matter if it is first or reused from sstate
Wouter0100 has quit [Read error: Connection reset by peer]
Wouter0100 has joined #yocto
GNUmoon has quit [Ping timeout: 240 seconds]
janvermaete[m] has joined #yocto
kevinrowland has joined #yocto
florian has quit [Ping timeout: 240 seconds]
dmoseley has quit [Ping timeout: 252 seconds]
amitk has quit [Ping timeout: 272 seconds]
GNUmoon has joined #yocto
florian has joined #yocto
creich_ has quit [Quit: Leaving]
creich has joined #yocto
prabhakarlad has quit [Quit: Client closed]
dmoseley has joined #yocto
prabhakarlad has joined #yocto
dmoseley has quit [Ping timeout: 272 seconds]
goliath has quit [Quit: SIGSEGV]
<RP>
Saur[m]: How many people actually list/want the exception licenses in INCOMPATIBLE_LICENSE in the first place though?
mvlad has quit [Remote host closed the connection]
dmoseley has joined #yocto
<agherzan>
go recipes fail after the advent of network restriction in do_compile