Thorn has quit [Read error: Connection reset by peer]
Tokamak has joined #yocto
florian_kc has joined #yocto
florian_kc has quit [Ping timeout: 240 seconds]
geoffhp has quit [Remote host closed the connection]
Tokamak has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
GNUmoon has quit [Remote host closed the connection]
GNUmoon has joined #yocto
dev1990 has quit [Quit: Konversation terminated!]
paulg has joined #yocto
amitk has joined #yocto
GNUmoon2 has joined #yocto
GNUmoon has quit [Ping timeout: 276 seconds]
davidinux has quit [Ping timeout: 268 seconds]
davidinux has joined #yocto
Vonter has joined #yocto
goliath has joined #yocto
GNUmoon2 has quit [Ping timeout: 276 seconds]
osama has joined #yocto
JaMa has joined #yocto
alessioigor has joined #yocto
alessioigor has quit [Client Quit]
alessioigor has joined #yocto
frieder has joined #yocto
osama has quit [Ping timeout: 256 seconds]
mckoan|away is now known as mckoan
<mckoan>
good morning
rob_w has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
lucaceresoli has joined #yocto
alessioigor has quit [Client Quit]
GNUmoon2 has joined #yocto
Vonter has quit [Ping timeout: 240 seconds]
zpfvo has joined #yocto
Vonter has joined #yocto
kroon has joined #yocto
rfuentess has joined #yocto
mvlad has joined #yocto
zpfvo has quit [Ping timeout: 256 seconds]
zpfvo has joined #yocto
GillesM has joined #yocto
GillesM has quit [Remote host closed the connection]
zpfvo has quit [Remote host closed the connection]
zpfvo has joined #yocto
dev1990 has joined #yocto
<qschulz>
mornin
<alejandrohs>
qschulz: morning
Etheryon has joined #yocto
<Etheryon>
Hi all, I'm looking for some help if anyone maybe ran into the same issues. I'm trying to build an image that I'm running on a vm but I can't seem to get the framebuffer working. I've scoured the internet for resources, but no luck so far
<mckoan>
Etheryon: describe the problem
<Etheryon>
I can't get a /dev/fb0 to show up (for reference I'm trying to build a distro to run eglfs qt applications)
<Etheryon>
I'm still learning all this so even some pointers where to dig would be useful, thakns
<Etheryon>
I've tried with both the meta-intel intel-corei7-64machine and generic x86-64
<Etheryon>
I'm not even sure if the issue could be that I'm using a vm (in virtualbox)
<Etheryon>
I'm booting of a live iso, if that makes any difference
florian has joined #yocto
<Etheryon>
I have removed x11 and wayland from the image
<mckoan>
Etheryon: for x86 you need X11 and/or wayland, try using core-image-sato as starting point
zpfvo has joined #yocto
<mckoan>
coldspark29[m]: hard to guess
<Etheryon>
mckoan Thanks! So there's no way of using the framebuffer without one of those?
zpfvo has quit [Ping timeout: 256 seconds]
zpfvo has joined #yocto
<mckoan>
Etheryon: in case "linuxfb" not "eglfs", however I usually use X11/Wayland
kroon_ has joined #yocto
kroon has quit [Ping timeout: 256 seconds]
leon-anavi has joined #yocto
<coldspark29[m]>
<mckoan> "coldspark29: hard to guess" <- It is weird because this didn't happen before
<coldspark29[m]>
The directory where bitbake searches the license is empty
prabhakarlad has joined #yocto
zpfvo has quit [Ping timeout: 240 seconds]
zpfvo has joined #yocto
Etheryon has quit [Ping timeout: 256 seconds]
zpfvo has quit [Ping timeout: 240 seconds]
zpfvo has joined #yocto
zyga-mbp has joined #yocto
jmiehe has joined #yocto
Guest36 has joined #yocto
Guest36 has quit [Ping timeout: 256 seconds]
zpfvo has quit [Ping timeout: 256 seconds]
zpfvo has joined #yocto
Schlumpf has joined #yocto
zpfvo has quit [Ping timeout: 268 seconds]
zpfvo has joined #yocto
Vonter has quit [Ping timeout: 240 seconds]
Vonter has joined #yocto
<qschulz>
coldspark29[m]: what's the path in LIC_FILES_CHKSUM exacrtly?
<qschulz>
(before expansion)
zpfvo has quit [Ping timeout: 256 seconds]
zpfvo has joined #yocto
zpfvo has quit [Ping timeout: 240 seconds]
zpfvo has joined #yocto
<rburton>
RP: just one new CVE, in libtiff. there's a patch in-progress but it's got feedback so I won't pick it just yet.
<RP>
rburton: It was nice to see the numbers go down for master! :)
<kanavin>
rburton, I looked at that too, what do we do about CVEs that remain unaddressed?
<kanavin>
e.g. what if this tiff thing is never fixed?
<rburton>
well, this one will be fixed as there's active work
<rburton>
we have to decide if its not a problem (there's a load of qemu issues which we have done that with), or we just leave them open and the user can decide what to do
<rburton>
if upstream is dead but its a core component, some other distro may have patched it already
<kanavin>
I mean, there are 6 open CVEs for master, and except for tiff, all are old and never got a proper fix seemingly
<RP>
kanavin: some are just deemed low priority upstream. I did create some entries in the inc file to cover cases like this
<rburton>
that's cve-extra-exclusions.inc
<RP>
kanavin: 6 is as low as we've ever got it down to
<kanavin>
RP: right, I just like empty lists (e.g. reproducibility ;)
<RP>
kanavin: so do I, hence that inc :)
<RP>
kanavin: it may not be realistic in this case :/
<kanavin>
RP: maybe some users may need a bit of education, an open CVE does not mean the product is insecure, or urgent action required or anything like that
<RP>
kanavin: Right, it is a tracking mechanism and just means there is something you may need to check/understand
<kanavin>
RP: nice spreadsheet - I also find it peculiar how clearly it shows that the older your yocto version is, the more open CVEs there are
<kanavin>
'staying close to upstream is good for you' in a shape of a graph
davidinux has quit [Quit: WeeChat 2.8]
<RP>
kanavin: what it doesn't show well is how many get addressed :/
<rburton>
add 'known CVEs' the chart?
<kanavin>
er, first derivative would?
<kanavin>
my calculus is a rust-land nowadays
davidinux has joined #yocto
<RP>
kanavin: sadly not :/
<RP>
rburton: I'm not sure how you'd get a meaningful number - how do we get a number for "these are the ones we fixed" ?
Schlumpf has quit [Ping timeout: 256 seconds]
zpfvo has quit [Ping timeout: 240 seconds]
zpfvo has joined #yocto
<coldspark29[m]>
<qschulz> "coldspark29: what's the path..." <- `LIC_FILES_CHKSUM = "file://COPYING;md5=6bc538ed5bd9a7fc9398086aedcd7e46"`
zpfvo has quit [Ping timeout: 240 seconds]
<coldspark29[m]>
The same as in linux-fslc-imx_5.10.bb
zpfvo has joined #yocto
Schlumpf has joined #yocto
<coldspark29[m]>
I also don't understand how this kernel is stitched together from three different sources. I already asked Andrey Zhizhkin, but he does not reply
<coldspark29[m]>
Oh I included the wrong file
<coldspark29[m]>
Got it
<OutBackDingo>
so DISTRO_FEATURES_APPEND = has become DISTRO:FEATURES:append ??
<rburton>
DISTRO_FEATURES:append
<rburton>
and the original was DISTRO_FEATURES_append
<rburton>
the variable is called DISTRO_FEATURES, and you were appending it
<rburton>
and here you see the confusion and why the operator was changed to :
<OutBackDingo>
LOL yeah okj typoed that one i have DISTRO_FEATURES:append
<OutBackDingo>
to core-image-minimal-xfce... boots to xfce fine but no sshd listening
<rburton>
are you looking for a sshd process? systemd will listen on the socket and start sshd on demand.
<OutBackDingo>
i cant ssh in to look :)
<rburton>
check the image manifest to verify that openssh-sshd is installed
<OutBackDingo>
rburton: sorry ? where is this "manifest" in tmp ?
<coldspark29[m]>
qschulz: I also don't understand that in the original there is a `file://defconfig`in the SRC_URI and this doesn't work in my copied version. Bitbake complains that there is no defconfig. Where does bitbake expect it to be? There is one in `linux-fslc-imx/mx8/defconfig`but copying it over still doesn't let bitbake find it
<coldspark29[m]>
qschulz: Guess I forgot a `:`at the end of `MACHINEOVERRIDES =. "imx-boot-container:mx8:mx8m:mx8mm:mymachine"?
zpfvo has joined #yocto
<coldspark29[m]>
It returned `OVERRIDES="runtime-gnu:toolchain-gcc:linux:aarch64:pn-defaultpkgname:aarch64:armv8a:use-mainline-bsp:imx-boot-container:mymachinemymachine:fslc:class-target:libc-glibc:forcevariable"`
<coldspark29[m]>
It works when I put an `:`at the end, but then I have the `mymachine`override listed twice
<coldspark29[m]>
I guess I don't need to list it in `MACHINEOVERRIDES` at all...
<coldspark29[m]>
Man, what a missing `:` can do in bitbake. I was searching for this error for days
zpfvo has quit [Ping timeout: 256 seconds]
<qschulz>
coldspark29[m]: no need to add your machine name to MACHINEOVERRIDES because it's already in there
<coldspark29[m]>
Is there any way I can tell bitbake to show me the live build output for a recipe?
<coldspark29[m]>
Ah yes thanks
<qschulz>
coldspark29[m]: no idea, but you do have the logs in $WORKDIR/temp/ for each recipe though
zpfvo has quit [Ping timeout: 240 seconds]
zpfvo has joined #yocto
zpfvo has quit [Ping timeout: 268 seconds]
zpfvo has joined #yocto
davidinux has quit [Ping timeout: 240 seconds]
davidinux has joined #yocto
michalkotyla_ has quit [Quit: michalkotyla_]
davidinux has quit [Ping timeout: 256 seconds]
davidinux has joined #yocto
ar__ has joined #yocto
sakoman has joined #yocto
<coldspark29[m]>
qschulz: So I have one remaining question. Since the linux-fslc-imx kernel is comprised of linux-imx and linux-fslc plus community patches, where do I have to apply my custom patches that I have previously applied to linux-imx in 5.4? Andrey writes patches should be applied to linux-fslc... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/75a31d3ab5802296fa283f8738792e75d2a4765d)
<coldspark29[m]>
I guess I need to apply those patches to linux-imx like before, because when I apply them to linux-fslc, make is complaining that there are headers from linux-imx missing for our custom patches.
zpfvo has quit [Ping timeout: 256 seconds]
<qschulz>
coldspark29[m]: devtool modify linux-fslc-imx and then patch from the workspace
zpfvo has joined #yocto
<coldspark29[m]>
qschulz: What do you mean by "patch form the workspace"?
<qschulz>
coldspark29[m] devtool modify creates a workspace
<coldspark29[m]>
qschulz: I already created copies of the recipe in our custon layer by hand
<coldspark29[m]>
but I guess there is a more elegant way...
<qschulz>
coldspark29[m]: are you going to use their layer or not?
<coldspark29[m]>
Guess I have to read more in the docs
<coldspark29[m]>
Yes
<qschulz>
then why do you copy the recipe?
<qschulz>
just append to it
<rfs613>
recently, the kernel recipie has started failing on me. Upon investigation, it's the do_validate_branches() function, and specifically the "git checkout -q -f ${machine_branch}" step, where mainline_branch is "master", however my kernel repo doesn't have such a named branch (I'm building on a different branch specified in the SRC_URI)
<rfs613>
the odd part is the problem is intermittent: one build will abort, trying again immediately, it will succeed.
<rfs613>
anybody else encountering this?
Vonter has quit [Ping timeout: 240 seconds]
<coldspark29[m]>
qschulz: Because the .bb file itself doesn't contain any links to git repositores, but includes two files, namely linux-fslc.inc and linux-imx.inc and I did not think you could create .incappend files to change those urls. We want to use our own Gitlab repositories and apply the patches to those
codavi has joined #yocto
huseyinkozan has joined #yocto
<coldspark29[m]>
God, now he fsl-imx8mm.dtsi has a syntax error although I just copied it over from linux-imx...
<coldspark29[m]>
This is really complcated
<coldspark29[m]>
Before we just added our two drivers and our device tree to the linux-imx kernel
ar__ has quit [Ping timeout: 268 seconds]
<qschulz>
coldspark29[m]: bbappend applies to the whole recipe,m after bbclasses and inc files are included
<qschulz>
so you can modify the URL from a bbappend
<coldspark29[m]>
qschulz: But there are two SRC_URIs
<coldspark29[m]>
How to modify both with on .bbappend??
<qschulz>
coldspark29[m]: no there's only one, with multiple values in it, probably
<qschulz>
coldspark29[m]: me neither, vendor stuff
<coldspark29[m]>
No this freescale stuff
<rfs613>
coldspark29[m]: there's comments, can't be vendor stuff :-)
huseyinkozan has quit [Remote host closed the connection]
huseyinkozan has joined #yocto
<dwagenk>
https://docs.yoctoproject.org/3.1.13/ docs for dunfell have a little problem: selecting 3.1.13 brings up the documentation for 3.1.12 with the big red banner saying "please use the docs for 3.1.13"
<dwagenk>
^ ping qschulz or who is managing the server for the docs?
<qschulz>
michaelo: halstead: good afternoon/morning. Some issues with the 3.1.13 docs ^
<qschulz>
dwagenk: thanks for the report
marka has quit [Remote host closed the connection]
<moto-timo>
OutBackDingo: the reason is both of these things require more than just the packagegroup...
Minvera has quit [Quit: Leaving]
Minvera has joined #yocto
<OutBackDingo>
moto-timo: and nothing from CORE_IMAGE_EXTRA_INSTALL = " git openssh kubernetes nvidia-docker pip-glances python3-pip " is in the build either
<OutBackDingo>
really odd
vquicksilver has quit [Ping timeout: 252 seconds]
<moto-timo>
what image are you building? if it doesn't inherit core-image then the CORE_IMAGE_EXTRA_INSTALL variable won't be used
<OutBackDingo>
core-image-minimal-xfce
vquicksilver has joined #yocto
<OutBackDingo>
and core-image is included in minimal-xfce
<moto-timo>
OutBackDingo: take out openssh, but more or less yes. kubernetes needs a DISTRO_FEATURE as I recall... and I don't know about nvidia-docker
<moto-timo>
and a lot of setup, but obviously you already know so I won't keep blathering on about it
<OutBackDingo>
moto-timo: thz for the pointer
<moto-timo>
OutBackDingo: you're welcome... that wasn't an obvious one
<OutBackDingo>
thinks core -image-minimal-xfce needs a buggy repoty :0
zpfvo has quit [Ping timeout: 240 seconds]
zpfvo has joined #yocto
<moto-timo>
or just send a patch
goliath has quit [Quit: SIGSEGV]
<OutBackDingo>
moto-timo: true
zpfvo has quit [Ping timeout: 240 seconds]
<moto-timo>
kanavin: I see you have python3-hypothesis python3-setuptools-scm and python3-importlib-metadata staged... do you want me to send the patches or just do your usual patch bomb?
zpfvo has joined #yocto
<rburton>
armpit: are you still the resident expert on check-layer?
goliath has joined #yocto
SunflowerMix has joined #yocto
kroon_ has quit [Quit: Leaving]
<SunflowerMix>
Hey all, it's known practice that you can do something like `MACHINE=x86 bitbake core-image-minimal` to inject the machine value for the build using the CLI instead of having it in `local.conf`
<SunflowerMix>
However the shell introduces limitations to this if there are dashes involved. i.e. this `PREFERRED_VERSION_my-recipe=1.0.0 bitbake core-image-minimal` won't ever reach bitbake
<rburton>
not all variables can do that
<rburton>
see the EXTRAWHITE variable in scripts/oe-buildenv-internal
<SunflowerMix>
Thanks, taking a look...
<SunflowerMix>
I see, so even if the dash "-" wasn't causing the problem for bash there would still be a limit to this.
<SunflowerMix>
Is there a way to workaround this?
<SunflowerMix>
(Context: I want to automate the generation of images which have different combinations of versions of certain userspace apps)
<rburton>
SunflowerMix: write conf/auto.conf
<rburton>
that gets read like local.conf and you can put your vars in there
<SunflowerMix>
That sounds like a good alternative, thanks!
Tokamak has joined #yocto
pnxs has joined #yocto
SunflowerMix has quit [Quit: Client closed]
<coldspark29[m]>
It built! I thought this day would never come 😭
<coldspark29[m]>
Those are tears of joy. Very manly tears of joy...
florian has quit [Quit: Ex-Chat]
<rfs613>
coldspark29[m]: \o/
<rfs613>
glad you got it sorted!
jmiehe has quit [Quit: jmiehe]
<mckoan>
coldspark29[m]: and what was the problem
zpfvo has quit [Quit: Leaving.]
manuel_ has quit [Quit: Leaving]
<coldspark29[m]>
mckoan: Many things. First of all, I did not understand how the defconfigs were served to bitbake, so I chose the wrong defconfig as basis for my changes. Then I used patches from the Android branch, which was wrong and the MACHINEOVERRIDE was wrong, which Quentin helped me sort out.
<coldspark29[m]>
I am still not sure what's the best way of organizing the kernel mod though.
<coldspark29[m]>
Guess I will have to play around a bit and see what's the most convenient.
ardo has quit [Read error: Connection reset by peer]
ardo has joined #yocto
amitk has quit [Ping timeout: 256 seconds]
<kanavin>
moto-timo, please do send patches
<moto-timo>
kanavin: ack
<kanavin>
moto-timo, they're automated patches from AUH and I stage all of it as a last resort in case maintainers neglect their duties ;)
<moto-timo>
kanavin: understood
<kanavin>
moto-timo, of course I know you're not like that :)
<moto-timo>
(and I have been guilty sometimes)
<kanavin>
moto-timo, it'd be better to run auh every other week, not every week
<kanavin>
the churn is a bit too much with the weekly schedule
<kanavin>
but buildbot doesn't allow this because of its scheduler syntax
<moto-timo>
especially for these #&(@# packages like python3-hypothesis that bump a release for every commit
<kanavin>
I feel ya, it's annoying that many python packages go outdated in less than 24 hours!
<moto-timo>
kanavin: I will probably send python3-pyparsing bump as well, because it's in the dependency tree for the PEP 517 work
<moto-timo>
FWIW I run my own AUH builds ~every wednesday, including meta-python and meta-perl... but the amount of recipes that change in meta-python is on the order of 50 per week. Too many for me to properly address on my own.
<moto-timo>
and the ones that are broken take extra care
<moto-timo>
kanavin: one thing I would like to add to AUH is a report of "UNKNOWN_BROKEN"... which tells us the UPSTREAM_CHECK_URI or _REGEX is broken (usually the URI)
<RP>
rburton: I wonder if something else is eating it
<rburton>
runtime tests are serial, right?
<RP>
rburton: yes. I still suspect rngd
frieder has quit [Remote host closed the connection]
lucaceresoli has quit [Ping timeout: 256 seconds]
<rburton>
it does have a lot of allocations
<moto-timo>
kanavin: yes, but it's lost in the logs from AUH runs and I would like it to be highlighted... it's a bug in each recipe no?
<kanavin>
moto-timo, what I mean is tat you can run devtool separately?
<kanavin>
and yes, any appearance of BROKEN means the check isn't working right
<rburton>
RP: but its OOMing during the compile, so its not executed the probe at all
florian_kc has joined #yocto
* moto-timo
just wishing
<moto-timo>
sometimes recipes with bad fetch urls also completely lock up the upgrade script... but I've been trying to catch those and fix
<rburton>
RP: the rss for rngd is tiny
<rburton>
its got a stupid amount of vm allocation but resident is just 407 pages
<RP>
rburton: perhaps I just saw those numbers and wondered what it was doing. Fair enough on the compile, I guess we have to move sdk to more memory :(
<rburton>
always alt though, which is interesting
<rburton>
why doesn't this happen on 5.15
<RP>
rburton: it isn't always alt but much much more frequent
<moto-timo>
but if so, you should be able to "oe-pkgdata-util list-pkgs kernel-module-* | grep btrfs"
<vd>
I see
<vd>
I've added a similar fragment for linux-ti-staging which unfortunately doesn't use the same mechanism
GNUmoon2 has joined #yocto
GNUmoon2 has quit [Ping timeout: 276 seconds]
lucaceresoli has joined #yocto
lucaceresoli has quit [Ping timeout: 240 seconds]
<ziga_>
I create a Yocto image,, mount the SD card and delete all the .dtb files from /boot... Then I try to boot with this SD card and it boots!??? HOW COME? I completely removed the device tree...
<ziga_>
Inn the /boot folder there are currently only files MLO, extlinux, u-boot.img and zImage.
florian_kc has quit [Ping timeout: 240 seconds]
Minvera has quit [Quit: Leaving]
GNUmoon2 has joined #yocto
florian_kc has joined #yocto
dvorkindmitry has quit [Ping timeout: 240 seconds]
florian_kc has quit [Ping timeout: 250 seconds]
florian_kc has joined #yocto
sakoman has quit [Read error: Connection reset by peer]
sakoman has joined #yocto
mvlad has quit [Remote host closed the connection]