Thursday, 2016-07-21

*** sgw_ <sgw_!~sgw_@> has quit IRC00:01
*** Crofton <Crofton!> has quit IRC00:02
*** billr <billr!~wcrandle@> has quit IRC00:02
*** t0mmy_ <t0mmy_!~tprrt@> has quit IRC00:26
*** sameo <sameo!samuel@nat/intel/x-ylusvvipifzesmzd> has quit IRC00:45
*** paulg <paulg!> has quit IRC00:45
*** tjamison <tjamison!~tjamison@> has quit IRC01:07
*** armpit <armpit!~akuster@> has quit IRC01:11
*** ka6sox is now known as zz_ka6sox01:48
-YoctoAutoBuilder- build #848 of nightly-ppc-lsb is complete: Failure [failed Running Sanity Tests] Build details are at
*** RagBal <RagBal!> has quit IRC02:23
*** Rootert <Rootert!> has quit IRC02:23
khempaulg_: dev branches are rebased IIRC, so all one should use for them is AUTOREV02:31
*** blueness <blueness!~blueness@gentoo/developer/blueness> has quit IRC02:40
*** crankslider <crankslider!~slidercra@unaffiliated/slidercrank> has quit IRC02:51
-YoctoAutoBuilder- build #948 of nightly is complete: Failure [failed] Build details are at
*** blueness <blueness!~blueness@gentoo/developer/blueness> has joined #yocto03:19
*** zz_ka6sox is now known as ka6sox03:28
*** tomz_ <tomz_!tomz@nat/intel/x-aujhhkciodvyhvol> has quit IRC03:55
*** tomz_ <tomz_!~tomz@> has joined #yocto04:09
*** ka6sox is now known as zz_ka6sox04:53
*** zz_ka6sox is now known as ka6sox05:08
*** obsrwr <obsrwr!> has joined #yocto05:18
*** obsrwr <obsrwr!> has quit IRC05:21
*** LocutusOfBorg <LocutusOfBorg!~Gianfranc@ubuntu/member/locutusofborg> has quit IRC05:30
*** armpit <armpit!~akuster@2601:202:4001:9ea0:81a:ab00:ca81:5385> has joined #yocto05:38
*** agust <agust!> has joined #yocto05:42
*** sgw_ <sgw_!~sgw_@> has joined #yocto05:44
*** sno <sno!> has quit IRC05:44
*** sno <sno!> has joined #yocto05:50
*** sno <sno!> has quit IRC05:53
*** Nilesh_ <Nilesh_!uid116340@gateway/web/> has joined #yocto05:54
*** sno <sno!> has joined #yocto05:54
*** sno <sno!> has quit IRC06:07
*** kukowski <kukowski!c2fb77c5@gateway/web/freenode/ip.> has joined #yocto06:13
kukowskiHi, i have a problem with task in python, how from python function knows that previous task running from cache or not ?06:14
*** pohly <pohly!> has joined #yocto06:19
*** V12 <V12!c32a382c@gateway/web/freenode/ip.> has joined #yocto06:20
V12hi guys06:23
kukowski Hi, i have a problem with task in python, how from python function knows that previous task running from cache or not ?06:26
kukowskianybody don't know it ?06:29
kukowskiif do_compile was running the binares are in $D dir but if not binaries are in $SYSROOT-DESTDIR dir, so i have to overwrite path to files, how know that the task was running ?06:32
*** hamis_lt_u <hamis_lt_u!~irfan@> has joined #yocto06:34
*** Rootert <Rootert!> has joined #yocto06:34
*** RagBal <RagBal!> has joined #yocto06:35
kukowski if do_compile was running the binares are in $D dir but if not binaries are in $SYSROOT-DESTDIR dir, so i have to overwrite path to files, how know that the task was running ?06:36
V12kukowski: you can make your task dependant of do_compile06:37
kukowskii have to do it in my python function06:38
V12addtask your_py_func after do_compile06:39
V12python your_py_func() {}06:40
V12should do the trick06:40
kukowskii can't overwrite file with do_compile function, i have to know that do_compile was running from my another file with run_ptest task06:44
*** csanchezdll <csanchezdll!> has joined #yocto06:46
*** MWelchUK <MWelchUK!> has quit IRC06:48
*** qt-x <qt-x!~Thunderbi@> has joined #yocto06:49
*** MWelchUK <MWelchUK!> has joined #yocto06:49
*** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has joined #yocto06:55
*** obsrwr <obsrwr!> has joined #yocto06:57
*** zeddii_home <zeddii_home!> has quit IRC06:58
*** zeddii_home <zeddii_home!> has joined #yocto06:59
*** melonipoika <melonipoika!~jose@> has quit IRC07:04
*** oan <oan!> has quit IRC07:04
*** rajm <rajm!> has joined #yocto07:12
*** townxelliot <townxelliot!~ell@> has joined #yocto07:14
*** melonipoika <melonipoika!~jose@> has joined #yocto07:15
*** present <present!~present@> has joined #yocto07:19
*** sno <sno!~sno@> has joined #yocto07:21
*** __karthik <__karthik!~karthik@> has quit IRC07:21
*** __karthik <__karthik!~karthik@> has joined #yocto07:22
*** V12 <V12!c32a382c@gateway/web/freenode/ip.> has quit IRC07:26
*** florian <florian!~fuchs@Maemo/community/contributor/florian> has joined #yocto07:40
*** rburton <rburton!> has joined #yocto07:44
*** boucman_work <boucman_work!> has joined #yocto07:54
boucman_workhey all07:55
*** yann <yann!> has joined #yocto07:56
*** Nilesh_ <Nilesh_!uid116340@gateway/web/> has quit IRC07:57
*** toscalix <toscalix!~toscalix@> has joined #yocto07:59
*** rburton <rburton!> has joined #yocto07:59
*** obsrwr <obsrwr!> has quit IRC08:02
*** Biliogadafr <Biliogadafr!> has joined #yocto08:07
*** obsrwr <obsrwr!> has joined #yocto08:08
*** crankslider <crankslider!~slidercra@unaffiliated/slidercrank> has joined #yocto08:09
*** jku <jku!jku@nat/intel/x-sxdramddefdpcedp> has joined #yocto08:10
boucman_workhow does one regenerate the bitbake documentation from the XML ?08:12
*** sameo <sameo!samuel@nat/intel/x-dgizzzzkumbikykh> has joined #yocto08:21
*** ftonello <ftonello!~felipe@> has quit IRC08:22
*** ftonello <ftonello!~felipe@> has joined #yocto08:23
LetoThe2ndboucman_work: see the bitbake/doc directory in poky, and the readme there. should come with a makefile.08:25
boucman_workLetoThe2nd: thx, found it... as usuall I asked my question to fast :( sorry about that08:26
*** khem <khem!~khem@unaffiliated/khem> has quit IRC08:28
sveinseI guess most of you end up using multiple layers from multiple sources. Out of curiosity, what do you use to manage the sources?08:32
*** khem <khem!~khem@unaffiliated/khem> has joined #yocto08:32
*** t0mmy_ <t0mmy_!~tprrt@> has joined #yocto08:34
boucman_worksveinse: you mean the layers ?08:34
boucman_workI mainly do it manually, we do have a custom tool but i'm not very found of it08:35
boucman_workI would recommand having a look at bitbake-layers and repo...08:35
boucman_workrepo seems the most common tool to save a yocto build layout...08:35
sveinseYes, I am looking at repo. We use it for other collection of git repos08:36
LetoThe2ndsveinse: mirror all upstream external sources on our own machines, couple of shell scripts to regenerate project structures.08:36
sveinseBut you'd need some tool to configure build, such as setting the right dirs in bblayers.conf08:36
LetoThe2ndsveinse: repo can fill in for the latter, but we consider it bloat and missing some features, at least at the time we looked at it.08:37
sveinseLetoThe2nd: It seems a lot do make such custom scripts. I've seen three variants in three companies now08:37
LetoThe2ndsveinse: yeah, our scripts do all that. complete rebuild of local.conf and bblayers.conf, including checkouts of all needed sources with specific states :-)08:37
sveinse(and we'll probably make our own as well)08:38
LetoThe2ndsveinse: probably there's 30, 300, or even 3000 of them,08:38
boucman_workyeah so does our script... that's the easy part. the hard part is dealing with the various use-cases of each dev, regenerating the XML description of the layout and uploading it...08:38
LetoThe2ndsveinse: in case you're interested, ours is public
LetoThe2ndsveinse: a major rewrite is underway, but nothing yet to show.08:39
sveinseLetoThe2nd: thanks. BTW, nice Dune reference :P08:40
LetoThe2ndsveinse: :-)08:40
boucman_workso far, repo is the best tool I have found, though I'd agree with LetoThe2nd about it being not perfectly fitted for yocto.08:42
boucman_workit does have some really cool features though. If I had to write a new tool, i'd definitely base it on repo or on similar concepts08:42
sveinseThis is perhaps an idea for the Yocto SC (if there is one) to set some tool/precendence?08:43
sveinseSC = Steering Committee08:43
*** belen <belen!~Adium@> has joined #yocto08:43
LetoThe2ndthe discussion has been there several times. FWIW, the general opinion is "use what fits your bill most, for many people it seems to be repo"08:44
*** oan <oan!> has joined #yocto08:44
boucman_workI read it as Summer of Code :P08:44
LetoThe2ndi read it as SupaCrowd08:45
boucman_workyeah, I don't like that conclusion. There are dozen of variant of that tool, basically one has been developed by each BSP provider08:45
boucman_workmost are heavily broken shell scripts that break whenever you don't do it exactly the way it's meant to be08:45
boucman_workand there would be really added value to yocto if the project used its "authority" to standardize on one tool... even if the tool is not perfect08:46
boucman_worksometime a bad answer is better than no answer at all08:46
LetoThe2ndi personally think its a better opinion than setting so new preference, which would be absolutely prone to be one more time08:46
sveinseYes, but, the downside is loss of consistency. I'm working in a company that makes end user products, and we use Yocto as a technical base for those products. But often we use subcontractors to supply BSP support. We see a lot of different practices when it comes to coding, and that we then later have to unify those efforts.08:46
*** kukowski <kukowski!c2fb77c5@gateway/web/freenode/ip.> has quit IRC08:46
LetoThe2ndboucman_work: mind, the conclusion is not "invent something new", but "here, lot at this couple of projects, they use repo."08:47
boucman_worksveinse: that why I think the "authority" part is important. The idea is not to provide a better tool but an authoritative tool08:47
sveinseyes, defacto working practices work equally well imho08:48
LetoThe2ndtools should convince by quality, not by authority. i strongly disagree here.08:48
boucman_workrepo could be the answer... it does have a couple of limitations (having the manifest forced to be in a git repo is one of them, forced autoupdate from google servers is another one) but it is the best tool I know of currently08:48
boucman_workLetoThe2nd: you base your assumption on the idea that BSP providers know how to use yocto/can assert what a good tool is08:49
boucman_workI agree on principle, but I deal with that mess everyday, so I have to disagree in practice08:50
sveinseNo, I'm not too fond of authority either. Because authority means that you can foresee all the use cases for it, and that is hardly the case.08:50
LetoThe2ndboucman_work: whereas you base your assumption on that some steering committee, somewhere else can judge what should fit the workflow of a majority of people.08:50
sveinseDoing Yocto ports is a proof of that, as I daily encounter something that evidently is not thought of08:50
LetoThe2ndboucman_work: both have up- and downsides.08:51
LetoThe2ndboth are assumptions.08:51
*** gtristan <gtristan!> has joined #yocto08:51
boucman_workthat's why they are opinions and not decision :P08:51
*** mortderire <mortderire!~rkinsell@> has joined #yocto08:52
boucman_workone feature that I really miss on repo is the ability to specify manifest in other thing than git repo... a local directory with the same layout, a tar.gz, or even being able to build a version of which would self-contain the manifest... that would be awesome08:53
sveinse(hmm. I had expected that krogoth has support for ubuntu 16.04 :o)08:56
rburtonsveinse: what's the problem?08:57
sveinserburton: No problem, just a note about the warning08:57
rburtonah, should work then08:57
rburtonunlike fedora 24 which needs patches (point release coming)08:58
rburtonSANITY_TESTED_DISTROS="" is your friend :)08:58
rburton(or write your own distro config, poky is an example)08:58
*** mortderire <mortderire!~rkinsell@> has joined #yocto08:58
*** jubr <jubr!57ed1b9e@gateway/web/freenode/ip.> has joined #yocto09:00
sveinseAre versions of the various layers tightly bound to each others?09:01
sveinseI mean09:01
rburtonif you're using krogoth oe-core then you want to track krogoth of each other branch09:01
jubrHi guys, I have a bitbake dynamic configuration loading question for y'all, anybody not idling in here? :)09:01
rburtonjubr: ask, don't ask to ask09:01
jubrtrue, it has been years since my last IRC experience, I'm a little rusty :)09:02
jubrtrue, it has been years since my last IRC experience, I'm a little rusty :)09:03
sveinseI just downloaded krogoth to be able to test qemu/intel build, and I see that the originial meta-qt5 is at jethro. The problem being that I see that we have a lot of local patches to it. To poky, meta-qt5 and meta-openembedded09:04
sveinseMy goal objective is to change our application from one BSP to another09:05
*** t0mmy_ <t0mmy_!~tprrt@> has quit IRC09:06
rburtonwhy dont you stick with jethro?09:06
sveinserburton: Well, it was the missing 'sdl' thing against qemu09:06
*** mortderire <mortderire!~rkinsell@> has quit IRC09:07
rburtonjethro 2.0.2 is fixed for that09:07
*** t0mmy_ <t0mmy_!~tprrt@> has joined #yocto09:07
sveinserburton: yeah, but I still need to update a patched poky. Which is equally much work as 2.109:08
rburtonwell not really, if you're on 2.0.0 then the migration to 2.0.2 is mostly trivial. also, this is why i suggest not patching oe-core/poky directly...09:08
jubrI have created an internal release management tool that allows us to maintain opkg feeds with hand-picked software components for our software releases. I've added functionality that writes a release.conf file with the same PN+SRCREV information for each component. The goal is to be able to build an image with these specific software components in them. I'm trying to http fetch + load this .conf file from inside OE.09:09
sveinseI'm attempting intel/qemu, because I'd hoped that this could serve as a generic playground for porting the app before attepting the real HW BSP09:09
rburtonabsolutely sensible09:10
*** benjamirc1 <benjamirc1!~besquive@> has quit IRC09:10
rburtonintel and qemu targets have always worked, just grab meta-intel and use the right branch if you want to boot on real x8609:10
*** mortderire <mortderire!~rkinsell@> has joined #yocto09:10
jubrBut I'm running into problems when dynamically loading the release.conf - since it does not yet exist at OE-start time. I've added caching. But now the conf information only seems to be available in the Recipe Parse phase, it does not seem to reach the worker threads.09:10
*** benjamirc <benjamirc!~besquive@> has joined #yocto09:11
sveinserburton: cool09:12
*** crankslider <crankslider!~slidercra@unaffiliated/slidercrank> has quit IRC09:12
jubrI've `release_conf_fetch_and_cache[eventmask] = "bb.event.ParseStarted"` and then use `bb.parse.handle(release_conf_cache_path, d, True)` to dynamically load it09:13
sveinserburton: We have like 10 patches or so on poky. Most about bugs/features in poky that does not play well on the specific HW09:13
sveinseBut I definitely see the issue here. I'm now stuck when considering other vendors/BSPs09:14
rburtonsveinse: vendors which don't track oe-core releases are a right pain09:15
rburton*but* if you have a final target BSP then use the release they support09:15
rburtonqemu and real intel will build on every release09:15
rburtonhopefully you cloned poky and branched?09:16
*** mortderire <mortderire!~rkinsell@> has quit IRC09:17
*** belen <belen!~Adium@> has quit IRC09:17
sveinseNo, it does not seem that way. And yes, I will direct the ranting in their direction, not here. So for the record, I'm not asking here to fix/undo what has been done. I just need humble advice on how to move forward.09:18
*** mortderire <mortderire!~rkinsell@> has joined #yocto09:18
*** belen <belen!Adium@nat/intel/x-vhdpbgqisafviwik> has joined #yocto09:19
rburtonclone poky, branch it where your BSP starts from, copy your patches in, commit, rebase to the latest stable release to get the sdl/qemu fixes, party.09:19
*** mortderire <mortderire!~rkinsell@> has quit IRC09:20
*** mortderire <mortderire!~rkinsell@> has joined #yocto09:22
*** jku <jku!jku@nat/intel/x-sxdramddefdpcedp> has quit IRC09:22
*** justanotherboy1 <justanotherboy1!~mlopezva@> has joined #yocto09:22
*** justanotherboy <justanotherboy!mlopezva@nat/intel/x-bqtbozurkpegxryo> has quit IRC09:23
sveinseI have a set of layers that has been modified to fit one particular BSP and system. system might be our requirements to the available software. When moving to another HW and BSP I can do one of two things: I can either start with a clean slate and work off official releases. Then I fear that I have to redo and relearn all the quirk and patches that has already been implemented into the...09:24
sveinse...former BSP. The other option is to build on the previous BSP, but that gives on a strong tie-in to what has already been done, and it already being surpassed by newer versions.09:24
sveinseI'd hoped on the latter, as it gives us freedom to move across BSP, but I fear the unknown amount of work that it might imply09:25
jubrrburton/sveinse: interesting BSP/release discussion, we're currently doing something similar with i.MX6 + Freescale's official Yocto release09:30
jubrI've managed to keep most changes in our own BSP meta layers with .bbappend and 2 or 3 .bbclass overrides.09:32
sveinsejubr: this is in fact a imx6 bases BSP too, custom HW thou09:38
boucman_workbased on what board ?09:38
sveinsewith Qt5 for graphics, and that certainly increases the complexity by a few notches09:39
jubrOurs too, i.MX6 SoloX09:39
jubrsveinse: did you bae on the latest Freescale release? Do you have grapics acceleration on your board?09:40
sveinseboucman_work: something called pandaboard I wonder. I have always been working with our custom HW, so I don't really know09:40
boucman_workok, i've never used taht one, I don't know how good their BSP would be09:40
jubrOurs is based on imx6sxsabresd ref design.09:41
* boucman_work uses a custom board based on the apalis by toradex09:41
boucman_workbut we don't use their BSP, we use what they provide in meta-fsl-extra09:41
jubrah, yes, saw a ref to it in there somewhere. Includes a custom kernel I believe09:41
boucman_workyes, but it works when you do your own build based on poky and just changing MACHINE so I'm quite happy09:42
sveinsejubr, hmm, sabre, that sounds awfully familiar.09:42
jubrrburton: know anything about Bitbake internal .conf parsing with bb.parse.handle()?09:43
* boucman_work has some very bad memory of a BSP that would download/rebuild a standard poky for another board, untar the rootfs, override the kernel and a couple of other stuff, then build a SD image based on that09:43
sveinsejubr, I honestly don't know what version, as we put the porting and implementation to a subcontractor.09:43
boucman_workif was horrible09:43
sveinseI'm just getting my hands wet with Yocto....09:43
boucman_workthat's the sort of stuff that makes me think that standardizing on a deployment tool would be a good idea :P09:43
sveinsejubr, but we do have gfx acceleration for Qt09:43
boucman_worksveinse: sabrelite and sabreauto are the reference dev board for designed by freescale09:44
boucman_workor am I messing up with the nitrogen, I tend to mix those two09:44
jubryep, now aqcuired by NXP09:44
*** mortderire <mortderire!~rkinsell@> has quit IRC09:45
sveinsejubr, bases on sabresd09:45
-YoctoAutoBuilder- build #849 of nightly-ppc-lsb is complete: Success [build successful] Build details are at
jubrsveinse, ah that's good, which kernel ver? 3.14.38, 3.14.52? I saw they have a new 4.1.15 release out. We're still working with .52 here.09:46
jubrboucman_work: Freescale's BSP is actually quite good I think. Full support for all the featues on all of their i.MX6* boards from one bsp release. Nicely done.09:48
sveinsejubr: .3809:48
sveinsehave any of you been working with Veriscite boards?09:48
sveinseThat is the BSP I'm porting my app to...09:48
jubrsveinse: we had someone from NXP port our .38 changes to .52 release. It's doable. I wonder how much work migrating to 4.1 will take... *sigh*09:49
jubrsveinse: nope09:49
boucman_workI did, but I don't remember what project it was...09:49
*** mortderire <mortderire!~rkinsell@> has joined #yocto09:49
boucman_workI think the BSP was quite messy, but I don't remember the specifics...09:50
boucman_workAM33 not their imx boards09:50
sveinseAh, ok, we're looking at the imx6 based boards. We're peeking at the 6UL architecture09:51
boucman_workmight be cleaner, then...09:52
jubrWe settled for the 6SX, we needed the ADC's + gfx. Now have 512M RAM + 4G eMMC. /me happy :)09:52
sveinseYeah, we're not sure the 6UL has enough juice for what we need it to do. So it's a concept test09:53
sveinsehaha, with reference to our previous discussion about repo/layer management. Variscite apparently have their own.09:58
sveinseI think I'll name my tool yalcmt. yet another layer configuration management tool09:58
jubrsveinse: nice09:58
jubrI'm starting to appreciate google repo. Now if we would only start to use sha's in our manifest instead of moving-target-master refs :)09:59
*** belen <belen!Adium@nat/intel/x-vhdpbgqisafviwik> has quit IRC10:04
* CTtpollard uses submodules 10:04
CTtpollardmainly because nty google10:04
sveinsefor scm that's nice, but I suppose you have script for build conf as well?10:09
*** t0mmy_ <t0mmy_!~tprrt@> has quit IRC10:12
*** t0mmy_ <t0mmy_!~tprrt@> has joined #yocto10:13
*** belen <belen!~Adium@> has joined #yocto10:18
*** clopez <clopez!> has quit IRC10:29
*** clopez <clopez!> has joined #yocto10:34
jubr@all: anybody here know anything about Bitbake internal .conf parsing with bb.parse.handle()?10:43
sveinseDoes any of you use external sources? Our software is a humongous hg repository, and (on 2.0.1 at least) hg support seems iffy. But when I attempted to use EXTERNALSRC on 2.1 yocto stops at: Failure expanding variable do_compile[file-checksums], expression was ${@srctree_hash_files(d)} which triggered exception IOError: [Errno 2] No such file or directory: '/home/nosse1/yocto/sp/repos/sp/.git/inde10:43
sveinseSo it apparently wants it to be a git repo10:44
*** JaMa <JaMa!> has joined #yocto10:46
*** mortderire <mortderire!~rkinsell@> has quit IRC11:00
boucman_workbitbake patch submitted, hopefully will get in11:02
* boucman_work <= noob enthusiasm11:02
* jubr is appreciative :)11:03
*** mortderire <mortderire!rkinsell@nat/intel/x-ijsglcuqpefbrqse> has joined #yocto11:03
*** mortderire <mortderire!rkinsell@nat/intel/x-ijsglcuqpefbrqse> has quit IRC11:07
*** mortderire <mortderire!rkinsell@nat/intel/x-lqkcneibsmgsomxe> has joined #yocto11:11
sveinseSorry to repeat, but how do I get past this: Failure expanding variable do_compile[file-checksums], expression was ${@srctree_hash_files(d)} which triggered exception IOError: [Errno 2] No such file or directory: '/home/nosse1/yocto/sp/repos/sp/.git/index'11:13
* sveinse giving up11:23
jubrsveinse: does not ring a bell, sorry11:24
jubrPS did you see
sveinseAh, I think I know what it is. We use hg, and some submodules that happens to be git repos. hg has some configs in .git, which later makes BB think its a .git repo.11:26
sveinseIsn't it lovely?11:26
boucman_worksveinse: that is a complicated question, chances are very few people can answer :(11:26
* jubr my pleasure :)11:26
Ulfalizersveinse: yeah, i think the problem is that your repo has a .git/ in it, but srctree_hash_files() can't find the files it expects in it11:27
boucman_worksveinse: tbh, a .git/ directory is the standard way of detecting a git repo :P11:27
jubrSame as my intro + question above. No-one knows.11:27
* jubr *sniffs11:27
Ulfalizersveinse: you'll find the source for srctree_hash_files() at the bottom of meta/classes/externalsrc.bbclass btw11:27
sveinseyup, but I think I have the answer11:27
sveinseUlfalizer: thanks, I'll look at it11:27
sveinseI think this is rather ironic. Didn't we start out the discussions today that we should try to avoid patching poky? Well, it seems, that there are lots of cases where its unavoidable :P11:29
sveinseNo pun intended, thou11:30
jubrI know. I even have a custom base.bbclass with patch to make the files do_fetch writes in ${DL_DIR} group writeable11:34
jubrI've set up a shared OE build env for our developers with shared DLs+ sstate. Hugely speeds up dev time + space reduction.11:35
*** berton <berton!~fabio@> has joined #yocto11:36
sveinsejubr, btw, if you have a CI server, or a build server, how far back do you take each build to ensure consistency? E.g. Do you wipe tmp/11:37
sveinseWe need to set up some similar scheme for sstate cache from a central build server. IT is already on my back for completely blowing up the requirements for the developer machines when working with Yocto.11:40
jubrjenkins, wip, currently not done yet. At least all releases are built with it though. I should make a second job that does a clean rebuild every now + then.11:41
* jubr is wondering if there is such a thing as SSTATE_EXLUDE = "recipe1 recipe2"?11:41
jubrsstate mirror stuff exists though11:42
*** mortderire <mortderire!rkinsell@nat/intel/x-jrztclznfjwlfkrn> has joined #yocto11:43
*** Cwiiis <Cwiiis!sid227@gateway/web/mozilla/x-egnpsoosebuveuax> has joined #yocto11:50
CwiiisTrying to build a recipe for a kernel module, I keep falling over because version.h isn't in the kernel src directory and it ends up using the host system's (which in this case, doesn't match at all) - I can see the generated version.h in the work directory, but it's not in the work-shared directory... Anyone know what's up with that?11:51
rburtonzeddii zeddii_home ^11:54
Cwiiiswell, when I say I see it in the work directory, I see it in the sysroot directory for an image that ends up with it and I see it in the work directory of linux-libc-headers11:54
boucman_workrburton: architecture question : I want to add a way to expand bb variables in target files (typically they come from "SRC_URI=file://" and end somewhere on the target's "/etc"11:56
boucman_workso somewhere on the do_fetch => do_unpack => do_patch chain11:56
boucman_workshould I try to do that in bitbake, somewher in fetcher2 or should I keep it yocto specific in the way do_patch is in patch.bbclass ?11:57
rburtoni'd write a class that adds a task between patch and compile11:58
rburtonif you had lots of recipes that did the same thing11:58
jubrrburton: does a way exists to manipulate recipe's from inside a handler?11:59
boucman_workok, thx11:59
jubrI just found out's execute_handler() does `del` :'(11:59
jubrin a way that it actually propagates to the tasks12:02
*** jkroon_ <jkroon_!> has joined #yocto12:02
*** Ulfalizer <Ulfalizer!~ulf@> has quit IRC12:06
jkroon_Hi. It seems like when I do incremental generation of my image's SDK with -c populate_sdk, each time the SDK gets a little bigger. I'm building the SDK with the kernel-devsrc package, and in the target's sysroot I have a pretty big /usr/src/kernel/.kernel-meta/ directory. I'm wondering if that could/should be discarded ?12:08
jkroon_(This is with pretty recent poky-master)12:09
-YoctoAutoBuilder- build #607 of nightly-oe-selftest is complete: Success [build successful] Build details are at
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC12:22
rburtonjkroon_: that doesn't seem right12:22
*** marka <marka!~marka@> has joined #yocto12:40
*** jchonig <jchonig!> has quit IRC12:41
*** jchonig <jchonig!> has joined #yocto12:42
*** anselmolsm <anselmolsm!~anselmols@> has joined #yocto12:42
-YoctoAutoBuilder- build #258 of nightly-checkuri is complete: Failure [failed BuildImages] Build details are at
*** Amynka <Amynka!~frozen@gentoo/developer/amynka> has quit IRC12:57
*** Amynka <Amynka!~frozen@gentoo/developer/amynka> has joined #yocto12:58
CTtpollardwhat's the cleanest way to set up a local source mirror for multiple builds to share? I know for a single pipeline the easiest method is to populate it with the output of an initial download_dir, but doing this for 'x' targets will create a lot of crossover13:02
neverpanicrun all x targets with $DL_DIR pointing to the same folder?13:03
jkroon_zeddii, ping13:05
*** paulg <paulg!~paulg@> has joined #yocto13:08
*** cference <cference!~cference@> has joined #yocto13:13
rburtonCTtpollard: bitbake world -c fetchall13:16
CTtpollardneverpanic: ok, so share dl_dir & source_mirror in each local.conf?13:17
rburtonbut yeah, if they're all local, then they can share DL_DIR13:17
rburton(and SSTATE_DIR)13:17
*** Amynka <Amynka!~frozen@gentoo/developer/amynka> has quit IRC13:17
CTtpollardok, well I'm currently inheriting the local mirror, I'll also share dl_dir as the same location13:17
*** Amynka <Amynka!~frozen@gentoo/developer/amynka> has joined #yocto13:18
jkroon_rburton, I may have spoke to soon. I did a -c clean -c cleansstate virtual/kernel and kernel-devsrc, rebuilt the SDK and it still comes out as big as before. hmm.13:21
boucman_workrburton: are you admin on the bitbake ML ? or should I wait for RP to be around ?13:22
sveinsedisk is certainly a premium when working with yocto. How can I clean a build when an image is done, yet allow me to work on it? If I have understood things correctly, sstate will cache most packages, right?13:22
rburtonboucman_work: no, yes.13:23
RPboucman_work: I did look at your patch you pasted here yesterday and looked good13:23
neverpanicrburton: CTtpollard: I'd advise against bitbake -c fetchall, because that just fetches but doesn't check whether what you have fetched actually builds, so you might populate your download cache with broken files.13:23
rburtonsveinse: if you find yourself running out of disk, you can inherit rm_work so it will delete the work directory when its finished building a recipe.13:23
RPboucman_work: I'd just want to check with kergoth about whether that is the right naming for the syntax13:23
rburtonsveinse: (or get a bigger disk)13:23
CTtpollardneverpanic: yeh that's a good point to consider actually13:24
neverpanicsveinse: you can always safely rm -rf tmp/ without loosing too much time, since you still have sstate13:24
neverpanicCTtpollard: We've seen it a couple of times where downloads failed and files in our download cache wouldn't even extract properly anymore13:24
neverpanicIn theory, that should neverâ„¢ happen.13:25
*** igor2 <igor2!~igor@> has joined #yocto13:25
sveinserburton: (I wish I could get bigger disk. But company policy and all that. Have to use branded disks under the manufacturers reccomendation is a must, and I'm maxed out already. -- and I'm not ever going to go over to spin drives again.)13:26
rburtonsveinse: i still endorse spinning rust for build disks as they're so much larger and given enough ram the performance improvement is actually negliab;e13:26
sveinseI wonder if I could get away with an external USB3 drive...13:28
sveinsehmm, the drives they put into these are probably too slow thou. 5400s as such13:28
*** Ulfalizer <Ulfalizer!~ulf@> has joined #yocto13:28
boucman_workRP: I just subscribed to the bitbake ml and posted my patch13:30
boucman_workproblem is, my patch is curently in the moderator queue because my company was bought so our email adresses changed, and I goofed up my git-send-email config13:30
boucman_workjust wanted to point it out so there is no mess-up13:30
boucman_work(if you our kergoth don't like the syntax, no problem)13:31
sveinseHeh, my attempt to build our Qt code on qmeu worked. What didn't work is execution. It crashes. So, someone is going to say "I told you so", but all I need to generate USB images for intel and to native boot is to pull in meta-intel ?13:31
jubrneverpanic: We have a patched base.bbclass to make the files do_fetch writes in ${DL_DIR} group writeable, so it can be used by multiple developers13:31
*** Ulfalizer <Ulfalizer!~ulf@> has quit IRC13:32
rburtonsveinse: throw enough ram at the problem and you'd be surprised how little the disk is used13:33
boucman_workjubr: I use local mirror rather than shared download... not sure how well shared downloads work...13:34
rburtonsveinse: add meta-intel, use intel-corei7-64 or -core2-32 machine as appropriate, copy the resulting .hddimg file to a usb stick13:35
sveinserburton: Thanks13:35
jubrboucman_work: pretty well, actually, with the umask patch. Note that changing base.bbclass will trigger a full rebuild, including cross-compiler + libc.13:36
sveinserburton: So all of these intel boards/machines have equal semblence to standard PC HW, right?13:39
rburtondepends what you mean13:39
rburtonthe intel-core* BSPs target "standard" machines13:39
rburtonminnow counts as standad13:39
rburtonedison and galileo are a bit more special13:39
sveinserburton: it't nice to be intel in this respect :P Our systems /are/ standard by definition :P13:40
sveinseI'll probably used some old washed out laptop for testing, so I corei7-64 is probably too new. core2-32 it is13:42
*** sgw_ <sgw_!~sgw_@> has quit IRC13:46
*** belen <belen!~Adium@> has quit IRC13:50
*** belen <belen!~Adium@> has joined #yocto13:50
*** fledermaus <fledermaus!~vivek@2a00:1098:5:0:ccb0:826a:ef2d:64d1> has joined #yocto13:52
*** townxelliot <townxelliot!~ell@> has quit IRC13:56
*** madisox <madisox!~madison@> has joined #yocto13:58
*** lamego <lamego!~jose@> has joined #yocto13:59
*** townxelliot <townxelliot!~ell@> has joined #yocto13:59
*** JominlorTTT <JominlorTTT!6cab81a3@gateway/web/freenode/ip.> has joined #yocto13:59
sveinseWhat do you guys do for configuring and package splitting? Please let me elaborate:14:01
*** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has quit IRC14:02
*** sgw_ <sgw_!~sgw_@> has joined #yocto14:03
sveinseWe have a large codebase  which must be configured. This configuration decides what gets installed. When supporting multiple MACHINEs (same tune), I am torn between doing this selection in configure-time, so that I don't have to do FILES-splitting. But, that requires one build for each MACHINE. Or configuring it generic (to tune), but then I need to maintain package splitting during installation.14:05
jubrsveinse: can't you split it into multiple recipes? Like qt-*?14:08
sveinsejubr, I can. But then implies multiple compilations of the same code, doesn't it?14:08
sveinse(without having looked at what qt-* does)14:08
*** belen <belen!~Adium@> has quit IRC14:10
jubrDepending if everything needs to be compiled. We kept our codebase component-based, in separate executables actually, communicating locally. This actually makes for a robust, somewhat crash-resistant architecture. Building + Packaging can then be done separately as well.14:10
rburtonsveinse: i lean towards build-everything-one for the tune, split up in packaging, then each image or machine can pull in the packages that it needs14:11
*** belen <belen!~Adium@> has joined #yocto14:11
* jubr agrees14:11
*** bottazzini <bottazzini!~realBigfo@> has joined #yocto14:12
sveinse...which actually makes the most sense, I think, so I concur as well.14:12
*** benjamirc1 <benjamirc1!~besquive@> has joined #yocto14:13
jubrDo you use the opkg feeds to update in the field, or are all sw updates monolithic?14:13
sveinsesw updates are monolithic. We tried in field package updates in our old OMAP based system, which turned out to be too slow. Nobody would wait 40 mins for a SW update. Monolithic took 5 mins14:15
sveinseubuntu deb bases thou. We're migrating to Yocto now14:15
jubrWe've been doing incremental going on 8 years now. Just adding monolithic actually, to add some flexibility wrt system/rootfs updates.14:20
jubrThe Qt pkg updates could be a bit slow though, true enough.14:21
sveinseYeah. Our storage system (sdcard) is painfully slow, so it didn't work out14:21
jubrWe have UBIFS on our old i.MX27 devices. Nightmare.14:22
sveinseIf I in my recipe want a feature flag, such as with-graphic, what is the common method of doing this in yocto? Can anyone point out an example, please?14:24
sveinseI'm thinking if this setting belongs in local.conf or not14:24
sveinse(and I have to learn this override stuff, since it translates to real changes in DEPENDS and RDEPENDS)14:25
rburtonsveinse: is that something that will vary by machine and won't be changed otherwise?14:25
sveinserburton: By role, actually. Which also implies machine. That is the "controller" role must have a display, so it only works on a specific machine with display.14:28
sveinseI'm starting to think if I want something like "core-image-controller"14:29
sveinseBut that doesn't work too well with the TUNE thinking, as you'd have to configure Qt with graphics in both cases14:30
rburtonis qt not split into graphical and non-graphical bits anyway14:30
rburtonso even if you build all of qt5 but only link to the core, you don't pull in the graphical bits14:31
*** ziggo <ziggo!~ziggo@> has quit IRC14:31
sveinserburton: Yeah, but to build qt5 you need to build it with graphics, don't you? Even if you dont pull in the non gfx libs14:31
sveinseSo you end up having to supply some opengl lib for qt, which you eventually might not need14:32
sveinseergo, on a MACHINE that does not need gfx, you don't need to configure it with gfx at all14:32
rburtonbut if you never install it and you'll be sharing from sstate anyway and you'll be building qt with graphics later, what's the problem?14:32
rburtonsure if you have a machine that never has graphics then say so in the machine config, and qt will never build with graphics14:33
rburtonwell, tune.14:33
*** belen <belen!~Adium@> has quit IRC14:34
*** belen <belen!~Adium@> has joined #yocto14:34
sveinseqt5 is built to tune it seems14:34
sveinsewhich I tend to prefer, since its more generic14:35
rburtonif you have various different configurations which have the same base hardware but different software, just build several different images14:36
*** adelcast <adelcast!~adelcast@> has quit IRC14:36
rburtonand hopefully the pieces you use can build modular enough14:36
jubrI think you can choose to build parts of Qt (qt-base) without the graphical stuff (qt-declarative)14:38
sveinseSo I have two machines, two HWs, "A" and "B". Same tune. The former with display, the latter without. The main application is built off the same codebase. Now my job is to test out a new MACHINE/BSP for "B", but I don't want to bother getting gfx up and running on it, so I need somehow to allow my recipe to not take use of any gfx14:38
rburtonare we talking opengl or  x11 or something else14:38
sveinseqt5 with opengl14:39
sveinseimx6 based14:39
sveinseI just remembered seeing that qt5 has some feature selector system when configuring. I'll take a look at it14:41
presentpackageconfig variable14:42
*** Guest70483 <Guest70483!> has joined #yocto14:44
Guest70483hi everyone14:44
rburtonsveinse: you have to chose if you want to share qt5 between tunes or not.14:44
sveinserburton: Yes I do.14:44
rburtonsveinse: if you don't then make it machine-specific and remove opengl/x11/etc from the machine with no GL.  if you do then you have to do a build with graphics.14:44
sveinseI can tag on to something like this from meta-qt5: PACKAGECONFIG_GL ?= "${@base_contains('DISTRO_FEATURES', 'opengl', 'gl', '', d)}"14:45
rburtonyes but thats tune-wide14:45
sveinseah, right14:45
rburtonyou could use a different distro for controller and worker, but then you'll likely be causing more builds14:46
Guest70483got a problem building an image for the raspberry pi 3. i always get this error: "/poky-krogoth-15.0.0/meta-openembedded/meta-python/recipes-devtools/python/, do_configure) failed with exit code '1'" and "configure: error: could not find Python headers". any hints?14:46
boucman_worksveinse: I tend to think that if the machines have any difference, then they are not the same MACHINE (they will still share everything that is not MACHINE specific)14:47
*** Anticom <Anticom!~timo.m@> has joined #yocto14:47
jubrsveinse: Maybe something like DISTRO_FEATURES_remove_machineB = "opengl" ?14:47
boucman_workjubr: DISTRO_FEATURES are not supposed to change from machine to machine... that would cause everything to rebuild every time you switch machine14:48
jubrHmm.. good point14:48
jubrsveinse: does the qt + gfx build ok for machine B?14:50
sveinseI'm thinking loud here: "A" and "B" as we have it today is two different MACHINEs, but evidently the same tune, as most code is built to tune. including Qt. So moving to variscite imx for "B", would imply new MACHINE, but quite possibly a new tune as well. So there is no benefits for code reuse there.14:50
sveinsejubr: It does for old "B" as its the same tune as "A". And qt + gfx apparently belongs to tune. But I don't know for new "B"14:51
boucman_workwould it be a different tune ? tune is usually linked to cpu type, and both are imx6 iiuc14:51
sveinseI don't now yet. It's a completely different yocto setup and BSP, so I have no idea14:52
*** jku <jku!> has joined #yocto14:59
sveinseI just need to comment out the lines with sdl in local.conf on older yocto releases to get compilation going on ubuntu 16.04?15:03
*** adelcast <adelcast!~adelcast@> has joined #yocto15:04
sveinseJust downloaded variscite's current yocto release...15:04
*** Guest70483 <Guest70483!> has quit IRC15:04
rburtonsveinse: on any release, assuming it supports libsdl-native.15:04
*** BlitzBlizz <BlitzBlizz!> has joined #yocto15:06
sveinsewell it failed. complains "Install SDL devel", yet it is. Similar to what we talked about previously. Just this time around, I don't care about sdl if I can avoid it. (Don't know the implication of it thou)15:06
BlitzBlizzhi guys15:06
istariluckyWhat is the correct approach to do a bootable image with a rootfs greater than 4GB?15:07
*** Anticom <Anticom!~timo.m@> has quit IRC15:08
BlitzBlizzi've got a problem building an image. i always got the error that the python headers couldnt be found.15:08
boucman_worksveinse: what version of yocto is variscite based on ?15:08
sveinseboucman_work: how can I find out?15:09
*** evanmeagher <evanmeagher!~MongooseW@> has joined #yocto15:10
BlitzBlizzany clues?15:11
*** sameo <sameo!samuel@nat/intel/x-dgizzzzkumbikykh> has quit IRC15:14
boucman_worksveinse: when bitbake run, it usually show what branches were actually cloned, usually they are using the yocto version name15:14
*** billr <billr!~wcrandle@> has joined #yocto15:16
sveinseboucman_work: It does not. It somewhere around 2.0 or 2.0.1 I think. Strange thing is I find the 2.0 tag in both (variscite tree and vanilla poky), but after this they vary a lot. I find /some/ patches from vanilla poky in the variscite tree. (Hmm, need to familiarize myself better with git it seems)15:18
*** Amynka <Amynka!~frozen@gentoo/developer/amynka> has quit IRC15:19
*** fl0v0 <fl0v0!> has joined #yocto15:23
*** psadro <psadro!~Thunderbi@2620:0:ed0:800a:72f3:95ff:fe1d:9866> has quit IRC15:25
*** jku <jku!> has quit IRC15:26
rburtonsveinse: can you not try rebasing the vendor branch on top of 2.0.2?15:26
*** mortderire <mortderire!rkinsell@nat/intel/x-jrztclznfjwlfkrn> has quit IRC15:28
*** sno <sno!~sno@> has quit IRC15:30
*** florian <florian!~fuchs@Maemo/community/contributor/florian> has quit IRC15:32
*** qt-x <qt-x!~Thunderbi@> has quit IRC15:34
*** ntl <ntl!> has joined #yocto15:39
*** boucman_work <boucman_work!> has quit IRC15:40
*** RagBal <RagBal!> has quit IRC15:42
*** Rootert <Rootert!> has quit IRC15:42
*** jkroon_ <jkroon_!> has quit IRC15:45
*** paulg <paulg!~paulg@> has quit IRC15:49
*** psadro <psadro!~Thunderbi@2620:0:ed0:800a:72f3:95ff:fe1d:9866> has joined #yocto15:50
*** csanchezdll <csanchezdll!> has left #yocto15:50
*** tjamison <tjamison!~tjamison@> has joined #yocto15:51
*** nillerbrun <nillerbrun!> has quit IRC16:10
*** Amynka <Amynka!~frozen@gentoo/developer/amynka> has joined #yocto16:14
*** rajm <rajm!> has quit IRC16:18
*** hamis_lt_u <hamis_lt_u!~irfan@> has quit IRC16:26
*** mortderire <mortderire!rkinsell@nat/intel/x-rzyouutfgtjzsrpw> has joined #yocto16:28
*** tlwoerner <tlwoerner!~trevor@unaffiliated/tlwoerner> has quit IRC16:29
*** billr <billr!~wcrandle@> has quit IRC16:30
*** tlwoerner <tlwoerner!~trevor@unaffiliated/tlwoerner> has joined #yocto16:31
*** fl0v0 <fl0v0!> has quit IRC16:34
*** sno <sno!~sno@> has joined #yocto16:40
*** tlwoerner <tlwoerner!~trevor@unaffiliated/tlwoerner> has quit IRC16:47
*** billr <billr!~wcrandle@> has joined #yocto16:48
*** t0mmy_ <t0mmy_!~tprrt@> has quit IRC16:51
*** yann <yann!> has quit IRC16:54
*** present <present!~present@> has quit IRC17:00
*** justanotherboy <justanotherboy!mlopezva@nat/intel/x-imaybtjfnkrtxvnl> has joined #yocto17:00
*** tlwoerner <tlwoerner!~trevor@unaffiliated/tlwoerner> has joined #yocto17:00
*** justanotherboy1 <justanotherboy1!~mlopezva@> has quit IRC17:01
*** Nilesh_ <Nilesh_!uid116340@gateway/web/> has joined #yocto17:01
*** belen <belen!~Adium@> has quit IRC17:01
*** mortderire <mortderire!rkinsell@nat/intel/x-rzyouutfgtjzsrpw> has quit IRC17:05
*** tlwoerner <tlwoerner!~trevor@unaffiliated/tlwoerner> has quit IRC17:05
*** MWelchUK <MWelchUK!> has quit IRC17:06
*** tlwoerner <tlwoerner!~trevor@unaffiliated/tlwoerner> has joined #yocto17:18
*** MWelchUK <MWelchUK!> has joined #yocto17:19
*** [Sno] <[Sno]!~sno@> has joined #yocto17:24
*** sno <sno!~sno@> has quit IRC17:25
*** rob_w <rob_w!~rob@unaffiliated/rob-w/x-1112029> has joined #yocto17:31
*** toscalix <toscalix!~toscalix@> has quit IRC17:32
*** [Sno] <[Sno]!~sno@> has quit IRC17:32
*** justanotherboy <justanotherboy!mlopezva@nat/intel/x-imaybtjfnkrtxvnl> has quit IRC17:34
*** Gintaro <Gintaro!> has quit IRC17:36
*** paulg <paulg!~paulg@> has joined #yocto17:41
*** Gintaro <Gintaro!> has joined #yocto17:44
*** gtristan <gtristan!> has quit IRC17:44
*** justanotherboy <justanotherboy!mlopezva@nat/intel/x-fpsioacadeqkdlwx> has joined #yocto17:47
*** Gintaro <Gintaro!> has quit IRC17:47
*** Gintaro <Gintaro!> has joined #yocto17:48
*** Gintaro <Gintaro!> has quit IRC17:52
*** Gintaro <Gintaro!> has joined #yocto17:53
*** Gintaro <Gintaro!> has quit IRC17:56
*** yann <yann!> has joined #yocto18:03
*** Gintaro <Gintaro!> has joined #yocto18:03
*** khem` <khem`!~khem@unaffiliated/khem> has joined #yocto18:06
*** Gintaro <Gintaro!> has quit IRC18:07
*** khem` <khem`!~khem@unaffiliated/khem> has quit IRC18:08
*** khem` <khem`!~khem@unaffiliated/khem> has joined #yocto18:09
*** jwessel <jwessel!~jwessel@> has quit IRC18:10
*** evanmeagher <evanmeagher!~MongooseW@> has quit IRC18:11
*** Gintaro <Gintaro!> has joined #yocto18:13
*** Gintaro <Gintaro!> has quit IRC18:17
*** sno <sno!> has joined #yocto18:24
*** blueness <blueness!~blueness@gentoo/developer/blueness> has quit IRC18:32
*** Gintaro <Gintaro!> has joined #yocto18:37
*** blueness <blueness!~blueness@gentoo/developer/blueness> has joined #yocto18:40
*** Gintaro <Gintaro!> has quit IRC18:40
*** evanmeagher <evanmeagher!~MongooseW@> has joined #yocto18:45
*** Gintaro <Gintaro!> has joined #yocto18:48
*** Ulfalizer <Ulfalizer!> has joined #yocto18:51
*** Gintaro <Gintaro!> has quit IRC18:51
*** evanmeagher <evanmeagher!~MongooseW@> has quit IRC18:57
*** Gintaro <Gintaro!> has joined #yocto19:02
*** townxelliot <townxelliot!~ell@> has quit IRC19:03
*** Gintaro <Gintaro!> has quit IRC19:05
*** Gintaro <Gintaro!> has joined #yocto19:07
*** rob_w <rob_w!~rob@unaffiliated/rob-w/x-1112029> has quit IRC19:09
*** Gintaro <Gintaro!> has quit IRC19:10
*** challinan <challinan!~chris@2601:702:c100:8be0:ec69:cc33:dd0e:7741> has quit IRC19:10
*** Gintaro <Gintaro!> has joined #yocto19:11
*** crankslider <crankslider!~slidercra@unaffiliated/slidercrank> has joined #yocto19:12
*** khem` <khem`!~khem@unaffiliated/khem> has quit IRC19:13
*** Gintaro <Gintaro!> has quit IRC19:14
*** Gintaro <Gintaro!> has joined #yocto19:16
*** blueness <blueness!~blueness@gentoo/developer/blueness> has quit IRC19:18
*** Gintaro <Gintaro!> has quit IRC19:19
*** bottazzini <bottazzini!~realBigfo@> has quit IRC19:20
*** pohly <pohly!> has quit IRC19:20
*** bottazzini <bottazzini!~realBigfo@> has joined #yocto19:20
*** Gintaro <Gintaro!> has joined #yocto19:25
*** blueness <blueness!~blueness@gentoo/developer/blueness> has joined #yocto19:26
*** pohly <pohly!> has joined #yocto19:27
*** blueness <blueness!~blueness@gentoo/developer/blueness> has quit IRC19:28
*** sno <sno!> has quit IRC19:28
*** Gintaro <Gintaro!> has quit IRC19:28
*** blueness <blueness!~blueness@gentoo/developer/blueness> has joined #yocto19:32
*** billr <billr!~wcrandle@> has quit IRC19:35
*** aehs29 <aehs29!~aehernan@> has joined #yocto19:37
*** pohly <pohly!> has quit IRC19:38
*** sno <sno!> has joined #yocto19:39
*** evanmeagher <evanmeagher!~MongooseW@> has joined #yocto19:52
*** Gintaro <Gintaro!> has joined #yocto19:53
*** evanmeagher <evanmeagher!~MongooseW@> has quit IRC19:54
*** Gintaro <Gintaro!> has quit IRC19:56
*** Nilesh_ <Nilesh_!uid116340@gateway/web/> has quit IRC19:57
*** Gintaro <Gintaro!> has joined #yocto19:58
*** Gintaro <Gintaro!> has quit IRC20:01
*** Gintaro <Gintaro!> has joined #yocto20:03
*** Gintaro <Gintaro!> has quit IRC20:07
*** Gintaro <Gintaro!> has joined #yocto20:08
*** eraineri <eraineri!> has joined #yocto20:10
*** Gintaro <Gintaro!> has quit IRC20:11
*** paulg <paulg!~paulg@> has quit IRC20:13
*** evanmeagher <evanmeagher!~MongooseW@> has joined #yocto20:17
*** fledermaus <fledermaus!~vivek@2a00:1098:5:0:ccb0:826a:ef2d:64d1> has quit IRC20:19
*** Gintaro <Gintaro!> has joined #yocto20:19
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto20:21
*** marka <marka!~marka@> has quit IRC20:22
*** Gintaro <Gintaro!> has quit IRC20:22
*** jwessel <jwessel!~jwessel@> has joined #yocto20:26
*** sno <sno!> has quit IRC20:29
*** Crofton <Crofton!> has joined #yocto20:29
*** obsrwr <obsrwr!> has quit IRC20:35
*** anselmolsm <anselmolsm!~anselmols@> has quit IRC20:42
*** anselmolsm <anselmolsm!~anselmols@> has joined #yocto20:43
*** Gintaro <Gintaro!> has joined #yocto20:47
*** JaMa <JaMa!> has quit IRC20:47
*** Gintaro <Gintaro!> has quit IRC20:50
*** dmoseley <dmoseley!> has quit IRC20:51
*** Crofton <Crofton!> has quit IRC20:54
*** khem <khem!~khem@unaffiliated/khem> has quit IRC20:55
*** ntl <ntl!> has quit IRC20:55
*** khem <khem!~khem@unaffiliated/khem> has joined #yocto20:56
*** sameo <sameo!~samuel@> has joined #yocto21:00
Ulfalizerhow can basing WORKDIR on MULTIMACH_TARGET_SYS be safe? MULTIMACH_TARGET_SYS only seems to include the "type" of the machine (PACKAGE_ARCH, TARGET_VENDOR, TARGET_OS). what if some recipe overrides variables based on the specific MACHINE? wouldn't that cause collisions, since MACHINE isn't included in MULTIMACH_TARGET_SYS?21:03
bluelightningUlfalizer: that makes the recipe machine-specific, which changes MACHINE_ARCH and therefore PACKAGE_ARCH21:04
bluelightningwell, it may change them automatically under certain circumstances, but you should really explicitly set PACKAGE_ARCH = "${MACHINE_ARCH}" in the recipe if you know you're making it machine-specific21:05
*** khem <khem!~khem@unaffiliated/khem> has quit IRC21:05
*** Gintaro <Gintaro!> has joined #yocto21:06
Ulfalizerwhat if you have two different machines with the same MACHINE_ARCH? is that supposed to never happen?21:07
*** cference <cference!~cference@> has quit IRC21:07
Ulfalizerbluelightning: what i'm *really* wondering though is whether the descriptions in the last comment of are accurate :)21:08
yoctiBug 9988: enhancement, Medium, 2.2 M3, srifenbark, IN PROGRESS REVIEW , Suggested clarification of the STAGING_DIR_* glossary entries21:08
*** khem <khem!~khem@unaffiliated/khem> has joined #yocto21:09
*** Gintaro <Gintaro!> has quit IRC21:10
*** Gintaro <Gintaro!> has joined #yocto21:11
*** evanmeagher <evanmeagher!~MongooseW@> has quit IRC21:11
*** Crofton <Crofton!> has joined #yocto21:11
bluelightningUlfalizer: looks fine to me21:11
*** sno <sno!> has joined #yocto21:11
Ulfalizergreat, thanks!21:12
bluelightningIMO the PACKAGE_ARCH / MACHINE_ARCH discussion doesn't really belong at this level, because that happens via PACKAGE_ARCH21:12
Ulfalizerwasn't going to add anything to the glossary entries re. that. i was just curious.21:13
*** Gintaro <Gintaro!> has quit IRC21:14
Ulfalizerbluelightning: would it still be good if i changed "uniquely identifies the type of the target system" to "uniquely identifies the target system"? that's a bit more concrete. i only wrote "type of" because i wasn't sure if the same MULTIMACH_TARGET_SYS value could cover multiple machines.21:14
bluelightningwell, it does often cover multiple machines - in fact the default is for it to be architecture-specific not machine-specific21:15
bluelightningFWIW, I think that change will be too subtle for most readers to make a distinction in any case21:16
Ulfalizerin that case i'm probably still missing something. if two packages use the same architecture but specialize on the machine, then it seems it'd collide.21:16
*** berton <berton!~fabio@> has quit IRC21:17
Ulfalizerbut maybe you can't "specialize on the machine"...21:17
Ulfalizerin a way that makes sense here at least21:17
Ulfalizerah well, i'm happy as long as the current description makes sense21:17
-YoctoAutoBuilder- build #608 of nightly-oe-selftest is complete: Failure [failed Running oe-selftest] Build details are at
-YoctoAutoBuilder- build #587 of nightly-world-lsb is complete: Failure [failed BuildImages] Build details are at
*** evanmeagher <evanmeagher!~MongooseW@> has joined #yocto21:19
*** evanmeagher <evanmeagher!~MongooseW@> has joined #yocto21:19
bluelightningUlfalizer: using the same PACKAGE_ARCH and then customising per machine will break things in a multi-machine build and shouldn't be done (assuming it does not trigger PACKAGE_ARCH to change to ${MACHINE_ARCH} automatically, which it will under some circumstances)21:20
Ulfalizerbluelightning: alright... then i think i'm following how it works at least. thanks!21:22
BlitzBlizzhi guys21:22
BlitzBlizzi've got a problem with building an image for the rpi 3. every build stops with the error buildDir/poky-krogoth-15.0.0/meta-openembedded/meta-python/recipes-devtools/python/, do_configure) failed with exit code '1'21:24
BlitzBlizzcan anyone help me?21:24
UlfalizerBlitzBlizz: do you get any other error messages?21:26
*** Gintaro <Gintaro!> has joined #yocto21:26
moto-timowhich host?21:26
BlitzBlizzconfigure: error: could not find Python headers21:26
BlitzBlizzdebian 8 virtual machine21:26
moto-timoI saw the same error while build testing for 2.1.1 fix for Fedora-2421:27
moto-timobut I did not investigate any further21:27
BlitzBlizzi sucessfully built a image before and after that i added meta-networking and meta-python to the bblayers.conf because i wanted a proftpd and since then this error pops up21:28
moto-timodid you checkout the "krogoth" branch of meta-openembedded?21:29
*** Gintaro <Gintaro!> has quit IRC21:29
moto-timocan you pastebin the log?21:30
BlitzBlizzthis branch
*** tlwoerner <tlwoerner!~trevor@unaffiliated/tlwoerner> has quit IRC21:30
*** sgw_ <sgw_!~sgw_@> has quit IRC21:30
moto-timothat's the repo, but you need
moto-timobut I need to see the output of the config log to help any further21:32
BlitzBlizzhere is the pastebin21:33
BlitzBlizzi just wanted to built in a ftp server.21:35
*** Gintaro <Gintaro!> has joined #yocto21:35
*** khem` <khem`!~khem@unaffiliated/khem> has joined #yocto21:36
UlfalizerBlitzBlizz: try adding 'export BUILD_SYS' and 'export HOST_SYS' to the recipe. dunno if it's the proper solution, but it might fix it.21:37
moto-timoThat's the exact same failure I saw and the same solution I thought of trying (but didn't)21:37
BlitzBlizzwhich recipe?21:38
UlfalizerBlitzBlizz: python-dbus_1.2.0.bb21:38
*** Gintaro <Gintaro!> has quit IRC21:39
BlitzBlizzis it possible to exclude python-dbus?21:39
Ulfalizerif you search the pastebin for "Error:", you'll see that some os.getenv()'s are failing, which in turn causes a .replace() to fail21:39
Ulfalizerthey return None, and that makes .replace() unhappy21:39
BlitzBlizzyes i saw this21:39
UlfalizerBlitzBlizz: not sure21:40
*** dv_ <dv_!~quassel@> has quit IRC21:40
* Ulfalizer found as well21:40
*** Gintaro <Gintaro!> has joined #yocto21:40
*** dv_ <dv_!> has joined #yocto21:40
moto-timohas the exact fix Ulfalizer mentioned.21:40
moto-timoso you can PNBLACKLIST the one from meta-python temporarily21:41
moto-timo(and we should probably consider dropping the one from meta-python)21:41
BlitzBlizzok. i will give it a try21:42
*** Gintaro <Gintaro!> has quit IRC21:43
moto-timoI know the one from core built ok for beaglebone machine21:43
*** Gintaro <Gintaro!> has joined #yocto21:45
BlitzBlizzdo i have to built a completely new image? (fyi: i'm new to the whole embedded/yocto thing)21:45
moto-timobitbake is smart enough to carry on where it left off21:46
BlitzBlizzi did this and the same error appears21:46
*** belen <belen!~Adium@> has joined #yocto21:46
BlitzBlizzi just moved the original .bb file and used the one from the link above21:47
*** khem` <khem`!~khem@unaffiliated/khem> has quit IRC21:47
Ulfalizerwhere did you move it?21:47
BlitzBlizzto bb.bakcup21:47
*** adelcast <adelcast!~adelcast@> has quit IRC21:48
Ulfalizerok... try running  bitbake python-dbus -c cleansstate  and then try rebuilding again21:48
Ulfalizernot great if that's needed though21:48
*** adelcast <adelcast!~adelcast@> has joined #yocto21:48
*** Gintaro <Gintaro!> has quit IRC21:48
*** dmoseley <dmoseley!> has joined #yocto21:48
Ulfalizermaybe adding exports is an obscure-enough case21:48
BlitzBlizzerror persists21:49
UlfalizerBlitzBlizz: try adding random junk to the bb file to make sure you didn't mess up :)21:49
Ulfalizeras a sanity check21:50
Ulfalizerto see that it's getting used21:50
moto-timo(or delete tmp and rebuild from sstate)21:50
moto-timobut that's a heavier hammer21:50
BlitzBlizzthis takes 3 hours to rebuild :-)21:51
UlfalizerBlitzBlizz: try running just  bitbake python-dbus21:51
moto-timonot with sstate it won't21:51
moto-timodouble negative. my grammar has gone south21:52
BlitzBlizzsanity check successfull21:52
BlitzBlizzparse error21:52
moto-timobitbake -c cleansstate python-dbus && bitbake python-dbus21:53
moto-timo(after you fix the parse error)21:53
rburtonparse error implies you make a typo21:53
* rburton is done for drive-by contributions and passes it back to moto-timo :)21:53
rburtong'night :)21:53
rburtonmoto-timo: good try with #99999 but i saw through you cunning plan21:54
moto-timorburton: of course you did21:54
rburtonwish we had more to redistribute :(21:54
moto-timoit was just for the laugh21:54
rburtonthere should be ~3 in JF somewhere21:54
moto-timowe need to kickstart another run21:54
rburtoni wonder if davest has some in a drawer somewhere21:54
rburtonyeah that would mean doing a 3d scan of a existing one21:55
rburtonthe model is way lost21:55
BlitzBlizzthis "bitbake -c cleansstate python-dbus && bitbake python-dbus" produced the pastebin again21:55
*** challinan <challinan!> has joined #yocto21:55
rburtoni may have "liberated" a copy of the entire openedhand git server before it got shut down post-acquisition and the model was never archived in the artwork repo :(21:56
UlfalizerBlitzBlizz: do you have some other python-dbus* bb files besides the one?21:58
Ulfalizerand does that one have 'export BUILD_SYS' and 'export HOST_SYS' in it?21:58
moto-timo^^^ very important21:59 that is21:59
BlitzBlizzonly and
UlfalizerBlitzBlizz: and and
UlfalizerDay changed to 22 Jul 201622:00
rburtonpastebin the entire recipe and the whole cooker log i guess22:00
*** Gintaro <Gintaro!> has joined #yocto22:00
UlfalizerBlitzBlizz: and have you double-checked that you have those two export's in it?22:00
Ulfalizerand are you getting the exact same errors as before?22:01
*** bfederau <bfederau!> has quit IRC22:01
*** fmeerkoetter <fmeerkoetter!> has quit IRC22:01
*** bfederau <bfederau!> has joined #yocto22:01
*** fmeerkoetter <fmeerkoetter!> has joined #yocto22:01
BlitzBlizzyes i checked it. export BUILD_SYS export HOST_SYS  are in file22:02
UlfalizerBlitzBlizz: on separate lines?22:02
Ulfalizerok... adunno then22:02
Ulfalizerseems odd22:02
moto-timoodd indeed22:02
BlitzBlizzi made some little changes to the local.conf. i don't know if this can cause the error22:03
*** Gintaro <Gintaro!> has quit IRC22:03
*** rburton <rburton!> has quit IRC22:04
BlitzBlizzi added "IMAGE_INSTALL_append = "proftpd" to the local.conf22:04
BlitzBlizzis this the right way?22:05
*** Gintaro <Gintaro!> has joined #yocto22:05
neverpanicYou're not even getting to the point where this matters when running bitbake python-dbus, but there should be a space before proftpd, since _append doesn't add one22:06
BlitzBlizzbblayers.conf: local.conf:
*** Gintaro <Gintaro!> has quit IRC22:09
*** evanmeagher <evanmeagher!~MongooseW@> has quit IRC22:09
moto-timothat bblayers.conf is truncated22:10
moto-timo(there's no closing ")22:11
moto-timoso probably didn't catch it all when you copied22:11
*** lamego <lamego!~jose@> has quit IRC22:11
BlitzBlizzthis "bitbake -c cleansstate python-dbus && bitbake python-dbus" produces this:
BlitzBlizzthe closing " is there. didn't catched it22:13
*** Gintaro <Gintaro!> has joined #yocto22:16
*** anselmolsm <anselmolsm!~anselmols@> has quit IRC22:17
*** anselmolsm <anselmolsm!~anselmols@> has joined #yocto22:17
*** Gintaro <Gintaro!> has quit IRC22:20
UlfalizerBlitzBlizz: is /home/debian1/buildDir/poky-krogoth-15.0.0/meta-openembedded/meta-python/recipes-devtools/python/ the file with the added exports? double-check.22:20
moto-timostrange that it isn't showing meta-oe, meta-networking and meta-python in the build output...22:21
moto-timoshould be seeing:22:21
moto-timometa-networking   = "krogoth:247b1267bbe95719cd4877d2d3cfbaf2a2f4865a"22:21
moto-timowhen's the last time you did a git pull on your repos?22:22
*** bottazzini <bottazzini!~realBigfo@> has quit IRC22:23
BlitzBlizzit was there. i don't know where it is gone. i added the exports and now i think it's working22:24
BlitzBlizzno error22:25
BlitzBlizzgreat. thank you guys :-)22:26
moto-timoyou're welcome22:26
BlitzBlizzi got some noob question. do you have time to answer them?22:26
Ulfalizertry and see. i might be going to bed at any moment though. :P22:26
moto-timowe can try. Otherwise I can point you to the ddocs22:26
BlitzBlizzfirst of all this line i added to the local.conf to built the proftpd... is this the right way to add22:27
moto-timoit is a right way. not the only way, but nothing wrong22:28
moto-timothe space matters (" proftpd")22:28
BlitzBlizzafter a succesful build, i add e.g. i will also the vsftpd, how can i build a new image including all i got before and the new vsftpd without building all packages? one build takes me 4-5 hours22:29
moto-timosee 5.2.1 in
moto-timoas long as you don't change layers and a few other things, bitbake is smart enough to use what it can22:30
moto-timothe actual last steps of building the image will of course have to be done fresh22:31
BlitzBlizzthere was always an error if i built in the same directory. but i didn't know the error anymore22:31
*** paulg <paulg!> has joined #yocto22:32
UlfalizerBlitzBlizz: rebuilding without rebuilding everything is how most builds are done when you're working on stuff. it's well-supported.22:33
Ulfalizerand yocto figures out by itself what needs to be redone22:33
BlitzBlizzok. i will try this after the current build.22:34
moto-timobut if you add a new layer, or change branches in a layer, the metadata has changed and so a rebuild is going to happen22:35
moto-timoif you are just changing what goes into an image in the existing build it shouldn't take as long22:35
BlitzBlizzok. i will not change that much. just want to transfer some data via ftp22:35
BlitzBlizzanother question. how can i change the keymap?22:36
*** igor2 <igor2!~igor@> has quit IRC22:36
*** benjamirc1 <benjamirc1!~besquive@> has quit IRC22:37
BlitzBlizzfrom qwerty to qwertz22:37
moto-timo28.2 in the mega manual link above22:37
moto-timoeh... not much detail22:38
*** istarilucky <istarilucky!~rlucca@> has quit IRC22:38
moto-timothat's not something I've done so I'll leave it to somebody else to answer :)22:38
*** Biliogadafr <Biliogadafr!> has quit IRC22:39
BlitzBlizzwho will answer this? :-)22:39
*** Gintaro <Gintaro!> has joined #yocto22:40
moto-timohere's an example:
BlitzBlizzhow can i exclude packages from being build? e.g. python-dbus. i didn't need this22:43
*** Gintaro <Gintaro!> has quit IRC22:43
moto-timoif it built, something needed it22:43
moto-timobitbake does not build stuff it didn't need22:43
moto-timothat's why the DEPENDS and RDEPENDS are there22:44
moto-timoin the recipes22:45
moto-timo(build time and run-time respectively)22:45
moto-timothere are a lot of good books on getting started with Yocto Project...22:45
BlitzBlizzi spend the last 2 weeks with it. it's a really amazing project, but at the moment i just want to getting a simple image, which is capable of transfering data via ftp. it's for my bachelor thesis and it's not about building an yocto image :-)22:47
moto-timoyou could try a pre-built distribution then22:48
*** Ulfalizer <Ulfalizer!> has quit IRC22:49
*** Gintaro <Gintaro!> has joined #yocto22:49
BlitzBlizzthe problem is, i need a working mptcp kernel and for yocto i found a good tutorial22:50
*** psadro <psadro!~Thunderbi@2620:0:ed0:800a:72f3:95ff:fe1d:9866> has quit IRC22:52
*** psadro <psadro!~Thunderbi@2620:0:ed0:800a:72f3:95ff:fe1d:9866> has joined #yocto22:52
*** Gintaro <Gintaro!> has quit IRC22:53
moto-timowell, it sounds like you are on your way to a working solution. I'm headed home. g'night.22:54
BlitzBlizzthanks again. :-) and good night22:55
moto-timoyou're welcome22:55
*** sameo <sameo!~samuel@> has quit IRC22:58
*** BlitzBlizz <BlitzBlizz!> has quit IRC23:00
*** Gintaro <Gintaro!> has joined #yocto23:08
*** Gintaro <Gintaro!> has quit IRC23:11
*** aehs29 <aehs29!~aehernan@> has left #yocto23:19
*** Gintaro <Gintaro!> has joined #yocto23:23
*** Gintaro <Gintaro!> has quit IRC23:26
*** Crofton <Crofton!> has quit IRC23:40
*** crankslider <crankslider!~slidercra@unaffiliated/slidercrank> has quit IRC23:41
*** Gintaro <Gintaro!> has joined #yocto23:42
*** Gintaro <Gintaro!> has quit IRC23:45
*** Gintaro <Gintaro!> has joined #yocto23:46
*** eraineri <eraineri!> has quit IRC23:47
*** Gintaro <Gintaro!> has quit IRC23:50
*** Gintaro <Gintaro!> has joined #yocto23:51
*** sgw_ <sgw_!sgw_@nat/intel/x-jsbqzkgaexxixxyj> has joined #yocto23:52
*** Gintaro <Gintaro!> has quit IRC23:54
*** challinan <challinan!> has quit IRC23:56

Generated by 2.11.0 by Marius Gedminas - find it at!