<smurray>
RP: okay, I'm about to check out for the evening, but can take a whack at it tomorrow
dev1990 has quit [Quit: Konversation terminated!]
<RP>
Oh, it is because I'm causing errors in the base configuration and this is before knotty has properly started up, therefore the log filtering isn't fully live
* RP
can live with a couple of duplicate lines
<RP>
sgw, smurray: the above commit should apply on top of the bitbake changes in master-next and be usable from there
<sgw>
Looking at this time.
<smurray>
RP: one question wrt having the list of variables in code, would the plan be to variables in oe-core just be added there? (I'd be okay with that, but checking)
<smurray>
err, would the plan be to have variables...
<sgw>
I will give them a try, I started with the earlier patch set and did see a reduction in errors, but will try again with master-next ++
<RP>
smurray: that list is just the bitbake ones, we should be able to add the oe-core ones in the metadata as you originally did using a flags variable
<smurray>
RP: okay
<RP>
smurray: we need the bitbake ones in bitbake so it can scan the enviroment and bail early for those
<smurray>
RP: yeah, I was more thinking about whether we'd need to carry a list of the OE ones in BitBake
<RP>
smurray: we shouldn't have to
<RP>
I think these changes address issues 1+2 in my email. 3 remains and 4 is maybe partly handled
* RP
has best try and sleep
<sgw>
night!
superdupond has quit [Ping timeout: 252 seconds]
florian has quit [Ping timeout: 252 seconds]
prabhakarlad has quit [Ping timeout: 256 seconds]
jqua[m] has joined #yocto
jclsn7 has quit [Ping timeout: 252 seconds]
goliath has quit [Quit: SIGSEGV]
jclsn7 has joined #yocto
jclsn7 has quit [Ping timeout: 252 seconds]
jclsn7 has joined #yocto
qschulz has quit [Quit: qschulz]
mckoan|away has quit [Ping timeout: 240 seconds]
qschulz has joined #yocto
jclsn7 has quit [Ping timeout: 252 seconds]
mckoan|away has joined #yocto
jclsn7 has joined #yocto
jclsn7 has quit [Ping timeout: 252 seconds]
jclsn7 has joined #yocto
sakoman has quit [Quit: Leaving.]
jclsn7 has quit [Ping timeout: 272 seconds]
jclsn7 has joined #yocto
jclsn7 has quit [Ping timeout: 272 seconds]
sakoman has joined #yocto
jclsn7 has joined #yocto
RobertBerger has joined #yocto
rber|res has quit [Ping timeout: 252 seconds]
jclsn7 has quit [Ping timeout: 240 seconds]
jclsn7 has joined #yocto
jclsn7 has quit [Ping timeout: 252 seconds]
jclsn7 has joined #yocto
jclsn7 has quit [Ping timeout: 252 seconds]
jclsn7 has joined #yocto
jclsn7 has quit [Ping timeout: 252 seconds]
jclsn7 has joined #yocto
jclsn7 has quit [Ping timeout: 240 seconds]
jclsn7 has joined #yocto
jclsn7 has quit [Ping timeout: 252 seconds]
jclsn7 has joined #yocto
jclsn7 has quit [Ping timeout: 272 seconds]
amitk has joined #yocto
jclsn7 has joined #yocto
jclsn7 has quit [Ping timeout: 240 seconds]
<zeddii>
khem: I'll have a look at it on Wednesday, that's for the heads up.
jclsn7 has joined #yocto
<zeddii>
s/that's/thanks/
<khem>
cool
silvermane has joined #yocto
sakoman has quit [Quit: Leaving.]
<zeddii>
ok. I identified the commit upstream, it's 5.15.17+, I have it ready and will send tomorrow
silvermane has quit [Quit: Leaving]
Vonter has quit [Ping timeout: 272 seconds]
Vonter has joined #yocto
xmn has joined #yocto
alessioigor has joined #yocto
alessioigor has quit [Client Quit]
jclsn77 has joined #yocto
RobertBerger has quit [Remote host closed the connection]
rber__ has joined #yocto
jclsn7 has quit [Ping timeout: 240 seconds]
jclsn77 is now known as jclsn7
lucaceresoli has quit [Ping timeout: 240 seconds]
Wouter0100 has quit [Remote host closed the connection]
Wouter0100 has joined #yocto
davidinux has quit [Ping timeout: 250 seconds]
davidinux has joined #yocto
GillesM has joined #yocto
GillesM has quit [Client Quit]
GillesM has joined #yocto
GillesM has quit [Client Quit]
GillesM has joined #yocto
mvlad has joined #yocto
rob_w has joined #yocto
goliath has joined #yocto
lucaceresoli has joined #yocto
frieder has joined #yocto
vladest has quit [Quit: vladest]
frieder has quit [Remote host closed the connection]
frieder has joined #yocto
Etheryon has joined #yocto
<jclsn[m]>
Morning guy
<jclsn[m]>
Is anyone experienced with Chromium? It just doesn't run and I have no idea where to start
<ziga_>
Does anybody know how to install DRM test programs. I am looking at the "libdrm" recipe here and I see that "install-test-programs" is a PACKAGECONFIG which is set by default. But I can't see "mmodetest" program on my target. I also tried creating a .bbappend file where I set PACKAGECONFIG:append = " install-test-programs" but the result is the same. No test programs are installed. How can I install "modetest" then?
<qschulz>
ziga_: recipes create packages. You bake recipes and install packages. It happens that the main/default package is named after the recipe but they are different things
<qschulz>
ziga_: when you install libdrm, you install the main package, but there are others too
<ziga_>
I understand. I meant: "I wasn't able to find "libdrm-tests" recipe in the Open Embedded Layer index.
<qschulz>
oe-pkgdata-util find-paht returns the name of the package containing the files you are looking for
<qschulz>
ziga_: you cannot, because the OpenEmbedded layer index returns stable "objects"
<qschulz>
a recipe, a class, a layer, a machine are all "stable"
<qschulz>
but a package isn't
<qschulz>
because a package can or can not be built depending on the distribution, bbappends, machines, etc...
<qschulz>
which means there's no way for us to know in which package the file you're looking for your specific layer+image+distro+machine configuration is
<jclsn[m]>
If `libVIVANTE.so` is not present, it means that the Vivante driver is not installed, doesn't it?
<ziga_>
Ha! So should I rather just use some search tool like "ag-silversearcher" (I recommend) and search the fetched poky repository for recipes? Probably this is the best way then?
<qschulz>
jclsn[m]: libraries aren't from drivers. So you're missing a package that installs this library. oe-pkgdata-util find-path '*libvivante*'
<qschulz>
ziga_: you can find recipes with the OE Layer Index
<qschulz>
you can NOT find packages with the OE Layer Index
<jclsn[m]>
qschulz: I just searched for '*libvivante*' in root. There is nothing
<qschulz>
jclsn[m]: in root? root of what? where?
<jclsn[m]>
Ah you mean in bitbake
leon-anavi has joined #yocto
<jclsn[m]>
qschulz: On the board
<jclsn[m]>
oe-pkgdata-util also finds nothing
<ziga_>
@qschulz So based on your replies. I probably have to write my own recipe that will fetch, compile & install the libdrm-tests package? I haven't yet found any existing recipe that does this.
<qschulz>
jclsn[m]: if oe-pkgdata-util finds nothing, then it means the recipe creating this library hasn't been built
<jclsn[m]>
The desktop environment is horribly slow. I am assuming that there is no graphics driver present at all
lucaceresoli_ has joined #yocto
<qschulz>
ziga_: no.
<jclsn[m]>
qschulz: Okay
<qschulz>
jclsn[m]: libvivante is proprietary sw also, etnaviv is the open-source alternative
<qschulz>
(just FYI)
<jclsn[m]>
The driver should be part of the kernel actually
<qschulz>
I can't help much more for now
<jclsn[m]>
qschulz: I know but our collegues want Vivante
<jclsn[m]>
Everyone is telling me not to use it though
<qschulz>
jclsn[m]: the driver will probably create a /dev device (for mali it's /dev/mali0 IIRC or something like that, there's probably something similar for vivante
<qschulz>
jclsn[m]: don't remember which NXP SoC you're using
<jclsn[m]>
im8mm
<jclsn[m]>
imx8mm
<qschulz>
but except if you have a very niche usecase, you're probably better off with Etnvaiv since I assume most open-source software actually test and/or are happy to help you debug etnaviv integration
<qschulz>
I only had vivante running on the imx8mm
<jclsn[m]>
I know
<jclsn[m]>
They are just worried about performance
<qschulz>
it's imx-gpu something recipe
<qschulz>
jclsn[m]: also, etnaviv is supported for imx8mm only from 5.4 and mesa 20 or 21 don't remember exactly
<qschulz>
so if you're stuck on a super old kernel, the answer is pretty straightforward
<qschulz>
ziga_: libdrm-tests is the package you need to install
<jclsn[m]>
5.10 here
<jclsn[m]>
imx-gpu-viv it is
<qschulz>
ziga_: if oe-pkgdata-util find-path returns something, it means this package was built
tnovotny has joined #yocto
<qschulz>
jclsn[m]: the GPU stuff is hairy in meta layers for NXP SoCs...
<qschulz>
so be extra super duper sure the MACHINEOVERRIDES, SOC_FAMILY and all are correctly set
<qschulz>
ziga_: if you want to know which recipe provides the package which provides the file you're after, run oe-pkgdata-util lookup-recipe libdrm-tests (or something close to this)
<qschulz>
ziga_: you'll see that libdrm is the recipe which creates the libdrm-tests package
Starfoxxes has quit [Ping timeout: 256 seconds]
<jclsn[m]>
qschulz: Interesting. The thing is we have created our own machine name, so many packages complain that it isn't compatible although it is an imx8mm actually. I just tried building `imx-gpu-viv`and it says exactly that. So I guess I have to make a .bbappend to make it compatible. But this is annyoing actually. Maybe I should use mx8 as machine override
Schlumpf has joined #yocto
<qschulz>
jclsn[m]: no no no
<qschulz>
jclsn[m]: you setup your machine to have the correct MACHINEOVERRIDES and you're settled
<qschulz>
(so yes to the last sentence actually :) )
<qschulz>
but look how the other machines are created
lucaceresoli_ has quit [Ping timeout: 240 seconds]
<qschulz>
and either include one machine conf file which is close enough to yours, or take inspiration from it
prabhakarlad has joined #yocto
<jclsn[m]>
qschulz: But how would I add my device tree then? It is our custom board after all
rfuentess has quit [Remote host closed the connection]
<ziga_>
@qschulz I think I now understand. I just installed "libdrm-tests" package and it installed without problems. AFTER IT WAS INSTALLED I used "oe-pkgdata-util lookup-recipe libdrm-tests" and it returned recipe "libdrm". SO NOW I FINALLY know that recipe "libdrm" is the one that builds the package "libdrm-tests" but only if PACKAGECONFIG has "install-test-tools" string. But I am missing the reverrse philosophy. For example. As a developer I only
<ziga_>
know which package I want/need to install. So I need a way to search for this package and then locate a recipe that produces it. At this point you would probably suggest me to use "oe-pkgdata-util" as you already did, but does this tool work if package hasn't yet been ccompiled? In my experience it doesn't. So here is where the problem is, because In my first go, I can't locate the recipe for some desired package.
<qschulz>
ziga_: you don't want to install a package, you want to install a file. So your reverse philosophy starts there. "I want this file", "does a package I've already built install this file?"
<qschulz>
ziga_: if there is no package providing the file 1) either the recipe was misconfigured, 2) or the recipe was not built yet
<qschulz>
this one is harder, and you'll need to use Google to find which project provides this file, then try to find if there's a recipe that exists for it
<qschulz>
build it, if no package still
<qschulz>
then you need to look into the recipe if something needs to be adapted/fixed
<ziga_>
@qscchulz Ah okay. So this is why you first suggested me to use "oe-pkgdata-util find-path '*modetest*'"! Okay. Got it got it!
<qschulz>
if no recipe, then ask here probably? otherwise create yours
Vonter has quit [Ping timeout: 252 seconds]
zpfvo has quit [Ping timeout: 252 seconds]
zpfvo has joined #yocto
<qschulz>
jclsn[m]: don't understand the question? you can include a machine configuration file in another machine configuration file, where you'll set your device tree if you want
<qschulz>
note that MACHINEOVERRIDES should contain MACHINE (the name of your machine configuration file without the .conf) and have it have the highest precedence
<jclsn[m]>
<qschulz> "jclsn: don't understand the..." <- I just don't know what to choose here. I could choose `imx8mm-evk-lpddr4` but then our board is not an evalutation board. Sure I could just add our device try by sourcing machine.conf for our board that contains it, but in the end we want to thin out the whole machine configuration. Then I would have to remove all the things from that configuration with :remove overrides. Is that really the way to
<jclsn[m]>
go?
Vonter has joined #yocto
<jclsn[m]>
Atm our machine configuration is based on imx8mm-evk-lpddr4 though
<qschulz>
jclsn[m]: look at what this machine configuration file does then and include the thing you need
<qschulz>
and adapt MACHINEOVERRIDES accordingly
<jclsn[m]>
MACHINEOVERRIDES are "imx-boot-container:mx8:mx8m:mx8mm:"
<jclsn[m]>
So no idea why bitbake thinks it is our board
florian has joined #yocto
<jclsn[m]>
I have only set our MACHINE in local.conf
<qschulz>
jclsn[m]: and before any include right? seems about right, if you check with bitbake -e some-recipe | grep ^MACHINEOVERRIDES=, you should have vti2 in there
<jclsn[m]>
qschulz: It is in there
<jclsn[m]>
I am currently building chromium though
<jclsn[m]>
I just wonder why the recipes are only being passed vti2
<jclsn[m]>
mx8 should also be passed, shouldn't it?
florian has quit [Ping timeout: 250 seconds]
m4ho has quit [Read error: Connection reset by peer]
<jclsn[m]>
It is tedious to add vti2 to COMPATIBLE_MACHINE in every recipe
<jclsn[m]>
CONFIG_MXC_GPU_VIV is also not added in the linux-fslc-imx defconfig
<jclsn[m]>
I still don't understand this kernel recipe fully
<qschulz>
jclsn[m]: kernel recipes are often complex so it's not surprise, it takes me time every time too
<qschulz>
no*
<qschulz>
jclsn[m]: I've seen some COMPATIBLE_MACHINE:machine = "machine" in some recipes, so you might be missing yours
<qschulz>
honestly I don't know
<jclsn[m]>
qschulz: This one is especially hard though because it is a kernel that is patched together from mainline and linux-imx
zpfvo has quit [Ping timeout: 250 seconds]
leon-anavi has quit [Remote host closed the connection]
leon-anavi has joined #yocto
m4ho has joined #yocto
zpfvo has joined #yocto
<jclsn[m]>
Why is it discouraged btw to edit defconfigs directly? Because some configurations might conflict and menuconfig can detect that?
zpfvo has quit [Ping timeout: 250 seconds]
zpfvo has joined #yocto
dsueiro has quit [Quit: Client closed]
huseyinkozan has joined #yocto
<qschulz>
jclsn[m]: because some configurations have "depends on" you might not have added yourself, and you think you have enabled an option but actually you didn't
<jclsn[m]>
Okay thanks
florian has joined #yocto
<Etheryon>
Hello, I have an ISO image that I built and burned to a USB stick to run live. Any was I can make the fs not read-only? I'm not even sure what sets it as RO
<LetoThe2nd>
Etheryon: adding read-only-rootfs to IMAGE_FEATURES should do the trick.
chep` has joined #yocto
prabhakarlad has quit [Quit: Client closed]
chep has quit [Read error: Connection reset by peer]
chep` is now known as chep
Vonter has quit [Ping timeout: 240 seconds]
zpfvo has quit [Ping timeout: 272 seconds]
florian_kc has joined #yocto
zpfvo has joined #yocto
Etheryon has quit [Quit: Client closed]
zpfvo has quit [Ping timeout: 252 seconds]
zpfvo has joined #yocto
Schlumpf has quit [Quit: Client closed]
woky has quit [Quit: Nothing in this world is hopeless!]
snapsd49 has joined #yocto
<snapsd49>
Hello
<snapsd49>
can I trigger a recipe build from another recipe (possibally from do_compile)?
woky has joined #yocto
zpfvo has quit [Ping timeout: 272 seconds]
manuel1985 has joined #yocto
zpfvo has joined #yocto
<RP>
snapsd49: you can add a dependency?
<LetoThe2nd>
snapsd49: nope.
<snapsd49>
I am getting what packages my recipe depends on after unpack task.. so need to build those pcakges
<snapsd49>
so can't set in as RDEPENDS .. as dependencies are not known when I run bitbake xyz.recipe
<LetoThe2nd>
snapsd49: it doesn't work that way, sorry.
<RP>
snapsd49: as LetoThe2nd says, you can't do that dynamically
<LetoThe2nd>
snapsd49: meta data must be constructed in a way so all the dependencies can be calculated without running any tasts.
<LetoThe2nd>
tasks, even.
zpfvo has quit [Ping timeout: 252 seconds]
pgowda_ has joined #yocto
zpfvo has joined #yocto
<snapsd49>
okay, thanks.. that's what I was wondering.. for any recipe, the metadata / depchain is constructed before executing any task..
<snapsd49>
so any workaround / hack to add dependencies dynamically? or building packages?
<snapsd49>
so any workaround / hack to add dependencies dynamically? or building packages dynamically from recipe?
<LetoThe2nd>
snapsd49: really bad hack: build everything in that one recipe. brute force hack: just add all dependencies statically. pipeline hack: build the thing at an earlier stage and just pack the artifact.
tnovotny has quit [Read error: Connection reset by peer]
zpfvo has quit [Ping timeout: 250 seconds]
<snapsd49>
LetoThe2nd - but I don't know what dependencies will be required to be built... I get that list after unpack stage..
zpfvo has joined #yocto
<LetoThe2nd>
snapsd49: i think you have some thinking to do then.
florian_kc has quit [Ping timeout: 240 seconds]
Etheryon has joined #yocto
<Etheryon>
I'd like it to be read-write
zpfvo has quit [Ping timeout: 272 seconds]
zpfvo has joined #yocto
zpfvo has quit [Ping timeout: 250 seconds]
<qschulz>
Etheryon: then make sure this is not added anywhere
<qschulz>
Etheryon: also make sure you're not using squashfs for the root filesystem
zpfvo has joined #yocto
tnovotny has joined #yocto
Etheryon has quit [Quit: Client closed]
Vonter has joined #yocto
<chrfle>
hello, I'm stuck in a state where I get kernel logs about version magic mismatch for kernel modules. The version is the same except the hash that's different. I have tried to cleanall the kernel recipe, but I still end up in the same state. Anyone have any advice?
kriive has quit [Remote host closed the connection]
Schlumpf has joined #yocto
Kaa has joined #yocto
<dv__>
is it still discouraged to use do_install_append unless it is really necessary?
<dv__>
IIRC, prefuncs and postfuncs are recommended over _append
<LetoThe2nd>
qschulz: ya but thats hard to avoid if you're outputting ISO
snapsd49 has quit [Quit: Ping timeout (120 seconds)]
<Kaa>
Does anybody think that the current behavior of INITRAMFS_IMAGE_BUNDLE is weird? Linux image goes to initramfs and initramfs goes to Linux image :D
zpfvo has quit [Ping timeout: 272 seconds]
Etheryon has joined #yocto
zpfvo has joined #yocto
zpfvo has quit [Ping timeout: 252 seconds]
superdupond has joined #yocto
zpfvo has joined #yocto
zpfvo has quit [Ping timeout: 252 seconds]
zpfvo has joined #yocto
ar__ has joined #yocto
<Etheryon>
IMAGE_FSTYPES = "iso" would do this? I've looked through env and couldn't find any read-only-rootfs
<jclsn[m]>
imx-gpu-viv expects mx8 as machine. Should I create a .bbappend now or find the reason why the machine is advertised as vti2?
<jclsn[m]>
I have quite a few overrides that had `:mx6` or `:mx8` before and since the honister upgrade they expect it to be `:vti2`
<dv__>
otavio ^
<qschulz>
jclsn[m]: PRISTINE_MACHINEOVERRIDES is not a common variable so can't say if it's correctly set up or no
ar__ has quit [Ping timeout: 240 seconds]
goliath has quit [Quit: SIGSEGV]
<otavio>
jclsn[m]: which machine is this?
<otavio>
jclsn[m]: also check the final MACHINEOVERRIDES value
<jclsn[m]>
Is there a way to set a MACHINE alias? Like my MACHINE=vti2 but all recipes with mx8 are also valid
<otavio>
jclsn[m]: vti2 is the machine name?
<otavio>
jclsn[m]: please post the final MACHINEOVERRIDES value
Schlumpf has quit [Quit: Client closed]
<jclsn[m]>
otavio: Our custom boards
<jclsn[m]>
with in im8mmm SoC
<jclsn[m]>
* with in im8mm SoC
<otavio>
jclsn[m]: please post the final MACHINEOVERRIDES value
<qschulz>
jclsn[m]: that's the whole point of MACHINEOVERRIDES, to not have to explicit each and every machine for recipes compatible with one specific SoC
<jclsn[m]>
Is that a new feature? It wasn't necessary in gatesgarth
<otavio>
jclsn[m]: i.mx8 has moved to default to mainline
<jclsn[m]>
I should probably default to mainline as well haha
<jclsn[m]>
I like to step out of line though
<qschulz>
jclsn[m]: rmember you want vivante which is very likely not built when you use mainline in meta-freescale?
<jclsn[m]>
qschulz: I realized that
<jclsn[m]>
That was why I tried to append it manually and had this issue in the first place
<smurray>
RP: other than the double logging, your changes in poky-contrib work well, if I apply/remove my rename changes on top of bitbake and oe-core they seem to catch what I'd expect them to
<jclsn[m]>
But now linux-fslc-imx doesn't work anymore
<jclsn[m]>
I thought this was a patched linux-imx kernel with Vivante graphics
<jclsn[m]>
Ah no it is u-boot nevermind
<RP>
smurray: ok, cool. Do you have OE-Core changes?
<RP>
smurray: I didn't spot those, I was trying to pull together a test set of changes
<RP>
smurray: I have a couple of tweaks to your siggen changes so we preserve some compatibility there with old sigdata files
<landgraf>
RP: both hg fetcher and mercurial in general are broken badly :-/
<smurray>
RP: okay. I've not posted my oe-core changes anywhere yet, they were effectively just grep | sed of the variables w/o going through and checking for anything else manually
<RP>
landgraf: sadly I'm not surprised :/
<RP>
smurray: ok, I've a couple of patches in that branch for that then
* RP
wonders about putting this in master-next
pabigot has quit [Remote host closed the connection]
pabigot has joined #yocto
xmn has joined #yocto
<otavio>
jclsn[m]: qschulz: Etnaviv is a quite usable alternative for most projects; we use it for most of our customers
<jclsn[m]>
otavio: And NXP can't even host their files right. Again this imx-vpu-hantro-daemon fetcher failure
* RP
updated master-next with the current inclusive language queue. Now I need to find the other patches people sent and try and merge these in
* RP
is extremely annoyed at being left with this
<JPEW>
RP: Did you figure out that erroronce problem?
<RP>
JPEW: I think it is because I was testing early variables in the configuration datastore and the message filtering only works once knotty is running
<qschulz>
otavio: I have suggested Etnaviv to jclsn[m] already :)
* JPEW
looks over the logging patches in master-next
<jclsn[m]>
qschulz: Everyone does :D
zpfvo has quit [Ping timeout: 272 seconds]
zpfvo has joined #yocto
rsalveti has quit [Ping timeout: 240 seconds]
Etheryon has quit [Quit: Client closed]
pgowda_ has quit [Ping timeout: 240 seconds]
bluelightning has quit [Ping timeout: 240 seconds]
pgowda_ has joined #yocto
rsalveti has joined #yocto
kanavin_ has quit [Remote host closed the connection]
<RP>
sgw: I tweaked your blacklist.bbclass series to fit with the other changes and added to -next
Etheryon has joined #yocto
<smurray>
RP: if you were mostly happy with those rename patches I did for BitBake, I can take a look at the few places in BitBake that still refer to "whitelist" and start on the "abort" changes tonight/tomorrow
<RP>
smurray: I think I'm ok with the ones in -next, yes
<RP>
I'm still not promising to merge any of this as we're still missing the conversion scripts and docs
kanavin has joined #yocto
<RP>
I just want to try and give this a chance with a baseline for people to work off
<smurray>
RP: okay. For docs it would be the migration guide entry?
<RP>
smurray: yes, that would be a good start. It doesn't have to be you but I'd like to have something
<smurray>
RP: okay, I'll check with sgw when he is on in a bit. I could maybe start a framework for it with these BitBake variables
<JPEW>
RP: With warnonce/erroronce, I think that the message will show up multiple times in the console log file (for example). More specifically, it will show up multiple times in any logger that doesn't explicitly use the designated filter. I *think* the solution here is to poke the "once" filter into the config in setLoggingConfig(), effectively making it mandatory. I have a patch to do this
<RP>
smurray: right, the PNBLACKLIST -> SKIP_RECIPE one also has patches
goliath has joined #yocto
<RP>
JPEW: Sounds good, I think I tried that and struggled
<JPEW>
I'll test and send it in then
<smurray>
RP: one note, I got a bitbake-selftest failure in test_parse_overrideimmediate with what's in poky-contrib atm
<RP>
smurray: sorry, there is a load of other junk in that branch including that test
<RP>
smurray: this is partly why I've moved to -next
<smurray>
RP: okay, cool
<RP>
smurray: from memory that is a new test where I was trying to debug something which needs fixing
<smurray>
gotcha
* RP
has a long todo list :(
<sgw>
RP : Morning, I woke up to a 6:00 am surprise meeting instead of trying to help you!
<sgw>
I will get to it shortly
Minvera has joined #yocto
<smurray>
sgw: wrt the discussion above, were you planning to work up the migration guide entry and/or the conversion script?
<RP>
smurray, sgw, jonmason: perhaps someone could also mail the list with a status on what is in -next and a list of what else needs doing. We now have some example patches of a conversion and the renames for core shouldn't be hard to write patches for
<smurray>
RP: somewhat related, is it halsted I should ping wrt getting my access to the wiki moved through approval process?
<RP>
smurray: it is halstead
<smurray>
RP: okay
<smurray>
RP: I'll update the table a bit once I get that sorted
<RP>
I'll run -next on the autobuilder, see how widespread the damage is there
<sgw>
smurray: I can work on the migration guide, if needed. I will be reading the log to catch up.
<smurray>
sgw: okay, let me know if you need help with it
Etheryon has quit [Quit: Client closed]
Kaa has quit [Quit: Client closed]
Guest83 has joined #yocto
<Guest83>
Hi, apologies if the following question is not a pure yocto question. In general, after writing a kernel driver, how are these drivers tested (e.g. a sensor)? Compile + insmod?
davidinux has quit [Ping timeout: 272 seconds]
zpfvo has quit [Ping timeout: 272 seconds]
zpfvo has joined #yocto
zpfvo has quit [Ping timeout: 252 seconds]
<LetoThe2nd>
Guest83: thats the classic approach, yes.
zpfvo has joined #yocto
<Guest83>
LetoThe2nd Thanks!
Vonter has quit [Ping timeout: 240 seconds]
rob_w has quit [Remote host closed the connection]
Vonter has joined #yocto
<JPEW>
RP: Is it ok if I squash your erroronce/warnonce patching into a new single patch with fixes?
<RP>
JPEW: if that makes most sense, I guess yes
<JPEW>
There was another bug I had to fix, so I think it makes sense :)
<RP>
JPEW: what else did I break? :)
<JPEW>
The "once-ness" was global, so the message would only show up on a single logging output, and no where else
<RP>
JPEW: oh, ouch :/
<RP>
JPEW: thanks for spotting that
<JPEW>
Each handler needs it's own copy of the filter so that it has it's own once state. I make setLoggingConfig() create one implicitly for each handler
<RP>
JPEW: makes sense, thanks
<JPEW>
np. Patch sent
Guest83 has quit [Quit: Client closed]
<RP>
JPEW: definitely looks cleaner, thanks
cengiz_io has quit [Ping timeout: 245 seconds]
cengiz_io has joined #yocto
thierryE[m] has quit [Quit: You have been kicked for being idle]
<otavio>
jclsn[m]: if you're facing errors please report it on GitHub so I can ask them to check internally.
<otavio>
jclsn[m]: (fetch errors)
<qschulz>
otavio: if it's hosted on codeaurora, it's not uncommon to have downtime
<Saur>
RP: I just had a build failure with Honister on one of our Jenkins builders and this is what I got in the log: https://pastebin.com/Pt91PEXM It tells me nothing of what actually went wrong. I am pretty sure there used to be more information in cases like this. I know there has been changes to the logging to avoid duplicating logs. Is it possible that too much has been removed?
goliath has quit [Quit: SIGSEGV]
<RP>
Saur: I suspect that is less about the logging changes and more about poor exception handling
<Saur>
Hmm, ok.
<RP>
Saur: subprocess has a habit of not showing the output from the failed command and I suspect bb.process inherited the problem
<RP>
Saur: it is interesting that is from the "if log:" branch so there should be output in the logs but that isn't being copied to the console
prabhakarlad has joined #yocto
<RP>
Saur: there are many issues like this, we just have to go through and fix them as we encounter them
<RP>
Saur: it might be we could just delete that if section now
<RP>
especially as it says "# Don't duplicate the output in the exception if logging it"
<RP>
sounds like we fixed the duplication elsewhere and now don't see it!
<Saur>
Yeah, unfortunately all our Jenkins builds are made in Docker containers that are thrown away afterwords so there is no way for me to get hold of that other log file. :(
* rfs613
has that problem too... makes it very challenging to debug!
<RP>
Saur: making that function call fail should be an easy way to reproduce and debug the error handling itself. Doesn't solve your failure but would then help next time
<Saur>
RP: I'll see what I can come up with...
<Saur>
Should be easy enough to force some error to happen...
<RP>
Saur: Just put an "if PN = XX exit 1" into that function ;-)
<RP>
(into BUILDSPEC)
<rfs613>
what's a good strategy for refreshing a patch (context lines need to be updated) when you can't touch the original layer? Can another layer replace individual patches?
<JPEW>
rfs613: If you are careful, but it can be fiddly
<RP>
rfs613: if you add a bbappend and add a new directory to the searchpath, yes
<rfs613>
i've been trying to find documention to explain the search path ordering... if I use the same filename for the patch, will it take it from the higher priority layer?
<Saur>
rfs613: `devtool finish <recipe> <one of your layers>` will do it automatically for you.
<RP>
rfs613: there are example doing FILESEXTRAPATHS:prepend := "${THISDIR}/files:" in meta-poky
<RP>
rfs613: FILESPATH (via FILESEXTRAPATHS) works like a PATH search in shell
<Saur>
As long as you make sure your layer is earlier in the BBLAYERS variable than the original layer it should work.
GNUmoon has quit [Remote host closed the connection]
<qschulz>
rfs613: you also have some slides in the bonus section about the selection algorithm
<rfs613>
thanks everyone for the replies! I'm giving it a try now...
<jclsn[m]>
<otavio> "jclsn: if you're facing errors..." <- I already found the thread and you already saw I guess ;)
GNUmoon has joined #yocto
tnovotny has quit [Quit: Leaving]
lucaceresoli has quit [Quit: Leaving]
<rfs613>
qschulz: thanks, slide #79 is exactly what I was looking for... and for debugging, I also found it helpful to do 'bitbake -v -c do_patch pkgname'... it shows me each patch being applied, including path, so I can confirm it took the version from my layer and not the original layer.
<rfs613>
Saur: minor item, I noticed devtool puts in "${THISDIR}/${PN}" whereas a lot of existing places use "${THISDIR}/files". Any particular reason to prefer one or the other?
<qschulz>
rfs613: it allows to have multiple recipes in the same directory
<qschulz>
and have patches/files for each recipe in logical directories
<rfs613>
ok, gotcha
<Saur>
RP: If I revert fc58ad84a9deb2620ad90611684dad65dafedb11 in bitbake I get back the error logs. :)
<RP>
Saur: Hmm, of course it was me who did that and it looks like there was some other case where it did duplicate :(
<RP>
Saur: Would have been nice if I'd recorded the other case :/
<sgw>
smurray: I updated the wiki with your name attached to the work RP has in -next so far.
<sgw>
Well never mind, looks like you got access and we collided!
<smurray>
sgw: heh, was just about to say I'd done that ;)
<JPEW>
Saur: What logs are missing?
<RP>
JPEW: it is the command output which was sent to the log file
<JPEW>
Hmm, I wouldn't expect that to be affected
<sgw>
smurray: are you going to work on the conversion script or shall I start on that.
<smurray>
sgw: if you have cycles atm, please start on it. If not, I can start working up something this evening
<Saur>
JPEW: See https://pastebin.com/Pt91PEXM With Hardknott, the content of .../build/build/tmp/work/<machine>-poky-linux/<recipe>/1.7.52-r0/temp/log.do_package_write_rpm.35734 is included in that error. Not so with Honister.
<RP>
Saur: you're saying the logfile itself didn't have it in either?
<Saur>
RP: No, the log.do_ file is there.
<Saur>
But it isn't in stdout/sterr of bitbake, and it is not in console-latest.log
florian has quit [Quit: Ex-Chat]
zpfvo has quit [Quit: Leaving.]
leon-anavi has quit [Quit: Leaving]
<sgw>
smurray: Ok, starting on a script similar to others in scripts/contrib
frieder has quit [Remote host closed the connection]
<smurray>
sgw: yeah, that was going to be my starting point as well if I did it
<RP>
Saur: I have a vague memory of adding some logging tests for python and shell task failures. Not sure if that shows a regression with that change reverted or not?
<Saur>
RP: With bitbake -v and Hardknott I get the output twice, could that be the duplication you were trying to avoid? That said, I remember having error output show up twice (or maybe it was even thrice) before (and that was without bitbake -v). Not sure if that went away with Hardknott or if it was Honister.
goliath has joined #yocto
<Saur>
RP: I guess the tests you were referring to are commit 414020a9bd656ee61efe2f47db1b31d86b15c1c8 in meta.
<RP>
Saur: there was a separate change for the -v duplication issue :/
<RP>
Saur: those tests are the ones I was thinking of, not sure how relevant they are. I did at least try and put some test cases in!
<Saur>
Yeah, I kind of guessed as I know I have had duplicated logs in the past, and I typically don't use bitbake -v.
huseyinkozan has quit [Quit: Konversation terminated!]
<Saur>
RP: Hmm, bblogging.BitBakeLogging.test_shell_logging fails for me whether I have the test in bitbake/lib/bb/process.py or not.
<Saur>
And this is with poky without any of our own changes.
mckoan is now known as mckoan|away
JrmeCarretero[m] has joined #yocto
manuel1985 has quit [Quit: Leaving]
florian_kc has joined #yocto
<RP>
Saur: presumably that is passing on the autobuilder and for me locally so that is rather strange
<moto-timo>
kanavin: I see you already staged python3-pytest and python3-tomli upgrades... glad you figured out the src/tomli change
<kanavin>
moto-timo, cheers, I trust you are meticulously working towards making those setup.py-less recipes work again :)
<kanavin>
tomli wasn't that hard, my cutoff time for this kind of thing is five minutes
pgowda_ has quit [Quit: Connection closed for inactivity]
unknown__ has quit [Quit: Leaving]
creich has joined #yocto
* RP
wonders who is going to give in and sort that gstreamer test failure
lucaceresoli has joined #yocto
Vonter has quit [Ping timeout: 272 seconds]
<kanavin>
RP: I just did
<kanavin>
Alex, the last resort guy
<kanavin>
(second-last I guess)
<rfs613>
hmm, so now on a different recipe, i created a patch with devtool... but when trying to build the package, quilt fails to apply the patch ("No file to patch.")
<RP>
kanavin: ah, thanks!
<RP>
kanavin: I'm curious to see if your build sees the same mirror issues mine are seeing
<RP>
kanavin: I wasn't sure which of us would crack first on gstreamer :)
<RP>
kanavin: I "fixed" the ltp one
florian_kc has quit [Ping timeout: 252 seconds]
<kanavin>
RP: I was hoping one of the gstreamer guys would send a followup :-/
<RP>
kanavin: right, me too
<Saur>
RP: It appears I had BB_VERBOSE_LOGS = "1" in my configuration which affected those tests.
<Saur>
With that removed the tests pass.
<Saur>
And if I revert the change in process.py they fail...
<rfs613>
ah, got it sorted... though it's odd, seems to be applying patch in a subdir of the repo, not at the top.
<kanavin>
RP: and yes, I sshd in, and it runs dunfell
bgreen0 has joined #yocto
<RP>
Saur: well, I did document what I was fixing then :)
<RP>
Saur: that should help us find a way to fix this other case too
<RP>
kanavin: nice :). At least it is dunfell so supported too
<RP>
kanavin: I wonder if we should at that to the users list on the wiki?
<bgreen0>
Hi. I have a question related to build reproducibility. I'm considering adding '-Wl,--build-id=none' to my compiler options because the the gnu build-id elf section is causing builds to differ when the build directory changes. The debug files are being thrown out for release builds anyway. I'm wondering if anyone knows of any potential
<bgreen0>
downsides to removing this section altogether, when debuggability is not a factor?
Starfoxxes has joined #yocto
<bgreen0>
I'm using jethro (can't change) with some patches to support build reproducibility
lucaceresoli has quit [Ping timeout: 272 seconds]
<sgw>
smurray: I ran my conversion script and noticed that you might have missed bitbake/lib/bb/siggen.py in your basehash/taskhash renames
<sgw>
Oh, never mind, I think that's the conversion code being overly agressive!
<Saur>
RP: On a totally unrelated note: you integrated most of my changes related to \n in mirror variables, but there are two patches sent to the poky list that are still not integrated (and there is one for the documentation too, but I guess I should ping Michael about that one).
<RP>
Saur: sorry, I must have missed the poky ones
Vonter has joined #yocto
<Saur>
No worries. Easy to do I guess when the changes are spread over three different repos and mailing lists.
<RP>
Saur: merged
<Saur>
:)
<RP>
Saur: please remind michaelo about the other one
<Saur>
Will do.
<sgw>
RP: I think you missed a meta-poky patch to poky-tiny in master-next
<smurray>
sgw: I'm a bit puzzled, I'd figure a conversion script would just be using the uppercase metadata variable names? The references in siggen.py in master-next are the internal variable name tweaking for signature compatibility
<RP>
sgw: well spotted, yes. queued for testing
<sgw>
RP: found with my conversion script !
<RP>
sgw: handy
<sgw>
smurray: it's also looking for whitelist/blackslist
<sgw>
not changing them since they are context sensitive
<sgw>
smurray: sent you a early version to direction check. RP, I will push a WIP to the list before noon here.
<smurray>
sgw: as a prod for users to change language in their own layers? or for some form of CI? I figured we'd just be making a script that updated metadata so it'd work, a la the override syntax script
<sgw>
yes, as a prod, the problem is we have also removed some variables that can just convert, so it flags those also.
<smurray>
sgw: I'm not convinced it's necessarily useful per se, but I'll take a look. It'd not work for e.g. "abort" necessarily, as I think there a couple of instances in toaster that are to functions in external libraries
<sgw>
smurray: That's true, this is a first pass, we can fine tune, it does not changes those, just inform.
florian_kc has joined #yocto
<sgw>
well meta-openembedded is looking relatively good, 80 forbidden words, and 12 recipes that the script changed (I think correctly)!
<RP>
sgw: we probably have a lot more conversions to go though!
<sgw>
Oh yes, just wanted to get the script started and testing, about to send it to oe-core list
<sgw>
Work@wr6
<sgw>
oops!
<otavio>
sgw: every one does this once in a life ;)
<sgw>
Or more than once in my case, but it's been a while since the last one!
bluelightning has joined #yocto
<Saur>
RP: I'm looking at the second test in bblogging.BitBakeLogging.test_shell_logging test, which corresponds to my case. When I look at the output returned by the bitbake() function it contains the error log and the test passes. However, if I look at the corresponding log that was stored in qemux86-64-selftest-st/tmp/log/cooker/qemux86-64 it does _not_ contain the error output...
<RP>
Saur: sounds like a bug
<rfs613>
Over on cve.mitre.org I see some notices about upcoming changes to JSON format as well as the CVE List downloads... which will presumably affect cve-checker.
<smurray>
sgw: looking at your script, I don't think there's value checking for basewhitelist & taskwhitelist, AFAICT they're internal BitBake variables that nothing in oe-core at least tries to dig in to modify. The associated metadata variables are for changing their values...
camus1 has joined #yocto
camus has quit [Ping timeout: 240 seconds]
camus1 is now known as camus
Vonter has quit [Ping timeout: 240 seconds]
<kanavin>
pro tip: if you want webkitgtk patches to be looked at by upstream, set 'component' in the bug tracker to webkitgtk
<kanavin>
otherwise, they'll be seen as 'generic bugs' that no one looks at
<kanavin>
I finally got movement with those patch submissions :)
GNUmoon has quit [Ping timeout: 240 seconds]
bgreen0 has quit [Quit: Client closed]
aleblanc[m] has joined #yocto
florian_kc has quit [Ping timeout: 256 seconds]
Vonter has joined #yocto
GillesM has quit [Quit: Leaving]
<moto-timo>
🎉
Vonter has quit [Ping timeout: 256 seconds]
<vd>
do you have a valid scenario for a distro extending MACHINE_EXTRA_RDEPENDS/RRECOMMENDS or that is outrageous?
<smurray>
vd: we do for a few machines in AGL for things like where the BSP doesn't include some firmware dependencies that likely all users of a board would want
<vd>
hum I see
<vd>
that might fit with my usecase
<smurray>
vd: the rationale in AGL might be easier as downstream may not use any of the provided images, even as a base
florian_kc has joined #yocto
<smurray>
vd: but our visibility into what downstream auto folks actually do with it is very limited
<vd>
smurray: often bsp layers default to a simple boot mechanism, e.g. having the kernel in IMAGE_BOOT_FILES or in the rootfs with MACHINE_ESSENTIAL_EXTRA_RDEPENDS. But the thing is that the boot mechanism is often a distro choice, e.g. I might want to have redundant rootfs partitions which include the kernel and only the bootloader in the boot partition.
<RP>
kanavin: nice. I'm still waiting/hoping on the libtool ones!
<vd>
smurray: this is where the distro/machine glue needs to tweak one or the other and OE-Core enforces no strong practices on this, unless I'm mistaken
<smurray>
vd: yeah, that gets hazy. BSP folks want to be able to show something like core-image-minimal (or their own demo image) boots, so they provide configuration
<vd>
well core-image-minimal is indeed meant to showcase a machine while core-image-base is meant to showcase the base of a distro
<vd>
thanks to packagegroup-core-boot and packagegroup-distro-base, assuming they are properly configured
<vd>
(via MACHINE/DISTRO_*EXTRA_*)
<kanavin>
RP: yeah, I was wondering why none of the webkit patches I submitted 3 months ago are moving forward - but once I did the self-triage and assigned to 'webkitgtk', I got attention within minutes!
<RP>
kanavin: I wish libtool were that simple :)
<RP>
kanavin: we are making steady progress on the patch stats though
<vd>
smurray: you are relying on multiconfigs so far for the distro/machine glue, aren't you?
Guest20 has quit [Quit: Connection closed]
<smurray>
vd: no, there's a setup script that generates the configuration, as most folks target a single hardware target of the bunch AGL supports. There's some minimal multiconfig use in AGL, but it's for some non-default experimental system container stuff
<kanavin>
RP: yes, I'm looking at those weekly stats too, they go down as previously submitted things get dropped on upgrades
<kanavin>
now how do I squeeze in my revised patchbomb between all those Important Builds :-/
<smurray>
vd: there are enough BSP layers that just bbappend random things that trying to make them work together in a single bblayers.conf has been considered out of scope for AGL
<kanavin>
RP: one trick is to jump out of bed at 6am, start a-full, then fall back and snooze for another 3 hours :-/
chrfle has left #yocto [Leaving]
<vd>
smurray: making them work all nicely together is indeed possible but it takes a while to figure out how to integrate nicely. Unfortunately quick and dirty hacks like IMAGE_INSTALL:append in bsp layers is often chosen instead
goliath has quit [Quit: SIGSEGV]
<vd>
smurray: having machine or distro variants (requiring a base config) is not the best but still a good way to isolate machine/distro glue
<smurray>
vd: that's more difficult with vendor BSP layers that have somewhat non-functional upstreams
<vd>
smurray: it's a good reason for adding a new machine requiring the broken upstream one in your downstream bsp layer, don't you think?
<smurray>
vd: I'm not sure I follow, include/require means using in the upstream layer, so you still get it's baggage you may not want. If you mean redefining MACHINE* in your own machine, sure
Minvera has quit [Remote host closed the connection]
<vd>
smurray: an example that comes to mind is having a gpu-friendly machine (e.g. beaglebone black) with accelerated graphics, while the upstream 'beaglebone' machine doesn't enable their drivers by default. One may add the necessary PREFERRED_PROVIDER* in their distro (or local.conf), or define a new machine require beaglebone.conf
<vd>
another example is chosing a different bootloader for your use case
<vd>
smurray: are you saying that you don't even rely on the upstream machine definition and create your own from scratch? like beaglebone-yocto from meta-yocto-bsp (which doesn't use meta-ti)
<smurray>
vd: we (AGL) rely on them, yes. It wasn't clear to me what you meant. I gathered you mean defining your own
florian_kc has quit [Ping timeout: 250 seconds]
<RP>
kanavin: queue it up, the AB will get to it overnight
<kanavin>
RP: right, I have this idea that starting another a-full will make already running a-fulls slower, so I tend to wait for a quiet moment
<vd>
should the kernel-modules package be added with RRECOMMENDS like other kernel-module-* packages or RDPENDS?
GNUmoon has joined #yocto
<RP>
kanavin: yes and no. I'd prefer not to get the system too backlogged but....
mvlad has quit [Quit: Leaving]
lucaceresoli has quit [Ping timeout: 256 seconds]
nsbdfl has joined #yocto
dev1990 has quit [Quit: Konversation terminated!]
codavi has quit [Ping timeout: 240 seconds]
<sgw>
RP: are you OK with all the oe-core renames in one commit or do you want them broken down to groups like CVE* / SDK*/ ...
<sgw>
RP, nm you already did in oe-core master-next!
awafaa has quit [Read error: Connection reset by peer]
awafaa has joined #yocto
YogeshSiraswar_ has quit [Read error: Connection reset by peer]
halstead has quit [Read error: Connection reset by peer]
YogeshSiraswar_ has joined #yocto
halstead has joined #yocto
shivamurthy has quit [Read error: Connection reset by peer]
dl9pf has quit [Read error: Connection reset by peer]
praneeth has quit [Read error: Connection reset by peer]
paulbarker has quit [Ping timeout: 252 seconds]
CosmicPenguin has quit [Read error: Connection reset by peer]
ldts has quit [Read error: Connection reset by peer]
xtopher_ has quit [Read error: Connection reset by peer]
praneeth has joined #yocto
dl9pf has joined #yocto
ndec has quit [Read error: Connection reset by peer]
CosmicPenguin has joined #yocto
rburton has quit [Read error: Connection reset by peer]
jamestperk has quit [Read error: Connection reset by peer]
georgem has quit [Read error: Connection reset by peer]
fancer has quit [Write error: Connection reset by peer]
xtopher_ has joined #yocto
ernstp has quit [Read error: Connection reset by peer]
thierryE has quit [Read error: Connection reset by peer]
ndec has joined #yocto
darknighte has quit [Read error: Connection reset by peer]
rburton has joined #yocto
jamestperk has joined #yocto
shivamurthy has joined #yocto
paulbarker has joined #yocto
darknighte has joined #yocto
thierryE has joined #yocto
ldts has joined #yocto
fancer has joined #yocto
georgem has joined #yocto
ernstp has joined #yocto
kanavin has quit [Remote host closed the connection]
kanavin has joined #yocto
kanavin has quit [Remote host closed the connection]