Thursday, 2018-10-25

*** tgraydon <tgraydon!textual@nat/intel/x-lovyifrasobjrtah> has quit IRC01:00
*** learningc <learningc!> has joined #yocto01:01
*** learningc <learningc!> has quit IRC01:02
*** learningc <learningc!> has joined #yocto01:02
*** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has joined #yocto01:52
*** tlwoerner_ <tlwoerner_!~trevor@unaffiliated/tlwoerner> has joined #yocto01:58
*** NU-Slacker <NU-Slacker!~NU-Slacke@> has joined #yocto02:14
*** NU-Slacker <NU-Slacker!~NU-Slacke@> has quit IRC02:17
*** NU-Slacker <NU-Slacker!~NU-Slacke@> has joined #yocto02:18
*** NU-Slacker <NU-Slacker!~NU-Slacke@> has quit IRC02:20
*** Hoolootwo is now known as Hooloovo003:15
*** learningc <learningc!> has joined #yocto03:18
*** learningc <learningc!> has joined #yocto03:20
*** learningc <learningc!> has quit IRC03:21
*** learningc <learningc!> has joined #yocto03:21
*** learningc <learningc!> has joined #yocto03:23
*** learningc <learningc!> has joined #yocto03:24
*** learningc <learningc!> has quit IRC03:25
*** learningc <learningc!> has joined #yocto03:25
*** learningc <learningc!> has joined #yocto03:26
*** learningc <learningc!> has joined #yocto03:27
*** learningc <learningc!> has joined #yocto03:29
*** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has quit IRC03:40
*** resixian <resixian!~akira@unaffiliated/resixian> has quit IRC04:14
*** learningc <learningc!> has quit IRC04:29
*** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has joined #yocto04:34
*** tlwoerner_ <tlwoerner_!~trevor@unaffiliated/tlwoerner> has quit IRC04:40
*** learningc <learningc!> has joined #yocto04:48
*** learningc <learningc!> has quit IRC04:50
*** learningc <learningc!> has joined #yocto04:51
*** learningc <learningc!> has joined #yocto04:52
*** learningc <learningc!> has quit IRC04:53
*** learningc <learningc!> has joined #yocto04:53
*** learningc <learningc!> has joined #yocto04:54
*** learningc <learningc!> has quit IRC04:55
*** learningc <learningc!> has joined #yocto04:56
*** learningc <learningc!> has joined #yocto04:57
*** learningc <learningc!> has joined #yocto04:58
*** learningc <learningc!> has quit IRC04:59
*** learningc <learningc!> has joined #yocto04:59
*** learningc <learningc!> has joined #yocto05:01
*** learningc <learningc!> has joined #yocto05:02
*** learningc <learningc!> has quit IRC05:03
*** learningc <learningc!> has joined #yocto05:04
*** learningc <learningc!> has joined #yocto05:05
*** learningc <learningc!> has joined #yocto05:06
*** AndersD <AndersD!> has joined #yocto05:11
*** AndersD <AndersD!> has quit IRC05:19
*** AndersD <AndersD!~AndersD@> has joined #yocto05:20
*** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has quit IRC05:23
*** NU-Slacker <NU-Slacker!~NU-Slacke@> has joined #yocto05:39
*** TobSnyder <TobSnyder!> has joined #yocto06:04
*** lpotter <lpotter!~quassel@> has joined #yocto06:05
*** Crofton_ <Crofton_!> has joined #yocto06:08
*** Guest47381 is now known as synack06:08
*** synack <synack!~synack@pdpc/supporter/active/synack> has joined #yocto06:08
*** lfa <lfa!> has joined #yocto06:11
*** frsc <frsc!> has joined #yocto06:26
*** lpotter <lpotter!~quassel@> has quit IRC06:28
*** zagor <zagor!~zagor@rockbox/developer/Zagor> has quit IRC06:32
*** zagor <zagor!~zagor@rockbox/developer/Zagor> has joined #yocto06:33
*** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has joined #yocto06:37
*** NU-Slacker <NU-Slacker!~NU-Slacke@> has quit IRC06:39
*** Carton__ <Carton__!~jo@2a02:120b:7ff:51a0:5475:2b8a:6e07:795e> has joined #yocto06:42
*** Carton__ <Carton__!~jo@2a02:120b:7ff:51a0:5475:2b8a:6e07:795e> has quit IRC06:49
*** Carton__ <Carton__!~jo@2a02:120b:7ff:51a0:5475:2b8a:6e07:795e> has joined #yocto06:49
*** joseppc <joseppc!~josep@unaffiliated/joseppc> has joined #yocto06:59
*** fl0v0 <fl0v0!> has joined #yocto07:00
*** smartin_ is now known as smartin07:05
*** nslu2-log <nslu2-log!~nslu2-log@> has quit IRC07:08
*** warthog9 <warthog9!warthog9@> has quit IRC07:09
*** tlwoerner_ <tlwoerner_!~trevor@unaffiliated/tlwoerner> has joined #yocto07:10
*** Crofton_ <Crofton_!> has quit IRC07:14
*** Crofton__ <Crofton__!> has joined #yocto07:14
*** boucman_work <boucman_work!~jrosen@wesnoth/developer/boucman> has joined #yocto07:14
yoctiNew news from stackoverflow: do_compile: oe_runmake failed and do_compile: Function failed: do_compile error while building yocto project <>07:15
*** tlwoerner_ <tlwoerner_!~trevor@unaffiliated/tlwoerner> has quit IRC07:18
*** armpit <armpit!~armpit@> has joined #yocto07:25
*** nslu2-log <nslu2-log!~nslu2-log@> has joined #yocto07:28
*** warthog9 <warthog9!warthog9@> has joined #yocto07:33
*** boucman_work <boucman_work!~jrosen@wesnoth/developer/boucman> has quit IRC07:39
*** boucman_work <boucman_work!~jrosen@wesnoth/developer/boucman> has joined #yocto07:40
*** ant_work <ant_work!> has joined #yocto07:41
armpithas ypdd started ?07:42
*** lfa <lfa!> has quit IRC07:44
*** tprrt <tprrt!~tprrt@> has joined #yocto07:58
LetoThe2ndarmpit: technically yes08:06
*** armpit <armpit!~armpit@> has quit IRC08:07
*** JaMa <JaMa!~martin@> has joined #yocto08:17
*** seebs <seebs!~seebs@> has joined #yocto08:21
Crofton__LetoThe2nd, how do you get in ?08:23
Crofton__any guards?08:23
*** kaspter <kaspter!~Instantbi@> has joined #yocto08:25
LetoThe2ndCrofton__: just the usual. orcs, ogres, a hungry balrog and some lf folks </SCNR>08:27
*** toanju <toanju!~toanju@> has joined #yocto08:27
Crofton__as always, I forget to register as staff08:27
Crofton__I think :)08:27
LetoThe2ndCrofton__: well the usual door bouncers asking for badges are still there08:28
*** mns_ <mns_!4fab95ac@gateway/web/freenode/ip.> has joined #yocto08:31
*** RyanMeulenkamp <RyanMeulenkamp!> has joined #yocto08:32
*** Bunio_FH <Bunio_FH!> has joined #yocto08:33
RyanMeulenkampHi guys. Question: how should I create library symlinks? If I do this in the image_postprocess step they disappear before the image is built..08:33
RyanMeulenkampAt least, the symlinks that I place in /lib or /usr/lib do. If I place them in another location they do remain. Which step causes them to disappear?08:34
mns_Anyone else observing extreme slow uninative downloads ?08:35
RyanMeulenkampI meant rootfs_postprocess instead of image_postprocess by the way.08:36
LetoThe2ndhalstead: ^^^^^^^^ (mns)08:36
*** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has joined #yocto08:36
LetoThe2ndRyanMeulenkamp: hum, why are you jumping through those magic hoops anyways, instead of getting stuff straight during do_install?08:37
halsteadThanks LetoThe2nd08:38
halsteadmns_ which region is the download happening in?08:39
mns_Denmark (Europe)08:40
RyanMeulenkampBecause the recipe it actually 'belongs' to has it's IPK's generated externally.08:41
LetoThe2ndRyanMeulenkamp: huh? you have a recipe that takes externally packaged ipks? or is it actually not a recipe, but something you just inject in the package feed08:42
LetoThe2ndRyanMeulenkamp: despite the fact this sounds extremely painful, the standard approach would be to do repackaging in the recipe. there's examples on doing that for debs, for example08:43
halsteadmns_ thank you. I'm checking a few things.08:43
mns_halstead: Tracepath available here: - don't know if it makes any sense to you08:43
RyanMeulenkampLetoThe2nd: Hmm alright, I'll have a look. Thanks!08:46
*** T_UNIX <T_UNIX!uid218288@gateway/web/> has joined #yocto08:48
angelo_tshi, how can i skip do_compile step ? I just need a do_install08:55
halsteadmns_, I'm seeing between 64-100mbps to Amsterdam and the UK. Can you run 'tracepath' and e-mail the result to
LetoThe2ndRyanMeulenkamp: i think there was some doc or example but can't find t right now too.08:55
LetoThe2ndand rburton is offline. i'd suggest to poke him08:56
LetoThe2ndangelo_ts: here you go:
angelo_tsLetoThe2nd, thanks !08:59
mns_Ok, I am seeing <10kbps. I'll start by trying through my LTE connection - could be our corporate network. I'll get back with the observations09:01
*** Bunio_FH <Bunio_FH!> has quit IRC09:04
*** Crofton__ <Crofton__!> has quit IRC09:06
*** Bunio_FH <Bunio_FH!> has joined #yocto09:07
mns_Hmm, it works fine on a LTE connection and issue must thus be in our corporate network - sorry for the noise09:10
mns_But thank, halstead09:21
*** awe00 <awe00!~awe00@unaffiliated/awe00> has joined #yocto09:23
*** lucaceresoli <lucaceresoli!> has joined #yocto09:37
*** tlwoerner_ <tlwoerner_!~trevor@unaffiliated/tlwoerner> has joined #yocto09:37
*** tlwoerner_ <tlwoerner_!~trevor@unaffiliated/tlwoerner> has quit IRC09:43
*** andrey_utkin <andrey_utkin!~andrey_ut@gentoo/developer/andrey-utkin> has joined #yocto09:46
*** bluelightning_ <bluelightning_!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto09:56
FrostEyesmns_: FYI the speed looks good from Frederiksberg. Just out of curiosity, where in DK are you working with Yocto?09:57
*** andrey_utkin <andrey_utkin!~andrey_ut@gentoo/developer/andrey-utkin> has left #yocto09:58
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC10:00
*** tlwoerner_ <tlwoerner_!~trevor@unaffiliated/tlwoerner> has joined #yocto10:02
*** tlwoerner_ <tlwoerner_!~trevor@unaffiliated/tlwoerner> has quit IRC10:04
*** georgem_home <georgem_home!uid210681@gateway/web/> has joined #yocto10:07
*** mns__ <mns__!~martin@> has joined #yocto10:10
*** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has joined #yocto10:13
halsteadmns_, Thanks for reporting. I'm always glad to check in.10:16
*** marble_visions <marble_visions!~user@> has quit IRC10:19
*** marble_visions <marble_visions!~user@> has joined #yocto10:20
*** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has quit IRC10:25
*** Crofton__ <Crofton__!~Crofton@> has joined #yocto10:39
*** Crofton__ is now known as Crofton|work10:39
*** JaMa <JaMa!~martin@> has quit IRC10:50
*** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has quit IRC11:05
*** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has joined #yocto11:06
*** Crofton|work <Crofton|work!~Crofton@> has quit IRC11:08
mns__FrostEyes: Aalborg (Gomspace)11:13
*** bentech <bentech!~ben36@unaffiliated/bentech> has joined #yocto11:17
*** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has joined #yocto11:20
*** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has quit IRC11:23
*** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has joined #yocto11:24
*** xtron <xtron!~mentor@> has quit IRC11:52
*** bluelightning_ <bluelightning_!~paul@pdpc/supporter/professional/bluelightning> has quit IRC11:56
*** Crofton|work <Crofton|work!~Crofton@> has joined #yocto11:58
*** RyanMeulenkamp <RyanMeulenkamp!> has quit IRC12:02
LetoThe2ndok now i have a weird one: when i try to use as SRc_URI for the kernel, it goes for a tableflip with "bb.data_smart.ExpansionError: Failure expanding variable PKG_kernel-image, expression was ...."12:04
LetoThe2ndwhy on earth is that?12:06
LetoThe2ndand where is zeddii when you need him12:10
*** geissonator <geissonator!~geissonat@> has joined #yocto12:11
LetoThe2ndgah paulbarker sorted it out12:14
*** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has quit IRC12:15
*** xtron <xtron!~mentor@> has joined #yocto12:21
*** learningc <learningc!> has quit IRC12:23
T_UNIXdoes bitbake somehow block network access besides its own SRC_URI fetch related tasks?12:36
T_UNIXi.e. meson has a wrap system that allows to download missing dependencies on the fly during configuration stage12:36
*** ant_work <ant_work!> has quit IRC12:37
*** cquast <cquast!~cquast@> has joined #yocto12:37
neverpanicT_UNIX: No. But if you want, you can do fetchall first and then run bitbake in a network namespace without internet access12:38
LetoThe2ndT_UNIX: nope it certainly doesnt12:39
LetoThe2ndat least not by default12:39
T_UNIXokay. Weird. Cause configuring the project works fine on my host. But fails during fetch w/ bitbake12:40
*** learningc <learningc!~learningc@> has joined #yocto12:45
T_UNIXdamn corporate proxy sh*$12:46
*** andrey_utkin <andrey_utkin!~andrey_ut@gentoo/developer/andrey-utkin> has joined #yocto12:48
*** stephano <stephano!stephano@nat/intel/x-bgisftzqxeljomcx> has joined #yocto13:17
T_UNIXfetching via urllib in python: works; fetching via meson (urllib) inside bitbake: fails -.-'13:19
kergothsounds like that recipe needs fixing regardless. bitbake doesn't block fetching from buildsystems, but it'd be awfully nice if it did, since all fetching belongs in do_fetch13:20
*** mns_ <mns_!4fab95ac@gateway/web/freenode/ip.> has quit IRC13:26
*** bentech_ <bentech_!~ben36@unaffiliated/bentech> has joined #yocto13:26
*** bentech <bentech!~ben36@unaffiliated/bentech> has quit IRC13:28
*** bentech_ is now known as bentech13:28
*** stephano <stephano!stephano@nat/intel/x-bgisftzqxeljomcx> has quit IRC13:29
*** kuzulis <kuzulis!~kuzulis@> has joined #yocto13:31
kuzulisHi guys. Is in yocto any variable which contains a name of current git-branch? E.g. I want to use a git-branch name as a 'suffix' for generation of a name of my image.13:33
kuzulislike: my-image-blabla-$${GIT_BRANCH_NAME}.ext313:35
*** joseppc <joseppc!~josep@unaffiliated/joseppc> has quit IRC13:38
*** mns__ <mns__!~martin@> has quit IRC13:39
T_UNIXkergoth: does it clean the enviornment variables it passes when it runs the stages?13:44
T_UNIXi.e. removing `https_proxy`?13:44
*** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has joined #yocto13:45
kergothit does filter the environment, but iirc those should already be in the whitelist unless you're running a very old version13:45
*** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has quit IRC13:48
*** toanju <toanju!~toanju@> has quit IRC13:52
*** marka <marka!~masselst@> has joined #yocto13:54
kuzulisguys, is it possible to call a system shell comamnds and to parse its output to some variables?13:55
kuzulise.g. I tried GIT_BRANCH_NAME='git rev-parse --abbrev-ref HEAD' but then ${GIT_BRANCH_NAME} returns 'git rev-parse --abbrev-ref HEAD' instead of, e.g. 'master'13:56
kuzulisI'm not a python expert.. From that doc I see similar: DATE = "${@time.strftime('%Y%m%d',time.gmtime())}"  ... But I need to do similar only for 'git' command..14:01
*** AndersD <AndersD!~AndersD@> has quit IRC14:02
*** vladzouth_ <vladzouth_!500c5411@gateway/web/freenode/ip.> has joined #yocto14:05
*** kaspter <kaspter!~Instantbi@> has quit IRC14:07
*** kaspter <kaspter!~Instantbi@> has joined #yocto14:07
kuzulisI found it: GIT_BRANCH_NAME=$(git rev-parse --abbrev-ref HEAD) :))14:11
T_UNIXkergoth: it is in the whitelist and fetching source via SRC_URI works. I just thought that bitbake might clean the environment prior to executing the compiled scripts (tasks)14:12
kergothif it's set in the recipe metadata, it'll be set for hte tasks. i.e. run bitbake -e somrecipe | grep 'https_proxy='14:13
kergothfiltering happens pretty early on, when setting up the global configuration metadata14:13
*** rcw <rcw!~rcw@> has joined #yocto14:15
*** Crofton|work <Crofton|work!~Crofton@> has quit IRC14:39
*** TobSnyder <TobSnyder!> has quit IRC14:45
*** Carton__ <Carton__!~jo@2a02:120b:7ff:51a0:5475:2b8a:6e07:795e> has quit IRC14:48
*** vladzouth_ <vladzouth_!500c5411@gateway/web/freenode/ip.> has quit IRC14:50
*** WillMiles <WillMiles!> has joined #yocto14:55
*** kuzulis <kuzulis!~kuzulis@> has quit IRC15:00
T_UNIXI've now added all the subprojects of the meson project as explicit SRC_URI (dublicating the checksum). That works.15:02
kergothah, nice15:04
*** boucman_work <boucman_work!~jrosen@wesnoth/developer/boucman> has quit IRC15:18
*** boucman_work <boucman_work!~jrosen@wesnoth/developer/boucman> has joined #yocto15:18
*** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has quit IRC15:24
*** Bunio_FH <Bunio_FH!> has quit IRC15:32
*** frsc <frsc!> has quit IRC15:34
*** bentech <bentech!~ben36@unaffiliated/bentech> has quit IRC15:36
*** georgem_home <georgem_home!uid210681@gateway/web/> has quit IRC15:36
*** georgem_home <georgem_home!uid210681@gateway/web/> has joined #yocto15:37
*** lusus <lusus!~lusus@> has quit IRC16:01
T_UNIXif this question reoccurs: the workaround is to download all the files (disabling unpacking `;unpack=0`) and then append e.g. `do_configure_prepend` to copy the zip files from the `${WORKDIR}` to meson's packagecache dir (typcally: `${WORKDIR}/git/subprojects/packagecache`). From there it'll pick'em up, assuming it fetched it on its own.16:05
T_UNIXbtw. I would have preferred `do_unpack_append` but, it seems, it is interepreted as python (i.e. indentation parsing errors, etc.)16:09
kergothdo_unpack[postfuncs] += "my_unpack_function"16:20
kergothwill do it16:20
*** Crofton|work <Crofton|work!~Crofton@> has joined #yocto16:24
*** fl0v0 <fl0v0!> has quit IRC16:24
T_UNIXis there a reasoning behind?16:30
*** lucaceresoli <lucaceresoli!> has quit IRC16:31
*** Alchemic <Alchemic!~al@unaffiliated/alchemical> has quit IRC16:33
*** Crofton|work <Crofton|work!~Crofton@> has quit IRC16:33
kergothI don't understandt he question16:36
kergoththe do_unpack function is python. bitbake's _append just concatenates you can't concatenate shell onto a python function16:36
kergothwhereas prefuncs/postfuncs are additional separate functions called, no string concatenation involved16:37
kergothdoes that make it clear?16:37
*** cquast <cquast!~cquast@> has quit IRC16:40
*** learningc <learningc!~learningc@> has quit IRC16:40
*** rcw <rcw!~rcw@> has quit IRC16:46
*** rcw <rcw!~rcw@> has joined #yocto16:47
T_UNIXkergoth: I didn't know one couldn't "mix". I thought commands were glued together and python snippets moved to tmp files and executed accordingly16:52
T_UNIXso yes, that makes it clear.16:52
kergothit's not that granular. and wouldn't be possible in all cases. i.e. we can't just execute each fragment of an append/prepend separately, as later appends often reference earlier appends variables16:54
kergothcould break it up at each python/shell boundary, but no one has bothered to make it happen16:54
T_UNIXthat's just what I assumed. Didn't mean to complain :)16:55
*** jdel <jdel!~jdel@> has joined #yocto16:55
kergotheh, it's a long standing limitation that occasionally irritates me, so.. :)16:55
jdelwhen is it appropriate to use work-shared?16:56
jdelnotably kernel headers seem to get installed there by default16:56
jdelbut they are not preserved in sstate16:56
jdel(at least not in my recipe)16:57
jdelis it reasonable to add work-shared directories to sstate output dirs?16:57
kergothwork-shared is highly special cased and is pretty much only used by the kernel and gcc sources16:57
kergothyou really shouldn't be trying to use it for anything else16:57
jdelmy kernel recipe installs the produced uapi headers there16:58
jdelbut when the kernel is restored from sstate those headers are not16:58
kergothsounds like you're installing them wrong16:58
jdeli guess this is covered in the libc-linux-headers recipe, which is to add explict dependencies on do_install16:58
kergothdo_install should only ever be installing to ${D}16:59
kergoththen our other functions and tasks and sstate are responsible for putting it where it belongs16:59
jdelthe recomendation in linux-libc-headers is to add #    do_configure[depends] += "virtual/kernel:do_shared_workdir"17:00
kergoththat's if you want to depend on the kernel headers, not write to them17:01
jdelerr, yeah17:01
jdeli think my kernel recipe doesn't do the headers installation at the right time17:01
jdeland my recipes don't depend on it properly17:01
*** mrpelotazo <mrpelotazo!> has quit IRC17:01
jdelit's sadly easy to write terribly broken bsps17:02
jdeleither that or qcom puts a lot of effort into making their bsps terrible :p17:03
jdelthx for the help17:03
kergothi'd suggest reading do_shared_workdir to see how the files get deployed into workdir, but likely you just need to install the headers in do_Install to ${D}${includedir}17:08
*** radsquirrel <radsquirrel!> has joined #yocto17:09
*** tprrt <tprrt!~tprrt@> has quit IRC17:14
*** rcw <rcw!~rcw@> has quit IRC17:35
*** rcw <rcw!~rcw@> has joined #yocto17:36
*** ant_home <ant_home!> has joined #yocto17:44
*** Crofton|work <Crofton|work!> has joined #yocto18:05
*** Bunio_FH <Bunio_FH!> has joined #yocto18:09
*** kaspter <kaspter!~Instantbi@> has quit IRC18:12
*** xtron <xtron!~mentor@> has quit IRC18:31
*** WillMiles <WillMiles!> has quit IRC19:03
*** T_UNIX <T_UNIX!uid218288@gateway/web/> has quit IRC19:04
*** Bunio_FH <Bunio_FH!> has quit IRC19:18
*** learningc <learningc!~learningc@> has joined #yocto19:36
*** learningc <learningc!~learningc@> has quit IRC19:40
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto19:53
*** awe00 <awe00!~awe00@unaffiliated/awe00> has quit IRC20:03
*** rcw <rcw!~rcw@> has quit IRC20:04
*** marka <marka!~masselst@> has quit IRC20:42
*** andrey_utkin <andrey_utkin!~andrey_ut@gentoo/developer/andrey-utkin> has left #yocto20:50
*** kaspter <kaspter!~Instantbi@> has joined #yocto20:57
uglyoldbobin a bbappend file, if I set SRCREV_thing = "${AUTOREV}", can I do PV += "${SRCPV}" to get a specific SRC_URI to always fetch when the repository is updated?21:08
*** geissonator <geissonator!~geissonat@> has quit IRC21:18
*** noway96 <noway96!> has joined #yocto21:19
*** georgem_home <georgem_home!uid210681@gateway/web/> has quit IRC21:26
*** robbawebba <robbawebba!~rob@> has joined #yocto21:28
noway964.4.3-yocto-standard corresponds to which linux kernel version? 4.4.3?21:31
robbawebbanoway96: yup! The output of uname -r on a yocto-built kernel is a combination of the LINUX_VERSION LINUX_VERSION_EXTENSION variables. Your LINUX_VERSION seems to be 4.4.3 and the default value of LINUX_VERSION_EXTENSION is "-yocto-standard"21:48
*** mrk377 <mrk377!442d9918@gateway/web/freenode/ip.> has joined #yocto21:51
noway96ok thank you robbawebba.21:58
mrk377ALL: On rocko, my read only filesystem has most of the files with uid:gid 1000:1000 and not root:root.  Is this normal or indication of a recipe issue?  I didn't see this with my kergoth release.21:58
noway96I know that linux 4.4.3 standard has NVMe support. Namely, it knows where to find the linux/nvme_ioctl.h command. But why when I try to build against 4.4.3-yocto-standard does it not compile and say unknown headers linux/nvme_ioctl.h?21:59
*** ant_home <ant_home!> has quit IRC22:06
robbawebbanoway96: Was the kernel definitely compiled with nvme support? IIRC the config options are CONFIG_NVME and/or CONFIG_BLK_DEV_NVME22:09
robbawebbanoway96: linux/nvme_ioctl.h doesn't seem to appear in linux kernel 4.4. There is NVMe support, but the only relevant header file I see in include/linux is nvme.h22:15
noway96oh ok. how to I get the most recent yocto linux kernel version??22:16
noway96also I found nvme_ioctl inside linux-4.4.0 headers for ubuntu but I must have done something wrong22:16
*** mrk377 <mrk377!442d9918@gateway/web/freenode/ip.> has quit IRC22:17
noway96what does the =m flag mean?22:17
*** ant_home <ant_home!> has joined #yocto22:18
robbawebbanoway96: ahh, I think I'm mistaken. the file appears at include/uapi/linux/nvme_ioctl.h. SO it should be available. I'm actually unfamiliar with the uapi subdirectory22:19
noway96=m means module22:20
noway96anyway why won't this find nvme_ioctl then?22:20
noway96do I need to do a rebuild from scratch?22:20
robbawebbathe =m flag instructs the kernel build system to build the nvme driver as a loadable module, rather than built into the kernel. If it was built-in, you wouldn't be able to insert or remove the module on-demand. It is built into the kernel if you choose =y, and it won't be included at all if you choose =n22:21
robbawebbanoway96: not sure why it won't find it. I'll brb, going to do some googling about uapi22:22
robbawebbanoway96: aokay, that's just the location of userspace API headers. That makes sense. Are you compiling on the target device, or are you compiling on your host PC?22:23
noway96host PC22:26
noway96thanks for the explanation22:26
noway96conf/fatal error: linux/nvme_ioctl.h: No such file or directory22:28
robbawebbaIs this being built with bitbake?22:29
robbawebbanoway96: Okay, so it sounds like your recipe might not have access to the shared kernel source that is provided by the virtual/kernel recipe22:32
robbawebbanoway96: The virtual/kernel do_shared_workdir task populates ${STAGING_DIR_KERNEL} (which is often tmp/work-shared/${MACHINE}/kernel-source), which your recipe would need22:33
robbawebbanoway96: what tsak is your recipe failing at? do_configure? do_compile?22:34
noway96do_compile: Function failed: do_compile22:35
noway96but I found nvme_ioctl.h: tmp/work-shared/genericx86-64/kernel-source/include/uapi/linux/nvme_ioctl.h22:37
*** awe00 <awe00!~awe00@unaffiliated/awe00> has joined #yocto22:41
*** armpit <armpit!~armpit@> has joined #yocto22:42
robbawebbanoway96: yup! Thats it :)22:45
robbawebbaSo we have to make sure your recipe has access to those files22:45
robbawebbaadding do_compile[depends] += "virtual/kernel:do_shared_workdir" might be a start22:45
noway96yeah still getting the same bug: fatal error: linux/nvme_ioctl.h: No such file or directory22:45
noway96I'll try that22:46
noway96doesn't look like it worked. still getting an error22:52
noway96same error*22:53
robbawebbanoway96: could you try making the do_configure task depend on the do_shared_workdir task? instead of do_compile22:55
*** Willy-- <Willy--!~william@> has joined #yocto22:55
noway96yeah it could be a race condition. but I'm getting the same error still22:57
robbawebbanoway96: this dependency declaration should prevent the race condition, meaning that it should gaurantee that the linux kernel source is available in work_shared. But it seems like your recipe still cannot find the sources :/22:58
robbawebbaand you verified that they are there in the work-shared directory22:58
noway96they're in the path I shared with you earlier22:59
noway96or rather, that's the path for nvme_ioctl.h. Is that what you're referring?23:00
noway96fatal error: linux/nvme_ioctl.h: No such file or directory. Maybe not linux/nvme_ioctl.h but some other path?23:02
robbawebbanoway96: I think that's the right include statement. Since linux/nvme_ioctl.h is located under include/uapi, we have to make sure include/uapi is able to be found by the compiler23:04
noway96any ideas? is there something I can depend on to ensure that linux headers are there?23:17
*** OutBackDingo <OutBackDingo!~quassel@unaffiliated/outbackdingo> has quit IRC23:28
noway96robbawebba, so turns out that it's something to do with Cython. Built my C++ code just fine using a Makefile with bitbake. So the issue is with using cython's for building.23:41
noway96My python code wraps some C++ code that uses linux/nvme_ioctl.h23:41
noway96C++ code compiles just fine by bitbake. But when wrapped by python, it doesn't23:42
*** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has quit IRC23:42
robbawebbanoway96: ahhh okay. I'm unfamiliar with how python/cython accomplishes this. It it's documentation, does it mention anything about adding more directories to look for when including headersw?23:43
noway96well my build command works just fine right now when not used by Yocto, but I'll take a look23:47
noway96there's an include_path variable which I can define to the kernel headers. Question is, what path should I use?23:50
robbawebba${STAGING_KERNEL_DIR} might be what you're looking for23:51
noway96it's empty inside the devshell23:52
robbawebbashoot, that might only be available to kernel recipes :/23:53
robbawebbanoway96: huh, I'm definitley seeingnon-kernel bb recipes and classes use the KERNEL_STAGING_DIR variable23:55
noway96PREFIX = os.path.normpath(sys.prefix).replace( os.getenv("BUILD_SYS"), os.getenv("HOST_SYS") )23:55
noway96TypeError: expected a string or other character buffer object23:56
noway96So I need to set some variable in my recipe?23:56
robbawebbano, that's usually set by the kernel recipe I believe23:56
noway96can I set it? Is it BUILD_SYS ?= "" or something?23:57
robbawebbaso you would use the ${STAGING_KERNEL_DIR} variable in your yourto recipe23:57
robbawebbayocto *23:57
robbawebbaI'm not sure if you can set it, without interfering with the kernel recipe at least23:57
robbawebbaI'm kind of lost for ideas at this point :/23:58
noway96unparsed line: 'BUILD_SYS = ${STAGING_KERNEL_DIR}'23:59
noway96let me just try to get to build inside the devshell23:59

Generated by 2.11.0 by Marius Gedminas - find it at!