jwillikers has quit [Read error: Connection reset by peer]
jwillikers has joined #yocto
<tlwoerner>
ndec_: on the dragonboard-410c, is it possible to stop the boot in the bootloader (lk?) and modify a variable? i'd like to change the kernel's cmdline args
meego has joined #yocto
meego has quit [Ping timeout: 246 seconds]
sakoman has quit [Read error: Connection reset by peer]
sakoman has joined #yocto
sakoman has quit [Quit: Leaving.]
jwillikers has quit [Remote host closed the connection]
<zeddii>
tlwoerner: was it you that had the bsp config question ? If so, I'll dig something up tomorrow. I was buried in trying to get 5.14 out for review.
<tlwoerner>
zeddii: yes that was me, sorry. i knew you were busy and asked anyway :-(
<ndec_>
tlwoerner: there is no 'shell' in lk. so you can't do that at run time, you need to update the boot image on the host. the bootargs are in the boot image, so you don't need to rebuild anything, abootimg can do it.
frieder has joined #yocto
frieder has quit [Remote host closed the connection]
frieder has joined #yocto
roussinm has quit [Quit: WeeChat 3.3-dev]
rob_w has quit [Remote host closed the connection]
zpfvo has joined #yocto
rob_w has joined #yocto
camus has quit [Ping timeout: 265 seconds]
Sion has joined #yocto
mattsm has quit [Read error: Connection reset by peer]
mattsm has joined #yocto
camus has joined #yocto
dgriego has quit [Ping timeout: 260 seconds]
dgriego has joined #yocto
argonautx has joined #yocto
camus1 has joined #yocto
leon-anavi has joined #yocto
camus has quit [Ping timeout: 252 seconds]
camus1 is now known as camus
gsalazar has joined #yocto
gsalazar has quit [Read error: Connection reset by peer]
gsalazar has joined #yocto
Schlumpf has joined #yocto
Schlumpf has quit [Client Quit]
<qschulz>
tlwoerner: re meta-rockchip and the mmc interface ordering, it's just a patch or two to apply to the device tree. Basically you need mmc aliases in the dts/dtsis
camus has quit [Read error: Connection reset by peer]
camus has joined #yocto
<ThomasD13>
Hi guys. I have a lot of machine configuration appends scattered in recipes. I've added now a second machine. Is there a mechnizm by yocto supplied to apply all these appends "j7-evm" also to my new machine configuration?
<ThomasD13>
Lets assume I have a variable SRC_URI_j7-evm = "github". When I start the build for machine j7-evm, the variable SRC_URI is set to "github". When I start the build for machine j7-paradise it is not.
<fbre>
Hi! Is there a command line call which outputs the used yocto linux version?
<ThomasD13>
Adding in j7-paradise machine configuration MACHINEOVERRIDE = "j7-evm" will set SRC_URI to "github" when I execute the build for j7-paradise?
<fbre>
...on my target device which is running yocto Linux
<dwagenk>
theyoctojester: I send those patches regarding the license implications of INITRAMFS_IMAGE_BUNDLE. Another possibly mistaken interpretation I have got: Adding the kernel and the initramfs to a combined FIT image does NOT make the kernel+initramfs a derivative work in the sense of GPLv2. Thus the initramfs may contain proprietary (GPL incompatible) programms. Any take (or pointers to documentation saying otherwise?)
<qschulz>
ThomasD13: yes, except you should use MACHINEOVERRIDES =. "j7-evm" before any include in your machine configuration file
<dwagenk>
on that?
<qschulz>
dwagenk: fitimage is just a container for artifacts
xmn has joined #yocto
<JosefHolzmayr[m]>
dwagenk: nothing that i can comment on, sorry.
<qschulz>
so yes, to me this is just fine (and the industry would sweat big time if that wasn't the case as many use initramfs for RO rootfs), but no lawyer again
<qschulz>
s/RO/non-persistent/
<ThomasD13>
Thank you very much qschulz :)
<dwagenk>
Thanks for the comments anyhow. Just trying to get a grasp of what is considered industry-standard and OK in this context.
<qschulz>
dwagenk: I would say that initrd should be pretty rare since it means you need to recompile (and reflash) the kernel every time you do a rootfs change
gsalazar has quit [Remote host closed the connection]
gsalazar has joined #yocto
<dwagenk>
Before diving deeper into INITRAMFS_IMAGE_BUNDLE and theyoctojester s pointer to the kernel docs I was not aware of the initramfs actually being passed into the kernel build and thus beeing affected by the GPL. I hope the proposed note in the yocto manual makes this potential problem obvious to users.
goliath has joined #yocto
<qschulz>
I didn't know either tbf :)
dgriego has quit [Ping timeout: 252 seconds]
dgriego has joined #yocto
camus1 has joined #yocto
camus has quit [Ping timeout: 252 seconds]
camus1 is now known as camus
meego has joined #yocto
kayterina has joined #yocto
meego has quit [Quit: Leaving...]
meego has joined #yocto
camus has quit [Ping timeout: 265 seconds]
camus1 has joined #yocto
camus1 is now known as camus
<JosefHolzmayr[m]>
i guess i'm missing something super obvious, but why does this recipe err out during parsing? https://hastebin.com/ipaxuvojed.nginx
<JosefHolzmayr[m]>
override syntax biting me?
gsalazar has quit [Ping timeout: 246 seconds]
guid has joined #yocto
<JosefHolzmayr[m]>
yup. needs. :${PN}
<ThomasD13>
MACHINE=j7-paradise bitbake image gives me an build error at specific package. MACHINE=j7-paradise bitbake specific-image however says "package specific-package was skipped: incompatible with with machine j7-paradise".
<guid>
Hi. I have a recipe A that installs a file foo.cert in /usr/local/share/ca-certificates. Now, I've got a recipe B that install a file bar.sh and I need to inject the foo.cert of the recipe A into my bar.sh (via sed). I added A as a dependency of B (DEPENDS = "A") but I don't know what task I should use for the injection. Can I do it in the
<guid>
do_install task?
<ThomasD13>
How does this make sense? Why is this package build for the image, even it is not compatible to the machine?
<mckoan>
JosefHolzmayr[m]: that will be a frequent error in the future :-(
<JosefHolzmayr[m]>
yup
<qschulz>
ThomasD13: because something pulls it in for you
beneth has quit [Quit: Gateway shutdown]
GillesM has joined #yocto
<barath>
is there documentation on what could cause something like `ERROR: Setscene task /var/jenkins/persistent_environment/layers/poky/meta/recipes-core/packagegroups/packagegroup-core-boot.bb:do_package in both covered and notcovered.` ?
<barath>
I assume it has something to do with dependencies, run-order and the sstate cache...
<kanavin>
moto-timo, how's your progress with phosh?
camus1 has joined #yocto
camus has quit [Ping timeout: 268 seconds]
camus1 is now known as camus
Net147 has quit [Quit: Quit]
Net147 has joined #yocto
Net147 has joined #yocto
Net147 has quit [Changing host]
mckoan is now known as mckoan|away
<RP>
barath: there was a bug open for that and it had fixes in master recently. Which version of the project is that?
<barath>
yeah just found that one, but we're not seeing any warnings about "Runqeueue deadlocked on deferred tasks"
<barath>
it's dunfell
<barath>
we've never consciously seen this before. I'm trying to read the runqueue.py but I haven't fully grokked what covered and notcovered actually mean in this context
jorschulko has joined #yocto
<RP>
barath: the same task should never be on both so there is a bug somewhere :(
<RP>
barath: I think dunfell and hardknott are getting some of these fixes queued up for them and they might help your case too
<barath>
RP: alright, thanks. so at least we're not alone. but does it make sense that we're not seeing the warnings about deferred tasks? form the issue ticket it seems like that's an indication
<barath>
and what's notcovered/covered? stuff "already run"?
<barath>
or already parsed?
Guest4 has joined #yocto
Guest4 has quit [Client Quit]
<RP>
barath: there are two stages to execution of tasks, "from sstate" and "real". covered and notcovered are two lists that real tasks get put into depending on whether the sstate was available and meant they weren't needed or not. One task should never be both
martin31821 has joined #yocto
<RP>
That check was added as a sanity check to find problems and give a warning before bad things happen
<barath>
hm okay. so "real" tasks get put into "notcovered" when no sstate cache is available for them?
<barath>
we've recently changed our build setup to hopefully reuse previously generated sstate cache files more, so maybe it's a symptom of that
<RP>
barath: effectively but real and sstate tasks aren't one to one mappings
<RP>
barath: that would make this worse, yes
<barath>
RP: alright, thanks! then we have something to go on. if necessary I'll try backporting the fixes for us locally and otherwise I'll keep a watch out for any fixes that trickle down to dunfell
<RP>
barath: it was a pain to track down and debug but I'm hoping it is at least fixed in master
<jorschulko>
Hi, we are currently in the process of reworking the google repo fetcher and have the following problem: We need to run repo sync every time, as checking for SRCREV changes within the manifest repo is not enough. That's because the manifest itself might reference a branch within the sources repo and thus the sources can still change. The easiest way to accomplish this that we could think about is adding
<barath>
sounds like it
<jorschulko>
a timestamp to the latest revision. That would force yocto to rerun do_fetch every time. However, this would also make offline builds impossible. Any ideas on how we could implement this in a smart way?
GillesM has quit [Quit: Leaving]
lucaceresoli has joined #yocto
<RP>
jorschulko: could we detect the manifest referencing a branch and make that an error?
<guid>
Hi. I have a recipe A that installs a file foo.cert in /usr/local/share/ca-certificates. Now, I've got a recipe B that install a file bar.sh and I need to inject the foo.cert of the recipe A into my bar.sh (via sed). I added A as a dependency of B (DEPENDS = "A") but I don't know what task I should use for the injection. Can I do it in the
<guid>
do_install task? What path can I use to access the foo.crt file from the B recipe?
<jorschulko>
that wouldn't really be useful, as referencing a branch during the development process ist vital. However, you just gave me an idea. Say, we could detect, if the manifest is referencing a branch, then we could use a timestamp to force a do_fetch. If we do not detect a reference to a branch, we could just return the manifest SRCREV and therefore support offline builds for fixed refspecs. What do you
<jorschulko>
think?
<RP>
jorschulko: wouldn't you just add the head revision of the branch rather than a timestamp?
<jorschulko>
ah, that's an option? :D
<jorschulko>
that would cause yocto to run do_fetch every time right?
pidge has joined #yocto
<RP>
jorschulko: the idea is the configuration is meant to be deterministic so if gitsm is referring to floating stuff, the configuration should either be pinning it down or explictly floating
<RP>
jorschulko: i.e. either you set SRCREVS which match the branches, or it is configured to be floating. You'd not want to run do_fetch unless it changes, which you'd see if the branch revision changes
<martin31821>
RP: I'm working with jorschulko on that and want to add my thoughts. Basically, the repo fetcher takes the src URL of the git repository where the XML manifest for google repo lives. That manifest can reference branches, tags or specific revisions for every sub-git-repository. When having something like branch=master specified for the
<martin31821>
main-repository, we would then need to do an lsremote, resolve the revision, inspect the XML at that revision and for each referenced repository do an lsremote again to do it correctly. then we could return a revision key that contains *all* git hashes of all referenced repositories.
<martin31821>
the border between pinned down SRCREVS and floating is very unclear in google repo, since the branches are so decoupled
<RP>
martin31821: right, I think you will have to do something like that
<RP>
martin31821: the fetcher does have the concept of multiple revisions against a git repository so you may be able to use that here too. The hard part is creating a sensible user facing revision but as you say, you could create a hash of the values for that
<martin31821>
RP: in your thoughts, what would be the best option for offline builds, e.g. having a specific SRCREV or tag set for the main-repository? I still would somehow need to enforce that the XML manifest is completely pinned down in order to enforce reprodcability
<RP>
martin31821: I'm thinking that you'd want multiple SRCREV values set as you'd do with a git repo where you use multiple branches
lucaceresoli has quit [Ping timeout: 252 seconds]
<RP>
That way it would be totally pinned down and reproducible
<martin31821>
one for each referenced repository in the xml manifest?
<RP>
martin31821: each one that can change
<RP>
martin31821: so I guess each "unpinned" repository in the xml manifest
<martin31821>
that makes sense, although is kinda hard to implement
<RP>
martin31821: I didn't say it would be easy! :)
<RP>
I'm not sure I see another way though
<jorschulko>
Another issue remains when combining google repo with git submodules. Or is it possible to get the revision of submodules during a lsremote?
<RP>
jorschulko: I'm afraid I don't know
<jorschulko>
ok, stike the submodule question. Changing the submodule revision would change the main repo revision as well. so no issue here :)
<RP>
jordemort: submodules have their own issues with ensuring all the submodules are in the fetcher cache
<RP>
jordemort: the fetcher does know how to handle that but that in itself isn't simple
<jorschulko>
RP: could you kindly point us to an example for the multiple SRCREVS part?
<jaskij[m]>
Something that always bugged me: why does Google repo exist? What is wrong with making a git repo and pulling layers as submodules?
<tlwoerner>
qschulz: the strange thing is, we already were carrying a patch to add those aliases, specifically for the rk3328-based devices
<tlwoerner>
qschulz: and it was on my rk3328-based device (rock64) that i noticed the problem
<RP>
git://git.yoctoproject.org/yocto-kernel-cache;type=kmeta;name=meta;branch=yocto-5.10;destsuffix=${KMETA}" from meta/recipes-kernel/linux/linux-yocto_5.10.bb
<RP>
jorschulko: there is a bbclass which sets SRCREV_FORMAT too
<RP>
jorschulko: the kernel did used to use one url for two different branches
<RP>
jorschulko: if you go back in history you should find that version which is still supported by the fetcher too
meego has quit [Remote host closed the connection]
<tlwoerner>
qschulz: the patch we have and the patch you link to are different, but simply booting up the board x times in a row would still show the devices enumerate in different orders on each boot
meego has joined #yocto
arlen has joined #yocto
xmn has quit [Quit: xmn]
xmn has joined #yocto
<jorschulko>
@jaskij[m]: In our case we want to be able to easily combine some couple dozen repositories in various versions. Also, changes within one of the repos during development might require changes in multiple other repos. In repo this can easily be done by starting a topic, using submodules the developer (AFAIK) would have to separately clone these submodule repos in order to make changes and then update
<jorschulko>
each of the affected refspecs in the main repo. So it is just a matter of management overhead
xmn has quit [Ping timeout: 264 seconds]
zyga-mbp has joined #yocto
camus has quit [Ping timeout: 268 seconds]
camus has joined #yocto
martin31821 has quit [Ping timeout: 265 seconds]
camus1 has joined #yocto
camus has quit [Ping timeout: 260 seconds]
camus1 is now known as camus
<jorschulko>
RP: thanks for your input, it helped a lot! :)
<qschulz>
tlwoerner: probing order isn't deterministic so it's not a surprise that without it sometimes does not work as expected. But the fact that there are (supposedly, need to be checked at runtime) aliases defined for it and it's still non-deterministic is an issue
<qschulz>
and I'm surprised this is happening with the patch you sent
<jaskij[m]>
<jorschulko> "@jaskij[m]: In our case we..." <- That's not true. By default submodules check out as detached head, that's true, but you can then manually check out the submodule you're working on to a branch, work on it and push normally. When done you just add and commit the refspec change in parent repo.
lucaceresoli has joined #yocto
<jaskij[m]>
But I didn't ask it to disagree with you. I just have this nagging feeling I'm missing something by using submodules instead of repo. Because if one solution is vastly more popular there must be reasons. But I have yet to find that reason, except submodules being widely misunderstood and misused. And having clunky UX.
meego_ has joined #yocto
meego has quit [Ping timeout: 246 seconds]
tnovotny has quit [Quit: Leaving]
tnovotny has joined #yocto
<tlwoerner>
qschulz: do you have rockchip boards to test?
<tlwoerner>
incidentally i'm also seeing the same issue on my dragonboard-410c, hence why i poked ndec_ about editing the kernel cmdline
<tlwoerner>
the tricky thing is, you can boot the same image 5 times in a row and it'll work so you think the problem is solved, but then the 6th boot shows the problem
<ndec_>
which problem?
<tlwoerner>
hilariously, i was trying to bisect the kernel to figure out the bad commit and ended up landing on a patch that did nothing but fix a spelling mistake!!! hahah
<tlwoerner>
i almost lost faith in my ability to git bisect (lol)
<zeddii>
RP: I if wanted to see if there were those pkg-config inherit issues in meta-virt. Is building against poky master-next enough ? or did you turf some fo the proposed patches ?
<RP>
zeddii: the patch in question is still in master-next
<tlwoerner>
ndec_: the 5.13 kernel doesn't probe mmc devices in a deterministic way, so if you hardcode your image to boot, say, mmcblk1 then it'll only boot successfully roughly half the time
<zeddii>
ack'd. I'll have a test spin just to see then!
<RP>
zeddii: I am unlikely to take it for 3.4 as it does cause too many complaints. I merged the other do_build dependency changes though
<ndec_>
tlwoerner: was it ever done in a deterministic way?
<tlwoerner>
ndec_: in meta-rockchip i had to switch to using UUIDs (but apparently some are seeing issues with my recent patch)
<zeddii>
RP: gotcha. I'll just see if I can get ahead of it eventually landing and already have the layer in shape, if it needs anything that is.
<ndec_>
i thought we had been using PARTLABEL for quite some time.
<RP>
zeddii: I thought we cleaned things up a while ago but looks like things regressed :/
<zeddii>
indeed. I remember doing a bunch of changes adding inherit pkgconfig .. so I don't expect much. Just looking at the stream of changes in meta-oe, made me wonder.
<RP>
zeddii: I ran a build with the kernel uprev last night and it seemed fine. I have another running now with Kevin's change
<RP>
zeddii: if those pass, are we good?
<ndec_>
tlwoerner: hmm. no we stopped using hardcoded block device in our debian builds.. not in meta-qcom. but i think we should.
<RP>
zeddii: the changes in core surprised me too :/
<zeddii>
RP: yup. that's all we'd need. and I can follow up and purge, or you could during the merge. whatever is easiest.
<tlwoerner>
ndec_: but then i got lost in recipes-kernel/linux/linux-qcom-bootimg.inc
<RP>
zeddii: I'll let you followup :)
<jorschulko>
jaskij[m] huh... cool I didn't know that you could checkout within the submodule. However, you would still have to manually step into each of the submodules, create a branch, make your changes and push them. With repo you can e.g. create / push branches on all desired repos with one command
<ndec_>
tlwoerner: change QCOM_BOOTIMG_ROOTFS
<tlwoerner>
ndec_: using a UUID requires the removal of the "root=" kernel cmdline arg, hence my question earlier
<tlwoerner>
ndec_: oops, not the removal of root=, but modifying it to use UUID too
<tlwoerner>
hmm, not sure that's going to work on the dragonboard-410c
<ndec_>
i don't think you can use UUID, since you don't know the value, no?
arlen has quit [Remote host closed the connection]
<ndec_>
i was thinking about root=PARTLABEL=rootfs
<tlwoerner>
ndec_: i've switched to booting off the uSD card on my dragonboard-410c, it avoids all that messy android stuff ;-)
<ndec_>
tlwoerner: well, 'rootfs' here is the partition name. so you need to make sure you don't have the same name on emmc and sd, otherwise it won't work well :)
Schlumpf has quit [Quit: Client closed]
<tlwoerner>
ndec_: i don't think any of the android partitions (i.e. on the emmc) have that name (fingers crossed)
<jaskij[m]>
<jorschulko> "jaskij huh... cool I didn't know..." <- Huh, okay, yes, that can be useful if you're working on multiple layers at once.
<qschulz>
tlwoerner: I have some rk3399-puma-haiku available
linkliu61 has joined #yocto
<qschulz>
tlwoerner: do you have mmc0/mmc1 entries in /sys/firmware/devicetree/base/aliases/ directory?
<tlwoerner>
a bb.error() in an anonymous python doesn't seem to stop the build?
<tlwoerner>
the message does get printed, and the build returns failure, eventually, but subsequent tasks keep running
<tlwoerner>
qschulz: (i'm investigating, i'll do a clean build for my rock64 with my patch removed and just the alias patch, the build will take a bit)
<qschulz>
tlwoerner: you want bb.fatal maybe?
<RP>
tlwoerner: you want bb.fatal() to stop the build
<tlwoerner>
qschulz: RP: ahh, thanks! :-)
frieder has quit [Ping timeout: 252 seconds]
frieder has joined #yocto
camus1 has joined #yocto
meego has joined #yocto
camus has quit [Ping timeout: 265 seconds]
camus1 is now known as camus
Schlumpf has joined #yocto
meego_ has quit [Ping timeout: 252 seconds]
rob_w has quit [Quit: Leaving]
<tlwoerner>
qschulz: sweet! the rk3399-puma-haikou has upstream support, i'll expect a patch adding it to meta-rockchip? ;-)
otavio_ has joined #yocto
otavio has quit [Read error: Connection reset by peer]
<moto-timo>
kanavin: I've got it building and properly setting the PIN to get past the login screen, but it immediately fails after that and I haven't gotten back to diagnosing why... looks like gsettings-daemon issue
<ThomasD13>
Hmmm.. qschulz your suggestion with MACHINEOVERRIDES worked well, apart for that: SYSFW_PREFIX_j7-evm-k3r5 = "ti-fs-firmware"
Sion has quit [Ping timeout: 264 seconds]
<kanavin>
moto-timo, right, hope you find time to push it further
<ThomasD13>
j7-evm has multiconfig "k3r5"
<moto-timo>
kanavin: probably tomorrow
<qschulz>
ThomasD13: j7-evm-k3r5 is an OVERRIDES, so you need another one in MACHINEOVERRIDES
<ThomasD13>
My added machine-config "j7-paradise" with the MACHINEOVERRIDES = "j7-evm" seems not to pickup on that
<qschulz>
might make sense to have it in the multiconfig file but I know very little about multiconfig unfortunately :/
vd has joined #yocto
<ThomasD13>
Yeah, my guess is that this multiconfig crap is kind of a "special case"
<qschulz>
ThomasD13: that's TI crap :) I don't think it has anything to do with "usual"/Yocto multiconfig setup?
<ThomasD13>
yeah sorry, thats probably more true :)
<ThomasD13>
So I have a machine configuration, and can work there with MACHINEOVERRIDES
arlen has joined #yocto
<ThomasD13>
that makes sense to me - and this machine configuration is used for a second "config" (k3r5)
sakoman has joined #yocto
<qschulz>
ThomasD13: dig into TI configuration file and you'll see they are adding this to MACHINEOVERRIDES somehwere (probably a ${MACHINE}-k3r5 or something similar?)
guid has quit [Quit: Client closed]
<ThomasD13>
But why worked the MACHINEOVERRIDES not in that case?
<qschulz>
might be using the name of the other machine in the multiconfig setup but I don't know
<qschulz>
ThomasD13: because OVERRIDES works on full strings
<vd>
what is the best way to provide a .nspawn configuration file? its own package, systemd-conf, or systemd-container?
<ThomasD13>
ahhh
<qschulz>
so _j7-evm is matched by j7-evm only, _j7-evm-k3r5 won't match unless you have j7-evm-k3r5 in OVERRIDES somewhere
<ThomasD13>
ahhhhh alright. I thought yocto does know about j7-evm is machine of that string. Ok, makes sense now :)
<ThomasD13>
thank you
<qschulz>
tlwoerner: that would be possible indeed. Have to figure out how the defconfigs are working on arm64 upstream. I only remember there's a default defconfig and we usually have our own next to that one for our machines
<ThomasD13>
They have a multiconfig "k3r5.conf" with this: MACHINE_append = "-k3r5". Does this make the trick?
<qschulz>
ThomasD13: oof
meego has quit [Remote host closed the connection]
<tlwoerner>
qschulz: i'm working on a "best practices" config for rockchip, i've noticed things missing from the defconfig that hurt rockchip
<tlwoerner>
i.e. working with the linux-yocto tooling from zeddii :-)
<qschulz>
tlwoerner: the concern now is where the defconfigs mentioned in the machine config file are :D
meego has joined #yocto
<qschulz>
ThomasD13: so, basically the issue right now is that they are renaming the machine completely
<qschulz>
so... j7-evm never exists anymore
<qschulz>
in the context of a multiconf build obviously
<tlwoerner>
btw, Amit Kucheria is currently giving a talk discussing "yocto" @ plumbers
<qschulz>
so your MACHINEOVERRIDES is technically incorrect if we follow tht "logic"
<rburton>
tlwoerner: is that the huawai allscenario one?
<ThomasD13>
lol - okay. That sounds like a bad practise
<qschulz>
ThomasD13: if this does not break (it'll silently break/misconfigure/enable/disable stuff) your builds, then a simple MACHINEOVERRIDES .= ":j7-evm-k3r5" in your multiconf file might be enough
<moto-timo>
Interesting talk so far… the slides are sparse
<moto-timo>
So video watching will be required
<ThomasD13>
qschulz, got it. I give it a try. thank you so much. I even have a testcase for this :)
meego_ has joined #yocto
fbre has quit [Quit: Client closed]
meego has quit [Ping timeout: 268 seconds]
kiran has joined #yocto
meego_ has quit [Ping timeout: 268 seconds]
<tlwoerner>
karim expresses an odd sentiment
meego has joined #yocto
pidge has quit [Quit: Client closed]
pidge has joined #yocto
kayterina has quit [Remote host closed the connection]
<JosefHolzmayr[m]>
does nodejs on master really compile for 1h+x on a mid-size box? (like, 16cores)
jorschulko has quit [Quit: leaving]
meego_ has joined #yocto
meego has quit [Ping timeout: 268 seconds]
vd has quit [Quit: Client closed]
vd has joined #yocto
Schlumpf has quit [Quit: Client closed]
frieder has quit [Remote host closed the connection]
<Tartarus>
moto-timo: Hey, smurray said perhaps I should poke you about poking some of the crops folks to update the containers, lz4c, pzstd and zstd are missing from cropy/poky:ubuntu-20.04 (and all the rest I assume) which master requires now
<moto_timo[m]>
Tartarus: right... rewitt has been maintaining things on a best-effort basis
<rburton>
moto_timo[m]: maybe he needs to open up the repo to a co-maintainer
<rburton>
maybe called Tim
<moto_timo[m]>
rburton: I have write privileges, but I have been respecting his final word
<rburton>
you could be a co-maintainer so you can push the aarch64 image
<rburton>
because right now, i'm telling people who want arm build containers to use the kas container
<Tartarus>
I mean, is crops open to pull requests? I should update my build system to something a tiny bit less old, but I've also found just firing off crops and building in that fairly handy
tnovotny has quit [Quit: Leaving]
<moto-timo>
Tartarus: crops is open to pull requests. the place to put the change is in yocto-dockerfiles
<Tartarus>
moto-timo: OK, yeah, thanks. I'll do a PR if things don't get updated by the time I'm needing to poke this again. :)
<moto-timo>
most of my daily usage is now kas based, so I haven't been using crops as much recently
whuang0389 has joined #yocto
<whuang0389>
Is there a way to unmask a service in a recipe??
<whuang0389>
(I want it unmasked, but not enabled)
ThomasD13 has quit [Ping timeout: 264 seconds]
dev1990 has joined #yocto
pidge has quit [Quit: Client closed]
camus1 has joined #yocto
camus has quit [Remote host closed the connection]
camus1 is now known as camus
DanielWalls[m] has quit [Remote host closed the connection]
olani[m] has quit [Remote host closed the connection]
hpsy[m] has quit [Remote host closed the connection]
hereiam[m] has quit [Remote host closed the connection]
michaelo[m] has quit [Read error: Connection reset by peer]
barath has quit [Read error: Connection reset by peer]
Alban[m] has quit [Remote host closed the connection]
behanw[m] has quit [Remote host closed the connection]
k4wsys[m] has quit [Read error: Connection reset by peer]
cryptollision[m] has quit [Read error: Connection reset by peer]
Pierre-jeanTexie has quit [Remote host closed the connection]
jordemort has quit [Read error: Connection reset by peer]
lexano[m] has quit [Read error: Connection reset by peer]
meck[m] has quit [Write error: Connection reset by peer]
ezzuldin[m] has quit [Remote host closed the connection]
moto_timo[m] has quit [Write error: Connection reset by peer]
berton[m] has quit [Read error: Connection reset by peer]
janvermaete[m] has quit [Remote host closed the connection]
JosefHolzmayr[m] has quit [Remote host closed the connection]
Emantor[m] has quit [Read error: Connection reset by peer]
PascalBach[m] has quit [Remote host closed the connection]
kranzo[m] has quit [Remote host closed the connection]
ejoerns[m] has quit [Remote host closed the connection]
jaskij[m] has quit [Remote host closed the connection]
xicopitz[m] has quit [Remote host closed the connection]
kayterina[m] has quit [Write error: Broken pipe]
jwillikers[m] has quit [Write error: Connection reset by peer]
Spectrejan[m] has quit [Remote host closed the connection]
WadeBerrier[m] has quit [Remote host closed the connection]
ramprakash[m] has quit [Remote host closed the connection]
CarlesFernandez[ has quit [Remote host closed the connection]
t_unix[m] has quit [Write error: Connection reset by peer]
scjg has quit [Write error: Connection reset by peer]
coldspark29[m] has quit [Write error: Broken pipe]
hmw[m] has quit [Write error: Connection reset by peer]
dwagenk has quit [Write error: Connection reset by peer]
falk0n[m] has quit [Remote host closed the connection]
twinning[m] has quit [Remote host closed the connection]
agherzan has quit [Remote host closed the connection]
fabatera[m] has quit [Remote host closed the connection]
SalamaSalama[m] has quit [Write error: Connection reset by peer]
mahu[m] has quit [Remote host closed the connection]
Jari[m] has quit [Remote host closed the connection]
shoragan[m] has quit [Write error: Connection reset by peer]
khem has quit [Read error: Connection reset by peer]
<kanavin>
alimon, are you aware of ptest-runner patches floating about?
kiran has quit [Ping timeout: 260 seconds]
zpfvo has quit [Read error: Connection reset by peer]
jordemort has joined #yocto
WadeBerrier[m] has joined #yocto
<alimon>
kanavin: not yet, i will review it, thanks for notice me, these days i'm returning from OOO
lexano[m] has joined #yocto
scjg has joined #yocto
Alban[m] has joined #yocto
Spectrejan[m] has joined #yocto
kayterina[m] has joined #yocto
Emantor[m] has joined #yocto
shoragan[m] has joined #yocto
meck[m] has joined #yocto
khem has joined #yocto
<kanavin>
alimon, thanks. Hope you're ok.
Pierre-jeanTexie has joined #yocto
ejoerns[m] has joined #yocto
moto_timo[m] has joined #yocto
t_unix[m] has joined #yocto
dwagenk has joined #yocto
PascalBach[m] has joined #yocto
falk0n[m] has joined #yocto
<alimon>
kanavin: i'm fine thanks, regarding the patch that counts the errors so we should return 0 when success and 1 when fails without count. the proposed patch didn't return 0 when succeed.
CarlesFernandez[ has joined #yocto
k4wsys[m] has joined #yocto
coldspark29[m] has joined #yocto
barath has joined #yocto
jwillikers[m] has joined #yocto
behanw[m] has joined #yocto
kiran has joined #yocto
Nate[m]1 has joined #yocto
twinning[m] has joined #yocto
DanielWalls[m] has joined #yocto
hmw[m] has joined #yocto
Jari[m] has joined #yocto
kranzo[m] has joined #yocto
fabatera[m] has joined #yocto
agherzan has joined #yocto
ezzuldin[m] has joined #yocto
JosefHolzmayrThe has joined #yocto
<alimon>
kanavin: i see there is a new patch
xicopitz[m] has joined #yocto
camus has quit [Ping timeout: 252 seconds]
ramprakash[m] has joined #yocto
janvermaete[m] has joined #yocto
Markus[m]1 has joined #yocto
cryptollision[m] has joined #yocto
olani[m] has joined #yocto
SalamaSalama[m] has joined #yocto
camus has joined #yocto
michaelo[m] has joined #yocto
berton[m] has joined #yocto
whuang0389 has quit [Quit: Client closed]
jaskij[m] has joined #yocto
hpsy[m] has joined #yocto
<kanavin>
alimon, yes, and some patches from me
argonautx has quit [Ping timeout: 252 seconds]
<alimon>
kanavin: yes i find this one, [ptest-runner][PATCH 3/3] utils.c: add system data collection when a test gets stuck
<alimon>
kanavin: do you have a repo/branch for this patches, for some reason git am is failing to apply
<tlwoerner>
qschulz: so a completely fresh/clean build of 5.13.y doesn't find the sdcard even with the patch i pointed you to earlier that explicitly sets mmcblk1 to the sdmmc (in the DT)
<tlwoerner>
and i can't verify what's in /sys/firmware/… because it doesn't get to a prompt ;-)
<alimon>
kanavin: is unable to build an ancestor, i'm using git version 2.33.0
<qschulz>
tlwoerner: or use dtc -I dtb -O dts on the output dtb
zyga-mbp has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<alimon>
kanavin: did you see that issue before with git am?, i wonder if is because of the version, i'm running debian sid
<alimon>
git version*
kiran has quit [Ping timeout: 250 seconds]
<kanavin>
alimon, I really don't know, I used standard git send-email with debian testing
florian has quit [Quit: Ex-Chat]
prabhakarlad has quit [Quit: Client closed]
<moto-timo>
kanavin: JPEW: actually phoc might be unhappy because the virtual keyboard (squeakboard) isn't present... that's the "Fatal server error:" "(EE) Failed to activate virtual core keyboard"
<moto-timo>
kanavin: JPEW: squeakboard requires Rust... hacking at the recipe now
prabhakarlad has joined #yocto
<kanavin>
moto-timo, I tried to play with phosh on latest fedora and it didn't go far, crashes on startup
<moto-timo>
kanavin: :(
<kanavin>
and squeakboard is fairly obtrusive, it pops up on screen every time an input widget gets focus - even when there is no touchscreen, and there is a physical keyboard
<kanavin>
but fedora carries fairly outdated versions
<moto-timo>
kanavin: ah, good to know. phosh is certainly targeting a phone/handset user experience. so it might need hacking to be a generic tablet/kiosk interface
<kanavin>
moto-timo, we certainly don't want squeakboard to take half the window in qemu
<moto-timo>
kanavin: absolutely not!
* moto-timo
stops working on squeekboard recipe
<moto-timo>
It would be ok if it had a "keyboard" icon on screen that you could hit to bring up the virtual keyboard, but if it automatically shows up just because there is a user input... nope
argonautx has joined #yocto
<kanavin>
moto-timo, again, this is what is in fedora, it may work better with latest code
<moto-timo>
I'm starting to wonder if rburton's idea to port matchbox might be better ... sigh
<moto-timo>
kanavin: ok. I'll keep poking at it
<kanavin>
moto-timo, yes please
<moto-timo>
kanavin: also, we haven't tried interacting with upstream yet, so who knows what is possible
vd has quit [Quit: Client closed]
argonautx has quit [Ping timeout: 252 seconds]
<ad__>
on gatesgarth, seems there is not way i can generate a zImage (tried KERNEL_IMAGETYPE = "zImage")
<ad__>
i always find a Image as output
vd has joined #yocto
<ad__>
oooh, ok, cannot have zImage for imx8mp
whuang0389 has joined #yocto
sethfoster has joined #yocto
<sethfoster>
Hey folks. I have a kconfig fragment that I've added to a .bbappend for my (bsp's) kernel recipe via SRC_URI that appears to get loaded - it's in the work dir for the kernel - but not actually applied to .config. Does anybody know why that might happen?
<sethfoster>
Do kconfig fragments _have_ to be in a directory named ${PN}? i have mine in one just called "defconfigs" (to differentiate from another with dtree fragments)
<Tartarus>
Is there a packagegroup for "I want to build the kernel, on device" today?
FredO2 has joined #yocto
FredO has quit [Ping timeout: 252 seconds]
<vd>
When is planned Honister?
<tlwoerner>
Tartarus: adding "tools-sdk" to EXTRA_IMAGE_FEATURES will add gcc, make, pkgconfig etc to your image
<Tartarus>
tlwoerner: Yes, that's missing several packages for 5.14.x and arm64 defconfig
<Tartarus>
I knew to add bison/flex before firing this off, and bc was easy enough to manually whack in. Rebuilding for perl stuff
meego_ has quit [Ping timeout: 246 seconds]
florian has joined #yocto
whuang0389 has quit [Quit: Ping timeout (120 seconds)]
kiran has joined #yocto
vd has quit [Quit: Client closed]
prabhakarlad has quit [Quit: Client closed]
<alimon>
kanavin: just pushed your changes, i think is ready to bump to v2.4.2
<kanavin>
alimon, thanks! we've been seeing lttng-ptest lockups and this would help figure out where and what
vd has joined #yocto
<vd>
RP: do depends and mcdepends really need to be separated? supporting both forces us to duplicate lot of code to determine if the dependency is from a multiconfig or from BB_CURRENT_MC
camus has quit [Ping timeout: 240 seconds]
camus has joined #yocto
argonautx has joined #yocto
prabhakarlad has joined #yocto
<abelloni>
kanavin: should I try your librsvg update ? ;)
roussinm has joined #yocto
florian has quit [Ping timeout: 252 seconds]
sethfoster has quit [Ping timeout: 265 seconds]
vd has quit [Quit: Client closed]
vd has joined #yocto
<vd>
Do we agree that do_thistask[depends] += "foobar:thattask" is equivalent to do_thistask[mcdepends] += "mc:${BB_CURRENT_MC}:${BB_CURRENT_MC}:foobar:thattask" ? Cc: abelloni RP
sethfoster has joined #yocto
prabhakarlad has quit [Quit: Client closed]
prabhakarlad has joined #yocto
<sethfoster>
Does anybody know why a kconfig snippet file might not apply properly? it seems to be detected but not applied
<vd>
sethfoster: what kernel recipe are you using?
<sethfoster>
specifically the "config fragment" approach
florian has joined #yocto
argonautx has quit [Ping timeout: 252 seconds]
<sethfoster>
vd: oh you know what i think i did not properly read the big warning about .config not containing config fragment overrides
prabhakarlad has quit [Quit: Client closed]
agners has joined #yocto
sethfoster has quit [Quit: leaving]
<RP>
vd: they probably don't have to be separated in hindsight. At the time they were implemented that wasn't very clear
<RP>
and yes, that looks about right to be equivalent
<RP>
mcdepends does mean bitbake can know relatively easily if it is dealing with cross multiconfigs or not
<RP>
there are other ways to do that but it makes it harder on bitbake
whuang0389 has joined #yocto
<vd>
RP: OK so one might simply stick with mcdepends (with a fallback to mc:::pn:task) instead of dealing with both. In which case would you use a multiconfig_from different than BB_CURRENT_MC (e.g. mc:NOTCURRENT:foo:bar:baz)?
<RP>
vd: I don't remember, I'd have to go and look at what that code is doing.
<whuang0389>
does anyone know how I can find which recipe is installing the weston.ini file?
* RP
doesn't have all this on instant recall :(
<RP>
whuang0389: I think oe-pkgdata-util can tell you
<whuang0389>
RP thanks so much!
<RP>
vd: When you write an mcdepends in a recipe, you want to be able to say which mc it should apply within
<RP>
so X[mcdepends] += "mc:A:B:C:D" will only apply in the A mc space even if the mcdepends was defined in all the different mcs
<vd>
RP: so building mc:E:pn won't pull in B:C as a dependency for X?
amitk has quit [Ping timeout: 264 seconds]
<RP>
vd: that is what I understand
<vd>
so multiconfig_from would act as an implicit condition against BB_CURRENT_MC
<RP>
vd: I think so
<vd>
I'm trying to find a valid usecase for that
<RP>
vd: if you're trying to write flat configuration files, it was necessary iirc
<RP>
people expect mutliconfig to be useful and usable in different ways
<RP>
One of the reasons for putting mcdepends separately was so we could change details like this if we needed to
<RP>
(iirc)
<vd>
RP: is there a way to know the DEPLOY_DIR_IMAGE path of an mcdepends? or one should guess it? It's tricky if the multiconfig changed TMPDIR for example.
<RP>
vd: there is not a way to know, no
<RP>
it is assumed the multiconfig knows how it sets up the individual configs
<RP>
zeddii, khem: Looks like 5.14 is passing on the autobuilder apart from the meta-oe failure. Not sure what to do now :/
xmn has joined #yocto
<whuang0389>
uhm is there a way to bitbake a recipe without clearing work after it's done?
<RP>
whuang0389: turn off rm_work?
<whuang0389>
RP thanks again haha
<RP>
Saur: I opened your email with some trepidation, glad it helped :)
<zeddii>
RP: I was cleaning up some -dev loose ends, and was looking at the vbox build here. no fix yet. but will poke at it more later.
<RP>
zeddii: I don't know if we block on that, I do feel bad I've given meta-oe a rough week
<RP>
zeddii: I've not had a chance to look at it. Maybe tomorrow if nobody else beats me to it
<zeddii>
I'll leave a message here in IRC with whatever I sort out, if I fix it, there will be a patch to meta-oe
* zeddii
sees what the kernel changed to break the build
lucaceresoli has quit [Ping timeout: 265 seconds]
<vd>
should I use distro feature "vulkan" or "opengl" to run chromium-ozone-wayland (from meta-browser/meta-chromium) on a beaglebone black?
camus has quit [Read error: Connection reset by peer]
camus1 has joined #yocto
camus1 is now known as camus
<smurray>
vd: I'd be somewhat surprised if vulkan is supported with the PowerVR stuff for BBB
kiran has quit [Ping timeout: 260 seconds]
florian has quit [Ping timeout: 260 seconds]
<vd>
smurray: should I remove vulkan from the distro features then? I'm not sure to understand what the recipe chooses to build with the two specified
<smurray>
vd: I probably would
dev1990 has quit [Quit: Konversation terminated!]
xmn has quit [Read error: Connection reset by peer]
xmn has joined #yocto
<vd>
smurray: I kept only opengl as a distro feature and restarted the build from scratch. I'm using meta-ti's linux-ti-staging kernel, I hope it'll be enough for a functional chromium.
<vd>
too bad there's no reliable web browser for embedded devices, ideally using the framebuffer directly... some exist and work well but are really rudimentary, most websites won't work.