**** BEGIN LOGGING AT Fri Nov 24 03:00:03 2017 Nov 24 04:18:05 wolfmitchell: I do see the slow down but I don't see the cause. You can grab from git://git-new.yoctoproject.org/poky (git protocol only) if you'd like to test that. Nov 24 04:18:37 Mmk, I'll try it when I get a chance to, not working on that project rn so... Nov 24 04:42:58 There are several fast connections pulling from that server. It doesn't appear to be anything malicious. Nov 24 08:08:25 good morning Nov 24 08:08:55 anybody seeing mouse problems while using fedora 26/27 with gnome-shell on xorg? Nov 24 08:09:25 it feels like the movement communication is lost and sometimes the mouse cursor does not move at all Nov 24 08:10:13 i have replaced one wireless mouse only to find that the problem was not the mouse Nov 24 08:10:24 in windows 8 on same computer works fine Nov 24 08:10:51 grrrr Nov 24 08:10:55 wrong chat :( Nov 24 08:11:15 apologies Nov 24 08:21:51 hello friends Nov 24 08:23:30 how do we solve ExpansionError during parsing, The issue is in meta-openembedded meta-ruby recipe. Nov 24 08:24:29 grokreality: this is appearing when doing what? you have checked that you are not mixing branches? on which recipe? Nov 24 08:25:00 its for the beagleboard xM (meta-ti) using daisy branch. Nov 24 08:25:53 erps Nov 24 08:26:06 that is about as outdated as possible Nov 24 08:26:13 doing bitbake core-image-minimal Nov 24 08:26:37 so besides the advice to check everything is equivalently on daisy... well... maybe upgrade? ;-) Nov 24 08:26:50 which is daisy branch...which do you think would be a better branch. plz help. Nov 24 08:27:05 i mean is daily branch outdated? Nov 24 08:27:29 grokreality: https://wiki.yoctoproject.org/wiki/Releases Nov 24 08:27:35 grokreality: daisy is 3.5 years old Nov 24 08:28:11 thanks for the advice...i was just following instructions from a n old blog... Nov 24 08:28:25 plus, beagle-xm is alsmost equivalently outdated and unsupported Nov 24 08:28:38 oh. :( Nov 24 08:28:59 just wanted to start with yocto and have this hardware around... Nov 24 08:29:25 you can easily start with openembedded without hardware, we have reasonably good qemu support Nov 24 08:29:51 but the beagle-xm is really a bad choice Nov 24 08:31:29 grokreality: you can try about everything in qemu, just follow the yocto quick start guide. it also makes sure you don't run into problems with pesky hardware etc. Nov 24 08:43:23 Hi everyone, do you know if we can override / with overlayfs if / is already mounted ? something like mount -t overlay ofs / -o lowerdir=/,upperdir=/data/overlay/,workdir=/data/work/ Nov 24 08:44:31 Probably possible at least in a mount namespace, unless your kernel doesn't allow overlayfs in mount namespaces Nov 24 08:47:23 Thank you so much Leto...:) Nov 24 08:49:04 grokreality: have fun Nov 24 08:49:14 :) Nov 24 08:49:28 nayfe: maybe you can leverage some ideas from this: https://spin.atomicobject.com/2015/03/10/protecting-ubuntu-root-filesystem/ Nov 24 09:00:51 LetoThe2nd> it should work with a separate partition for /boot and then mount rootfs partition to /readonly ... i'll probably try to mount only rootfs parts instead of all :p for example in ROOTFS_POSTPROCESS_COMMAND move /etc to /etc-ro and mount /etc with overlayfs .. Nov 24 09:59:20 New news from stackoverflow: Build yocto project on entirely encrypted ubuntu Nov 24 10:29:24 New news from stackoverflow: iMX27: Embedded Linux size to Run QT || YOCTO how to create a basic ubuntu 16.04 linux Nov 24 10:36:04 ok so use overlayfs directly for / is not working but for /etc it is working ( mount -t overlay ofs /etc -o rw,lowerdir=/etc,upperdir=/data/overlay/etc,workdir=/data/work/etc ) (mountpoint same as lowerdir) Nov 24 10:46:42 The recipe license for python3-pycairo is LGPLv3 in poky. Is this correct? On github it says it is 'licensed under the LGPLv2.1 as well as the MPLv1.1.' Nov 24 10:56:26 Suppose I want to be able to build 3 different types of images: factory (everything including bootloader and some other stuff), update (just a new kernel and rootfs partition) and SD (my bootloader will choose to load the SD kernel), how should I specify which type I want to build in Yocto? By adding a DISTRO_FEATURE? 3 different image recipes? Other command line variable? What is the best practice? Nov 24 10:57:54 ;2CD Nov 24 11:15:49 Hi! I'm having issues (`tar: ./source/foobar: file changed as we read it`) with concurrent use of a SVN source repository by multiple recipes. Shouldn't bitbake lock it? If it does not: How can I force recipes to be not build in parallel? Nov 24 11:16:29 what task is causing that error? Nov 24 11:21:33 rburton: I think it's two seperate recipes sourcing the same svn repository Nov 24 11:24:35 T_UNIX: https://p.dnnr.de/as4o5ENsYqzEGyqq Nov 24 11:25:23 No idea of what the status getting this merged upstream is or whether that patch even applies anymore, I'm just dumping what we've done to solve this issue Nov 24 11:27:05 neverpanic: thanks :) Nov 24 11:27:44 T_UNIX: if this works for you, I'd welcome if you cleaned it up and submitted it upstream Nov 24 11:28:35 neverpanic: well I'm not even sure this will be an issue for us at all in the near future since we're migrating from SVN to git :-/ Nov 24 11:28:59 Sure, maybe. It'll still be an issue in bitbake, even though fewer and fewer people are using SVN Nov 24 11:30:05 Actually, we did submit that: http://lists.openembedded.org/pipermail/bitbake-devel/2016-May/007499.html Nov 24 11:30:32 Turns out nothing happened, even after a ping: http://lists.openembedded.org/pipermail/bitbake-devel/2016-May/007507.html Nov 24 11:30:37 rburton: ^? Nov 24 11:34:02 :-D Nov 24 11:34:38 neverpanic: can you ensure it still applies and reping? i tend to ignore bitbake patches and let RP handle those Nov 24 11:35:42 rburton: RP == ReProducer? ;-) Nov 24 11:39:00 rburton: No time at the moment, but I'll ping somebody in our integration team to come back to it once they have time Nov 24 11:43:18 neverpanic: hmm, we should really merge something like that Nov 24 12:18:31 When a new project is started two things happen 1) Collect the layers, 2) Create the build/conf/local.conf and bblayers.conf and edit them with appropriate contents. Nov 24 12:19:33 There exists systems, such as repo to the first, but is there a tool for the second item? In particular populating the bblayers.conf, Or do we always require the user to hand-edit the two config files? Nov 24 12:20:27 sveinse: bitbake-layers Nov 24 12:24:26 thanks, that makes it scriptable Nov 24 12:54:58 kanavin: your patches to meta-selftest break the selftest. does upgrade-test1 need both upstream check uri and no update reason? surely the latter means the former is pointless? Nov 24 12:56:12 rburton: I didn't make any patches to meta-selftest lately? Nov 24 12:56:21 'meta-selftest: fix upstream version checks for devtool test recipes' Nov 24 12:56:41 ah Nov 24 12:57:07 upstream check uri is so that the recipe doesn't report that the version is unknown which improves the overall statistics Nov 24 12:57:16 no update reason is so that the tools won't attempt to update it Nov 24 12:57:38 maybe we should remove meta-selftest from checkuri runs Nov 24 12:58:03 anyway can you fix up the devtool selftest that uses those recipes? it does an upgrade and then compares the values, and they don't match anyore Nov 24 12:58:09 https://autobuilder.yocto.io/builders/nightly-oe-selftest/builds/650/steps/Running%20oe-selftest/logs/stdio Nov 24 12:58:11 rburton: that would work too or I can fix the selftest Nov 24 13:00:34 SO review system is fucked up Nov 24 13:01:12 oops Nov 24 13:03:27 rburton: i wonder who will fix the curl/dnf issue :) Nov 24 13:03:43 maybe in the end I'll have to do it because everyone else is too busy.... Nov 24 13:17:26 rburton: fixed Nov 24 13:17:35 (the selftest, not the curl :) Nov 24 13:22:16 kanavin: should there be two patches? the meta-selftest bit you've already sent. Nov 24 13:23:06 rburton: I squashed them into one - it contains both the original patch and the needed fix in the reference output for the test Nov 24 13:23:26 no it doesn't :) Nov 24 13:24:59 rburton: original patch 3 files changed, 5 insertions(+), new patch 5 files changed, 9 insertions(+) Nov 24 13:25:10 hm Nov 24 13:25:36 ah ok sorry, i was thinking it was one of the tests where the new content is in the test case itself Nov 24 13:25:38 my fault Nov 24 13:25:51 cheers Nov 24 13:26:16 :) Nov 24 13:29:57 New news from stackoverflow: Yocto / Poky : Error at build - EGL functions feature could not be enabled Nov 24 13:53:59 I'm currently experimenting with a Yocto build for an Intel FPGA SoC. I see that they setup a meta-linaro-toolchain. Why would they? Why is there a Linaro toolchain and how is it different from the one in stock Yocto/OE? Nov 24 14:04:13 Does og will Yocto have a scheme for LTS or similar? Nov 24 14:12:56 When I changed gcc for my distro (from linaro to stock yocto), I get a lot of version-going-backwards messages. However my build was clean, so this is fetched from sstate cache. How can I avoid this error? Nov 24 14:24:50 sveinse: you'll get it only once Nov 24 14:24:56 right after switching Nov 24 14:25:53 kanavin: good, thanks Nov 24 14:26:16 I would like to ask what is the biggest advantage to use native recipe to build a tool instead of using the same tool from. Nov 24 14:26:29 Do you have a link to read online about that? Nov 24 14:26:42 from host* Nov 24 14:26:59 sveinse: LTS can be purchased from commercial yocto vendors; it's simply beyond the community's capacity Nov 24 14:27:34 sveinse: you'll have to ask the fpga bsp people the linaro question Nov 24 14:27:58 Tamis_: in short, then we would know exactly what we're getting when we use that tool (or library etc.). Fighting with a zoo of desktop distributions is a major pain. Nov 24 14:28:19 Tamis_: the downside is that building the tool takes time, maintaining the recipe and its dependencies takes effort Nov 24 14:30:06 Tamis_: example: we build subversion-native because subversion had a few serious changes in behaviour where we can't cater for both at the same time. build our own, we know what we're getting. Nov 24 14:32:54 kanavin: I see. So the biggest advantage is that get the exact version and behaviour we want. Instead of fighting with what the current distro provides Nov 24 14:34:02 But with all those new tools like VM's docker's etc. Wouldn't make above consideration a little bit obsolete? Nov 24 14:34:40 only if we start shipping a VM for people to build inside Nov 24 14:34:45 which so far, we're not Nov 24 14:35:42 I see. Ok thanks. Nov 24 14:35:42 the flatpak sdk can actually run yocto inside flatpak when building Nov 24 14:35:47 to avoid odd host systems Nov 24 14:35:49 :) Nov 24 14:36:57 kanavin, rburton: thanks Nov 24 14:38:13 allthou i've never really understood what linaro adds to the table (and not just for yocto-things) ...but yes, not a Yocto question Nov 24 14:39:15 upstream work on ARM support across the Linux ecosystem - for example upstreaming and maintaining good ARM support in gcc, linux, a u-boot that actually supports multiple boards, ... Nov 24 14:39:33 it will be a sad day when VM becomes a requirement for development Nov 24 14:40:00 you can solve any problem with another indirection layer, except the problem of too many layer Nov 24 14:40:01 s Nov 24 14:40:14 :) Nov 24 14:42:05 And those indirection layers often hide real issues, too. Nov 24 14:43:31 I can vouch for that: Before we changed our product to Yocto, we used Ubuntu (they were the first to have good support for armhf back in the days). We need to use docker and maintain a container with the host tools that matches the (old) version of the target system. It's a pain to maintain. Nov 24 14:46:19 From what I see here and there, devops and build systems are using heavily VM's and dockers and those stuff. So I guess that a lot of things are moving towards there. Nov 24 14:48:28 Absolutely agree, but even those VMs and containers aren't stuck at fixed versions, so you either need to continuously test with newer containers (and then adapt your code to support both versions or drop support for the older version), or you're stuck with an old container (which is even worse) Nov 24 14:49:08 not to mention that VMs and containers have their own bugs, too Nov 24 14:50:08 qemu can be very frustrating for us, and we only use it to do (simple) testing - the image boots, ssh works, etc. Nov 24 14:53:30 Thanks for all these inputs. I am really new to all these devops things so I want to know about all those considerations. Nov 24 14:54:17 I am changing our development process to use yocto for all the image creation and those questions pop up all the time Nov 24 14:55:44 I spent quite some time to make some java apps to build using ant-native and mvn so I really wandering if those time was well spend to make the yocto tools to work instead of just install those tools to the host machine Nov 24 14:56:12 Btw, full disclosure, we're using a container for Yocto builds, too. It just takes another variable out of the equation when bugs occur. But we're also not very interested in finding every obscure bug that would make binutils or some other fundamental component fail to build. Nov 24 14:59:00 The distro feature 'multiarch', does it affect non-intel architectures? From what I can see from code when grepping, it seems not, but does it have impact on host tools? Nov 24 15:47:45 I wish bitbake would have a way to redefine a ?= value. The use case is that a machine conf includes tune-cortexa9.inc which sets DEFAULTTUNE ?=, and that the machine conf also would like to that, but with a different default value. Nov 24 16:01:11 sveinse maybe change ?= by ??= in tune-cortexa9.inc ? Nov 24 16:02:02 nayfe: which is in poky :D Nov 24 16:02:46 ???= lol :D Nov 24 16:03:28 can't you use something like DEFAULTTUNE_ override ? Nov 24 16:03:57 sveinse: you normally set the ?= value in the machine.conf before the include of the tune Nov 24 16:04:16 sveinse: lol :D, yes Nov 24 16:05:34 sveinse: not sure your problem then? ?= behaves that why on purpose ;) Nov 24 16:05:35 nrossi: That would make more sense. But grepping a little bit around, it seems the DEFAULTTUNE_ is more common? Nov 24 16:06:37 sveinse: i've never needed to set it with an override since that would break the nesting of DEFAULTTUNE Nov 24 16:07:23 e.g. if someone wants to include the machine.conf to create a derivative machine, then the override would not work Nov 24 16:07:24 nrossi: nesting? Nov 24 16:08:36 nrossi: yes, I see, but this is the case from a 3rd party machine layer. And it's certainly not the first time I've seen this Nov 24 16:09:26 The fix is that I need to fork this layer and do the appropriate reordering of the statements so that is defaults correctly Nov 24 16:10:19 sveinse: ideally yes Nov 24 16:10:56 sveinse: which/whose bsp layer is it out of query? Nov 24 16:11:33 nrossi: https://github.com/kraj/meta-altera Nov 24 16:13:26 sveinse: which machine? none of them set DEFAULTTUNE? Nov 24 16:14:56 Precicely. It instructs to set DEFAULTTUNE="cortexa9hf-neon" in local.conf, while this is a machine layer task. For the cyclone5.conf machine Nov 24 16:17:38 sveinse: not sure exactly why it doesn't set the DEFAULTTUNE, i suspect it might be to play nicer with distro settings? Nov 24 16:19:40 nrossi: perhaps. no idea. I've forked the repo and will fix it, because I don't like having to rely on large edits in local.conf Nov 24 16:20:44 sveinse: you can always do it from a distro config, like how meta-angstrom rewrites DEFAULTTUNE for arm targets: https://github.com/Angstrom-distribution/meta-angstrom/blob/12a9410dff0806bf2b57b42920d2431f592c38d5/conf/distro/include/arm-defaults.inc#L28 Nov 24 16:22:53 nrossi: yes. I used to have DEFAULTTUNE in my own distro, but it doesn't feel right to have it there. It is a BSP-thing not a distro thing Nov 24 16:24:24 sveinse: others would have you believe its the oppose :). But the choice is yours :) Nov 24 16:24:36 s/oppose/opposite/ Nov 24 16:28:15 nrossi: I suppose it depends on how one interprets "distro". For some uses, like a complete image for a speicifc product or HW, then a distro can be machine specific. While if distro is a generic collection of functionlity, then I suppose machine shouldn't be a part of that equation. Nov 24 16:28:59 I've been using both variants, depending on what the purpose of what I'm building towards Nov 24 17:56:07 I'm writing a layer setup script, and I use bitbake-layers to add the layers. First of all the tool is very slow, and in rocko I get messages "NOTE: Starting bitbake server...". Am I using the tool wrong? Nov 24 18:23:23 no, it starts bitbake to do suff Nov 24 18:23:24 stuff Nov 24 18:27:00 stuffing Nov 24 19:18:39 rburton, I started a built on .io AB. if you need it for mut, you can kill it Nov 24 19:41:59 thats fine, i'll just fire and let it run over the weekend Nov 24 19:46:48 the original ab has hung but RP want me to look at it but I still don't have access Nov 24 19:47:22 rburton, have a good weekend Nov 24 19:56:35 rburton: it is horribly slow thou. 40 secs per invocation of bitbake-layers. Takes time if you are manipulating 7 layers :( Nov 24 20:49:18 I see that yocto now has the multiconfig feature. The manual sais "You can change the TMPDIR to not conflict" when setting up the multiconfig. But you don't have to make not conflict, but you /can/, right? Nov 24 20:50:53 We're currently running bitbake three times in a row with three different MACHINE, since the basic arch is the same for all of these. So to adopt to multiconfig I only need to set MACHINE in the config file and I should be all set Nov 24 22:02:59 sveinse: yep, it's entirely safe to build multiple machines in a single tmpdir, it's other configuration changes that are more problematic Nov 25 00:41:16 Is this a bug: "ERROR: libgcc-7.2.0-r0 do_packagedata: QA Issue: Package version for package libgcc went backwards which would break package feeds from (0:linaro-7.1-r2017.08 to 0:7.2.0-r0) [version-going-backwards]" Nov 25 00:43:01 afaik 7.2.0-r0 is newer than linaro-7.1-r2017.08, not the other way round. Perhaps the lexical comparison ruins the comparison? **** ENDING LOGGING AT Sat Nov 25 03:00:01 2017