**** BEGIN LOGGING AT Mon Oct 08 03:00:01 2018
Oct 08 09:35:53 <Kitsok> Hi there! Got a question regarding ntp recipe. I can't get how to force it to install ntpq to the target image. Give me a hint plz
Oct 08 09:46:14 <LetoThe2nd> Kitsok: not having checked it thoroughly, but the recipe suggests ntp-utils
Oct 08 10:03:25 <Kitsok> LetoThe2nd, yea, but bitbake claims there is no ntp-utils recipe
Oct 08 10:03:55 <LetoThe2nd> Kitsok: there is no ntp-utils recipe, but a ntp-utils package. the ntp recipe provides both.
Oct 08 10:04:54 <Kitsok> LetoThe2nd, so if I have "ntp" in IMAGE_INSTALL_append I should have ntp in the target rootfs, correct?
Oct 08 10:05:32 <Kitsok> Correction "have ntpq in the target rootfs"
Oct 08 10:05:32 <LetoThe2nd> Kitsok: assuming that you have set that IMAGE_INSTALL_append at a proper place, then yes.
Oct 08 10:05:39 <LetoThe2nd> no.
Oct 08 10:05:56 <LetoThe2nd> IMAGE_INSTALL_append = " ntp-utils"
Oct 08 10:06:31 <LetoThe2nd> package != recipe. a recipe can provide multiple packages. IMAGE_INSTALL takes package names, whereas bitbake takes recipe names.
Oct 08 10:06:59 <Kitsok> LetoThe2nd, I see, will give it a try
Oct 08 10:07:28 <Kitsok> Gotcha! Thank you, LetoThe2nd!
Oct 08 10:07:52 <LetoThe2nd> have fun
Oct 08 12:20:00 <Marex> is there a reason why the nodejs modules are installed into ${libdir}/node_modules instead of ${libdir}/node ? I am told the later is the standard path which nodejs expects ...
Oct 08 12:59:44 <PinkSnake> I all, i'm currently working with Yocto based on sumo branch, Ubuntu 18.04 is not tested but I want to use this version, so I have some trouble during the first build ( *** These critical programs are missing or too old: GNU ld ) any hint ? :-) cheers
Oct 08 13:31:40 <mcfrisk> PinkSnake: start with https://www.yoctoproject.org/docs/2.5.1/brief-yoctoprojectqs/brief-yoctoprojectqs.html#brief-compatible-distro
Oct 08 13:35:50 <PinkSnake> >mcfrisk as I said i doesn't to downgrade to 17.04 ...
Oct 08 13:36:45 <PinkSnake> mcfrisk: as I said i doesn't to downgrade to 17.04 ...
Oct 08 13:38:06 <LetoThe2nd> PinkSnake: 1) this document also should point out what you might have missed to install 2) you can always go for a container, like docker to run a different distro for building
Oct 08 13:39:06 <PinkSnake> hi LetoThe2nd all dep is installed, the trouble is about binutils version
Oct 08 13:40:38 <PinkSnake> as i can't install bother version of binutils I don't know what I can do to fi poky :(
Oct 08 13:42:52 <LetoThe2nd> PinkSnake: you can test wirh master, if it works there, then bisect. thats the only thing that comes to my mind instantly.
Oct 08 13:43:39 <PinkSnake> @LetoThe2nd what do you mean about wirh master ? o.0
Oct 08 13:44:17 <PinkSnake> ok with master branach of poky i got it ;)
Oct 08 13:44:26 <PinkSnake> thx for hint i will make a try
Oct 08 13:53:05 <PinkSnake> LetoThe2nd: same issue... It's strange because of ubuntu 17.04 is already in end of life state...
Oct 08 13:54:11 <LetoThe2nd> PinkSnake: and this is a totally vanilla sumo on a totally vanilla 18.04?
Oct 08 13:55:47 <PinkSnake> LetoThe2nd: yes i have a fresh ubuntu 18.04 install from official website, with sumo branch on all meta :(
Oct 08 13:56:22 <PinkSnake> LetoThe2nd: do you know if an external toolchain can do the trick ?
Oct 08 13:59:00 <LetoThe2nd> PinkSnake: that just sounds kinda wrong.
Oct 08 13:59:30 <LetoThe2nd> PinkSnake: I'll give it some testing, but please elaborate what "all meta" means? what layers are you using?
Oct 08 14:01:44 <PinkSnake> LetoThe2nd: https://pastebin.com/vkpvdKPr
Oct 08 14:02:04 <PinkSnake> LetoThe2nd I have also tested with master branch
Oct 08 14:02:33 <LetoThe2nd> OMG
Oct 08 14:03:01 <PinkSnake> LetoThe2nd: it's so bad ? ^^
Oct 08 14:03:25 <LetoThe2nd> i'll give it a try with poky alone, but if that successfully builds core-image-minimal (which i kinda guess!) then i'd say its your own task to figure out which layer breaks your build
Oct 08 14:05:47 <rburton> PinkSnake: what actually fails? can you pastebin the log
Oct 08 14:09:29 <PinkSnake> rburton: https://pastebin.com/crpTAjcW
Oct 08 14:10:01 <PinkSnake> rburton: many recipes failes because of ld version (2.30 seems not supported by the yocto project...)
Oct 08 14:17:50 <LetoThe2nd> ok, kicked off sumo aarch64 build on 18.04 docker. lets see what happens.
Oct 08 14:28:58 <JaMa> rburton: doesn't empty Subject break devtool manipulation with .patch files?
Oct 08 14:33:39 <LetoThe2nd> PinkSnake: 1485 of 2373 tasks and counting, no errors (yet)
Oct 08 14:33:49 <rburton> JaMa: hm will revise with something in there
Oct 08 14:34:47 <rburton> PinkSnake: thats not ld, that's uninative breaking.  try INHERIT_remove = "uninative"
Oct 08 14:36:38 <rburton> JaMa: resent
Oct 08 14:38:58 <JaMa> rburton: thanks
Oct 08 14:39:09 <rburton> wasn't aware of that, will keen an eye out
Oct 08 14:50:22 <lukma> If I may ask -> In Yocto/OE the gcc for cross compiled device is a link to arm-poky-linux-gcc ...... -march= xxx -sysroot=/.......
Oct 08 14:50:36 <lukma> is there a way to extend this line with extra linker option?
Oct 08 14:50:49 <lukma> I do have a legacy package, which in makefile on the beginning
Oct 08 14:50:54 <lukma> sets LDFLAGS=
Oct 08 14:51:25 <LetoThe2nd> lukma: you should be perfectly able to modify LDFLAGS in your recipe as you wish
Oct 08 14:51:36 <lukma> and I do have an issue with fixing QA error of do_package_qa: QA Issue: No GNU_HASH in the elf binary:
Oct 08 14:52:21 <lukma> EXTRA_OEMAKE = "LDFLAGS=${LDFLAGS}" is not working
Oct 08 14:53:19 <lukma> LetoThe2nd: the makefile still generated the executables with HASH (not GNU_HASH) section
Oct 08 14:53:44 <mcfrisk> lukma: fix the Makefile with a patch to do LDFLAGS+= instead of plain assignment
Oct 08 14:55:10 <lukma> mcfrisk: Yes, this is one solution
Oct 08 14:55:36 <lukma> but I was wondering if there is some kind of OE/Yocto fix, so I wouldn't need to fix the recipe itself
Oct 08 14:56:50 <rburton> lukma: its a problem in makefile
Oct 08 14:57:08 <rburton> you can use make -e to override the makefile definitions with environment but then you just have other problems instead
Oct 08 14:57:14 <rburton> so, fix makefile, send fix upstream
Oct 08 14:57:50 <lukma> rburton: Ok, thanks -> I wanted to be sure
Oct 08 15:06:33 <rburton> lukma: basic problem with upstreams that think plain make is 'easy'
Oct 08 15:08:28 <LetoThe2nd> rburton: yeah, and once they realize plain make is kinda meh, they start writing custom simplification wrapper scripts around it.
Oct 08 15:11:22 <JaMa> or just refuse to touch it at all, because it's too complicated and nobody understands why those things are done that way
Oct 08 15:12:47 <JaMa> rburton: heh v1 of your .patch change was just merged to master
Oct 08 15:12:51 <rburton> damnit!
Oct 08 15:13:01 <rburton> i'll rebase :)
Oct 08 15:15:00 <rburton> RP: sent another libx11 patch, and can you fix the double colon in the util-linux message as it's bothering me :)
Oct 08 15:15:23 <RP> rburton: I actually merged some of those as they looked safe :/
Oct 08 15:20:58 <PinkSnake> rburton: thx for the hint i will make a try
Oct 08 15:21:09 <PinkSnake> LetoThe2nd: thx a lot!
Oct 08 15:23:11 <LetoThe2nd> PinkSnake: just the very moment you said that, my build completed: successfully
Oct 08 15:23:41 <LetoThe2nd> vanilla 18.04 in docker, just downloaded the requirements from the quickstart and generated en_US.UTF-8 locale
Oct 08 15:23:55 <LetoThe2nd> successfully built core-image-minimal for aarch64
Oct 08 15:24:31 <LetoThe2nd> hence, my gut feeling is that something in your layer collection does magic that breaks things. some tinkering to the toolchain system, maybe.
Oct 08 15:27:41 <lukma> rburton: The problem is that LDFLAGS set in OE
Oct 08 15:27:55 <lukma> pass LDFLAGS=-Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed
Oct 08 15:28:05 <rburton> lukma: no, the problem is that the makefile doesn't extend LDFLAGS but override it
Oct 08 15:28:18 <lukma> but the -Wl,--as-needed part causes build break of the whole program
Oct 08 15:28:26 <lukma> that is why it was overriden
Oct 08 15:28:58 <fray> if as-needed breaks the build (of anything) -- unless dl-open is needed, that indicates a so dependency issue
Oct 08 15:29:19 <fray> (so - shared object)..  usually you want to fix the dep issue, cause it'll cause other problems eventually
Oct 08 15:30:15 <RP> rburton: fired a -next with a few patches in
Oct 08 15:38:54 <PinkSnake> LetoThe2nd: ok great new, so the trouble is on my side... could please share a little about your config ?
Oct 08 15:39:57 <rburton> PinkSnake: still convinced that the problem is the uninative thing, turn off uninative to test
Oct 08 15:40:39 <PinkSnake> rburton: yes I have had your hint to my conf/local.conf, with a -c cleanall same issue ... maybe i have to delete all cache ?
Oct 08 15:40:56 <rburton> i'd definitely wipe your tmp
Oct 08 15:41:09 <PinkSnake> rburton: i copy that
Oct 08 15:41:24 <rburton> but that will at least change the error message
Oct 08 15:43:03 <PinkSnake> rburton: thanks for support! tmp cleaned, building in progress
Oct 08 16:17:05 <PinkSnake> rburton: LetoThe2nd: same issue after deleting tmp folder + INHERIT_remove = "uninative" in conf/local.conf --> https://pastebin.com/YzrtB8Rm  || I will try to delete cache and sstate-cache ... finger crossed
Oct 08 16:26:41 <rburton> PinkSnake: log still says /home/nicolas/peepoo_Disk/grayjay-yocto/build_zcu102/tmp/sysroots-uninative/ which suggests your remove didn't work
Oct 08 16:27:00 <rburton> i'd suggest just doing a bare poky build and seeing if that fails the same way
Oct 08 16:51:00 <PinkSnake> rburton: I have delete tmp, cache and sstate-cache, just source conf/local.conf and run bitbake core-image-minimal, my conf/local.conf could put this mess ?
Oct 08 18:15:54 <FrostEyes_P1> Hi folks. Creating a custom proprietary layer, and was wondering about the "COPYING.MIT" being generated by the yocto-layer scripts.
Oct 08 18:16:51 <FrostEyes_P1> As I understand the COPYING file is optional, but what would be the prefered way of handling it in a proprietary layer. Remove the COPYING.MIT file, and create a LICENSE file?
Oct 08 18:17:37 <luneff> hey guys! I got different kind of question :-) is there a way to show up some image instead of black console login prompt whenever the EGLFS app isn't running?
Oct 08 18:18:17 <luneff> I thought about creating some qtwayland compositor that just happens to have some image background which is obscured by the running app if it's there, but that seems way to complex for the job
Oct 08 18:19:08 <luneff> (that's pi3/meta-qt5)
Oct 08 18:26:24 <luneff> maybe, some image viewer within inittab instead of getty...
Oct 08 18:59:21 <derRichard> hmm, how can i enable asan for a recipe?
Oct 08 18:59:31 <derRichard> so far it fails with ...cannot find -lasan
Oct 08 19:00:20 <luneff> add it to DEPENDS, maybe?
Oct 08 19:00:51 <derRichard> luneff: what shall i add? libasan? libsanitizer?
Oct 08 19:01:24 <luneff> whatever the package containing libasan is called
Oct 08 19:01:38 <derRichard> well, it is a gcc feature. so it is not a package itself
Oct 08 19:12:18 * derRichard tries to make sense of meta/recipes-devtools/gcc/gcc-sanitizers.inc
Oct 08 19:13:03 <luneff> oh. last time I saw something similar, I just set security flags to "" so my recipe could compile
Oct 08 19:13:45 <derRichard> in my case i want to enable libasan to hunt down a bug :)
Oct 08 19:13:48 <derRichard> hm, security flags
Oct 08 19:13:51 <derRichard> let me see
Oct 08 19:17:32 <derRichard> ok, i need to depend on "gcc-sanitizers"
Oct 08 19:17:41 <derRichard> stupid me :D
Oct 08 19:26:08 <neverpanic> derRichard: Last time I tried this it was a handful since it's only really useful when you compile all library dependencies with ASAN, too, and you'll have to do a lot of filtering to get the ASAN flags out of the bootstrapping stuff, but it can be done
Oct 08 19:26:39 <neverpanic> Of course YMMV if you don't need ASAN all the way down the call stack
Oct 08 19:58:44 <derRichard> i don't want to build a kernel in my yocto project. but it always tries to build make-mod-scripts, which fails badly since no kernel source/config is present
Oct 08 19:58:47 <derRichard> how comes?
Oct 08 20:17:09 <derRichard> oh dear! tools-profile selects lttng-modules, which selects make-mod-scripts...
Oct 08 21:33:58 <Marex> is there a reason why the nodejs modules are installed into ${libdir}/node_modules instead of ${libdir}/node ? I am told the later is the standard path which nodejs expects ...
Oct 08 22:05:50 <lukma> Is there any way to fix this: Hunk #1 FAILED at 37 (different line endings).
Oct 08 22:06:08 <lukma> I do have a recipe's Makefile developed on Windows
Oct 08 22:06:17 <lukma> and I need to apply patches to it from Linux.....
Oct 08 22:06:30 <lukma> even if I modify the needed stuff, and all seems to be correct
Oct 08 22:06:34 <lukma> I do see following issie
Oct 08 22:06:41 <lukma> s/issie/issue
Oct 08 22:09:52 <robbawebba> lukma: It sounds like the original source has different line endings than the patch you're trying to apply
Oct 08 22:10:10 <kergoth> god i missed my mechanical keyboard while iw as on vacation
Oct 08 22:10:17 <kergoth> using my macbook pro keyboard for 17 days? screw that
Oct 08 22:10:33 <kergoth> going to *make* space in the luggage next trip
Oct 08 22:19:23 <lukma> robbawebba: Yes, it has
Oct 08 22:19:36 <lukma> I've tried to delete the Makefile (whole)
Oct 08 22:19:40 <lukma> and then replace it with new one
Oct 08 22:20:02 <lukma> quilt also was complaining about different line endings (even when whole file was replaced)
Oct 08 22:21:48 <lukma> I need to do this change from OE
Oct 08 22:22:04 <lukma> best, no need to touch the original code -> just 2 lines change of Makefile
Oct 08 22:35:40 <robbawebba> What about the patch file? Are you able to generate a new patch file with the same line endings as the new Makefile
Oct 08 22:35:59 <robbawebba> lukma: and jut to clarify, the patch is being applied to the Makefile?
Oct 08 22:38:05 <lukma> Yes, it is a fix for Makefile
Oct 08 22:38:29 <lukma> The best approach would be to convert patch to use the same endings
Oct 08 22:38:36 <lukma> dos2unix or unix2dos
Oct 08 22:38:44 <lukma> and then try to apply it
Oct 08 22:38:57 <lukma> it may work as the patch itself will be stored anyway
Oct 08 22:39:17 <Marex> kergoth: I love my new-ish thinkpad
Oct 08 22:39:32 <Marex> kergoth: I was so stupid to buy a macbook before, I should've stuck with the thinkpads
Oct 08 22:39:48 <Marex> kergoth: the apple keyboards are garbage
Oct 08 22:40:05 <kergoth> I'm stuck on osx for a variety of reasons at t his point, invested, so even if the hardware isn't quite up to par, not ready to migrate back to windows
Oct 08 22:40:22 <Marex> kergoth: hackintosh still a thing ? >:-)
Oct 08 22:40:25 <kergoth> thankfully i use an external keyboard more often than not regardless of what machine i'm using
Oct 08 22:40:32 <Marex> kergoth: yeah
Oct 08 22:40:53 <Marex> lukma: s/\r$// or something ?
Oct 08 22:41:32 <lukma> Marex: May be the trick
Oct 08 22:41:59 <lukma> For thinkpads -> Only with docking station
Oct 08 22:42:04 <lukma> external keyboard + monitor
Oct 08 22:42:08 <lukma> + pad for the laptop
Oct 08 22:42:50 <robbawebba> lukma: this might be a noobish question about pathes, but can there be different line-ending characters in the patch file? I.e. the patch contents (code that's applied to the existing code) has line endings, and then the patch file itself has it's own line endings like a regular text file?
Oct 08 22:43:36 <kergoth> https://photos.app.goo.gl/cLDKJ4VegzndZ5yK7 - workspace using the work laptop. <3 this little keyboard so much
Oct 08 22:44:58 <robbawebba> kergoth: sweet setup! Is that a Dell XPS?
Oct 08 22:46:29 <fischerm> Marex: once you start writing your own OSX drivers you begin hating yourself for hackintoshing. Ask me how I know.
Oct 08 22:47:02 <kergoth> precision 5520 actually. pretty similar, the more business focused version
Oct 08 22:47:36 <kergoth> hackintoshing does sound like a lot pf ain
Oct 08 22:47:39 <kergoth> of pain, even
Oct 08 22:47:52 <fischerm> yeah
Oct 08 22:48:06 <fischerm> recently needed a macos platform to develop on for pcie, so I made it work ... lol
Oct 08 22:48:22 <fischerm> it ain't pretty
Oct 08 23:23:51 <Marex> lukma: you can connect everything over USB-C today anyway
Oct 09 00:06:48 <Marex> is there a reason why the nodejs modules are installed into ${libdir}/node_modules instead of ${libdir}/node ? I am told the later is the standard path which nodejs expects ...
Oct 09 00:58:56 <yocti> New news from stackoverflow: Manually building a Kernel source from Yocto build <https://stackoverflow.com/questions/47429670/manually-building-a-kernel-source-from-yocto-build>
Oct 09 01:26:20 <khem> building a new image for bbb today some issues ..
Oct 09 01:26:32 <khem> denix: sent a patch for you to review and apply
**** ENDING LOGGING AT Tue Oct 09 02:59:59 2018