Thursday, 2016-08-18

*** sameo <sameo!samuel@nat/intel/x-uhogtnavhkdajppp> has quit IRC00:01
*** igor2 <igor2!~igor@> has quit IRC00:06
*** JohnniePeters <JohnniePeters!c66941c5@gateway/web/freenode/ip.> has quit IRC00:11
*** jbrianceau_away <jbrianceau_away!uid10952@gateway/web/> has quit IRC00:29
*** slidercrank <slidercrank!~slidercra@unaffiliated/slidercrank> has quit IRC00:34
*** nighty <nighty!> has joined #yocto00:38
*** dvhart <dvhart!~dvhart@> has quit IRC00:40
*** dreyna <dreyna!> has joined #yocto01:11
*** Nilesh_ <Nilesh_!uid116340@gateway/web/> has joined #yocto01:27
*** slidercrank <slidercrank!~slidercra@unaffiliated/slidercrank> has joined #yocto01:43
*** billr <billr!wcrandle@nat/intel/x-erdgztlocfbeemdi> has quit IRC01:54
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto03:04
*** slidercrank <slidercrank!~slidercra@unaffiliated/slidercrank> has quit IRC03:06
*** blueness <blueness!~blueness@gentoo/developer/blueness> has quit IRC03:17
*** AgentElrond <AgentElrond!> has joined #yocto03:31
*** boucman_work <boucman_work!> has quit IRC03:56
*** dvhart <dvhart!~dvhart@> has joined #yocto04:20
*** blueness <blueness!~blueness@gentoo/developer/blueness> has joined #yocto04:22
*** dreyna <dreyna!> has quit IRC04:31
*** vmesons <vmesons!> has quit IRC04:59
*** dvhart <dvhart!~dvhart@> has quit IRC05:11
*** AgentElrond <AgentElrond!> has quit IRC05:13
*** zeddii_home_ <zeddii_home_!> has joined #yocto05:14
*** zeddii_home <zeddii_home!> has quit IRC05:17
*** zeddii_home_ is now known as zeddii_home05:17
*** t0mmy <t0mmy!> has joined #yocto05:28
*** Girafferson <Girafferson!~Giraffers@2601:281:8500:95b0:5249:f3c:d4e2:30a9> has joined #yocto05:33
*** dreyna <dreyna!> has joined #yocto05:38
*** t0mmy <t0mmy!> has quit IRC05:39
*** gtristan <gtristan!~tristanva@> has quit IRC05:47
*** dreyna <dreyna!> has quit IRC05:48
*** AgentElrond <AgentElrond!> has joined #yocto05:58
*** t0mmy <t0mmy!> has joined #yocto06:06
*** gtristan <gtristan!~tristanva@> has joined #yocto06:08
*** AgentElrond <AgentElrond!> has quit IRC06:20
*** hamis_lt_u <hamis_lt_u!~irfan@> has joined #yocto06:26
*** blueness <blueness!~blueness@gentoo/developer/blueness> has quit IRC06:30
*** blueness <blueness!~blueness@gentoo/developer/blueness> has joined #yocto06:31
*** eduardas_m <eduardas_m!~eduardas_@> has joined #yocto06:33
*** qt-x <qt-x!~Thunderbi@> has joined #yocto06:43
*** jbrianceau_away <jbrianceau_away!uid10952@gateway/web/> has joined #yocto06:43
*** jbrianceau_away is now known as jbrianceau06:44
*** fl0v0 <fl0v0!> has joined #yocto06:54
*** agust <agust!> has joined #yocto06:58
*** jku <jku!jku@nat/intel/x-gxiicgvkpsrbdvxo> has joined #yocto06:59
*** boucman_work <boucman_work!> has joined #yocto07:06
*** sno <sno!> has quit IRC07:07
*** rajm <rajm!> has joined #yocto07:11
*** joseppc <joseppc!~josep@linaro/joseppc> has quit IRC07:12
*** AgentElrond <AgentElrond!> has joined #yocto07:12
*** Kakounet <Kakounet!58a35735@gateway/web/freenode/ip.> has joined #yocto07:13
*** t0mmy <t0mmy!> has quit IRC07:14
*** florian <florian!~fuchs@Maemo/community/contributor/florian> has joined #yocto07:16
*** jku <jku!jku@nat/intel/x-gxiicgvkpsrbdvxo> has left #yocto07:17
*** jku <jku!jku@nat/intel/x-gxiicgvkpsrbdvxo> has joined #yocto07:19
*** slidercrank <slidercrank!~slidercra@unaffiliated/slidercrank> has joined #yocto07:19
KakounetHi all, here is my question : I want to have "brctl" command to bridge ethernet and bluetooth, what is your advise to make it ? I tried to use "bride-utils" that is in "meta-networking", but it doesn't want to compile (the dependencies are ok)... Is there a simplier solution than to use meta-networking ? Thanks !07:20
*** AgentElrond <AgentElrond!> has left #yocto07:21
boucman_workKakounet: meta-networking is probably the way to go... why doesn't it compile ?07:22
boucman_work(and what version of yocto are you using ?)07:22
LetoThe2ndKakounet: although bride-utils is a wonderful typo, meta-networking should be fine. have you checked that you are not mixing up branches? what is the compile error you see?07:22
boucman_workLetoThe2nd: hehe07:23
KakounetERROR: Failed to parse recipe: /home/architech/architech_sdk/architech/hachiko/yocto/poky/meta-openembedded/meta-oe/recipes-support/libsoc/libsoc_0.8.1.bb07:23
boucman_workthat's weird...07:24
KakounetERROR: Error executing a python function in <code>:07:24
Kakounet...and a lot of lines07:24
*** Crofton <Crofton!~Crofton@> has joined #yocto07:24
boucman_workcould you pastebin those lines somewhere ? what version of yocto and meta-networking are you using ?07:24
KakounetDo you have the command to know the version of yocto plz :)07:26
LetoThe2ndKakounet: so you're either on krogoth or master, right? on purpose?07:26
LetoThe2ndKakounet: plus, the path suggests that you cloned meta-oe beneath your poky directory, with is certainly a bad practise.07:27
*** Crofton <Crofton!~Crofton@> has quit IRC07:27
*** Crofton <Crofton!~Crofton@> has joined #yocto07:28
LetoThe2nd14.04 not validated? that sounds like you are some super ancient thing....07:28
* Kakounet is kind of a yocto begginner :)07:28
LetoThe2ndKakounet: let me guess, and you are starting out with some tarball blob that you received from your board distributor?07:28
KakounetI'm using a virtual machine that has been given by a board distributor yes :) It's Architech07:29
KakounetHachiko board :)07:29
LetoThe2ndKakounet: first of all, i'd suggest carefully walking through the yocto quick start tutorial to learn the super basics07:29
LetoThe2ndKakounet: you're basically running into a version mismatch between the poky version that your supplier baked into that VM and meta-oe, which you just cloned into master07:30
LetoThe2ndKakounet: so the fix is to find out the poky version they are supplying, and then switch to the corresponding branch on the meta-oe checkout.07:31
boucman_workmy guess would be meta-oe (master) uses python3 whereas your provider's yocto uses an older version (python2)07:31
KakounetI read a white book made by french guys (I'm french) the "Smile" company. It's super basic... But ok I will read the yocto quick start07:31
Kakounetah ok, cool, it's a version mismatch, Ok I can dig in that direction07:32
LetoThe2ndKakounet: and to get your terminology right: you are not using yocto, you are using poky, which is provided by the yocto project.07:33
* boucman_work works there, the author is my neighbour :P07:33
LetoThe2ndboucman_work: ok, now you're basically FLS.07:34
boucman_workFLS ?07:34
LetoThe2ndboucman_work: First Level Support07:34
KakounetOkay ! Thanks for those elements, it's really helpful. And ok I will get my terminology right ;)07:35
boucman_workLetoThe2nd: TBH, that's one of the services my company provides, but most board providers do a horrendous job of supporting Yocto. Old versions that they absolutely refuse to upgrade, most of them don't know what a recipe is... their documentation is minimalist (on board compilation, wtf)07:36
LetoThe2ndboucman_work: ack.07:37
*** yann <yann!> has quit IRC07:38
*** joshuagl <joshuagl!joshuagl@nat/intel/x-kuriquijjocgfglg> has joined #yocto07:38
*** raymanfx <raymanfx!raymanfx@gateway/shell/> has joined #yocto07:39
LetoThe2ndboucman_work: suggesting customers to compile in a VM sounds like abuse on purpose anyways.07:39
raymanfxHello everyone07:39
boucman_workyeah, but it's very common07:39
raymanfxI have a quick question regarding the SDK07:40
boucman_workas is providing binaries in a tar.gz, unpacking the rootfs, overwriting and repacking07:40
raymanfxI'm building chromium inside a yocto build env, that needs Google's depot_tools obviously07:40
Kakounetboucman_work: It's really my situation, I have no support from them and I try as much as I can alone but it's a really big subject. You made a huge and super powerfull thing, but it's hard for a begginner :D07:41
raymanfxNow I would like to install the depot_tools (mostly pyhon scripts) to the populated SDK07:41
*** Kakounet <Kakounet!58a35735@gateway/web/freenode/ip.> has quit IRC07:42
boucman_workKakounet: yeah, I know how you feel, but once you get it, yocto is awesome07:42
*** Kakounet <Kakounet!58a35735@gateway/web/freenode/ip.> has joined #yocto07:43
*** sno <sno!~sno@> has joined #yocto07:46
*** blueness <blueness!~blueness@gentoo/developer/blueness> has quit IRC07:46
*** Kakounet <Kakounet!58a35735@gateway/web/freenode/ip.> has quit IRC07:46
*** blueness <blueness!~blueness@gentoo/developer/blueness> has joined #yocto07:48
*** aragua <aragua!> has joined #yocto07:49
*** T_UNIX <T_UNIX!d4d3bd3c@gateway/web/freenode/ip.> has joined #yocto07:50
*** boucman_work <boucman_work!> has quit IRC07:51
*** Kakounet <Kakounet!> has joined #yocto07:51
*** pficheux <pficheux!> has joined #yocto07:56
pficheuxhi all07:56
*** boucman_work <boucman_work!> has joined #yocto07:56
*** gtristan <gtristan!~tristanva@> has quit IRC08:00
*** obsrwr_ <obsrwr_!~otp-amois@> has joined #yocto08:04
*** btooth <btooth!6cab81a3@gateway/web/freenode/ip.> has quit IRC08:04
LetoThe2ndboucman_work: s/yocto/openembedded/ :)08:08
boucman_workLetoThe2nd: yocto just overheated my laptop, I probably have missed your last sentence :P08:09
*** Crofton <Crofton!~Crofton@> has quit IRC08:09
*** kimo <kimo!c1f09a78@gateway/web/freenode/ip.> has joined #yocto08:09
LetoThe2ndboucman_work: i just meant that once you get the hang of it, openembedded is awesome. not yocto, as yocto is just a fancy name in the end.08:09
boucman_workagreed, though yocto is more and more the "commercial name" for the whole OE galaxy08:10
LetoThe2ndboucman_work: like in so many places, something just doesn't magically become more true if repeated often enough.08:12
LetoThe2nd(please don't take it personal :-) )08:12
boucman_workagreed again, but you need to adapt to your audience, most people with beginner questions don't have the OE-background to really understand the difference between yocto and OE, and they don't really care since they are working on yocto anyway :P08:13
*** Ulfalizer <Ulfalizer!~ulf@> has quit IRC08:14
LetoThe2ndboucman_work: the whole naming construct is unfortunate, that is oh so true.08:15
LetoThe2ndboucman_work: yet i still think that ironing out a couple of things here and there does good in the long run. i mean, there is no way to properly respond to somebody who want to know where to download rpms to install on his machine that is running the "yocto distribution"08:16
LetoThe2ndboucman_work: either that person gets the terminology, and the meaning behind it right - or there is no help.08:17
LetoThe2nd(can be no help)08:17
jubr"yocto distribution" <- more shadyness, don't you mean "poky" ? :)08:18
boucman_workLetoThe2nd: yeah, pedagogy is a subtle balance08:18
LetoThe2ndjubr: see context :)08:18
jubrLetoThe2nd: ok, ok, in context: true. Didn't read too far back08:18
boucman_worksometime you have to lie to your students so that they understand... being pedantic is usefull when your students understand the underlying concepts, but in that case most beginners don't. I save that for later08:19
boucman_workbut overall, I think we agree anyway08:19
*** kimo <kimo!c1f09a78@gateway/web/freenode/ip.> has quit IRC08:19
LetoThe2ndand even if not, there's nothing bad about civilized disagreement.08:19
*** arkver <arkver!> has joined #yocto08:23
LetoThe2ndthats what oh so many people mix up. just because i disagree with you on a professional topic (happens often enough with my customers), theres no personal problem. i still think you are a nice guy.08:23
LetoThe2ndboucman_work: (again, not you specifically. speaking to a 'virtual customer')08:24
*** Flow86 <Flow86!> has quit IRC08:24
*** yann <yann!> has joined #yocto08:24
*** Girafferson <Girafferson!~Giraffers@2601:281:8500:95b0:5249:f3c:d4e2:30a9> has left #yocto08:28
*** Flow86 <Flow86!> has joined #yocto08:31
*** kimo <kimo!500ddc5b@gateway/web/freenode/ip.> has joined #yocto08:35
*** agust <agust!> has quit IRC08:37
kimohello guys, I managed to get a core-image-minimal NAND boot on my imx28evk but I encountered a kernel panic
kimoany idea what it is about ?08:38
*** rajm <rajm!> has quit IRC08:41
*** rajm <rajm!> has joined #yocto08:41
*** Girafferson <Girafferson!~Giraffers@2601:281:8500:95b0:5249:f3c:d4e2:30a9> has joined #yocto08:42
LetoThe2ndkimo: its unable to mount your rootfs08:45
LetoThe2ndkimo: line 175ff sugest that your filesystem is not what you think it is.08:46
*** nighty <nighty!> has quit IRC08:47
*** CTtpollard <CTtpollard!> has quit IRC08:48
kimoLetoThe2nd: Yes but I just flashed the ubifs image using update_nant_filesystem cmd08:48
LetoThe2ndkimo: "i did something" does not necessarily mean "i did something correctly" or "i did something successfully"08:49
LetoThe2ndkimo: my personal advice would be to set up nfs root, make that boot, and from there inspect the ubi/ubifs08:49
kimoLetoThe2nd: right, I was expecting someone would have this issue, which is maybe related to imx28evk.conf08:51
LetoThe2ndkimo: or, as a slightly simpler stage maybe - stay in uboot and inspect from there, it might have some means of doing that.08:51
*** agust <agust!> has joined #yocto08:53
LetoThe2ndkimo: my gut feeling says that you just did something slightly wrong, and hence the nand content is not exactly what it should be. but thats just guessing08:53
boucman_workLetoThe2nd: do you have any knowledge of how the yocto autotest/builder infrastructure works, by any chance ?08:54
LetoThe2ndboucman_work: only very superficial. AFAIK its a buildbot that has been beaten into shape08:54
LetoThe2ndboucman_work: pidge is the one to poke about.08:54
LetoThe2nd(or at least she was the last time i touched that topic)08:55
boucman_workok, thx08:55
pidgeboucman_work: which parts of it? autobuilder, yes. the automated testing? it's been a while, but yeah.08:55
LetoThe2ndpidge: ah you wake? cheers!08:55
pidgeLetoThe2nd: Yup, ireland time now.08:56
boucman_workpidge: I am trying to build yocto with no gcc in PATH (i.e using BUILD_CC variable and checking that no software hardcodes the name gcc)08:56
LetoThe2ndpidge: holiday or relocated? ;-()08:56
boucman_workand i've found quite a few problems just by building core-image-minimal.08:56
pidgeLetoThe2nd: relocated um... almost 2 years now.08:56
boucman_workI'll submit a patch serie for that at some point, but I don't have the manpower nor time to check with a bitbake world08:57
boucman_workso the only way to guarentee that such bugs don't reapear would be to have some project-level testing. I don't know how to do that, but the autobuilders seemed like a reasonable place to start08:57
LetoThe2ndpidge: ah ok... last time we met there was too much talk on D&D and gaelic, little of RL value ;-)08:58
pidgeboucman_work: ok, yeah, that would be good to get that into the oe testing framework.08:58
kimoLetoThe2nd: I will give a try changing the min-io-size to 2048 as it says line17508:58
pidgeLetoThe2nd: Ha, I don't remember this.08:58
boucman_workpidge ok, nice to see i'm not too much off the line, can I come back to you when my main patch is more mature on the subject ?08:59
LetoThe2ndpidge: OEDEM dublin, lunch.08:59
pidgeboucman_work: sure. pidge@toganlabs.com08:59
boucman_workpidge: thx, or IRC09:00
pidgeLetoThe2nd: ahh, yes!09:00
LetoThe2ndpidge: probably you just don't link my face and nick.09:00
*** CTtpollard <CTtpollard!> has joined #yocto09:01
pidgeLetoThe2nd: Yeah, I know another Leto I got you confused with.09:02
LetoThe2ndpidge: np :-D i often get confused with some other Leto. Jared, methinks.09:03
*** gtristan <gtristan!~tristanva@> has joined #yocto09:03
*** kimo <kimo!500ddc5b@gateway/web/freenode/ip.> has quit IRC09:05
*** agust <agust!> has quit IRC09:15
*** joshuagl <joshuagl!joshuagl@nat/intel/x-kuriquijjocgfglg> has quit IRC09:17
*** slidercrank <slidercrank!~slidercra@unaffiliated/slidercrank> has quit IRC09:21
boucman_workI'm trying to do a versionned packagegroup, i.e a packagegroup that depends on specific version of recipes.... I can add version information in RDEPENDS, but that only works at rootfs time, it doesn't make bitbake compile the right version of the software09:25
boucman_workis there an easy way to do that ? (I tried to add a version to DEPENDS, bitbake seems to accept the syntax but does not compile the proper version anyway)09:25
*** MWelchUK <MWelchUK!> has quit IRC09:28
jubrboucman_work: that's PREFERRED_VERSION I think09:29
jubrbut it lives at the .conf level, not at .bb level09:29
*** joshuagl <joshuagl!~joshuagl@> has joined #yocto09:29
boucman_workyeah, that's my problem...09:30
jubrDon't think bb can do that...09:31
boucman_workI need to set PREFFERED_VERSION for each program in the packagegroup, I'd like to just set it for the packagegroup...09:31
jubrmultiple versions can't co-exist in the same sysroot|deploy/ipk anyways09:31
boucman_worktrue, but bb can have multiple versionned recipe, so versionned depends could be theoretically possible (with the correct error messages in cas of contradictory dependencies)09:32
boucman_workbut thx, if it's not possible, I won't look further on how to do it :P09:32
boucman_workRDEPENDS still guarentees version consistence, which is good09:33
-YoctoAutoBuilder- build #888 of nightly-qa-skeleton is complete: Failure [failed BuildImages Running Sanity Tests] Build details are at
-YoctoAutoBuilder- build #879 of build-appliance is complete: Failure [failed BuildImages BuildImages_1] Build details are at
-YoctoAutoBuilder- build #884 of nightly-qa-extras is complete: Failure [failed BuildImages Running Sanity Tests BuildImages_1 Running Sanity Tests_1] Build details are at
-YoctoAutoBuilder- build #889 of nightly-qa-pam is complete: Failure [failed BuildImages Running Sanity Tests] Build details are at
-YoctoAutoBuilder- build #288 of nightly-checkuri is complete: Failure [failed BuildImages] Build details are at
-YoctoAutoBuilder- build #894 of nightly-non-gpl3 is complete: Failure [failed BuildImages] Build details are at
-YoctoAutoBuilder- build #879 of nightly-intel-gpl is complete: Failure [failed BuildImages BuildImages_1] Build details are at
-YoctoAutoBuilder- build #884 of nightly-qa-logrotate is complete: Failure [failed BuildImages Running Sanity Tests] Build details are at
-YoctoAutoBuilder- build #914 of poky-tiny is complete: Failure [failed BuildImages] Build details are at
-YoctoAutoBuilder- build #886 of nightly-x32 is complete: Failure [failed BuildImages Running Sanity Tests Running Sanity Tests_1] Build details are at
-YoctoAutoBuilder- build #888 of buildtools is complete: Failure [failed BuildImages BuildImages_1 BuildImages_2] Build details are at
-YoctoAutoBuilder- build #888 of nightly-qa-systemd is complete: Failure [failed BuildImages Running Sanity Tests BuildImages_1 Running Sanity Tests_1 BuildImages_2 Running Sanity Tests_2] Build details are at
-YoctoAutoBuilder- build #540 of nightly-rpm-non-rpm is complete: Failure [failed BuildImages Running Sanity Tests] Build details are at
-YoctoAutoBuilder- build #542 of nightly-deb-non-deb is complete: Failure [failed BuildImages Running Sanity Tests] Build details are at
-YoctoAutoBuilder- build #861 of nightly-rpm is complete: Failure [failed BuildImages Running Sanity Tests] Build details are at
-YoctoAutoBuilder- build #867 of nightly-ipk is complete: Failure [failed BuildImages Running Sanity Tests] Build details are at
-YoctoAutoBuilder- build #847 of nightly-deb is complete: Failure [failed BuildImages Running Sanity Tests] Build details are at
-YoctoAutoBuilder- build #444 of nightly-wic is complete: Failure [failed BuildImages BuildImages_1 CreateWicImages CreateWicImages_1 BuildImages_2 BuildImages_3 CreateWicImages_2 CreateWicImages_3 CreateWicImages_4 Publishing Artifacts] Build details are at
*** t0mmy <t0mmy!> has joined #yocto09:37
-YoctoAutoBuilder- build #911 of nightly-multilib is complete: Failure [failed BuildImages Running Sanity Tests BuildImages_1 Running Sanity Tests_1 BuildImages_2 Running Sanity Tests_2 BuildImages_3 Running Sanity Tests_3 BuildImages_4] Build details are at
*** MWelchUK <MWelchUK!> has joined #yocto09:41
-YoctoAutoBuilder- build #872 of nightly-mips-lsb is complete: Failure [failed BuildImages Running Sanity Tests BuildImages_1] Build details are at
-YoctoAutoBuilder- build #878 of nightly-ppc-lsb is complete: Failure [failed BuildImages Running Sanity Tests BuildImages_1] Build details are at
-YoctoAutoBuilder- build #926 of nightly-x86-64 is complete: Failure [failed BuildImages Running Sanity Tests BuildImages_1 Building Toolchain Images Running SDK Sanity Tests Building Toolchain Images_1 Running SDK Sanity Tests_1 BuildImages_2 Running ESDK Sanity Tests] Build details are at
-YoctoAutoBuilder- build #892 of nightly-mips is complete: Failure [failed BuildImages Running Sanity Tests BuildImages_1 Building Toolchain Images Running SDK Sanity Tests Building Toolchain Images_1 BuildImages_2 Running ESDK Sanity Tests] Build details are at
-YoctoAutoBuilder- build #905 of nightly-ppc is complete: Failure [failed BuildImages Running Sanity Tests BuildImages_1 Building Toolchain Images Running SDK Sanity Tests Building Toolchain Images_1 BuildImages_2 Running ESDK Sanity Tests] Build details are at
-YoctoAutoBuilder- build #905 of nightly-x86 is complete: Failure [failed BuildImages Running Sanity Tests BuildImages_1 Building Toolchain Images Running SDK Sanity Tests Building Toolchain Images_1 Running SDK Sanity Tests_1 BuildImages_2 Running ESDK Sanity Tests] Build details are at
-YoctoAutoBuilder- build #862 of nightly-arm-lsb is complete: Failure [failed BuildImages Running Sanity Tests BuildImages_1] Build details are at
-YoctoAutoBuilder- build #523 of nightly-arm64 is complete: Failure [failed BuildImages Running Sanity Tests Building Toolchain Images Running SDK Sanity Tests Building Toolchain Images_1 BuildImages_1 Running SDK Sanity Tests_1] Build details are at
pidgehrm. is there a way in combo-layer to specify a revision to peg an entry to. so when you combo-layer update, it won't update just that repo?09:45
*** Biliogadafr <Biliogadafr!> has joined #yocto09:51
pidgeRP, I guess you'd know the answer to this maybe? ^^^09:53
*** Crofton <Crofton!~Crofton@> has joined #yocto09:54
*** belen <belen!~Adium@> has joined #yocto09:56
RPpidge: offhand I don't remember09:56
*** belen <belen!~Adium@> has quit IRC09:57
pidgeif there is it's not documented. I'll poke through it I guess.09:57
*** nrossi <nrossi!> has joined #yocto09:59
*** JaMa <JaMa!> has joined #yocto10:02
RPpidge: the script itself is pretty simple10:14
HyP3rBy default the apache2 recpie out of yocto poky meta-www seems not to enable its systemd server10:18
HyP3rHow can I enable this service?10:18
HyP3rYeah I know with systemctl enable apache2. But I talk about the package generation runtime10:18
*** khem <khem!~khem@unaffiliated/khem> has quit IRC10:24
*** nighty-- <nighty--!> has joined #yocto10:26
-YoctoAutoBuilder- build #916 of poky-tiny is complete: Success [build successful] Build details are at
*** khem <khem!~khem@unaffiliated/khem> has joined #yocto10:28
*** Crofton <Crofton!~Crofton@> has quit IRC10:29
joshuagl"Services are set up to start on boot automatically unless you have set SYSTEMD_AUTO_ENABLE to "disable". "10:29
joshuaglpresumably the apache2 recipe sets that variable?10:30
-YoctoAutoBuilder- build #890 of buildtools is complete: Success [build successful] Build details are at
*** Biliogadafr <Biliogadafr!> has quit IRC10:30
-YoctoAutoBuilder- build #896 of nightly-non-gpl3 is complete: Success [build successful] Build details are at
-YoctoAutoBuilder- build #886 of nightly-qa-extras is complete: Success [build successful] Build details are at
-YoctoAutoBuilder- build #243 of nightly-no-x11 is complete: Success [build successful] Build details are at
-YoctoAutoBuilder- build #881 of nightly-intel-gpl is complete: Success [build successful] Build details are at
*** florian <florian!~fuchs@Maemo/community/contributor/florian> has quit IRC10:47
-YoctoAutoBuilder- build #447 of nightly-wic is complete: Success [build successful] Build details are at
-YoctoAutoBuilder- build #891 of nightly-qa-skeleton is complete: Success [build successful] Build details are at
*** gtristan_ <gtristan_!~tristanva@> has joined #yocto10:53
*** florian <florian!~fuchs@Maemo/community/contributor/florian> has joined #yocto10:58
-YoctoAutoBuilder- build #291 of nightly-checkuri is complete: Success [build successful] Build details are at
-YoctoAutoBuilder- build #881 of build-appliance is complete: Success [build successful] Build details are at
-YoctoAutoBuilder- build #886 of nightly-qa-logrotate is complete: Success [build successful] Build details are at
-YoctoAutoBuilder- build #624 of nightly-world-lsb is complete: Success [build successful] Build details are at
*** florian <florian!~fuchs@Maemo/community/contributor/florian> has quit IRC11:07
-YoctoAutoBuilder- build #889 of nightly-x32 is complete: Success [build successful] Build details are at
*** florian <florian!~fuchs@Maemo/community/contributor/florian> has joined #yocto11:09
-YoctoAutoBuilder- build #545 of nightly-deb-non-deb is complete: Success [build successful] Build details are at
*** Ulfalizer <Ulfalizer!~ulf@> has joined #yocto11:15
-YoctoAutoBuilder- build #891 of nightly-qa-pam is complete: Success [build successful] Build details are at
*** grma <grma!~gruberm@> has joined #yocto11:17
*** rburton <rburton!> has joined #yocto11:21
-YoctoAutoBuilder- build #870 of nightly-ipk is complete: Success [build successful] Build details are at
*** joseppc <joseppc!~josep@linaro/joseppc> has joined #yocto11:24
rburtonalexlarsson: hey alex11:25
rburtonalexlarsson: the tune etc i wasn't aware was in CC but the sysroot certainly always is.  this has bitten me before though and i have wondered if we should change CC to be literally the gcc name even if its entirely useless without CFLAGS (to get the sysrot)11:26
boucman_workrburton: hey11:28
boucman_workdo you know where I should put a patch that affects ALL version of linux ?11:28
boucman_work(it is not possible to overload the hardcoded name "gcc" used to compile the kconfig stuff, thus breaking BUILD_*)11:29
-YoctoAutoBuilder- build #850 of nightly-deb is complete: Success [build successful] Build details are at
rburtonboucman_work: you can patch everything using linux-yocto by simply adding to SRC_URI right?11:38
boucman_workyes, I guess that will be good enough for my goal. other meta will hav to fix their stuff themselves...11:40
*** psadro <psadro!~Thunderbi@2620:0:ed0:800a:72f3:95ff:fe1d:9866> has quit IRC11:43
-YoctoAutoBuilder- build #914 of nightly-multilib is complete: Success [build successful] Build details are at
*** psadro <psadro!~Thunderbi@2620:0:ed0:800a:72f3:95ff:fe1d:9866> has joined #yocto11:54
*** berton <berton!~fabio@> has joined #yocto11:54
-YoctoAutoBuilder- build #864 of nightly-rpm is complete: Success [build successful] Build details are at
*** Girafferson <Girafferson!~Giraffers@2601:281:8500:95b0:5249:f3c:d4e2:30a9> has quit IRC12:04
HyP3rjoshuagl: you were right inside this apache2 script stands: SYSTEMD_AUTO_ENABLE_${PN} = "disable"12:18
HyP3rHow can I enable this service?12:19
HyP3rwith a bbapend file?12:19
*** dvhart <dvhart!~dvhart@> has joined #yocto12:20
-YoctoAutoBuilder- build #540 of nightly-mips64 is complete: Success [build successful] Build details are at
joshuaglHyP3r: or setting SYSTEMD_AUTO_ENABLE_pn-apache2 = "enable" somewhere in your distro's conf should work12:23
joshuagl(I think)12:23
HyP3rWell I have anyway allready a meta layer for my project and also a apache2.bbappend which should fix this12:24
HyP3rBut I'm still wondering why its by default disabled12:24
-YoctoAutoBuilder- build #543 of nightly-rpm-non-rpm is complete: Success [build successful] Build details are at
alexlarssonrburton: I don't really know unfortunately, it was always various points of jethro12:28
HyP3rAnd I'm wondering why yocto is not using any chroot enviroment each complex package has its patches to fix path problems \o/12:28
alexlarssonrburton: but, it used to work, and at some time broke12:28
alexlarssonrburton: not sure exactly what caused the change12:28
*** arkver <arkver!> has quit IRC12:28
rburtonalexlarsson: hmm12:29
*** paulg <paulg!> has joined #yocto12:29
alexlarssonrburton: the host didn't change (centos7)12:29
alexlarssonso, shouldn't be the host compiler12:29
alexlarssonbut we did bump the jethro rev a few times12:30
alexlarssonunfortunately i was on vacation so i don't really know when it appeared, etc.12:30
rburtondidn't spot anything in jethro which would cause this, i'll look again12:31
*** istarilucky <istarilucky!~rlucca@> has joined #yocto12:31
alexlarssonIts kinda weird though12:32
alexlarssonIt happens in g-ir-scanner, but only when called from webkit12:32
rburtonalexlarsson: i though CC had the sysroot in for a long time, so maybe distutils changed?12:32
Ulfalizeralexlarsson: maybe you could do some debugging with 'bitbake -e' if you search for "^export CC"12:32
rburtoni'd suggest patching distutils to split on whitespace before doing basename12:33
rburtonthough as i said, i've seen a few other pieces moan if CC isn't just a binary name, so i do wonder how much breaks if we move the sysroot from CC to CFLAGS12:33
rburton(my guess: lots)12:33
rburtonseveral packages failed to build when we made not listening to LDFLAGS throw a warning12:34
*** ntl <ntl!> has joined #yocto12:35
*** m70b54 <m70b54!c32a382c@gateway/web/freenode/ip.> has joined #yocto12:36
*** t0mmy <t0mmy!> has quit IRC12:37
alexlarssonrburton: distutils is part of python, right?12:37
*** dv <dv!~quassel@> has quit IRC12:37
alexlarssonrburton: the weird thing is that all my other packages build fine, and i'd be surprised if webkit is the first that uses g-ir-scanner12:38
*** dv <dv!> has joined #yocto12:38
alexlarssonrburton: which is very confusing, because the distutils issue is very clear, looking at the distutils code12:39
m70b54hi guys12:39
*** dvhart <dvhart!~dvhart@> has quit IRC12:40
*** dv is now known as dv_12:41
boucman_workaaand glibc git refuses to compile :(12:42
rburtonalexlarsson: oh webkit build from oe-core?12:42
alexlarssonrburton: no, in flatpak12:42
rburtonah right12:42
-YoctoAutoBuilder- build #890 of nightly-qa-systemd is complete: Success [build successful] Build details are at
rburtoni was going to say, g-i should be disabled everywhere in jethro12:42
alexlarssonpython -c "import sysconfig; print sysconfig.get_config_var('CC')"12:42
alexlarssonx86_64-unknown-linux-gcc  -m64 -march=core2 -mtune=core2 -msse3 -mfpmath=sse12:42
alexlarssonthat is on my build12:42
*** Crofton <Crofton!~Crofton@> has joined #yocto12:43
m70b54can anyone tell me where the syslog file should be? i'm trying to output all systemd logs to syslog but it's not working12:44
m70b54ForwardToSyslog=yes is defined in my journald.conf12:45
*** nighty-- <nighty--!> has quit IRC12:45
*** nighty-- <nighty--!> has joined #yocto12:46
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC12:46
*** Crofton <Crofton!~Crofton@> has quit IRC12:48
alexlarssonrburton: do you know where the sysconfig is stored?12:49
rburtonno, sorry12:49
rburtonknowing python, blasted into the module directly12:49
-YoctoAutoBuilder- build #526 of nightly-arm64 is complete: Success [build successful] Build details are at
*** junland <junland!~junland@> has joined #yocto12:52
alexlarssonrburton: /usr/lib/python2.7/ it seems12:53
*** igor2 <igor2!~igor@> has joined #yocto12:53
m70b54when attaching to syslog process with strace, i can see all the logs coming from journald, but there is no output12:54
*** nighty-- <nighty--!> has quit IRC12:55
HyP3rHm another strange thing: I have added openvpn to my core image. And openvpn has this line: "RRECOMMENDS_${PN} = "kernel-module-tun"". But I don't have a kernel module 'tun'12:55
*** nighty-- <nighty--!> has joined #yocto12:55
HyP3rHere the modinfo: "modinfo: ERROR: Module tun not found."12:56
-YoctoAutoBuilder- build #929 of nightly-x86-64 is complete: Success [build successful] Build details are at
boucman_workHyP3r: my understanding : RRECOMMENDS is not mandatory, so if it's not found, it won't be an error at build time12:58
boucman_workso if noone builds kernel-module-tun, it won't be build12:59
boucman_workyou need to add kernel-module-tun to IMAGE_INSTALL yourself, I guess12:59
alexlarssonrburton: hmm, i think i may have an idea12:59
HyP3rboucman_work: ok I'll try13:00
alexlarssonrburton: looking at my build, it seems like the is "right" (has no --sysroot)13:01
alexlarssonrburton: but the _sysconfigdata.pyc *does* have it13:01
*** m70b54 <m70b54!c32a382c@gateway/web/freenode/ip.> has quit IRC13:01
alexlarssonrburton: and then we run the entire thing through ostree, reseting the mtimes, and we have some python mtime fixup thing for this in flatpak13:01
alexlarssonrburton: so, i wonder if yocto rewrites this file after the .pyc is written13:02
rburtonpy_package_preprocess in python.bb13:03
rburtonthough that is meant to be removing the sysroot...13:04        sed -i -e 's:--sysroot=${STAGING_DIR_TARGET}::g' -e s:'--with-libtool-sysroot=${STAGING_DIR_TARGET}'::g \13:04
alexlarssonyes, and it does13:04
alexlarssonin the .py file13:04
alexlarssonbut its left in the .pyc file13:04
alexlarssonwhich admittedly should be invalid due to the timestamp13:04
alexlarssonso, the fault is mine13:05
rburtonso its a comedy interaction between our recipe expecting the pyc to be regenerated/ignored, and you adjusting timestamps?13:05
HyP3rboucman_work: I added this to my IMAGE_INSTALL but there is no such package :(13:05
rburtonsurely we can remove those bits earlier than that preprocess hook13:06
alexlarssonwell, its a general problem for me though13:06
alexlarssoni should handle it as such13:06
alexlarssonor i will run into similar issues later.13:06
rburtonrecompile all py before trashing timestamps?13:07
alexlarssonOr just drop all .pyc files that have an invalid timestamp13:07
rburtonpresumably there's a good improvement in loading .pyc over .py so especially for the core library a forced compile might be sensible13:08
LetoThe2ndboucman_work: then you have to make sure your kernel config even builds that module13:10
boucman_workLetoThe2nd: yeah, true13:11
LetoThe2ndboucman_work: ah sry13:11
LetoThe2ndHyP3r: that was for you ^^^^^^^13:11
boucman_workHyP3r: what LetoThe2nd said... I'm not sure the proper, yocto, way to enable a module, but that's what you need to do13:11
LetoThe2ndboucman_work: as usual, it depends.13:12
rburtonalexlarsson: <squits> find all .pyc which are older than .py?13:12
rburtonwould be a sensible sanity check13:12
* rburton adds to insanitier13:12
HyP3rboucman_work: yeah I guess I have to add this kernel module13:16
LetoThe2ndHyP3r: boucman_work: there are the various fragments that can also be depended on IIRC or be set up through DISTRO, or if its a simpler setup, just modify the kernels .config13:16
-YoctoAutoBuilder- build #865 of nightly-arm-lsb is complete: Success [build successful] Build details are at
HyP3rTo the apache thing back, while compiling the kernel module tun: I have created a apache2.bbapped (which im already using to patch some configurations) and wrote the line: SYSTEMD_AUTO_ENABLE_${PN} = "enable"13:18
*** anselmolsm <anselmolsm!~anselmols@> has joined #yocto13:18
HyP3rBut this service is still not eanabled :(13:18
*** bluelightning <bluelightning!~paul@> has joined #yocto13:20
*** bluelightning <bluelightning!~paul@> has quit IRC13:20
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto13:20
joshuagldid you misspell bbappend as you did above? :-)13:20
LetoThe2ndHyP3r: the name of the bbappends has to completely match the name except for the extension13:20
LetoThe2ndHyP3r: there are a couple of wildcards, but is certainly not correct13:21
HyP3rThe exact name of my bbappend: "apache2_2.4.10.bbappend"13:21
HyP3rThe original file: apache2_2.4.10.bb13:21
-YoctoAutoBuilder- build #921 of nightly-arm is complete: Success [build successful] Build details are at
joshuaglbitbake apache2 -e | grep ^SYSTEMD_AUTO_ENABLE ?13:22
LetoThe2ndHyP3r: then first check if the systemd unit is not packed into a seperate package. second, evaluate the recipe as joshuagl just said, he was faster on typing :)13:23
bluelightningnot sure since I only saw some of this discussion, but maybe this will be helpful:
LetoThe2ndbluelightning: any documentation is useful if correct, be it only for later reference :)13:23
bluelightningLetoThe2nd: good point :)13:24
*** marka_home <marka_home!> has joined #yocto13:26
*** marka_home is now known as marka13:26
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC13:28
*** boucman_work <boucman_work!> has quit IRC13:30
*** challinan <challinan!> has quit IRC13:30
*** challinan <challinan!> has joined #yocto13:31
HyP3rjoshuagl: LetoThe2nd looks good right?13:33
-YoctoAutoBuilder- build #895 of nightly-mips is complete: Success [build successful] Build details are at
HyP3rI have now enabled TUN/TAP inside the kernel configuration. How can I check if its enabled13:33
LetoThe2ndHyP3r: build the kernel and then see if the package is generated13:34
HyP3rok, its enough to save the config as '.config' right?13:34
joshuaglHyP3r: yeah, that looks OK. Did `bitbake apache2` result in a new package being generated? (That variable is used in a postinst that runs at first boot)13:36
*** rcw <rcw!~rwoolley@> has joined #yocto13:36
LetoThe2ndHyP3r: erm.... no, not really. especially not if you want things to be reproductible and you are using OE to build the kernel13:37
LetoThe2ndHyP3r: you have to make sure that the new config file ends up at the place where your former one was fetched from13:38
-YoctoAutoBuilder- build #908 of nightly-ppc is complete: Success [build successful] Build details are at
*** boucman_work <boucman_work!> has joined #yocto13:43
HyP3rjoshuagl: well I gues I have to to a clean for that13:43
-YoctoAutoBuilder- build #908 of nightly-x86 is complete: Success [build successful] Build details are at
eduardas_mhello. How can I find out which u-boot defconfig is used to build my u-boot.img?13:49
eduardas_mthe recipe file that is apparently being used does not directly provide such info13:50
LetoThe2ndeduardas_m: IIRC uboot does not rely on defconfigs, but its own machines. thats what the uboot machine name in the recipe selects. with that information, look at the uboot sources.13:56
*** dholland <dholland!> has joined #yocto13:59
eduardas_m LetoThe2nd: this is not to be confused with linux kernel defconfig which is a separate matter entirely14:01
eduardas_mwhen building u-boot one can do something like the following:14:02
eduardas_mmake ARCH=arm CROSS_COMPILE=${CC} wandboard_defconfig14:02
eduardas_mins the u-boot sources there is a "configs" folder14:02
LetoThe2ndeduardas_m: i know.14:02
eduardas_mand the file names there end with "defconfig"14:02
HyP3rLetoThe2nd: the config in kernel-build-artifacts seems ok14:04
eduardas_mso I have to use this file when I compile from u-boot sources separately, but Yocto does not utilise them?14:04
HyP3rand yes... the apache2 has just to be recompiled :S14:04
HyP3ror just repacked14:04
LetoThe2ndeduardas_m: yocto does not utilize anything, as it is no software :-P14:04
LetoThe2ndeduardas_m: but the usual bitbake recipes for u-boot just trigger the very same config step as a manual build does.14:05
eduardas_mbut how do I trace that from the .bb file?14:06
eduardas_mLetoThe2nd: I want to do manually what Yocto does for me automatically14:07
LetoThe2ndeduardas_m: doesn't your recipe say something like U_BOOT_MACHINE = "something"? or one of the includes it pulls in?14:07
Ulfalizereduardas_m: might be helpful14:09
Ulfalizereduardas_m: and will also show you how to see exactly what commands bitbake runs14:10
eduardas_mthis is the .bb file14:10
eduardas_mthere is no U_BOOt_MACHINE14:10
*** sveinse <sveinse!~chatzilla@> has joined #yocto14:11
sveinseThe docs suggests SSTATE_MIRRORS ?= "file://.* ...". What is the significance of this file URL?14:11
-YoctoAutoBuilder- build #875 of nightly-mips-lsb is complete: Success [build successful] Build details are at
Ulfalizereduardas_m: you could run 'bitbake -e u-boot-var-6ul' and search for U_BOOT_MACHINE. might be from or fsl-u-boot-localversion.bbclass if it exists.14:12
LetoThe2ndUlfalizer: ++14:12
Ulfalizer'bitbake -e' also shows you where variables are set14:12
* Ulfalizer tries giving general advice with zero context :P14:12
*** madisox <madisox!~madison@> has joined #yocto14:13
sveinseThat's 42 isn't it?14:13
*** madisox <madisox!~madison@> has quit IRC14:13
Ulfalizer42 is the answer14:13
*** benjamirc <benjamirc!~besquive@> has joined #yocto14:17
HyP3rOk great apache2 starts now automatic but the kernel module 'tun' is not aviable :/14:17
HyP3runder kernel-build-artifacts I have the .config file for my kernel (I gues this is the correct directory). And inside this file I have the line "CONFIG_TUN=m"14:18
HyP3r(I created it as kernel module, maybe not so good idea) but 'modprobe tun' does not work14:18
Ulfalizersveinse: guessing it's consistent with e.g. PREMIRRORS where you can have things like "git://./.*" to map the former to the later, only file:// is the only thing that makes sense for the sstate cache14:19
Ulfalizerand yeah, that should be explained in the documentation, imo14:19
LetoThe2ndHyP3r: you have to check for:
*** blueness <blueness!~blueness@gentoo/developer/blueness> has quit IRC14:23
eduardas_mUlfalizer, LetoThe2nd : it is now apparent that in poky sources actually uses UBOOT_MACHINE for I only need to know where UBOOT_MACHINE is set14:23
HyP3rLetoThe2nd: UBTOO?14:24
*** blueness <blueness!~blueness@gentoo/developer/blueness> has joined #yocto14:25
*** jku <jku!jku@nat/intel/x-gxiicgvkpsrbdvxo> has quit IRC14:26
LetoThe2ndHyP3r: sorry, wrong nick14:26
LetoThe2ndeduardas_m: ^^14:26
HyP3rLetoThe2nd: no problem ^^14:26
*** RagBal <RagBal!> has quit IRC14:26
HyP3rLetoThe2nd: I guess I missed after menuconfig the savedefconfig \o/14:26
*** Rootert <Rootert!> has quit IRC14:27
*** jku <jku!> has joined #yocto14:27
*** RagBal <RagBal!> has joined #yocto14:28
*** Rootert <Rootert!> has joined #yocto14:28
*** Crofton <Crofton!~Crofton@> has joined #yocto14:29
LetoThe2ndHyP3r: that might work as a single shot, but its really important that the config finds its way back to the place where the original one came from. otherwise you will be stuck instantly again the next time you want to modify anything14:29
*** billr <billr!~wcrandle@> has joined #yocto14:31
HyP3rok? But whats the better way?14:31
*** Anticom <Anticom!~timo.m@> has quit IRC14:32
Ulfalizereduardas_m: 'bitbake -e' tells you where variables are set too, not just their value14:34
LetoThe2ndHyP3r: *sigh* like i said: make sure the config file you created ends up exactly where the original file was before. e.g. in the layer, in the repo, whatever.14:34
HyP3rwell I gues the kernel.bbclass is more complex than simply coping my config file (which contains every configuration point of linux) to there, and your answer is really universal14:36
eduardas_mUlfalizer, LetoThe2nd: thank you for your help...was really informative...14:36
HyP3rI read now something about that I have to create a 'linux-toradex_4.1.bbappend' with a SRC_URI Reference to a config file which is only configuring those things which are nessercary (in my case: tun.cfg) then it should work14:37
Ulfalizereduardas_m: when going through the manuals, a tip is to always read the latest version btw14:37
LetoThe2ndHyP3r: not at all. it really, really depends on your specific kernel setup. it can be as simple as just replacing some defconfig file.14:37
LetoThe2ndHyP3r: or that, the cfg way is also possible.14:37
Ulfalizerguess you risk seeing something version-specific, but it's a small risk compared to updated descriptions14:37
HyP3rAnd inside the tun.cfg stands: "CONFIG_TUN=y"14:38
LetoThe2ndHyP3r: always keep in mind - what would a coworker need to find tomorrow if you get hit by a bus tonight.14:38
HyP3rthat way is really scalable14:38
HyP3rLetoThe2nd: a good documentation :). Each recpie of my meta layer has some lines documentation14:38
HyP3rhopefully enough :3#14:39
LetoThe2ndHyP3r: and if that defconfig ends up in your layer, then all is fine. thats wahat i want to say.14:39
HyP3rLetoThe2nd: yep this bbappend and tun.cfg is inside my layer ;)14:40
LetoThe2ndHyP3r: perfect!14:42
HyP3rLetoThe2nd: only by the way: my cowork which left the company and gave me this huge pile of missconfiguration. He simply compiled the kernel out of the whole yocto toolchain and copied the zImage into the rootfs before do_rootfs14:45
LetoThe2ndHyP3r: yeah - thats why i'm saying to get it done right from the beginning14:47
*** t0mmy <t0mmy!> has joined #yocto14:48
*** demonimin <demonimin!~demonimin@unaffiliated/demonimin> has quit IRC14:49
*** Rootert <Rootert!> has quit IRC14:49
*** RagBal <RagBal!> has quit IRC14:49
*** T_UNIX <T_UNIX!d4d3bd3c@gateway/web/freenode/ip.> has quit IRC14:50
*** billr <billr!~wcrandle@> has quit IRC14:50
*** billr <billr!wcrandle@nat/intel/x-eaelvacxfvfigxlg> has joined #yocto14:51
*** Crofton <Crofton!~Crofton@> has quit IRC14:51
*** ntl <ntl!> has quit IRC14:53
*** demonimin <demonimin!~demonimin@unaffiliated/demonimin> has joined #yocto14:54
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has joined #yocto14:55
*** rcw <rcw!~rwoolley@> has quit IRC14:56
*** rcwoolley_ <rcwoolley_!~rwoolley@> has joined #yocto14:56
HyP3rLetoThe2nd: it seems like its not working. I still have "ERROR: Cannot open TUN/TAP dev /dev/net/tun: No such device"14:59
-YoctoAutoBuilder- build #900 of nightly-world is complete: Success [build successful] Build details are at
HyP3rLetoThe2nd: can you help me?14:59
HyP3rLetoThe2nd: I don't know how to troubleshoot this problem15:00
*** psadro <psadro!~Thunderbi@2620:0:ed0:800a:72f3:95ff:fe1d:9866> has quit IRC15:02
nishaHyP3r, tunctl -b -u $USER15:06
nishathat'll make you a tap device15:07
HyP3rnisha: I don't have the depending kernel module integrated and also not this tunctl binary15:07
*** psadro <psadro!~Thunderbi@> has joined #yocto15:08
nishaHyP3r, heh, seems I might have a similar problem with a kernel config file15:11
*** sameo <sameo!samuel@nat/intel/x-jwytddvjjbgxjloj> has joined #yocto15:11
*** gtristan <gtristan!~tristanva@> has quit IRC15:12
*** vmeson <vmeson!> has joined #yocto15:12
*** gtristan_ <gtristan_!~tristanva@> has quit IRC15:12
HyP3rI have followed this tutorial:
HyP3rnisha: and I should add this tunctl which maybe useful troubleshoot this15:14
*** aehs29 <aehs29!~aehernan@> has joined #yocto15:15
nishaHyP3r, so you already have a .bbappends file in your recipe-kernel folder?15:17
HyP3rwell I have a meta layer 'meta-foo' with the directory 'recpie-bar' insside this folder I have the file 'linux-toradex_4.1.bbappend' with this as conent:
*** billr <billr!wcrandle@nat/intel/x-eaelvacxfvfigxlg> has quit IRC15:18
HyP3rthen I have inside this '15:18
HyP3rthen I have inside this 'recpie-bar' folder the folder 'linux-toradex' with those two files listes in SRC_URI15:19
HyP3rAnd tun.cfg contains 'CONFIG_TUN=y'15:19
*** sveinse <sveinse!~chatzilla@> has quit IRC15:21
*** AgentElrond <AgentElrond!> has joined #yocto15:21
nishathat looks right15:22
HyP3ryeah, but something is missing. I'm not sure if its allowed to use 'y' or should I use 'M'?15:22
*** billr <billr!~wcrandle@> has joined #yocto15:23
nishaif you use m it just means you will have to manually load it15:24
nishayou can try doing an insmod tun.ko after you boot15:24
*** yann <yann!> has quit IRC15:28
boucman_workcgroup are awesome... I finally found how to not have bitbake eat my cpu :)15:30
*** jku <jku!> has quit IRC15:31
*** Kakounet <Kakounet!> has quit IRC15:34
*** grma <grma!~gruberm@> has quit IRC15:34
HyP3rWow what a bunch of shit. I told you my configuration ~17:19 and now my system has again booted: '# CONFIG_TUN is not set'15:35
HyP3rYeah. And then people are wondering why there are so many mass shootings15:35
rburtonalexlarsson: WARNING: python-2.7.12-r1 do_package_qa: QA Issue: package python-core contains stale pyc work/corei7-64-poky-linux/python/2.7.12-r1/packages-split/python-core/usr/lib64/python2.7/_sysconfigdata.pyc [stale-pyc] <— i'll push this new test into oe-core to ensure we don't do it again15:39
markaHyP3r: what kernel are you building?15:43
*** rcwoolley_ <rcwoolley_!~rwoolley@> has quit IRC15:46
markaif you are building linux-yocto you can/should make use of kernel config frags as you seem to be attempting from what I see15:46
markabut if you are inserting a different kernel then config frags are not applied and the 'seeded' defconfig is all that is used15:47
davisomg, this thing might be working. rock and roll.15:47
*** gtristan <gtristan!~tristanva@> has joined #yocto15:49
*** gtristan_ <gtristan_!~tristanva@> has joined #yocto15:50
CTtpollardI think someone needs to by HyP3r a drink after this week15:51
*** rajm <rajm!> has quit IRC15:51
eduardas_mUlfalizer, LetoThe2nd: you were of great help today..finally was able to build modified u-boot for my board with the proper configuration15:51
nishaso, I tried to add a kernel config but I get this build error: Computing transaction...error: Can't install packagegroup-distro-base-1.0-r83@qemux86_64: no package provides kernel-module-virtio-gpu15:51
*** eduardas_m <eduardas_m!~eduardas_@> has quit IRC15:52
*** dv <dv!> has joined #yocto15:54
*** dv_ <dv_!> has quit IRC15:54
*** boucman_work <boucman_work!> has quit IRC15:56
*** lamego <lamego!~jose@> has joined #yocto15:57
*** paulg <paulg!> has quit IRC15:59
davisso, this multiple git repot with a cmake build in bitbake is oh so close to working16:03
*** dmoseley <dmoseley!> has joined #yocto16:03
davisit pulls the three repots, puts them in a single git subdir16:03
*** sno <sno!~sno@> has quit IRC16:04
davisand possibly attempts to build from the src dir in one of the repots16:04
davisbut it might actually be trying to build in git/ and not git/pcmx16:04
rburtonwell you put S=git/pcmx so it should be doing cmake in there16:04
davisyes, that was the goal16:05
rburtonlooking at cmake.bbclass shows you that it has a OECMAKE_SOURCEPATH to tell it where the cmakelists is16:05
rburtonwhich defaults to ${S}16:05
davisahh so that is an override?16:05
rburtonwell you shouldn't need it if you set S to the right place16:06
rburtonyou know actually saying what breaks really would be helpful16:06
davisim trying to specify just in case.16:06
daviswhen I did the simple cmake tutor build in bitbake, i used jsut workdir/git16:07
davisand that worked16:07
davisi wonder if at this point its a cmake problem and I know very little about it16:08
markadavis: the only recipe I have worked on with multiple git repos is the recipe for spice16:08
davislet me look at it, one sec16:09
markanot sure if that will help but having a reference is never a bad thing16:09
rburtondavis: seriously, pastebin how it breaks and what you expect it to do, it may be something trivial16:09
rburtonbut just saying "it doesn't work" means nobody can help16:10
davislol, but i'm so verbose.16:10
davisi updated the gist to have an error16:11
davisbtw, if i use OECMAKE_SOURCEPATH is generates same error as without it specified16:11
rburtonyeah because its running cmake fine and its finding the cmakelists16:12
rburtonso where are the files its looking for16:12
davisfwiw, when i look at the error, it looks to me like its in this dir:16:12
davispcmx is the name of the recipe16:12
rburtonyes, we do out of tree builds, and tell cmake where the cmakelists is16:12
rburtonlook at the cmake invocation in the log you pasted16:13
davisthe actual code would be in pcmx/xxxxgitxxxr0/git/pcmx16:13
rburtonright, and its finding the cmakelists fine16:14
rburtonbecause its reading that and then saying it can't find other pieces16:14
rburtonso where are they and where is it actually looking16:14
davisits hard for me to say, let me show in pastebin. it looks like it trying to build pcmx seperate16:15
davisone sec16:15
rburtonbasically we're out of "yocto" and into "your code"16:15
davisyeah that might be it16:16
davisi'm mistaken16:16
davisthe other subdir there is not for pcmx src its for timestamps and such16:16
davisso, if I make a subdir say foo and then cd to foo and git pull the three repots16:17
davisdo a cd foo/pcmx/ and then do cmake . it builds16:17
rburtonso try mkdir foo/build ; cd build ; cmake ../pcmx16:17
rburton(which is all the class is doing)16:18
rburtontenner says that fails and your cmakelists has false expectations about file layout16:18
davisyes,, if I do cd to tree in bitbake and do cmake . in same place as where I do this manually it fails.16:19
daviswith the error shown in bitbake16:19
*** rcw <rcw!~rwoolley@> has joined #yocto16:21
rburtonso we now know its nothing to do with yocto16:22
rburtonbut your software not handling out-of-tree builds16:22
rburtonso after inherit CMAKE set B=${S} and add a comment along the lines of "fix the stupid cmakelists"16:22
*** darwish <darwish!~darwish@> has joined #yocto16:24
darwishHello .. How can I mask a MULTILIB version of a recipe, instead of its whole?16:25
darwishBBMASK does not understand multilib prefexes it seems :-(16:25
kergothwhat exactly are oyu trying to achieve with bbmask?16:26
kergothbbmask should only be used to work around parse errors16:26
darwishkergoth, I have a recipe (provided by board manufacturerer in their own layer) which extracts binary .so files (related to graphics). These .so files are only 64-bit version (under /usr/lib64). Meanwhile MULTILIB 32-bit support is enabled, and Bitbake tries to build the 32-bit version of it16:28
darwishAnd when building 32-bit version, do_install() tries to install libraries from ${libdir} (/usr/lib in 32-bit mode). This folder does not exist, and thus the build fails :-(16:29
kergothwhy is bitbake trying to build the 32 bit version of it? what's pulling it into your build? if something is pulling it in, bbmask isn't going to magically fix that, it'll just error out instead16:30
darwishkergoth, I guess that's the right question to ask .. Is there a way to know who's pulling the 32-bit version?16:31
kergothpresumably you could also disable multilibs for that recipe, so the variants don't get created for it16:31
kergothbitbake -g is your best bet, either with or without -u depexp16:31
darwishkergoth, great! and the second part: "disable multilibs for that recipe" .. how to do that? check for ${MLPREFIX} in a .bbappend ?16:32
*** florian <florian!~fuchs@Maemo/community/contributor/florian> has quit IRC16:34
*** ka6sox is now known as zz_ka6sox16:35
*** joseppc <joseppc!~josep@linaro/joseppc> has quit IRC16:36
*** jbrianceau is now known as jbrianceau_away16:44
*** ntl <ntl!> has joined #yocto16:45
*** dvhart <dvhart!dvhart@nat/intel/x-aefbatxgisejnlzs> has joined #yocto16:47
*** gtristan <gtristan!~tristanva@> has quit IRC16:47
HyP3rmarka: I've compiling the kernel linux-toradex its from the meta layer meta-toradex but this kernel also inherits the class kernel. You are posting link to the documentation. I followed this topic
HyP3rCTtpollard: there are so many recpies and different which makes it really hard.16:50
HyP3rCTtpollard: and the customer is crying everyday into my ears why I'm not finished16:51
HyP3rBut ok, I'll get that today ;)16:51
*** raymanfx <raymanfx!raymanfx@gateway/shell/> has left #yocto16:51
*** RagBal <RagBal!> has joined #yocto16:52
*** Rootert <Rootert!> has joined #yocto16:52
*** dreyna <dreyna!> has joined #yocto16:52
*** dvhart <dvhart!dvhart@nat/intel/x-aefbatxgisejnlzs> has quit IRC16:56
HyP3rThis fyi:16:56
*** CTtpollard <CTtpollard!> has quit IRC17:00
*** hamis_lt_u <hamis_lt_u!~irfan@> has quit IRC17:02
*** t0mmy <t0mmy!> has quit IRC17:03
HyP3rmarka: well thats the answer: the recpie linux-yocto inherits kernel and kernel-yocto. This bbclass searches for cfg files and applies them. My linux-toradex only inherits kernel.bbclass, thats the reason why its not working17:05
HyP3rSo now for all: my custom kernel script (from toradex) which is not using that way of adding configurations. How should I do it then?17:05
HyP3rWith classic patches? should I just patch the .config file?17:06
HyP3r(lol classic)17:06
*** lamego <lamego!~jose@> has quit IRC17:08
*** fl0v0 <fl0v0!> has quit IRC17:09
*** yann <yann!> has joined #yocto17:09
*** JaMa <JaMa!> has quit IRC17:12
zeddiiHyP3r, a defconfig will work with something that just inherits kernel.bbclass.17:18
HyP3rlinux-tordax allready applies a defconfig
HyP3rI guess I use this :S ->
zeddiiaha. yes.17:19
HyP3recho "foobar" >> .config <- what a nice solution17:19
zeddiiin that case, I'd say copy their defconfig, add your lines and then add it to your layer17:19
AgentElrondEvery time I see a Dr. Dobb's article I get sad :(17:19
AgentElrondat least the archive is still up17:19
HyP3rzeddii: wouldn't it then collied while fetiching phase?17:19
zeddiithe layer ordering and priority will take care of it.17:20
zeddiiI can't say the order precisely from memory .. so double check.17:20
zeddiiHyP3r. that's why my latest series for master is a prep to extend the fragments to all kernel types. but there is a LOT of history in the config of the kernels, so it has been a multi year effort to get something reasonable.17:21
*** dvhart <dvhart!dvhart@nat/intel/x-cnuyvsxbealulehy> has joined #yocto17:21
HyP3rzeddii: yup, I'll copy that defconfig into my directory and run bitbake -c patch linux-toradex, I'll see whats there17:21
* zeddii has to transition, but will reappear as zeddii_home in a bit.17:21
zeddiicool. I'll be around if it doesn't work. we can sort it out and avoid any really nasty hacks :P17:22
HyP3rzeddii: good driving or so :)17:22
*** joseppc <joseppc!~josep@linaro/joseppc> has joined #yocto17:28
*** lamego <lamego!~jose@> has joined #yocto17:28
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has quit IRC17:29
*** AgentElrond is now known as hweaving17:29
kergothRP: did anyone add 'unset' to the bitbake vim syntax?17:37
*** dvhart <dvhart!dvhart@nat/intel/x-cnuyvsxbealulehy> has quit IRC17:39
*** agust <agust!> has joined #yocto17:39
-YoctoAutoBuilder- build #896 of nightly-x86-lsb is complete: Success [build successful] Build details are at
*** RagBal <RagBal!> has quit IRC17:54
*** RagBal <RagBal!> has joined #yocto17:54
*** dvhart <dvhart!~dvhart@> has joined #yocto17:59
*** dvhart <dvhart!~dvhart@> has quit IRC18:00
*** RagBal <RagBal!> has quit IRC18:03
*** slidercrank <slidercrank!~slidercra@unaffiliated/slidercrank> has joined #yocto18:05
*** RagBal <RagBal!> has joined #yocto18:05
*** blueness <blueness!~blueness@gentoo/developer/blueness> has quit IRC18:18
*** blueness <blueness!~blueness@gentoo/developer/blueness> has joined #yocto18:22
-YoctoAutoBuilder- build #646 of nightly-oe-selftest is complete: Success [build successful] Build details are at
*** blueness <blueness!~blueness@gentoo/developer/blueness> has quit IRC18:29
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has joined #yocto18:32
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto18:34
*** anselmolsm <anselmolsm!~anselmols@> has quit IRC18:34
*** blueness <blueness!~blueness@gentoo/developer/blueness> has joined #yocto18:37
*** dreyna <dreyna!> has quit IRC18:38
*** anselmolsm <anselmolsm!anselmolsm@nat/intel/x-jusmptvijhuicmum> has joined #yocto18:40
*** rcw <rcw!~rwoolley@> has quit IRC18:49
*** jbrianceau_away <jbrianceau_away!uid10952@gateway/web/> has quit IRC18:49
*** rcw <rcw!~rwoolley@> has joined #yocto18:50
*** gbisson <gbisson!> has joined #yocto18:53
davisif i want to force a repull from git and build of the target foo, $bitbake -c do_cleanall foo will do it correct?18:55
davisie. $ bitbake foo will then pull, configure and build afterwards18:55
*** zz_ka6sox is now known as ka6sox19:00
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC19:01
*** rcw <rcw!~rwoolley@> has quit IRC19:01
kergothno, cleanall doens't prevent use of sstate19:01
kergothit'll re-run the tasks, but it might just pull from sstate rather than building19:01
*** rcw <rcw!~rwoolley@> has joined #yocto19:01
kergothbitbake -c cleanall foo; bitbake -C fetch foo; would be my recommendation. you could also do cleansstate along with cleanall, but sstate can still be used after a cleansstate when SSTATE_MIRRORS is involved. -C will force the matter regardless19:02
daviskergoth: many thanks19:04
*** IanCoolidge <IanCoolidge!46a9e369@gateway/web/freenode/ip.> has joined #yocto19:07
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has quit IRC19:10
*** igor2 <igor2!~igor@> has quit IRC19:10
HyP3rzeddii zeddii_home its colliding, and ignoreing my file -.-19:10
*** igor2 <igor2!~igor@> has joined #yocto19:11
darwishkegroth, sorry for resurrecting an older discussion ;-) You've mentioned earlier you can disable multilib for a certain recipe?19:12
kergothdavis: there's also bitbake's --setscene-only and --no-setscene arguments, but that'll affect any task bitbake runs, not just the ones for this recipe, so -C would be best there19:12
darwishkegroth, thanks a lot for your advice earlier btw. I've indeed now know who pulls the undersied 32 bit versions of the library :D19:12
daviskergoth: rocks so much they need to rename that branch, s/krogoth/kergoth/19:13
kergothdarwish: in theory the recipe could override MULTILIBS = "", but i've never tried it19:13
*** MWelchUK <MWelchUK!> has quit IRC19:13
kergothdavis: hah19:13
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has joined #yocto19:14
darwishkergoth, I see .. thx :-)19:15
davishmm. ok i had an error in my cmake project based source.19:15
davisoddly enough when i was building at cmdline it was using something left around from before19:16
davisi fixed that.  Now I can definitely issue the git pull outside bitbake, do cmake -G "Unix Makefiles" and then cmake . followed by make and all builds fine19:16
davishowever, if I go to bitbake pulled source with corrected source. at least I did -C fetch and clean, it fails.19:17
davisit fails for diff reason than before so at least i'm making forward progress, yay!19:18
davisok, it appears that the cmake build for this proj is putting files in my home dir which it uses to build. that ain't gonna work.19:25
*** MWelchUK <MWelchUK!> has joined #yocto19:25
rburtonha, nice!19:25
rburtonthat's an all-new level of screwedup that i hadn't considered19:26
daviswell there was some errors before where the gstreamer receipe you pointed out got me to here.19:26
IanCoolidgeHi all. Is there a standard bitbake module recipe formula that addresses when a module needs symbols from another module? I pointed KERNEL_SRC to the kernel build's WORKDIR/build and it works. It's just very hack-y19:27
rburtonpaging zeddii for IanCoolidge's question19:28
zeddii_homeHyP3r: I ran a test here, and works as I’d expect.19:32
zeddii_homemy 2nd defconfig is the file in ${WORKDIR} and hence fed into the kernel configuration step.19:33
HyP3rin ${WORKDIR} is allready a defconfig :/19:34
zeddii_homethat’s not the point.19:34
HyP3rAnd my defconfig is not at this position19:35
zeddii_homedepending on the order in the SRC_URI and how you bbappended the file://defconfig, the last one is going to remain there.19:35
HyP3rCan you tell me how can I get the information which bb file is exectued (or runng) when I call bitbake -c config linux-toradex19:36
HyP3rIn my stuff folder (with the layers inside) I have more than 5 linux-toradex*.bb files19:36
HyP3rI'm slowly getting confused around that19:36
IanCoolidgehighest version or the PREFERRED one gets ran19:36
zeddii_homeeither the latest / highest version. or the one that is tagged as compatible with your $MACHINE.19:37
zeddii_homebitbake -e has all the info about what is being processed.19:37
HyP3rNone of the linux-toradex files is 'PREFERRED' set but I gues its working with MACHINE19:38
HyP3rThats a huge load of data '-e'19:41
HyP3rThats so depressing19:41
IanCoolidgeyou could set it in local.conf like: PREFERRED_VERSION_linux-toradex = "1.2.3" make sure is chosen. Although its redundant if you're using the highest version19:42
IanCoolidgeor tmp/work/{machine}/linux-toradex/ would show the version being built19:42
zeddii_homeor just temporarily remove all but one :)19:42
HyP3rYeah I'm a often in this directory to see whats happens e.g. while configure19:42
HyP3rthere I have the 4.1-r019:43
HyP3rBut I have two recpies which is build 4.119:43
HyP3rBut with different checksums19:43
IanCoolidgego into git and do git log19:43
IanCoolidgeor have one recipe instead19:43
HyP3rI did bitbake -c configure linux-toradex went into the working diretory and took a look into the current checkout and it was fitting with another file (o.O) wait I post it here19:44
HyP3rBut thats not all... wait o.O19:46
HyP3rMind the directory about:
HyP3rI guess files like and so on are ignored. Only this file from Freescale is loaded but then Version changed with this file from Toradex.19:48
HyP3rBecause the "e6d111cd909551cec5902358db1e25dcaa8c86bb" <- hash is matching with my current version19:49
HyP3rSo NOT the Scripts of Toradex are working the Script from Freescale (which are more obvious) are working19:49
*** gtristan_ is now known as gtristan19:51
*** rcw <rcw!~rwoolley@> has quit IRC19:52
*** rcw <rcw!~rwoolley@> has joined #yocto19:52
HyP3rBut over all: zeddii_home here is my current bbappend (please mind there is allready another bbappend from toradex loaded):
HyP3rOr anthoer path: can't be append with linux-toradex_4.1.bbappend?19:59
RPkergoth: no, I suspect not20:00
IanCoolidgemake it linux-toradex_%.bbappend20:00
kergothRP: k, figured, i'll see about updating it20:01
HyP3rMy append file is loaded but wins not the race with defconfig anthoer defconfig (out of 3) is feteched :/20:01
IanCoolidgedo FILESEXTRAPATHS_append += "${THISDIR}/${PN}:"20:02
HyP3rTake a look at my pastebin20:02
HyP3rIanCoolidge: I added this20:02
HyP3rIanCoolidge: or I have this :) sorry20:02
*** dreyna <dreyna!> has joined #yocto20:02
kergothIanCoolidge: that will not work. FILESEXTRAPATHS is : separated, not space, and += adds a space20:03
kergoththat needs to be =, and even then, _append is wrong, it'll be the lowest priority, not highest, you want prepend20:03
kergoths/needs to be =/needs to be :=/20:03
kergoth:= forces immediate expansion, which makes THISDIR resolve to the subdir of the append, otherwise it'll be the subdir of the recipe20:04
HyP3rI gues I don't win the race because of that vs.
IanCoolidgeAH, you're right20:05
IanCoolidgeyeah, I use FILESEXTRAPATHS_append := "${THISDIR}/${PN}:"20:05
IanCoolidgei'm so used to just +='ing everything20:05
HyP3rand my meta folder has the name 'meta-racechip' and the other is 'meta-toradex' so the with toradex wins -.-20:05
*** billr <billr!~wcrandle@> has quit IRC20:05
kergothHyP3r: layer priority is what matters here.20:06
HyP3rWhere can I configure that?20:06
*** jbrianceau_away <jbrianceau_away!uid10952@gateway/web/> has joined #yocto20:07
*** jbrianceau_away is now known as jbrianceau_home20:07
HyP3rOnly to make sure: the layer racechip and toradex is loading defconfig who who should have the higher prioroty to win?20:08
kergothhighest priority gets preferred over lower priority20:09
HyP3rwhats a high priority a low or high value? I've saw systems where 0 is the highest prio.20:10
kergoththat wouldn't make sense here. in yocto we have no idea what future layers might exist, which may well need to override the core. it needs to grow toward higher priority, not toward lower20:10
kergothhigh = high20:10
HyP3rokay thanks :)20:11
HyP3rWell I guess this night I will run a bitbake -c cleanall and a full new build, after this priority change I'm feeling not really well20:14
kergothif you want to know which defconifg will be used, just bitbake -e yourrecipe | grep FILESEXTRAPATHS=, make sure the layer you want to be used is before the other in the list20:14
*** vlad_b <vlad_b!> has joined #yocto20:15
HyP3rYeah. Priority fixed that. Now its working thanks kergoth IanCoolidge and zeddii_home :)20:18
zeddii_homegood news.20:18
zeddii_homeI had looked away.20:18
zeddii_homeglad you got it sorted.20:18
HyP3rWhat a akward include strucrute, but I see that the developer has cleaned that20:18
*** dvhart <dvhart!dvhart@nat/intel/x-znvvmgcitzabhchn> has joined #yocto20:18
zeddii_homethere’s lots of rope out there. and lots of questionable layer structures out there. but the flexibility is the power and bane of the system :D20:19
HyP3rI gues it make sence to build a network - device - flashing infrastructure, I have the bad feeling that this is not the last time yocto compiling my kernel and so on20:23
*** igor5 <igor5!~igor@> has joined #yocto20:23
*** ntl <ntl!> has quit IRC20:24
*** istarilucky <istarilucky!~rlucca@> has quit IRC20:24
*** obsrwr_ <obsrwr_!~otp-amois@> has quit IRC20:24
*** hweaving <hweaving!> has quit IRC20:24
*** igor2 <igor2!~igor@> has quit IRC20:25
*** pohly <pohly!> has joined #yocto20:31
*** benjamirc <benjamirc!~besquive@> has quit IRC20:31
*** dvhart <dvhart!dvhart@nat/intel/x-znvvmgcitzabhchn> has quit IRC20:32
*** rcw <rcw!~rwoolley@> has quit IRC20:35
*** sno <sno!> has joined #yocto20:36
*** dholland <dholland!> has quit IRC20:39
darwishIs there a way to remove stuff from IMAGE_INSTALL .. rather than just append to it?20:54
HyP3rdarwish: you can copy the recpie and remove the lines? I know thats not a nice solution21:01
darwishHyP3r, yeah .. I wished there would be a way to do so like the _append mechanism :-(21:02
HyP3rah ok21:02
darwishOK .. Now imagine I'm depending on a silicon provider recipe & image .. and that image contains known buggy packages that I want to remove .. what's the best way to not include them?21:03
darwishBBMASK the hell out of them? :D21:03
IanCoolidgeIMAGE_INSTALL_remove in local.conf, maybe21:03
zeddii_homeIMAGE_INSTALL is just a variable21:03
zeddii_homeso yah, what IanCoolidge says will work.21:03
darwishoh .. didn't know there's a _remove suffix .. will recheck the docs!21:03
*** marka <marka!> has quit IRC21:04
*** junland <junland!~junland@> has quit IRC21:05
davisso it appears this cmake build needs fully qualified pathnames. It builds stuff in /home/foo and /home/goo  which it then uses to do the rest of its build. I've tried to dork with it to do relative makes but it fails. I give up on that. I have managed to get it work with /tmp/foo type mechanism.  However this seems to be a problem in bitbake. Is this even possible? have a fully qualifed dir to build things,21:14
davisthen use that dir to build other things?21:14
neverpanicCan you describe what you're trying to do? I can't figure it out from what you wrote.21:15
kergothcmake handles out of tree builds just fine. patch that buildsystem to do something that makes sense and move on21:16
kergothall cmake.bbclass does is runs cmake. there's no magic.21:16
daviswell, its not working as is.21:18
davisif I use the source in the build/tmp... dir and do $ cmake -G "Unix Makefiles"; make it will build21:18
kergothas i said, the buildsystem is doing something stupid, patch cmakelists to behave the way every other sane buildsystem does21:18
*** agust <agust!> has quit IRC21:19
davisbut its using files in /tmp/foo21:19
davisyah, I am just trying to patch up something which works outside bitbake to be bitbake compliant21:19
davisand I get an error in bitbake which I don't otherwise.21:20
davisi think if I can get it to stop doing fully qualified subbuilds this will work.21:20
kergothagain, all bitbake does is runs cmake. there's no magic. but it does expect everything to build in ${B} against source in ${S}. if it's assuming stupid ahrdcoded paths, then that needs to be fixed21:21
daviskergoth: I agree. i'm 100% on that.21:22
davisbecause using /tmp is not working.21:22
davisso one question though. i was trying to see if cmake was doing a $cmake . or a $camke -G "Unix Makefiles" though21:23
davisi could not, but I found a variable in cmake.bbclass21:23
davisI tried to set that to do this, but that did not change my situation.21:24
davisthe log.do_configure shows the results of cmake command, but not the command which generated the file.21:25
davisthre is a run.do_configure script21:26
davisI'm guessing its in there somewhere.21:26
kergothit's running cmake ${S}21:27
davisone sec, let me look at your links21:27
kergothit cds to ${B}, then runs cmake ${S}21:27
kergothsame as you'd do outside of bitbake to build in a separate build dir21:27
kergothyou cd to the build dir, then cmake /path/to/source/tree21:27
kergoththen make21:27
kergothexactly what bitbake does21:27
kergothits' not passing -G "Unix Makefiles", presumably because that's default behavior21:27
kergoththe links are just lines in cmake.bbclass..21:28
kergothEXTRA_OECMAKE += "-G 'Unix Makefiles'" would work fine, if you think that's a factor, but i doubt it21:28
*** nisha <nisha!~nisha@> has quit IRC21:28
davisyeah, well in this cmake setup ive tried to do $cmake . and outside of bitbake and it fails. however, if I do $cmake -G "Unix Makefiles" it does.21:29
kergothyou removed '.' from the latter?21:29
davisso perhaps that is something which will also need to be fixed.21:29
davisno, i removed nothing.21:29
kergothyou just wrote two commands, but -G wasn't hte only change21:29
rburtonif its out of tree that is breaking then just set B=${S} *after* the inherit cmake21:29
kergoth'cmake .' and 'cmake -G "Unix Makefiles"' -> the latter doesn't have the source tree path21:29
davisjust in an regular shell. this works $ cmake -G "Unix Makefiles"; make21:29
kergothyou removed .. so you made two changes to the command, you added the -G, and you removed the path to teh source tree21:30
kergothbut yes, as rburton says, if the problem is the out of tree build, just set B = ${S} and move on21:30
*** berton <berton!~fabio@> has quit IRC21:33
*** dmoseley <dmoseley!> has quit IRC21:34
*** pohly <pohly!> has quit IRC21:35
davishhmm. if I do "inherit pkconfig cmake" and on next line B="${S}" as well as remove EXTRA_OECMAKE variable mod it fails.  After I make the change, I'm doing this to test it. $ bitbake -c cleanall pcmx; bitbake -c fetch pcmx; bitbake pcmx21:36
davisin more concise terms21:38
*** pohly <pohly!> has joined #yocto21:40
rburtoni presume the comment about how the build should be in d3 is wrong as you set S to pcmx21:40
rburtonso now bitbake is just going into git/pcmx and running "cmake ."21:41
rburtonliterally that's it21:41
rburtonif you can make that work outside of bitbake then i guess you want to start looking at the toolchain file the class writes and how that could be breaking your cmakelists21:42
davisyes, that is an error in the comment.21:42
davisit should be pcmx21:42
davisby moving that B= line after inherit21:42
davisit has the same error, but now when I try to build in shell ouside bitbake environment in the build dir it complains about c compiler21:43
davisso that is doing something21:43
rburtonso important test is do some clean checkouts, go into pcmx, run cmake .21:44
davisim in middle of clean/fetch/build now. when completes. ill try21:44
*** dvhart <dvhart!~dvhart@> has joined #yocto21:44
rburtonalso, try out of tree build from clean with a build alongside the clones, cd into it and run cmake ../pcmx21:44
rburtonif those work then out-of-tree is fine and basically you've either got a really bad cmakelists, or our toolchain file (which tells cmake what compiler to use) is upsetting your cmakelists (which implies you've a bad cmakelists)21:45
*** igor5 <igor5!~igor@> has quit IRC21:45
davisso you guys have been saying out of tree builds. I might not have clear understanding. I think you mean, if you are using bitbake and it puts files in build, get a new shell and cd to build/tmp-glibc/....pcmx/../git/pcmx and do the command there.21:46
*** dvhart <dvhart!~dvhart@> has quit IRC21:46
rburtonan out of tree build is simply where you make puts the compiled objects into a directory that isn't where the sources are21:47
rburtonso the WORKDIR/build directory that cmake.bbclass uses, where the cmake generated files and eventually the binaries end up21:47
davisthis is the soruce dir ~/setup-scripts/build/tmp-glibc/work/corei7-64-oe-linux/pcmx/1.0.0+gitAUTOINC+d3_d3v16_pcmx-r0/git/pcmx$21:47
rburtonthey're good because it means we can delete it automatically on rebuilds21:47
davisi thought it was the build dir as well.21:47
davisthat is where i was trying to do build outside of bitbake21:48
rburtoni'd do tests outside of bitbake with entirely fresh checkouts21:48
davisoutside of bitbake just in a unix shell, $cmake . fails. $cmake -G "Unix Makefiles" works.21:49
rburtonimpressively broken cmakelistss21:49
davisso it looks like bitbake is trying to do cmake .21:49
rburtonwhat about just cmake21:49
rburtonwithout the -G21:49
rburton(because that is the default value)21:50
davis$cmake says usage error. i belive that will fail on the cmake tutorial source as well.21:51
davisok, i stand corrected21:51
davisnow if I do $cmake . it works.21:51
rburtoni *bet* your cmakelists expects the build dir to be a subdirectory of the top level of the sources21:51
rburtonoh right21:51
davisthen again, i've dorked with the cmake file today in this sample repot21:51
davistrying to fix things.21:52
rburtoncmake defaults to doing builds inside a directory under the source tree21:52
rburtonwe move it for ease of cleaning and no sane cmakelists will care21:52
davisim just trying to make sure, i don't have any artifiactgs in /home/davis and /tmp21:53
rburtonbut if the cmakelists is assuming that ../ is the source tree then all sorts will fail21:53
davisthey all look clean21:53
davislet me get a new shell as well, since it might have something in environment21:53
rburtonliterally impossible to debug software via irc and pastebin, hooray open source!21:53
* rburton -> bed21:53
davissweet, so yes indeed if I open new terminal, ensure /tmp and /home have no artifacts. cmake . works so that is good.21:54
davisrburton: goodnight21:54
rburtontry an out of tree build to see if that works. mkdir build alongside your checkouts, cd into it, cmake ../pcmx21:56
rburtonif that works then congratulations you've reduced it down to bad interaction between our toolchain file generated by cmake.bbclass and your source21:56
davisyes, if I do clean git checkout, cmake .; make it builds21:56
*** Girafferson <Girafferson!~Giraffers@2601:281:8500:95b0:5249:f3c:d4e2:30a9> has joined #yocto21:56
davisie. seperately from bitbake21:57
davisit will put stuff in /tmp/jfdinstall though21:57
*** nisha <nisha!~nisha@> has joined #yocto21:57
daviscmake will put files in /tmp/jfdinstall that it uses to complete cmake step.21:57
rburtonfor no sensible reason as there's a perfectly good build directory to use21:58
rburtonhave fun21:58
davisyes, when they told me they were using cmake21:58
davisi said, we can strip out cmake and make our life easier21:58
rburtoncough feel free to leak the software online cough21:58
davisyah, have a good night21:58
davissleep well. im going to bolt to do homework soon.21:58
*** rburton <rburton!> has quit IRC21:59
neverpanicdavis: cmake works fine if it's used correctly, it's incorrect use of cmake that puts stuff in /tmp/jfdinstall; no sane CMakeLists.txt will do that.22:00
davisneverpanic: i agree.22:00
*** bfederau <bfederau!> has quit IRC22:01
*** fmeerkoetter <fmeerkoetter!> has quit IRC22:01
*** fmeerkoetter <fmeerkoetter!> has joined #yocto22:01
*** bfederau <bfederau!> has joined #yocto22:01
davisi tried to change the cmakelist.txt to use relative build settings for some of the tools. ie. XXX=../jfdinstall and it did not work22:01
Giraffersonwhy is it that I set up my environment yet I am constantly missing packagegroups22:01
davishowever the deeper parts of this build work, it seems to require fully qualifed pathnames.22:02
Giraffersonone of the packagegroups I needed I had to copy and paste a changelog because I couldn't actually find the file22:02
neverpanicdavis: you shouldn't try to use relative paths, use ${CMAKE_BINARY_DIR} and other appropriate CMake variables22:02
Giraffersonwhy do I need a packagegroup from openembedded-core? I thought I only needed the meta-openembedded but core-image-minimal is saying I'm missing dependencies from it22:07
Giraffersonit's saying the dependency is unbuildable...22:09
davisneverpanic: the cmakelists.txt file i'm editing is setting CMAKE_BINARY_DIR and corresponding instal dir to be /home/foo22:11
davisi changed that to /tmp/foo since ../foo and ./foo did not work.22:12
Giraffersondoes anyone know anything on getting unbuildable error on a packagegroup. I can't find anything22:14
neverpanicdavis: A CMakeLists.txt should never set CMAKE_BINARY_DIR; CMAKE_BINARY_DIR should always be the current working directory when calling CMAke22:15
neverpanicA CMakeLists.txt should also never set CMAKE_INSTALL_PREFIX, that's for users to set.22:15
davisSET(CMAKE_BINARY_DIR ./tmp/JFDInstall/development/PCMX/build)22:15
davisi hear what you are saying. i'm just working with an existing setup22:16
davisif I use ./tmp it fails. /tmp it works.22:16
neverpanicGirafferson: You're not providing any of the information required to debug this. You didn't pastebin an error message. Nobody can help you with this.22:16
davisim trying to figure it out.22:16
neverpanicdavis: Just delete those two lines.22:16
neverpanicAnd tell whoever wrote them to read the CMake documentation22:16
davisneverpanic: lol22:16
davisoh man, lol22:16
neverpanicBut then again, since they set those two files, it's likely that they actually rely on those paths elsewhere :/22:17
davisyah cmake works, but make immediately tries to create a dir /usr/local/foo22:18
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has quit IRC22:19
neverpanicdavis: that's likely because the CMakeLists.txt uses CMAKE_INSTALL_PREFIX where it should be using CMAKE_BINARY_DIR22:19
*** joshuagl <joshuagl!~joshuagl@> has quit IRC22:20
neverpanicGirafferson: crda is in meta-networking, see
neverpanicYou're right that this is part of meta-openembedded.22:21
neverpanicHowever, poky master doesn't have this dependency in its packagegroup-core-boot:
neverpanicSo either some other layer sets one of the variables in this recipe to include crda, or the file looks different for you (because you're on a different branch for example)22:22
Giraffersoni don't understand why I have to include each meta from meta-openembedded22:22
neverpanicUse bitbake -e packagegroup-core-boot and figure out where the crda in RDEPENDS_${PN} comes from22:22
neverpanicYou shouldn't have to; it might be your bsp that forces you to.22:23
*** IanCoolidge <IanCoolidge!46a9e369@gateway/web/freenode/ip.> has quit IRC22:25
davisneverpanic: imm tryinhg your suggestion22:26
davisneverpanic: btw are you German?22:26
neverpanicYes; which means it's half past midnight, and since I have to work tomorrow I'll likely leave soon.22:28
Giraffersonok thank you; I just added in meta-networking and meta-python. I still don't understand the meta-openembedded layer but I'll have to look at it once I finish the build22:28
davisok very good. i worked in germany. schon platz.22:29
davishave a good night. i'm fixing up the enumerous make+directory entries now.22:29
davislol, its building out of source now, with relative dir.22:31
davisits getting closer, many thanks.22:31
neverpanicyou're welcome. Good night and happy debugging.22:31
davisghuten nach22:31
*** lamego <lamego!~jose@> has quit IRC22:36
*** sameo <sameo!samuel@nat/intel/x-jwytddvjjbgxjloj> has quit IRC22:49
*** jbrianceau_home is now known as jbrianceau_away22:49
*** aehs29 <aehs29!~aehernan@> has left #yocto22:54
*** darknighte <darknighte!~darknight@pdpc/supporter/professional/darknighte> has quit IRC23:05
*** _william_ <_william_!> has quit IRC23:08
*** sameo <sameo!samuel@nat/intel/x-pmmnmpekvzlltogk> has joined #yocto23:08
khemabelal: this patch looks ok23:13
khemross will pick it up23:13
khemjubr: no, it wont work from config context23:14
seebsso, a heads-up for people, yes, I'm aware of the Exit Status 4 messages from pseudo, I think the message is a harmless diagnostic and probably doesn't need to be displayed (the startup code had some fancy stuff in it because I was debugging it, and since it didn't show up under light load, I didn't look too closely), but I'm gonna try to double-check.23:35
*** sameo <sameo!samuel@nat/intel/x-pmmnmpekvzlltogk> has quit IRC23:38
*** anselmolsm <anselmolsm!anselmolsm@nat/intel/x-jusmptvijhuicmum> has quit IRC23:41
*** nighty-- <nighty--!> has quit IRC23:43

Generated by 2.11.0 by Marius Gedminas - find it at!