halloy4985 has quit [Remote host closed the connection]
leon-anavi has joined #yocto
tgamblin has quit [Ping timeout: 268 seconds]
GNUmoon2 has quit [Remote host closed the connection]
GNUmoon2 has joined #yocto
enok has quit [Ping timeout: 252 seconds]
mbulut__ has joined #yocto
enok has joined #yocto
mvlad has joined #yocto
dkc has quit [Ping timeout: 256 seconds]
dkc has joined #yocto
bgreen has quit [Ping timeout: 268 seconds]
bgreen has joined #yocto
Jones42_ has joined #yocto
Jones42 has quit [Ping timeout: 268 seconds]
enok has quit [Ping timeout: 268 seconds]
Jones42__ has joined #yocto
Guest13 has joined #yocto
Daanct12 has quit [Quit: WeeChat 4.2.2]
Jones42_ has quit [Ping timeout: 272 seconds]
enok has joined #yocto
<LetoThe2nd>
yo dudX
mbulut__ has quit [Quit: Leaving]
mbulut has joined #yocto
<mckoan>
LetoThe2nd: hey
<mbulut>
hey gents, i was just looking at some 3rd party set of layers that have image recipes with lots of `require` directives from other layers in different repos (e.g. poky)........ i was wondering if this is common practice because it feels wrong... any thoughts?
<mckoan>
mbulut: it is common practice and a feature in OE/YP
<mckoan>
mbulut: consider it as "not re-inventing the wheel"
<mbulut>
yeah of course but, what annoys me about that is that the recipe makes assumptions on the checked out repo name
<mbulut>
the poky repo for instance is assumed to be checked out as yocto.git
<mbulut>
e.g. require ../../../yocto.git/...
<mckoan>
mbulut: very likely is is a wrong setting in the 3rd party set of layers. I'd need a real example
<qschulz>
mbulut: no, this is very wrong :)
<qschulz>
mbulut: require directive searches for everything relative to BBPATH if I remember correctly
<qschulz>
herre I require the u-boot-common.inc by relative path from the root of any layer
<qschulz>
it should match the one from poky
<qschulz>
though, I'll get some remarks because specifically for the u-boot recipes these inc files aren't meant to be compatible with multiple versions of U-Boot... but you see the example
<mbulut>
qschulz, i take from that it matches the first occurence of the required path in any of the layers in BBPATH?
<mbulut>
is search order defined by the order or entries in BBLAYERS?
c-thaler has quit [Quit: Client closed]
florian__ has joined #yocto
<JaMa>
mbulut: it's a combination of how layer.conf uses BBPATH and order of layers how they are in BBLAYERS
<mbulut>
ok, i think i got it now (assuming i'm right that require takes the first match if more than one layer has it)
<rburton>
RP: amazingly pciutils fails to link for x86-64 so don't pull that into master-next
<RP>
rburton: this is what the LDLIBS mess was for :/
<RP>
rburton: thanks for the heads up though
* RP
notes abelloni is struggling with builds
<rburton>
our gcc is built to do -fPIC/-fPIE automatically, right?
<JaMa>
khem: one of your "gosu: Adjust for UNPACKDIR/WORKDIR rework" commits in master-next is actually for "etcd", can you please merge the fixes for etcd, crucible, gosu from master-next to master? these are broken with go.bbclass changes even without the final UNPACKDIR changes and might be useful to have them applied separately ahead of the rest of master-next
<KanjiMonster>
I don't know enough about oe to tell which one is more appropriate
Ad0 has quit [Ping timeout: 260 seconds]
enok has quit [Ping timeout: 252 seconds]
Guest92 has joined #yocto
dmoseley has joined #yocto
Ad0 has joined #yocto
enok has joined #yocto
alessioigor has quit [Quit: Client closed]
Kubu_work has quit [Quit: Leaving.]
Xagen has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Jookia has quit [Read error: Connection reset by peer]
florian__ has quit [Ping timeout: 240 seconds]
Jookia has joined #yocto
<khem>
JaMa: yes will do it shortly, I am waiting on couple of world builds to finish in next hr
<khem>
adjusted the commit msg thanks
<khem>
KanjiMonster: you can do both, it keeps cherry-picking easier as it does not diverge
mckoan is now known as mckoan|away
yudjinn has quit [Ping timeout: 268 seconds]
zpfvo has quit [Quit: Leaving.]
rfuentess has quit [Remote host closed the connection]
jmiehe has joined #yocto
yudjinn has joined #yocto
yudjinn has quit [Ping timeout: 260 seconds]
linfax has quit [Ping timeout: 268 seconds]
yudjinn has joined #yocto
<RP>
khem: you may want to hold off master-next for a bit
Saur_Home has quit [Quit: Client closed]
Saur_Home has joined #yocto
mbulut_ has joined #yocto
mbulut has quit [Ping timeout: 260 seconds]
mbulut_ has quit [Ping timeout: 268 seconds]
mbulut_ has joined #yocto
dgriego has quit [Quit: Computer going to sleep]
dgriego has joined #yocto
goliath has quit [Quit: SIGSEGV]
Xagen has joined #yocto
florian__ has joined #yocto
leon-anavi has quit [Remote host closed the connection]
jmiehe has quit [Quit: jmiehe]
yudjinn has quit [Ping timeout: 240 seconds]
mbulut__ has joined #yocto
<khem>
RP: you mean master-next of core ?
mbulut_ has quit [Ping timeout: 268 seconds]
<khem>
RP: I have seen some recipes doing S = WORKDIR but actually the recipe is installing a udev rule or some other scripts in do_install, now changing WORKDIR to UNPACKDIR in do_install fixes it, but I wonder if we need to the S = WORKDIR/source UNPACKDIR = S as well ?
<khem>
or just punt S and be done with it
<khem>
is there some later task which would want to look into S pointing to WORKDIR ( old ) and UNPACKDIR ( now )
<qschulz>
khem: IIRC, S = WORKDIR would become a fatal error?
<khem>
right, I am saying if S = WORKDIR is deleted and not replaced
<khem>
IOW do we need S = WORKDIR now point to S = UNPACKDIR
<khem>
even if recipe does not use S directly
florian__ has quit [Ping timeout: 260 seconds]
<khem>
and has couple of files added via file:// in SRC_URI
yudjinn has joined #yocto
<qschulz>
khem: S = "${WORKDIR}/${BP}" by default in bitbake.conf
<JaMa>
S = WORKDIR/source UNPACKDIR = S; will make sure the file:// from SRC_URI end "unpacked" here
<qschulz>
so if you don't use it, not sure you would need to redefine it?
<qschulz>
I assume the file:// in SRC_URI would be unpacked in UNPACKDIR and not S
<qschulz>
so you would need to update the tasks/paths that were looking into S/WORKDIR to use UNPACKDIR for those now?
<qschulz>
(Honestly guessing, so probably not that helpful, I barely read the mails yet :/)
<JaMa>
if you have e.g. bbappend for one of these recipes, then you need to use S or UNPACKDIR instead of WORKDIR, because your file:// entries will get "unpacked" there (so do_install with ${WORKDIR}/foo won't work anymore)
<JaMa>
and npmsw:// is also a bit broken if you use that
florian__ has joined #yocto
mbulut__ has quit [Quit: Leaving]
mbulut has joined #yocto
<khem>
JaMa: this all I understand, I have changed the do_install to pick it from UNPACKDIR already
<khem>
question is do we need S/UNPACKDIR dance in such cases
<JaMa>
I guess you can use the default meta/conf/bitbake.conf:UNPACKDIR ??= "${WORKDIR}/sources-unpack" and point S to it instead of the default ${WORKDIR}/${BP}
<qschulz>
JaMa: yeah but what would be the benefit?
<khem>
right my question is do we need to if S is not used in recipe at all
<khem>
is there some implicit task where it will be needed e.g. source package creation or some such
Guest92 has quit [Ping timeout: 250 seconds]
Saur_Home has quit [Quit: Client closed]
Saur_Home has joined #yocto
sa7mfo has joined #yocto
<sa7mfo>
Hello, I want to create python functions that is shared between a bbclass file and a wic plugin. Does these two "entities" have some common area? meta/lib?
<RP>
khem: we want to try and keep it standard so please use S as the other recipes
<RP>
khem: We use S in PSEUDO_IGNORE_PATHS and other places so it does need to be set correctly
MrCryo has quit [Ping timeout: 255 seconds]
goliath has joined #yocto
<RP>
JPEW: did you have a patch to implement the unihash parallelism in some of the code?
<JPEW>
RP: I think so
<RP>
JPEW: I don't think that bit merged
Vonter has quit [Ping timeout: 268 seconds]
mvlad has quit [Remote host closed the connection]
<JPEW>
RP: Ah right, I remember now; the stuff that was easily parallelizable was the hash existence check that we wanted to add for the sstate cache to reduce negative lookups on the CDN. The runqueue is.... more complicated.
<JPEW>
Hard to keep it all in my head sometimes :/
<JPEW>
Ok, I think this is doable though, let me take a look
dgriego has quit [Quit: Computer going to sleep]
dgriego has joined #yocto
dgriego has quit [Quit: Computer going to sleep]
<RP>
JPEW: runqueue is complicated, yes. Don't worry about it for now. I just wanted to make sure you didn't have anything already
<JPEW>
I do not, I was misremembering. Sorry
<RP>
JPEW: 191 queries passing through my code and they take 15s :/
<RP>
NOTE: Initial setup loop took: 3357.571198940277 - so a world build with some hash matches is still slow to start up
<RP>
going to need to rewrite this heavily. My patch also has a glitch in somewhere as it breaks :(
dgriego has joined #yocto
<RP>
I need to sleep, time to leave this for today
jmiehe has joined #yocto
Xagen has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]