**** BEGIN LOGGING AT Fri Jun 15 03:00:11 2018
Jun 15 05:19:41 <vishnu_nk> Is there any difference between setting SSTATE_DIR and SSTATE_MIRRORS to the same local path? (SSTATE_DIR = "/tmp/yocto", SSTATE_MIRRORS = "file://.* file:///tmp/yocto/PATH")
Jun 15 05:20:05 <vishnu_nk> Will there be any difference in this, like the fetch speed?
Jun 15 06:17:00 <LetoThe2nd> vishnu_nk: first do no crosspost everywhere if you don't get an answer within 5 minutes.
Jun 15 06:18:03 <LetoThe2nd> vishnu_nk: and pointing both to the same directory is kinda pointless. SSTATE_DIR means that this is the directory to use if nothing is found in SSTATE_MIRRORS. thats why SSTATE_DIR requires write permissions, SSTATE_MIRRORS only needs read permissions.
Jun 15 06:33:24 <pk> anyone can tell what "sysroot"  in yocto is?
Jun 15 06:34:00 <pk> where do i get clear explanation about sysroot?(any link please)
Jun 15 06:34:37 <LetoThe2nd> pk: it is not yocto specific, but a term from gcc: https://www.quora.com/What-is-a-sysroot
Jun 15 06:45:58 <kir> Hey guys. Have anybody managed to run SDK compiled under poky under Linux Subsystem for Windows 10?
Jun 15 07:19:59 <cornel> good morning
Jun 15 07:21:39 <cornel> i have one strange problem: for a certain (local) recipe, sumo fails do_configure()  complaining that 'Unix Makefiles' binary is not found
Jun 15 07:21:58 <cornel> i've added 'make' into DEPENDS list but it did not help
Jun 15 07:22:28 <cornel> i've also tried changing the line in cmake.class
Jun 15 07:22:46 <cornel> anybody else has seen such a problem?
Jun 15 07:37:15 <LetoThe2nd> cornel: nothing too specific i can help with right now, but it might be related to cmake using ninja as standard generator in sumo, IIRC
Jun 15 07:44:51 <cornel> LetoThe2nd: that's what i've thought, but replacing Ninja with Unix Makefiles in cmake.bbclass did not help
Jun 15 07:45:22 <cornel> i'm tempted to thing that somehow cmake 3.10 unlike 3.3 has some default for Unix Makefiles for cmake-native
Jun 15 07:45:39 <cornel> or maybe a combination of these :)
Jun 15 07:45:54 <LetoThe2nd> cornel: sorry, i do not have in-depth knowledge here.
Jun 15 07:46:17 <cornel> LetoThe2nd: thank you very much
Jun 15 07:46:42 <cornel> i'll keep digging
Jun 15 07:46:50 <LetoThe2nd> yeah, good luck
Jun 15 08:46:14 <yann> any idea why MACHINE_EXTRA_RDEPENDS += "kernel-image" results in "kernel-image-$VERSION-yocto-standard" being added to packagegroup-machine-base, and not just "kernel-image" ?  What's causing this expansion ?
Jun 15 08:50:02 <yann> that happens in sumo, but did not in morty
Jun 15 09:49:07 <pk> anyone know what kind of files stored in sysroot folder in yocto? like -srcfiles., etc
Jun 15 10:29:29 <RP> pk: the headers and libraries to build and link against, or native tools in the native sysroot
Jun 15 10:36:42 <eduardas_m> hello, has anyone successfully used the bluez-qt recipe from meta-qt5-extra? I believe it produces a dev package that is inappropriate for integration with qmake projects, i.e. header inclusion does not work when adding the module to a project
Jun 15 11:14:44 <hattzy> kir: No, or well, i found a thread about it and there is an experimental build of WSL but you need to be part of the windows insider program to test it. The root problem is in WSL. Hopefully the fix will be in the next monthly windows update
Jun 15 11:16:32 <hattzy> kir: here is the bug report, https://github.com/Microsoft/WSL/issues/3154
Jun 15 11:39:05 <kir> hattzy, thanks, dude, that really helps!
Jun 15 11:47:44 <yocti> New news from stackoverflow: why connman ipv4 settings are having dhcp by default <https://stackoverflow.com/questions/50874790/why-connman-ipv4-settings-are-having-dhcp-by-default>
Jun 15 11:57:45 <pk> why do we need to copy files into sysroot folder in yocto/
Jun 15 11:58:48 <RP> armpit: That rm_work patch in sumo-next has known issues :(
Jun 15 13:14:50 <rburton> kanavin_home: so those hashes in gitlab tarballs are in fact random, which is fun
Jun 15 13:15:31 <rburton> kanavin_home: any thoughts on extending the fetcher's find-versions logic to return the URLs, so as it scrapes the page it can return the correct links instead of just versions
Jun 15 13:15:43 <rburton> as more projects move to gitlab we're going to hit this
Jun 15 13:15:50 <rburton> and eg iso-codes is a 3M tarball but 170M git repo
Jun 15 13:17:20 <kanavin_home> rburton: it's not just the find-versions logic that needs to return not just the version, but the full URI. also 'devtool upgrade' needs to be able to rewrite the URI using that information, instead of renaming the recipe.
Jun 15 13:17:30 <kanavin_home> doable, but not trivial
Jun 15 13:20:04 <kanavin_home> rburton: the first part is perhaps easier, as the find versions logic iterates over links on a webpage, and matches them against the regex - it could simply be extended to return the link, which I don't think it does now... not sure. it's buried somewhere in meta/lib/oe/
Jun 15 13:20:28 <rburton> yes, it should be able to construct the absolute URL from the page
Jun 15 13:20:54 <rburton> and obviously sf sites are down too now, so eg libpng fails checkpkg
Jun 15 13:21:12 <rburton> and shadow moved from alioth to github but doesn't have uploaded tarballs for the release we ship
Jun 15 13:21:27 <kanavin_home> sourceforge seems to be down at least once a month, I've gotten used to it :)
Jun 15 13:23:05 <kanavin_home> the sooner they pull the plug on it, the better really, although it'll be pain for us
Jun 15 13:23:59 <rburton> but they've had a massive resurgence of github leavers right
Jun 15 13:24:02 <rburton> (lols)
Jun 15 13:25:11 <rburton> huh, that's clever.  the shadow release was never actually in debian
Jun 15 15:18:30 <yocti> New news from stackoverflow: Yocto: BUILD_LDFLAGS set to build system libraries, not target <https://stackoverflow.com/questions/50866761/yocto-build-ldflags-set-to-build-system-libraries-not-target>
Jun 15 15:25:07 <kergoth> <3 https://github.com/rustyrussell/stats#readme
Jun 15 15:41:36 <teo_icks> Hi at all, I have question about ramdisk image build....
Jun 15 15:44:10 <teo_icks> ... I create an my s.o. yocto image that depends to boot from a ramdisk to boot. Is possible to automticaly generate the ramdisk image when build my s.o. image?
Jun 15 15:45:18 * armpit looks
Jun 15 15:48:16 <armpit> RP so did you drop it
Jun 15 15:49:20 * armpit yep looks like
Jun 15 16:33:03 <rburton> armpit: in the bind upgrade, does it make sense to shunt the python bits into a separate package?
Jun 15 16:34:41 <armpit> rburton, hmm, yeah.. I suppose so. did you wan v+ or addition patch to add the split ?
Jun 15 16:35:14 <rburton> patch refresh, we can pull ply into core and tbh i can't seem to make it even build the py bits :)
Jun 15 16:36:23 <armpit> rburton, is there a log I can look at for the failures
Jun 15 16:37:29 <rburton> also mdig isn't in the same package as dig
Jun 15 16:42:50 * armpit will have to find patch to what's what
Jun 15 16:50:47 <RP> armpit: yes, I did
Jun 15 16:50:57 <RP> armpit: sumo-next and rocko-next good to go?
Jun 15 16:51:34 <armpit> yes
Jun 15 16:52:09 <armpit> I suspect both will need the uninative update?
Jun 15 16:53:16 <RP> armpit: We usually keep them up to date but probably not urgent
Jun 15 23:29:01 <RzR> hi, Any edison gurus around  ? I have a non yocto related question
Jun 15 23:29:14 <RzR> I fear mine is bricked..
Jun 16 01:02:36 <khem> RzR: https://communities.intel.com/thread/55187
Jun 16 01:08:39 <RzR> yea I saw this thread , but I am afraid I am in more serious situation
Jun 16 01:08:39 <RzR> https://communities.intel.com/message/550099#550099
Jun 16 01:09:25 <RzR> dmesg sees it as
Jun 16 01:09:27 <RzR> [57940.127046] usb 1-1.5: Product: MERRIFIELD
Jun 16 01:09:27 <RzR> [57940.127049] usb 1-1.5: Manufacturer: INTEL
Jun 16 01:09:39 <RzR> and it's super hot
Jun 16 01:11:17 <khem> I wonder if you have flash issues
Jun 16 01:11:36 <khem> may be let it cool down in a cold area and retry
Jun 16 01:11:57 <khem> you can also try a different usb cable and port
Jun 16 01:18:40 <RzR> 06/16/18 03:17:06.337  DEBUG  : [Port 1/5] XFSTK-LOG--usb_bulk_read() fails
Jun 16 01:18:58 <RzR> yea I tried different cables
Jun 16 01:20:05 <RzR> is there a way to know if it is briked ?
Jun 16 01:20:32 <khem> I am not sure
**** ENDING LOGGING AT Sat Jun 16 03:00:04 2018