**** BEGIN LOGGING AT Mon Aug 24 02:59:59 2015 Aug 24 07:56:03 hey, has anyone stumbled on a circular dependency error on initscripts_1.0.bb? Aug 24 07:56:38 apparently it used to be problem with intel-iot-devkit but i'm not using that Aug 24 08:29:06 morning all Aug 24 08:47:16 good morning :) Aug 24 09:11:46 same thing over here... Aug 24 09:11:51 https://www.youtube.com/watch?v=kerUbfOQTW0 Aug 24 09:18:23 OHAI! Aug 24 09:18:36 Is there a separate IRC channel for OE? Aug 24 09:18:55 I'm hoping to speak to the maintainer of the perl layers for OE Aug 24 09:19:10 and I wonder if it is best to try here or somewhere else. Aug 24 09:20:18 The yak I wish to shave is why are there two perl versions given for perl in in yocto 1.7 (perl 5.20.0 and 5.14.2) Aug 24 09:20:51 jeremiah: there is #oe yes Aug 24 09:21:52 bluelightning: Thanks, I guess I'll hop over there. :-) Aug 24 10:12:38 bluelightning: I want to add "TARGET_CC_ARCH_append_pn- = " -fPIC -pie " to all packages of a packagegroup. Can I do it with a bbappend for the packagegroup.bb file, instead of changing each package recipe ? Aug 24 10:13:09 milan_: I'm afraid not; one recipe cannot influence the build process of another in that way Aug 24 10:13:50 ok Aug 24 10:16:10 Is it at all possible to achieve this for a particular image ? I do not want to affect other images (using the same packages) with this change. Probably that's why I am not able to add this to distro.conf file as well :( Aug 24 10:21:43 bluelightning : Would appreciate any advice on the above scenario Aug 24 10:23:09 there are only two practical ways really - have two recipes (perhaps sharing a common inc file) that deploy differently named packages that you can select from the image; or, completely separate builds with separate distro configurations Aug 24 10:24:10 I am currently working on cleaning up my system on the machine, and I have some packages I absolutely do not need. For example "avahi-daemon". But opkg says it is depended upon by some packages: packagegroup-base-zeroconf & libnss-mdns. Is there a way to overwrite these dependencies and force bitbake to not install them at all? Aug 24 10:26:01 bluelightning : thanks Aug 24 10:33:07 zwerch: have a look at the packagegroup-base recipe and see how those packagegroups come in - it's all based on MACHINE_FEATURES and DISTRO_FEATURES, so you should set those appropriately Aug 24 10:33:37 zwerch: mostly it'll be about DISTRO_FEATURES Aug 24 11:04:56 bluelightning: thanks, I'll have a look Aug 24 11:10:46 Hi! I'm trying to do static code analysis with CodeSonar on yocto, using codesonar's compiler wrapper. Is there a way I can wrap all do_compile funcions with this compiler wrapper? I could extend base.bbclass to run oe_runmake with codesonar wrapper but that would not match custom do_compile's in various recipes. Aug 24 11:11:36 Anyone knows where "watchdog watchdog0: watchdog did not stop!" comes from, and how to disable it spamming logs? Aug 24 11:12:57 AzaToth: obviously from some watchdog ^^ maybe have a look at your /etc/watchdog.conf (if it exists) Aug 24 11:14:30 AzaToth: probably it has the magic close feature Aug 24 11:14:59 bluelightning: the base for my image is the core-x11 image, but I can't find packagegroup-base-zeroconf anywhere :( Aug 24 11:15:17 mcfrisk: hmm... I suspect you'd prepend CC or something like that in order to have the wrapper invoked Aug 24 11:16:02 zwerch: packagegroup-base-zeroconf is a package produced from the packagegroup-base recipe that I mentioned earlier - meta/recipes-core/packagegroups/packagegroup-base.bb Aug 24 11:16:43 joseppc, what's the magic close feature? Aug 24 11:17:05 bluelightning: yeah I know, already found it's declaration, but how can I exclude this packagegroup from packagegroup-base without rewriting it? Aug 24 11:17:22 zwerch, we've enabled the watchdog chip in the kernel config, but we've no watchdog.conf Aug 24 11:17:32 bluelightning: ooooooh never mind Aug 24 11:17:34 bluelightning: actually I could just call "codesonar analyze bitbake image_name", but codesonar doesn't know how to split results after compiling like this. With Coverity the analysis results can be post-processed and split to recipies based on source file locations in the build tree. Aug 24 11:17:44 bluelightning: I think I got it, thanks so much Aug 24 11:18:10 AzaToth: to start the WD you open the device, normally it is disabled if you close the file descriptor. With the magic close the WD keeps ticking even after the file is closed Aug 24 11:18:12 AzaToth, then maybe this is the problem. Try installing the watchdog package and enable it's hardware-device Aug 24 11:18:56 AzaToth: at least unless you write the "magic string", which is the V character to the file, then the WD will be disabled upon closing the fd Aug 24 11:19:20 looking; thanks Aug 24 11:19:42 bluelightning: ... so I'd like a way to run all do_compile's with the 'codesonar analyze ${DISTRO}_${PN} do_compile' Aug 24 11:20:00 AzaToth: http://layers.openembedded.org/layerindex/recipe/122/ Aug 24 11:20:32 AzaToth: one of the patches applied uses /dev/watchdog as hardware watchdog device Aug 24 11:21:37 mcfrisk: I'm not sure you can easily do that, that I know of... I guess you could do something like do_compile_prepend() { codesonar analyse ... ( } do_compile_append() { ) }, but I really don't know that that will work or even parse for that matter Aug 24 11:23:21 mcfrisk: another hacky way around it would perhaps to be use anonymous python to grab the value of do_compile, set that as another function, then set do_compile_prepend() to call that function within the wrapper and then exit Aug 24 11:24:45 zwerch, ah Aug 24 11:24:58 bluelightning: the prepend&append I could try out, maybe with a here text though it does feel really hacky too. Aug 24 11:25:43 how does that anonymous python thing work, any examples I could have a look at? Aug 24 11:26:02 mcfrisk: right, and whether it works is going to be dependent on your append/prepend being applied last Aug 24 11:29:10 mcfrisk: git grep 'python \(__anonymous \)\?() {' Aug 24 11:29:37 (the __anonymous is optional, I believe the modern convention is not to include it) Aug 24 11:31:39 hmm, all of these depend on the order of execution, when is the anonymous python thing executed? When parsing the recipe? Aug 24 11:56:47 hi.. i am interested in the testimage stuff.. but i do not want to boot the target and deploy stuff. i only want to get the tests generated and afterwards run them from a different machine. is there a way to get rid of the masterimage stuff.. only getting the tests? Aug 24 11:57:49 bluelightning: If I add a DISTROOVERRIDES in an image.bb file, should it affect the included packages for that image this way ? Aug 24 11:58:09 no Aug 24 12:01:41 rburton: But when I run bitbake -e image, I can see the DISTROOVERRIDES included in to the overrides list! Not sure why it should not reflect for the listed packages under it. Aug 24 12:02:10 milan_: it won't rebuild the recipes though Aug 24 12:03:08 ok,understood Aug 24 12:07:22 rburton: Will it make sense to add "SSTATE_DISABLE="1" as well into the image file here ? Aug 24 12:07:48 Hope that should help rebuild all the packages Aug 24 12:09:33 you can't manipulate distro-wide settings from inside an image Aug 24 12:09:49 inside the image recipe any changes you make are specific to the image recipe Aug 24 12:11:06 rburton: My changes are focussed on a particular image ( meant for a specific customer). Hope I am on the right path then ? Aug 24 12:11:33 I dont want it to be reflected across all images of the distro Aug 24 12:22:51 How can I delete some DISTRO_FEATURES without rewriting them completely? Aug 24 12:24:15 milan_: as I said earlier, you simply cannot do things the way you're trying to do them - you cannot influence the build one recipe from another - i.e. you can't make these changes from the packagegroup or the image recipe Aug 24 12:24:22 zwerch: DISTRO_FEATURES_remove, if you have a recent enough OE Aug 24 12:24:37 rburton: is 1.7 recent enough? Aug 24 12:25:20 yes Aug 24 12:25:30 nice, thansk Aug 24 12:26:12 Can I do this in the image / layer.conf or does it have to be done in the local.conf? Aug 24 12:27:58 zwerch: local.conf or custom distro config (preferably the latter) Aug 24 12:28:12 zwerch: doing things like that in the layer.conf is evil Aug 24 12:28:33 Okay, thanks Aug 24 12:29:22 I still don't get when to use which conf ^^ Aug 24 12:30:47 local.conf is for local settings, the less you put in there the better (it's supposed to be something you create for the specific install and completely replicable without having to put it into version control) Aug 24 12:31:52 anything that is "policy" about how the system is built i.e. which recipes to select, what options to enable, etc. should go into the custom distro config that you point to from DISTRO Aug 24 12:32:46 okay, then we did it intuitively right :) thanks Aug 24 12:33:13 the layer.conf should just add the paths such that items in the layer can be found and set the priority, and that's pretty much it Aug 24 12:38:19 so, our DISTRO is by default set to "poky", where do I find the distro config (and how do I append it)? Aug 24 12:43:58 Ah, I found the poky.conf, but how can I create a new distro that inherits from poky.conf? Or just plain copy the file? Aug 24 12:47:15 Can I just use the "poky-bleeding.conf" and copy it? Aug 24 12:47:55 And then simply set my DISTRO in the layer.conf? Aug 24 12:52:52 bluelightning: Does SSTATE_DISABLE="1" force all dependencies to be re-built ? Aug 24 12:59:44 milan_: I don't think it will no Aug 24 13:00:03 zwerch: you can do either of those Aug 24 13:00:15 zwerch: you may wish to read http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#creating-your-own-distribution Aug 24 13:00:26 ok Aug 24 13:00:31 Hi, everyone! Where can I read documentation for matchbox? Where is config files, what can I config, etc… Aug 24 13:02:38 bluelightning: thanks! Aug 24 13:04:27 pohmelie: https://github.com/openembedded/openembedded-core/blob/master/meta/recipes-graphics/matchbox-wm/matchbox-wm_git.bb this is the recipe (or the one in of the branches), there is a homepage http://matchbox-project.org, you should be able to get some information there Aug 24 13:06:59 zwerch: matchbox-project.org just a mirror for yocto page, which has no information I need. Recepie also have no information about configuring. Aug 24 13:11:43 pohmelie: you are right, sorry, but I could find a https://github.com/openembedded/openembedded-core/blob/master/meta/recipes-graphics/matchbox-wm/matchbox-wm/kbdconfig#L7 reference here, which was not helpful because it didn't load. But I found this, maybe it helps you: http://wiki.openmoko.org/wiki/Window_Manager_Startup Aug 24 13:15:30 zwerch: thanks ;) Aug 24 13:16:01 pohmelie: but there seem not to be that many options :D Aug 24 13:16:35 pohmelie: http://manpages.ubuntu.com/manpages/lucid/man1/matchbox-window-manager.1.html Aug 24 13:22:06 zwerch: Wow, it is just what I looking for! Great! Aug 24 13:53:21 I’m wondering what the proper SRCREV and PV for a package is that’s from git but I’m trying to build an RC tag? Aug 24 13:53:36 Do I use the commit-ish fully or the tag? Aug 24 14:00:09 Cardoe: if your recipe is named mypackage_git.bb it's correct Aug 24 14:01:28 Cardoe: more information on fetching code is here: http://www.yoctoproject.org/docs/1.8/dev-manual/dev-manual.html#new-recipe-fetching-code Aug 24 14:02:07 Cardoe: http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#properly-versioning-pre-release-recipes Aug 24 14:02:49 i.e. if you do use the RC version in PV, then do it in the manner described so that you don't get the version seemingly going backwards when you upgrade to the final release Aug 24 14:03:33 Cardoe: also, use the full commit hash in SRCREV, and specify the branch it comes from in branch= in SRC_URI (if it's not a commit that's on master) Aug 24 14:03:48 It’s on master Aug 24 14:03:57 I’m trying to clean up Xen in meta-virtualization Aug 24 14:03:59 Cardoe: you should not use master in production stuff Aug 24 14:04:16 This isn’t for production. Aug 24 14:04:24 Cardoe: just saying ^^ Aug 24 14:04:33 meta-virtualization has their xen_git.bb on some random Xen 4.4 master commit. Aug 24 14:04:41 It has xen_4.5.0.bb as well Aug 24 14:04:54 And then it has pulled out “common” bits into xen.inc Aug 24 14:05:02 You can also use ${AUTOREV} variable Aug 24 14:05:19 I’m trying to get ready for Xen 4.6.0 to drop (its only at 4.6.0-rc1 right now) Aug 24 14:06:09 zwerch: well, SRCREV = "${AUTOREV}" in a layer you publish for others is generally frowned upon Aug 24 14:06:36 bluelightning: I know, but he said it's not for production Aug 24 14:07:07 zwerch: even so Aug 24 14:09:11 Well I’m looking to update meta-virtualization’s xen_git.bb to be at least 4.6.0 Aug 24 14:14:05 bluelightning: thanks Aug 24 14:29:19 Hi all ! I've got a problem with Yocto. The /sys/class/gpio directory, subdirectories and files have root:root owner:group with 744/644 rights. Do you now a way to change these for a user without use sudo. Or most simply, to add the gpio sysfs subdirectories on another group ? Thanks in advance. Aug 24 14:32:53 dcryille18: if you know which recipe is responsible for the directory (i assume one of the following http://layers.openembedded.org/layerindex/branch/master/recipes/?q=gpio) you can bbappend it and add a chroot or chmod to do_install_append() Aug 24 14:40:09 zwerch: I don't think that's going to help, this will be something generated by a kernel driver Aug 24 14:41:20 Yes, I've configured my kernel to add gpio on sysfs. But all rights are root and unexecutable by users. Aug 24 14:42:30 Do you known a way to add gpio sysfs directories on a dedicated group ? Aug 24 14:43:01 I don't, if you're asking me Aug 24 14:43:23 I suspect it's more of a generic Linux thing than specific to our system though Aug 24 14:44:01 it's possible you might be able to do it through udev, but that's really more for /dev/ nodes even if it can match on sysfs nodes Aug 24 14:51:39 Ok, thanks anyway :-/ Aug 24 14:51:50 I'm regarding to use udev :) Aug 24 16:31:36 khem: your six patch series to oe-core over the weekend appears to be missing part 2. is it in a branch somewhere? Aug 24 18:22:36 bitbake issue: I'm using the gitsm fetcher with the same URL in a number of different .bb files. Every now and then, all of the fetches of that gitsm url appear to fail in the bitbake code around where .gitmodules is retrieved Aug 24 18:22:58 It looks like a simple race: we move the git repo to grab .gitmodules, but at the same time others are trying to do similar things Aug 24 18:23:21 so the question: Is there a locking mechanism I can use in the gitsm fetcher to fix this? Aug 24 19:32:49 So this might be a weird request but is it possible to include an image within an image? Aug 24 19:33:17 Exact use case is for Xen. Building up a domU that’s then placed inside the dom0 so that I can boot the domU on startup. Aug 24 19:38:48 rburton1: hmm Aug 24 19:39:31 let me push them to a branch for ease of use Aug 24 19:42:11 Cardoe: that's exactly what hddimgs are, so yes Aug 24 19:42:33 rburton1: Aug 24 19:42:52 So I’m building up 2 but I’m not sure how to include one wholesale into another one Aug 24 19:43:11 make one image depends on the other image's do_deploy task Aug 24 19:43:22 ah Aug 24 19:43:31 then during generation you copy the image from deploy dir into the other's image's staging directory Aug 24 19:43:46 ok that makes sense Aug 24 19:44:18 rburton1: http://git.openembedded.org/openembedded-core-contrib/log/?h=kraj/for-master Aug 24 19:44:45 I have few more patches in there as well. Aug 24 19:44:57 thanks khem Aug 24 19:45:04 but thats the current list I would like to consider for master Aug 24 19:48:40 khem: can you send the new ones to the list? Aug 24 19:49:05 OK, I will create a pull request Aug 24 19:49:09 that will be easy Aug 24 20:10:07 Does it annoy anyone else that we have a boneblack machine in three different layers? Aug 24 20:13:24 er, beaglebone machine, that is Aug 24 20:27:42 * armpit should have one layer to bind them all Aug 24 20:35:10 armpit: "build them all" Aug 24 21:04:56 kergoth: it does Aug 24 21:05:38 kergoth: meta-bb is quite different it has cape support and many users still use it especially angstrom users Aug 24 21:06:07 huh, meta-ti doesnt' have cape support? Aug 24 21:06:16 kergoth: jason was to work on upstreaming that to kernel if it has happened then meta-bb wouldnt exist Aug 24 21:06:20 AFAIK no Aug 24 21:06:46 and meta-yocto-bsp is just trying to be BSP independent layer Aug 24 21:06:58 or rather vendor independent Aug 24 21:08:40 not particularly pretty Aug 24 21:09:12 nerdboy: Oh, right, I was supposed to remind you about building a trimslice BSP. Should we save that for the next hackfest/demo/whatever? Aug 24 21:09:26 I think it would be ideal if it picked machines that are fully supported in upstream components e.g. kernel toolchaine etc. and graphics too Aug 24 21:09:43 its possible for x86 only as of now reliably Aug 24 21:09:56 hmm, that does seem odd, i'd think meta-yocto-bsp would be machines that are either 100% upstream, or machines whose vendors aren't directly supporting them themselves Aug 24 21:10:10 right Aug 24 21:10:11 otherwise it's too easy to be out of sync, and add confusion Aug 24 21:10:27 may be meta-ti should just drop it Aug 24 21:10:56 but then binary graphics drivers :) Aug 24 21:11:40 ideally we shouldnt even need linux-yocto as core kernel Aug 24 21:12:14 only emulators supported upstream Aug 24 21:12:21 and some reference machines Aug 24 21:12:34 * kergoth nods Aug 24 21:12:38 kergoth: correct, meta-ti doesn't have cape support - it is coming from upstream with 4.1/4.2 Aug 24 21:12:41 linux-yocto has advantage for certain vendors which is a skew imo Aug 24 21:12:59 hmmm Aug 24 21:13:27 kergoth: and meta-yocto-bsp is indeed the reference bsp with everything that is already upstream, at least for beaglebone Aug 24 21:13:51 denix: it adds to confusion why meta-ti should also have it Aug 24 21:14:24 khem: should also have it what? Aug 24 21:15:16 bbb Aug 24 21:16:15 kergoth: reading a bit earlier - why do you say 3 layers? I only know 2 Aug 24 21:16:27 meta-ti, meta-beagleboard, and meta-yocto-bsp Aug 24 21:16:37 meta-beagleboard is long since dead Aug 24 21:16:48 if cape support is coming to 4.1 then meta-bb might be able to drop it Aug 24 21:16:49 nothing indicates this Aug 24 21:16:53 not hte readme, not the layer descriptions, nothing Aug 24 21:16:58 if htey're obsolete, someone should mention it Aug 24 21:17:05 its still used in angstrom Aug 24 21:17:11 for cape support reasons Aug 24 21:17:30 kergoth: this question is being raised every year and nothing changes Aug 24 21:17:37 I have dim hope of getting meta-beagleboard up to date, but beagleboard.org moved on to debian Aug 24 21:18:15 kergoth: https://github.com/beagleboard/meta-beagleboard - last commit was in 2013 Aug 24 21:19:21 at least koen has been doing _some_ updates to angstrom Aug 24 21:19:26 the only point of meta-bb was to carry over cape support from when it was initially developed for 3.2/3.8 until it accepted upstream. Aug 24 21:19:41 nobody estimated it would take that long, but it finally happened Aug 24 21:19:51 +1 Aug 24 21:20:32 so, there's no reason to keep on dragging it further Aug 24 21:21:53 if it has landed in 4.1 upstream then I agree Aug 24 21:23:39 cape support is rather very unorthodox... Aug 24 21:25:11 there were large set of users of it so you just couldnt throw it out Aug 24 21:25:55 well, many peripherals on modern SOCs are unusual, really, with all the accelerators, engines and other heterogeneous cores... Aug 24 21:27:15 but, CircuitCo/koen picked up cape support and the rest was picked up by TI... Aug 24 21:28:04 since then panto continued working to get it upstream, which is pretty much there with 4.1/4.2 Aug 24 21:28:51 and TI also contributed a lot to upstream, that's why meta-yocto-bsp can do basic BBB support from pure mainline Aug 24 21:29:46 yes, however, it would be good if we could really pick up ko kernel and build it Aug 24 21:29:57 for ref BSP Aug 24 21:30:26 khem: and why you can't? Aug 24 21:30:44 you can, I am talking about recipes from meta-yocto-bsp Aug 24 21:31:14 same for qemu machines in OE-Core Aug 24 21:31:31 khem: meta-yocto-bsp does use pure ko kernel at least for bbb Aug 24 21:31:42 isnt it linux-yocto ? Aug 24 21:31:50 as far as I understand it, you can do that in master (or if not yet, will be able to soon) Aug 24 21:32:04 khem: at least that's what I pushed back in 3.14 days - it was pure mainline Aug 24 21:32:08 thats good Aug 24 21:32:12 master has the metadata (config fragments) and constructed linux-yocto separated.. so they can be used independently Aug 24 21:32:23 khem: linux-yocto is just a wrapper Aug 24 21:32:25 and linux-yocto is pretty much KO.. Aug 24 21:32:39 I was talking to some kernel devs at plumbers and they said linux yocto was a fork Aug 24 21:32:57 it's like anything else.. KO + patches.. Aug 24 21:33:08 but the patches are targeted to boards, features, etc.. Aug 24 21:33:11 but if its ko/linux-stable thats good to hear Aug 24 21:33:14 if you don't want hte patches you don't need them Aug 24 21:33:19 it's LTSI AFAIK Aug 24 21:33:25 khem: different machines can add patches in linux-yocto, but in 1.6 there were no patches for bbb Aug 24 21:33:50 denix: thats what I was eluding too Aug 24 21:33:50 denix, that matches my understanding.. Aug 24 21:34:01 build ko kernel w/o patching Aug 24 21:34:15 which is true upstream Aug 24 21:34:18 yes.. and separating the metadata (kernel config) and the kernel source in (again I think master) allows that Aug 24 21:34:25 in my little experience, there is a long way to go in order to convince joe kernel developer to use linux-yocto Aug 24 21:34:37 it just means if you try to enable kernel configs that don't exist upstream you get stopped Aug 24 21:34:53 I had to revert back to ko, back on popular request :/ Aug 24 21:34:56 ant_home: they dont bother unless you talk ko Aug 24 21:35:02 khem: it does no patches for bbb. but linux-yocto wrapper was the requirement for oe-core/meta-yocto-bsp Aug 24 21:35:12 ant_home, the issue is most developers don't support 1000 combinations.. so they don't see the immediate need that is solved Aug 24 21:35:45 (and I'm not kidding when I talk about 1000 or more combinations) Aug 24 21:35:45 afaik linux-yocto's main advantage is maintainance of multiple bsps in a single tree with support for flowing common changes into them all. i've seen similar tools developed internally at companies. so your average developer probably *wouldnt'* see the ned Aug 24 21:35:49 fray: OE doesnt do that either Aug 24 21:36:03 honestly I can only talk about old unsupported hw, maybe for new stuff it is different Aug 24 21:36:04 it enables someone to doso Aug 24 21:36:06 but for companies stuck on the bsp treadmill, such things are useful Aug 24 21:36:08 khem: and due to linux-yocto complexity I had to add linux-mainline recipe, but I fail to update it regularly... :) Aug 24 21:36:14 doesnt mean it should be default Aug 24 21:36:49 I was bantered by every dev to whomeever I said to use linux yocto Aug 24 21:36:58 denix, then have a conversation with all of the board manufacturers out there and tell them to start working upstream.. :P Aug 24 21:37:25 the risk with linux-yocto is to get stale .bbappend...it happened to me twice... Aug 24 21:37:31 I don't think the KO developers understand that it's KO + patches.. what they often think is that it's a hacked up kernel.. Aug 24 21:37:47 fray: they dont want to Aug 24 21:37:50 ant_home, that is why the recommended method is reference clones.. Aug 24 21:38:06 i don't think those two are mutually exclusive. KO + patches can be pretty hacked up, dependign on what those patches are up to Aug 24 21:38:06 the you loose the updates... Aug 24 21:38:14 khem, thats fine.. and part of the reason the metadata was split form the kernel sources Aug 24 21:38:28 for reference machines we should just have ko I am convinced Aug 24 21:38:32 kergoth, I consider the end results to be possibly hacked up.. but it's a lot cleaner way to handle it Aug 24 21:38:54 agreed. Aug 24 21:38:57 you can at least see and unwind the hacks.. vs a lot of the board vendor kernels which are just tarballs of crap Aug 24 21:38:57 some even did not trust out UAPIs Aug 24 21:39:14 who knows how OE patches the kernel UAPIs Aug 24 21:39:20 was the response Aug 24 21:39:23 git log Aug 24 21:39:24 :) Aug 24 21:39:40 part of the reason that it was done the way it was.. make things transparent to anyone who can use git Aug 24 21:39:45 vs .. "tarball of crap" Aug 24 21:41:34 kergoth: I see linux-yocto is good for OSVs or platform folks thats ok Aug 24 21:41:59 but ODMs dont have 1000 machines Aug 24 21:42:02 khem, customers I've talked to that work with more then 1 platform on a common base.. they really like it Aug 24 21:42:03 they usally have 2 to 4 Aug 24 21:42:21 fray that base could be linux-stable Aug 24 21:42:30 These are customers who make common 'software' for usually 2-10 different boards... (often different architectures) Aug 24 21:42:43 yes I am in same boat Aug 24 21:42:58 but for the guys working on a project with -1- board.. they don't like the overhead.. until they understand that the configuration patching is useful.. Aug 24 21:43:15 but usually they "get" it after the project is nearly done and they are down chasing problems in patches or trying to resync Aug 24 21:45:38 the benefits of kern-tools and config checks are out of discussion. The 'dark' part are the common patches, not immediate to find (I was told so) Aug 24 21:46:31 well the common base is KO for all.. but with that said, the split of meta-data and source should be making it easier to see.. Aug 24 21:46:56 before being intermingled had the effect of confusing people cause they saw a branch and thought it was the whole tree.. where it was just a fragment Aug 24 21:47:05 so in the end I don't dare to send patches upstream based on linux-yocto... Aug 24 21:47:28 I don't think anyone has ever said linux-yocto should be the basis of KO work Aug 24 21:48:11 not only for linux-next, even for stable Aug 24 21:48:34 So I have new-pseudo probably ready for more thorough testing. I am sort of going to recommend that we NOT enable the extended attribute database code by default yet, but it might be a good bet for autobuilds. I'd want a lot more burn-in time before using it in production. Aug 24 21:50:05 with raspbian's success on rpi I still think cross compiling is still a voodoo and no matter how slow the machine is people still like feed based distros Aug 24 21:50:31 well I don't think it's voodoo, but I know some people do.. Aug 24 21:50:38 and feed based distros can easily be done with OE Aug 24 21:50:47 fray, in the case of new devices, with more than 1-2 active developers, it probably does make sense to invest in linux-yocto :) Aug 24 21:50:48 fray: it should be possible for upstream work Aug 24 21:50:52 (if my talk had been accepted, I'd have talked about it at ELC) Aug 24 21:51:02 OE is at that point where it should start fixing packages upstream Aug 24 21:51:27 khem, that was the point of the upstream-status.. but frankly the resources to "force" it up is not there.. Aug 24 21:51:43 and often the stuff is ignored by upstream (still) because they just don't care Aug 24 21:52:10 or it's not even maintained anymore Aug 24 21:52:11 heh Aug 24 21:52:15 ya that too Aug 24 21:52:34 but reality is that people try.. but once you 'try' once.. things fall away quickly Aug 24 21:52:50 it's the laziness factor.. it's easier to contribute to OE then 1000 upstream projects.. Aug 24 21:53:14 and with there being realistically only about a dozen maintainers within the OE world.. it's hard to convince people to contribute back to the 1000 upstreams Aug 24 21:53:35 I should do a better job of it. I can't push stuff during crunch time, but when we work on a new release and i start pushing my backlog up to oe-core, i should push more direct to upstream at that time Aug 24 21:53:37 I don't mean for that to be an excuse, just reality.. something we need to keep working to improve.. (yocto project and OE) Aug 24 21:53:57 kergoth, thats what our guys are told to do.. Aug 24 21:54:14 if we really have to improve on quality then this should be must, sometimes upstreams fixes the issues properly for things which we carry patches which may be workarounds etc. Aug 24 21:54:22 -everything- goes to OE, no exceptions.. upstream (above OE) when there is time.. exceptions being bintuils/gcc/kernel.. those always go back (if applicable) Aug 24 21:54:48 happily now and then it just happens upstream devs are lured by some OE patches and get interested in OE Aug 24 21:55:07 we occasionally carry something through multiple releases, but it's usually when we know it belongs in oe-core, but it has to be completely reworked to be suitable there, so the hack stays local for a while Aug 24 21:55:14 I think devtool will help in component development and upstreaming effort Aug 24 21:55:15 heh Aug 24 21:55:24 devtool modify -x is pretty sweet Aug 24 21:55:48 devtool stuff is still on my TODO list.. :/ Aug 24 21:55:50 * kergoth devtool create-workspace; recipetool kernel_set_configs workspace CONFIG_USB_G_MULTI_CDC=y; bitbake virtual/kernel Aug 24 21:56:08 +1 Aug 24 21:56:35 kergoth: why recipetool is not a subsystem of devtool ? Aug 24 21:57:07 not sure, paul would be the one to ask about the separation Aug 24 22:01:51 khem: btw, about glibc, it seems buildroot carries some mips patches (not upstreamed) so that the two fine developers I'm trying to convert to OE/Yocto are still hesitating Aug 24 22:03:37 OK which ones Aug 24 22:03:40 we can convert them Aug 24 22:03:43 MXU simd Aug 24 22:04:19 also binutils iirc Aug 24 22:04:39 I think the real question is what do the patches do, what cores do they affect.. :) Aug 24 22:04:44 best would be someone from Imgtek jump in... Aug 24 22:04:55 I've seen some really nasty glibc patches in some other systems I'd hesitate to generically include Aug 24 22:05:50 (I'm thinking of some "not to be named" vendor who makes a certain SDK... ) breaking gcc behavior to eek out a slightly better artificial benchmark is a BAD way to go about life Aug 24 22:06:27 what you want predictable sign extensions?! na.. Aug 24 22:11:09 yikes Aug 24 22:33:42 Anyone feel like poking at https://github.com/openembedded/bitbake/compare/openembedded:master...kergoth:shallow-git-mirror-tarballs ? I could use testers other than myself to check sanity Aug 24 22:57:39 hmm, i should probably split the general bb.fetch bugfixes from the git shallow support for easier review Aug 24 22:57:52 * armpit knows Frey's SDK woes too well Aug 24 23:03:54 $ git diff --shortstat v4.1.6...linux-yocto-4.1/standard/base Aug 24 23:03:54 271 files changed, 61963 insertions(+), 96 deletions(-) Aug 24 23:04:02 that's a fork :) Aug 24 23:30:45 ntl: heh, indeed, that does seem substantial Aug 24 23:31:13 Hmm, wonder if we should switch to tar.xz or something for the git mirror tarballs eventually, though we'd need my multiple-mirror-tarball-support patch for compatibility Aug 24 23:46:19 thoughts on https://github.com/MentorEmbedded/meta-mentor/commit/b058cda ? Aug 24 23:54:41 hmm, afaict bitbake-whatchanged no longer works, at least it's not very effective. it changes STAMPS_DIR, but STAMPS_DIR is in some task signatures now. Aug 24 23:54:51 * kergoth looks into what's pulling it in Aug 24 23:56:49 bazel.io is pretty neat, Aug 24 23:56:59 runtaskdeps changed from ['dbdb_6.0.30.bb.do_configure:virtual:native'] to ['dbdb_6.0.30.bb.do_configure:virtual:native'] ... seriously, bitbake? Aug 24 23:57:11 RP: runtaskdeps changed from ['dbdb_6.0.30.bb.do_configure:virtual:native'] to ['dbdb_6.0.30.bb.do_configure:virtual:native'] in -S printdiff. Aug 25 00:10:45 khem: keep meaning to try it, but haven't had the time, have you played with it? Aug 25 00:14:58 kergoth: yes I have, its very fast Aug 25 00:15:06 and has java'ism Aug 25 00:15:26 but if you are able to ignore it. its pretty decent Aug 25 00:57:29 I am getting python tracebacks from bitbake starting today Aug 25 00:57:31 http://pastebin.com/et8aSUrB Aug 25 01:08:13 well, broken pipe usually means the thing on the other side exited unexpectedly. Aug 25 02:04:13 I'm new to yocto. I am building a vanilla Fido image for the Beagle Bone Black. It builds alsa-lib-1.0.28 by default, but I need alsa-lib-1.0.29. How do I go about specifying this? Aug 25 02:23:46 dhirc: you can check out stuffs from http://git.yoctoproject.org/cgit.cgi/poky/plain/meta/recipes-multimedia/alsa/ which contain alsa-lib 1.0.29 Aug 25 02:30:02 parrot1: thanks, where is the 'best' place to put the .bb recipes and how do I add them to my local.conf? Aug 25 02:30:56 hmm.....not really sure if you can work with just alsa-lib being 1.0.29 while the rest is 1.0.29 Aug 25 02:31:19 I would suggest creating a new meta layer and dump the new recipes there Aug 25 02:37:00 gholms: that's the plan... (sjl noticed too ;) **** ENDING LOGGING AT Tue Aug 25 02:59:58 2015