**** BEGIN LOGGING AT Tue Aug 11 02:59:58 2015 Aug 11 03:53:43 okay, i have a functioning prototype of use of shallow mirror tarballs. the problem with it is, it's still using a core that only supports a single mirror tarball, meaning it won't fall back to fetching a full git mirror tarball if there's no shallow tarball available, which isn't ideal Aug 11 03:54:15 so addressing that situation will be up next Aug 11 04:06:58 WIP: https://github.com/openembedded/bitbake/compare/openembedded:master...kergoth:shallow-git-mirror-tarballs#diff-a54c921e60fabbe307d2e90cf3bebb9cR201 Aug 11 04:07:12 re: the ExpansionError: https://github.com/openembedded/bitbake/compare/master...kergoth:useful-expansionerror-traceback (includes example output) Aug 11 06:53:57 Is there a variable in a recipe or bbappend that points to the current file, similar to python's __file__? Aug 11 07:00:25 OK, $FILE is what I'm looking for according to the definition of $THISDIR in base.bbclass; it's not documented, though. Aug 11 07:08:21 has anybody build a set top box image? Aug 11 07:39:45 is it possible to add a .bbappend file to a .inc? Aug 11 07:42:53 topik: AFAIK not. Aug 11 07:49:04 Hello everyone!! Aug 11 08:01:21 sujith_h: hi, how is it going with your layer config? Did you see the error I posted yesterday? Aug 11 08:20:38 Hi, I've been getting weird error of not finding revision thingy when I use linux-yocto-dev Aug 11 08:20:48 Full err msg at http://pastebin.com/eJt0m7eH Aug 11 08:20:59 I don't think there's network error though since it did download the git repo Aug 11 08:25:49 hey guys Aug 11 08:26:02 how to build an image without password? Aug 11 08:26:13 I want just type root to login and to be logged in Aug 11 08:27:12 Ox4`: check the debug-tweaks feature, one of the things it does is exactly that. Aug 11 08:31:04 LetoThe2nd: thanks Aug 11 08:32:03 morning all Aug 11 08:34:35 bluelightning: c\_/ Aug 11 08:38:57 Guys, anyone going to OEDEM? The wikipage has no info regarding how to join the meeting. Aug 11 08:46:14 edbart: Hi. Did you sent to mailing list? Aug 11 08:47:10 edbart: I saw your feedback regarding patch review. Aug 11 08:47:34 sujith_h: no, I didn't. I've sent it here. Aug 11 08:47:50 sujith_h: it may be fixed by your changes, I think. Aug 11 08:48:30 sujith_h: Can you explain your changes again please? I'm afraid I didn't get the idea. Aug 11 08:49:14 edbart: Sure. Aug 11 08:49:19 sujith_h: I only understood that current toaster code looks for 'yocto' for some reason. Aug 11 08:49:33 edbart: so let me open my config file Aug 11 08:49:35 sujith_h: and you had to add 'yocto,mel' to handle that. Aug 11 08:50:26 edbart: Initially I had yocto only in the bitbake area Aug 11 08:50:28 of the config Aug 11 08:50:48 edbart: And when I ran loadconf command, i was getting errors Aug 11 08:51:17 edbart: after debugging I realized that its trying to compare "yocto" with each of the repos I have added in the config file. Aug 11 08:51:39 edbart: can you show me your config file, please? Aug 11 08:51:59 edbart: So then I thought why not add mel to that and modify the code accordingly. And I added mel, later modified the code Aug 11 08:52:06 edbart: sure. Aug 11 08:53:11 edbart: http://pastebin.com/kACPy46L Aug 11 08:54:30 sujith_h: I can see 'yocto,mel' in bitbake part. Aug 11 08:54:44 edbart: yah Aug 11 08:55:37 edbart: So, this will help us if we have multiple remote branches Aug 11 08:55:49 named as mel or yocto or anything else. Aug 11 08:55:54 sujith_h: still don't get why do you need 2 remotes for every rpo. Aug 11 08:56:01 repo Aug 11 08:56:47 edbart: There are some repos with mel and some repos with yocto Aug 11 08:57:01 so I thought by adding names comma separated would help. Aug 11 08:57:18 edbart: sorry if the way I handled it was absolutely wrong :( Aug 11 08:58:14 sujith_h: no, it may be not wrong. I'm still trying to get it :) Aug 11 08:58:52 sujith_h: can you give me example of two repos with yocto and mel remotes? Aug 11 08:58:59 sujith_h: from your config. Aug 11 08:59:10 edbart: there are no two repos with yocto and mel Aug 11 08:59:19 edbart: only one of them is there Aug 11 08:59:24 Guys, where is recommended to put the PR definition, in the include or recipe file? Aug 11 08:59:40 sujith_h: I'm lost :) Aug 11 08:59:50 edbart: I wish I could call you :) Aug 11 09:00:02 edbart: Let me explain again. Aug 11 09:00:17 edbart: There are lets say 10 different layers Aug 11 09:00:32 ok Aug 11 09:00:46 edbart: Among them, some of the layers have remote output -> "yocto" Aug 11 09:00:58 edbart: Some of the layers have remote output -> "mel" Aug 11 09:01:12 none of the repos have both of them Aug 11 09:01:42 edbart: if I add only "yocto", then it will fail for repos which have output "mel" Aug 11 09:02:08 edbart: similarly If I add only "mel" it would fail for repos which have output "yocto" Aug 11 09:02:31 sujith_h: ok, so in bitbake configuration you can't say which layer to use, right? Aug 11 09:02:56 sujith_h: and this causes the issue in finding bitbake. Aug 11 09:03:13 sujith_h: Have I understood that correctly? Aug 11 09:03:45 edbart: bitbake configuration as in bblayers.conf? Aug 11 09:03:59 sujith_h: nope, in your config Aug 11 09:04:24 sujith_h: it starts from this line: "bitbake" : [ Aug 11 09:04:27 edbart: yah Aug 11 09:04:56 edbart: so the first error that hit me was when it started searching for remote output of meta-mentor layer Aug 11 09:05:23 edbart: and it has "mel", whereas loadconf.py file was searching for "yocto" as per the configuration. Aug 11 09:07:13 sujith_h: yes, and you fixed that by changing yocto to mel in layer configuration. Aug 11 09:07:36 edbart: yes Aug 11 09:09:06 sujith_h: that looks like correct fix to me. Aug 11 09:09:32 sujith_h: but having yocto,mel in bitbake section still puzzles me. Aug 11 09:10:41 edbart: give me a moment, let me revert change yocto,mel. Aug 11 09:11:15 sujith_h: git checkout -b test HEAD^ ? Aug 11 09:11:45 sujith_h: I mean you don't need to revert it. Just switch to the branch without it. Aug 11 09:14:21 edbart: When I remove yocto,mel to just yocto in bitbake area: http://pastebin.com/aMNBxGdf Aug 11 09:18:07 sujith_h: why does it look for bitbake in ssh://git@github.com/MentorEmbedded/meta-mentor.git ? Aug 11 09:18:26 sujith_h: is there bitbake in that repository? Aug 11 09:18:51 edbart: no there is no bitbake in the repo Aug 11 09:19:04 sujith_h: where is it then? Aug 11 09:19:52 there is no bitbake in meta-mentor. Its in the poky repo which I have added in the config file Aug 11 09:20:23 edbart: What I understood is that in the loadconf.py file Aug 11 09:20:26 sujith_h: yep, so you need a way to point out to it in bitbake configuration. Aug 11 09:20:41 sujith_h: otherwise it's a guess game. Aug 11 09:21:18 edbart: the first 3 layer name openembedded-core, meta-yocto, meta-yocot-bsp have yocto Aug 11 09:21:25 edbart: so till then its ok Aug 11 09:22:07 edbart: and the moment it finds a different layer with "mel" it will fail. Aug 11 09:22:52 sujith_h: do all of them have bitbake? Aug 11 09:23:08 sujith_h: I don't think so. Aug 11 09:23:11 edbart: no Aug 11 09:23:42 sujith_h: so, toaster code is trying to find bitbake in every layer from the configuration. Aug 11 09:23:57 sujith_h: it doesn't look good to me. Aug 11 09:23:58 edbart: yah Aug 11 09:24:49 edbart: instead it should look into the vcs_url accordingly and then add the layers Aug 11 09:28:22 sujith_h: I think proper fix would be to point to the layer+remote in bitbake section. Aug 11 09:28:54 sujith_h: it will also speed up the process as toaster will not be looking for bitbake in every layer. Aug 11 09:29:47 edbart: let me sketch patch for you and you'll try it, ok? Aug 11 09:29:55 edbart: Sure Aug 11 09:30:18 edbart: I didn't got layer+remote Aug 11 09:31:08 sujith_h: for now configuration poits to the remote without specifying the repository. Aug 11 09:31:21 sujith_h: so, toaster is looking for every repository. Aug 11 09:31:36 sujith_h: which is qute strange approach. Aug 11 09:32:01 sujith_h: and it fails because not every repository has remote specified in bitbake config. Aug 11 09:32:07 sujith_h: and it shouldn't Aug 11 09:32:53 edbart: ok Aug 11 09:33:36 edbart: I did a 200% hackish approach :( Aug 11 09:34:08 s/hackish/weird/ Aug 11 09:34:43 sujith_h: I may be wrong too. I'm relatively new to the project and don't know why it's designed this way. Aug 11 09:35:24 sujith_h: what I see in the code that _read_git_url_from_local_repository called only if giturl starts with 'remote:' Aug 11 09:35:57 sujith_h: just wondering would it work if you can specify full url there? Aug 11 09:36:08 sujith_h: I mean url of bitbake repo. Aug 11 09:36:36 sujith_h: I'll look at toasterconf from master. Aug 11 09:38:12 sujith_h: try to use "giturl": "git://git.openembedded.org/bitbake", there instead of remote... Aug 11 09:38:12 edbart: so if I am using poky, the /path/poky/bitbake, like that? Aug 11 09:38:29 edbart: sure Aug 11 09:39:04 sujith_h: I'm off for lunch. will be back in 30 mins. Aug 11 09:39:31 edbart: sure, I will update what happens I if I update with "giturl" and bitbake path Aug 11 09:42:18 edbart: This is the error I get : http://pastebin.com/FpmhuRC7 Aug 11 09:44:12 edbart: after replacing "remote:yocto" with "git://git.openembedded.org/bitbake" Aug 11 10:01:12 brb Aug 11 10:11:20 sujith_h: do you use loadconf.py with your modifications? Aug 11 10:12:27 sujith_h: your code breaks at this line: bvo.giturl = _read_git_url_from_local_repository(bvi['giturl']) Aug 11 10:12:50 sujith_h: in my code that line is executed only if giturl starts with 'remote:' Aug 11 10:15:02 sujith_h: are your layers public? I can't debug this as your config points to the local paths on your machine, i.e. /home/sujith/MEL/toaster_MEL/poky/meta Aug 11 10:49:44 edbart: I did a git stash Aug 11 10:49:51 edbart: Let me bring back my changes Aug 11 10:56:04 sujith_h: you shouldn't bring back your code changes. Aug 11 10:56:16 sujith_h: only config changes. Aug 11 10:56:34 edbart: ok. let me remove my code changes Aug 11 10:58:05 edbart: This is the config change I have: http://pastebin.com/xQML6J8T Aug 11 10:59:12 edbart: and it gives me error: http://pastebin.ubuntu.com/12054837/ Aug 11 11:02:18 sujith_h: this is another story. Aug 11 11:02:55 sujith_h: previously it was happening when toaster was trying to load bitbake section. Aug 11 11:03:16 sujith_h: this crash happens when it tries to load layer. Aug 11 11:03:34 sujith_h: so, bitbake section is fixed I think. Aug 11 11:05:26 edbart: If we specify, git url which points to git://git.openembedded.org/bitbake, will toaster try to clone bitbake? Aug 11 11:06:14 sujith_h: most probably Aug 11 11:07:38 edbart: oops. My requirement is bit different. I would provide toaster all cloned layers. But any ways will see that part later. Aug 11 11:09:57 sujith_h: yep, let's look at it later. Aug 11 11:10:19 sujith_h: which of your layers has this remote: mel ssh://git@github.com/MentorEmbedded/meta-mentor.git ? Aug 11 11:10:49 edbart: I don't see meta-mentor in your config. Aug 11 11:11:01 edbart: but I see that url in the traceback. Aug 11 11:12:56 edbart: meta-mentor is a repo which has layers inside it. Just like meta-oe Aug 11 11:14:02 edbart: meta-mentor has layers meta-mentor-staging, meta-mel, meta-mel-support etc Aug 11 11:14:53 edbart: So in the layers section local_path, I have provided my local path to the layers. Aug 11 11:19:24 sujith_h: hm, why remote yocto is used there then? Aug 11 11:21:36 edbart: You mean vcs_url? Aug 11 11:23:00 edbart: I had used it based on the output I got from git remote -v on each layer Aug 11 11:23:29 sujith_h: I mean this: Error while looking for remote "yocto" in "mel ssh://git@github.com/MentorEmbedded/meta-mentor.git (fetch) Aug 11 11:24:14 sujith_h: it means that remote:yocto is specified for one of your repos in config. Aug 11 11:24:28 sujith_h: however, that repo has only 'mel' remote. Aug 11 11:26:26 edbart: Only 4 layers have "remote:yocto" 1) Poky's : meta, meta-yocto, meta-yocto-bsp 2) meta-fsl-arm Aug 11 11:27:12 sujith_h: hm, let's see. may be it's a bug in the code. Aug 11 11:29:23 edbart: yah, may be Aug 11 11:31:57 sujith_h: can you apply this patch please: https://gist.github.com/bart0sh/ee6e25e1a7c41fb1e932 Aug 11 11:32:04 sujith_h: and show me the output. Aug 11 11:32:33 edbart: sure Aug 11 11:35:51 edbart: http://pastebin.ubuntu.com/12054991/ Aug 11 11:40:09 sujith_h: thank you. one more patch, please: https://gist.github.com/bart0sh/baa69ee1a5edddded975 Aug 11 11:40:15 edbart: sure Aug 11 11:42:01 edbart: http://pastebin.ubuntu.com/12055021/ Aug 11 11:47:20 sujith_h: can you show me the output of this command on your system: cd /home/sujith/MEL/toaster_MEL/poky/meta && git remote -v Aug 11 11:47:30 edbart: sure Aug 11 11:48:21 edbart: http://pastebin.ubuntu.com/12055043/ Aug 11 11:52:13 sujith_h: one more patch: https://gist.github.com/bart0sh/592fceb5bd384c857082 Aug 11 11:52:47 sujith_h: it includes two previous changes Aug 11 11:53:25 edbart: sure Aug 11 11:53:26 Hello:.. Aug 11 11:54:14 I want to know how the kernel mount the SD slot and make link in /dev repertory . /dev/mmcblk0p1 Aug 11 11:54:24 edbart: may be 1% resemblance with change I made to loadconf.py :) Aug 11 11:55:08 sujith_h: I'm not sure about that :) Aug 11 11:57:05 sujith_h: I have last tiny suggestion regarding v3 of your patch, btw. Other than that it looks great, thank you! Aug 11 11:59:04 sujith_h: this line 'self.assertTrue(data["error"], "ok")' should be replaced with 'self.assertEqual(data["error"], "ok") Aug 11 12:03:01 edbart: sure Aug 11 12:04:02 edbart: I made a small modification in your patch, it was local_path , key. and this is the debug output: http://pastebin.ubuntu.com/12055115/ Aug 11 12:04:46 edbart: This was my old change : http://pastebin.ubuntu.com/12055122/ Aug 11 12:04:47 :) Aug 11 12:06:03 sujith_h: ah, now I see the recemblance :) Aug 11 12:07:06 sujith_h: I forgot about it. looked mostly at two remotes for bitbake. Aug 11 12:07:58 sujith_h: so, that patch fixes the issue with layers, right? Aug 11 12:10:01 edbart: Well that patch, actually uses split line no.28. That was because I was using remote:yocto,mel in the bitbake section of the config Aug 11 12:10:35 sujith_h: I mean my patch fixes the issue with layers configuration. Aug 11 12:10:54 sujith_h: let's go back to bitbake configuration. Aug 11 12:11:29 sujith_h: there are two ways to fix it Aug 11 12:12:59 edbart: This is the webpage I get after running loadconf and reloading webpage : http://imagebin.ca/v/2BlnXN8eZveo Aug 11 12:13:41 sujith_h: first way is to replace "giturl": "git://git.openembedded.org/bitbake" with "giturl": "/home/sujith/MEL/toaster_MEL/poky/" Aug 11 12:14:08 sujith_h: toaster will still clone the repo, but it will do it locally. Aug 11 12:15:34 sujith_h: let's finish with the loading issues first. Aug 11 12:19:50 edbart: sure. Aug 11 12:22:32 edbart: I have updated the patch. Need to take a small break. I am down with fever, cold and cough. Aug 11 12:22:41 edbart: brb Aug 11 12:23:40 sujith_h: get better! Aug 11 12:33:26 edbart: hi Aug 11 12:33:34 edbart: what's the toaster channel ? Aug 11 12:34:14 ddalex: it's in internal jabber Aug 11 12:45:43 sujith_h: i'm looking into what you're seeing with Toaster Aug 11 13:10:19 edbart: i am back Aug 11 13:10:57 ddalex: sure Aug 11 13:42:06 sujith_h: hi Aug 11 13:42:31 sujith_h: for a bit of reference, in the poky tree, do a diff between meta/conf/toasterconf.json and meta-yocto/conf/toasterconf.json Aug 11 13:42:57 the "meta/conf/toasterconf.json" is designed to use an out-of-tree bitbake Aug 11 13:43:34 and the bitbake giturls are given as absolute paths Aug 11 13:43:50 ddalex: sure let me do a diff Aug 11 13:43:57 ddalex: ok Aug 11 13:46:16 ddalex: http://pastebin.ubuntu.com/12055564/ Aug 11 13:46:37 ddalex: oops i shouldn't have pasted the diff :( Aug 11 13:48:02 ddalex: I have replaced giturl with absolute path in my config Aug 11 13:50:09 sujith_h: the question that is answered by this config file is: Aug 11 13:50:49 sujith_h: what "bitbake" do I need to build the version of the layer imported here for the specified "branch" of the layer Aug 11 13:51:19 sujith_h: so you need to be careful to specificy valid bitbake values for the layers defined in your config file Aug 11 13:52:03 sujith_h: hope this helps Aug 11 13:57:57 ddalex: sure. In the bitbake section of the config file, I have pointed giturl to the location of bitbake: http://pastebin.ubuntu.com/12055618/ Aug 11 15:37:29 * sujith_h leaves for the day Aug 11 15:37:40 Hi! Why can't I set MACHINE = "vmwx86" and why must I set it with MACHINE ?= "vmwx86" so that env. variables can override it? Aug 11 15:38:09 that doesn't really make sense Aug 11 15:38:20 mcfrisk: er, you *can* set it with ?= Aug 11 15:38:20 you don't have to use ?= unless you want to be able to set it from the environment Aug 11 15:38:26 if you want to do so, go ahead Aug 11 15:38:44 ?= is "set only if not already set". if it was set in the environment, then it was already set. Aug 11 15:38:57 whereas = will blow away the existing value Aug 11 15:39:47 yes, I'm writing a build script which creates a valid local.conf and sanity complains that MACHINE is bad if I don't define it with ?= Aug 11 15:40:34 I don't want any env variables to override the MACHINE that I set in this local.conf. Or any other variable for that matter. Aug 11 15:40:50 again, that doesn't make any sense. sanity doesn't care if you use ?= for MACHINE in local.conf Aug 11 15:40:55 i never do Aug 11 15:40:58 yes it does Aug 11 15:41:06 well, hundreds of folks don't Aug 11 15:41:09 so don't know what to tell you Aug 11 15:41:37 ok, I'm on dizzy where this happens Aug 11 15:42:35 "Please set a valid MACHINE in your local.conf or environment" when I have MACHINE = "vmwx86" Aug 11 15:42:56 sounds like that isn't a valid machine, and you had MACHINE set in your env, so when you set it with ?= it wasn't set to vmwx86 at all Aug 11 15:43:14 Personally, I've never set machine from the environment, nor defined my vars to expect it to be set that way in my personal builds Aug 11 15:43:39 And no warnings from sanity if I set it with MACHINE ?= "vmwx86" in conf/local.conf Aug 11 15:43:59 and I don't have MACHINE set in env Aug 11 15:44:05 I user MACHINE from the nevironment all the time.. calling like: MACHINE=qemux86-64 bitbake core-image-minimal Aug 11 15:44:05 so I assume this is a bug in sanity Aug 11 15:44:20 that way I can follow it up with a different machine and use the same project Aug 11 15:44:29 did you bother to check bitbake -e and see if MACHINE is what you think it is? Aug 11 15:44:33 check your assumptions Aug 11 15:46:49 where in bitbake -e output is MACHINE? I see MACHINEOVERRIDES="vmwx86", and MACHINE_ARCH="vmwx86" but not plain ^MACHINE there. Aug 11 15:47:10 it's probably commented out due to unexport Aug 11 15:47:13 check for ^#MACHINE Aug 11 15:50:02 denix: do you happen to know what upstream branch/release meta-arago master is supposed to go with? not upstream master, given all the old now-incorrect paths in meta-arago-extras.. Aug 11 15:50:33 with bitbake -e I also see just the sanity error if I set MACHINE="vmwx86" in local.conf. If I set it with MACHINE ?= "vmwx86" it is set correctly and sanity error is gone. I assume there's a bug in sanity check for MACHINE... Aug 11 15:50:39 kergoth: currently fido Aug 11 15:51:00 kergoth: which paths are incorrect? Aug 11 15:51:31 denix: gstreamer0.10 now lives in reicpes-multimedia/gstreamer-0.10/ in meta-multimedia, now that 1.0 is default, not recipes-multimedia/gstreamer/ Aug 11 15:51:42 i'll try fido though, thanks Aug 11 15:52:51 kergoth: yeah, will have to remove gst0.10 soon anyway, since we switched to 1.x now Aug 11 15:52:57 * kergoth nods Aug 11 15:54:26 mcfrisk: all sanity.conf checks is whether conf/machine/${MACHINE}.conf exists, using the value from the metadata. it doesn't poke into *how* it's set in local.conf at all. that was true in dizzy and it's true in master. Aug 11 15:54:32 mcfrisk: sanity.bbclass, that is Aug 11 15:54:51 so again, its value almost certainly isn't what you think it is Aug 11 15:56:10 kergoth: ok, thanks. Then I guess it might be a template problem. I'll dig into that. Thanks! Aug 11 15:57:28 denix: btw, minor issue, but you guys should set LAYERDEPENDS_meta-processor-sdk in meta-processor-sdk to make clear the dependence on both meta-arago-distro and meta-arago-extras. I'm guessing you don't get many folks wanting to use that bsp layer with other distros, but best to be explicit Aug 11 15:58:42 on a related note, you can't use meta-arago-distro wtihout meta-arago-extras: meta-arago/meta-arago-distro/recipes-core/meta/meta-toolchain-arago-tisdk.bb:5: Could not include required file recipes-core/meta/meta-toolchain-arago-qte.bb Aug 11 15:58:46 so extras aren't very extra ;) Aug 11 15:59:42 kergoth: meta-processor-sdk is not supposed to be used on its own :) it's just a staging area before it gets to upstream - either meta-arago, meta-ti or even higher to meta-oe or oe-core Aug 11 16:00:20 kergoth: heh, I know of some interdependency, which I need to clean, but haven't had time Aug 11 16:00:53 heh, no worries, i probably have some of that between the meta-mentor layers too Aug 11 16:01:05 periodically have to go back and make sure the distro layer is still yocto compliant Aug 11 16:03:34 kergoth: btw, thanks for the reminder! anything specific you are looking for in meta-arago? or just poking? :) Aug 11 16:03:44 just poking at the moment :) Aug 11 16:29:27 denix: I tried meta-arago yesterday too, and I was under the impression it depends on an external toolchain by linaro. Is that right? Aug 11 16:30:30 mario-goulart: it can use any toolchain or build one from sources, but DISTRO sets external linaro by default Aug 11 16:30:54 mario-goulart: pass TOOLCHAIN_TYPE and TOOLCHAIN_BRAND to control that Aug 11 16:31:52 denix: ah, ok. I think the error I got was due to meta-arago-extras/recipes-core/meta/external-linaro-toolchain.bbappend , which caused an error because elt_get_bfd_version returned None. Aug 11 16:33:01 I wasn't using the arago distro, BTW. Aug 11 16:33:42 mario-goulart: I see. I guess it could depend on something from distro part - I need to clean that... Aug 11 16:41:28 RP1: https://github.com/openembedded/bitbake/compare/master...kergoth:useful-expansionerror-traceback Aug 11 16:43:24 denix: i'd recommend in that particular case you think about adopting the pattern where you can put appends in a subdir for the layer their recipe lives in, which lets a distro layer append on bits in layers that might or might not be available. See https://github.com/MentorEmbedded/meta-mentor/blob/master/meta-mel/conf/layer.conf#L5-L10, https://github.com/MentorEmbedded/meta-mentor/tree/master/meta-mel/fsl-arm Aug 11 16:43:33 s/append on/depend on/ Aug 11 16:44:32 RP1: the comment at the bottom shows an example Aug 11 16:45:07 kergoth: ah, very nice! I'll definitely steal that bit! :) Aug 11 16:45:16 RP1: the filenames, lack of code context, etc aren't ideal, but we can improve that as a later step Aug 11 16:45:33 denix: :) Aug 11 17:24:12 kergoth: your change reminds that python3 has far better backtrace than python2 Aug 11 17:24:34 may be bitbake should plan on using python3 Aug 11 17:26:12 I see that after systemd moved to using github infra for patch management the spike in patch contribution is huge Aug 11 17:26:38 so afterall a complete orchestration tool for codeflight has lot of value Aug 11 17:27:47 really? that's quite interesting Aug 11 17:27:51 (re systemd) Aug 11 17:27:53 i agree on python3 Aug 11 17:28:01 given the advent of tools like github and gitlab etc. the days of using mailing lists for patch management has served its purpose Aug 11 17:42:40 khem, the concern would be github starts to charge at some volume of activity Aug 11 17:43:02 or other metric, and all of a sudden we find outrselves forced to pay for workflow Aug 11 17:43:06 we'd probably have to host a gitlab Aug 11 17:43:13 would avoid that issue Aug 11 17:43:26 yeah, we'd need to think it through Aug 11 17:43:30 there'd be a lot of resistance from the community to any change of any sort, though :P Aug 11 17:47:19 nothing to stop oe hosting a gitlab and migrating a couple of layers to see what happens Aug 11 17:47:55 what's gitlab like compared to github? never used it. Aug 11 17:48:12 importantly, does it let you merge a pull request with a fastforward instead of adding merge commits? Aug 11 17:49:01 bastards, that's an enterprise feature Aug 11 17:49:15 http://doc.gitlab.com/ee/workflow/rebase_before_merge.html Aug 11 17:49:30 hooks are enterprise too Aug 11 17:49:48 open core :} Aug 11 17:50:00 and money for the features everyone wants in github Aug 11 17:50:12 god i bet their planning meetings are evil Aug 11 17:50:36 hrmph Aug 11 17:50:51 no discounts for non-profits too Aug 11 17:54:45 have you considered gerrit? Aug 11 17:55:33 zecke: gerrit is fine but needs hosting Aug 11 17:57:30 I think its easy for patches to get lost in mailing lists thats why tools like patchwork etc. are but github, bitbucket etc. take it to different level Aug 11 17:58:07 llvm uses yet another tool called phabricator Aug 11 17:58:18 http://phabricator.org/ Aug 11 17:59:55 hooking up travis ci to github is nice for CI too Aug 11 18:00:03 I did it for meta-musl Aug 11 18:00:17 but problem is its limited for free use Aug 11 18:00:46 building full platforms like we do in OE world is way above the limits travis allows Aug 11 18:01:08 so all my builds fail due to "build running for too long" error :) Aug 11 18:01:39 systemd wont have this problem Aug 11 18:09:55 main issue with github is that the pull requests are insane Aug 11 18:10:16 in what way ? Aug 11 18:11:47 khem`: if you could cache sstate it might help as well.. but sure if you modify musl everything will rebuild :} Aug 11 18:12:59 zecke: yeah and I need to host that sstate somewhere Aug 11 18:13:03 public Aug 11 18:13:27 zecke: I saw you use musl whats yuor usecase ? Aug 11 18:18:19 khem`: you can send a PR Aug 11 18:18:24 then rebase your branch Aug 11 18:18:28 and rebase again Aug 11 18:18:32 and again Aug 11 18:18:42 and the PR is based on the last rebase Aug 11 18:18:58 abelloni: yes but isnt that whats required anyway ? Aug 11 18:18:59 which means the maintainer has to be extra careful Aug 11 18:19:32 right so one can sneak in unreviewed changes Aug 11 18:19:40 but that will happen only once Aug 11 18:20:12 rburton: is some one trying glibc 2.22 builds on AB ? Aug 11 18:20:29 not if the goal is to get more contributions Aug 11 18:20:40 people will send PRs Aug 11 18:21:06 so how does kernel folks solve this issue Aug 11 18:21:17 that model is similar to github's Aug 11 18:23:17 abelloni: you can see, easily, when looking at a PR if the content has changed. each push is shown in the history Aug 11 18:23:22 just need to pay attention Aug 11 18:23:47 khem`: simple, Linus doesn't take PRs from random people Aug 11 18:24:46 so here its flat structure compared to Linux pyramid model Aug 11 18:34:30 khem`: I have been toying around. I started a project to have full image updates for our BTS devices. I have a system0/system1 partition and then a rescue system (update controller, dropbear) Aug 11 18:34:49 zecke: ok Aug 11 18:34:52 khem`: and my rescue system should be as small as possible, uclibc doesn't seem buildable for amrv5t in fido/master. Aug 11 18:35:30 zecke: yeah ok. let me know how it goes Aug 11 18:35:50 I have got lot of stuff building/running using musl Aug 11 18:36:25 khem`: yes will do. I didn't run it on the HW yet but the size is promising. Only barebox (the target utility) in addition to coreutils didn't build Aug 11 18:37:00 khem`: thanks for the integration work. musl really looks interesting! Aug 11 18:37:02 yeah generally in my experience if something doesnt build with musl its due to applications sloppiness Aug 11 18:37:48 khem`: right, barebox has its copy of strlcpy (it obviously clashes) and is using ulong instead of off_t/size_t Aug 11 18:39:03 OK glibc doesnt have strlcpy :) Aug 11 18:41:47 I would think that barebox can't clash with the libc Aug 11 18:53:46 abelloni: strlcpy is not posix function Aug 11 18:54:01 so its signatures could vary Aug 11 18:54:19 although I think it originates from BSD Aug 11 18:55:37 so musl matches that Aug 11 19:00:40 abelloni: barebox the bootloader can't clash with a libc, but it is building a target utility as well and this clashes with the libc Aug 11 19:13:28 Is there a way that I can see what the final result for a variable is like DISTRO_FEATURES for a recipe? Aug 11 19:13:44 Cardoe: bitbake -e? Aug 11 19:15:36 zecke: thanks Aug 11 19:24:58 khem: what branch is your glibc 2.22 upgrade on? Aug 11 19:25:15 khem: you refer to a branch but there's no mention of what it actually is :) Aug 11 19:29:55 http://git.openembedded.org/openembedded-core-contrib/log/?h=kraj/for-master Aug 11 19:30:03 thanks Aug 11 19:34:31 rburton: I would be interested to see some of failures on x86/coreutils with gcc5 go away with this Aug 11 19:34:48 yeah let's see Aug 11 19:35:01 i'll smoke test locally now, and hit the ab tonight maybe Aug 11 19:35:19 ok Aug 11 19:35:31 my usual targets are mips and arm Aug 11 19:35:46 and it has been doing fine on those system s Aug 11 19:44:50 So, I have a pseudo thing coming up which might improve performance. And this leads me to a question: Aug 11 19:44:54 What if anything have we got for build profiling right now? Aug 11 19:45:17 I want to have some kind of useful measurements so I can tell whether I'm even making progress, or how much, etcetera. Aug 11 19:47:38 I mean, I can time builds, I guess. But I also want to try to get more detailed information on, say, how much time is spent in or waiting on pseudo, specifically. Aug 11 19:59:53 khem: valgrind fails (| checking the GLIBC_VERSION version... unsupported version 2.22) Aug 11 20:00:16 yes thats a patch needed for valgrind Aug 11 20:00:26 its a ritual we need to do everytime we upgrade glibc Aug 11 20:01:18 see http://git.openembedded.org/openembedded-core/tree/meta/recipes-devtools/valgrind/valgrind/glibc.patch Aug 11 20:19:20 Is there a way to just mirror git repos and only git repos? Aug 11 20:19:44 linux-yocto is painfully slow to grab Aug 11 21:37:54 rburton: http://git.openembedded.org/openembedded-core-contrib/commit/?h=kraj/master&id=b3de9a8af00095a42641131d42d6ab8e6450f2e1 Aug 11 21:38:00 for valgrind fix Aug 11 21:38:08 you can cherry-pick it Aug 12 00:47:18 anyone else got the same msg WARNING: Failed to fetch URL git://git.yoctoproject.org/linux-yocto-dev.git;bareclone=1;branch=standard/base,meta;name=machine,meta, attempting MIRRORS if available ? **** ENDING LOGGING AT Wed Aug 12 02:59:59 2015