**** BEGIN LOGGING AT Thu Nov 22 02:59:58 2018
Nov 22 03:27:21 <yocti> New news from stackoverflow: Connect Arduino to local MQTT broker using loopback <https://stackoverflow.com/questions/53423414/connect-arduino-to-local-mqtt-broker-using-loopback>
Nov 22 06:05:28 <Dvorkin> I have a problem applying patches to yocto-linux kernel tree. I'm getting "Patch needs to be refreshed ... .git/rebase-apply/resolve_rejects". I know the patch is nice
Nov 22 08:58:21 <yocti> New news from stackoverflow: Yocto Bitbake Glibc Build Fails <https://stackoverflow.com/questions/53426734/yocto-bitbake-glibc-build-fails>
Nov 22 09:11:30 <ernstp> I think I ran into https://bugzilla.yoctoproject.org/show_bug.cgi?id=12107 and have a pretty good solution...
Nov 22 09:11:31 <yocti> Bug 12107: normal, Medium, 2.7, JPEWhacker, NEW , useradd-staticids: groupadd: GID already exists
Nov 22 09:32:48 <ernstp> or maybe not...
Nov 22 09:36:28 <ernstp> hi rburton, ran into  https://bugzilla.yoctoproject.org/show_bug.cgi?id=12107 , trying to build a solution...
Nov 22 09:36:29 <yocti> Bug 12107: normal, Medium, 2.7, JPEWhacker, NEW , useradd-staticids: groupadd: GID already exists
Nov 22 09:38:22 <ernstp> so for example my dbus recipe fails, because it has an old etc/group in it's sysroot, and do_prepare_recipe_sysroot: Skipping as already exists in sysroot: ['base-passwd', bla bla... ]
Nov 22 10:32:54 <rburton_> hm
Nov 22 10:33:05 <rburton_> RP: just realised that HOSTTOOLS and BUILD_CC conflict
Nov 22 10:33:21 <rburton_> if the user sets BUILD_CC to something like gcc-8 then that won't be in the path
Nov 22 10:33:22 <RP> rburton_: in what way?
Nov 22 10:33:34 <RP> rburton_: right, you'd have to tweak both
Nov 22 10:34:10 <RP> rburton_: I'm now thinking "a-quick" and "a-full" so the UI works better fwiw
Nov 22 10:34:19 <RP> not ideal but
Nov 22 10:34:27 <rburton_> presumably there's no hidden sort-key tag
Nov 22 10:35:05 <RP> rburton_: there could be but I kind of doubt it and I'm not in the a mood for a day of playing with coffeescript :/
Nov 22 10:36:46 <RP> I'm getting worried about supporting the older releases with all these changes. I guess I finish piling stuff in and then try and sort it out...
Nov 22 10:44:14 <RP> rburton_: is -next ok?
Nov 22 10:44:36 <RP> rburton_: clean build apart from missing maintainer which I fixed
Nov 22 10:57:12 <rburton_> RP: -next isn't based on master
Nov 22 10:58:05 <RP> rburton_: it is now
Nov 22 10:58:17 <rburton_> :)
Nov 22 10:58:56 <RP> (was a couple of bitbake tweaks different)
Nov 22 11:00:14 <rburton_> huh the buildhistory git repo is huge, even a week of commits on just one branch is quite a lot to fetch
Nov 22 11:00:50 <RP> rburton_: its why I was wondering if we get it to summarise in the results
Nov 22 11:00:56 <rburton_> yeah
Nov 22 11:00:59 <rburton_> would be useful
Nov 22 11:01:42 <RP> rburton_: I'm limiting build history to just qemu* going forward btw
Nov 22 11:02:21 <rburton_> do you have 12f1b114db4ec4952aed8131e5f88c3e6e559659 in your poky clone?
Nov 22 11:02:39 <RP> rburton_: yes
Nov 22 11:02:45 <rburton_> what is it?
Nov 22 11:03:00 <rburton_> that's what the buildhistory last did but i don't have that sha
Nov 22 11:03:59 <RP> rburton_: http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=rpurdie/for-ross
Nov 22 11:04:20 <rburton_> huh
Nov 22 11:04:37 <RP> rburton_: buildhistory was a bit unreliable as not all the workers had the right ssh access but michael is working on fixing that (I think he may have done so)
Nov 22 11:04:58 <rburton_> might explain why that sha doesn't bare much relation to current net
Nov 22 11:04:59 <rburton_> next
Nov 22 11:05:11 <RP> rburton_: no, that wouldn't explain that
Nov 22 11:05:24 <RP> it just explains why some branches were updating and others weren't
Nov 22 11:05:37 <rburton_> yeah i just fetched origin/poky/master-next/nightly-x86-64
Nov 22 11:06:01 <RP> rburton_: ah, it would explain why it was perhaps missed on the last -next
Nov 22 11:06:38 <RP> rburton_: oh, last -next used the new names
Nov 22 11:06:48 <rburton_> of course!
Nov 22 11:07:08 <rburton_> erm should ross/mut be pushing to the buildhistory repo?
Nov 22 11:07:18 <RP> rburton_: sure, we configured it to
Nov 22 11:07:24 <rburton_> ok, just checking
Nov 22 11:07:53 <RP> rburton_: http://git.yoctoproject.org/cgit.cgi/yocto-autobuilder-helper/tree/config.json#n10
Nov 22 11:08:30 <RP> rburton_: that basically says ross/mut is to be a rebased history against the last poky master
Nov 22 11:08:52 <rburton_> right
Nov 22 11:09:17 <rburton_> you can delete for-ross now
Nov 22 11:09:53 <RP> rburton_: gone :)
Nov 22 11:10:26 <RP> rburton_: care to glance over http://git.yoctoproject.org/cgit.cgi/yocto-autobuilder2/tree/config.py#n41 - the split between quick and full
Nov 22 11:10:52 <RP> rburton_: btw, the UI displays "Start a-full Build" which is quite nice :)
Nov 22 11:11:57 <rburton_> haha
Nov 22 11:16:21 <rburton_> oddly i'm seeing openssl changing in the buildhistory
Nov 22 11:16:33 <rburton_> packages/core2-64-poky-linux/openssl/openssl-engines: FILELIST: added "/usr/lib/engines-1.1/afalg.so"
Nov 22 11:17:20 <RP> rburton_: that seems strange :/
Nov 22 11:17:23 <rburton_> yeah
Nov 22 11:18:24 <rburton_> apart from that reviewing the buildhistory from the ab was good
Nov 22 11:18:28 <rburton_> yeah merge away
Nov 22 11:18:32 <rburton_> shall quickly look at openssl
Nov 22 11:20:20 * rburton_ starts to giggle manically at what he suspects is happening
Nov 22 11:20:26 <rburton_> coffee first :)
Nov 22 11:41:52 <RP> rburton_: curious now!
Nov 22 12:14:08 <rburton_> RP: openssl doesn't think its cross-compiling so it looks at the host kernel version to decide whether to build this module
Nov 22 12:17:55 <RP> rburton_: oh dear :/
Nov 22 12:18:03 <RP> yay buildhistory though
Nov 22 12:18:20 <RP> and rburton_++ for spotting it :)
Nov 22 12:18:28 <rburton_> of course, tell it we're cross compiling and it just force-disables that modue
Nov 22 12:18:29 <no_such_user> Hiya... I'm trying to put together a workflow for managing multiple projects - I'm using wiki.yoctoproject.org/wiki/TipsAndTricks/TeamWorkflows as a starting point as it seems sensible. It references http://sstate.yoctoproject.org/ and http://downloads.yoctoproject.org/mirror/ - is there any info about how these are populated or any publicly available scripts that show that?
Nov 22 12:22:49 <RP> rburton_: 37 minute oe-selftest with hot sstate!
Nov 22 12:22:56 <rburton_> !
Nov 22 12:22:58 <rburton_> lies
Nov 22 12:23:16 <RP> rburton_: now we can run per distro we can compare speed too
Nov 22 12:23:50 <RP> rburton_: sorry, 34 mins: https://autobuilder.yoctoproject.org/typhoon/#/console
Nov 22 12:24:00 <RP> er, https://autobuilder.yoctoproject.org/typhoon/#/builders/86/builds/1
Nov 22 12:24:28 <RP> athough we do seem to be skipping signing tests when we shouldn't be
Nov 22 12:27:24 <RP> rburton_: I still have mingw to think about on the AB, anything else I need to tweak whilst I'm thinking about it? I added ptest. I guess maybe other layers?
Nov 22 12:29:04 <yocti> New news from stackoverflow: Error: cannot register alternative groups while executing bitbake rootfs command <https://stackoverflow.com/questions/53430878/error-cannot-register-alternative-groups-while-executing-bitbake-rootfs-command>
Nov 22 12:29:12 <rburton_> RP: yes, but what layers i'm not sure yet
Nov 22 12:40:57 <OutBackDingo> rburton_: i thoughht thhis was fixed ?  openssl:Error: 'rehash' is an invalid command.
Nov 22 12:41:05 <rburton_> it was
Nov 22 12:41:25 <OutBackDingo> hrmmm... in whhich version of 1.0.2? im using 1.0.2p
Nov 22 12:56:47 <RP> rburton_: just reconfigured the AB 'live' which is rather scary
Nov 22 12:57:27 * RP was surprised something didn't break
Nov 22 13:11:31 <RP> rburton_: to test with wine did you have to add i386 packages to your host?
Nov 22 13:25:21 <rburton_> RP: debian ships a wine64 package
Nov 22 13:25:34 <rburton_> so i couldn't test the 32-bit stuff, but i built a 64-bit sdk and that worked
Nov 22 13:25:38 <RP> rburton_: that is enough to make the tests work?
Nov 22 13:25:54 <RP> rburton_: I could install the 32 bit junk onto an AB worker I guess
Nov 22 13:25:57 <rburton_> with SDKMACHINE = "x86_64-mingw32" yes
Nov 22 13:26:42 <RP> rburton_: its just the normal -c testsdk right?
Nov 22 13:26:46 <rburton_> yes
Nov 22 14:02:36 <rfried> Hi There. created SDK using "-c populate_sdk" and installed it. sourcing the environment  file replaces the PATH environment variable completely instead of appending it. is that the expected behaviour ?
Nov 22 14:02:44 <rfried> I don't recall that I saw this before.
Nov 22 14:19:22 <JaMa> rburton_: do you already have openssl-1.1.1a upgrade in queue?
Nov 22 14:19:38 <rburton_> JaMa: nope
Nov 22 14:29:56 <LetoThe2nd> by the way, strange idea. has anybody thought about an IMAGE_FSTYPE "directory"? basically so the build output can be used directly to feed a nfs boot
Nov 22 14:30:09 <rburton_> sounds sensible
Nov 22 14:30:10 <rburton_> do it
Nov 22 14:30:25 <rburton_> not sure what you'd do about ownership though
Nov 22 14:30:42 <LetoThe2nd> rburton_: if neither you nor RP scream "jehova" i'd actually try
Nov 22 14:31:00 <rburton_> you writing != merging ;)
Nov 22 14:31:12 <rburton_> also looking forward to your ownership problem
Nov 22 14:31:36 <rburton_> tbh probably easier to just chain off the tar fstype and then sudo tar xf in a task :)
Nov 22 14:31:36 <LetoThe2nd> "jehova" in terms of "stupid idea, cannot work because of XXX"
Nov 22 14:32:00 <rburton_> well, .... file ownership
Nov 22 14:32:08 <LetoThe2nd> thats what came to my mind too
Nov 22 14:32:44 <RP> I thought we could already use unfs to share a rootfs directory and boot off it by using it with pseudo
Nov 22 14:32:58 <RP> I think armpit has an open bug related to this
Nov 22 14:33:03 <LetoThe2nd> RP: ?
Nov 22 14:33:31 <rburton_> yes, we can use unfs to start a user-mode nfs for nfs-booting a qemu
Nov 22 14:33:47 <rburton_> armpit has the bug for extending that for real hardware iirc
Nov 22 14:33:57 <rburton_> i suspect that code just unpacks the tar
Nov 22 14:34:12 <RP> LetoThe2nd: https://github.com/epyeoh/openembedded-core/blob/oeqa-manual-test-case/meta/lib/oeqa/manual/cases/sdk.json is a test which does this in the SDK
Nov 22 14:34:32 <RP> LetoThe2nd: meaning we already have the permissions issue solved with pseudo and a working user space nfs server
Nov 22 14:34:42 <LetoThe2nd> RP: \m/
Nov 22 14:34:58 <RP> LetoThe2nd: its not an IMAGE_FSTYPE but...
Nov 22 14:37:18 <LetoThe2nd> RP: i know what you mean
Nov 22 14:37:42 <RP> LetoThe2nd: I guess I'm saying it should be possible
Nov 22 14:39:25 <LetoThe2nd> ok, then i'll put it onto the "weird ideas to try"-pile
Nov 22 14:40:32 <rburton_> LetoThe2nd: if you do, ping armpit  first
Nov 22 14:40:56 * LetoThe2nd bites keyboard in order to resist jokes about odour
Nov 22 14:48:27 <la_croix> I have a recipe that builds scipy, which depends on numpy. I also have a recipe that builds numpy, which works correctly. I am getting a dependency issue when it tries to build scipy. I've added DEPENDS = "python3-numpy" to my scipy recipe, but it still fails...
Nov 22 14:52:36 <no_such_user> When creating sstate mirrors, is it best to create a new mirror per poky version or per poky version and distro/machine target?
Nov 22 14:56:11 <RP> no_such_user: only matters in that it helps you being able to remove things later
Nov 22 14:56:22 <RP> no_such_user: the system can cope with anything all together
Nov 22 14:56:42 <ernstp> no_such_user: I run sstate-cache-management.sh --remove-duplicated every now and then..
Nov 22 14:57:32 <jeciak> Hello
Nov 22 14:58:17 <jeciak> May I have a question? I would like to use docker in order to build our images using bitbake on MacOS. I have two problems/questions
Nov 22 14:59:14 <jeciak> 1) I prefer run building process as root in docker container. I would like to disable bitbake's sanity check "Do not use Bitbake as root."
Nov 22 14:59:27 <jeciak> Is it possible to disable only one sanity check?
Nov 22 15:00:26 <RP> jeciak: if you do that there are some file ownership tests which would fail to work properly so its really not recommended
Nov 22 15:00:30 <LetoThe2nd> jeciak: in short: change your preferences. building as root is discouraged for good reasoning - and what would you gain, besides that warm, rooty feeling in your guts?
Nov 22 15:01:07 * LetoThe2nd actually does it the complete reverse style - my containers are all users unless absolutely needed.
Nov 22 15:01:29 <jeciak> 2) MacOS has case insensitive file system in default. Is it safe to disable sanity check for checking whether filesystem is case sensitive or not? If I disable this sanity check then I will have some unexpected problems later? (e.g. duplicatation in sstate)
Nov 22 15:01:48 <LetoThe2nd> jeciak: yes you will have problems. been there, done that.
Nov 22 15:01:49 <RP> jeciak: no, its not safe at all and it will break
Nov 22 15:02:02 <LetoThe2nd> RP: hey we overlap again!
Nov 22 15:02:10 <jeciak> thank you for your help :)
Nov 22 15:02:11 <LetoThe2nd> jeciak: usually you can't even build the kernel.
Nov 22 15:02:35 <LetoThe2nd> jeciak: so either use a vm, or switch to an OS (pun intended)
Nov 22 15:02:39 <jeciak> I'm new in yocto (I have used it for 2-3 months)
Nov 22 15:02:55 <jeciak> ok
Nov 22 15:03:17 <nayfe> Hi, I'm trying to create recipe for https://github.com/mongodb/mongo-tools. I manage to create it for one tool (ie mongoimport) but when I add a  new GO_INSTALL, it overwrites build/bin/main as every tools folder are named "main", do you know any way (or I duplicate my recipe?)
Nov 22 15:04:56 <la_croix> Building scipy fails, claiming it has no module named 'setuptools'. The recipe clearly includes 'inherit setuptools3', and I have now built a number of python packages in this manner. This is the first problem...
Nov 22 15:11:12 <ernstp> doesn't docker on MacOS already use a vm... ?
Nov 22 15:12:40 <jeciak> LetoThe2nd: May I ask why I can't build the kernel using root account (inside docker container). I know that building using root account is a bad practice, because for example if we have a bug in our makefile then we can break our system. Also security. It's reasonable, but I wonder whether these arguments are still true if we use containers (our environment is isolated)
Nov 22 15:13:21 <jeciak> ernstp yes the docker on MacOS uses hyperkit (lightweight vm), but if we use docker volumes then the volume will have the same filesystem as host
Nov 22 15:13:50 <jeciak> I mean under the hood there is NFS share between MacOS -> HyperKit (Linux VM) and our container
Nov 22 15:14:53 <ernstp> jeciak: you should build on a native filesystem and then only copy the artifacts to the shared volume after the build...
Nov 22 15:15:18 <jeciak> $ docker run --rm -ti ubuntu mkdir dir Dir   # works well
Nov 22 15:15:20 <RP> jeciak: Its not supported ,its known to break.
Nov 22 15:15:28 <jeciak> $ docker run --rm -ti --volume $(pwd)/foo:/foo ubuntu mkdir /foo/dir /foo/Dir
Nov 22 15:15:28 <jeciak> mkdir: cannot create directory '/foo/Dir': File exists
Nov 22 15:15:42 <RP> jeciak: you can of course try it you were warned...
Nov 22 15:15:55 <jeciak> ernstp good idea, thank you
Nov 22 15:17:28 <jeciak> RP I don't want :) I just wonder, because all the people say that it's not recommended but unfortunately they are not able to give an example - why it will create a problem.
Nov 22 15:17:44 <jeciak> I'm just curious
Nov 22 15:17:45 <jeciak> :)
Nov 22 15:20:44 <RP> jeciak: taking one specific problem, we detect "user" contamination leakage by checking that nothing in the generated output is owned by the build user/group. If that is 0:0 (root:root) our leakage detection no longer works.
Nov 22 15:21:32 <RP> jeciak: it also means that operations that wouldn't work as a normal user would work in your build meaning if you hand a recipe you write to someone else, it could behave differently
Nov 22 15:22:01 <jeciak> oh, this is very good example, thank you!
Nov 22 16:28:13 <nayfe> go.bbclass installs files with ${GO} install ... `go_list_packages` and go_list_packages calls go list -f '{{.ImportPath}}' ...
Nov 22 16:28:14 <nayfe> But when I inspect target with following command, there are some duplicated files: https://pastebin.com/scdMmWbw
Nov 22 16:29:54 <yocti> New news from stackoverflow: Ip address for wifi tethering using connman <https://stackoverflow.com/questions/53434802/ip-address-for-wifi-tethering-using-connman>
Nov 22 16:51:45 <nayfe> Well  it seems I'll live with 10 copy/paste recipes for now :D
Nov 22 16:57:11 <RP> rburton_: mingw doesn't seem to want to work :/
Nov 22 16:57:18 <rburton_> awww
Nov 22 16:58:00 <rburton_> what's happening?
Nov 22 16:58:10 <RP> rburton: https://autobuilder.yoctoproject.org/typhoon/#/builders/89/builds/2
Nov 22 16:58:15 <RP> rburton: will have to debug
Nov 22 16:59:31 <rburton> that happened to me when the sysroot was win32 but i didn't have wine32 installed
Nov 22 17:00:37 <rburton> need to monkey-patch in the replacement subprocess exception that shows stderr too
Nov 22 17:03:30 <RP> rburton: wine32 wanted to install all kinds of mutliarch i386 stuff (0.5GB worth)
Nov 22 17:03:52 <rburton> ouch
Nov 22 17:04:01 <rburton> i guess it doesn't emulate 32-bit ia
Nov 22 17:04:07 <rburton> so yeah, that's needed
Nov 22 17:04:14 <rburton> lets just start with 64-bit sdk?
Nov 22 17:05:28 <RP> rburton: isn't it still mingw32 though?
Nov 22 17:05:47 <cslcm> Hey. I'm currently having an issue with my yocto image on a raspberry pi 3 where processes fail to exit, they all turn into zombies
Nov 22 17:05:51 <cslcm> anyone seen this?
Nov 22 17:05:58 <RP> rburton: I guess not
Nov 22 17:06:20 <rburton> RP: i'll admit ignorance here
Nov 22 17:06:28 <rburton> is it called mingw32 because its the win32 api
Nov 22 17:06:31 <rburton> even though its 64-bit
Nov 22 17:08:03 <RP> rburton: right. I'll try it
Nov 22 17:08:48 <rburton> of course https://mingw-w64.org/doku.php is something else
Nov 22 17:09:13 <rburton> oh that's what we ship
Nov 22 17:09:18 <rburton> so the sdk name is wrong i guess
Nov 22 17:09:57 <rburton> maybe renaming the sdks is something else to do
Nov 22 17:11:24 <RP> rburton: possibly yes
Nov 22 17:30:08 <RP> rburton: that worked
Nov 22 17:34:12 <rburton> success, ship it
Nov 22 17:34:25 <RP> rburton: testing it on the AB now :)
Nov 22 17:41:54 <RP> rburton: success - https://autobuilder.yoctoproject.org/typhoon/#/builders/89/builds/3/steps/7/logs/step2c
Nov 22 17:41:59 <rburton> yay
Nov 22 17:42:00 <RP> JPEW: ^^^ :)
Nov 22 17:42:48 <RP> JPEW: just need to work on the WARNING messages now ;-)
Nov 22 20:00:36 <yocti> New news from stackoverflow: compilation error: No suitable bison/yacc found <https://stackoverflow.com/questions/53394997/compilation-error-no-suitable-bison-yacc-found>
Nov 22 20:18:32 <peniwize> I'm building the nvidia kernel module in yocto and I'm receiving this error:
Nov 22 20:18:53 <peniwize> test -e include/generated/autoconf.h -a -e include/config/auto.conf || (		\
Nov 22 20:18:53 <peniwize> echo >&2;							\
Nov 22 20:18:53 <peniwize> echo >&2 "  ERROR: Kernel configuration is invalid.";		\
Nov 22 20:18:53 <peniwize> echo >&2 "         include/generated/autoconf.h or include/config/auto.conf are missing.";\
Nov 22 20:18:53 <peniwize> echo >&2 "         Run 'make oldconfig && make prepare' on kernel src to fix it.";	\
Nov 22 20:18:54 <peniwize> echo >&2 ;							\
Nov 22 20:18:56 <peniwize> /bin/false)
Nov 22 20:19:11 <peniwize> It's not clear why since the files exist.  Does anyone have any insight?
**** ENDING LOGGING AT Fri Nov 23 03:00:01 2018