<snapsd>
Hello all, I have set SOURCE_MIRROR_URL pointing to my local server + appended few PREMIRRORS for source download
<snapsd>
now, when fetcher runs, it finds the tar ball on SOURCE_MIRROR_URL, but still try to translate that URL with PREMIRROR...
<snapsd>
is it possible, if fetcher finds tarball on SOURCE_MIRROR_URL, it uses that only and if not, than only move to other PREMIRRORS....
<snapsd>
I know, with own-mirrors, source mirror url is PREMIRROR only.. but still
amitk has joined #yocto
sakoman has quit [Quit: Leaving.]
goliath has quit [Quit: SIGSEGV]
<snapsd>
anyone? any idea
camus has quit [Ping timeout: 240 seconds]
camus has joined #yocto
tlwoerner has quit [Ping timeout: 240 seconds]
tlwoerner has joined #yocto
tlwoerner has quit [Ping timeout: 268 seconds]
alicef has quit [Quit: install gentoo]
alicef has joined #yocto
tlwoerner has joined #yocto
GNUmoon has quit [Ping timeout: 276 seconds]
goliath has joined #yocto
alessioigor has joined #yocto
alessioigor has quit [Client Quit]
GNUmoon has joined #yocto
Wouter0100 has quit [Read error: Connection reset by peer]
Wouter0100 has joined #yocto
olani has quit [Ping timeout: 256 seconds]
olani has joined #yocto
dushara has quit [Quit: Leaving]
frieder has joined #yocto
zpfvo has joined #yocto
rfuentess has joined #yocto
<ziga_>
How cann I tell which .dts files a kernel recipe used to create .dtb that is used in hte end? I am asking because there are plenty of .dts files and I don't know which one to patch.
<ziga_>
And one more thing... Do I have to download a kernel repository and use that one in order to do ANY KIND of patching to the device tree?
kroon has joined #yocto
gsalazar has joined #yocto
dev1990 has joined #yocto
mckoan|away is now known as mckoan
<mckoan>
ziga_: look at the kernel recipe
zpfvo has quit [Ping timeout: 268 seconds]
zpfvo has joined #yocto
vladest has quit [Quit: vladest]
vladest has joined #yocto
dev1990 has quit [Quit: Konversation terminated!]
leon-anavi has joined #yocto
kroon has quit [Ping timeout: 256 seconds]
kroon has joined #yocto
olani has quit [Remote host closed the connection]
<ziga_>
c) somehow... I don't understand this one.
zpfvo has quit [Ping timeout: 268 seconds]
zpfvo has joined #yocto
zpfvo has quit [Ping timeout: 240 seconds]
zpfvo has joined #yocto
gsalazar_ has joined #yocto
zpfvo has quit [Ping timeout: 256 seconds]
zpfvo has joined #yocto
gsalazar has quit [Ping timeout: 256 seconds]
zpfvo has quit [Ping timeout: 256 seconds]
zpfvo has joined #yocto
gsalazar_ has quit [Quit: Leaving]
gsalazar has joined #yocto
leonanavi has joined #yocto
leon-anavi has quit [Ping timeout: 256 seconds]
xmn has quit [Ping timeout: 268 seconds]
olani has quit [Remote host closed the connection]
snapsd has quit [Ping timeout: 250 seconds]
olani has joined #yocto
zyga-mbp has joined #yocto
osama has joined #yocto
mvlad has joined #yocto
zpfvo has quit [Ping timeout: 240 seconds]
tnovotny has joined #yocto
zpfvo has joined #yocto
jmiehe has quit [Quit: jmiehe]
zpfvo has quit [Ping timeout: 240 seconds]
zpfvo has joined #yocto
florian has joined #yocto
camus has quit [Ping timeout: 240 seconds]
camus has joined #yocto
osama has quit [Ping timeout: 256 seconds]
zpfvo has quit [Ping timeout: 240 seconds]
zpfvo has joined #yocto
zpfvo has quit [Ping timeout: 240 seconds]
zpfvo has joined #yocto
zpfvo has quit [Ping timeout: 240 seconds]
zpfvo has joined #yocto
zpfvo has quit [Ping timeout: 268 seconds]
zpfvo has joined #yocto
<RP>
kanavin: we're going to wait on michael to look at debian9 I guess? It does seem to be very slow and we both have hung builds now :/
<kanavin>
RP: yes, it does seem as if the CPU cores are 5x slower than they should be
<kanavin>
I was watching your repro build via ssh - it's progressing but at a snail pace
<kanavin>
not hung exactly
zpfvo has quit [Ping timeout: 268 seconds]
zpfvo has joined #yocto
<kanavin>
RP: in other news, I just sent the upgrade rollup
zpfvo has quit [Ping timeout: 240 seconds]
zpfvo has joined #yocto
<RP>
kanavin: I just triggered the M2 build so I guess this is going in after that :)
<kanavin>
RP: perfect timing ;)
Schlumpf has joined #yocto
<RP>
kanavin: interesting use of mcextend
<RP>
kanavin: a little worrying as it isn't a real mc and I worry what happens if we add a real mc into the mix
<RP>
kanavin: I like the idea, I just worry we can't use mcextend like this
<kanavin>
RP: this comes from me working on a proof of concept for cross compiling a cross compiler for the target - I used the mcextend extensively there to avoid duplicating .bb files
<kanavin>
e.g. add a mcextend variant, and tweak TARGET_SYS in it
huseyinkozan has joined #yocto
<kanavin>
adding recipe variants like this for common configurations is very handy, devupstream is another example
camus has quit [Ping timeout: 268 seconds]
camus has joined #yocto
<RP>
kanavin: right, but using the mcextend namespace like that means it would no longer work for real multiconfig work
<RP>
kanavin: we need something which would stack for the multiconfig case correctly
<kanavin>
RP: I see, can you describe a test case where things would break?
<kanavin>
maybe on the mailing list so that it's preserved and visible
<RP>
kanavin: I'd be curious if the multiconfig tests in oe-selftest work with larger images that include mesa after your change
<RP>
kanavin: the multiconfig tests don't use large images due to time/resource usage constraints
<kanavin>
RP: I can try that
<kayterina[m]>
hello. How can I keep my previous built when I use devtool modify <component>, make changes to the code and devtool deploy <component>? I want to devtool-deploy between two builds without rebuilding
<RP>
kanavin: I'd need to spend more time on a specific test case/reproducer and I may be worrying about nothing but I think it does need to be checked. We may need a different version of the class for non-mc use
d0ku has joined #yocto
<kanavin>
RP: I can try the multiconfig tests meanwhile
zpfvo has quit [Ping timeout: 268 seconds]
zpfvo has joined #yocto
<RP>
kanavin: please, that would be where I'd start
zpfvo has quit [Ping timeout: 240 seconds]
zpfvo has joined #yocto
<RP>
Why do we find networking failures in a release build :(
<RP>
Not sure it is a network issue. It is always rust-native and cargo-native
<coldspark29[m]>
I don't see anything odd about it. Everything seems okay with the file name. Here is the full error
<coldspark29[m]>
It complains about too many values. Maybe lgpl-3.0 exists twice?
rob_w has joined #yocto
manuel1985 has joined #yocto
<RP>
madisox: which crate fetcher issue?
kroon_ has joined #yocto
kroon has quit [Ping timeout: 268 seconds]
<madisox>
RP: the one I sent patches for - crate-fetch.bbclass sets SRCPV to import the crate fetcher, but that fetcher doesn't support srcrevs, and that causes a silent failure (bb throwing an exception) during pstaging_fetch for any sstate package that needs to be fetched from the sstate mirror
<RP>
madisox: oh, right, yes. I really should remember that :/
<RP>
and it only hits our release builds as we change config to populate a new sstate directory
<RP>
and only early builds as later it is populated
<RP>
madisox: I've been hoping we could sort the test cases and get that fetcher merged
alejandrohs has quit [Ping timeout: 256 seconds]
<rburton>
moto-timo: py-crypto-native doesn't work
<RP>
abelloni: some useful insight into the rust/cargo sstate warnings ^^^
<madisox>
RP: I haven't volunteered to do the bitbake integration because I don't know rust well enough to put together those test cases, sorry
<RP>
madisox: right, neither do I really :(
Skinny79 has joined #yocto
doquiros[m] has joined #yocto
_whitelogger has joined #yocto
tgamblin_ has quit [Client Quit]
Starfoxxes has joined #yocto
nerdboy has joined #yocto
nerdboy has quit [Changing host]
nerdboy has joined #yocto
Habbie has joined #yocto
tgamblin has joined #yocto
zpfvo has quit [Ping timeout: 268 seconds]
mcfrisk has quit [Ping timeout: 256 seconds]
rfs613- has quit [Ping timeout: 256 seconds]
rfs613 has joined #yocto
mcfrisk has joined #yocto
zpfvo has joined #yocto
camus1 has joined #yocto
camus has quit [Ping timeout: 256 seconds]
camus1 is now known as camus
<smurray>
fray: when you're around, could you elaborate on the qtbase failures you mentioned last week? Someone else building AGL is seeing failures there that I don't see
zpfvo has quit [Ping timeout: 256 seconds]
zpfvo has joined #yocto
zpfvo has quit [Ping timeout: 256 seconds]
zpfvo has joined #yocto
beneth has joined #yocto
<RP>
rburton: did you ever work out that sstate failure improvement patch?
<RP>
rburton: I've sent a blind attempt at improving it
<coldspark29[m]>
I am confused about linux-fscl-imx. If you look at the recipe, you see that linux-fscl and linux-imx are required. I added all our custom patches to the lf-5.10.y branch of linux-imx, but it seems that linux-fslc is built
<smurray>
coldspark29[m]: at least on master, linux-fslc-imx looks like uses a branch in linux-fslc.git? (based on KBRANCH = "5.10-2.1.x-imx")
<moto-timo>
rburton: did you get any further with py-native host ssl contamination theory?
<coldspark29[m]>
smurray: Yes, but it includes linux-fslc.inc, which includes linux-imx.inc. So I thought I would need to patch linux-imx as before on gatesgarth
<smurray>
coldspark29[m]: it's what SRC_URI points at that matters, and linux-fslc.inc sets it to linux-fslc.git
<smurray>
coldspark29[m]: that plus the KBRANCH set what gets used
florian_kc has joined #yocto
<coldspark29[m]>
smurray: Yeah and in linux-imx.inc the SRC_URI points to the NXP kernel. I assume since the linux-imx.inc is included at the top, its SRC_URI is overwritten by the linux-fslc one?
<coldspark29[m]>
I think I need to learn something about inheritance in Yocto
<smurray>
coldspark29[m]: yes. When in doubt check variable values in the 'bitbake -e <recipe>' output or with the newer bitbake-getVar tool
<coldspark29[m]>
So why is it including linux-imx? Is it just getting the patches from there?
sakoman has joined #yocto
codavi has joined #yocto
<coldspark29[m]>
Well, I guess this is a good opportunity to learn about all of that :D
<coldspark29[m]>
How security patches are applied if they are not in the mainline or NPX branch
jmiehe has joined #yocto
<smurray>
coldspark29[m]: by the maintainer or by an enduser like yourself?
<coldspark29[m]>
By the maintainer
<coldspark29[m]>
This kernel seems to be patched together from different sources. It is a bit complex, but a good learning opportunity
<coldspark29[m]>
In Gatesgarth or Hardknott there was just linux-imx or linux-fslc
<coldspark29[m]>
This is like a fused kernel
<smurray>
coldspark29[m]: I assume he has some scripting to manage it
<smurray>
coldspark29[m]: if you have questions about how Andrey puts those kernels together, perhaps email him or post to the meta-freescale mailing list
codavi has quit [Ping timeout: 250 seconds]
kroon_ has quit [Remote host closed the connection]
kroon has joined #yocto
<RP>
madisox: I've pushed something to master-next to try and resolve this
<RP>
some really basic tests
<qschulz>
Skinny79: you're missing `inherit systemd` I think
kroon_ has joined #yocto
vladest has quit [Remote host closed the connection]
vladest has joined #yocto
zpfvo has quit [Ping timeout: 240 seconds]
zpfvo has joined #yocto
kroon has quit [Ping timeout: 250 seconds]
<Perceval[m]>
Hello all :)
<Perceval[m]>
Has anyone experienced a significant gap in runtime performance between nvidia Jetpack stock OS and the meta-tegra OS on Jetson TX2 board?
<Perceval[m]>
My camera gige software (IDS ueye) has no issue with the basic install and no tweaking on the jetpack stock OS but when I run it on the meta-tegra based OS the software starts dropping frames.
<Perceval[m]>
We profiled the app on the jetpack OS using Nsight Systems (I really recommend this tool if you are having performance issues. It's really well integrated.) Cleaned up the software. Our software was working perfectly on the jetpack even while profiling.
<Perceval[m]>
When we deployed the software on the meta-tegra based OS there was almost no difference between (10% improvement I would say) before and after all the performance improvements
<Perceval[m]>
If someone has any idea that could help us ! That would be awesome ! :)
florian_kc has quit [Ping timeout: 256 seconds]
zpfvo has quit [Ping timeout: 256 seconds]
<Skinny79>
qschulz ohmy.. reading and mixing all kind of blogs posts is not helping in this case.. that was it, thanks!
xmn has joined #yocto
zpfvo has joined #yocto
jatedev has quit [Quit: Client closed]
rob_w has quit [Remote host closed the connection]
jatedev has joined #yocto
<rburton>
moto-timo: i tried adding -Bsymbolic-functions to openssl-native but that didnt appear to work
<moto-timo>
rburton: also a report about sdk broken... but that smells like a rust sdk issue
Schlumpf has quit [Quit: Client closed]
<vd>
I create multiple psplash-{foo,bar} alternatives but the build system still complain about them even though I set PREFERRED_PROVIDER_psplash = "psplash-foo". Isn't it the correct way to do it?
<qschulz>
vd: "complains about them" ?
<vd>
qschulz: yes a warning stating that there are multiple alternatives for the psplash package
amitk has quit [Ping timeout: 240 seconds]
<RP>
vd: your alternatives are overlapping somehow and bitbake isn't happy about it or both aren't providing everything they need to
jmiehe has quit [Quit: jmiehe]
<vd>
RP: in a psplash_git.bbappend I'm simply adding a few SPLASH_IMAGES += "file://psplash-foo-img.h;outsuffix=foo". My distro then sets PREFERRED_PROVIDER_psplash = "psplash-bar". Isn't it the correct way to do it?
kroon_ has quit [Quit: Leaving]
<rburton>
where is psplash-bar defined?
<vd>
rburton: same as for psplash-foo with s/foo/bar/ obviously
<vd>
(psplash-foo, psplash-bar are just example names of psplashes I have)
<RP>
vd: what are "psplash-foo" and "psplash-bar" though? You've changed the PN for the recipe?
<vd>
RP: isn't it how you're supposed to add custom splash screens? I might be wrong. I looked at a few examples and they seem to do the same, then setting SPLASH = "psplash-bar" in an image recipe
<vd>
I understood that the psplash recipe was somehow dynamically adding alternatives to the main psplash package
<vd>
Should the distro set a default SPLASH ?= "psplash-foo" instead of PREFERRED_PROVIDER_psplash?
<RP>
vd: I had to look at what the recipe is doing as the information above is very confusing. The psplash recipe adds multiple PACKAGES
<RP>
vd: you do not select things in the PACKAGES/runtime namespace with PREFERRED_PROVIDER which is the PN namespace
<RP>
vd: so yes, changing SPLASH would be more appropriate
d0ku has quit [Ping timeout: 268 seconds]
<vd>
RP: sorry about the confusion, but to be fair this package is quite confusing itself.
<vd>
But I understand it's just doing dynamically what you could do with PACKAGES = "${PN}-foo ${PN}-bar", thank you.
<RP>
vd: writing up an example of using it for the manual would be great now you understand it! ;-)
<vd>
RP: sure. What's the best place for it?
<RP>
vd: not sure, probably a new section in the development tasks going from memory?
<vd>
RP: btw do you think you could consider replying to the patches on the mailing list, so that a contributor knows if the bad has been applied or not?
<vd>
RP: I've sent two patches for beaglebone-yocto a few days ago without follow-up
<vd>
s/bad/patch/ (I don't know how that came out)
<vd>
Instead of quietly applying the patch I mean.
<RP>
vd: you're asking me to send an extra 4000 emails a year?
<vd>
RP: didn't you do it for the kernel?
<rburton>
RP: i'm sure jonmason will be quick to point out that if you use lore/b4/etc, it can send those for you
<RP>
rburton: in that case someone else can just script it and make it work as it is so easy to do
amitk has joined #yocto
<rburton>
yeah, i know you have a pile of local scripting to manage patches-on-list
<RP>
rburton: I do have an email from jon to look at some details on that stuff
<vd>
I rarely saw a kernel patch applied with a reply, yet I bet these "Applied, thanks." messages are automatic.
<RP>
but people really don't want an extra 4000 emails on list and the email they really want is why their patch is being ignored, not that it merged
<vd>
that's not really the problem here...
<RP>
vd: ok, so what is the problem?
<vd>
First problem is that the yocto MLs are quite annoying with their digest configs and footer. Then replying to an email for notifying that the patch is applied is part of a thread, that won't bother anyone
<RP>
The reason I get a little "touchy" on this subject is that basically people want me to do a ton of extra work. I don't know where this time comes from.
<RP>
vd: I can tell you they would bother me as I don't use digests
<RP>
I know they will annoy others too, we've discussed this before
<qschulz>
RP: I remember there was some discussion about fixing a patchwork instance somewhere?
<fray>
Or, you can just watch master-next... that's what I do
<vd>
RP: So you're basically saying that you don't want to notify when a patch is applied, because it will bother a few people?
<RP>
qschulz: still in progress and I'm getting very annoyed/frustrated about how long it is taking
<smurray>
fray: those intermittent qtbase errors you mentioned last week, do you recall if they were from linking?
<jonmason>
honestly, b4 and lei are your friends
<RP>
vd: I don't want to do it as it is a fair chunk of work. Even automation isn't as easy/good as anyone thinks it is. If it were, patchwork would be easy too
<fray>
smurray: linking and referencing a file, but I forget what file
<rburton>
assuming your patches are in local branches, rebase onto latest master. when the branch disappears, they were merged.
<jonmason>
It won't take an hour, and you can use any email reader you want
<jonmason>
and if your keys get triggered, it'll add the whole thread to your inbox
Tokamak has joined #yocto
<fray>
smurray: we ended up doing a bbappend to qtbase, setting PARALLEL_MAKEINST = "-j 1" and then replacing EXTRA_OEMAKE:task-install = "...." using PARALLEL_MAKEINST instead of PARALLE_MAKE
<smurray>
fray: the log I've been given has a lot of "DWARF error: could not find variable specification at offset X" errors
<jonmason>
and you can add more at any time. For example, I started tracking the stuff in tunes now just by adding a single line
<RP>
You know I'm actually really close to just walking away from this all. If its all so damn easy, someone else can just step up and do it all.
<jonmason>
lmao
<jonmason>
RP: I'm just trying to help
* zeddii
has the same feeling about things as RP :)
<smurray>
fray: I'm hesitant to offer that as a solution as the person with the issue is building on a developer laptop ;)
<jonmason>
ok, if I can get zeddii to convert, would that work for everyone that it is trivial to learn?
<fray>
In reality it's far easier to have people actually monitor the work.. i.e. go to git.yoctoproject.org (or openembedded) and look at master-next..
<fray>
that is 100% how I watch if my patches have been accepted or the status.. takes me seconds to do it
<vd>
smurray: who's that?
<fray>
we get it on our container build systems
<smurray>
fray: someone attempting to build AGL
<RP>
jonmason: I have your email about b4/lei in my inbox marked as important and need to look at properly
<smurray>
vd: someone attempting to build AGL
<RP>
I just don't get the time :(
<jonmason>
`b4 ty` automatically emails in the thread for patches that have been applied
<jonmason>
thats what I'm doing now for meta-arm
<qschulz>
just for the sake of completeness, Buildroot does the extreme opposite by sending a mail as answer to the original thread + a mail which notifies a new commit has made it to the X branch
<jonmason>
RP: you'll never have the time. you don't have time to properly sleep as it is
<qschulz>
and I'm frankly annoyed by it, every monday I've like 500 mails from Buildroot over the weekend :)
zpfvo has quit [Ping timeout: 240 seconds]
<RP>
zeddii: the trouble is people think I'm joking and I'm not. I don't know if I want to keep doing this :(
<vd>
RP: well I obviously didn't mean to piss you off. I just have trouble understand this different workflow for yocto since you actually are a kernel maintainer.
<RP>
vd: we built yocto project differently from the kernel and I don't think the kernel is right about everything.
<qschulz>
RP: I think it's always going to be the issue that people have so many different workflows and whatever the upstream project (or its maintainer(s)) picks as workflow, it'll always bother people
<fray>
every projects workflow is different.. it's the user's responsibility to adapt to the communities/maintainers workflow
zpfvo has joined #yocto
<fray>
smurray: BTW the message I was seeing most was "Makefile:144: recipe for target 'sub-dbus-install_subtargets' failed"
<RP>
qschulz: this is the challenge. If I started replying to patches I could probably only do it privately as people wouldn't want the list spam. Even then I'd need an exclusion list for those people who asked not to get such a reply (and yes, there would be some)
* rburton
decides not to lob the gitlab-shaped grenade into the room :)
<rburton>
arguably, if b4 was used, people who object to the replies can at least then filter them all out relatively easily
<fray>
smurray: what was happening was a file either already existed (so it didn't overwrite and failed) or it DIDN'T already exist to copy it over..
<rburton>
but that does mean RP rewriting his workflow to use b4
<RP>
it would mean RP having time to even think about this stuff
<rburton>
which may be a net win in the long term but is a time sink in the short
<vd>
problem is that you send a patch, you can no reply, the patch being good or bad. Then what? You come bother the maintainer on IRC.
<rburton>
vd: ideally the sender pings the list first instead of bothering on irc
<fray>
vd -- or you look at the git repository.. if it's not merged into -next within a week.. ping..
<smurray>
fray: this log I'm looking at has a failure down in the qdbus stuff, but not exactly that target
<Saur>
vd: You do as fray said, you monitor master-next and master.
<RP>
vd: what happens is that either you need it merge or see it in master-next. If it fails for some reason you generally get a reply. If it languishes most people ping in reply to the message and I realise it got lost and do something
<fray>
smurray: there is definitely something wrong with the dbus stuff in qtbase.. like I said, it's not always int he same place.. but in my case 90% of the reports were in that place
<vd>
I don't understand this point about people being annoyed by too many emails. That's a mailing list for patches. What's the matter?
<jonmason>
RP: if I wrote a script to take everything off a mailing list (e.g., oe-core) and apply it to a tree, throw it in a cronjob and run it for a week or so to prove it works. would that be a good example for you?
<RP>
some people reply to the message losing the mail id and that *really* annoys me as I then have to find the original mail as my threading doesn't work. I tend not to complain though as that is my problem
<rburton>
jonmason: you're wildly over-estimating how good 50% of the patches are
<smurray>
fray: okay. I'll perhaps get them to try a build with it at -j 1 to see
<zeddii>
jonmason: except that's pulling in all patches. regardless of their quality
<jonmason>
lol, probably
<RP>
jonmason: no. I can't just accept some random script I wasn't party to writing as I'm the one left trying to use/maintain it
<zeddii>
snap
<fray>
smurray: we found if we just switch to -j1, the do_compile moves to HOURS.. but if we do it only for do_install issue is fine and the time difference is "reasonable".. again your config may vary
<jonmason>
RP: I'm not saying it's yours, I'm saying as an example for you to modify. a starting point to show you it's useful
<RP>
Even the reply to patch stuff is difficult as a lot of the time I end up correcting spelling mistakes and so on so the patch doesn't match the original shortlog and so on
<smurray>
fray: hrm, the failure I've been pointed at is in do_compile, though, so perhaps it's different
<fray>
up different then. I've not seen any do_compile failures (I'm speaking very much of honister BTW)
fitzsim has quit [Remote host closed the connection]
<smurray>
fray: this is dunfell, but would be similar qt version, I imagine
<fray>
in gatesgarth, we DID see do_compile as well as do_install.. so that required the -j 1.. and a lot of upset people that their build times jumped by 2-3 hours
<smurray>
fray: if I could reproduce it myself it'd be a lot easier, but I've never seen it
<qschulz>
rburton: I've stumbled upon sourcehut recently too, mailing list based reviews and I read somewhere ("sources tell me" kinda) that they were tracking the result of the patch on the mailing list or something?
<fray>
we see it about 1 out of every 10 builds.. (maybe even less honestly).. but when it happens it's catastrophic to automated building..
<smurray>
fray: yeah, that's a pretty high frequency
<qschulz>
rburton: just wanted to add this, not start a new debate though :)
<fray>
I should clarify when I say 10 builds, we do 1 "build" a day and inside of that 1 build is probably 20+ configurations..
<fray>
so it's pretty rare..b ut we'll occasionally see it with multiple trys.. then it just goes away for 2 weeks
<fray>
we've not seen any failures (honister) since moving it exclusively to -j 1 in do_install though. I doubt it's "fixed", but it's "better"
tnovotny has quit [Remote host closed the connection]
<vd>
RP: I'm definitely not telling you how to do your job. I am also grateful for what you're doing with Yocto. I'm just giving a feedback as a modest contributor. Even though each project has a different workflow, it seems like the tooling for yocto isn't appropriate and/or you might have too much on your plate and might need an extra hand for maintainership. Sorry for bringing this up.
<smurray>
fray: okay, good to know, as we'll be bumping AGL to kirkstone in the not too distant future, so it might be something we see then
<RP>
vd: I understand the request. Sadly it just isn't as easy as you'd think and we do have a significant lack of maintainers :(
<RP>
I think we need to write off 3.5 M2 rc1
* rburton
shakes fist at networks in general
<RP>
I think I can see at least four issues in that build
<RP>
and sadly I think the best way to fix some of them is heavy rewriting on some core bits of bitbake
ferlzc has joined #yocto
ferlzc57 has joined #yocto
dev1990 has joined #yocto
ferlzc95 has joined #yocto
zyga-mbp has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
ferlzc95 has quit [Client Quit]
ferlzc has quit [Ping timeout: 256 seconds]
ferlzc57 has quit [Ping timeout: 256 seconds]
ferlzc has joined #yocto
ferlzc has quit [Client Quit]
ferlzc has joined #yocto
<vd>
To ask for a following on a patch, do you guys prefer to reply to the thread, resending the series with a prefix such as RESEND?
zpfvo has quit [Ping timeout: 240 seconds]
<rburton>
vd: a 'ping' is sufficient
zpfvo has joined #yocto
<ferlzc>
hello I'm trying to create a recipe on (Yocto 3.3) for an project using Makefile. I'm suck on a missing library : <libpq-fe.h> . I tried to in my recipe the following DEPENDS = "postgresql" but it still no getting to compile. Any suggestion on where I should look/tweak to make it work ?
<rburton>
ferlzc: most likely you're not using pkgconfig to find the postgresl headers, and they're not in the default search path
<vd>
rburton: like you literally reply 'ping' to your own patch?
<rburton>
pretty much
<RP>
vd: since I know about this one I'll take a look at them
<vd>
The biggest (and more interesting) challenge in FOSS to me is the mixture of culture and the language barrier. I can write things that seem offending when I don't mean to, and sometimes I see offense when there's none.
zyga-mbp has joined #yocto
ferlzc has quit [Quit: Client closed]
pgowda_ has quit [Quit: Connection closed for inactivity]
frieder has quit [Read error: Connection reset by peer]
<vd>
qschulz: I still have the same psplash message: "Warn: update-alternatives: psplash has multiple providers with the same priority" even though the distro sets SPLASH ?= "psplash-foo".
<RP>
vd: Set ALTERNATIVE_PRIORITY_psplash-foo to something
rfuentess has quit [Quit: CHELAS!]
<RP>
vd: btw, for the docs if you don't know where it should go, just write the section in an email and mail to the docs list. michaelo and/or qschulz or someone else can find where it should be
florian has quit [Quit: Ex-Chat]
<vd>
RP: got it.
<vmeson>
Perceval[m]: is seems that there isn't anyone here with relevant meta-tegra performance experience, maybe try the yocto email list and provide more info such as kernel versions and a simple reproducer if possible.
<Perceval[m]>
okay, thank you for the hint :)
zyga-mbp has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
fitzsim has joined #yocto
<ziga_>
Where should variable PREFERED_PROVIDER be set? I saw a lot of exaples where this variable is used in "conf/local.conf" but i don't like to put it there... Is there any better file where I can put it?
<rburton>
your distro conf
zyga-mbp has joined #yocto
<ziga_>
So basically in any kind of .conf file? If it is insice conf/local.conf we would say that this is a "poking" approach? This approach is not the correct one and should be for testing only?
<rburton>
local.conf should be as minimal as possible, yes
<rburton>
ideally, you have your own distro config for the policy stuff like that
<rburton>
well, some things are machine-specific, so can go in the machine conf
<rburton>
like 'what boot loader do i use'
zyga-mbp has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
ferlzc has joined #yocto
mckoan is now known as mckoan|away
<ziga_>
Ok. In mmy case I have no machine .conf file so I can only use distro currently. Thank you.
ferlzc has quit [Client Quit]
zyga-mbp has joined #yocto
neverpanic has quit [Quit: reboot]
zyga-mbp has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
neverpanic has joined #yocto
zyga-mbp has joined #yocto
Tokamak has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Tokamak has joined #yocto
manuel1985 has quit [Remote host closed the connection]
manuel1985 has joined #yocto
ferlzc has joined #yocto
florian_kc has joined #yocto
ferlzc has quit [Quit: Client closed]
Dhruvagole[m] is now known as Dhruvag2000[m]
sakoman has quit [Quit: Leaving.]
tlwoerner has quit [Remote host closed the connection]
tlwoerner has joined #yocto
dtometzki has joined #yocto
leonanavi has quit [Ping timeout: 240 seconds]
<jonmason>
zeddii: thanks for fixing dtc stuff!
leonanavi has joined #yocto
zyga-mbp has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
zyga-mbp has joined #yocto
<ziga_>
Can I require/include a one machine's .conf file inside the other machine's .conf file?
dtometzki has quit [Read error: Connection reset by peer]
pabigot has quit [Ping timeout: 240 seconds]
GNUmoon has quit [Ping timeout: 276 seconds]
zyga-mbp has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
florian_kc has quit [Ping timeout: 240 seconds]
zyga-mbp has joined #yocto
leonanavi has quit [Ping timeout: 240 seconds]
zyga-mbp has quit [Client Quit]
dmoseley has quit [Ping timeout: 240 seconds]
dmoseley has joined #yocto
<kergoth>
ziga_: yes, just remember to set MACHINEOVERRIDES if you also want overrides in recipes to take effect for both machines
<ziga_>
@kergoth Thank you. I thought that include/require is only applicable to the .inc files! :D
<kergoth>
.inc is just a convention for the file being included, same syntax as .bb, but any bitbake file can be included, even a bbclass (inherit is shorthand for require classes/foo.bbclass with a bit of wrapper logic)
pabigot has joined #yocto
<kergoth>
just remember that you want to use the full path fromt he root of the repo for your inclusion
<kergoth>
that is, don't require somemachine.conf, but require conf/machine/somemachine.conf
leonanavi has joined #yocto
<ziga_>
Yes. I understand. I can use conf/machine/ part for all the machines from all the layers? Even for the layers that are downloaded additionally from Openembedded layer index for example? Does bitbake somehow see them as all being stored inside "conf/machine/" ?
Tokamak has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<fray>
I've got a recipe that has an anonymous python section looking to see if a file pointed to by a variable exists. If it doesn't then it does a bb.parse.SkipRecipe w/ a message
<fray>
the problem is I create the file.. and it never re-runs the anon python, it caches that the recipe isn't available.
<fray>
How can I deal with this?
<fray>
(the purpose of the recipe is to take a binary firmware blob provided by the user.. so we can't "build it", and I don't want to wait until it tries to use it to warn the user it's missing -- if they try to build somethat that needs the firmware blob)
zyga-mbp has joined #yocto
zyga-mbp has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
davidinux has quit [Ping timeout: 240 seconds]
zyga-mbp has joined #yocto
goliath has quit [Quit: SIGSEGV]
zyga-mbp has quit [Client Quit]
zyga-mbp has joined #yocto
<fray>
looks like I might be able to set BB_DONT_CACHE
GNUmoon has joined #yocto
amitk has quit [Ping timeout: 250 seconds]
<zeddii>
yah. I think that is the right var.
kevinrowland has joined #yocto
<kergoth>
fray: i'd expect you to be able to set file-checksums, programmatically in the anonymous python if necessary
<fray>
Thats what I'm going to be doing.. setting SRC_URI, file-checksums and BB_NO_CACHE in the anon python.. I've not tested it much, but I suspect this will do what I want
Skinny79 has quit [Quit: Connection closed]
zyga-mbp has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<fray>
in the end if the user doesn't set it, I need the recipe skipped.. but if they do set it.. I need to pay attention to the checksum and change if they put in a new binary.. I THINK this will do what I need now
<fray>
(I only set the BB_NO_CACHE if I'm doing the skip recipe exception.. I'm fine with caching otherwise as long as the file-checksums are set)
mvlad has quit [Remote host closed the connection]
<RP>
JPEW, sgw: I was looking at the spdx code and it looks like we don't scan for any license header to inject into the SPDX data yet, do I understand correctly?
<RP>
JPEW: also, if I remember rightly you use the icecc class? Is there a good reason to separate the *_SYSTEM_* and *_USER_* variables or could those be merged?
Tokamak has joined #yocto
<sgw>
RP: that's my understanding, currently the License Declared is from the recipe, there is no further parsing of Source code to create a license concluded value.
huseyinkozan has quit [Quit: Konversation terminated!]
<rburton>
RP damnit!
<RP>
sgw: I think we should find a tool or just add something really simple that scans the source file for an SPDX-License-Identifier
<sgw>
RP: I will add it to my list, not sure when I will get to it, maybe JPEW has cycles to look at it more closely if you want it for the spring release.
<RP>
sgw: ok, I just thought I'd mention it as it would make things much more interesting/useful. It shouldn't be hard to do so I might give it a go, we'll see
otavio_ has joined #yocto
otavio has quit [Read error: Connection reset by peer]
<JPEW>
No, we don't do scanning
<sgw>
RP: was that a request based on sharing the kernel data?
<sgw>
I can give it a go, I know you have alot on your plate also.
<JPEW>
We only do the "declared" right now. Scanning gives you the "concluded" license
<JPEW>
I was hoping something like reuse would become standard and we could use that, but I haven't seen anything
Tokamak has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
leonanavi has quit [Ping timeout: 256 seconds]
<RP>
sgw: It wasn't but I know it will be the next question I get asked!
<RP>
I think we should be able to do something relaitvely easily if we limit it to the SPDX license identifier standard
zyga-mbp has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]