Monday, 2019-11-04

*** goliath <goliath!> has quit IRC00:19
*** khem <khem!~khem@unaffiliated/khem> has joined #yocto00:37
*** yizhao <yizhao!~zhaoyi@> has joined #yocto01:01
*** ckalluri731 <ckalluri731!~ckalluri@2601:647:5b00:64f0:9903:9d60:27da:f63a> has quit IRC01:56
*** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has quit IRC02:54
*** d_thomas <d_thomas!cffae6c2@> has quit IRC03:41
*** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has joined #yocto04:52
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has joined #yocto05:16
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC05:22
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has joined #yocto05:59
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC06:04
*** kaspter <kaspter!~Instantbi@> has quit IRC06:11
*** kaspter <kaspter!~Instantbi@> has joined #yocto06:11
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has joined #yocto06:21
*** AndersD <AndersD!> has joined #yocto06:27
*** kaspter <kaspter!~Instantbi@> has quit IRC06:28
*** kaspter <kaspter!~Instantbi@> has joined #yocto06:28
*** Scoutboy <Scoutboy!> has quit IRC06:57
*** goliath <goliath!> has joined #yocto07:04
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC07:05
*** dv_ <dv_!> has quit IRC07:06
*** alessioigor <alessioigor!~alessioig@> has quit IRC07:12
*** alessioigor <alessioigor!~alessioig@> has joined #yocto07:15
*** agust <agust!> has joined #yocto07:15
*** dv_ <dv_!~dv@> has joined #yocto07:19
*** frsc <frsc!~frsc@2003:a:e7a:6200:246c:2a8b:f45a:a33d> has joined #yocto07:26
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has joined #yocto07:37
*** leon-anavi <leon-anavi!~Leon@> has joined #yocto07:48
*** kroon <kroon!~kroon@> has joined #yocto07:55
*** TobSnyder <TobSnyder!> has joined #yocto07:56
*** mckoan <mckoan!~marco@unaffiliated/mckoan> has joined #yocto08:00
mckoangood morning08:00
frosteyesmckoan: morning08:02
alessioigorgood morning08:23
kayterinahello hello08:23
*** goliath <goliath!> has quit IRC08:31
*** florian_kc <florian_kc!~florian_k@Maemo/community/contributor/florian> has joined #yocto08:51
*** Bunio_FH <Bunio_FH!> has joined #yocto09:09
*** goliath <goliath!~goliath@> has joined #yocto09:10
*** camus <camus!~Instantbi@> has joined #yocto09:12
*** lucaceresoli <lucaceresoli!> has joined #yocto09:12
*** kaspter <kaspter!~Instantbi@> has quit IRC09:14
*** camus is now known as kaspter09:14
*** rburton <rburton!> has joined #yocto09:24
*** T_UNIX <T_UNIX!uid218288@gateway/web/> has joined #yocto09:24
*** diego_r <diego_r!> has joined #yocto09:31
*** nayfe <nayfe!uid259604@gateway/web/> has joined #yocto09:48
*** bojones <bojones!> has quit IRC10:04
*** yann <yann!~yann@> has joined #yocto10:13
*** awe00 <awe00!~awe00@unaffiliated/awe00> has joined #yocto10:26
*** awe00 <awe00!~awe00@unaffiliated/awe00> has joined #yocto10:27
*** goliath <goliath!~goliath@> has quit IRC10:59
*** florian_kc <florian_kc!~florian_k@Maemo/community/contributor/florian> has quit IRC11:13
*** litb <litb!> has joined #yocto11:13
litbhello folks11:13
litbwhat is the meaning of ?= together with  override statements?11:13
litblike  FOO_myoverride ?= baz11:13
litbwill it be like "if Foo is not assigned yet, then if 'myoverride' is active, assign baz" ?11:14
mcfrisklitb: yes, allows recipe, appends and classes to override variables11:14
*** JaMa <JaMa!~martin@> has joined #yocto11:15
*** kanavin <kanavin!~kanavin@> has joined #yocto11:21
litbmcfrisk, thanks!11:25
litbwhat's the equivalent of a packagegroup for buildtime dependency grouping?11:26
*** hpsy <hpsy!~hpsy@> has quit IRC11:26
litbi have a "" that groups required libraries for the GUI. now I need to group build time dependencies. I would think packagegroup should be usable aswell, but I'm not sure11:27
*** hmw1 <hmw1!hmwmatrixo@gateway/shell/> has joined #yocto11:29
yoctiNew news from stackoverflow: In poky-tiny, why adding openssh also adds bash? <>11:30
*** berton <berton!~berton@> has joined #yocto11:33
rburtonlitb: ?= with overrides is meaningless11:34
litbrburton, oh11:34
rburtonat least, thats my understanding of how overrides are parsed.11:35
rburtonRP: ^11:35
litbrburton, I found instances in the manual that combine them both11:35
rburtonlets get RPs statement then we can either fix the docs or i've learnt something new already11:36
litbSRCREV_pn-matchbox-panel-2 ?= "${AUTOREV}"11:36
* rburton tests11:37
litbah at least that thing with SRCREV makes intuitive sense!11:37
rburtonright so i did PV_pn-m4 ?= "1.2.3"11:38
rburtonwhere bitbake.conf has PV=11:38
rburtonand the override took11:38
rburtonwhich you'd expect, no value already to it i assigned11:39
litbat first I was confused because it could also check whether there was already an override-assignment with that exact override flags, rather than only checking for the "base" variable11:39
rburtonok looks like it does what you'd expect, but that behaviour isn't really useful?11:39
litbmakes sense to me now11:40
rburtonin that you can't have conditional overrides.  the override *will* happen11:40
rburtonif you have multiple overrides set with ?= then they do chain in that the second ?= doesn't happen11:40
rburtoni guess that could be useful if you're layering pieces together11:41
litboh I see now. it checks for a previous assignment of the base-variable combined with the exact combination of overrides?11:42
*** berton <berton!~berton@> has quit IRC11:42
rburtonbitbake.conf does PV={take version from filename}11:42
rburtonif you do PV_override ?= "2" then if the override is triggered, that happens.11:42
*** kroon <kroon!~kroon@> has quit IRC11:42
rburtonanother PV_override ?= "3" doesn't override 2 to 311:43
*** berton <berton!~berton@> has joined #yocto11:43
litbwith potentially a different override even11:43
litbnot sure whether I expect  PV=...   PV_override ?= ,,,   to override the value set with "=". I guess I wouldn't11:44
rburtonthe entire point of an override is that it overrides the value11:44
litbhm, I see11:45
mcfriskAfter all the BSP bashing in Lyon, nice to be back at $work and start bashing BSP layer crap. BBMASK += "meta-*bsp*"11:54
letothe2ndmcfrisk: :)11:55
RPrburton: its not exactly useful11:55
*** goliath <goliath!> has joined #yocto12:00
*** kroon <kroon!~kroon@> has joined #yocto12:02
letothe2ndmcfrisk: but, there certainly was no bashing. just very polite, gentle reminders. with a sledge hammer.12:13
*** radsquirrel <radsquirrel!> has quit IRC12:14
*** radsquirrel <radsquirrel!> has joined #yocto12:15
*** kroon_ <kroon_!~kroon@> has joined #yocto12:16
*** kroon <kroon!~kroon@> has quit IRC12:17
*** kroon_ <kroon_!~kroon@> has quit IRC12:20
*** kroon <kroon!~kroon@> has joined #yocto12:20
*** Dracos-Carazza <Dracos-Carazza!> has quit IRC12:22
*** tgamblin <tgamblin!~tgamblin@> has joined #yocto12:49
litbmy package has a config "debug=0|1", "context=release|develop" and a GUI can be included or not (which will add "gui" at compile time and "install-gui" at install time).12:51
*** jmiehe <jmiehe!> has joined #yocto12:53
litbis it a bad idea to "abuse" PACKAGECONFIG for this? the individual groups will then be empty like "PACKAGECONFIG[debug] = ",,". individual variables will query PACKAGECONFIG, like    GUI_INSTALLFLAG = "${@oe.utils.contains('PACKAGECONFIG', 'gui', 'install-gui', '')}"12:53
litband they will be passed in do_compile and do_install such as    "./buildscript  ${GUI_INSTALLFLAG} dest=${D}"  in do_install12:54
*** Dracos-Carazza <Dracos-Carazza!> has joined #yocto13:01
letothe2ndlitb: its certainly a way of getting it done. one would probably not do this in a public upstream layer but if it suits your usecase, why not13:01
letothe2ndlitb: i'd add that it depends a bit on if you have more packages behaving like that, and if you need to be able to tune them independently. otherwise it might be simpler to add a distro flag like "mycompany-debugtweaks"13:03
litbhm, I see.13:03
letothe2ndso, "it depends" (TM)13:03
* mcfrisk rants: why would a BSP layer set GCCVERSION?!13:07
* mcfrisk rants: it only results in a huge list of: NOTE: preferred version 8.2% of gcc-runtime not available (for item gcc-runtime)13:09
letothe2ndmcfrisk: because $VENDORKERNEL or $VERNDORBOOTLOADER need $OLDGCC to even build13:09
letothe2nda true classic13:09
mcfriskexcept that they dont :)13:10
letothe2ndthere's always the possibility that its just a crappy bsp13:10
mcfriskand I need to explain why mixing clang and gcc for kernel and external kernel modules is "a bad idea (TM)"13:11
nayfeHi any meta-java maintainer here or news about Richard Leitner? or maybe openjre is not embedded jre choice now? ;)13:13
qschulzmcfrisk: can I ask how this clang+gcc mixing is handled in your Yocto? I'm interested in having IRL examples on how people implemented this to find the best way to do it13:14
letothe2ndnayfe: did you reach out for him by mail? thats usually his favorite way of interaction, IIRC13:14
mcfriskqschulz: inherit clang in recipes, meta-clang as layers. switch from default toolchain gcc to clang using that inherit.13:16
mcfriskoh, TOOLCHAIN = "clang" is needed too in the recipes.13:18
nayfeletothe2nd> mails on openembedded-devel with meta-java prefix and maintainers in CC do not get answers, it's been a while layer had no activity13:19
letothe2ndnayfe: hm i'm quite sure i readhim in the last couple of weeks13:21
*** tprrt <tprrt!~tprrt@> has joined #yocto13:22
letothe2ndbu tno time to go searching right now, sorry.13:22
qschulzmcfrisk: ok thanks13:24
*** florian_kc <florian_kc!~florian_k@Maemo/community/contributor/florian> has joined #yocto13:26
*** la_croix <la_croix!> has quit IRC13:28
litbhaving the paragraph-character available helps quite a lot when searching in the manual13:28
litboften I have to copy the paragraph character out of the manual and paste it into the firefox search field.13:29
litbI guess I  should install some "enter unicode character" plugin for this13:29
rburtonlitb: most environments have a character picker hidden away13:33
*** la_croix <la_croix!> has joined #yocto13:34
*** mihai <mihai!~mihai@unaffiliated/mihai> has joined #yocto13:35
*** kroon <kroon!~kroon@> has quit IRC13:40
*** d_thomas <d_thomas!cffae6c2@> has joined #yocto13:43
litbis it a good idea to use weak default assignments "??=" in classes, and normal default assignments "?=" in .bb files?  That way, bb files can override choices of classes, but  distribs/local.confs can override choices of recipes13:44
*** mrc3 <mrc3!~mrc3@linaro/mrc3> has joined #yocto13:49
mcfrisklitb: sounds good to me13:52
*** AndersD <AndersD!> has quit IRC14:04
*** nslu2-log <nslu2-log!> has quit IRC14:11
litbsorry, another question! I see class names that contain dashes, but also underscores over the place in the oe-core layer14:12
litbwhat's the guideline? I wish to use EXPORT_FUNCTIONS, and I suspect it requires the class name to not contain dashes. but beyond that?14:13
rburtonwhy do you want to use EXPORT_FUNCTIONS?14:15
litbrburton, i wrote a class company_scons.bbclass  that executes scons with a defined set of targets at compile time and install tim14:18
rburtonthats good14:18
rburtonso why do you want to use EXPORT_FUNCTIONS?14:18
*** copycat88 <copycat88!~copy@> has joined #yocto14:19
litbthe set of targets can be defined as  SCONS_COMPANY_TARGETS  and do_install   takes the targets and prefixes them with 'install-' and passes those as targets14:19
litbrburton, i wanna provide them as default implementations14:19
rburtonas in so a recipe can do do_install() { something; company_scons_do_install ; somethingelse}14:20
rburton99% of people who write export_functions in a class don't know what it actually does you see14:21
litbhm, maybe it's not worth it. I suspect I can just define do_install()  and if the user overrides it, they can just use my   scons_company_runscons <myowntargets>14:21
rburtonuse it if you want, i just wanted to check that you understood what it does14:22
litbrburton, I think of it as providing a  do_install() { company_scons_do_install; }  . but now I see I don't really need it14:22
rburtonsome people think it means 'make this function public' and to be honest given the name that makes sense14:23
litbhm, I see. I think I fell into this trap before14:24
litbrburton, I think this task of providing default implementations of do_install that call a classes' function cannot be provided by another class, i.e "exportfunctions.bbclass" ?14:27
alessioigorHas someone idea why few BSP (e.g. meta-ti) seems to ignore the .cfg snippets to change Linux kernel configuration?14:27
rburtonalessioigor: because the maintainers of those kernels use a defconfig instead of the kernel fragments framework14:27
letothe2ndalessioigor: IIRC that happens if a kernel is not yocto-ized14:28
rburtonas to why they do that, ask them14:28
alessioigorAlso meta-intel does it :-(14:29
alessioigorrburton, letothe2nd: Thanks14:29
*** nslu2-log <nslu2-log!> has joined #yocto14:33
qschulzrburton: two included fragments can collide and disable one another, while defconfig guarantees it works well with Kconfig.14:34
rburtonwhy not ship a known good configuration using fragments and then say if you fiddle the config then obviously its your problem14:36
rburtoni doubt they'll support someone fiddling the defconfig randomly either14:36
rburtonanyway, because they wanted to use a defconfig is the answer.14:36
rburtonalessioigor: what kernel in meta-intel uses defconfig?14:36
*** leitao <leitao!~leitao@2620:10d:c092:200::1:d18d> has joined #yocto14:38
alessioigorrburton: Seems none14:39
*** elGamal <elGamal!~elg@> has quit IRC14:39
*** elGamal <elGamal!~elg@> has joined #yocto14:40
alessioigorrburton: linux-ti-staging (meta-ti) uses defconfig whereas linux-intel (meta-intel) my cfg snippet collides with ERNEL_EXTRA_FEATURES ?= "features/netfilter/netfilter.scc features/security/security.scc"14:42
alessioigorInfact I'm trying to turn off netfilter.14:43
rburtonalessioigor: unset extra-features?14:45
alessioigorrburton: Yes but I don't know how do the same for linux-ti-staging... Do you have any hint?14:46
rburtonalessioigor: for meta-ti, write your own defconfig14:47
qschulzalessioigor: it's fine. run a build without your changes. then run bitbake -c menuconfig linux-ti-staging14:49
qschulzdisable what you need, bitbake -c savedefconfig linux-ti-staging, go to the workdir, get the defconfig in the root of ${S} (usually)14:50
alessioigorqschulz: Ok thanks14:50
qschulzput this defconfig where the recipe expects it (or in a bbappend which adds the required logic of loading a defconfig)14:50
*** TobSnyder <TobSnyder!> has quit IRC14:52
d_thomasHello, I'm trying to upgrade the version of u-boot Yocto is building by using a recipe in my own custom layer.  I have verified the recipe builds v2019.04 when placed in the meta-atmel layer.  When I put the recipe in my own layer, the meta-atmel layer version of v2018.07 is built.  I think the problem is the "require" statement.  How do I proper14:53
d_thomasrequire/include a file from meta-atmel in my own layer?14:53
letothe2ndd_thomas: require and put the full path in. if it doesn't give you an error, it was successful14:53
letothe2ndd_thomas: include is the same, but will fail silently14:54
letothe2nd(which is usually not what you want)14:54
qschulzd_thomas: shouldn't this be part of a bbappend?14:54
*** AndersD <AndersD!> has joined #yocto14:54
d_thomasI'm seeing "Could not include required file meta-atmel/recipes-bsp/u-boot/".  If I remove the meta-atmel part it silently uses the old version.14:55
d_thomasI went with a bb file since it is a new version, based on a different git commit.  Seemed cleaner that way.  Otherwise the bbappend name wouldn't match the actual version14:56
qschulzyup, understood. That's what you should do indeed14:57
qschulzyou cannot put the name of a layer in the path, Yocto looks from the root of every layer, not elsewhere14:57
letothe2ndyeah, and the version without the meta-atmel is correct. but, this means you have the file twice, under the exact same path?14:57
qschulzrequire recipes-bsp/u-boot/ is ok14:57
letothe2ndinside the layers, that is?14:57
d_thomasMy intention is that will only be in my layer (2018.07 is currently in the meta-atmel layer)14:58
qschulzletothe2nd: I suspect a PREFERRED_VERSION somewhere?14:59
d_thomasI put in the meta-atmel layer only temporarily to verify that the recipe was correct and that nothing was forcing a preferred version14:59
letothe2ndqschulz: i did the same, but $ASKER claims there is none14:59
d_thomasCorrect, so far I can't find anything forcing a version15:00
*** copycat88 <copycat88!~copy@> has quit IRC15:00
letothe2ndlike i said last time, i'm sure it is something rather stupid/weird, but i can't put my finger on it at the moment15:01
letothe2ndwhy do you need meta-atmel then anyways?15:01
d_thomasSame here :).  As soon as I switch to "require recipes-bsp/u-boot/", the build proceeds without complaint but ignores v2019.0715:02
d_thomasI need meta-atmel for the development kit I'm building the image for15:02
qschulzd_thomas: that is normal, all recipes are parsed even if they are not to be compiled or used in any way.15:02
qschulzd_thomas: debug with bitbake u-boot-at91 -DDDDDDDDDDDDDDDDDDDDDDDDDDDDD and maybe that'll help find out something?15:03
qschulz(I never remember how many D's are needed, so I just put as many as my patience let me15:04
d_thomaswow, that's verbose turned up to 1115:05
*** jmiehe <jmiehe!> has quit IRC15:10
d_thomasThat's disappointing.  The log just shows the sorted providers for u-boot are just the latest one from meta-atmel15:12
letothe2ndd_thomas: can you just put your layer on github or such?15:13
d_thomasThat's the recipe15:15
letothe2ndi don't think that the recipe in itself is the problem15:16
d_thomasin a meta-my-custom-layer/recipes-bsp/u-boot directory15:16
letothe2ndi have no better advice at the moment other to make a fresh layer, add just the u-boot and start out testing from there. remove your other custom layer for the build, see if it works or breals.15:17
d_thomasI know my custom layer is getting used, because I had to modify the AT91Bootstrap bootloader to build the way I wanted in Yocto.  So that bbappend file is working15:17
letothe2ndand if it breaks, show the whole minimized layer15:17
*** leitao <leitao!~leitao@2620:10d:c092:200::1:d18d> has quit IRC15:17
d_thomasthere just isn't much else in the layer..... the bootloader bbappend, a hello world program, and u-boot15:18
letothe2ndthen, put it on github.15:18
letothe2ndif there's nothing magic inside15:19
*** leitao <leitao!~leitao@2620:10d:c092:200::1:d18d> has joined #yocto15:19
*** tgoodwin <tgoodwin!> has quit IRC15:30
d_thomasIs it possible I just need to rebuild the entire image and not just u-boot?15:32
*** ericch <ericch!> has joined #yocto15:38
d_thomasBefore posting the repo to github, I'd need to scrub out my ssh configuration.  But it's just a basic layer I'm building that I don't see how that would be breaking anything.  Seemed like I just needed to get the directory and filename convention correct and this should have worked.15:38
denixrburton: meta-ti uses config fragments15:39
denixbut not linux-yocto specific "scc"15:39
letothe2ndd_thomas: if you keep ssh configuretion inside the layer its a bad idea anyways :P15:40
d_thomasMoving it is on the list of things to do.  This was just to get an image going that was usable for others15:41
d_thomasGetting Yocto to build u-boot, kernel, etc is just for my own sanity. :]15:42
letothe2ndd_thomas: whatever. i already invested a substantial amount of time trying to help you, which is fine. but my patience is used up by now - either i can see the whole thing, or' i'm just out.15:42
qschulzletothe2nd: I'm new to this but... what's the impact of layer priorities in figuring out which recipe to pick?15:42
qschulzbecause that might explain why an older version gets picked up?15:43
qschulzjust throwing ideas15:43
letothe2ndqschulz: AFAIK none, it should just kick in if things collide, but i might be wrong. yet, with a complete layer i can try and reproduce. which i am also willing to do, but no more poking.15:44
qschulzletothe2nd: ah found it!15:45
qschulz"The precedence established through this variable stands regardless of a recipe's version (PV variable)"15:45
qschulzd_thomas: ^15:46
d_thomasAh, so my layer needs to be on the same priority level as meta-atmel?  Thanks, I'll give that a try15:46
d_thomasoh weird, meta-atmel is 10 and I'm at 615:47
letothe2nd(we could easily have looked at it if the layer was up)15:48
d_thomasIt was the priority15:51
d_thomasSorry letothe2nd.  I think long term I could put my changes into a meta-atmel into a public layer and the secret sauce into a private layer15:52
*** AndersD <AndersD!> has quit IRC15:53
*** frsc <frsc!~frsc@2003:a:e7a:6200:246c:2a8b:f45a:a33d> has quit IRC15:53
*** tgamblin <tgamblin!~tgamblin@> has quit IRC15:53
*** tgamblin <tgamblin!~tgamblin@> has joined #yocto15:55
qschulzd_thomas: maybe worth noting that, IIRC, this does not apply to bbclasses, where the first occurence of the bbclass in BBLAYERS to be found is the one taken15:57
qschulzto be taken with a grain of salt and experimentation :)15:57
*** tprrt <tprrt!~tprrt@> has quit IRC15:57
*** varjag <varjag!> has quit IRC15:58
d_thomasqschulz: interesting, good to know16:00
*** leitao <leitao!~leitao@2620:10d:c092:200::1:d18d> has quit IRC16:02
RPqschulz: pretty sure classes are searched for using BBPATH16:03
*** stephano <stephano!> has joined #yocto16:10
*** goliath <goliath!> has quit IRC16:10
litbqschulz, at least if metadata that comes before yours in BBLAYERS inherits a class that you want to override in yours, then the "wrong" bbclass is taken16:11
litbthat happened for me16:11
litbRP, ah, for classes the priority it completely ignored?16:11
RPlitb: not sure priority makes sense for classes16:13
kergothah the old 'bblayers order' vs bbfile priority thing pops up again :)16:13
RPkergoth: part of me wants to delete a load of these variables16:14
letothe2ndRP: gogogo!16:14
kergothit's tempting for sure. we have so much legacy stuff in all of this. i can't imagine many folks use bbpath+bbfiles to set up anymore16:14
*** vmeson <vmeson!> has joined #yocto16:15
litbBTW sometimes I write'foo'):  and i have seen others that do that16:15
letothe2ndRP: here something to get you started:
kergothonly the metadata knows what's been inherited, not the global python module :)16:15
kergothglobals aren't nice16:15
litbmaybe it would be cool if there is a   _bbclass-<name>  override for each class inherited.  then some of those checks could go16:15
RPlitb: each override slows down parsing. Are you sure you'd want to do that?16:19
RPbetter would be d.inherits()16:19
litbin fact, it would be natural if the  override  was  _class-<name>  because it would be compatible with the BBCLASSEXTEND names, afaics16:19
litbRP, hm, I see16:20
*** gaulishcoin <gaulishcoin!> has joined #yocto16:20
rburtoninherits() is fairly common16:24
*** cp <cp!> has quit IRC16:29
*** cp <cp!> has joined #yocto16:29
RPI mused at the OE meeting about a) fixing bitbake memres b) making it default c) making some kind of layer setup support in bitbake d) requiring it for eSDK e) replacing eSDK with that simpler mechanism (and simplifying selftests to use it )16:31
*** jmiehe <jmiehe!> has joined #yocto16:33
*** Sandrita <Sandrita!d0586e2e@gateway/web/cgi-irc/> has joined #yocto16:34
*** Bunio_FH <Bunio_FH!> has quit IRC16:38
*** Sandrita <Sandrita!d0586e2e@gateway/web/cgi-irc/> has quit IRC16:40
*** rburton <rburton!> has quit IRC16:47
*** jmiehe <jmiehe!> has quit IRC16:47
*** rburton <rburton!> has joined #yocto16:48
*** jmiehe <jmiehe!> has joined #yocto16:48
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC16:49
*** vineela <vineela!~vtummala@> has joined #yocto16:50
*** goliath <goliath!> has joined #yocto16:50
*** florian_kc <florian_kc!~florian_k@Maemo/community/contributor/florian> has quit IRC16:52
*** jmiehe <jmiehe!> has joined #yocto16:53
*** awe00 <awe00!~awe00@unaffiliated/awe00> has quit IRC17:00
kanavinrburton, RP - a colleague wrote a tool that would print 'critical paths' of Yocto builds:
kanavinI am now convincing them to rewrite it in python, so it can be merged into buildstats directly17:02
rburtoni've something here somewhere that probably isn't as good :)17:03
kanavinrburton, they didn't ask me about the unfortunate choice of implementation language :(17:03
kanavinboost as well!17:03
kanavinbut their approch is based on computer science: they implement a well proven algorithm17:04
*** mihai <mihai!~mihai@unaffiliated/mihai> has quit IRC17:05
RPkanavin: nice, I've always just looked at the graph :)17:06
*** diego_r <diego_r!> has quit IRC17:11
*** lpapp <lpapp!~lpapp@kde/lpapp> has joined #yocto17:17
lpapphi, is supposed to run on boot from meta?17:17
lpappit seems that it fails at this condition in our case: [ -f /etc/modules ] || [ -d /etc/modules-load.d ] || exit 017:17
lpappso it skips the rest, like important depmod, etc.17:17
*** jmiehe <jmiehe!> has quit IRC17:18
lpappis it reasonable my  board has neither /etc/modules, nor /etc/modules-load.d17:18
*** goliath <goliath!> has quit IRC17:24
*** mckoan is now known as mckoan|away17:24
*** mabnhdev <mabnhdev!0c260e0a@> has joined #yocto17:25
*** tgoodwin <tgoodwin!> has joined #yocto17:32
mabnhdevI'm upgrading my work to Zeus.  I have a custom kernel which has to remain at 4.14 for the time being.  I've defined my own Linux recipe modeled after linux-yocto.  This has been working fine for me since Sumo.  However, I'm now seeing failures in my perf build.  My failure log is here -17:34
mabnhdev  Any guidance on addressing this issue would be appreciated.17:34
litbmabnhdev, not sure, but it appears that it doesn't like your python version?17:42
*** JaMa is now known as Guest5847117:45
*** JaMa <JaMa!~martin@> has joined #yocto17:45
mabnhdevlitb Yes, I added NO_LIBPERL=1 NO_LIBPYTHON=1 to EXTRA_OEMAKE and it complains less.  But those warnings are still there and it now fails in do_install.  I'm not sure that's the right way to go, though.17:45
*** WillMiles <WillMiles!> has joined #yocto17:47
*** yann <yann!~yann@> has quit IRC17:48
mabnhdevHere's the failure with NO_LIBPERL=1 NO_LIBPYTHON=1:
litbmabnhdev, another parameter says PYTHON=python3 . dunno whether or not that contradicts NO_LIBPYTHON=117:57
litbmabnhdev, maybe the shebang line in that script is too long for your kernel to interpret. I once read some code in yocto that tried to minimize this path length18:02
litbideally it would rely on PATH, instead of having an absolute pathname. maybe do_devshell could help18:02
zeddiimabnhdev: it would be interesting to hear if some of the mismatched header file warnings go away if you cherry-pick a commit on master to your branch. might not help, but you never know.18:13
zeddiisee: perf: drop 'include' copy18:14
zeddiialso, it might be possible that 4.14 is just to old to support the python3 only build, I’d have to double check when that transition was made.18:14
zeddiiin that case, you might have to revert the python3 changes in zeus and take your chances with the python 2.7 EOL18:14
mabnhdev@zeddii - I should have both python 2.7 and python3 defined.  I'll have to check that.  I actually only need python 2.7, but including python3 was always the path of least resistence.18:16
*** falstaff <falstaff!~quassel@> has quit IRC18:16
*** thannoy <thannoy!> has joined #yocto18:26
*** goliath <goliath!> has joined #yocto18:35
zeddiithe point is that we integrated patches in zeus to go to python3 only for the kernel bits, towards the goal of not having python3 in the release.18:37
zeddiibut if the kernel is too old to fully support python3 perf, you’d have to revert those, or come up with your own patches, etc.18:38
*** litb <litb!> has quit IRC18:47
*** yann <yann!> has joined #yocto18:48
mabnhdevzeddii Ah.  Understood.  Is perf a "required" package?  Can I just get rid of it to move forward?18:50
zeddiiyep. you definitely can.18:51
JaMamabnhdev: do you have in your build?18:51
*** awe00 <awe00!~awe00@unaffiliated/awe00> has joined #yocto18:52
*** T_UNIX <T_UNIX!uid218288@gateway/web/> has quit IRC18:53
mabnhdevJaMa: Yes, I do have that patch in my build.18:54
*** gaulishcoin <gaulishcoin!> has quit IRC19:21
*** florian_kc <florian_kc!~florian_k@Maemo/community/contributor/florian> has joined #yocto19:52
*** WillMiles <WillMiles!> has quit IRC20:03
*** tgamblin <tgamblin!~tgamblin@> has quit IRC20:12
*** thannoy_ <thannoy_!> has joined #yocto20:12
*** thannoy <thannoy!> has quit IRC20:12
letothe2ndqschulz: you around? did you get to talk to khem?20:19
*** florian_kc is now known as florian20:21
*** Sandrita <Sandrita!d0586e2e@gateway/web/cgi-irc/> has joined #yocto20:55
*** berton <berton!~berton@> has quit IRC21:15
*** goliath <goliath!> has quit IRC21:26
*** Sandrita <Sandrita!d0586e2e@gateway/web/cgi-irc/> has quit IRC21:37
*** MiskaX <MiskaX!> has joined #yocto21:57
*** JaMa <JaMa!~martin@> has quit IRC22:04
*** diego_r <diego_r!~diego@> has joined #yocto22:21
*** marler8997 <marler8997!> has joined #yocto22:23
marler8997I'm not sure what I'm missing here22:23
marler8997I'm creating a recipe meant to be used as a tool during the build22:23
marler8997it depends on openssl, so I add it as an RDEPENDS22:24
marler8997but openssl doesn't get installed to the sysroot when I build mytool-native22:24
marler8997I've minimized what I'm trying to do into these to small recipes:
marler8997I would think that if you added RDEPENDS to a recipe, that it would install those dependencies into the sysroot?22:37
marler8997if you are building the "*-native" version of the recipe22:37
khemrdeps are used when building images or doing package installs22:39
khemif something is needed during build then use depends = ...22:39
marler8997but this is an indirect dependency22:39
marler8997A DEPENDS on B22:40
marler8997well, A DEPENDS on B-native22:40
marler8997and B has RDEPENDS22:40
marler8997so, I would think that if you want to use B-native, which gets installed to the sysroot, then you would need the RDPENDS of B22:41
marler8997Otherwise, you would need to write a different recipe for both B and B-native right?22:41
khemnot really you can use class-native override22:42
marler8997so you're saying I should do this:22:42
marler8997DEPENDS_class-native = "bash coreutils openssl"22:42
marler8997RDEPENDS_${PN} = "bash coreutils openssl"?22:43
khemrdeps are encoded into packages ( rpms, ipk etx metadata) since there are no output packages for native packages rdeps might go unnotices22:45
marler8997Actually, it would be: DEPENDS_class-native = "bash-native coreutils-native openssl-native"22:45
marler8997right, I understand what's goin on, I just don't understand the right way to do this22:46
marler8997I want to write a recipe that works both with "-native" and without "-native".   I would think I could configure the same dependencies for both22:46
khemDEPENDS_class-native = "bash-native coreutils-native openssl-native" seems fine22:46
marler8997but that doesn't seem right does it?22:46
marler8997Now I have to code the same dependencies twice22:47
marler8997DEPENDS_class-native = "bash-native coreutils-native openssl-native" and then RDEPENDS_${PN} = "bash coreutils openssl"22:47
marler8997is that really the right way to do this?22:47
khemusually rdeps are built too so I am sure it should be building the rdeps but it might not be staging them for native package sysroots22:49
marler8997the RDEPS are not availible in the sysroot so my recipe that depends on openssl-wrapper-native fails because openssl isn't installed to the sysroot22:49
marler8997I know I can add DEPENDS += "openssl"22:50
marler8997but that doesn't seem correct22:50
marler8997I mean DEPENDS += "openssl-native"22:50
marler8997am I really supposed to configure the same dependencies twice...once for when it is installed to the sysroot and one for when it is installed to the target rootfs?22:51
*** diego_r <diego_r!~diego@> has quit IRC22:54
khemrdeps are target specific22:54
marler8997right, I understand what RDEPENDS does22:55
marler8997it causes the packages listed to be installed when you install the PN from RDEPENDS_PN22:55
marler8997in the example I posted, what is the right way to configure so it works both natively and on the target22:56
marler8997openssl-wrapper is just creating a bash script that called openssl22:56
marler8997so it requires both bash and openssl to be installed22:56
marler8997the only way I know how to make that work both natively and on the target is to use DEPENDS += "bash-native openssl-native" and RDEPENDS_${PN} += "bash openssl"22:57
khemrdeps should get mapped to native as well22:57
marler8997but that doesn't seem right22:57
marler8997right, it would get mapped to native22:58
marler8997but sysroot doesn't use packages22:58
marler8997it uses SYSROOT_DIRS for normal recipes and SYSROOT_DIRS_NATIVE for "*-native" recipes22:58
marler8997SYSROOT_DIRS uses common library directories and SYSROOT_DIRS_NATIVE uses common bin/config directories22:59
marler8997it took me a while to realize that the sysroot is populated completely differently from the packages22:59
marler8997and that sysroot uses DEPENDS and the packages use RDEPENDS23:00
*** goliath <goliath!> has joined #yocto23:01
marler8997at least that's how I understand it, when I think about it more, it seems like "*-native" packages should actualy be using RDEPENDS to know which "*-native" packages it depends on...but that doesn't seem to be the case in my example23:01
*** awe00 <awe00!~awe00@unaffiliated/awe00> has quit IRC23:06
marler8997it seems very odd to me that there are 2 different systems for "native runtime dependencies" and "target runtime dependencies"23:12
marler8997as I see it, this comes from the fact that the sysroot is populated differently from the target rootfs23:12
marler8997if sysroot was populated from the packages, then this would work as expected23:13
*** BobPungartnik <BobPungartnik!~BobPungar@> has joined #yocto23:13
*** ecdhe <ecdhe!~quassel@unaffiliated/ecdhe> has quit IRC23:14
*** leon-anavi <leon-anavi!~Leon@> has quit IRC23:20
khemopenssl seems to not have option -v so maybe you want to use something like 'help'23:20
khemand perhaps thats what the problem is23:20
*** BobPungartnik <BobPungartnik!~BobPungar@> has quit IRC23:20
*** agust <agust!> has quit IRC23:29
marler8997the problem is it can't find openssl23:33
marler8997because it's not being installed to the sysroot23:33
marler8997but when I add DEPENDS_class-native += "openssl-native", then it does get installed to the sysroot23:33
*** stephano <stephano!> has quit IRC23:37
*** ecdhe <ecdhe!~quassel@unaffiliated/ecdhe> has joined #yocto23:38
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC23:47
*** nslu2-log <nslu2-log!> has quit IRC23:49
*** thannoy_ <thannoy_!> has quit IRC23:52

Generated by 2.11.0 by Marius Gedminas - find it at!