**** BEGIN LOGGING AT Mon Aug 13 03:00:00 2018
Aug 13 04:10:06 <yocti> New news from stackoverflow: Ca't install my own syslog's syslog-startup.conf via Yocto <https://stackoverflow.com/questions/51804055/cat-install-my-own-syslogs-syslog-startup-conf-via-yocto>
Aug 13 07:36:32 <khem> RP: the size increase is due to this feature https://fedoraproject.org/wiki/Changes/Glibc_collation_update_and_sync_with_cldr and also explained here  https://bugzilla.redhat.com/show_bug.cgi?id=1551073
Aug 13 07:36:33 <yocti> Bug 1551073: was not found.
Aug 13 07:37:08 <khem> RP: I think its a compromise thats was so far deferred
Aug 13 07:38:47 <khem> https://sourceware.org/bugzilla/show_bug.cgi?id=14095
Aug 13 07:38:48 <yocti> Bug 14095: was not found.
Aug 13 07:39:09 <khem> it was open since 2.15
Aug 13 07:50:32 <RP> khem: hmm. Not a lot we can do about that I guess
Aug 13 07:50:50 <RP> khem: I started wondering about http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=de4b8febd8ae1c57742bd3452b6889814b2fd3ef for images...
Aug 13 07:51:12 <RP> khem: I also tried fixing sparse files but that doesn't seem to save enough as yet
Aug 13 08:03:52 <khem> RP: for completeness I think the SDK fix is right
Aug 13 08:06:11 <RP> khem: the kernel-devsrc improvements may also save us some space. Good news is that if we fix this, I think all the tests in core are good for the new glibc
Aug 13 08:07:49 <khem> may be we can say that we only support limited locales for SDK for nativesdk and then just ship may be en_US.UTF-8
Aug 13 08:07:58 <khem> and remove rest
Aug 13 08:10:49 <yocti> New news from stackoverflow: Yocto - Building a SELinux image - RPM Package compilation Error <https://stackoverflow.com/questions/51817642/yocto-building-a-selinux-image-rpm-package-compilation-error>
Aug 13 08:14:04 <lukma> Maybe somebody could help me
Aug 13 08:14:12 <lukma> I do have a non standard problem
Aug 13 08:14:35 <lukma> I do need to run ./configure to build my package
Aug 13 08:15:30 <lukma> the problem is that this package's configure requires some JDK to be installed (otherwise the configure fails).
Aug 13 08:16:44 <bluelightning> lukma: wouldn't the recipe just need something that puts the JDK into the sysroot in DEPENDS (i.e. a JDK recipe)?
Aug 13 08:17:19 <lukma> I've added to the recipe DEPENDS = "openjdk-7" , but the log.task_order only shows do_fetch , do_unpack, do_configure
Aug 13 08:17:49 <lukma> and the stuff normally installed by openjdk-7 is not visible in the recipe for ./configure ......
Aug 13 08:18:31 <lukma> I've always thought that DEPENDS = "foo" is equal to foo:do_install and the needed libs, binaries are copied to my recipe's sandbox ?
Aug 13 08:19:06 <lukma> bitbake -e foo | grep ^DEPENDS also shows that openjdk-7 is there
Aug 13 08:21:48 <lukma> bluelightning: So I don't know what is going on really (and I do use morty 2.2)
Aug 13 08:23:55 <bluelightning> lukma: it effectively means do_populate_sysroot for the other recipe (there's a little more to it than that, but that's not important here)
Aug 13 08:24:11 <bluelightning> lukma: you won't see tasks for any other recipes in log.do_task_order
Aug 13 08:25:10 <lukma> bluelightning: But this means that the do_populate_sysroot for openjdk-7 is not working properly?
Aug 13 08:25:45 <lukma> (And probably the rootfs stuff has been installed in do_install of this task) ?
Aug 13 08:26:34 <bluelightning> lukma: not necessarily
Aug 13 08:26:50 <bluelightning> lukma: ultimately you'd need to find out what the recipe's configure script is trying to do i.e. what file is it looking for or what binary is it calling, then look at the files in the sysroot to determine why they don't match up to its expectations
Aug 13 08:27:15 <lukma> bluelightning: The file needed is rt.jar
Aug 13 08:27:16 <bluelightning> it may be that the configure script is looking in the wrong path - this is common for software that doesn't expect to be built with a sysroot
Aug 13 08:27:38 <bluelightning> I don't know enough about openjdk to know if it provides that, sorry
Aug 13 08:28:00 <lukma> bluelightning: Ok, I will check that......
Aug 13 08:28:24 <lukma> and yes, the script is only tested (supposed to work) on x86_64 with native compilation .....
Aug 13 08:37:17 <Alex___> hi guys
Aug 13 08:37:33 <Alex___> is there any way I can get the output from bitbake of d.getVar?
Aug 13 08:37:44 <Alex___> eg: bitbake d.getVar('x) ?
Aug 13 08:39:56 <bluelightning> Alex___: bitbake -e | grep ^VARNAME=
Aug 13 08:52:55 <Alex___> thanks bluelightning
Aug 13 08:53:14 <RP> bluelightning: unless its exported. Really need to add better API... :/
Aug 13 08:53:34 <bluelightning> RP: right yes... https://bugzilla.yoctoproject.org/show_bug.cgi?id=10748
Aug 13 08:53:35 <yocti> Bug 10748: enhancement, Medium+, Future, richard.purdie, NEW , Means of querying history for a single variable
Aug 13 08:54:06 <bluelightning> writing that script probably wouldn't take long
Aug 13 08:54:29 <RP> bluelightning: indeed particularly with tinfoil these days
Aug 13 09:27:19 * RP ponders ways to clear space in core-image-lsb-sdk
Aug 13 09:27:34 <RP> locales taking up over 900MB seems like the place to start :/
Aug 13 09:41:06 <yocti> New news from stackoverflow: Building a SELinux image - RPM Package compilation Error <https://stackoverflow.com/questions/51817642/building-a-selinux-image-rpm-package-compilation-error>
Aug 13 13:47:13 <golledge> hi, I am trying to add a rootfs image to /boot partition of a wic image. I have added the image to the IMAGE_BOOT_FILES but it seems like the ext3 file is not in the deploy folder. Has anyone doen this before or know what i am missing.
**** BEGIN LOGGING AT Mon Aug 13 17:38:57 2018
Aug 13 20:10:31 <lukma> I was wondering about one thing
Aug 13 20:10:56 <lukma> Would it be possible to emulate native host build of recipe?
Aug 13 20:11:19 <lukma> I mean to avoid cross compilation, but provide for it the native environment ?
Aug 13 20:11:52 <lukma> Some packages are very difficult to move from native compilation to cross compilation
Aug 13 20:12:28 <kergoth> no, we can't avoid cross-compilation by building in qemu or on device at this time
Aug 13 20:12:57 <neverpanic> lukma: The biggest problem with that is that build systems may expect to be able to run binaries that were just compiled in native builds.
Aug 13 20:15:02 <neverpanic> We (as in $employer) have done some work to make the cross-compiler the default in some environments, which does make cross-compiling very easy, but there are also some downsides to that, and we still have to do proper cross-compiling in bitbake recipes.
Aug 13 20:17:47 <lukma> The problem is that large ./compile file needs a lot of tunning to provide --sysroot here and there
Aug 13 20:18:44 <lukma> also the problem with libraries...... ld: cannot find crt1.o: No such file or directory
Aug 13 20:19:41 <neverpanic> Welcome to cross-compiling.
Aug 13 20:20:05 <neverpanic> If it's a large project, look for cross-compiling instructions by other distributions.
Aug 13 20:20:21 <neverpanic> If it isn't, consider re-writing their buildsystem in something that natively supports cross-compiling
Aug 13 20:21:48 <lukma> neverpanic: Yeah..... NIH principle :D
Aug 13 20:22:30 <lukma> But I personally prefer "reuse" as much as possible :)
Aug 13 20:23:36 <neverpanic> lukma: ./compile really sounds like a self-written build system. I'd consider that NIH already, and that's likely your problem.
Aug 13 20:24:01 <neverpanic> All build systems suck, but those that have been sucking for a long time (autotools, cmake, and the most recent contender, meson) all get this right
Aug 13 20:35:49 <lukma> Strange...... as it is very comprehensive autotools configure script
Aug 13 20:49:08 <rburton> lukma: then they're doing autotools wrong.  if the build wants to build a binary to run on the *build host* then the idiom is to use CC_FOR_BUILD from autoconf-archive
Aug 13 20:51:03 <lukma> rburton: The problem is a bit more subtle....
Aug 13 20:51:28 <lukma> the configure script (from autotools) was tunned for host builds
Aug 13 20:51:37 <lukma> and some odd errors pop up from here and there
Aug 13 20:51:38 <rburton> well that's wrong isn't it
Aug 13 21:01:01 <lukma> rburton: Yes, it is :)
Aug 13 21:43:17 <yocti> New news from stackoverflow: bitbake task to run openocd <https://stackoverflow.com/questions/51830795/bitbake-task-to-run-openocd>
Aug 13 23:03:41 <RP> khem: I tried with the locales, ended up with https://autobuilder.yocto.io/builders/nightly-x86-lsb/builds/1212/steps/BuildImages/logs/stdio which I'll have to dig into tomorrow
**** ENDING LOGGING AT Tue Aug 14 03:00:01 2018