**** BEGIN LOGGING AT Thu May 17 03:00:02 2018
May 17 07:35:22 <fberg> hello guys ! I'm bitbaking poky@sumo (f0ec7c8). After some packages buing built bitbkae stops with error: zlib-native-1.2.11-r0 do_unpack: Unpack failure for URL: 'http://downloads.sourceforge.net/libpng/zlib/1.2.11/zlib-1.2.11.tar.xz'.
May 17 07:35:34 <fberg>  zlib-native-1.2.11-r0 do_unpack: Function failed: base_do_unpack
May 17 07:35:56 <fberg>  bison-native-3.0.4-r0 do_unpack: Unpack failure for  URL: 'http://ftp.gnu.org/gnu/bison/bison-3.0.4.tar.xz'.
May 17 07:36:05 <fberg>  bison-native-3.0.4-r0 do_unpack: Function failed: base_do_unpack
May 17 07:36:16 <fberg> : mpfr-native-3.1.5-r0 do_unpack: Unpack failure for URL: 'http://www.mpfr.org/mpfr-3.1.5/mpfr-3.1.5.tar.xz'.
May 17 07:36:22 <fberg> : mpfr-native-3.1.5-r0 do_unpack: Function failed: base_do_unpack
May 17 07:36:38 <fberg> doesn anyone has any idea ?
May 17 08:07:20 <vishnu_nk> Hi All, Yocto SDK manual states that a standard sdk contains 1. cross-dev toolchain 2. lib, headers, symbs 3. env setup script.
May 17 08:07:38 <vishnu_nk> But I need to take the sdk for the cross-dev toolchain itself.
May 17 08:08:25 <vishnu_nk> Will merely adding "inherit populate_sdk" be able to help to generate deployable sdk for my gcc-cross toolchain?
May 17 08:10:55 <vishnu_nk> When I tried that I'm getting stuck at error with the packagegroup-core-standalone-sdk-target, saying nothing provides libgcc
May 17 08:11:01 <LetoThe2nd> vishnu_nk: no, thats not how it works.
May 17 08:11:03 <vishnu_nk> Can anyone kindly help me with this?
May 17 08:11:24 <LetoThe2nd> you create an sdk with bitbake -c populate_sdk core-image-minimal, for example
May 17 08:12:58 <vishnu_nk> But I need to take the portable prebuilt binaries of gcc-cross-*, gcc-cross-initial-*, gcc-runtime, libgcc to upload it into a common server.
May 17 08:13:33 <LetoThe2nd> vishnu_nk: then you need to rethink what you upload. this is not how it is meant to be used.
May 17 08:14:02 <LetoThe2nd> we've had a toolchain target preliminary, and i think it was dropped because it caused too many troubles.
May 17 08:14:05 <vishnu_nk> Because each time compiling cross-toolchain takes time. By making it as portable prebuilt binaries I can upload the binaries and then only fetch_prebuilt and do_install() needs to be done
May 17 08:14:34 <LetoThe2nd> vishnu_nk: again, thats not how things are meant to be used. what you jsut described is a simple sstate mirror
May 17 08:16:54 <vishnu_nk> LetoThe2nd: But then if I inherit populate_sdk in my gcc-cross-* recipe then it wont build sdk?
May 17 08:17:11 <LetoThe2nd> and if you totally want "JUST PREBUILT TOOLCHAINS", then look at what linaro provides for example, and read the "using an external toolchain" documentation
May 17 08:17:35 <LetoThe2nd> vishnu_nk: you do not have to inherit anything anywhere. its all done already.
May 17 08:18:57 <vishnu_nk> By default if i do populate_sdk for gcc-cross-* then it results in "Task do_populate_sdk does not exist for target gcc-cross-arm"
May 17 08:19:06 <LetoThe2nd> *sigh*
May 17 08:19:12 <LetoThe2nd> because you are not listening.
May 17 08:19:32 <LetoThe2nd> you do *NOT* call populate_sdk on a gcc recipe, but an image target.
May 17 08:19:32 <vishnu_nk> Sorry
May 17 08:20:09 <LetoThe2nd> 08:11 < LetoThe2nd> you create an sdk with bitbake -c populate_sdk core-image-minimal, for example
May 17 08:22:32 <vishnu_nk> Ok. But for example core-image-minimal will contain all the packages required to boot a device right.
May 17 08:22:38 <LetoThe2nd> yes.
May 17 08:23:10 <vishnu_nk> So are you suggesting that from that generated sdk, I take out only the cross-toolchain?
May 17 08:24:00 <LetoThe2nd> i suggest that you just use it as is. because the *IMAGE* contains the things. the sdk is just an sdk. its a toolchain that *WORKS*
May 17 08:24:26 <LetoThe2nd> but my general impression is that you are just tinkering around some much bigger architectural problem in your development process.
May 17 08:27:59 <vishnu_nk> But my doubt is If I take core-image-minimal sdk which includes toolchain. Then I should replace this sdk for my gcc-cross-* ?
May 17 08:29:01 <vishnu_nk> Then what about the other packages? Like libmpc, mpfr and gmp. Those will be linked to sdk right? So then If I stop build of those packages, will my cross-toolchain still work?
May 17 08:29:31 <LetoThe2nd> i wonder what yourt *ACTUAL* problem is.
May 17 08:29:57 <vishnu_nk> Ok. I will clarify it.
May 17 08:30:04 <LetoThe2nd> do you want to get down build times for your developers? or why are you trying so hard to reuse a gcc that is not meant for it.
May 17 08:30:44 <vishnu_nk> Yes. Because there are some CI tests which are failing due to timeout
May 17 08:31:04 <LetoThe2nd> well then use an sstate cache. done.
May 17 08:31:20 <LetoThe2nd> thats *EXACTLY* what it is there for. to reuse prebuilt stuff
May 17 08:31:34 <vishnu_nk> sstate cache?
May 17 08:31:45 <LetoThe2nd> sstate cache
May 17 08:32:18 <LetoThe2nd> https://wiki.yoctoproject.org/wiki/Enable_sstate_cache
May 17 09:19:24 <didil> hi!
May 17 09:21:15 <didil> I cannot build my image with BitBake from rocko because the receipe for PAX 3.4-r2 failed at do_compile task.
May 17 09:22:36 <LetoThe2nd> didil: as there is nothing "PAX" in the layerindex, i guess you are talking about some internal stuff?
May 17 09:22:49 <didil> here are the logs: https://paste.ofcode.org/MV8FVdwjktMeUr57gup5mg
May 17 09:23:58 <LetoThe2nd> looks like the source is broken.
May 17 09:26:09 <didil> I use poky from https://git.yoctoproject.org/git/poky
May 17 09:26:35 <didil> plus meta-openembedded, meta-freescale, meta-ti
May 17 09:26:46 <didil> from GitHub
May 17 09:30:26 <LetoThe2nd> jsut taht?
May 17 09:31:04 <didil> meta-qt5 also
May 17 09:31:51 <didil> but the recipe-sysroot directory is a core feature I guess
May 17 09:34:17 <LetoThe2nd> but where does that PAX come from?
May 17 09:35:32 <didil> I have no idea. The is the POSIX archive tool.
May 17 09:35:49 <didil> ftp://rpmfind.net/linux/RPM/centos/7.4.1708/x86_64/Packages/pax-3.4-19.el7.x86_64.html
May 17 09:35:53 <LetoThe2nd> and all layers are coherent on the rocko branch?
May 17 09:36:20 <didil> there are all on rocko yes
May 17 09:37:58 <LetoThe2nd> i'm wondering where it comes from. there is no "PAX" in the layerindex as far as i can see. so i assume there is still some other layer or workspace in effect and that causes your problem.
May 17 09:38:10 <LetoThe2nd> can you put bitbake -e pax on a pastebin?
May 17 09:38:48 <didil> yes 2sec
May 17 09:41:23 <didil> https://paste.ofcode.org/9TuvBXnNSYSmTxfYPBv2MA
May 17 09:45:47 <LetoThe2nd> well this certainly is not just the layers you mentioned, but with some udoo glue on it
May 17 09:46:56 <didil> The recipe-sysroot has been added with rocko in Yocto according to this page: https://www.packtpub.com/mapt/book/networking_and_servers/9781788470469/5/ch05lvl1sec41/understanding-the-sysroot-directories
May 17 09:48:28 <LetoThe2nd> rocko got recipe specific sysroots, yes. but from whati see, that compilation failure is not related to it.
May 17 09:49:17 <didil> pax is part of poky
May 17 09:49:51 <didil> it's located under /meta/recipes-extended/pax_3.4.bb
May 17 09:51:14 <LetoThe2nd> ah, i see. its there in rocko and gone now. well, guess why :-P
May 17 09:52:23 <didil> https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/recipes-extended/pax/pax_3.4.bb?h=rocko
May 17 09:52:40 <didil> ok but rocko is the last branch right?
May 17 09:52:46 <didil> last "stable"
May 17 09:53:04 <rburton> didil: sumo is latest stable now
May 17 09:53:27 <didil> ok
May 17 09:53:50 <didil> I'll move forward so
May 17 09:54:33 <rburton> didil: if you want to stay on rocko for now, patch pax so that it doesn't pass -Werror
May 17 09:55:04 <rburton> everyone who forces -Werror in their builds should be forced to rebuild an entire distro on gcc from git
May 17 09:55:20 <didil> I don't have choice
May 17 09:55:27 <didil> sumo isn't available in meta-freescale
May 17 09:55:42 <rburton> sumo was literally released this week, so that's not a surprise
May 17 09:55:51 <didil> I see
May 17 09:56:18 <didil> simply removing the package isn't a good idea?
May 17 09:56:27 <didil> with INSTALL_remove or?
May 17 09:56:38 <LetoThe2nd> didil: if you don't use it, sure. the question is what pulls it in, in the first place
May 17 09:56:53 <didil> hm ok
May 17 09:58:40 <LetoThe2nd> sumo has oe-dot-depends :)
May 17 10:06:30 <yocti> New news from stackoverflow: ALSA lib ../../../alsa-lib-1.1.0/src/pcm/pcm_dmix.c:1029:(snd_pcm_dmix_open) unable to open slave <https://stackoverflow.com/questions/50388475/alsa-lib-alsa-lib-1-1-0-src-pcm-pcm-dmix-c1029snd-pcm-dmix-open-una>
May 17 10:14:39 <vishnu_nk> LetoThe2nd: Can you please give me an idea why populate_sdk() task cannot be done for gcc-cross-arm or similar recipes? It can be only run on certain images? Is there any criteria?
May 17 10:15:31 <LetoThe2nd> vishnu_nk: the sdk correlates to an image. hence, the populate_sdk task can be run on image recipes.
May 17 10:15:37 <LetoThe2nd> thats it, in a nutshell
May 17 10:16:45 <vishnu_nk> Ok
May 17 10:20:22 <vishnu_nk> In this doc https://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html#cross-development-toolchain-generation, they have mentioned that gcc-cross-canadian is the reolocatable cross-compiler generated.
May 17 10:22:56 <vishnu_nk> So even if I'm able to generate any image for my profile, can I use those sdk's instead of my gcc toolchains source and then directly install everything that comes with the sdk?
May 17 10:23:33 <LetoThe2nd> the installation part, you have to elaborate a bit. i failed to understand it.
May 17 10:23:58 <LetoThe2nd> but the first two, yes. you have an image, you have an sdk, so you can build things for the image.
May 17 10:28:18 <vishnu_nk> I will explain a lil bit, Currently I'm buliding my gcc-cross-arm, gcc-cross-initial-arm, gcc-runtime, libgcc from the source. But I dont want to build everything from source everytime. So I want to make the binaries of these packages portable, So that if I download those prebuilt binaries which just needs a do_install() task.
May 17 10:29:17 <vishnu_nk> Since these are prebuilt binaries and I dont have to compile or configure it I can directly perform do_install().
May 17 10:30:11 <LetoThe2nd> have you even read up on sstate as i told you? its *EXACTLY* that.
May 17 10:30:12 <vishnu_nk> So If I want to take prebuilt binaries of those images, Then I need to run populate_sdk() to make the cross-toolchain independent or to dynamically link the cross-toolchain with mpc, mpfr, gmp packages.
May 17 10:30:58 <LetoThe2nd> you build the sstate on one machine, and multiple machines/users use it. they can detect that it is already built, and jump directly to instal.
May 17 10:30:58 <vishnu_nk> LetoThe2nd: Yes. I have read that. It is a bit difficult to understand those features in depth.
May 17 10:31:26 <vishnu_nk> But then how those machines know each other?
May 17 10:31:48 <LetoThe2nd> its all in the article. the user-machines get SSTATE_MIRROR set
May 17 10:32:13 <LetoThe2nd> really, you're hand-reinventing jsut a a tiny part of what is already there.
May 17 10:32:57 <vishnu_nk> Sir I was not able to completely understand the use of sstate-cache.
May 17 10:33:29 <LetoThe2nd> ... which led you to "i don't understand it right now, back to my initial idea even if its a bad one."
May 17 10:33:38 <vishnu_nk> What I understood is that it takes note of the hashes of tasks() to compute whether they need to be rebuild or not
May 17 10:33:58 <LetoThe2nd> the hashes are the detection mechanism if smoehting needs to be rebuilt, yes.
May 17 10:34:12 <vishnu_nk> No No..Parallely I'm reading the sstate stuff
May 17 10:34:58 <LetoThe2nd> *sigh* you know what, i'm off that topic for some time. maybe laters again.
May 17 10:36:09 <vishnu_nk> Regarding sstate cache server: another build machine is needed to produce the sstate file periodically right? So the machines needs to be connected via nfs, http or ftp.
May 17 10:36:36 <yocti> New news from stackoverflow: autostart webserver and programm <https://stackoverflow.com/questions/50388902/autostart-webserver-and-programm>
May 17 10:37:46 <vishnu_nk> But this is applicable if the packages on the both machines have same changes right? If the machine is SSTATE_MIRROR is having some other changes then the tasks wont be skipped right?
May 17 12:16:03 <acrap> Hi folks! I faced with a problem. I can't find bits/libc-lock.h inside a target sysroot.
May 17 12:16:56 <acrap> It is a part of glibc
May 17 13:49:28 <JPEW> rburton: I've been looking at devupstream.bbclass. Would it be possible to use that to track an upstream branch head?
May 17 14:37:45 <yann> hm, in sumo packagegroup-machine-base is not regenerated when PREFERRED_PROVIDER_virtual/kernel changes ?
May 17 15:16:39 <rburton> JPEW: yes
May 17 15:16:47 <rburton> JPEW: assuming you don't need to change a native recipe, currently
May 17 15:17:46 <JPEW> Right. Would that look like: SRCREV_class-devupstream = "refs/heads/master" ?
May 17 15:22:42 <rburton> JPEW: well for srcrev you could just use autorev
May 17 15:23:07 <rburton> if you already clone from git, you don't really need devupstream
May 17 15:27:06 <JPEW> rburton: Ok, AUTOREV looks like what I want (learn something new every day). I was trying to distinguish between "bleeding edge" and a "stable" git SHA1 in the same recipe
May 17 15:27:25 <rburton> have a look at the poky-bleeding distro
May 17 15:27:47 <rburton> back in the days, and by which i mean a decade ago, that was the bulk of the gtk+2/gnome stack built from git HEAD via autorev
May 17 15:28:25 <rburton> if you fetch all your important bits with git anyway, then a conf that just sets SRCREV=AUTOREV for those recipes is trivial
May 17 15:28:26 <JPEW> Ah, awesome that is excatly what I want. Thanks!
May 17 15:28:49 <rburton> i guess this means a new blog/howto
May 17 15:28:58 <rburton> 'how to make a tip build'
May 17 15:29:16 <JPEW> rburton: That would be helpful
May 17 15:29:57 <JPEW> rburton: The harder part is making it return in the first page of a google search ;)
May 17 15:30:03 <rburton> ha
May 17 15:35:48 <khem> except that patches might start being problematic when changing SRCREV to AUTOREV
May 17 15:35:59 <khem> especially backported one
May 17 15:36:19 <JPEW> khem: Ok. Good to know. This is for all internal stuff, so we don't allow patches in the recipes
May 17 15:36:42 <khem> internal happiness is more important yes
May 17 15:37:40 <yocti> New news from stackoverflow: Add a custom executable bash script and its systemd script to Yocto Build <https://stackoverflow.com/questions/50395374/add-a-custom-executable-bash-script-and-its-systemd-script-to-yocto-build>
May 17 15:44:57 <fberg> hello guys, does anybody know how to configure eclipse with a yocto project ? I've followed the howto but still missing information on how to set the toolchain/sysroot path
May 17 15:51:30 <didil> rbutton: if I patch the configure file from pax, it get replace back by the do_configure task
May 17 15:52:14 <rburton> didil: patch configure.ac
May 17 15:52:31 <rburton> (or configure.in)
May 17 15:53:24 <didil> that was stupid indeed ^^
May 17 15:55:38 <u1106> the image manifest seems to contain package names, "oe-pkgdata-util list-pkgs" lists packages. According to my manifest I have "libc6 corei7-64 2.26-r0", but oe-pkgdata-util does not know of any such package. Instead it is called glibc. "oe-pkgdata-util lookup-pkg" can do the translation between recipe space packsge names and runtime package names. But I could not find any documentation of these concepts in the mega manual. Can somebody point me to the right
May 17 15:55:38 <u1106>  place?
May 17 16:06:51 <didil> rbuton: thanks :)
May 17 16:07:46 <yocti> New news from stackoverflow: Modifying core-image-minimal to only make rootfs <https://stackoverflow.com/questions/39531211/modifying-core-image-minimal-to-only-make-rootfs>
May 17 16:28:58 <manuel-> hey folks. i have 2 recipes that conflict with eachother : python3-ndg-httpsclient and python-ndg-httpsclient, they both try to install /usr/bin/ngd_httpclient (which i don't care about). I'm tyring to override installing that file using a bbappend file, and I'm not having much success. is tehre a way to remove an entry from FILES_${PN} ?
May 17 16:29:31 <manuel-> i tried to add FILES_${PN}_remove but that doesn't seem to work
May 17 16:40:44 <u1106> could the problem be that you have several packages in the recipe? FILES_${PN}-foo and FILES_${PN}-bar ? I have had issues before that a file "magically" jumps to another package if you modify one of the list. IIRC the lists are processed sequentially, the first package can "steal" files from the later ones if the paths are general enough. Have you verified the "bitbake -e" output that your remove modifies the correct variable?  I simple type somewhere and
May 17 16:40:44 <u1106> you end up with something different than intended.
May 17 16:42:10 <u1106> s/type/typo/ self-fulfilling...
May 17 16:45:33 <manuel-> i was misparsing the error. i had a do_install_append() { } removing the superfluous files in /usr/bin, but it was leaving /usr/bin behind
May 17 16:45:48 <manuel-> in the end, just do_install_append() { rm -rf ${D}${bindir} } did the trick
May 17 16:45:50 <manuel-> thanks u1106
May 17 16:47:57 <khem> manuel-: the real fix would be rename the file installed by python3 to ngd3_httpclient
May 17 16:48:02 <khem> or something like that
May 17 17:34:44 <khem> rburton: are you still needing some stuff for ovmf
May 17 18:16:29 <joeythesaint> fray: just pushed round one of the meta-selinux updates, at least it builds and boots on two arches for me.  Saw you branched rocko already, so I figured it was safe.  Going to work through the outstanding patches now.
May 17 18:17:29 <joeythesaint> It'd be really nice if the meta-selinux patches were available on patchwork, but I guess we never really did push for that.
May 17 18:18:28 <fray> excellent
May 17 18:18:45 <fray> it was discussed that we can do it.. but we need to ask at the beginning of a patch cycle (which is right now)
May 17 18:18:57 <fray> so i think now is the right time to go to the YP and 'ask'
May 17 18:35:29 <armpit> fray, isn't patchwork an OE thing? maybe MH can help ?
May 17 18:51:20 <fray> armpit, in the ELC OE meetings we talked about it, but there were changes needed to support other projects -- it was decided it needs to be asked for early in the dev cycles to get any help doing it
May 17 18:51:56 <fray> I believe it also needs it's own mailing list for this to work.. (not a big deal)
May 17 19:07:40 <joeythesaint> Yeah, that second one was actually the main issue since we were kind of reluctant to create a mailing list just for meta-selinux and it didn't seem possible to extract just patches tagged with meta-selinux for patchwork.  Something like that, the details are hazy.
May 17 19:08:36 <joeythesaint> I've literally been saying this for closing in on two years but I honestly haven't ever been directly involved in any discussion around it, so, y'know.  I guess it's not something I'm all that passionate about even though I think I am.
May 17 19:11:39 <fray> ya.. whenever a new mailing list, or patchworks was suggested -- it was always in the last 1/3 of the current project and we were asked to wait.. and then waited too long.. ;)
May 17 19:11:46 <fray> so now is the time to ask, even if we need a new mailing list
May 17 19:13:50 * joeythesaint really wishes a separate mailing list wasn't required.
May 17 19:14:40 <joeythesaint> Too many mailing lists just adds to confusion and potential for lost stuff.  And for people missing out on stuff they might otherwise care about.
May 17 19:14:57 <armpit> fray I thought that was in meta-openembedded context with its sublayers.
May 17 19:14:58 <joeythesaint> But I will totally believe that is a technical limitation of that's what you guys say.
May 17 19:16:19 <armpit> patchwork.. get that confused with patchqueue
May 17 19:17:08 <armpit> mine is an old man issue
May 17 19:19:09 <armpit> joeythesaint, maybe a we should open a bug on this
May 17 19:20:13 <armpit> 2.6 planning is underway so seems like a good candidate to add
May 17 19:23:08 <joeythesaint> Yeah, sure, it at least is the right time to ask.  :-)
May 17 19:23:37 <joeythesaint> I'll be happy to open the bug if you guys like.
May 17 19:23:52 <joeythesaint> Probably makes sense because I'm the one whining about it.
May 17 19:29:17 <armpit> joeythesaint, other folks have expressed interest in patchwork being more "portable"
May 17 19:29:36 * armpit lake of a better term
May 17 19:29:53 <armpit> ^lack
May 17 19:43:38 <joeythesaint> Woo, step #1 complete.  I remembered my bugzilla login credentials.
May 17 19:44:29 <joeythesaint> And now that I've gotten that far I discover: https://bugzilla.yoctoproject.org/show_bug.cgi?id=11020
May 17 19:44:30 <yocti> Bug 11020: normal, Medium+, 2.6 M1, michael, NEW , We need a patchwork instance pointing to the Yocto mailing list
May 17 19:44:52 <joeythesaint> Which looks like what I planned to write up anyway.
May 17 19:48:56 * joeythesaint decides fray would probably like to be subscribed to that bug as well, at least.
May 17 19:55:13 <armpit> sweet
May 17 20:00:47 <vishnu_nk> Hi All, Can anyone please tell me why we can't create an sdk package for a recipe? Why sdk's can be created only for images like core-image-minimal?
May 17 20:11:02 <kergoth> an sdk package for a recipe doesn't make sense
May 17 20:11:06 <kergoth> what would be in it?
May 17 20:11:34 <vishnu_nk> like gcc-cross
May 17 20:11:58 <kergoth> gcc-cross is a cross recipe, it isn't packaged at all, so isn't suitable for an sdk
May 17 20:12:15 <kergoth> only crosssdk and nativesdk recipes are packaged for installation in an sdk, and that packaging and installation uses the same mechanisms as image construction.
May 17 20:12:34 <kergoth> erm, cross-canadian, not crosssdk
May 17 20:14:02 <vishnu_nk> So the minimal sdk which I can use to get gcc-cross, libmpc, mpfr etc is the 'core-image-minimal' image?
May 17 20:17:04 <kergoth> or create a recipe to do it, see meta-toolchain for an example
May 17 20:17:30 <vishnu_nk> That will be an excellent idea
May 17 20:17:53 <vishnu_nk> So I can create a recipe with dependencies for packages I need right?
May 17 20:26:44 <kergoth> the variables used to add packages to an sdk are documented in the yocto project documentation. the same vars are used for -c populate_sdk someimage as are used by meta-toolchain
May 17 20:26:55 <kergoth> specifically TOOLCHAIN_HOST_TASK and TOOLCHAIN_TARGET_TASK
May 17 20:27:08 <kergoth> for bits that run on the host the sdk is going on and bits that are for the target, respectively
May 17 20:28:36 <vishnu_nk> Thanks for the info. I will add a new recipe.
May 17 20:35:51 <kergoth> np
May 17 22:04:47 <rburton> khem: yeah can you verify that your gcc8 patches for ovmf apply for you?  i get line end problems here after picking from the branch
May 17 22:05:31 <khem> it applies
May 17 22:05:51 <rburton> grrr line endings of doom
May 17 22:10:07 <rburton> now this is just taking the piss
May 17 22:10:11 <rburton> Applying patch 0001-BaseTools-header.makefile-add-Wno-stringop-truncatio.patch
May 17 22:10:13 <rburton> (Stripping trailing CRs from patch; use --binary to disable.)
May 17 22:10:13 <rburton> patching file BaseTools/Source/C/Makefiles/header.makefile
May 17 22:10:15 <rburton> Hunk #1 FAILED at 47 (different line endings).
May 17 22:18:36 <khem> rburton: can you try git cherry-pick
May 17 22:18:47 <khem> add contrib repo
May 17 22:18:53 <rburton> khem: that's exactly what i did
May 17 22:19:37 <rburton> 1 out of 1 hunk FAILED -- rejects in file BaseTools/Source/C/Makefiles/header.makefile
May 17 22:20:02 <rburton> hm the patch from the pick is mixed encoding
May 17 22:20:38 <khem> hmmm
May 17 22:20:48 <khem> let me try a mock cherrypick
May 17 22:22:37 <khem> rburton: https://gist.github.com/f1f3860855f143abc96fe34be8ed4a8a
May 17 22:22:44 <khem> it works here
May 17 22:22:47 <rburton> ffs
May 17 22:22:57 <rburton> will that build though?
May 17 22:23:02 <rburton> i pick fine, just won't build
May 17 22:23:48 <khem> I only tried with musl/x86 it seems to build
May 17 22:25:35 <rburton> arhg i hate this recipe
May 17 22:25:52 <khem> delete it :)
May 17 22:25:57 <khem> do you want a patch
May 17 22:25:59 <rburton> don't tempt me
May 17 22:26:17 <khem> btw. I pushed another patch to kraj/master to upgrade libxcrypt
May 17 22:26:26 <khem> you might have seen
May 17 22:28:05 <khem> its a minor release just fixing issues I was raising upstream
May 17 22:32:51 <rburton> khem: oh the ovmf patches are missing your S-o-b
May 17 22:38:50 <rburton> khem: http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/commit/?h=ross/mut&id=f855f71c1e7c6e106b6464326204767fd8916f4a
May 17 22:42:03 <rburton> khem: ok something is *really* weird.  if i dos2unix the entire source tree and all the patches, i still get apply failures with your patch
May 17 22:42:59 <khem> SoB :) ok
May 17 22:43:39 <khem> I thought they had original authors SOB
May 17 22:43:54 <rburton> no, patches need your SoB in alongside the upstream-status
May 17 22:44:25 <khem> yes
May 17 22:48:09 <khem> rburton: updated and pushed
May 17 22:48:47 <rburton> thanks
May 17 22:50:30 <rburton> oh you little <expletive>
May 17 22:50:38 <rburton> the first failing patch has
May 17 22:50:43 <rburton>  BUILD_LFLAGS =
May 17 22:50:44 <rburton> as context
May 17 22:50:57 <rburton> but my file has BUILD_LFLAGS = $(LDFLAGS)
May 17 22:52:38 <khem> inherit dos2unix in this damned recipe
May 17 22:53:08 <khem> what version of git do you use
May 17 22:53:17 <rburton> 2.11
May 17 22:53:22 <rburton> but the context isn't matching, that's what is weird
May 17 22:53:35 <khem> hmmm
May 17 22:53:58 <khem> leave it out for now
May 17 22:54:10 <khem> trade it with libxcrypt patch
May 17 22:54:17 <khem> I will take a closer look
May 17 22:54:59 <khem> % git --version                                                                                                                                                                                 kraj/master ⬆ ⬇ ◼
May 17 22:55:01 <khem> git version 2.17.0
May 17 22:55:37 <khem> it seems you are on one of those stable distros eh
May 17 22:55:50 <rburton> yeah debian
May 17 22:56:23 <khem> OK
May 17 22:56:36 <khem> but if the context is not applying that should be quilt issue
May 17 22:56:50 <khem> and we use quit-native of our own
May 17 22:56:51 <rburton> the patch context doesn't match what is on disk
May 17 22:57:02 <rburton> which leads me to say whaaaaaaat
May 17 22:57:04 <khem> OK
May 17 22:57:13 <rburton> anyway i'm going to bed its midnight
May 17 22:58:10 <khem> 2 more mins to go :)
May 17 22:58:14 <khem> good night
May 17 23:15:16 <khem> armpit: around ?
May 17 23:21:59 <khem> armpit: I have started rebasing myself on top of your stagging/next
May 18 00:09:26 <yocti> New news from stackoverflow: Deploying Django app on Yocto <https://stackoverflow.com/questions/46587441/deploying-django-app-on-yocto>
**** ENDING LOGGING AT Fri May 18 03:00:03 2018