<xixi>
The google search page guide says to modify /proc/sys/fs/inotify/max_user_instances, but this file is a read-only mount and cannot be remounted to rw.
goliath has joined #yocto
BCMM has joined #yocto
tnovotny has joined #yocto
zyga-mbp has joined #yocto
BCMM has quit [Remote host closed the connection]
<dl9pf>
xixi: check sysctl command and how you can set the value with it
neverpanic has joined #yocto
leon-anavi has joined #yocto
<frosteyes>
JaMa: Created the PR for the log files :)
eloi has joined #yocto
<eloi>
Hi guys, I have an issue with extrauserparams adding "read-only-rootfs" IMAGE_FEATURES. I can not use my parameters set in extrauserparams. The variable is correctly set adding debug in extrausers.bbclass
<eloi>
I tried to bind /etc volatile in a .bbappend. E.g "VOLATILE_BINDS_append = "/var/volatile/etc /etc\n"
<eloi>
I am wondering if exrausersparam works with read-only-rootfs.
<qschulz>
eloi: a bbappend for volatile-binds.bb I assume?
<eloi>
yes qschulz in recipes-core/volatile-binds/volatile-binds.bbappend
<eloi>
is it the right method ?
<qschulz>
don't know, but if it weren't done in a bbappend for volatile-binds, that was already an issue
xixi has quit [Remote host closed the connection]
LetoThe2nd has joined #yocto
<eloi>
yes qschulz extrausersparam should work with read-only-rootfs without requiring volatile-binds.
<eloi>
I really don't understand what is the root cause, I am trying to troubleshot that
<eloi>
My volatile-bind systemd service is correctly created. I can see it when removing read-only-rootfs.
<eloi>
Now I need to understand why I can not loging with my user params on read-only-rootfs :(
vmeson has quit [Read error: Connection reset by peer]
<paulbarker>
RP: Trying to look into the autobuilder failures with my prserv patch today, the output in the autobuilder log seems to be buffered so we're probably missing key info
<paulbarker>
It says that test took 1.10s but the line printed when the test starts (`wic.Wic.test_wrong_compressor (subunit.RemotedTestCase)`) and the line printed when the test finishes (`... ok`) are timestamped in the same millisecond
<RP>
paulbarker: the parallelism means that the logs are buffered and it only prints things when they've already completed
<RP>
paulbarker: I ended up stopping the hung builds but we can start a single selftest and see if that hangs?
<RP>
paulbarker: it is the last patch in the series since I left the others and no issues there. I guess that isn't a surprise though!
<paulbarker>
RP: I wonder if parallelism or the load pattern on the autobuilder is triggering a failure, I can't reproduce it myself here but I'm running on an otherwise unloaded machine and in single threaded mode
<paulbarker>
No surprise at all
<paulbarker>
I need to respin that patch anyway, I found some junk code leftover which is never called so it can be removed
<RP>
paulbarker: the parallelism would mean multiple tests running in parallel but in separate build dirs
<RP>
paulbarker: I can add the patch back and start a single selftest if that would help?
<paulbarker>
I'm currently testing another patch to add timeouts to asyncrpc on the client side when it's waiting for a response from the prserver
<paulbarker>
I'll do a bit more testing here first then we can try that if I don't find anything useful
<RP>
paulbarker: ok, just let me know
<paulbarker>
I expect running just the prservice tests would be enough to see a failure
<RP>
paulbarker: actually, I can trigger it now as it will take a while. We can cancel if not needed
<paulbarker>
Ok, let me send a couple of updated patches
<paulbarker>
Thanks, I'll grab a coffee then see if it's getting anywhere
<eloi>
regarding my issue with read-only-rootfs, I see that "base-passwd shadow" are set in ROOTFS_RO_UNNEEDED variable. That is the reason why my extrausersparams are not used
<RP>
paulbarker: it does normally take a few hours :/
<paulbarker>
RP: Multiple coffees!
<eloi>
I miss the reason why base-passwd shadow packages are removed on read-only rootfs ?
<RP>
eloi: what would you use them for on a read only rootfs?
<eloi>
RP: I am appending users with extrausersparam. If I use read-only rootfs, my added users/config seem not taken in account
<eloi>
RP: I have something "working"inch adding /etc in volatile-binds and remove passwd and shadow from ROOTFS_RO_UNNEEDED
<eloi>
I might be wrong in the way I am resolving that. The overlay on /etc/ should help. I will try to remove it.
<eloi>
But I believe it is fine to keep a package on RO system. It is not incompatible
<RP>
eloi: If I read that email correctly, you're basically saying that if you make the readonly image read-write again, it doesn't work as a read-write image and that is really to be expected
<RP>
eloi: read-only-rootfs with extrausersparam probably simply hadn't been tested and probably don't quite work together. That could be a bug
<eloi>
no exactly RP. I have a RW image with extrausersparam fully working (I print as debug the variable in extrauserparam.bbclass). When switching to RO, the variable is correctly set in .bbclass but I can not connect with my user.
<eloi>
Yes I see a bug but I am not sure what is the issue/solution.
<eloi>
First I want to understand why shadow and passwd pkgs are removed in RO. It is fine to keep them even the filesystem is RO, nop ?
<RP>
eloi: it was just an efficiency thing, it probably is ok to leave them
<RP>
eloi: I'd suggest filing a bug in the bugzilla for the issue
<RP>
No fix promised but means we can at least track it
<eloi>
sure RP. I will do that. I will discuss about the issue internally to provide as much investigation as we could. Thanks for your help :)
kpo has quit [Read error: Connection reset by peer]
kpo has joined #yocto
eloi has quit [Ping timeout: 264 seconds]
<JPEW>
RP: FYI that SDE patch will rebuild everything
<JPEW>
If you didn't already figure that out :)
<RP>
JPEW: I kind of guessed but it looks like a great fix, thanks!
<RP>
JPEW: were you able to reproduce or was it just by deduction? Nice to get rid of another race regardless!
<JPEW>
Deduction, but fairly obvious once I sat down and gave it a good look
tnovotny has quit [Quit: Leaving]
<yates>
is there a definition of all (or most) of the smart data variable names which can ba d.getVar'ed in "d"?
<yates>
i.e., how to see all variables in <bb.data_smart.DataSmart object at 0x7fcb1837fa90>
<yates>
i want to put insert a simple python task that will report various information about the configured kernel when a target image is being built
goliath has quit [Quit: SIGSEGV]
rob_w has quit [Quit: Leaving]
<qschulz>
yates: recipe data is local to the recipe
<qschulz>
so you can only do this from the kernel recipe
<qschulz>
and it won't know for which image recipe it's being built
<qschulz>
(just so you don't get your hopes up :) )
kergoth has joined #yocto
<RP>
yates: d.keys() but be warned that is a slow operation
<yates>
RP: thank you
kergoth has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
zyga has joined #yocto
paulg has joined #yocto
zyga has quit [Quit: Leaving]
tnovotny has joined #yocto
<yates>
i've noticed there is often a task do_xyz_setscene(). what is this used for? what is a "scene"?
* yates
resists the temptation to constructively criticize the documentation, unless someone requests my thoughts
<qschulz>
yates: if it's constructive, critics are very much welcome
<yates>
qschulz: thank you. let me gather my thoughts and try to be concise
<qschulz>
yates: if there's much to say, please send a mail to the docs mailing list so it's easier to discuss and you don't need to strip it down too much
<yates>
that sounds like a great idea.
<qschulz>
eager to read what you've to say
<yates>
so here? docs@lists.yoctoproject.org
<qschulz>
yup, you need to be subscribed first to send a mail though
<yates>
+
<yates>
+1
kpo has quit [Ping timeout: 272 seconds]
kpo has joined #yocto
goliath has joined #yocto
sakoman has joined #yocto
fitzsim has joined #yocto
eloi has joined #yocto
<eloi>
is it possible to append VOLATILE_BINDS in a bbclass ? I can with a bbappend but VOLATILE_BINDS_append_pn-volatile-binds = "foo bar\n" in my bbclass does not work
<qschulz>
eloi: recipe data is local. classes inherited in recipes are local, so VOLATILE_BINDS_append_pn-volatile-binds does not mean much
<qschulz>
eloi: with the bbappend you had, just run bitbake -e "volatile-binds" | grep "^VOLATILE_BINDS=" and see if it has the content you want
<qschulz>
sorry, no quotes around the first volatile-binds
<eloi>
my bbappend works perfectly qschulz, I would juste prefer to gather all my modifications in a bbclass that I can optionnaly inherit
<eloi>
I would need probably to define a machine specific and apply this bbappend for a specific machine
<qschulz>
eloi: that's fine, a simple VOLATILE_BINDS_append = "foo var\n" in the class would do, and you only need to comment/uncomment inherit your-class in your kernel recipe
<qschulz>
eloi: you cannot apply a bbappend for a specific machine, but you can make the recipes within a bbappend machine specific
<qschulz>
make the variables*
<eloi>
qschulz: yes that's what I mean
<eloi>
"VOLATILE_BINDS_append = "foo var\n" in the class would do" nop it does not work
<qschulz>
it should, what exactly did you do for that specific try
<qschulz>
what's the name of the class, did you inherit it in the kernel recipe, if in a bbappend, are you sure the bbappend is parsed, no typo in VOLATILE_BINDS_append?
<qschulz>
etc...
<qschulz>
best would be the code snippets in a pastebin
<eloi>
you should not deal with that in your kernel recipe
<qschulz>
not kernel sorry
<eloi>
it is my image recipe
<qschulz>
same
<qschulz>
can't do it in the image recipe
<qschulz>
recipe data is local
vmeson has joined #yocto
<eloi>
so where then could I inherit my class qschulz ?
<qschulz>
did you inherit it in the volatile-binds recipe* was remembering the previous discussion
<qschulz>
eloi: in volatile-binds
<eloi>
so it is exactly the same behavior than a .bbappend
<eloi>
I just want to optionnaly enable volatile-binds. It looks like I can not
<eloi>
Thanks for your help qschulz
<qschulz>
eloi: you would be able to via a new machine configruation file (and optionally do it directly in that file) or a new distro configuration file
<qschulz>
or local.conf
<qschulz>
by using the pn-volatile-binds you mentioned earlier
<qschulz>
this is fine because configuration files are not recipes, and they apply on the "global" scope
<fray>
I've got a problem with git fetching. I run a build, and it goes and fetches teh sources everything works.. update my layers a few days later.. and I restart the build. It skips the do_fetch since the SCMs are already local and then fails with a do_unpack "Unpack failure, No up to date source found: clone directory not available to or not up to date"
<fray>
this is with gatesgarth, and the one odd thing I have is that the upstream location (github.com) is excluded from download, but my local mirror is in the BB_ALLOWED_NETWORKS
<qschulz>
eloi: also, you can do conditional inheriting via inline python IIRC (inherit ${@some-class if var else ''}, something like that)
<fray>
so for some reason it doesn't run do_fetch?!
<qschulz>
fray: shouldn't your local mirror be in PREMIRROS or MIRRORS in local.conf?
<fray>
it is in _both_
<fray>
like I said, it doesn't even seem to run do_fetch, this is the part that is really confusing the hell out of me
JaMa has quit [Quit: reboot]
<fray>
but even if I wipe my tmpdir.. it still fails in the same way.. I have to remove the local copy of the git repositories from downloads/git2
<fray>
then it refetches from my mirror and continues.. I wasted all of yesterday on this issue, and I still can't figure out what is actually happening..
<fray>
I may try to come up with a 'small' reproducer, and then see if this is still happening in master..
<fray>
at this point I'm having to rm -rf downloads and tmpdir before each build.. which is obviously "suboptimal"
<eloi>
qschulz: inerhit my bbclass in distro works ;) Thanks
kergoth has joined #yocto
kergoth has left #yocto [#yocto]
kergoth has joined #yocto
kergoth has quit [Ping timeout: 252 seconds]
kergoth has joined #yocto
<RP>
fray: does sound like a bug in the fetcher code and network exclusion somehow :/
<frosteyes>
Hey. is there anyone who have used meta-xilinx-tools, and the xsct part for creating a barebone app to the 32 bit R5 of a ZynqMP?
<frosteyes>
Will ask on Xilinx forum (because it of cause is xilinx specific yocto solution) but would just ask here also.
<RP>
kergoth: I'm trying to fix the fetcher to allow cleanup of the file from previous runs and it is driving me a little crazy. I can't decide how much pain we might be willing to take to make this work better :/
<RP>
(the commit message is from an earlier version so ignore the bits that don't match)
<qschulz>
RP: I'll watch with great interest as this was an issue in my company last week too :)
matrixbridge12 has joined #yocto
matrixbridge12 has left #yocto [#yocto]
matrixbridge12 has joined #yocto
matrixbridge12 has left #yocto [#yocto]
<RP>
qschulz: I don't know if I can face fixing all the fallout from this
shoragan[m] has joined #yocto
<qschulz>
yeah that will break many things I foresee
<qschulz>
the simple do_install which takes files from ${WORKDIR} for example
<RP>
qschulz: the patch above does avoid that by having magic symlinks
<qschulz>
RP: my brain just ignored those lines for some reasons
<RP>
currently it breaks anything using "find ${S}" since we mean "find ${S}/" when S is a symlink
<qschulz>
oof
<qschulz>
I also think there'll be an issue with rm_work
<RP>
rm_work *is* an issue ;-)
<qschulz>
I don't know why I said that... rm_work is more or less doing what you did for the unpack task here I guess
<qschulz>
anyway, /me nitpicks. I'd actually see ${WORKDIR_LOCALFILES} instead of WORKDIR_SOURCES
<qschulz>
or something along those lines
<qschulz>
because sources will actually be in ${S}
<kergoth>
Hmm, guess we could also unpack to WORKDIR_SOURCES, find > filelist, move them into WORKDIR, and clean up the files from fileslist, along the lines of how sstate is used, but that'd potentially have a performance impact..
<khem>
yeah
<RP>
kergoth: there are lots of tricks we could play, I'm just not sure where the point where we force recipe changes is :/
<kergoth>
alternatively, we could try to force S to the real underlying correct value where it's used, but that'd be rather brittle since we'd need task prefuncs to ensure we catch everything
<JPEW>
RP: If we are going to force changes, this would be the release to do it
<RP>
kergoth: I know you wondered about redesigning the fetch/unpack/patch stage but we never did come up with a design...
<kergoth>
Yeah.. been wanting to do that for years, but we really need to document the requirements fully to ensure the design satisfies them all
<RP>
kergoth: I guess if we did that in the base.bbclass anon python that could work
<kergoth>
non-trivial
<kergoth>
True. I doubt many recipes are setting S with anonymous python
<kergoth>
at least i'd hope not
<RP>
kergoth: it is non-trivial. I'm amazed at how differently recipes are using ${S} even in a handful of recipes in core
<kergoth>
that's the downside to our flexibility, folks *can* do whatever, so they do :)
<RP>
I was looking at ${WORKDIR}/temp again and thinking that could do with a rename for the millionth time
<RP>
JPEW: this is partly why I'm thinking about it now
<paulg>
RP at least it isn't "foo" or "bar"....
* paulg
idly wonders why the workdir one got a vowel and the toplevel one didnt....
<RP>
paulg: so we could tell which people were talking about? :)
<zeddii>
more cash during that round of wheel of fortune
<kergoth>
RP: it'd slow cleanup, but another option would be to hardlinktree the unpacked bits into workdir, then use the parallel tree to know what to clean up. again with the performance impact, though.
<kergoth>
or go even further, and implement an unpacked source cache, checksum based, which hardlinktrees over in do_unpack from a common base, which would give some of the benefit of work-shared transparently
* kergoth
shrugs, throwing ideas around :)
<JPEW>
RP: Stupid question: Why not define S as "${WORKDIR}/${BP}/"
<kergoth>
would be along the lines of sysroot-components, really, but for unpacked sources
<RP>
kergoth: The unpacked source cache does sound like the kind of crazy thing I'd do :)
<kergoth>
well, recipes overwrite S, that'd be hard to pull off
<JPEW>
Oh right git
<shoragan[m]>
khem: ah, you bridged to matrix :)
<RP>
JPEW: lots of things override S with their own things
<khem>
shoragan: yes
<kergoth>
I always thought it'd be nice to avoid the need to define S at all by instead altering how the main archive is unpacked to strip off the leading path component, so the files end up where we expect anyway :)
<RP>
kergoth: that would be nice
sakoman has quit [Quit: Client closed]
<kergoth>
(which we coincidentally just removed from the fetcher since we never used that option :)
sakoman has joined #yocto
<RP>
every time I look at this I get so far in and then decide just to run away screaming...
<RP>
kergoth: I think it was also a bit broken :/
<paulg>
and here I thought that only happened to me when I strayed outside kernel...
<kergoth>
that wouldn't surprise me, considering we never used or tested it really.. :)
<RP>
kergoth: I think I tried to use it, realised it didn't work and removed it instead since clearly it wasn't being used
<RP>
easier to add something back with tests than fix/support what was there iirc
<paulg>
(actually there are plenty of run-away-screaming areas in kernel too ; BPF comes to mind...)
frieder has quit [Remote host closed the connection]
<RP>
JPEW: just thinking, fixing up ${S} would be a nice use of that filter stuff we talked about
<RP>
totally the wrong thing to do but... :)
tnovotny has quit [Read error: Connection reset by peer]
tnovotny has joined #yocto
JaMa has joined #yocto
JaMa has quit [Client Quit]
JaMa has joined #yocto
cody has joined #yocto
eloi has quit [Ping timeout: 252 seconds]
sakoman has quit [Quit: Client closed]
sakoman has joined #yocto
sakoman87 has joined #yocto
sakoman87 has quit [Client Quit]
ndec[m] has joined #yocto
<RP>
Next up we find that sed on files in WORKDIR turns the symlink back into real files
<shoragan>
ndec, you can use /mode +be $~a *!*@2001:470:69fc:105::/64 instead of -r. that bans all unauthenticated users but exempts the matrix bridge.
tnovotny has quit [Quit: Leaving]
shoragan[m]1 has joined #yocto
<shoragan[m]1>
so, now i can join without a registered nick
<ndec>
ok.. that's good, well for now.
<RP>
who knew, autotools hates symlinks in paths :/
shoragan[m]1 is now known as shoragan|m
BCMM has joined #yocto
zyga has joined #yocto
Guest31 has joined #yocto
<JPEW>
RP: Hmm.... what if you move ${WORKDIR} down to be a subfolder of some new directory... maybe that would be less breakage?
sakoman has quit [Quit: Client closed]
sakoman has joined #yocto
kergoth has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<RP>
JPEW: Its a good idea but I suspect you trade two sets of problems
<JPEW>
RP: Ya I figured. I was suspecting that most recipe usage of ${WORKDIR} would be fine if it was deleted in do_unpack.... the classes and stuff in oe-core would have to be updated, but it would be a one time thing
Andrei[m] has joined #yocto
Andrei[m] has left #yocto [#yocto]
<RP>
JPEW: the patch can get as far as core-image-sato now
Andrei[m] has joined #yocto
<JPEW>
RP: Cool
* JPEW
idly wonders if do_patch could be a postfunc of do_unpack
<RP>
JPEW: almost certainly but probably not worth it now
<JPEW>
RP: I was thinking about the archivers; it would be nice if the archiver could be a post-func of a cleaned do_unpack (after or before a do_patch postfunc). It might make the archiver simpler
<paulg>
Only savages stuck in 2005 are still applying patches at build-time.
* paulg
runs
<RP>
JPEW: how does that differ from before/after do_patch?
<JPEW>
it would be guarenteed to be clean (maybe that's not as much of a problem as I fret about)
* RP
looks for rocks to throw in the direction of paulg
<RP>
JPEW: it is a big problem but you could probably get the same result with a do_patch postfunc
pingovin has joined #yocto
<JPEW>
Probably. Mostly, I was wonder if we could get rid of do_unpack_and_patch in archiver.bbclass
<RP>
JPEW: I've worried a lot about the archiver for these reasons for a long time :(
khem has left #yocto [#yocto]
Jari[m] has joined #yocto
<RP>
JPEW: it gets complicated since arguably, some source scanning solutions want the source after we autoreconf it too :(
<paulg>
clobbering unused yocto kernel branches/tags from v2.6 .x and v3.x was a natural extension. :-P
<RP>
paulg: I have a load of 3c509 cards :)
<paulg>
RP the 3c509 will probably get a pass because the EISA kooks still claim to use it.
<fray>
I still know of _new_ devices that use the ISA NE2k driver..
<RP>
paulg: Right, I was just laughing a little as I have some of that stuff!
<fray>
that direct wired NE2k is never going to die
<fray>
(I'm assuming the NE2k will die "sooner" rather then later since the one I know of is still limited to 100 Mbit..)
<paulg>
yeah, I'll probably have to steer clear of the ne2k driver too for similar reasons -- it is basically a NS8390 chip with some TTL glue, and since the 8390 code is used by legacy arch, it won't be going away either - unless one wants to fight with atari/amiga people.
<paulg>
the m86k people have already interpreted an overdue phase #2 of a cleanup as a direct attack on them...
<fray>
only time I've see 'ISA' used in the modern era is when people just wire stuff together, and then 'call it ISA'.. :P
Emantor[m] has quit [Quit: node-irc says goodbye]
Emantor[m] has joined #yocto
<yates>
qschulz: let me get that email to the docs list in a few hours. still struggling to get real work done today.
Emantor[m] has quit [Client Quit]
Emantor[m] has joined #yocto
<yates>
ok, i've gotten confused again. i thought all .bbclass files with python, yet meta/classes/kernel.bbclass is not python.
<yates>
s/with/were/
<kergoth>
a bbclass is the same file format as a recipe
<kergoth>
you can define tasks in shell or python as you would anywhere
<yates>
kergoth: ok thanks for setting me straight (again)
kpo has quit [Ping timeout: 264 seconds]
<yates>
kergoth: are .inc files and .conf files also allowed to have either python or shell?
<JPEW>
.inc files yes, .conf files are more limited
<JPEW>
You can't define "code" in a .conf file, effectively just variable assignments
<yates>
k
mccc has joined #yocto
kergoth has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
abelloni has joined #yocto
abelloni is now known as abelloni_
abelloni_ is now known as abelloni
robbawebba has joined #yocto
<yates>
JPEW: in .bbclass files, are only variable definitions, function definitions (python or shell), and a limited number of other operations (e.g. "addtask") permitted?
<JPEW>
yates: I don't think there are any limitations to what you can do in a bbclass (as compared to a recipe)
<yates>
i added a single 'echo "..."' to one and got ParseError .... unparsed line
<JPEW>
yates: Sure... "echo" is not a valid line in a recipe
<yates>
this is a .bbclass file
<JPEW>
yates: Right. bbclass file have the same parsing as recipe files
<JPEW>
So, you can't add a line like that just anywhere in a bbclass or a recipe
<JPEW>
You could add it to a shell function defined *inside* a bbclass or .bb file
<yates>
so could you way that, in .bbclass files, are only variable definitions, function definitions (python or shell), and a limited number of other operations (e.g. "addtask") permitted?
<JPEW>
yates: Ah, I see what you are saying. Yes that is correct
<yates>
+1
<yates>
thanks JPEW
<JPEW>
I thought that you were talking about limitations *within the bitbake file syntax*. You can do any valid bitbake file syntax in a recipe or bbclass file, but not in a .conf file
ecdhe has joined #yocto
<JPEW>
But it does have to be valid bitbake file syntax :)
<ecdhe>
I need a base recipe for building a 2.6 series kernel
<yates>
for debugging purposes, is there an easy way to have a function always execute in a .bbclass file?
<yates>
is there an "addtask before_anything"?
<JPEW>
yates: Not really, what are you trying to do specifically?
<yates>
examine the state of certain variables in a .bbclass file when it is invoked
<JPEW>
yates: "invoked" is a bit of a strange term... but "bitbake -e recipe" will tell you what you want
<JPEW>
It will even show you the entire history of a variable and where it gets set/reset/appended/whatever on which lines
<yates>
what would you call it?
<yates>
i guess "executed" is better?
<JPEW>
Well, the bbclass itself gets "parsed". If the class defines functions (shell or python), those would be invoked, but not necessarily at parse time
<yates>
right
<yates>
ok
<JPEW>
Confusingly perhaps, variables can use inline python expansion "${@...}" and that will "invoke" python functions at parse time :)
<yates>
i tried bitbake -e and i got an extremely voluminous amount of output.
<JPEW>
Somewhat simplistily, the "parsing" all happens when you see bitbake show the "parsing" progress bar and the "executing" happens when you see the tasks running after that
<yates>
it didn't see practical
<yates>
right, i see.
<yates>
..didn't seem
<yates>
that was a couple of hours ago.
<JPEW>
yates: Ya, it takes a bit to get used to. Redirect to a file is your best bet
<JPEW>
yates: If you just want the final value of a variable, you can find many of them with `bitbake -e recipe | grep VAR=`
<JPEW>
Although that doesn't work if the variable is exported
<yates>
is there an "addtask before_anything"?
<yates>
that would be a more direct, simpler solution, where i define the task and in the task do my debugging
<JPEW>
Not that I know of
<yates>
ok
<JPEW>
You could just define a task and do bitbake -fc mytask recipe though
<yates>
that sounds like an idea
<yates>
i didn't know you could concatenate options like that to bitbake
<JPEW>
yates: The problem you run into with "before everything" is that bitbake tries really hard to not execute tasks that it's done before and have not changed
<JPEW>
So over several invocations of bitbake, the tasks executed for a given recipe might look like: do_fetch, do_patch, do_compile, do_install, (edited something) do_compile, do_install, (changed SRC_URI) do_fetch, do_patch, do_compile, do_install
<yates>
i don't mind removing all state beforehand. this is just a testing oe-init-build-environment
<JPEW>
defining a task and running it manually with `-fc mytask` will work; I would also recommend getting familiar with `bitbake -e output` though :)
<yates>
yes, doing just that
<yates>
does it matter to bitbake where on the command line options are specified? e.g., could i do this without a problem? bitbake -c populate_sdk_ext core-image-minimal -e
<JPEW>
yates: No, it should not
dev1990_ has quit [Quit: Konversation terminated!]
kergoth has joined #yocto
sakoman has quit [Ping timeout: 250 seconds]
LetoThe2nd has quit [Quit: Connection closed for inactivity]
sakoman has joined #yocto
BCMM has quit [Quit: Konversation terminated!]
kergoth has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
kergoth has joined #yocto
Guest0 has joined #yocto
Guest0 has quit [Client Quit]
Guest2 has joined #yocto
Guest2 has quit [Client Quit]
ndec[m] has left #yocto [#yocto]
ndec[m] has joined #yocto
<ndec[m]>
test msg
kergoth has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]