vmeson has quit [Read error: Connection reset by peer]
goliath has quit [Quit: SIGSEGV]
warthog9 has quit [Ping timeout: 268 seconds]
x0n^^ has joined #yocto
xon^ has quit [Ping timeout: 244 seconds]
RobertBerger has joined #yocto
rber|res has quit [Ping timeout: 244 seconds]
matthewcroughan has joined #yocto
camus has joined #yocto
matthewcroughan has quit [Client Quit]
matthewcroughan has joined #yocto
<matthewcroughan>
well hello there..
<matthewcroughan>
that transition was painless
<matthewcroughan>
Can anybody please break this down for me, or link me to part of the documentation that explains the syntax of things like ${@bb.utils.contains('arg1', 'arg2')}
<matthewcroughan>
I'm a bit confused on what the @ means, the rest I kind of understand.
<khem>
this is the magic to call python functions in shell scripts
<matthewcroughan>
Is there any bit of the docs that explains this particularly?
<matthewcroughan>
Or is it just something we take for granted and use without thinking too much about it?
<matthewcroughan>
Just as it looks like we put spaces at the start of lists.
<matthewcroughan>
What about this? require ${@bb.utils.contains('DISTRO_FEATURES', 'wayland', 'recipes-samples/images/feature-wayland.inc', '', d)}
<matthewcroughan>
in this case, is it saying that the return value of the function is required?
zeddii is now known as zzedd
zzedd is now known as zedd
camus1 has joined #yocto
camus has quit [Ping timeout: 272 seconds]
camus1 is now known as camus
<moto-timo>
if the variable DISTRO_FEATURES contains "wayland" then 'require recipes-samples/images/feature-wayland.inc' otherwise the require statement is empty as does nothing
<moto-timo>
require means the file must exist, include can fail silently
<matthewcroughan>
oh wow that's a really strange way of saying it, to me :D
<matthewcroughan>
so require is also an if statement secretly?
<moto-timo>
it's the start of the line
<moto-timo>
nothing secret, it either finds the file or it fails
<moto-timo>
but if it's asked to find nothing, it succeeds at finding nothing
<matthewcroughan>
do you view this as legitimate functionality of the language, or a hack?
<matthewcroughan>
It seems to me, a bit hard to understand.
<matthewcroughan>
Now that you have explained it, I understand. The return of the function in ${@} is empty otherwise, so it'll require nothing if DISTRO_WAYLAND isn't defined.
<moto-timo>
we need a mechanism to do things based on values stored in variables. it's not a hack.
<moto-timo>
it might be subtle nuance
sakoman has quit [Quit: Leaving.]
<moto-timo>
in particular, DISTRO_FEATURES are very high priority, but you don't know whether or not it is enabled in a recipe unless you check
<matthewcroughan>
Well no, think about it. It's just an if statement.
<moto-timo>
I'm not going to argue with you.
<matthewcroughan>
It's being misused as an if statement. I understand this may be the only way to do it within the constraints of the language.
<moto-timo>
HTH
<matthewcroughan>
Is there another way of doing the same thing out of interest? Thanks so much for explaining this to me. It did not make sense before your help :D
<matthewcroughan>
where does `require` come from?
<matthewcroughan>
is it the same place the @functions come from?
<kergoth>
You can also call any function defined with 'def' in the metadata too
<matthewcroughan>
Is Bitbake more like a templating language?
<matthewcroughan>
${@} calls some stuff which is passed to directives like `inherit` and `require`.
<kergoth>
The file format is meant to be mainly declarative, yes. Essentially a key/value store of information about a recipe and platform and distro, even tasks are just key/value with a flag set to indicate the difference from a plain variable.
<kergoth>
Sadly we have some imperative elements, and order-dependent aspects that confuse it a bit, so is neither purely declarative nor purely imperative. gets the job done. in retrospect we'd have done a number of things differently
<matthewcroughan>
Ever played with Nix? :P
<kergoth>
yep, didn't exist when we wrote bitbake though :)
<matthewcroughan>
Yeah I've read a bit about the history.
<kergoth>
bitbake was inspired by the gentoo package manager portage, so a number of little elements came from that, such as certain variable names and conventions
<matthewcroughan>
Although actually, Nix precedes bitbake by a year.
warthog9 has joined #yocto
<matthewcroughan>
kergoth: I've noticed that. Can you explain this one to me?
<kergoth>
interesting, haven't read much about the history of nix. did it originate in academia?
<matthewcroughan>
kergoth: comes from a university in a way. A genius by the name Eelco Dolstra.
<matthewcroughan>
same guy who made patchelf which I see used a lot in OE commits.
<matthewcroughan>
Whereas here, they are quite explicit. In OE they are hidden behind python-dateutil.
<matthewcroughan>
This hiding. Does it have a name, and why is it something that seems to happen in OE and not so much in Gentoo? Is it a choice? Is it a language feature that is different between the two?
<kergoth>
no idea who maintains that layer, it's a bug in the recipe.
<kergoth>
neither, you're conflating a random file in a not official layer with project policy :)
<matthewcroughan>
Oh, that's not official?
<kergoth>
well, it's one of many layers, not part of yocto itself
<kergoth>
anyone can make a layer, quality varies widely
<matthewcroughan>
Well that does answer my question :D
<matthewcroughan>
thanks
<kergoth>
We prioritized flexibility, but that has consequences, a lot of ways of doing things, and not everyone follows conventions
<kergoth>
we're working on this issue as a project, adding better tooling for checking layer quality and the like, but it's a work in progress, and not everyone applies to be yocto compatible
<kergoth>
if you use `recipetool` to create a new recipe for a python project, it'll call out to a script that does static analysis on the code in the project sources to prepopulate the rdepends
<kergoth>
presumably whomever created this one didn't use it, though :)
<kergoth>
calling it unofficial wasn't a great way to put it, it's maintained by a core yocto developer, and it's hosted at yoctoproject.org, but it's not one of the core layers either
<kergoth>
i'd suggest opening a bug in the yocto bugzilla on this specific issue
<kergoth>
i should really run through and run the python depends analysis on every python recipe in the yp.o layers and compare to the recipe content
<kergoth>
I think the biggest advantage of oe isn't the tooling, the file format, etc, but the fact that's it's structured in a way that makes it easy-ish to share the same common baseline for widely varied use cases between numerous companies with differing requirements. The layer structure along with our distro/machine/image axes being key elements to that.
warthog9 has joined #yocto
<paulg>
anyone can make a lawyer, quality varies widely
pidge_ has joined #yocto
pidge has quit [Read error: Connection reset by peer]
Vonter has joined #yocto
pidge_ has quit [Remote host closed the connection]
pidge_ has joined #yocto
x0n^^ has quit [Remote host closed the connection]
Vineela has quit [Quit: Leaving.]
x0n^ has joined #yocto
pidge has joined #yocto
pidge_ has quit [Read error: Connection reset by peer]
x0n^ has quit [Quit: Leaving]
x0n^ has joined #yocto
x0n^^ has joined #yocto
x0n^^ has quit [Quit: x0n^^]
x0n^^ has joined #yocto
x0n^^ has quit [Quit: x0n^^]
x0n^^ has joined #yocto
x0n^^ has quit [Remote host closed the connection]
x0n^^ has joined #yocto
chrfle has joined #yocto
x0n^^ has quit [Quit: x0n^^]
x0n^ has quit [Quit: Leaving]
rob_w has joined #yocto
x0n^ has joined #yocto
x0n^ has quit [Quit: x0n^]
LetoThe2nd has joined #yocto
x0n^ has joined #yocto
x0n^ has quit [Quit: x0n^]
x0n^ has joined #yocto
Vonter has quit [Ping timeout: 272 seconds]
x0n^ has quit [Remote host closed the connection]
prabhakarlad has quit [Quit: Client closed]
mckoan|away is now known as mckoan
<mckoan>
good morning
<ant_home>
ciao mckoan
<LetoThe2nd>
yo dudX and mckoans
x0n^ has joined #yocto
leon-anavi has joined #yocto
zyga-mbp has joined #yocto
davidinux1 is now known as davidinux
hpsy has joined #yocto
hpsy has quit [Client Quit]
goliath has joined #yocto
camus has quit [Ping timeout: 272 seconds]
camus has joined #yocto
prabhakarlad has joined #yocto
Andy99 has joined #yocto
RobertBerger has quit [Quit: Leaving]
rber|res has joined #yocto
BCMM has joined #yocto
BCMM has quit [Client Quit]
BCMM has joined #yocto
<Andy99>
Maybe I was off during some answer, so I will ask again. Is anyone using the eSDK devtool update?
<paulg>
RP, just sent you a fix to look at/test....
<paulg>
fingers crossed.
* paulg
stumbles off.
<mckoan>
ant_home: hey!
<mckoan>
LetoThe2nd: yo!
xmn has quit [Quit: ZZZzzz…]
<LetoThe2nd>
Andy99: haven'T been around earlier, so do you have a more specific question? because a mere "yes/no" answer won't get you anywhere, probably
<Andy99>
LetoThe2nd: Maybe I've founded a problem, when this feature is not working. It's calculate the difference between hashes of your local and remote version. But the local version is not being updated.
<LetoThe2nd>
Andy99: sounds like condensing it into a reproducable description and putting in onto the mailing list would be a good idea.
<Andy99>
@Let
<Andy99>
LetoThe2nd: The question is, if it's working in general?
<LetoThe2nd>
Andy99: i think it should, but my understanding is that it is meant to look if an upstream repo has a newer version than being noted in the recipe.
<LetoThe2nd>
what do the docs say about it?
<smurray>
one issue is there are not a lot of eSDK users, so hitting a window when someone here can provide an answer is a bit harder than for other stuff. The ml probably would work better
zpfvo has joined #yocto
camus1 has joined #yocto
<RP>
Andy99: I think I saw the question on a different channel. devtool upgrade does work and is used for example by our AUH (automatic upgrade helper) to help keep recipes up to date. Does it work in every case? No. There are some open bugs in bugzilla. Does the eSDK work in every case? Also, no, it isn't as widely used as some areas of the project
<RP>
devtool upgrade can be used outside the eSDK
camus has quit [Ping timeout: 272 seconds]
camus1 is now known as camus
<RP>
paulbarker: do you want me to keep any of these hanging builds around for debugging? We're starting to collect quite a few :(
<ant_home>
RP: kergoth: pls decide about overrides and immediate evaluation :)
<paulbarker>
RP: I don't think they're needed
Guest1310 has joined #yocto
Guest1310 has quit [Client Quit]
<RP>
ant_home: that decision can't be a quick one. It needs analysis of the impact of the change on wide set of metadata
Andy99 has quit [Ping timeout: 250 seconds]
<RP>
ant_home: trying to pressure me like this isn't really fun either, I'm depressed enough with the long list of problems we've got
<ant_home>
sorry, it was not intended
<ant_home>
pls don't misunderstand
<ant_home>
it was like 'poke kergoth' for a new reading tonite :)
<ant_home>
you were just fc/c
<kanavin>
RP: apologies for the wrong tone, people have been getting on my nerves too this week
<kanavin>
RP: let's just rest the issue
<kanavin>
RP: if there's anything where I can help, do tell
<ant_home>
RP: did you maybe finish the beer in the fridge?
<RP>
kanavin: the upgrades look good, thanks. For the prelink thing, disabling ppc 32 may be a better option although even with that we should probably see if there is any kind of simple fix first. I am worried we're not getting bugs in pseudo or patchelf fixed and prelink is just part of that same problem in my eyes :/
<ant_home>
I already owe cans to you guys :)
dkl has joined #yocto
<RP>
ant_home: I do love the fact meta-handheld is still going and I have a soft spot for the zaurus. I just don't know how safe making that change is and the analysis will not be easy to figure it out
<kanavin>
RP: I really should have addressed the questions to Mark Hatle rather than you, it's his baby, and he probably can point to specific benefits, given the effort he's put into it
<kanavin>
fray, ^^^
<RP>
kanavin: the wins should be a) lower memory usage as pages mapped from disk files shouldn't need the offsets rewritten in them meaning the pages can be shared between processes b) faster load times as the offsets shouldn't need to be recomputed
<kanavin>
RP: I'd like to measure those, perhaps core-image-sato-sdk without kvm will do? (use 'free' to compare memory usage, run testimage 10 times in a row)
<RP>
kanavin: "man ld.so" may give some hints about getting timings from prelink. I could have sworn there was a way to get timing info but I can't spot it from a quick read
<kanavin>
RP: upstream prelink has been abandoned in 2013 too
<RP>
kanavin: prelink support is still in glibc though. If it were removed from there, that would be a bigger issue
sstiller has joined #yocto
kayterina has joined #yocto
<RP>
qschulz: since you've looked at bitbake operators, what would you use to indicate a new assignment operator which behaved like "=" but reset overrides and append/prepend/remove?
<rburton>
=!!
<rburton>
! being emphasis :)
<LetoThe2nd>
"===="
<rburton>
i hope that's four equals
<LetoThe2nd>
yup. three equals would be too javascriptish for us.
<rburton>
exactly
<RP>
rburton: !=! :)
<rburton>
isn't that a PHP operator?
<LetoThe2nd>
or "totally!="
<RP>
rburton: !== is
<LetoThe2nd>
"==!1!one!"
<rburton>
ah <=> is the one i'm thinking of
<LetoThe2nd>
ah no, rather "=!1!!eleven!!"
<LetoThe2nd>
rburton: spaceship operator.
<RP>
this is where we're going wrong with bitbake, we need better operator names
<rburton>
'be more like PHP' is not a policy i'm entirely happy with
<RP>
rburton: hmm, when you put it like that :/
<LetoThe2nd>
how about "assign_now_and_totally_no_matter_what_is_stated_elsewhere"?
<RP>
LetoThe2nd: too unclear as later statements would still change it
<LetoThe2nd>
i just had the idea of making a bitbake version where all assignments would be verbs.
<qschulz>
RP: please no, I just gave a talk to tackle everything.. now is not the time to add one more operator :D
<LetoThe2nd>
qschulz: think job security! whenever you give the talk, RP creates a new operator and you can sell new talks!
<qschulz>
If only I got paid :p
<LetoThe2nd>
you got paid in karma! i sent a lot your way!
* RP
is torn between changing the behaviour of := and adding a new operator. We don't need the expansion part of that := does
<qschulz>
RP: I would use a declination of := since I imagine your new operator would reset everything that was done before but allow further overrides/append/prepend and remove?
<RP>
qschulz: correct
<qschulz>
RP: I would avoid using ! since it usually means "not" in languages
<qschulz>
so, an additional character that would mean "everything"
<qschulz>
would :=42 work :p ?
mckoan is now known as mckoan|away
<qschulz>
something like *:= ?
<qschulz>
or :=*
<ant_home>
RP: sorry but what was then '<foo>_forcevariable'
<qschulz>
ant_home: it's an override, it applies before _append, _prepend and _remove if I'm not mistaken
<qschulz>
also, _forcevariable has a lower priority than virtclass-mulitlib-
<ant_home>
then bitbake.conf needs to be updated
<ant_home>
qschulz, never ever used it
<RP>
qschulz: not intentionally, forcevariable was meant to win
ilunev has joined #yocto
sstiller has quit [Quit: Leaving]
<qschulz>
RP: that's what I had guessed :)
<qschulz>
the fix should be rather straight forward though
<qschulz>
where we add virtclass-mulitlib- in OVERRIDES, we re-add forcevariable just after?
<RP>
qschulz: could we get rid of the original too please and avoid the duplicate?
<RP>
with that tweak, please do send
<RP>
FWIW I mailed oe-arch with the idea of a new operator
<RP>
ant_home: ^^^ progress. I'm interested in kergoth's thoughts
<ant_home>
thanks!
gsalazar has joined #yocto
<rburton>
does anyone know how to get clang to tell me exactly what warning category a message comes from so i can turn it off?
bps has joined #yocto
bps has quit [Changing host]
bps has joined #yocto
angolini has joined #yocto
vquicksilver has quit [Quit: WeeChat 3.1]
<qschulz>
RP: very upset you didn't like my suggestion.. :D
<qschulz>
(new operator topic)
vquicksilver has joined #yocto
<dl9pf>
RP: question on usage of LICENSE and LICENSE_mypackage-1, LICENSE_mypackage-2 : Lets assume my default license is A and a subpackage has license B. Is it valid to just say LICENSE = "A" (thus mypackage-1 gets A by default) LICENSE_mypackage-2 = "B"
<dl9pf>
RP: or do I need to write it LICENSE = "A & B" , LICENSE_mypackage-1 = "A" , LICENSE_mypackage-2 = "B"
<dl9pf>
real case here is more complex due to dynamic packages that need to be handled.
<dl9pf>
I think this shows an area where we can improve. Aka differ between 'all licenses used in this package' vs 'default license' unless declared for output package for example.
<dl9pf>
e.g. look at what xz produces if you query the licenses from rpm:
<qschulz>
dl9pf: you need to write LICENSE = "A & B" currently
camus has quit [Ping timeout: 264 seconds]
camus has joined #yocto
<qschulz>
I think it still makes sense to have a global LICENSE, specifically because it's used for DEPENDS too, where the notion of packages is absent
<JPEW>
RP: why don't we need the expansion part of := ?
<JPEW>
FWIW, I always use := when pretending THISDIR to FILESEXTRAPATHS. I thought using := was required in that context
<qschulz>
JPEW: it is
<qschulz>
because of THISDIR variable
<JPEW>
Right, I must be misunderstanding RP's comment then
<RP>
dl9pf: I was going to say the later, unless dynamic packages are involved :/
rob_w has quit [Quit: Leaving]
<RP>
'LICENSE = "A" LICENSE_mypackage-2 = "B"' is ok but not when dynamic packages are around :/
<qschulz>
RP: Bitbake complains that B is not in LICENSE (at least on thud)
<RP>
for dynamic packages, all the licenses probably need to be in LICENSE
<RP>
ok, then they need to all be in LICENSE :)
<qschulz>
JPEW: we don't need the new operator to do immediate expansion like := does
<qschulz>
is how I understood it
<qschulz>
so now I see why RP didn't like my :=* *:= suggestions
* JPEW
understands now
<RP>
qschulz: it depends how you think of :=
<RP>
I think this thread is proving why I dread and fear making any change at all to bitbake :(
BCMM has quit [Quit: Konversation terminated!]
<qschulz>
RP: I misunderstood how the _collie was an issue
<qschulz>
I should wait for my post-lunch sugar rush to settle before I try to communicate :D
<qschulz>
RP: I'll answer that if I don't forget on the ML
<qschulz>
but... I have seen a TON of overrides in bbappends for Freescale/NXP machines in their vendor BSP
<qschulz>
so forbidding this new operator from being used in conf files won't make vendor BSPs much better since they would still have that option in bbappends anyway
<RP>
qschulz: fair enough, just mentioning a possible option
<ant_home>
qschulz, maybe we should just have reverted 4ef8f82 in meta-handheld uncovering the issue
<ant_home>
just rewind back :)
prabhakarlad has quit [Quit: Client closed]
<qschulz>
well.. it's a valid use case? you could use IMAGE_FSTYPES_remove_collie but that's definitive
<qschulz>
so the trick of IMAGE_FSTYPES_REMOVE_COLLIE = "ubifs ubi" IMAGE_FSTYPES_remove_collie = "${IMAGE_FSTYPES_REMOVE_COLLIE}" which allows to modify it in other places
<qschulz>
would allow*
<RP>
qschulz: that is horrific ;-)
<qschulz>
hehehehe
<qschulz>
i'm actually not entirely sure to have understood the actual issue here
<qschulz>
it's a case of needing bitbake -e (or the need oe-getvar or however its' called?) to figure this out?
<qschulz>
RP: qschulz: just so I don't forget to test this and make the commit at home: https://paste.ack.tf/13d051 (for forcevariable)
nerdboy_ has joined #yocto
xmn has joined #yocto
nerdboy has quit [Ping timeout: 244 seconds]
wmiles has joined #yocto
pbergin has joined #yocto
camus has quit [Remote host closed the connection]
camus has joined #yocto
vmeson has joined #yocto
sakoman has joined #yocto
BCMM has joined #yocto
<paulg>
RP, got about 50 runs on that 13-rc6 one liner "overnight" and zero fails/warn/ooops....
droman is now known as stkw0
xmn has quit [Read error: Connection reset by peer]
<kergoth>
... wow, freenode exploded even more. https://pastebin.com/raw/XaCXd2SD yikes, what is that person smoking.. glad we got off it before that madness
<RP>
paulg: I've got 20 runs with the tweak applied, no BUG:
<RP>
paulg: that was with master OE-Core and the tweak
<kergoth>
I'll check out the new operator thread a bit later today and give my thoughts, haven't had a chance yet this morning.
<RP>
paulg: had a bit of a slow start getting a cleaner test environment but got there...
<RP>
kergoth: thanks. On the one hand its a horrible mix of semantics, on the other it isn't worse than what we already do. I just can't see a good way to solve the underlying interaction problem
pbergin has quit [Remote host closed the connection]
Vonter has joined #yocto
<paulg>
RP, I'll double check things here, fix it "properly", write a commit log and bounce it off the usual suspects sometime today to see what they think - but testing seems to be on my side so far.
<dl9pf>
RP: qschulz: problem is dynamic packages like locale or other dynamic packages. There I have good way to give them just one of the licenses listed in LICENSE. They get all. (see the pipewire example or the xz-locale above)
stkw0 has quit [Ping timeout: 240 seconds]
<dl9pf>
RP: qschulz: problem is dynamic packages like locale or other dynamic packages. There I have *no* good way to give them just one of the licenses listed in LICENSE. They get all. (see the pipewire example or the xz-locale above)
perdmann has quit [Ping timeout: 252 seconds]
perdmann has joined #yocto
wesm has quit [Ping timeout: 244 seconds]
stkw0 has joined #yocto
skrawn has joined #yocto
skrawn has quit [Client Quit]
skrawn has joined #yocto
<ecdhe>
I had a machine crash during a build. I backed up my DL_DIR and ran bitbake -c cleanall then restored my DL_DIR but now when I build I get an sqlite error "database disk image is malformed". I can't tell from the logs what file it's for
<qschulz>
dl9pf: iterate over all entries in PACKAGES matching the regexp used in the dynamic packaging right after your dynamic packaging and set the appropriate license there?
<qschulz>
would that work?
<dl9pf>
in principle, yes. But the variant a) is way simpler for users.
x0n^^ has joined #yocto
prabhakarlad has joined #yocto
x0n^ has quit [Remote host closed the connection]
<RP>
dl9pf: I think do_split_packages has a way to set this kind of thing, whether it is accessible is another matter
wesm has joined #yocto
pidge has quit [Quit: Leaving]
sstiller has quit [Remote host closed the connection]
<RP>
haha, I find code marked "Disabled by RP 18/06/07"
pidge has joined #yocto
<fray>
lol
<RP>
dl9pf: I think you should add a patch to do_split_locales() which allows the license of the locales to be set
<ecdhe>
Is there an sqlite file I can delete to resolve this error?
<RP>
ecdhe: when are you seeing that error, there are a few it could be :/
<dl9pf>
do_split_packages does not have license in its arguments ... ok, let me look
<rburton>
ecdhe: just delete the tmp directory
<RP>
dl9pf: you could query a variable for it though
<paulg>
RP, I found a driver thatwas marked with CONFIG_BROKEN the commit after it was added. Years later and it is still that way.
<paulg>
Reminds me - need to send a removal commit for that turd.
<RP>
paulg: I'm not surprised, I was just amused to read it had been that long :)
<ecdhe>
rburton: that did it
<RP>
paulg: I'm now wondering if I should revert that kernel fix just to test my environment does reproduce the bug :)
kayterina has quit [Remote host closed the connection]
<paulg>
RP - can't hurt - toggle one thing at a time - just to be sure.
x0n^^ is now known as x0n^
<paulg>
I'm always double checking "/proc/version" for normal bugs to ensure I've booted what I'm testing -- this case has a lot more moving chunks than just bzImage.
perdmann_ has joined #yocto
<qschulz>
RP: dl9pf: we could also pass d to the hook function in do_split_packages if we wanted so that anything can be done there, e.g. d.setVar('LICENSE_' + pkg, 'GPL-2.0')
droman has joined #yocto
camus has quit [Ping timeout: 265 seconds]
perdmann has quit [Ping timeout: 265 seconds]
xmn has quit [Ping timeout: 265 seconds]
stkw0 has quit [Ping timeout: 265 seconds]
<paulg>
RP, I'm going to stick your fingerprints on this with a Reported-by: unless it should be someone else ; TBH I didn't study the bugzilla cases much....
camus has joined #yocto
<zedd>
paulg: I'm finally putting aufs back, and doing a -stable update. let me know if you want something integrated, I'm trying to get the other things back in to be ready.
<zedd>
zedd who finally got his environment working right as paulg started to isolate it :D
<paulg>
let me hack together what I want the final fix to look like and get a snapshot of that across to you.
<paulg>
zedd, nobody remembers who came 2nd. :)
<zedd>
since this will take a bit to get into mainline, I'll queue it for -dev and whatever-my-nex-refernence is
<paulg>
actually I'm guessing Al will move it across quickly and get it to linus before v5.13-final -- but that is just a gut feel based on my 1/4 century imprisonment here.
<paulg>
...assuming I get off my arse and send it today.
<derRichard>
when a recipe as something like SRC_URI_append_machinefoo = "patch-foo.patch" and SRC_URI_append_machinebar = "patch_bar.patch". how can i use devtool modify/update-recipe?
x0n^ has quit [Ping timeout: 252 seconds]
<derRichard>
devtool update-recipe will kill with SRC_URI_append_machinefoo and SRC_URI_append_machinebar :(
<derRichard>
*will kill both
camus has quit [Ping timeout: 240 seconds]
camus has joined #yocto
<ecdhe>
On dunfell, should bitbake core-image-minimal -c fetchall be expected to download all dependencies?
<qschulz>
derRichard: devtool does not work too well with SRC_URI that are machine-specific, so I'd assume you should update the recipe by hand
<derRichard>
qschulz: this renders devtool close to useless :-(
<qschulz>
ecdhe: I don't think so, I think it';s something close to --run-all=fetch
<ecdhe>
I think my hard reset corruped my downloadloads directory, I'd like to just redownload it to be sure (was unpacking a tarball of the corrupt one before)
x0n^ has joined #yocto
<ecdhe>
qschulz: you're correct, sorry, had the pre 2.5 command
<derRichard>
qschulz: any workaround? or is somebody working on improving devtool in that direction?
kpo_ has quit [Read error: Connection reset by peer]
kpo_ has joined #yocto
<qschulz>
derRichard: it works just fine for what I do with it: developing/debugging
xmn has joined #yocto
<qschulz>
derRichard: patches welcome though :)
<derRichard>
qschulz: well, i need something to give my customers. when devtool destroys existing recipes it is ...
<derRichard>
qschulz: maybe i get budget to improve devtool
<derRichard>
but i fear devtool misses a lot of context, so making it less stupid in that area is not easy
roussinm has quit [Quit: WeeChat 3.3-dev]
roussinm has joined #yocto
roussinm has quit [Client Quit]
roussinm has joined #yocto
roussinm has quit [Client Quit]
ncaidin_lf has joined #yocto
roussinm has joined #yocto
<ant_home>
derRichard, decades ago there was even a try to stylize the recipes
<kergoth>
RP: Hmm, interesting problem (the email thread), I've been repeatedly bitten by similar issues -- IMAGE_INSTALL_append globally will also affect buildtools-tarball and co since they set their install without clearing pending bits much as the initramfs images did with fstypes
* kergoth
ponders
<v0n>
if my package generates .py files in /usr/lib/python3.9/site-packages/something, should it be named ${PYTHON_PN}-something?
vmeson has quit [Ping timeout: 268 seconds]
marka has joined #yocto
rcw has joined #yocto
robbawebba has joined #yocto
camus1 has joined #yocto
<RP>
kergoth: some other examples of this might show the issue is wider than people realise which is my feeling, I just lack evidence :/
camus has quit [Ping timeout: 272 seconds]
camus1 is now known as camus
pidge_ has quit [Read error: Connection reset by peer]
pidge_ has joined #yocto
<zedd>
RP: I was looking into creating a package for the configuration fragments, so I could solve a problem in meta-virt. I can't find in the manual, or a good example. What would I make a task depend on, if I want those packaged files available for that task ?
<zedd>
I can see them be packaged up if I build the package completely. so that's good.
<zedd>
but when I run do_kernel_metadata, I want them available to rummage through .. I can't get that depends[] incantation right
<fray>
if you depend on the packaged contents, your task can depend on ... (forgetting, looking it up)
<zedd>
I thought it was a target/native thing, but that was just me being dumb, since the kernel is a target build and the native recipes aren't packaged like that.
ecdhe has quit [Changing host]
ecdhe has joined #yocto
<RP>
zedd: when you say packaged files available, do you mean in tmp/deploy/rpm or in WORKDIR/package ?
<fray>
argh.. still not finding it
prabhakarlad has quit [Quit: Client closed]
<zedd>
whatever is in the WORKDIR/package. I want the source .cfg files around.
<fray>
Ahh it's "do_prepare_recipe_sysroot".. but that is only needed if you have a function that needs to spceifically wait on dependencies (and doesn't by default)
<RP>
zedd: WORKDIR/package is do_package
<fray>
ohh ok
<zedd>
I'm probably just describing the wrong thing. let me try that again, but I thought I started there :D
<zedd>
yah. that's not it either.
<RP>
zedd: I'm struggling to understand what you want then :)
<RP>
zedd: are you perhaps after one recipe to install extra files into the sysroot so a different recipe can look at them?
<zedd>
basically yes. in this case a bunch of .cfg files. I'm packaging them up in recipe a, and I want recipe b to depend on it for a given task, so it can see them in its sysroot
<RP>
zedd: so please don't use the word "packaged"
<zedd>
it is a target package :D
<RP>
You want it in a sysroot, not a target package?
<RP>
the sysroot does not work with packages and never has
<RP>
we once experimented with "packaged staging" and it never ended well
<zedd>
it's a build dependency in this case, right. I started with it as a -native package, but couldn't get anything to show up in the sysroot at all.
<zedd>
s/package/recipe/
<fray>
yes, I think he needs it in the sysroot.. sicne one workdir shouldn't look in another
<RP>
zedd: so lets just reset and step back and I'll explain what I think you really want :)
<RP>
zedd: maybe I should make you promise to send a manual entry for this first? :)
<zedd>
I can live with that. I'm tired of grepping for something to follow in the source, and my doc search failed :D
<RP>
zedd: the files we put into the sysroot are different from the files we put into packages. The sysroot code is in staging.bbclass
<zedd>
right. I've abused that with calls to stage_file in the past.
<RP>
zedd: You'll see SYSROOT_DIRS and SYSROOT_DIRS_NATIVE which are basically masks over do_install of what gets into the sysroot
<zedd>
right. so my non-standard location isn't making it into the sysroot.
<zedd>
because it is non-standard and not in those already.
<RP>
zedd: so I suspect you need to change the masking on what is going into the sysroot to include your cfg files then you can depend on it and things should work
<RP>
zedd: you'll see some recipes change SYSROOT_DIRS for this reason
<zedd>
for that task, I'd depend on the -native:<??>
<RP>
zedd: you can depend on either, that decision needs other context
<zedd>
I actually wrote one that did that in meta-virt to get a qemu wrapper available. but I try to block out how I came to that conclusion.
vmeson has joined #yocto
<RP>
a native recipe only generates a sysroot, not any target packaging
<RP>
native recipes are also "cheaper" in that they don't need the cross compiler
* zedd
tries
Vonter has joined #yocto
goliath has quit [Quit: SIGSEGV]
<zedd>
hmm. obviously no do_package in the -native, so my [depends] blew up.
* zedd
greps
<zedd>
do_populate_sysroot looks about right
<RP>
zedd: its a do_populate_sysroot depends line entry
<zedd>
if I add a custom directory to SYSROOT_DIRS, what's the base ? ${d}/<something>. I made one that I could pick up easily called "cfgbruce" to contain them all, and I'm not seeing it over in the kernel build sysroot, which means my attempt at adding it to the sysroot_dirs was the wrong format.
<zedd>
I'll dump the env and look at the defaults, that'll help.
<RP>
zedd: it is target filesystem paths so yes
<RP>
zedd: oh, natives are a little fun
xmn has quit [Ping timeout: 272 seconds]
<RP>
zedd: you have to remember that natives are against the full system path to /
<RP>
this does make sense and is correct but will hurt your brain if you've not thought about it for a while
<zedd>
so in this example, I'm installing to ${D}/cfgbruce, and I'd want my SYSROOT_DIRS to have "${D}/cfgbruce" as well.
<zedd>
yes, I've been through this before, but seem to have cache flushed it.
<zedd>
I failed with my ${D} only, so trying that :D
* zedd
is totally keeping 'bruce' in the final packaging name
<zedd>
hmm. nothing. clearly I'm too dumb for this today. I'll give up for now and come back to it later.
<RP>
zedd: my memory is clearly slightly fuzzy too :/
<zedd>
RP: my goal is to create a package that I can use to avoid duplicating configuration fragments into meta-virt, for kernel recipes that use kernel-yocto, but not the kernel-cache.
<RP>
zedd: that makes sense and should be ok as a native
<RP>
zedd: I'd probably cheat and use ${D}${datadir}/brucecfg
<zedd>
yep. I'll just get the right magic to have the fragments show up so the kernel meta data phase can find them. it's worth the effort to avoid going back to duplicated fragments for non-linux yocto recipes
<RP>
since datadir is known to work
<zedd>
I can tweak my install to see if that works.
<zedd>
since it really doesn't matter where they are, I can find them and use them after.
<RP>
zedd: This is why I'm suggesting it since anything under datadir should "just work".
Vonter has quit [Ping timeout: 268 seconds]
<zedd>
just so I know I'm not losing it completely, a -native can also install into ${D}, it just goes to the proper place for -native
<RP>
zedd: yes, it needs to do that. You'll see duplicate paths, that is fine
<RP>
the same do_install should work for target and native
* zedd
nods
<RP>
the native variable values are just a little weird looking
<zedd>
it shows up twice, which means, yes, it did finally make it over.
<RP>
so you could work it back and see how datadir is defined but if it doesn't actually really matter about the path...
<zedd>
yah. I'll do that later and decide, but that's all I needed. I can now arrange for that to be searched for fragments and voila.
* zedd
is going to get a beverage sent to paulg
<zedd>
finding that fix was kind of epic
<RP>
paulg did well to find it, it is crazy
<paulg>
yah, I've seen a lot of shit in 25 years, but that was nucking futs.
<paulg>
<------ not a filesystem guy.
<RP>
paulg: I had wondered if we would actually get an answer on it
<zedd>
paulg aka 'the new al viro'
* zedd
runs
<paulg>
heh. Not even close. More like "a blind squirrel eventually finds an acorn now and again."
<ecdhe>
I have a TI AM3517 sitara. TI still provides a ubuntu 10 vm that will build kernel 2.6 and U-boot for it.
<ecdhe>
These assets all boot just fine.
<ecdhe>
When I grab the latest meta-ti and meta-arm, I can build new assets (I need a newer kernel)
<ecdhe>
Since I already have a working U-Boot I dropped the new kernel onto the filesystem in place of the kernel 2.6 (it's a uImage file) but this doesn't boot -- the last output is U-Boot saying "Starting kernel ..."
<ecdhe>
I rebuilt with EARLY_PRINTK and set the earlyprintk=serial,ttyxx,speed param in U-Boot but still nothing
<ecdhe>
It's likely that the TI stuff completely supports the part I'm using, I'm just getting something misconfigured
<ecdhe>
is there some sort of bring-up flowchart I could refer to?
Guest50 has quit [Quit: Client closed]
<dvorkindmitry>
ffmpeg build problem https://pastebin.com/Bhf8AWHh as I foun, It try to link my host to my libraryes
LetoThe2nd has quit [Quit: Connection closed for inactivity]
vmeson has quit [Ping timeout: 272 seconds]
vmeson has joined #yocto
vmeson has quit [Client Quit]
xmn has joined #yocto
<RP>
JPEW: has anyone mentioned mingw issues to you?