<frosteyes>
Unfortunately it seems to use an ipu firmware - i can't find anywhere
<frosteyes>
The last patch in the series is 0011-isys-psys-package-lib2600b0-for-commit-id-fec284b.patch where it is upgraded to a ipu firmware 0x20200922
<frosteyes>
I can find earlier version in clearlinux - but can't seem to find this anywhere.
zpfvo has quit [Ping timeout: 272 seconds]
zpfvo has joined #yocto
florian_kc has joined #yocto
Etheryon has quit [Quit: Client closed]
zpfvo has quit [Ping timeout: 252 seconds]
zpfvo has joined #yocto
tnovotny has joined #yocto
smsm has joined #yocto
zpfvo has quit [Ping timeout: 272 seconds]
zpfvo has joined #yocto
leon-anavi has joined #yocto
davidinux has quit [Ping timeout: 272 seconds]
davidinux has joined #yocto
xmn has quit [Quit: ZZZzzz…]
Etheryon has joined #yocto
<Etheryon>
Hi all, I'm trying to copy over some files to my image but I'm having some issue. I'm clearly missing some knowledge so any help would be greatly appreciated. Here's my bb recipe file, let me know what I'm doing wrong
<qschulz>
Etheryon: I doubt that install -d -m 0755 ${S} ${D}${bindir}/resources is installing your files
<Etheryon>
Hey
<qschulz>
I think you need a for loop, find exec or cp -r
<Etheryon>
I'm currently getting this error: package_write_rpm not found in ...
<Etheryon>
on do_rootfs: task
<Etheryon>
Is my assumption correct that the files would be located in ${S} ?
zpfvo has quit [Ping timeout: 252 seconds]
zpfvo has joined #yocto
<qschulz>
Etheryon: I think so, you cna always do an ls -l ${S} to check in your do_install and check the install logs in ${WORKDIR}/temp/log.do_install
zpfvo has quit [Ping timeout: 272 seconds]
zpfvo has joined #yocto
<RP>
I'm torn on how to implement the variable rename warnings :/
camus has quit [Ping timeout: 252 seconds]
camus has joined #yocto
<qschulz>
RP: anything to suggest so we can share our opinion? or is it somewhere on the ML?
Etheryon has quit [Quit: Client closed]
<RP>
qschulz: no, this has all been left so late we now likely can't do that kind of discussion :(
* RP
will try and send something out
<qschulz>
RP: I'm surprised there hasn't been any patch except the PN_BLACKLIST one
<qschulz>
is there some non-yet-sent patches somewhere (e.g. contrib repo/branches) or has everything stalled hard
<qschulz>
I was asking for suggestions on the warnings since it seems you're "torn on how to implement [it]"
<ziga_>
@mckoan I added details regarding the distribution in the Stackoverflow as well.
<RP>
One gives nice line/file numbers for some cases. "Some" means core conf files bit not recipes
<RP>
but it is obviously more invasive
Etheryon has joined #yocto
<RP>
sadly, these errors don't actually stop the build either
<qschulz>
RP: I assume people are able to do a grep -R with the shown variable and find where it needs to be modified?
<RP>
qschulz: I hope so. There will likely be some script as well
<qschulz>
I would rely more on the migration manual to let people know how to deal with renames than tell them a rename has been made and what's the new name
<qschulz>
I'm also not 100% certain they will ALWAYS be a simple rename?
<RP>
qschulz: none of this automatically renames anything
codavi has joined #yocto
<qschulz>
RP: it does show the new name though
<RP>
qschulz: yes, that seems like something helpful we can do
<qschulz>
the other question is: is this mechanism supposed to be used later on or just for this specific case of "bulk" renaming?
<qschulz>
meaning, should we (you :/) spend time crafting something nice that will be ditched in 3.6?
<RP>
qschulz: there is probably a second class of vars which are just obsolete and not used, those could probably have a string value to show
<RP>
qschulz: I suspect this won't be the last time we have this issue so the mechanism will likely stay
<qschulz>
RP: are we supposed to keep compatibility for one release or more for the renames (I remember seeing something like this for PN_BLACKLIST rename)
<RP>
qschulz: depends how you define compatibility
<qschulz>
in which case, we just keep a list of deprecated variables and show a warning to the user and redirect to the docs
<RP>
What *really* annoys me is this is the stuff people should have been working out. Change is hard and requires work to make it happen
<qschulz>
and basically do a mapping between the old and newer name
<RP>
we simply cannot do an automatic conversion
<qschulz>
RP: nope
ar__ has joined #yocto
<qschulz>
RP: I didn't think this would be something we'd look into, I was more into the thought that we 1) do a simple rename with no warning or compatibility 2) have a warning+compatibility implemented for *each* change
<qschulz>
I didn't think we'd go for a global mechanism tbh
<qschulz>
(I was not part of the discussions, just to be clear, this might have been discussed)
<qschulz>
the issue for my 2 points is that we need to keep track of renames and have the documentation up-to-date
codavi has quit [Ping timeout: 252 seconds]
<qschulz>
I'm not sure I'm helping or making everything worse here :|
<RP>
qschulz: There is little point in doing this on a case by case basis since we're going to have to have some kind of standard detection/warning mechanism
<RP>
unless we want it done badly several times over
superdupond has joined #yocto
<Etheryon>
so: I found my files in build/tmp/work/all-poky-linux/resources/0.1-r0/image, is this correct?
<Etheryon>
resources/0.1-r0/temp/log.do_install does not contains the output for ls -l
<qschulz>
RP: If I understood correctly, the problem here is that the renamed variables show an error but don't stop the build
<qschulz>
Etheryon: yes this seems about right
<Etheryon>
ands that folder would be ${S} ?
<qschulz>
RP: honestly, I'm not sure I would be able to suggest any code implementation so I might be taking some of your time for no real benefit other than roleplaying the rubber duck :/
<qschulz>
Etheryon: no, that's ${D}
<RP>
qschulz: that is one of several issues. I'm going to have to write this up for the list
<Etheryon>
so now I'd need to move them from ${D} to ${D}${bindir}/resources as part of do_install?
<Etheryon>
how does this translate to where they go on the resulting image?
<qschulz>
layout in image directory is the layout on the root filesystem
<Etheryon>
do_rootfs is the task that copies them over?
<qschulz>
not really no
<qschulz>
first, I'd say you need to inherit bin_package before your do_install
<Etheryon>
so now that they're in ${D} they're basically in / on the resulting image?
<qschulz>
I'm not sure bin_package's custom do_install does not override the do_install you wrote
<qschulz>
so inherit it before you redefine do_install just to be sure (and it's also best practice anyways)
<Etheryon>
ok cool
<qschulz>
Etheryon: more or less yes, there's an intermediary step first, the packaging step
<Etheryon>
so I did that, now image has the folder structure I'm expecting, but the files are gone
<qschulz>
which splits the content of image directory of your recipe into multiple packages
<qschulz>
then IF your image recipe pulls a package, the files from the package, respecting the layout in image will be installed
<qschulz>
(technically, it's the layout in package-split/<package> and not image, but they are the same)
<qschulz>
Etheryon: yup, because your install -d ${S} ${D}${bindir} does not do what you think it does
<qschulz>
use cp -r instead
<qschulz>
(IIRC install -d will just create the directory if it does not exist but not copy its content over)
<Etheryon>
thanks!
<Etheryon>
so ${S} is EXTERNALSRC ( did an echo)
<Etheryon>
and I'm now copying from there to D
<Etheryon>
value of EXTERNALSRC
zpfvo has quit [Ping timeout: 272 seconds]
zpfvo has joined #yocto
<Etheryon>
cool, so I've got the image folder inside my recipe looking like what I would need. But when I try to build an image I get this error now: package_write_rpm not found in ...
<Etheryon>
I've added the recipe to IMAGE_INSTALL
<Etheryon>
maybe that's wrong
<RP>
qschulz: I emailed oe-arch with some details
<RP>
I'm sure there are 101 other issues I haven't thought of yet :(
<qschulz>
Etheryon: just a technicality, but you add a *package* to IMAGE_INSTALL and not a recipe (though the name of the main package is the name of the recipe)
<qschulz>
Etheryon: we'll need the whole build log posted in a pastebin somewhere (any website is fine)
<qschulz>
and the full content of the recipe too while we're at it
<agherzan>
For this case, A is unconditionally set to “Z” and “X” is unconditionally and immediately appended to the variable A:foo. Because overrides have not been applied yet, A:foo is set to “X” due to the append and A simply equals “Z”.
<agherzan>
The confusing part (or maybe even wrong) is `“X” is unconditionally and immediately appended to the variable A:foo.`.
florian_kc has quit [Ping timeout: 252 seconds]
<RP>
agherzan: that language isn't brilliant :/. The trouble is people think differently about how this works. I think several people keep changing this to fit how they prefer to think about it
<RP>
michaelo: ^^^
<agherzan>
The problem is with `immediately`. Which is not true, is it?
<agherzan>
Unless I'm reading this wrongly.
<RP>
well, it isn't immediately done but effectively it is as it cannot be undo and would always happen
<agherzan>
OK I see the intentions here.
<agherzan>
The problem is that it seems to contradict 2 lines above
<agherzan>
Where it says
<agherzan>
`Recall that an append or prepend operation using “:append” and “:prepend” does not result in an immediate assignment as would “+=”, “.=”, “=+”, or “=.”. `
<agherzan>
Where this becomes confusing.
<qschulz>
agherzan: I would remove immediately yes
<qschulz>
but I think we should just rephrase the whole document
<agherzan>
I agree.
<agherzan>
And you had a good talk on that matter.
<qschulz>
I've said I'd look into this about a year ago already
<agherzan>
I really think we should prioritize this because it is a constant pain to newcomers.
<RP>
please someone send patches!
<Etheryon>
qschulz: here is the full error, recipe is what I've posted earlier with the modifications we've talked about
<Etheryon>
ERROR: Manifest /mydir/build/tmp/sstate-control/manifest-x86_64_x86_64-nativesdk-app-resources.package_write_rpm not found in genericx86_64 core2-64 x86_64 allarch x86_64_x86_64-nativesdk (variant '')?
<Etheryon>
I'm guessing it's looking for a package_rpm step, that doesn't happen in the recipe? (because of bin_package?)
<qschulz>
Etheryon: what exactly is the command you're running to get this error?
<qschulz>
I'm surprised it mentions anything about nativesdk
<Etheryon>
task that fails is : my-image.bb:do_rootfs
<Etheryon>
TOOLCHAIN_HOST_TASK += "\
<Etheryon>
nativesdk-cmake \
<Etheryon>
nativesdk-meson \
<Etheryon>
"
<Etheryon>
this is the only mention I have of nativesdk in my image
<Etheryon>
tbh not sure what this does
<Etheryon>
If I want that resources recipe to be depended on by another recipe it needs to be an RDEPENDS, right?
<qschulz>
Etheryon: runtime dependency yes, otherwise DEPENDS for build time dependencies (but I assume media files will probably be runtime dependencies, so yes, RDEPENDS)
<Etheryon>
thanks
<Etheryon>
any suggestions what should I start looking into for this package_rpm issue?
Guest47 has joined #yocto
<agherzan>
RP: qschulz I was talking to zyga_ about this the other day and I think that having this done through the eyes of a person new to the project would end up having the best outcome (obviously under and subject to later review). The advantage of this is that a newcomer might end up raising issues that we would miss as implicit. And Zyga is willing to push patches while untangling the syntax and operators in bitbake for his own learning process.
<agherzan>
What do you think?
* zyga[m]
waves
<Etheryon>
Lemme know if I can help, I'm new too
<RP>
agherzan: it is something we used to do and yes, new eyes do tend to spot issues others would not. I'm open to it
<qschulz>
The issue with that is that the moment he's untangled the syntax and operators, he's not a beginner anymore
<qschulz>
ideally, we'd need someone who's never laid eyes on this review patches
<qschulz>
and tell us "this I don't understand first time I read"
<qschulz>
but maybe I'm pushing it too far already :)
<zyga[m]>
I can share some of the feedback as a relative newcomer
<RP>
qschulz: whilst not perfect, it could be useful to look at that feedback
<zyga[m]>
for the various variable manipulation operators, the difference between += .= and :append is very confusing
<agherzan>
It's a hard one because those people would not know if it is something that they missed or it is really lack of docs. And as I newcomer you would not be comfortable in clarifying this with an entire community. And yes, while they dig deeper, the quality of having new eyes will dim.
<zyga[m]>
semantics aside, the fact that += and :append do very different things is confusing
<agherzan>
zyga[m]: indeed. And I've given an example above.
Guest47 has quit [Client Quit]
<zyga[m]>
syntax wise I would make += and :append identical and introduce a new keyword: say, "late" to make += behave as :append does now
<zyga[m]>
but apart from me being grumpy sometimes, I think I could help with the docs
<qschulz>
zyga[m]: can't have :late because you also have a :prepend one
<RP>
zyga[m]: There have been a few discussions about the append vs += issue. Sadly it is far from simple
<agherzan>
^ that is not a bad idea at all. My focus though at this point is to make the current state clear in docs. Or clearer. And improvements discussed either in parallel or afterwards.
<zyga[m]>
I'm sure I'm missing a lot, my point was to not overload what reads as a pretty standard operation (concatenation or appending) with extra hidden meaning that is unique to yocto/bitbake - to reduce the surprise factor
<qschulz>
agherzan: I would basically send a new page for review, the diff does not matters much for that
<agherzan>
But the problem of += and append needs to be improved somehow.
<RP>
zyga[m]: I did start to try and simplify things with the override syntax change and dropping operators with append/prepend (so :append += "" isn't legal now)
<zyga[m]>
RP: I agree it's not simple at all, especially for a well established project
<zyga[m]>
I like that, that's a good step
<agherzan>
qschulz: Agreed. And that can be easily managed in something like GitHub where you can see the entire file.
zpfvo has quit [Ping timeout: 272 seconds]
<agherzan>
So before doing the ml diff we can have an initial look at the entire document.
<qschulz>
agherzan: I just need to kick my own butt and get started
<zyga[m]>
qschulz: actually append is not bad, it's just that it's quite different from what appending to a list does in other languages that is confusing; in that sense prepend and append are prefectly fine, except for their "late" behavior that is surprising at first
<agherzan>
qschulz: work with zyga[m] on this. He had a lot of good questions while figuring this out.
<RP>
zyga[m]: I'm open to other ideas on syntax improvement but we have to do it in a way with some kind of migration/compatibility
zpfvo has joined #yocto
<zyga[m]>
RP: I agree and understand, while radical on clear design I'm also radical on backwards compatibility
* RP
is sad he never got back to trying to work out the next steps
<zyga[m]>
I realize that the feedback is not easy to make practical use of
<qschulz>
zyga[m]: as agherzan stated before, it's hard for us to have better doc because most of us contributing to the docs have some understanding and we forgot about our early struggles. And people starting on Yocto (or any project) usually don't give feedback on their struggles
<zyga[m]>
is there a non-late prepend operator similar to +=?
<qschulz>
zyga[m]: =+
<qschulz>
and -.
<qschulz>
=.
<zyga[m]>
so it's possible to have :append and :prepend retain their semantics
<qschulz>
zyga[m]: there is not duplicate behavior right now unfortunately
<zyga[m]>
while introducing something new like: late FOO += ... and late FOO =+ ... - where late would make this identical to :append and :prepend respectively
<zyga[m]>
and couple that with weak deprecation of :append and :prepend - this would leave just one set of operators with either immediate or late semantics
<zyga[m]>
again, my idea is just back-of-the-envelope draft
<zyga[m]>
I'm trying to find a way to reduce overal complexity
zpfvo has quit [Ping timeout: 272 seconds]
<Etheryon>
qschulz: PACKAGE_ARCH = "all" <- this seemed to be the issue - removed it from the resources recipe and everything works now. Thanks a lot for all the help!
zpfvo has joined #yocto
<qschulz>
Etheryon: inherit allarch is probably what you're after
<agherzan>
I'm going to test drive this for a while but I'm thinking to turn the most bits into GitHub actions that Yocto-base projects can reuse - for example build configuration through CI yml, yocto layer check, git log linter, DCO/SoB check and so on.
<agherzan>
Happy to hear feedback
<LetoThe2nd>
agherzan: sounds interesting, hopefully can poke it soon (very busy this week)
<agherzan>
I'm yet to do the git log linter - and I want to do it as a wrapper on top of gitlint. Make that an action and based on that create another one with the git log general guidelines for Yocto/OE projects LetoThe2nd
<agherzan>
The current implementation does DCO check, reuse check (non fatal as the layer is not yet compliant) and matrix based builds.
mvlad has joined #yocto
zpfvo has quit [Ping timeout: 250 seconds]
<agherzan>
Oh - and yocto script layer check
zpfvo has joined #yocto
Etheryon has quit [Quit: Client closed]
Etheryon has joined #yocto
<Etheryon>
any way I can avoid having packages-split and image duplicate my files?
<qschulz>
Etheryon: no, that's how Yocto works internally. What's the issue?
smsm has quit [Quit: Client closed]
prabhakarlad has quit [Quit: Client closed]
<Etheryon>
files large - two copies larger
Schlumpf has quit [Quit: Client closed]
<RP>
agherzan: One the one hand that is all nice and good. On the other, it would be lovely if we could reuse some of our existing checks and get patchtest back to help with core. But nobody seems to want to care/help with that :(
<agherzan>
RP: what existing checks do you refer to? I've included `yocto-layer-check` for example.
<smurray>
RP: is your issue wrt stopping when a renamed variable is seen that it doesn't stop on the first parse error? If BBHandledException is getting thrown I'm not sure I see how a build would proceed
<RP>
smurray: where is that being thrown? I do have a local fix which may improve this, was just working on that
<agherzan>
RP: I see. Well - what can I say? I didn't know about that :) But I think that would definitely make more sense
<smurray>
RP: if I switch to bb.fatal in my tree it does, I'd guessed your erroronce would do so as well
<RP>
smurray: it doesn't, erroronce shouldn't be fatal as it would only show the first error
<smurray>
RP: hrm, if it's not going to halt things then I'd maybe say erroronce seems redundant?
<smurray>
RP: in the grand scheme of things it almost seems like just going with a check in CookerParser.shutdown like I had to begin with seems easier than worrying about per-file and erroronce even if it's less optimal
<RP>
smurray: you misunderstand how the errors/exceptions works :/
<smurray>
RP: I'm willing to believe that, sure
<RP>
smurray: see the tweaks to ast.py in my branch, I have that working now (show all the errors, stop the build)
prabhakarlad has joined #yocto
<RP>
smurray: next, to deal with XXX:foo:append where XXX is deprecated
<smurray>
RP: that's not resolved bythe end of parsing?
zpfvo has quit [Ping timeout: 250 seconds]
zpfvo has joined #yocto
Schlumpf has joined #yocto
sakoman has joined #yocto
<RP>
smurray: yes and no. I'd just prefer to tell people about any bad references
<smurray>
RP: that'd maybe seems like it'd only be useful with option (c) that can get the file/line no, I'm guessing?
<RP>
smurray: I'd have thought it would be generally useful
pasherring has quit [Remote host closed the connection]
pasherring has joined #yocto
<JPEW>
RP: I had my head stuck in a problem yesterday; I don't know why I didn't offer to just build MinGW binutils to see if it's taking a long time locally. Doing that now :)
<RP>
JPEW: I was thinking I should really just profile a build of it and see what was taking the time.
<RP>
JPEW: my worry was that the change isn't to the parallelism of bintuils, its to the mingw runtime
<RP>
JPEW: so my bug report didn't make sense unless the runtime was taking a long time and I'm not sure it was that, it could have been qemu
<RP>
I then wondered if I knew what I was doing at all (I'm still wondering that)
<zeddii>
RP: with AMD -> Xilinx yesterday, the day was kind of messed up. But I'm building the binutils -> ppc combo now. Assuming we still need to identify a fix. I'll do that when I see it go boom (lots of rebuilding right now, it was on an out of date machine of mine).
<RP>
zeddii: I replied to the mails confirming there is the single patch we need
<zeddii>
oh. I must have missed that. I'll go check.
<RP>
zeddii: that fixed the builds at least for my local tests
<RP>
zeddii: I figured you were busy so I just queued stuff
<zeddii>
ahah. I see that now. I didn't even notice it when it came in. I'll send a SRCREV bump in just a few minutes then.
Etheryon has quit [Quit: Client closed]
<JPEW>
RP: Ok, I'm doing a build with buildstats. I'll report back what I see
<RP>
JPEW: thanks. I think it may just be a combination of old sstate and loaded autobuilder
<RP>
smurray: I was curious why in your version you didn't put the calls at the end of finalize() ?
davidinux has quit [Ping timeout: 252 seconds]
xmn has joined #yocto
davidinux has joined #yocto
Schlumpf has quit [Ping timeout: 256 seconds]
<smurray>
RP: when I went and looked at expandKeys it wasn't clear to me if it'd make a difference, and then it was working in my tests so I didn't investigate further
Etheryon has joined #yocto
Schlumpf has joined #yocto
<RP>
smurray: it could if someone does A = "HASHBASE" then BB_${A}_WHITELIST = "B" :)
<RP>
If someone did that I would suggest medical attention mind :)
<smurray>
RP: heh, indeed. I figured expandKeys was related to that, but wasn't sure if it'd be a real issue or not
<RP>
smurray: my bigger worry was one of the event handlers setting new things
<smurray>
RP: to some degree if someone is jumping through hoops like that in an external layer for the variables involved I'm not entirely sympathetic
Tokamak has joined #yocto
zpfvo has quit [Ping timeout: 252 seconds]
zpfvo has joined #yocto
goliath has quit [Quit: SIGSEGV]
zpfvo has quit [Ping timeout: 250 seconds]
zpfvo has joined #yocto
<Etheryon>
Hey, I'm back, any easy way of solving "rootfs size is greather than or equal to 4GB" ?
<Etheryon>
not sure where hddimg comes from
<Etheryon>
I have IMAGE_FSTYPES = " live"
<Etheryon>
I guess from here: DEPLOYABLE_IMAGE_TYPES="hddimg iso"
<Etheryon>
hmm or here? IMAGE_TYPES_MASKED=" live hddimg iso"
<RP>
smurray: this is the challenge with core API though, it will end up used for things you never considered :/
marc2 has quit [Ping timeout: 250 seconds]
marc2 has joined #yocto
<smurray>
RP: I think I'm in the "perfect is the enemy of good" camp on this at least wrt getting over this immediate hump with the inclusive language changes finally done
* RP
is being called away to small crisis outside work :(
<dacav>
Hi. Is there a way to invalidate the cache of an image recipe without rebuilding the whole universe?
<RP>
Status report will be delayed, will do my best to make the weekly call
<smurray>
RP: okay, good luck with whatever is going on
<qschulz>
dacav: what is your issue right now? what are you trying to do that would require invalidating the image sstate-cache?
<dacav>
I'd like to update a busybox configuration, to obtain another utility. After I changed it, I should be able to rebuild the image with `bitbake myimage`, right? Nope. The image is not rebuilt.
<zyga[m]>
RP: just thinking about append vs += and other operators, why :append and not .append? Why not treat it more like a typed python object that just renders to a string?
<dacav>
At this point I spent so much time trying to make sense of this mess of system roots, that I just nuked the whole thing from orbit, got rid of 50 gigabytes and more of builds, and I'll let my computer spin for a few hours.
zpfvo has quit [Ping timeout: 272 seconds]
<qschulz>
dacav: won't work
zpfvo has joined #yocto
<qschulz>
if a bitbake myimage does not trigger a rebuild of your busybox recipe, a clean rebuild won't either
<dacav>
I nuked via `git clean -fxd`. It *will* work :)
<dacav>
Yet I'd be curious to know what is the proper way of doing what I'd like, that is, updating a dependency and have the whole change propagated properly
<qschulz>
dacav: it is, so you are doing something wrong
zpfvo has quit [Ping timeout: 250 seconds]
<qschulz>
I would expect a change to busybox config to trigger A LOT of dependency rebuilds
zpfvo has joined #yocto
<dacav>
of course I am. With that being said, having a system that is not a jungle might help, and I'm working in a quite broken situation to begin with.
<dacav>
Starting clean won't be bad.
<dacav>
Moreover, it works for a colleague, so it is definitely true that something is wrong for me
<dacav>
When you've gigabytes of files around, go figure *where* the problem is
<qschulz>
dacav: might be something wrong in your expectations. Didn't mean to be rude sorry
<qschulz>
so.. what did you do? What is happening? What did you expect to happen?
<qschulz>
and "wrong" is a strong word too, not good at picking the right words today :/
<dacav>
Not your fault man. Actually, you're always very helpful.
<dacav>
Strong or not, it is correct. There must be something wrong. Or rather, there was :D
<dacav>
nuke -> there's nothing wrong.
<dacav>
:D
<qschulz>
dacav: if nuking works, something's wrong :D
<smurray>
dacav: usually I'd expect the approach to be to add a .cfg fragment turn on a busybox option to SRC_URI in a bbappend in my own layer, and I would expect that to trigger a rebuild unless there's a typo
<dacav>
qschulz: Interestingly it is also true that if something's wrong, nuking works!
<dacav>
- typically -
<smurray>
dacav: looking at the output of "bitbake -e busybox" to see what the state of SRC_URI (or other variables) is can be useful to help debug
<dacav>
smurray: in this case the .cfg fragment existed already
<smurray>
dacav: if it's in SRC_URI and you changed its contents in your layer, I'd expect that to be seen and trigger a rebuild
<dacav>
I'll check out later. Now I'm in the middle of a full rebuild (see above, I nuked the whole thing and started over, out of dispair)
<dacav>
s/dispair/despair/
<qschulz>
dacav: usually you can just keep the sstate-cache and downloads directory and ditch the rest
<qschulz>
it's not really a clean build but at least you don't lose hours rebuilding stuff from scratch
<dacav>
Actually, I've explicitly nuked also sstate. In my case I might have the additional burden of two teams working on the same yocto repository, with different ways of working and generating configurations.
<dacav>
I wouldn't be surprised if the oracle told me there was a funny overlapping frustrating my attempts. I don't know what sstate-cache is caching.
<dacav>
I'll leave it compiling and do something else. Thanks for your hints and for your time :)
tnovotny has quit [Quit: Leaving]
falk0n[m] has quit [Quit: You have been kicked for being idle]
Etheryon has quit [Quit: Client closed]
Thorn has joined #yocto
prabhakarlad has quit [Quit: Client closed]
dsueiro has joined #yocto
goliath has joined #yocto
<dsueiro>
I have a couple of image recipes that depend on specific DISTRO_FEATURES values. I'm making usage of the features_check bbclass and setting REQUIRED_DISTRO_FEATURES and CONFLICT_DISTRO_FEATURES. And it all works as expected. My problem is that whatever I change the DISTRO_FEATURES values, the incompatible image built previously with the expected
<dsueiro>
DISTRO_FEATURES, gets removed from the DEPLOY_DIR_IMAGE. I'm just wondering if there is a way to change this behaviour and prevent bitbake to remove images (skipped via bb.parse.SkipRecipe) from DEPLOY_DIR_IMAGE.
Minvera has joined #yocto
lucaceresoli has joined #yocto
camus1 has joined #yocto
camus has quit [Remote host closed the connection]
camus1 is now known as camus
zpfvo has quit [Quit: Leaving.]
<RP>
zyga[m]: ":" seemed like the least ambiguous choice for the character, "." didn't look/feel right. ":" also had the advantage that the parser never accepted it previously
<zyga[m]>
I see, that's indeed relevant
Schlumpf has quit [Quit: Client closed]
florian_kc has joined #yocto
chep has quit [Read error: Connection reset by peer]
chep has joined #yocto
chep has quit [Read error: Connection reset by peer]
chep has joined #yocto
chep` has joined #yocto
chep has quit [Read error: Connection reset by peer]
chep` is now known as chep
mckoan is now known as mckoan|away
huseyinkozan has joined #yocto
lucaceresoli has quit [Remote host closed the connection]
lucaceresoli has joined #yocto
florian_kc has quit [Ping timeout: 240 seconds]
florian has quit [Quit: Ex-Chat]
<JPEW>
RP: nativesdk-mingw-w64-runtime took 251 seconds on my machine with PARALLEL_MAKE="", which doens't seem terribly unreasonable?
Etheryon has joined #yocto
<RP>
JPEW: that seems ok
<RP>
JPEW: I wonder if it was just the new binutils causing qemu to rebuild which took ages?
<JPEW>
qemu can be really slow
<JPEW>
anecdotally at least
ex-bugsbunny has quit [Ping timeout: 240 seconds]
Guest20 has joined #yocto
<Guest20>
Hi, in my pytorch-native.bb recipe, I install the bin mkalias. It appear in build/tmp/work/x86_64-linux/pytorch-native/1.9.1-r0/recipe-sysroot-native/usr/bin/mkrename But this bin doest not appears in sysroot-native of pytorch.bb. Am I doing something wrong?
pasherring has quit [Quit: Leaving]
Guest20 is now known as miki26
Etheryon has quit [Quit: Client closed]
miki26 has quit [Quit: Connection closed]
Guest20 has joined #yocto
miki26 has joined #yocto
florian_kc has joined #yocto
camus has quit [Remote host closed the connection]
camus has joined #yocto
florian_kc has quit [Ping timeout: 252 seconds]
<sgw>
smurray: RP: I have some additional time to work on the bitbake changes, I will look at RP's email again, let me know where I can help more
<smurray>
sgw: if you are in a position to pick up moving the renamed variable detection along, please do so.
<smurray>
sgw: I didn't entirely grasp where JPEW and RP went with the hybrid checking discussion, but if it gets stalled somehow, please let me know and I can attempt to figure it out, I guess
<sgw>
smurray: I will take a look at your code also then and see what I can do there, your not alone on some of the discussion.
camus has quit [Ping timeout: 240 seconds]
camus has joined #yocto
<smurray>
sgw: for the variable renaming, if you want to test the better option would be RP's improved version he mentioned in his email to oe-arch, rather than my WIP that's the HEAD of that branch
<smurray>
sgw: renamed variable checking, I mean
<sgw>
I am going to look at both so that I can try and understand the ramifications of each.
ex-bugsbunny has joined #yocto
ex-bugsbunny has left #yocto [#yocto]
<smurray>
sgw: just note that RP rewrote my WIP, the link into poky-contrib for option (b) in his mail is that
s4d has joined #yocto
GillesM has quit [Remote host closed the connection]
amitk has quit [Ping timeout: 240 seconds]
florian has joined #yocto
camus has quit [Remote host closed the connection]
camus has joined #yocto
xmn has quit [Ping timeout: 272 seconds]
alimon has quit [Ping timeout: 252 seconds]
alimon has joined #yocto
Minvera has quit [Quit: Leaving]
lucaceresoli has quit [Ping timeout: 240 seconds]
kevinrowland has joined #yocto
<RP>
sgw, smurray: Sorry, I'm having a bad day. I'm wondering if people on the call noticed the point I found a scafolding truck blocking the narrow backlane I was driving down to get home. Trying to talk coherently whilst reversing a 4x4 around narrow backlanes whilst coherently talking about bitbake internals was a different experience :)
<smurray>
RP: ouch
<RP>
We mentioned the TSC, they've suggested I email the members about the issues so I need to write that email
<sgw>
RP: Well done on multitasking then!
<sgw>
Hope all is OK otherwise
<RP>
the scafolding truck is from all the roofing work being done after storm Arwen. D<something> and Eunice are due tomorrow and Friday
<RP>
sgw: complicated but dealing with the things life sends our way as best we can ;-)
<sgw>
I figured it was related to someone's roof. Hope you guys are all button'ed up and these new storms dont cause issues.
<RP>
sgw: only 90mph winds forecast this time
<RP>
the streets are lined with broken slate :/
<sgw>
ouch, stay safe.
<RP>
sgw: Storm C<something> did pull some of the rainwater piping off the back of the house, it is proving a fun winter!
<sgw>
RP I am starting to look / understand your changes, but I am still not clear on the overall direction, and did not really follow the discussion you and joshua had.
<RP>
sgw: you can see in my branch I shared there are two different approaches? One is ast.py based and the other is in data_smart.py?
<sgw>
Yes, I have a call to take, back in 30 or so.
* RP
gives in and powers up his servers to try and work on this a bit more
<sgw>
RP: I know its getting late there, I should be on early in the morning.
<RP>
sgw: I'll poke at things a bit more, see if I can get more coherent patches
* RP
notes that according to the libtool list, we do cross compiling all wrong :/
lucaceresoli has joined #yocto
<smurray>
RP: hrm, I'm not sure I'd be willing to believe that, libtool has been it's own special form of hell whenever I've needed to try to debug an issue
mvlad has quit [Quit: Leaving]
<RP>
smurray: I don't believe it either but they're saying our patches which I cleaned up and submitted are wrong and that we're using libtool incorrectly
<RP>
android gets it right of course
* RP
will just ignore that for now
<RP>
I mean what do we know about cross compilers
<smurray>
heh
huseyinkozan has quit [Quit: Konversation terminated!]
frieder has quit [Remote host closed the connection]
s4d has quit [Quit: s4d]
smrtz has joined #yocto
smrtz has quit [Client Quit]
ar__ has quit [Ping timeout: 252 seconds]
marc2 has quit [Ping timeout: 252 seconds]
marc2 has joined #yocto
<RP>
JPEW: I was just looking at implementing what we talked about earlier. There is a big downside in that it would duplicate messages since one would have file/line numbers and the second pass would not
<RP>
JPEW: I think that rules it out as it would confuse people
<JPEW>
RP: that wasn't my understanding... First pass only checks the base config in a post parsing (e.g ast finalize?). It had line numbers because we include variable tracking. Second pass is after that and hooks getvar, so it has the line numbers?
florian has quit [Ping timeout: 252 seconds]
<RP>
JPEW: hmm, right.
<RP>
I'm confusing myself. I do now have the early environment checks at least...
davidinux has quit [*.net *.split]
madisox has quit [*.net *.split]
mrnuke has quit [*.net *.split]
shoragan has quit [*.net *.split]
Habbie has quit [*.net *.split]
zibri has quit [*.net *.split]
woky has quit [*.net *.split]
marex has quit [*.net *.split]
Ch^W_ has quit [*.net *.split]
ak77_ has quit [*.net *.split]
Fanfwe has quit [*.net *.split]
ak77_ has joined #yocto
marex has joined #yocto
zibri has joined #yocto
davidinux has joined #yocto
madisox has joined #yocto
mrnuke has joined #yocto
Fanfwe has joined #yocto
Ch^W_ has joined #yocto
woky has joined #yocto
Habbie has joined #yocto
shoragan has joined #yocto
<khem>
zeddii: linux-yocto is trying to use CONFIG_MAXPHYSMEM_128GB kconfig option perhaps this should be removed ? such option seems to not exist in latest kernel
<RP>
JPEW: it seems the base datastore isn't using history tracking. I could have sworn it did :(
leon-anavi has quit [Quit: Leaving]
<JPEW>
RP: too good to be true I guess :(
<JPEW>
Can we add tracking of just the line number? I thought history tracked a bunch of other stuff. Not sure what the expensive part is
Guest20 has quit [Ping timeout: 240 seconds]
miki26 has quit [Ping timeout: 256 seconds]
<RP>
JPEW: I think the behaviour is UI dependent so I may be able to force this
<JPEW>
Or maybe only track history for the free variables that are being renamed? If it's an error to not rename them, does parsing have to be optimally fast?
<JPEW>
*few variables being renamed
<RP>
JPEW: we can't know which ones have a problem with renaming until it is too late
<RP>
JPEW: I think I nearly have it working but now it looks like my erroronce implementation doesn't work
<JPEW>
Ok. I'm AFK for the rest of the day, but I'll try to take a look at that tomorrow
<RP>
JPEW: I'll try and put together some kind of example of where it is at
<RP>
That does seem to do roughly the right things locally, except for duplicating error messages (which it shouldn't)
<RP>
sgw, smurray: you may have to comment the environment bb.fatal to get anything to parse
florian has joined #yocto
<RP>
smurray, sgw: the best use of your time might be to get the renaming patches in place for the bitbake variables and check the errors are showing up before conversion
<RP>
I guess I'll worry about the duplicate errors tomorrow