**** BEGIN LOGGING AT Tue Nov 29 03:00:01 2016 Nov 29 09:10:40 is there some kind of "know working/recommended" way of building stuff from different repositories/branches with one recipe ... so I can achieve something like ... bitbake myImage/myImge_devel using the same recipe but once the devel branch and once master? Nov 29 09:15:50 hm wouldn't be a distro feature be the right thing to do that? Nov 29 09:18:38 you can use bb.utils.contains('DISTRO_FEATURES', 'development-build', , , d) Nov 29 09:21:27 mdnneo: but i dont really know if thats how its done Nov 29 09:30:41 fl0v0: currently I somehow miss the link between image and distro but sounds like a plan ... I will give it a try Nov 29 09:32:21 mdnneo: do you have multiple recipes where you want to change the SRC? Or is it just the collection of packages that is different? Nov 29 09:33:18 fl0v0: multiple packages ... but I could arrange them as packagegroup as well Nov 29 09:33:18 If it is the latter you could also use you could also use IMAGE_FEATURES Nov 29 09:34:40 so in multiple recipes you change the SRC from branch master to develop? Then think you have to use the DISTRO_FEATURES variable. Nov 29 09:34:42 fl0v0: ... can I have custom IMAGE_FEATURES? and how can I check them then? Nov 29 09:36:48 fl0v0: just figured out we have a DISTRO per machine so most likely the DISTRO_FEATURE matches pretty well my use case Nov 29 09:38:12 as far as i understood it, image features are handled in the image recipe only. You can look in the image.bbclass and look what "debug-tweaks" does for example Nov 29 09:38:38 yes image features are by definition only relevant at image generation time Nov 29 09:38:46 you can have custom ones though, easily Nov 29 09:38:57 ah ok ... then I have a problem ... would need to have something per recipe Nov 29 09:39:31 mdnneo: but DISTRO_FEATURES should work Nov 29 09:39:33 -> distro feature, or just a variable you can set in your local.conf/whatever. Nov 29 09:44:02 I'm developing an image that needs to be GPLv3 free (tivoization problem). I used the INCOMPATIBLE_LICENSE variable to exclude GPLv3. But there is still libstdc++.so and libgcc. To my understanding i cant have those in the image either or the tivoization clause applies. I think i need to statically compile the libs into the runtimes. Has anybody already solved that problem? Nov 29 09:51:26 fl0v0: arent they LGPL3.0 and like this not that strict? Nov 29 09:52:23 yes they have a exception, that you can link against them without having to gpl your code Nov 29 09:53:05 But the anti-tivo clause is another thing Nov 29 09:54:24 fl0v0: ah ... got it ... heard of it first time ... but good to know Nov 29 10:29:40 fl0v0: The exception would apply and should work for you, but IANAL Nov 29 10:55:44 neverpanic: the topic is at least controversal: https://lwn.net/Articles/600210/ Nov 29 10:57:42 fl0v0: That's a topic you should ask you lawyer. I'm not qualified to help you with that, and it would be unethical. Nov 29 10:58:45 yeah no problem :) just wanted to give the article Nov 29 10:59:02 i think many embedded developers are not aware of this problem Nov 29 10:59:20 Thanks. I've looked at this in detail and my laywers have discussed this, but yours may very well come to a different conclusion. Nov 29 10:59:29 ah ok Nov 29 10:59:42 well thats good to hear Nov 29 11:00:16 thank you Nov 29 11:04:26 can I use pattern expression with _remove ? Nov 29 11:09:00 hi. building recipe with bitbake, getting sources from svn. it gives svn the option -no-auth-cache. How do I disable that option, ie. enable auth cache use? or if this is not possible, how should I give login info for svn checkout? Nov 29 11:13:45 hyde: use ~/.subversion/config and/or ~/.netrc Nov 29 11:21:25 binarym: thanks. at least .netrc didn't work. I created the file, added line: machine svn.server.com login me.here password abcd1234 Nov 29 11:22:15 in log.do_fetch there is no indication that this info was used Nov 29 11:34:01 ah ha, I wrote do_fetch myself, and it uses svn command from the build env, instead of the OS one. Nov 29 11:48:51 aV_V: No Nov 29 11:56:02 neverpanic: ok Nov 29 11:56:11 ty Nov 29 13:17:07 anyone ever used the etnaviv driver in a yocto image? Nov 29 13:22:26 graphiqs: AFAIK etnaviv is not supported in the standard NXP/FSL kernel Nov 29 13:23:45 using 4.8x+fslc Nov 29 13:34:31 graphiqs: 4.8 is not in meta-fsl-arm Nov 29 13:39:46 I know it isn't, didn't ask if it is supported though Nov 29 13:40:48 hi guys Nov 29 13:42:14 is there any way, in a do_install of a recipe, to chown with a user that has been created by another recipe? because i'm getting log_check: warning: user xxxx does not exist - using root Nov 29 13:49:28 Hi guys. is there an easy way to bridge local internet/ethernet with the runqemu script Nov 29 13:49:44 I tried doing a runqemu path_to_image slirp Nov 29 13:49:48 but didn't work Nov 29 13:59:50 hi@all, i am having problems with building crosssdk-gcc and cross-canadian-gcc, if both are different versions (e.g. crosssdk-gcc is vanilla gcc 4.8 and cross-canadian-gcc is linaro), only one source is fetched via gcc-source dependency Nov 29 14:00:32 so one version will not build properly, any ideas how to fix this Nov 29 14:02:54 graphiqs: you could try https://github.com/d4ddi0/meta-etnaviv perhaps? Nov 29 14:15:04 Has anyone here tried chromium from meta-browser with morty? Every tab opened crashes with "Aw, Snap!" and I was just curious if it was generally broken or something specific to my platform/environment. Nov 29 14:15:22 krogoth works Nov 29 14:15:51 tlwoerner: looks promising, thanks Nov 29 14:22:49 georgem: it's related to glibc Nov 29 14:23:17 tlwoerner: ah, ok. so newer glibc break it? Nov 29 14:23:43 georgem: i was able to get chromium working fine with 2.23, but was never able to isolate the problem with 2.24 Nov 29 14:24:15 tlwoerner: okay, thanks. at least that gives me somewhere to start if I decide to pursue it. Nov 29 14:24:41 in OE, updating from glibc-2.23 to glibc-2.24 jumps lots of commits in between. my hope was to bisect those commits to see if i could narrow it down Nov 29 14:25:37 i had a hacked-up build where i was using master but replacing glibc with 2.23. it built, and ran. the only problem was generating the (e)SDKs (which failed) Nov 29 14:26:07 with those massive build times and (in my case) long downloads it was a slow process :-) Nov 29 14:27:05 georgem: some people using freescale devices noted that if the content you wanted was loaded from the cmdline and you didn't play with the tabs, it would work (I think they said it was stable) even with glibc-2.24 Nov 29 14:27:13 tlwoerner: https://bugzilla.redhat.com/show_bug.cgi?id=1361157 Nov 29 14:27:14 Bug 1361157: was not found. Nov 29 14:27:25 silly yocti Nov 29 14:28:40 I'll look into it more and see if their patch actually fixes it. May not be the same thing. Nov 29 14:31:16 Ah. that might make sense since I'm using a 4.4 kernel. Nov 29 14:31:35 georgem: great! nice to see the bug exists elsewhere (it's not just me!) and that it's not just chromium (qtwebengine too?) Nov 29 14:32:19 i had also wondered if maybe a newer chromium would fix the issue too Nov 29 14:40:27 does anybody know about the state of qtquickcompiler recipes? The one I found in the meta-boot2qt layer references a qt internal git repository :-/ Nov 29 14:40:49 I have a commercial license. It's just about the packaging, so to say Nov 29 19:28:26 tlwoerner: That patch fixed the chromium issue. I guess I'll send a patch to meta-browser to the openembedded-devel list. Nov 29 20:00:03 georgem: awesome! :-D Nov 29 20:31:00 halstead: are you around? Nov 29 20:31:27 lamego, Yes. Nov 29 20:31:56 Hi, this is regarding Paul's request for the git hook to be enabled for meta-oe Nov 29 20:32:14 halstead: have you look at it? Nov 29 20:32:43 halstead: it requires to add login info at the .pwclientrc file in the production instance Nov 29 20:32:57 halstead: for meta-oe project Nov 29 20:33:23 halstead: oe project, I meant Nov 29 20:33:48 lamego, Can we just add another section to .pwclientrc for meta-oe? Nov 29 20:34:48 yes, the [oe] section with appropriate username/password. Just not sure if the [default] section should be commented out. Nov 29 20:36:21 lamego, Here is what we have currently, https://paste.fedoraproject.org/493426/45176714/ Nov 29 20:38:14 halstead: correct, the oe section should do the job, but given that it is not, I'm wondering if we should take out the "default" section Nov 29 20:38:39 lamego, So delete the [options] section and see what happens? Nov 29 20:38:46 halstead: maybe we could test at patchwork-staging Nov 29 20:40:50 anyone know why there are dupes in the layerindex search results? i.e. https://layers.openembedded.org/layerindex/branch/master/recipes/?q=binutils — the 2.17.50.0.12 binutils in meta-mel-support is in the results table twice, linking to the exact same recipe id Nov 29 20:42:11 halstead: question: since the git hook is triggered at the production server, could we have configuration for both instances simultaneously? I mean having both the url to production and staging for each project? Nov 29 20:42:15 I don't but I remember an e-mail awhile back about how to report duplicates. Nov 29 20:42:35 lamego, We do! Nov 29 20:43:27 lamego, Actually we have two.. one pointed at https://patchwork.openembedded.org/xmlrpc/ and the other pointed at http://patchwork-prev.openembedded.org/xmlrpc/ Nov 29 20:43:49 lamego, I can update to point at the staging site instead of the archive site. Nov 29 20:46:30 halstead: I see. It is actually updating both of those instances, so that would be a good way for us to track that feature too. Now, returning to P's request, we can try removing the options section **** ENDING LOGGING AT Wed Nov 30 03:00:00 2016