<PhoenixMage>
Could be worse, could be using git.kernel.org :D
leon-anavi has joined #yocto
<tomzy_0>
Heh, that's true.
manuel_ has joined #yocto
zpfvo has joined #yocto
mthenault has joined #yocto
<jclsn>
Good morning
<mthenault>
Hello, I am a bit confused by devtool. When i do devtool modify <linux-recipe> and modify the sources, are those modifications included in my main image, or is that just confined to the "devtool build" output?
<mthenault>
aah just found out about devtool build-image <image_name> :)
fleg has quit [Quit: Ping timeout (120 seconds)]
fleg has joined #yocto
<qschulz>
mthenault: no, bitbake will use the devtool'ed recipes too
<mthenault>
thanks
<qschulz>
at least if: 1) the devtool workspace is listed in your bblayers.conf (automatically added when using devtool IIRC), 2) your recipe is available in devtool, check with devtool status
<ejoerns[m]>
Hi, anyone here having experience with using bitbake fetcher for downloading release assets from private Github repositories?
<ejoerns[m]>
The thing is they are available via the GitHub API only. Providing oauth token via headers is possible and I succeeded in manipulation FETCHCMD_wget to download something, the main thing what I stumble upon is that you need an 'asset id' that you obviously can only obtain by a previous API call to a release or a tag...
<ejoerns[m]>
So does anyone have a better advice then writing a new 'github' fetcher or obtaining the asset ID manually?
Payam has joined #yocto
Schlumpf has quit [Quit: Ping timeout (120 seconds)]
d-s-e has joined #yocto
florian has joined #yocto
dacav has joined #yocto
dacav has quit [Client Quit]
tor_ has joined #yocto
rob_w has quit [Remote host closed the connection]
tor has quit [Ping timeout: 260 seconds]
<rburton>
DvorkinDmitry: image_types.bbclass is 99% new image types. see for example the ext4 function that uses mkfs.ext4
<rburton>
ejoerns[m]: write a fetcher :)
d-s-e has quit [Ping timeout: 260 seconds]
<ejoerns[m]>
rburton: that's the answer I was afraid of :D
<rburton>
ejoerns[m]: doesn't have to be hard if you ignore some features, see the s3 fetcher
<LetoThe2nd>
ejoerns[m]: alternative, patch github with a bitbake provider? ;-)
kanavin has joined #yocto
Schlumpf has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
<ejoerns[m]>
<LetoThe2nd> "ejoerns: alternative, patch..." <- I'll think about the first alternative again ;)
<ejoerns[m]>
defining a fetcher locally (in any meta-layer) is not possible, right? not that I would not like to upstream it, but just as an intermediate solution
<LetoThe2nd>
ejoerns[m]: it is possible.
<LetoThe2nd>
ejoerns[m]: need me to dig up an example, or feel like hunting yourself?
d-s-e has joined #yocto
amitk__ has joined #yocto
amitk_ has quit [Ping timeout: 260 seconds]
<ejoerns[m]>
LetoThe2nd: only if you have one lying around. If you have to dig I can dig myself, too ;)
<Saur[m]>
hmw: You should use `oe_runmake` rather than `make` when running from a recipe. I also recommend to use the `-C` option rather than changing directory using `cd`.
d-s-e has quit [Quit: Konversation terminated!]
vmeson has quit [Ping timeout: 256 seconds]
vmeson has joined #yocto
gho has quit [Quit: Leaving.]
gho has joined #yocto
mvlad has joined #yocto
Tyaku has joined #yocto
kscherer has joined #yocto
sakoman has joined #yocto
<hmw[m]>
<Saur[m]> "hmw: You should use `oe_runmake`..." <- tnx
<hmw[m]>
i think i find the root of the problem but not sure what causes it
<hmw[m]>
qschulz: can i mark that file some how that its not needed to clean ? or remove it from the bitbake schript
<qschulz>
hmw[m]: which step fails for you?
<qschulz>
I guess you could remove the files in do_configure:prepend for example
<qschulz>
but it's not an issue for other u-boot recipes
<qschulz>
might just be related to your ancient version of u-boot using inc files meant to be used for much newer versions
<hmw[m]>
its a version of 2017 so i think that is ancient
alessioigor has quit [Quit: alessioigor]
<hmw[m]>
my hardware/ u-boot supplier cant supply a newer one ...... but i'm able to patch somthing if needed
<qschulz>
hmw[m]: I hope you don't expect this device to be secure, because this version has a few critical CVEs already
amitk_ has quit [Ping timeout: 260 seconds]
Schlumpf has quit [Quit: Client closed]
<hmw[m]>
qschulz: trying to port it to dunfell everthing in the field is still running krogoth
<hmw[m]>
so i don´t u-boot is my last concern
<qschulz>
hmw[m]: that's a painful upgrade :/
<hmw[m]>
it is
<qschulz>
hmw[m]: some veterans here recommend to not use inc files from outside of the layer where the recipe is
<qschulz>
hmw[m]: so maybe what you could do is import the .inc files (and others) from the krogoth layers that were used for u-boot, and import them in your dunfell layer
<hmw[m]>
oke going to try that
<hmw[m]>
qschulz: btw say them tnx
styloge[m] has joined #yocto
xmn has joined #yocto
<JaMa>
was there some wiki page, news entry, ML post describing lack of resources in Yocto project and calling for member companies to provide engineering resources as well? I think I've seen it before, now could use link to it in presentation for LGE
<qschulz>
JaMa: ML AFAIR
hcg has joined #yocto
<mcfrisk>
or was it members list only?
<JaMa>
I was checking oe-core, yocto, oe-members list, but "resources" "engineers" "developers" queries often provide too many results, don't remember exactly what to query for :)
<DvorkinDmitry>
hmm... how it could be? I'm setting B="${S}" (builddir) inside the recipe and it is not working
<qschulz>
DvorkinDmitry: what are you trying to do, what is "not working"?
<DvorkinDmitry>
qschulz, I set B="${S}" inside my recipe, when S="${WORKDIR}/git". It is not working, do_compile still trying to build inside {WORKDIR}/build
|Xagen has joined #yocto
<qschulz>
DvorkinDmitry: are you sure B is set? did you check with bitbake-getvar -r <recipe> B ?
Xagen has quit [Ping timeout: 260 seconds]
<DvorkinDmitry>
qschulz, to my surprise, it is not if I LATER put "inherit autotools"!
<DvorkinDmitry>
never expect that :)
<rburton>
DvorkinDmitry: if the recipe uses autotools *but* is broken with out-of-tree builds, then inherit autotools-brokensep
<rburton>
autotools set B=WORKDIR/build, as it does out-of-tree builds
<rburton>
(and fix the makefiles to work with out-of-tree builds, its better)
<DvorkinDmitry>
rburton, wow! thanks!
<rburton>
imho, *every* user of autotools-brokensep needs an upstream bug report to complain
<RP>
+1
<RP>
we haven't seen that many of those improve over the years :(
<JPEW>
RP: I had a few thoughts on the variable tracking
amitk_ has joined #yocto
<JPEW>
RP: First, I think you do want to do the weird looking cache[s] = s instead of cache[hash(s)] = s because the latter might get weird if there are hash collisons
<JPEW>
Second.... if there are a lot of "" entries, maybe they can be optimized? I'm thinking of some sort of "flipped" cache where maybe instead of doing cache[var] = value, you do `cache.setdefault(value, []).append(key)`, at least for the really common ones like "" and "1" (maybe all strings where len(value) <= 1 could be done that way)?
demirok has quit [Quit: Leaving.]
neilim has quit [Quit: Leaving]
<qschulz>
JPEW: don't know the context, but maybe you want a set and not an array if there's no need for two instances of the same object in the "list"?
<JPEW>
Ya, set would be fine
<JPEW>
better probably
<RP>
JPEW: I think if there were hash collisions we'd have a bigger problem but yes, I did try that and it doesn't change the speed
<RP>
JPEW: I think the "" values probably don't matter much since python likely has optimisations in place for that already too
<JPEW>
RP: right, I think the main difference is if `cache[s]` doens't return s on hash collision, that's a bug in python where as if `cache[hash(s)]` doesn't return s, that's on us :)
<RP>
JPEW: right. There is also a second benefit since we drop the overhead of the hash() function call
<RP>
My local code is now doing it for that reason. I had it down to 8.8s instead of 10s so a ~4s increase in parsing time overall
manuel_ has quit [Remote host closed the connection]
manuel_ has joined #yocto
zpfvo has quit [Ping timeout: 260 seconds]
<JPEW>
RP: cool
zpfvo has joined #yocto
Payam has quit [Quit: Client closed]
kayterina[m] has quit [Quit: You have been kicked for being idle]
justache has quit [Remote host closed the connection]
justache has joined #yocto
mthenault has quit [Ping timeout: 248 seconds]
<RP>
kergoth: any thoughts on allowing python data in recipes somehow (e.g. lists or dicts) ?
<zeddii>
bloody elfutils ptests, can't run just the one I want
* zeddii
starts hacking
<RP>
kergoth: I wonder if that could be as simple as MYVAR = ['x', 'y', 'z']
Minvera has joined #yocto
gho has quit [Quit: Leaving.]
florian has joined #yocto
zpfvo has quit [Ping timeout: 260 seconds]
zpfvo has joined #yocto
zpfvo has quit [Quit: Leaving.]
<rburton>
is it me, or is PERSISTENT_DIR aka build/cache, a bit misused.
<rburton>
if its meant to be shared between all builds why is sanity_info in there?
<rburton>
if I have a shared sstate-dir, should i set PERSISTENT_DIR to alongside it so the hashequiv.db is with it?
<rburton>
there's also the bitbake codeparser cache, surely that shouldn't be shared between builds?
hcg has quit [Ping timeout: 256 seconds]
geoffhp has joined #yocto
<rburton>
JPEW RP looking at you two for ^^^
<Ch^W>
rburton: I probably need to RTFM, but your question does resonate... I have been pondering how I am going to enable one development team to work on many different distros of varying architectures within a single desktop virtual machine...
<rburton>
well sharing sstate is trivial: single directory
<Ch^W>
Right... that is the easy part.
<Ch^W>
Orchestrating the whole circus so my developers do not need to _think_ about it, is the hard part.
<Ch^W>
Wrappers galore for the time being...
<RP>
rburton: we're off into really old bits of code, it is totally badly named
<RP>
rburton: no, codeparser should not be shared, that cache doesn't work like that
<RP>
(it has build paths in it from expanded functions)
leon-anavi has quit [Quit: Leaving]
<RP>
and no, hashserv shouldn't be set to a shared location, it isn't really designed for too much shared access, we have the network ports for that
<RP>
i.e. hashserv over NFS would be a disaster
<rburton>
how about on a local machine?
<RP>
rburton: depends how well you think sqlite works
<rburton>
i may run two parallel builds
<rburton>
so wellish :)
florian has quit [Ping timeout: 256 seconds]
<RP>
rburton: you can run two servers from the data hashserv DB, I've never tried two builds
Tyaku has quit [Quit: Lost terminal]
<JPEW>
You _should_ be able to share the SQLite database between two servers, or two builds from the same server
<JPEW>
The latter is probably better though
* RP
advises rburton to have a box to put all the pieces in
<rburton>
ye of little faith
<rburton>
RP: so i cant replicate that equiv problem with langdale... it rebuilds everything instead!
<RP>
rburton: gah :(. We should work out why :/
<RP>
rburton: any luck with a debug log when it happens?
<Ch^W>
MC/DC is required of the highest level criticality software in aerospace.
<RP>
Ch^W: nice!
florian has joined #yocto
florian_kc has joined #yocto
gsalazar has joined #yocto
* paulg
is still rocking out the AC/DC
<JPEW>
rburton: I'll put it this way: I tried hard not do to anything weird that would prevent concurrent access, and SQLite is _supposed_ to handle it, but YMMV
<JPEW>
Hashserve usage of SQLite is a lot more simple and "normal" than other places in bitbake, so I suspect it works concurrently
<rburton>
hmm why isn't hashequiv working *at all* for me with langdale
<JPEW>
No forks, no threads, etc
<JPEW>
That's strange
<rburton>
build image, touch autoconf-native's configure script with a bbnote, build image -> doesn't notice autoconf-native's sysroot is identical and rebuilds the world
<rburton>
did almost-the-right-thing in master, but trying with a clean langdale tree
<JPEW>
I'll give it a try when I get back to a computer
<rburton>
JPEW ircing with HIS MIND
<JPEW>
Cyberpunk complete with head jack
<rburton>
RP: ah i think this is the same problem but with langdale i don't have a build tree for it to re-package from
Vonter has quit [Quit: WeeChat 3.7.1]
<RP>
rburton: that would make sense
<rburton>
easy to test
<RP>
rburton: I'm heading afk with a headache but if you share the debug logs I'll take a look
<rburton>
i'll share them monday :)
Vonter has joined #yocto
<DvorkinDmitry>
is there any example of handling @d.getVarFlags() in bash?
Payam has joined #yocto
<rburton>
DvorkinDmitry: that would expand before the shell script runs
<rburton>
basically, the question doesn't make sense
<rburton>
${@...} gets expanded as the script is written out
<DvorkinDmitry>
ok. any way to parse this {'tst1': ' p0;k0;o0 p1;k1;o1', 'tst2': ' t0;a0;f0 t1;a1;f1'} in bash?
<rburton>
so bash sees what the expansion was
<rburton>
use python instead of bash to write the task or whatever?
<DvorkinDmitry>
rburton, seems there is no way not to use python :) I'm not good in syntax, but good in bash :)
Tokamak has quit [Ping timeout: 248 seconds]
Tokamak_ has joined #yocto
Tokamak_ has quit [Quit: Tokamak_]
Piraty has quit [Quit: No Ping reply in 180 seconds.]
Piraty has joined #yocto
Tokamak has joined #yocto
sakoman has quit [Quit: Leaving.]
bantu has quit [Quit: No Ping reply in 180 seconds.]
bantu has joined #yocto
florian_kc has quit [Ping timeout: 268 seconds]
Tokamak has quit [Quit: Tokamak]
goliath has joined #yocto
florian_kc has joined #yocto
<vvn>
does some_task[mcdepends] += "mc::foo:recipe:task" work for you guys?
Tokamak has joined #yocto
GillesM has quit [Ping timeout: 268 seconds]
florian_kc has quit [Read error: Connection reset by peer]
qschulz has quit [Read error: Connection reset by peer]
<vvn>
RP: I believe mcdepends is broken at the moment
qschulz has joined #yocto
florian has quit [Ping timeout: 240 seconds]
goliath has quit [Quit: SIGSEGV]
qschulz has quit [Quit: qschulz]
mvlad has quit [Remote host closed the connection]
d-fens has joined #yocto
<vvn>
damn, found it... INITRAMFS_MULTICONFIG also needs BBMULTICONFIG..
<vvn>
ok so we just need to error out with "Multiconfig dependency %s depends on nonexistent multiconfig configuration named %s" instead of blowing up with a stack trace
florian_kc has joined #yocto
Vonter has quit [Ping timeout: 260 seconds]
Vonter has joined #yocto
vmeson has quit [Quit: Konversation terminated!]
qschulz has joined #yocto
amitk_ has quit [Ping timeout: 260 seconds]
goliath has joined #yocto
npcomp has quit [Ping timeout: 260 seconds]
amitk has quit [Ping timeout: 268 seconds]
npcomp has joined #yocto
tor_ has quit [Quit: Leaving]
kscherer has quit [Quit: Konversation terminated!]
goliath has quit [Quit: SIGSEGV]
<RP>
vvn: could you send a patch please?
goliath has joined #yocto
Minvera has quit [Remote host closed the connection]
gchamp has quit [Read error: Connection reset by peer]