camus has quit [Read error: Connection reset by peer]
camus1 is now known as camus
Vonter has quit [Ping timeout: 256 seconds]
goliath has joined #yocto
leon-anavi has joined #yocto
kroon has joined #yocto
lucaceresoli_ has joined #yocto
frieder has joined #yocto
lucaceresoli_ has quit [Ping timeout: 240 seconds]
rfuentess has joined #yocto
Nathan85 has joined #yocto
rob_w has joined #yocto
vmeson has quit [Ping timeout: 240 seconds]
zpfvo has joined #yocto
<Nathan85>
Am I correct in thinking that INSANE_SKIP_${PN} += "already-stripped" should get rid of the following QA error? Seems to work on dunfell but honister seems to ignore it. Just checking before I go and create a repo to reproduce this issue and go down the rabbit hole of figuring out why it's not behaving the way I'd expect it to!
<Nathan85>
"QA Issue: File '/var/lib/shared/e8f2/diff/usr/sbin/rmt-tar' from custom-recipe was already stripped, this will prevent future debugging! [already-stripped]"
lucaceresoli has joined #yocto
tre has joined #yocto
zpfvo has quit [Ping timeout: 256 seconds]
shoragan has quit [Excess Flood]
zpfvo has joined #yocto
shoragan has joined #yocto
davidinux has quit [Ping timeout: 256 seconds]
ex-bugsbunny has joined #yocto
davidinux has joined #yocto
<Nathan85>
"d.getVar('INSANE_SKIP:' + pn"
<Nathan85>
Oh, that's right - needs to be a colon instead of a underscore. That one keeps catching me out porting the packages across!
dev1990 has joined #yocto
Nathan85 has quit [Quit: Connection closed]
mckoan|away is now known as mckoan
<mckoan>
good morning
<LetoThe2nd>
yo dudX and mckoan
davidinux has quit [Ping timeout: 250 seconds]
davidinux has joined #yocto
Habbie has quit [Ping timeout: 250 seconds]
rob_w has quit [Quit: Leaving]
mvlad has joined #yocto
Habbie has joined #yocto
florian has joined #yocto
Nathan20 has joined #yocto
olani has quit [Ping timeout: 240 seconds]
olani has joined #yocto
<RP>
morning
florian has quit [Ping timeout: 250 seconds]
<mckoan>
hi RP, LetoThe2nd, all
zpfvo has quit [Ping timeout: 256 seconds]
zpfvo has joined #yocto
frieder has quit [Remote host closed the connection]
frieder has joined #yocto
frieder has quit [Remote host closed the connection]
<RP>
rburton: ltp crashed in the controllers test on arm, caused a hung system showing rcu stalls :/
frieder has joined #yocto
<landgraf>
Does someone know why headrev cache (BB_SRCREV_POLICY) is disabled by default and what will enabling cost?
rob_w has joined #yocto
<RP>
landgraf: people expect revisions to be looked up at each bitbake invocation. Enabling it means you'd be responsible for deciding when you wanted to to look upstream again
<landgraf>
cache is cleaned even if do_fetch() is not needed
zpfvo has joined #yocto
* landgraf
will think more about it
<landgraf>
RP: thanks!
florian has joined #yocto
<RP>
landgraf: the do_unpack issue is a bug, it shouldn't do that :(
zpfvo has quit [Ping timeout: 256 seconds]
zpfvo has joined #yocto
<zyga[m]>
hello
<landgraf>
RP: sure. I have a fix for it but it looks complex and overengineered. there's should be an easier way.
<zyga[m]>
I'm interested in helping out with go 1.18 support, go.workspace and other new features, properly
<zyga[m]>
I heard that someone was also interested in that, in case that person is around I would love to talk
<RP>
landgraf: did you share it anywhere? I'm curious :)
<zyga[m]>
my tl;dr; idea is to use a global (build-wide) go.workspace
<zyga[m]>
and allow local.conf to override any package selections so that build is more cohesive as a while (up to the developer's desire)
<zyga[m]>
and to use go built-in module feature to implement correct downloads
<zyga[m]>
this way network ofline mode would actually work
<landgraf>
RP: not yet. it calls rev-parse instead of ls-remote if BB_NO_NETWORK (and this doesn't work with rebaseable repos but who uses them :) )
<zyga[m]>
I'm not sure if packages should be split at the dependency level - that has one huge risk - multi-version
<zyga[m]>
where two programs may depend on two separate versions of a library correctly, requiring that both versions are packaged and downloaded
<zyga[m]>
it's a little bit easier to do if there's no need to split each library
<zyga[m]>
but that has downsides on making licensing data clearly available
<zyga[m]>
as the effective license will almost always be a complex expression
<RP>
landgraf: you'd be surprised the people who think changing a tag is ok :/
<landgraf>
RP: I know such projects...
<landgraf>
without network connections it will not anyway so I'd raise an exception there (or use the cache)
<RP>
zyga[m]: the people I know with the most interest/experience with go (e.g. zeddii ) are hopefully asleep at the moment, just in case you wonder why things are quiet
<zyga[m]>
RP: I see, I'll keep an eye out, thanks to matrix keeping me connected without all the bouncer setups I never did
<zyga[m]>
RP: it's not urgent but I definitely want to get go.mod support to work well in yocto this year
<zyga[m]>
I'm happy to join any existing effort to get that done
<zyga[m]>
or implement one from scratch if there's agreement on the direction
<RP>
zyga[m]: it is definitely a problem we need to solve in some way. There have been some discussions on the mailing list and on our weekly tech call
<zyga[m]>
oh, I need to check out the tech call
<zyga[m]>
and catch up on the mailing list
<RP>
zyga[m]: please do sync with zeddii (Bruce Ashfield) as I think he has looked at this the most
<zyga[m]>
ack, will do
zyga[m] has left #yocto [#yocto]
zyga[m] has joined #yocto
GillesM has joined #yocto
<landgraf>
RP: another issue is that fetcher_init is not called from within bitbake tests (only from worker->cookerdata) so this part (srvrev cache) works differently in tests and in builds (that's how I found this variable - test was working while it should fail)
<RP>
landgraf: we should call that in any tests if/as/needed
GNUmoon has quit [Remote host closed the connection]
GNUmoon has joined #yocto
Nathan20 has quit [Quit: Connection closed]
zpfvo has quit [Ping timeout: 256 seconds]
zpfvo has joined #yocto
<LetoThe2nd>
how are site.conf and auto.conf actually meant to be used? what is the rationale behind those?
zpfvo has quit [Ping timeout: 250 seconds]
<rburton>
site is meant for 'site wide' settings
zpfvo has joined #yocto
<rburton>
auto is meant for auto-generated settings
<rburton>
as they're looked for across all layers you can do nice things like put a site.conf in a layer which all your builds use, to set up stuff like a central DL_DIR
<LetoThe2nd>
rburton: "site-wide" means: the build host? like dropping it in /etc?
<rburton>
no, its got to be in the standard search path for config files
<Saur[m]>
We have a global site.conf where we only configure things that that do not directly affect the produced artifacts, e.g., proxy settings, premirror, etc.
<rburton>
you could have an meta-company layer which has a site.conf for proxies, caches, mirrors etc.
<LetoThe2nd>
rburton: ah okay. that makes sense, re site.conf. but auto.conf? this sounds a lot like local.conf, but in a different shape then.
<rburton>
auto.conf is so you can have tools which automatically write config files but don't trample on existing local.conf
<LetoThe2nd>
hmkay.
<RP>
the autobuilder places auto.conf happy in the knowledge it doesn't need to worry about local.conf
<LetoThe2nd>
but local.conf takes precedence, I presume?
<RP>
abelloni: it is lovely having swatbot mostly clear :)
zpfvo has quit [Ping timeout: 256 seconds]
zpfvo has joined #yocto
lucaceresoli_ has joined #yocto
zpfvo has quit [Ping timeout: 252 seconds]
zpfvo has joined #yocto
<Saur[m]>
LetoThe2nd: auto.conf is read just before local.conf, but as usual with bitbake variables, it all depends on how you manipulate them.
<LetoThe2nd>
Saur[m]: kay thanks
<Saur[m]>
You can see the order the configuration files are read if you run `bitbake -e | less` and search for, e.g., local.conf.
lucaceresoli_ has quit [Ping timeout: 256 seconds]
zpfvo has quit [Ping timeout: 256 seconds]
zpfvo has joined #yocto
vladest has quit [Remote host closed the connection]
<RP>
landgraf: I've replied, thanks. I like the idea of creating some test cases but I'm not sure those ones are quite right
prabhakarlad has quit [Quit: Client closed]
zpfvo has quit [Ping timeout: 250 seconds]
zpfvo has joined #yocto
prabhakarlad has joined #yocto
<agherzan>
RP: 14484 is hard to reproduce. And it is really strange to begin with. All `package_write` tasks run under `fakeroot`. While deb and ipk create DEBIAN and CONTROL repectively, rpm just ignores them in a walk loop. And the pseudo error seems to happen in rpm. This smells to me as a race between ipk and deb? I'm yet to understand the relevant pseudo code and the logs are not very helpful at this point.
zpfvo has quit [Ping timeout: 240 seconds]
<RP>
agherzan: whilst rpm ignores them, the file accesses themselves probably make pseudo aware of them
zpfvo has joined #yocto
<RP>
agherzan: it is as if the deletion in one thread has happened and the inode reused but the old inode is still in the pseudo database
<RP>
agherzan: the reason the bug worries me is that if that is true we have a wider race issue
<agherzan>
That could only happen if a delete happened outside of pseudo right?
<landgraf>
RP: replied. there was a mistake in the test indeed. However it was not affecting the results (because first "flow" was correct one download() -> init() and cache problem doesn't affect it) long story short the test case would be as simple as: "BB_SRCREV_POLICY" = "clean" BB_NO_NETWORK="1" fetcher = Fetcher(...)
<ad__>
gm, i have a "The recipe imx-boot is trying to install files into a shared area when those files already exist. How can i verify who is installing such files ?
<LetoThe2nd>
agherzan: I think we've seen problems where hardlinks were involved too.
<agherzan>
LetoThe2nd: Could be related but in this situation it is not the case.
<landgraf>
RP: Sorry, fetcher_init() missed. setVar(BB_NO_NETWORK, "1"); fetcher_init(); fetcher = Fetcher() - this will fail because it will try to call ls-remote
<RP>
landgraf: the fetcher *can* access the network once in do_fetch, the issue is that it shouldn't do it again in do_unpack
<landgraf>
RP: right. the problem is when fetch() was not called.
<landgraf>
so Fetcher() object is not initialized with network
<RP>
landgraf: but fetch would usually be called right?
<landgraf>
RP: Doesn't this patch change default BB_SRCREV_POLICY effectively ?
<landgraf>
RP: because it was my first question today :)
<RP>
landgraf: no since it will run in the server process
<RP>
we're just stopping the worker processes from wiping the cache
<kayterina[m]>
hello, where can I read more about how devtool undeploy-target works? Does it keep the previous files in the target machine and restores them?
<RP>
kayterina[m]: your best bet to answer that may be the code if the manuals don't say
<landgraf>
RP: I see. I though it wipes the cache on purpose.
* landgraf
didn't have full picture :(
<agherzan>
RP: the only reasonable explanation at this point is that it is an issue in pseudo. The deb/ipk handle the package lock correctly so under the lock they both create and remove the control directory(s). So it has to be an issue while one of the cases when creating and removing the directory while pseudo db retains the entry.
<agherzan>
while = with
<RP>
agherzan: that is what worried me :/
<RP>
agherzan: is it possible that the removal is happening out of pseudo's view somehow?
<agherzan>
That would be my only lead at this point.
<agherzan>
Somehow, and landgraf was suspecting rpm, is removing stuff and we do that out of pseudo/fakeroot
<agherzan>
But again, the rpm side also runs under pseudo... This is an ugly fish to catch.
<RP>
agherzan: I just had a quick look at the code and I don't have anything useful to add. The files are added/deleted and should just be ignored by rpm :/
<RP>
agherzan: need to grab food but I'll think about it
<agherzan>
RP: Get me something too please. :)
<RP>
agherzan: I do worry it is a pseudo race :(
<agherzan>
Me too
<landgraf>
RP: would you mind submitting your fix? Looks like it solves the issue and even more it answers all questions and concerns I had :)
<landgraf>
and fixes the bug
<agherzan>
RP: I just have to understand the psudo code better to understand the possible paths.
ad__ has joined #yocto
ad__ has quit [Changing host]
Tokamak has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<RP>
at least that points to make version rather than kernel. I wondered about libc or not...
<kanavin>
RP: we can try to collect more data points I suppose
<RP>
kanavin: Some of the upstream changes after 4.2.1 looked interesting from what I remember too
<kanavin>
RP: there's also that once-in-a-blue-moon perl fail too, which could well be a make bug, since no one could figure out anything possibly wrong with the makefiles themselves
<RP>
kanavin: I think that may have one?
<RP>
the hang was odd as it never generated a swatbot failure to trigger triage
<kanavin>
RP: I mean, not in this run - in general
<kanavin>
it hasn't happened lately
<kanavin>
maybe after coreutils in rust are ready, the rust ppl will embark on rewriting make in rust ;)
<RP>
kanavin: just don't think that! :)
ilunev has joined #yocto
Tokamak has joined #yocto
klockwood has quit [Ping timeout: 245 seconds]
klockwood has joined #yocto
<sgw>
RP: Doing SWAT, seems like there are lots of networking issues, including the last 2 maybe
alimon has quit [Remote host closed the connection]
<RP>
sgw: that matches my understanding. I did triage a load of known issues from the weekend
<sgw>
Thanks, I was not around to triage, looking at them now.
lucaceresoli_ has quit [Ping timeout: 250 seconds]
rfuentess has quit [Remote host closed the connection]
Chaser has joined #yocto
klockwood has quit [Ping timeout: 240 seconds]
florian_kc has joined #yocto
florian_kc has quit [Ping timeout: 240 seconds]
ex-bugsbunny has joined #yocto
florian_kc has joined #yocto
Alternate_Pacifi has joined #yocto
<vd>
Can an IMAGE_CMD mount the image file to do extra work on it?
moto_timo[m] has quit [*.net *.split]
hmw[m] has quit [*.net *.split]
ericson2314 has quit [*.net *.split]
Dhruvag2000[m] has quit [*.net *.split]
beneth has quit [*.net *.split]
The_Pacifist has quit [*.net *.split]
fray has quit [*.net *.split]
Saur has quit [*.net *.split]
landgraf has quit [*.net *.split]
yocton has quit [*.net *.split]
florian_kc has quit [Ping timeout: 250 seconds]
kevinrowland has joined #yocto
moto_timo[m] has joined #yocto
beneth has joined #yocto
hmw[m] has joined #yocto
<kevinrowland>
What are everyone's thoughts on using the wildcard (%) character in BBAPPEND filenames, vs. using the PV of the recipe to which you're appending? Should I just use PV unless I have a BBAPPEND that applies to multiple different versions?
ericson2314 has joined #yocto
Dhruvag2000[m] has joined #yocto
landgraf has joined #yocto
yocton has joined #yocto
Saur has joined #yocto
<JaMa>
kevinrowland: depends on each case, if it's likely version-agnostic (like extra PACKAGECONFIG enabled for your distro) then I use % so that I don't need to rename bbappend everytime the recipe filename is changed, if it's something I'm going to send upstream (and likely to be temporary) I use PV to make sure to revisit the need of that .bbappend at least next time the version is updated in upstream
<JaMa>
similarly when it has some extra .patch files which might need re-review for each version
fray has joined #yocto
krowlan3[m] has quit [Ping timeout: 240 seconds]
jwillikers[m] has quit [Ping timeout: 240 seconds]
Perceval[m] has quit [Ping timeout: 245 seconds]
asconcepcion[m] has quit [Ping timeout: 250 seconds]
berton[m] has quit [Ping timeout: 250 seconds]
NishanthMenon[m4 has quit [Ping timeout: 240 seconds]
jqua[m] has quit [Ping timeout: 240 seconds]
fabatera[m] has quit [Ping timeout: 240 seconds]
agherzan has quit [Ping timeout: 240 seconds]
T_UNIX[m] has quit [Ping timeout: 240 seconds]
Portia[m] has quit [Ping timeout: 240 seconds]
cperon has quit [Ping timeout: 240 seconds]
leonanavi has joined #yocto
falk0n[m] has quit [Ping timeout: 250 seconds]
Emantor[m] has quit [Ping timeout: 250 seconds]
glembo[m] has quit [Ping timeout: 250 seconds]
blauskaerm[m] has quit [Ping timeout: 250 seconds]
Spectrejan[m] has quit [Ping timeout: 250 seconds]
ejoerns[m] has quit [Ping timeout: 250 seconds]
zyga[m] has quit [Ping timeout: 240 seconds]
barath has quit [Ping timeout: 240 seconds]
Saur[m] has quit [Ping timeout: 240 seconds]
doquiros[m] has quit [Ping timeout: 256 seconds]
zagor has quit [Ping timeout: 256 seconds]
rgov[m] has quit [Ping timeout: 256 seconds]
jordemort has quit [Ping timeout: 256 seconds]
lexano[m] has quit [Ping timeout: 256 seconds]
booboo1212[m] has quit [Ping timeout: 256 seconds]
alvaropg[m] has quit [Ping timeout: 252 seconds]
grembeter[m] has quit [Ping timeout: 252 seconds]
dwagenk has quit [Ping timeout: 252 seconds]
coldspark29[m] has quit [Ping timeout: 250 seconds]
Dhruvag2000[m] has quit [Ping timeout: 260 seconds]
khem has quit [Ping timeout: 268 seconds]
FredericOuellet[ has quit [Ping timeout: 268 seconds]
jonesv[m] has quit [Ping timeout: 268 seconds]
suy|m has quit [Ping timeout: 268 seconds]
expert[m] has quit [Ping timeout: 268 seconds]
PascalBach[m] has quit [Ping timeout: 268 seconds]
kayterina[m] has quit [Ping timeout: 268 seconds]
Alistair[m] has quit [Ping timeout: 268 seconds]
Tartarus has quit [Ping timeout: 268 seconds]
thierryE[m] has quit [Ping timeout: 268 seconds]
<kevinrowland>
JaMa: makes sense, thanks. I'll probably need to revisit when the upstream version changes, so I'll stick with PV
leon-anavi has quit [Ping timeout: 256 seconds]
ericson2314 has quit [Ping timeout: 260 seconds]
hmw[m] has quit [Ping timeout: 260 seconds]
moto_timo[m] has quit [Ping timeout: 260 seconds]
leon-anavi has joined #yocto
shoragan[m] has quit [Ping timeout: 268 seconds]
leonanavi has quit [Ping timeout: 256 seconds]
goliath has quit [Quit: SIGSEGV]
leon-anavi has quit [Remote host closed the connection]
leon-anavi has joined #yocto
ex-bugsbunny has quit [Ping timeout: 250 seconds]
florian_kc has joined #yocto
PascalBach[m] has joined #yocto
amitk has quit [Ping timeout: 240 seconds]
Spectrejan[m] has joined #yocto
kayterina[m] has joined #yocto
rob_w has quit [Quit: Leaving]
leonanavi has joined #yocto
<abelloni>
RP: yes, sgw is on duty ;)
leon-anavi has quit [Ping timeout: 250 seconds]
krowlan3[m] has joined #yocto
jwillikers[m] has joined #yocto
expert[m] has joined #yocto
asconcepcion[m] has joined #yocto
thierryE[m] has joined #yocto
jonesv[m] has joined #yocto
coldspark29[m] has joined #yocto
jqua[m] has joined #yocto
cperon has joined #yocto
Perceval[m] has joined #yocto
fabatera[m] has joined #yocto
rgov[m] has joined #yocto
falk0n[m] has joined #yocto
glembo[m] has joined #yocto
Portia[m] has joined #yocto
ex-bugsbunny has joined #yocto
camus has quit [Ping timeout: 252 seconds]
camus has joined #yocto
leon-anavi has joined #yocto
kevinrowland has quit [Quit: Client closed]
leonanavi has quit [Ping timeout: 240 seconds]
florian_kc has quit [Ping timeout: 240 seconds]
blauskaerm[m] has joined #yocto
Dhruvag2000[m] has joined #yocto
ex-bugsbunny has quit [Remote host closed the connection]
ericson2314 has joined #yocto
hmw[m] has joined #yocto
leon-anavi has quit [Read error: Connection reset by peer]
mvlad has quit [Remote host closed the connection]
T_UNIX[m] has joined #yocto
khem has joined #yocto
Tartarus has joined #yocto
suy|m has joined #yocto
barath has joined #yocto
alvaropg[m] has joined #yocto
FredericOuellet[ has joined #yocto
Tokamak has joined #yocto
Tokamak has quit [Client Quit]
Wouter0100 has quit [Read error: Connection reset by peer]
Wouter0100 has joined #yocto
<sgw>
RP: abelloni: I am trying at least!
dwagenk has joined #yocto
Emantor[m] has joined #yocto
ejoerns[m] has joined #yocto
Circuitsoft has joined #yocto
<Circuitsoft>
Hi, some weirdness: `File: 'a_file_in_a_bbappend' has sha256 checksum 7b025933beedf46928a066ddbdcd8a91bfb155773b88d77e60037e29e172f738 when 7b025933beedf46928a066ddbdcd8a91bfb155773b88d77e60037e29e172f738 was expected`
<Circuitsoft>
Any clue what this could be?
dwagenk has quit [Read error: Connection reset by peer]
suy|m has quit [Read error: Connection reset by peer]
Tartarus has quit [Read error: Connection reset by peer]
FredericOuellet[ has quit [Read error: Connection reset by peer]
barath has quit [Read error: Connection reset by peer]
khem has quit [Read error: Connection reset by peer]
zyga[m] has quit [Write error: Connection reset by peer]
T_UNIX[m] has quit [Read error: Connection reset by peer]
NishanthMenon[m4 has quit [Write error: Connection reset by peer]
alvaropg[m] has quit [Read error: Connection reset by peer]
ejoerns[m] has quit [Read error: Connection reset by peer]
Emantor[m] has quit [Read error: Connection reset by peer]
Spectrejan[m] has quit [Read error: Connection reset by peer]
lexano[m] has quit [Read error: Connection reset by peer]
moto_timo[m] has quit [Read error: Connection reset by peer]
falk0n[m] has quit [Read error: Connection reset by peer]
krowlan3[m] has quit [Read error: Connection reset by peer]
shoragan[m] has quit [Write error: Connection reset by peer]
jordemort has quit [Write error: Connection reset by peer]
PascalBach[m] has quit [Read error: Connection reset by peer]
Alistair[m] has quit [Write error: Connection reset by peer]
thierryE[m] has quit [Write error: Connection reset by peer]
berton[m] has quit [Read error: Connection reset by peer]
glembo[m] has quit [Read error: Connection reset by peer]
ericson2314 has quit [Read error: Connection reset by peer]
agherzan has quit [Write error: Connection reset by peer]
hmw[m] has quit [Write error: Connection reset by peer]
blauskaerm[m] has quit [Read error: Connection reset by peer]
fabatera[m] has quit [Read error: Connection reset by peer]
rgov[m] has quit [Read error: Connection reset by peer]
Perceval[m] has quit [Write error: Connection reset by peer]
jonesv[m] has quit [Read error: Connection reset by peer]
jwillikers[m] has quit [Read error: Connection reset by peer]
kayterina[m] has quit [Read error: Connection reset by peer]
cperon has quit [Read error: Connection reset by peer]
jqua[m] has quit [Write error: Connection reset by peer]
Portia[m] has quit [Read error: Connection reset by peer]
asconcepcion[m] has quit [Read error: Connection reset by peer]
Dhruvag2000[m] has quit [Write error: Connection reset by peer]
coldspark29[m] has quit [Write error: Connection reset by peer]
expert[m] has quit [Read error: Connection reset by peer]
Spectrejan[m] has joined #yocto
jordemort has joined #yocto
florian_kc has quit [Ping timeout: 240 seconds]
<kergoth>
Circuitsoft: looks like you have a leading space
Emantor[m] has joined #yocto
kayterina[m] has joined #yocto
NishanthMenon[m] has joined #yocto
lexano[m] has joined #yocto
shoragan[m] has joined #yocto
khem has joined #yocto
ejoerns[m] has joined #yocto
Portia[m] has joined #yocto
moto_timo[m] has joined #yocto
dwagenk has joined #yocto
jonesv[m] has joined #yocto
Alistair[m] has joined #yocto
ZygmuntKrynicki[ has joined #yocto
PascalBach[m] has joined #yocto
zagor has joined #yocto
coldspark29[m] has joined #yocto
barath has joined #yocto
jwillikers[m] has joined #yocto
blauskaerm[m] has joined #yocto
glembo[m] has joined #yocto
hmw[m] has joined #yocto
FredericOuellet[ has joined #yocto
suy|m has joined #yocto
ericson2314 has joined #yocto
berton[m] has joined #yocto
<Circuitsoft>
Ah. Yup. What confused me was `SRC_URI += "my_url"` and `SRC_URI[sha256sum] = "sha256"` <- Note, no `+=` here. `+=` here made it fail.
expert[m] has joined #yocto
Tartarus has joined #yocto
Perceval[m] has joined #yocto
alvaropg[m] has joined #yocto
booboo1212[m] has joined #yocto
cperon has joined #yocto
jqua[m] has joined #yocto
thierryE[m] has joined #yocto
falk0n[m] has joined #yocto
T_UNIX[m] has joined #yocto
Dhruvag2000[m] has joined #yocto
doquiros[m] has joined #yocto
Saur[m] has joined #yocto
rgov[m] has joined #yocto
asconcepcion[m] has joined #yocto
grembeter[m] has joined #yocto
fabatera[m] has joined #yocto
krowlan3[m] has joined #yocto
agherzan has joined #yocto
<Circuitsoft>
What sets the order of a quilt `series` file?