**** BEGIN LOGGING AT Fri Sep 27 02:59:57 2019
**** BEGIN LOGGING AT Fri Sep 27 04:20:54 2019
Sep 27 05:32:56 <nrossi> RP: found the issue, for some reason the binutils logfile has non-unicode bytes. two patches on list to fix it and a bug with how concurrencytest was not handling exceptions nicely
Sep 27 05:33:53 <nrossi> RP: should clarify the non-unicode bytes should be allowed in the log file, just the compress/decompress did not handle it
Sep 27 05:49:34 <Domin1k> In one of my recipes the task do_cleanall() does not do what i would expect. listtasks says that do_cleanall should also remove all downloaded source files for a target. In my case i use the clearcase fetcher (ccrc) and i would expect that do_cleanall() should remove build/downloads/clearcase-<SRC_URI_vob>-<SRC_REV>.tar.gz. Do i have wrong
Sep 27 05:49:34 <Domin1k> expectations here or is this a bug? I feel like nearly nobody sticks to IBM-clearcase nowadays except us. So its likely that this is most likely a bug.
Sep 27 06:16:49 <RP> nrossi: good catch, thanks!
Sep 27 06:20:05 <nrossi> RP: btw just playing with proot to try and figure out a microblaze bug, looks like it could be used for glibc test suite to cover the "needs /bin/sh"
Sep 27 06:32:26 <mckoan> good morning
Sep 27 06:33:31 <RP> nrossi: interesting, I see its ptrace based
Sep 27 06:35:55 <nrossi> RP: yep, the most important two features are the bind mount and the ability to handle host binaries in place of target binaries (e.g. the binfmt stuff)
Sep 27 06:38:29 <alessioigor> good morning!
Sep 27 06:38:31 <alessioigor> I'll receive a board with two type of CPU (a big Intel CPU and a little ARM cpu) soon. Is it possible to produce an image with both compilers?
Sep 27 06:39:49 <LetoThe2nd> alessioigor: if it were, think along what it would mean. a... kernel that runs on both cpus at the same time? a combined x86/arm rootfilesystem?
Sep 27 06:41:02 <RP> alessioigor: I've done that kind of thing before. Adding target cross compilers always seemed a little crazy so it was never submitted/merged but is definitely possible
Sep 27 06:41:50 <LetoThe2nd> RP: don't give away the enlightenment about what compiles what for which usage early! self-accomplished learning effects last the longest :)
Sep 27 06:42:14 <alessioigor> LetoThe2nd: No the ARM CPU (it is definitely capable to run Linux) but in my case it been used as MCU (w/o OS).
Sep 27 06:42:52 <LetoThe2nd> alessioigor: see, now think about what this means. it implies that the image runs on the x86, right?
Sep 27 06:43:05 <alessioigor> LetoThe2nd: Right
Sep 27 06:43:39 <alessioigor> LetoThe2nd: I would like to have an image with a compiler that run on Intel and produce code for ARM.
Sep 27 06:43:41 <LetoThe2nd> alessioigor: good. think more about what this tells you about the "meaning" of the arm build?
Sep 27 06:43:58 <LetoThe2nd> alessioigor: heh no, you're already disgressing again
Sep 27 06:46:32 <LetoThe2nd> alessioigor: hint - it means that whatever runs on the arm is merely.... included in the image
Sep 27 06:46:48 <iceaway> I have a package in two versions, 2.0 and 3.0. If I use version 2.0, I need to patch a completely different package, but if I use version 3.0, no patching is necessary. How would I link the patching to a specific recipe version? As it stands, I have the patch in my layer, but I mask it in my local.conf when using version 3.0. Can I do the BBMASK in the 3.0 version of the recipe, or is there a better way?
Sep 27 06:47:29 <LetoThe2nd> iceaway: why don't you just write two recipes? mypackage_2.0.bb, mypackage_3.0.bb
Sep 27 06:48:40 <iceaway> LetoThe2nd: I have two package recipes, 2.0 and 3.0, but I need to patch a third package depending on which version I choose to include in my image.
Sep 27 06:49:10 <LetoThe2nd> iceaway: that sounds very much like you got a architecture problem
Sep 27 06:51:43 <iceaway> LetoThe2nd: I am including a binary package (ms dotnet core), and unfortunately version 2.x of this package has some issues with curl which requires a small patch. But 3.0 does not appear to have the same issue. So depending on if I want to include version 3.0 or 2.0, I need to apply the curl patch.
Sep 27 06:54:01 <LetoThe2nd> iceaway: then write two recipes for dotnet, one _2.0 with the patch, one _3.0 without the patch, and match them through the DISTRO, for example
Sep 27 06:55:27 <LetoThe2nd> iceaway: i mean, you're having an inversion of control otherwise. the recipe would go like "hum lets see what i find, i'll do whatever then" instead of "this is what i need. build this."
Sep 27 06:56:19 <iceaway> LetoThe2nd: I have two recipes for the package, I'm just trying to understand how to link the curl patch to the dotnet version.
Sep 27 06:56:32 <LetoThe2nd> iceaway: you don't. thats the point.
Sep 27 06:56:51 <LetoThe2nd> i mean, how do you select which dotnet package gets built?
Sep 27 06:57:01 <iceaway> Sorry, dotnet version to curl patch I mean.
Sep 27 06:57:27 <iceaway> Using PREFERRED_VERSION_dotnet at the moment.
Sep 27 06:57:51 <LetoThe2nd> iceaway: see. so, add another line right below that goes like PREFERRED_VERSION_curl :)
Sep 27 06:58:14 <LetoThe2nd> and then modify those two in lockstep. thats exactly the job of a DISTRO config, to define the ABI
Sep 27 07:00:48 <iceaway> LetoThe2nd: The version of curl is the same though, it's just the matter of whether to apply the patch from my custom layer or not. (I really feel like I am missing something obviuos here).
Sep 27 07:02:15 <LetoThe2nd> iceaway: erm. are we talking about dotnet patching *itself* or about it *patching curl*?
Sep 27 07:04:17 <iceaway> LetoThe2nd: Dotnet pathing curl.
Sep 27 07:04:32 <LetoThe2nd> thats not how it works. a package does not patch another package
Sep 27 07:04:58 <LetoThe2nd> you have to take the patch, and add it to a custom curl-patched recipe
Sep 27 07:06:17 <iceaway> So basically creating my own curl-recipe, with the patch included, and use that as preferred version?
Sep 27 07:06:25 <LetoThe2nd> yep.
Sep 27 07:06:39 <iceaway> Cool, thanks.
Sep 27 07:07:01 <LetoThe2nd> iceaway: recipes do not affect other recipes. simple as that.
Sep 27 07:07:33 <iceaway> LetoThe2nd: I'll keep that rule in mind! Sounds perfectly reasonable.
Sep 27 07:08:01 <LetoThe2nd> iceaway: its just another interpretation of "conf data is global, recipe data is local"
Sep 27 07:08:24 <LetoThe2nd> i think i have already encouraged you to say that out loud, but it certainly wouldn't hurt repeating it a couple of times :)
Sep 27 07:13:05 <iceaway> LetoThe2nd: my colleugues would look at me very strangely... :)
Sep 27 07:13:17 <LetoThe2nd> iceaway: they should join in
Sep 27 07:43:26 <thomasd13> Hi. I would like to generate a custom .img-File (multiple partitions) with yocto. Has anyone done this already, or could give me a starting hint?
Sep 27 07:47:54 <mckoan> thomasd13: look at wic and files .wks
Sep 27 07:48:53 <thomasd13> mckoan: thanks!
Sep 27 08:39:04 <Domin1k> LetoThe2nd: (y)  Thank you for you're great live coding sessions on youtube and twitch. They really helped me a lot.
Sep 27 08:39:16 <yocti> New news from stackoverflow: How do I write a yocto/bitbake recipe to copy a directory to the targe root file system <https://stackoverflow.com/questions/40722637/how-do-i-write-a-yocto-bitbake-recipe-to-copy-a-directory-to-the-targe-root-file>
Sep 27 08:39:57 <LetoThe2nd> Domin1k: gald to hear!
Sep 27 08:41:33 <thomasd13> Domin1k which live coding sessions? :)
Sep 27 08:42:25 <Domin1k> LetoThe2nd: I wish i would had found them earlier. I also recommend them to my colleagues.
Sep 27 08:43:30 <Domin1k> thomasd13: https://www.youtube.com/watch?v=EfKLrSxA_H8&list=PLD4M5FoHz-TxMfBFrDKfIS_GLY25Qsfyj https://www.twitch.tv/yocto_project
Sep 27 08:44:10 <thomasd13> Cool! I will look at them
Sep 27 08:45:28 <LetoThe2nd> Domin1k: feel free to shoot us comments, questions, things we can do better :)
Sep 27 08:56:36 <LetoThe2nd> Domin1k: thomasd13: for the record, the next session on Oct 8th will be on the holy trinity: MACHINE, DISTRO, IMAGE :)
Sep 27 08:57:41 <thomasd13> Nice. Seems to fit in my current workload ;)
Sep 27 09:01:58 <Domin1k> I can't take part at the session on Oct 8th. I will recover during vacations from the Marathon i ran two days before. But i will look up the video on youtube as soon as im back in the office.
Sep 27 09:02:11 <LetoThe2nd> :-)
Sep 27 09:09:23 <yocti> New news from stackoverflow: YOCTO : How can I exclude drrivers that are reserving and handling my embedded board GPIO <https://stackoverflow.com/questions/58130865/yocto-how-can-i-exclude-drrivers-that-are-reserving-and-handling-my-embedded-b>
Sep 27 09:14:02 <bluca> hi - was the systemd + cryptsetup dependency loop ever solved? There's no resolution in either http://lists.openembedded.org/pipermail/openembedded-devel/2018-February/116964.html or https://bugzilla.yoctoproject.org/show_bug.cgi?id=11856
Sep 27 09:14:03 <yocti> Bug 11856: normal, Undecided, ---, richard.purdie, RESOLVED INVALID, Dependency loop in systemd/cryptsetup.
Sep 27 09:14:18 <bluca> in thud, it still fails
Sep 27 09:39:28 <yocti> New news from stackoverflow: Building yocto/poky image with wic? <https://stackoverflow.com/questions/58131685/building-yocto-poky-image-with-wic>
Sep 27 09:50:32 <qschulz> I am struggling to understand the difference between PARALLEL_MAKE and ICECC_PARALLEL_MAKE (limited knowledge of icecc, I haven't set it up but we use it). For an icecc enabled build, are we always going to take ICECC_PARALLEL_MAKE?
Sep 27 09:51:07 <qschulz> or is it something like, it's the PARALELL_MAKE given to other machines in the icecc cluster but we keep our local PARALLEL_MAKE? I'm just guessing wildly here :)
Sep 27 09:59:47 <interruptguy> Hey guys. Are `http://sstate.yoctoproject.org/2.6.2/` servers accessible? If I used them from my browser I do get `403 Forbidden`error
Sep 27 10:10:26 <RP> interruptguy: they don't support directory indexing
Sep 27 10:10:45 <bluca> I see there are some commits in oe-core/master for the dep loop, I'll try those
Sep 27 10:19:24 <bluca> 64ed8b631 fbe17b57d and 3f64779ea from meta-openembedded/master seem to fix the issue
Sep 27 11:09:44 <yocti> New news from stackoverflow: Bitbake, build from git but not latest commit <https://stackoverflow.com/questions/58132965/bitbake-build-from-git-but-not-latest-commit>
Sep 27 11:15:24 <pepone> Trying to figure why locale -a only list C/POSIX locales
Sep 27 11:16:13 <pepone> I have set GLIBC_GENERATE_LOCALES="en_US.UTF-8 es_ES.UTF-8" and IMAGE_LINGUAS="en-us es-es"
Sep 27 11:16:24 <pepone> do I need any extra package to install the locales?
Sep 27 12:02:47 <tgoodwin> Does anyone happen to know if the result of populate_sdk can be restored from only shared state cache?
Sep 27 12:09:36 <LetoThe2nd> tgoodwin: i think it shuold, but no guarantees.
Sep 27 12:12:56 <tgoodwin> LetoThe2nd: I would assume so too, but I'm trying to work out how to put this into gitlab ci and the thought I had was between build stages, the container empties but the sstate cache was stored outside the container.  So if I re-run the same command with the same conf files, the SDK should simply unpack (or at worst, rebuild), but for some reason the sdk directory doesn't exist after the bitbake command completes.
Sep 27 12:17:16 <LetoThe2nd> no idea, sorry.
Sep 27 12:46:41 <rburton> pepone: for reasons, en_US is utf-8
Sep 27 12:46:58 <rburton> the 8859-1 variant is en_US.ISO8859
Sep 27 12:47:04 <rburton> something i've been meaning to fix for about a decade
Sep 27 12:47:08 <tgoodwin> Thanks for the sanity check :)  Glad I'm not the only one who thought it would.
Sep 27 14:44:59 <tgoodwin> LetoThe2nd: I recreated the environment locally and SDK does indeed get unpacked fine.  I'm not sure what the deal is in the container...
Sep 27 15:40:32 <zeddii> Does anyone have the link to the oeadam or whatever-you-call-it page ? My plans changed, and if I can get hotels sorted out, I’ll stay through the end of the work.
Sep 27 15:40:43 * zeddii goes to look on the oe wiki
Sep 27 15:41:34 <zeddii> found it
Sep 27 15:49:03 * fray has to start working on his talk.. :P
Sep 27 18:11:56 <litb> hello all
Sep 27 18:15:39 <litb> I'm working on adding a "BBCLASSEXTEND" for "mingw". one is supposed to define the mingw parameters in local.conf. I think that's the best way to make compiling windows firmware parts work
Sep 27 18:15:59 <litb> i'll base the work on the native class
Sep 27 18:46:49 <JPEW> litb: What are you trying to do with mingw?
Sep 27 19:43:00 <yocti> New news from stackoverflow: Yocto: how to remove a layer without rebuild all <https://stackoverflow.com/questions/58140448/yocto-how-to-remove-a-layer-without-rebuild-all>
**** ENDING LOGGING AT Sat Sep 28 02:59:59 2019