<mckoan>
jclsn: yes fatal: Could not read from remote repository.
<mckoan>
Please make sure you have the correct access rights
<mckoan>
and the repository exists.
<jclsn>
mckoan: So by reposity my Artifactory is meant I guess? That would be weird, because it could fetch all sources in the previous build step
<jclsn>
"Could not read the remote repository" is a git error though
<jclsn>
There is also something with SSH and Artifactory is http
<jclsn>
It seems to me like it can't check out from the NXP server
leon-anavi has joined #yocto
gho has joined #yocto
gho has quit [Quit: Leaving.]
gho has joined #yocto
nemik has quit [Ping timeout: 268 seconds]
nemik has joined #yocto
<qschulz>
jetm: IIRC the only thing that is not supported is files disappearing (so someone running -c cleansstate for example)
<qschulz>
jetm: but shared sstate-cache and downloads directories is widely used
<qschulz>
for CI/CD
<qschulz>
if you want your users to benefit from the sstate-cache/downloads, set up a PREMIRRORS for your downloads directory and a SSTATE_MIRROR for your sstate-cache
<qschulz>
PhoenixMage: that's bad luck :/ at least one issue out of the way :)
AKN_R has joined #yocto
AKN has quit [Ping timeout: 268 seconds]
d-s-e has joined #yocto
florian has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
alessioigor has quit [Client Quit]
alessioigor has joined #yocto
hmw[m] has joined #yocto
nemik has quit [Ping timeout: 260 seconds]
nemik has joined #yocto
Guest9764 has joined #yocto
gho has quit [Quit: Leaving.]
gho has joined #yocto
alessioigor has quit [Quit: alessioigor]
nemik has quit [Ping timeout: 248 seconds]
alessioigor has joined #yocto
alessioigor has quit [Remote host closed the connection]
alessioigor has joined #yocto
nemik has joined #yocto
AKN_R has quit [Read error: Connection reset by peer]
starblue has quit [Ping timeout: 268 seconds]
mvlad has joined #yocto
starblue has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
marek has quit [Quit: Client closed]
Guest9764 has quit [Quit: Client closed]
prabhakarlad has quit [Quit: Client closed]
marek has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
prabhakarlad has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
LocutusOfBorg has quit [Ping timeout: 252 seconds]
prabhakarlad has quit [Quit: Client closed]
prabhakarlad has joined #yocto
PhoenixMage has quit [Remote host closed the connection]
sr2 has quit [Quit: Client closed]
d-s-e has quit [Quit: Konversation terminated!]
LocutusOfBorg has joined #yocto
nemik has quit [Ping timeout: 268 seconds]
nemik has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
nemik has quit [Ping timeout: 260 seconds]
nemik has joined #yocto
florian_kc has joined #yocto
florian_kc has quit [Ping timeout: 268 seconds]
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
rob_w has quit [Remote host closed the connection]
marek has quit [Quit: Client closed]
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
florian_kc has joined #yocto
LetoThe2nd has quit [Quit: WeeChat 3.5]
hsv has joined #yocto
Guest92 has joined #yocto
<Guest92>
hi
LetoThe2nd has joined #yocto
<Guest92>
I have built a yocto project. I want to change one of the (binary intermediate) files used and rebuild it. Just to test something out, I don't need to make this a new permanent recipe. How can do this?
sakoman has joined #yocto
xmn has joined #yocto
goliath has joined #yocto
florian_kc has quit [Ping timeout: 268 seconds]
d-fens has joined #yocto
<d-fens>
hi guys, i have the task to setup a yocto build environment and there is already bitbucket used but i feel this would not run good as a ci task due to the memory needed and the long (and costly) runtime, my preference would be a dedicated worker machine but TLDR; is there a best practice to handle image and app build both hosted on bitbucket?
Habbie has quit [Ping timeout: 252 seconds]
nemik_ has joined #yocto
<nemik_>
Hello. I'm trying to do a `devtool modify u-boot-imx` on Yocto 3.2 on an Ubuntu 20.04 machine, but I keep getting "Exception: ModuleNotFoundError: No module named '_sysconfigdata'". Other devtool modify commands work
<nemik_>
I looked up an old chat and found a link to a solution that worked for me at https://patchwork.openembedded.org/patch/175735/ but that link is now dead :(. I remember having to change something in the poky layer but I can't find the answer with Google at all. Does anyone have any hints please?
<qschulz>
nemik_: you can ask kanavin if he still has a local copy or if something was merged for this
<JaMa>
nemik_: 3.2 is out of support for quite some time, upgrading to kirkstone would probably fix that, if you really need to stay on gatesgarth, then check if this issue already was on dunfell (as there might be a backported fix there easier to find)
<qschulz>
but contrib git repos are not expected to be stable/kept
<qschulz>
they are just for contributors to test things out
<JaMa>
I think oe-core 5a118d4e7985fa88f04c3611f8db813f0dafce75 and follow-up fixes were part of that final solution
nemik has quit [Ping timeout: 260 seconds]
nemik has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
<nemik_>
JaMa: thank you! I'll have a look there. unfortunately I need to make a u-boot edit for an existing product on gatesgarth and I can't update to kirkstone
<nemik_>
JaMa: that worked! thank you again very much for the help. I really appreciate it.
hpsy[m] has quit [Quit: You have been kicked for being idle]
nemik has quit [Ping timeout: 268 seconds]
nemik has joined #yocto
<xcm_>
hey all. i'm attaching a usb serial device on my yocto machine. in other distributions it seems that the baud rate etc are automagically detected (when checking with stty). this doesn't seem to happen on yocto. am i missing something?
nemik has quit [Ping timeout: 260 seconds]
nemik has joined #yocto
alessioigor has quit [Quit: alessioigor]
nemik has quit [Ping timeout: 248 seconds]
nemik has joined #yocto
KristinTeam4U has joined #yocto
<KristinTeam4U>
greetings looking for ppl to join team for passive income all work on computer and phone, you have to pay nothing this is my website https://earnbysellinginternetpack.blogspot.com pls dont forget to try, if you seeing my blogspot site from phone pls bookmark it so that you can do all from computer becoz phone has limited RAM
KristinTeam4U has left #yocto [#yocto]
ecdhe has joined #yocto
nemik has quit [Ping timeout: 260 seconds]
nemik has joined #yocto
jclsn has quit [Ping timeout: 246 seconds]
nemik has quit [Ping timeout: 252 seconds]
prabhakarlad has quit [Quit: Client closed]
nemik has joined #yocto
nemik has quit [Ping timeout: 268 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 260 seconds]
nemik has joined #yocto
gho has quit [Quit: Leaving.]
<tortoise>
I'm trying to understand why my changes to a recipe aren't working as expected. The goal was to apply a patch but it looks like it's not applying. When I run bitbake linux-yocto it fails because the patch didn't get applied so there is no Make target for my device tree. But I'm at a loss for how to figure out why bitbake isn't applying my patch from the recipe
<tortoise>
I ran. bitbake -c cleanall linux-yocto before trying again in case there was some state that was skipping over running that part of the recipe that I changed
<mckoan>
tortoise: this is not linux-yocto, it is linux-meson64_5.15.bb
<mckoan>
try bitbake linux-meson64
<tortoise>
when I try bitbake linux-meson64 I get errors that seem to tell me to use linux-yocto
<tortoise>
ahh in my image it includes conf/machine/include/amlogic-modern-boot.inc which sets that PREFERRED_PROVIDER ... I'll try building my image and seeing if it applies the patch
<JaMa>
also use bitbake -e to see if your .patch is really in SRC_URI
<mckoan>
tortoise: good luck and have a nice weekend
mckoan is now known as mckoan|away
<rburton>
tortoise: don't set the machine variables in the image
<rburton>
your local.conf sets MACHINE=foo.conf, that foo.conf should set PREFERRED_PROVIDER. you *can* override it in local.conf yourself if you're experimenting with different kernels, but the standard is for the machine to set the default.
vladest has joined #yocto
leon-anavi has quit [Remote host closed the connection]
<tortoise>
well I'm not doing that per-se I'm just following meta-meson's directions, so MACHINE is set as an environment variable before building my image. And I know that the corresponding conf for my board includes that amlogic-modern_boot.inc
<tortoise>
Unfortunately, it sets it to PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto" ... so I'm probably making a mistake about where the device tree is provided , will keep investigating and maybe clarify with the meson folks
<tortoise>
I probably was supposed to add the patch to linux-yocto_5.15.bbappend instead of that linux-meson64_5.15.bb
<rburton>
as that's the kernel they specify, yes
xmn has quit [Ping timeout: 246 seconds]
xmn has joined #yocto
prabhakarlad has joined #yocto
<tortoise>
in the bbappend they already have one line that starts
<tortoise>
SRC_URI:append:meson-gx
<tortoise>
the specifier after SCR_URI:append, meson-gx ... I'm not sure how to interpret that meson-gx
<tortoise>
That is I don't now if that append applies for my machine which I think is a meson-g12a... should I be adding a new line to bbappend that is SRC_URI:append:meson-g12a ... what values after the last colon referring to, so I can cross reference in the meta-meson project
<tortoise>
there is an example in the docs for the meta-raspberrypi project SCR_URI:append:rpi ... but I don't think that layer has any other types (for lack of a better word right now) than just rpi
<tortoise>
"list additional source files to use when rpi is found in the list of OVERRIDES"
<tortoise>
I guess my question is how do I know which override applies for my machine's build
<tortoise>
or is it referring to the SOC_FAMILY from this include
<tortoise>
which I don't think applies to my build
<rfs613>
sakoman: if you're around, I have a question related to CVE fixes for golang-1.14 on the dunfell branch
dmoseley has joined #yocto
<rfs613>
a number of the open CVEs (per the weekly report) fall outside of the ustream policy ("only last two releases get patched")
<sakoman>
rfs613: I'm here
<rfs613>
backporting those to 1.14 is mostly straightforward, i've done that, will post patches to the list
<rfs613>
sakoman: oh excellent!
<rfs613>
but there are a few odd ones, like CVE-2021-33194 for example
<rfs613>
the weekly report flags that one against go:go-native
amitk has quit [Ping timeout: 260 seconds]
<rfs613>
but when I go looking, the bug seems to be in golang.org/x/net, which near as I can tell, is not part of the basic go build.
<rfs613>
any idea how the weeky CVE scan is picking up that particular CVE? (there are couple more similar ones)
<sakoman>
I guess there are a couple of options 1) send a request to update the CVE database to call out the correct package or 2) whitelist this in the go recipe with a detailed explanation in the commit message (as well as a comment in the code)
<sakoman>
The scan is picking it up because the CVE database assigns the issue to particular golang releases
<rfs613>
the CPE strings are matching, is that what you mean?
<sakoman>
yes
<rfs613>
ok i gotcha
<sakoman>
hence the two options above
<rfs613>
yup makes sense
<rfs613>
OTOH it is a mess to actually track where it needs to be fixed... if someone uses this package, there are vulns, but they might pull it in indirectly (building some code using golang that happens to "go get" this module)
<sakoman>
I'm not at all familiar with go, so I'm afraid I can't offer much advice beyond the obvious :-(
<rfs613>
in my case, the main user of golang is in fact docker (build by yocto).. so I guess I need to do more grepping to see if docker/containerd/... might use this module
<rfs613>
but it feels like whack-a-mole
<sakoman>
Good luck! Once you sort it out a patch would be welcome :-)
<rfs613>
yup, appreciate your time, patches (at least for the simple stuff) will likely go out next week
nemik has quit [Ping timeout: 268 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 248 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 260 seconds]
nemik has joined #yocto
kscherer has quit [Quit: Konversation terminated!]
nemik has quit [Ping timeout: 268 seconds]
nemik has joined #yocto
olani has joined #yocto
nemik has quit [Ping timeout: 268 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 268 seconds]
nemik has joined #yocto
<rfs613>
studing this a bit more, it seems the golang.org/x/net module gets used during the build of go itself (it is listed in src/go.mod)... so I guess that means go itself might be subject to the CVE... in addition to any other code that happens to use this module.
zkrx has joined #yocto
mvlad has quit [Remote host closed the connection]
seninha has quit [Ping timeout: 260 seconds]
seninha has joined #yocto
seninha has quit [Remote host closed the connection]
<yolo>
there is also yoe-distro, used yocto a while ago, it seems new stuff pops out
sr2 has joined #yocto
<yolo>
is RDK the Yocto for CPEs
nemik has quit [Ping timeout: 260 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 260 seconds]
nemik has joined #yocto
<tortoise>
I found a bug in a recipe, where it assumes that do_configure has run before do_populate_lic ... which doesn't appear to be true, at least on the first run of the recipe. Is there a way to specify dependencies between tasks, or re-order them?