**** BEGIN LOGGING AT Tue Dec 04 03:00:15 2018
Dec 04 03:22:43 <robbawebba> gnac: might it be a Linux kernel issue related to your SoC? I'm currently working on an Atom (CherryTrail) platform and /proc/timer_list shows resolution of 1 nsecs. I'm on a 4.9.% kernel. Built with Yocto.
Dec 04 03:23:27 <robbawebba> gnac: cherrytrail z8550
Dec 04 03:26:06 <robbawebba> gnac: possibly a BIOS issue as well? I'm not sure if the BIOS handles initialization of the clock timers, but that's another difference I can think of between running in VirtualBox and running on hardware
Dec 04 05:33:58 <gnac> robbawebba: yeah, I was thinking along those two lines as well. We have a patch to apply related to the platform and debugging support, might address other issues as well.
Dec 04 05:34:11 <gnac> Also going to look at the BIOS in the morning. thanks.
Dec 04 07:44:12 <webreformer> I want to do remote debugging using gdbserver. I tried to generate SDK environment and used remote debugging but  debug symbols are around 14GB and even on host machine it is not loading it.
Dec 04 07:46:27 <webreformer> > Reading symbols from /usr/lib/libcbe.so...
Dec 04 07:46:27 <webreformer> warning: the debug information found in "/usr/lib/.debug/libcbe.so" does not match "/usr/lib/libcbe.so" (CRC mismatch).
Dec 04 07:47:18 <webreformer> I would like to know exact steps for cross remote debugging.
Dec 04 07:47:54 <webreformer> Any suggestion or resources will be helpful. Thanks.
Dec 04 07:51:33 <pepijndevos> Can I make changes to a git recipe? Or do I have to push them first...
Dec 04 07:53:45 <LetoThe2nd> pepijndevos: you can, as usual, just use EXTERNALSRC respectively the devtool magic that wraps it.
Dec 04 08:01:09 <webreformer> pepijndevos : devtool modify <receipe-name>
Dec 04 08:40:41 <T_UNIX> hi
Dec 04 08:41:30 <T_UNIX> I assume that the official buildbot/ci runs massively parallel?
Dec 04 08:48:03 <pepijndevos> oh, thanks. I was unaware of devtool magic. The one time I tried to use devtool it failed, so I've been doing normal builds.
Dec 04 09:03:31 <Marex> OK, so I updated to linux-yocto 4.19 and now scc marks CONFIG_SOC_IMX53 in invalid.cfg
Dec 04 09:03:43 <Marex> that doesn't make any sense, since that config option ends up in the kernel .config
Dec 04 10:31:51 <kanavin> rburton: yep, I'm still at a loss as to how systemtap-native should be fixed - hints welcome
Dec 04 10:33:05 <kanavin> RP: right :)
Dec 04 10:59:14 <eduardas_m> hello, what is the proper way to deal with setting the license and doing a check with LIC_FILES_CHKSUM when the original source tarball does not come with a COPYING type license file?
Dec 04 10:59:59 <eduardas_m> I am currently trying to properly define the licensing information for the mksh shell 56 release
Dec 04 11:00:07 <LetoThe2nd> eduardas_m: look into the sources, usually there are some copyright notices in the header
Dec 04 11:00:27 <LetoThe2nd> then you can checksum those snippets
Dec 04 11:02:08 <eduardas_m> LetoThe2nd: makes sense, but that kinda does not cover the case if someone changes the license for some source files and not others
Dec 04 11:02:49 <eduardas_m> though that might be very unlikely for some projects
Dec 04 11:02:59 <LetoThe2nd> eduardas_m: alternatively, you can checksum a part of README, INSTALL, whatever, that states the projects license as a whole
Dec 04 11:03:17 <LetoThe2nd> i mean, it must be noted somewhere
Dec 04 11:03:38 <LetoThe2nd> because if not, it must be considered proprietary.
Dec 04 11:03:56 <rburton> eduardas_m: if you're genuinely concerned that the licensing will vary per-file then the solution is to checksum all the source headers
Dec 04 11:04:05 <eduardas_m> LetoThe2nd: funny thing is in the case of mksh it has neither, closest thing is the mksh.1 file
Dec 04 11:04:05 <rburton> otherwise i tend to just checksums the 'main' sources
Dec 04 11:04:41 <rburton> well, that's what you'll have to checksum then.  might want to tell them to add a proper license statement too :)
Dec 04 11:05:50 <LetoThe2nd> l
Dec 04 11:06:25 <eduardas_m> rburton: main.c it is then for now :) I probably should mail the maintainer about this
Dec 04 11:09:07 <kanavin> this is the license for mksh https://www.mirbsd.org/TaC-mksh.txt
Dec 04 11:09:24 <kanavin> it's basically bsd
Dec 04 11:09:58 <eduardas_m> kanavin: poky common-licenses actually contains a MirOS license
Dec 04 11:10:08 <eduardas_m> that is what I intend to mark the recipe as
Dec 04 11:10:35 <eduardas_m> though the stuff on the main website lists more licensing info
Dec 04 11:10:46 <eduardas_m> not sure how that should be handled
Dec 04 11:13:01 <eduardas_m> well, the UCB and ISC licenses are also among common-licenses. I expect I can use multiple licenses for a recipe in Yocto?
Dec 04 11:13:29 <eduardas_m> I do not ship the icons, so I guess I do not need to worry about those
Dec 04 11:14:01 <kanavin> rburton: can you give this a spin on AB? http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=akanavin/perl-sanity
Dec 04 11:14:11 <rburton> sire
Dec 04 11:14:12 <rburton> sure
Dec 04 11:16:49 <rburton> kanavin: as a sanity run, just fired it on x86-64. when that goes green we can hit the entire AB.  https://autobuilder.yoctoproject.org/typhoon/#/builders/73/builds/56
Dec 04 11:17:07 <rburton> kanavin: still concerned about the lack of perl-native though
Dec 04 11:17:30 <kanavin> rburton: yes, a lot of places assume that, but I like having a single recipe
Dec 04 11:17:37 <rburton> using it less is good, so the dpkg change is probably a good thing anyway
Dec 04 11:17:48 <rburton> but intltool needs non-standard C perl modules
Dec 04 11:17:50 <kanavin> there is a perl-native, just not as a separate recipe file
Dec 04 11:22:55 <rburton> kanavin: oh right, so why was stuff breaking then?
Dec 04 11:23:09 <rburton> (didn't really pay a huge amount of attention obviously)
Dec 04 11:24:52 <kanavin> rburton: because RDEPENDS = "perl" only works for native recipes, when perl-native is a separate recipe
Dec 04 11:25:15 <kanavin> rburton: otherwise you need to set RDEPENDS_class-native = "" and DEPENDS = "perl"
Dec 04 11:25:16 <rburton> huh
Dec 04 11:25:27 <kanavin> we do it in many places for python modules as well
Dec 04 11:25:52 <rburton> i thought the py stuff should have been sorted when the provides were syncronised
Dec 04 11:31:59 <rburton> well the less we build perl-native the better
Dec 04 11:35:04 <kanavin> it's not a heavy build though
Dec 04 11:35:46 <kanavin> Error:
Dec 04 11:35:46 <kanavin>  Problem: package packagegroup-core-sdk-1.0-r9.0.qemux86_64 requires perl-module-text-wrap, but none of the providers can be installed
Dec 04 11:35:46 <kanavin>   - conflicting requests
Dec 04 11:35:46 <kanavin>   - nothing provides perl-module-strict needed by perl-module-text-wrap-5.28.0-r0.0.core2_64
Dec 04 11:35:46 <kanavin>   - nothing provides perl-module-vars needed by perl-module-text-wrap-5.28.0-r0.0.core2_64
Dec 04 11:35:50 <kanavin>   - nothing provides perl-module-warnings-register needed by perl-module-text-wrap-5.28.0-r0.0.core2_64
Dec 04 11:35:54 <kanavin> :(
Dec 04 12:20:46 <epistax> Hey there I am use some direction. After going from a 3.x kernel on buildroot to a 4.x kernel on yocto, we can no longer get trace functional on an i.MX 6. We've double checked the device tree and we're unaware of anything that may need to be enabled in the linux config. If anyone could provide a link to a resource that'd be awesome.
Dec 04 12:32:08 <Crofton> What kin dof trace?
Dec 04 12:34:13 <epistax> I don't know what it's called exactly. The hardware trace. We're on the trace pins on the iMX RT with a Lauterbach EDM Trace debugger.
Dec 04 12:34:21 <epistax> Sorry, IMX 6
Dec 04 12:35:20 <LetoThe2nd> ARM ETM. embedded trace macrocell
Dec 04 12:35:39 <epistax> Thank you for that, knowledge is power!
Dec 04 12:35:57 <LetoThe2nd> ignorance is bliss!
Dec 04 12:36:07 <LetoThe2nd> :-D
Dec 04 12:36:39 <LetoThe2nd> but yes, AFAIK it needs to be enabled in the kernel config
Dec 04 12:37:36 <epistax> We have PID_IN_CONTEXTIDR enabled, I'll poke around some more.
Dec 04 12:38:15 <LetoThe2nd> CONFIG_CORESIGHT, CONFIG_CORESIGHT_SOURCE_ETM3X and friends
Dec 04 12:39:37 <LetoThe2nd> even moreso: https://github.com/torvalds/linux/blob/master/Documentation/trace/coresight.txt
Dec 04 12:42:02 <epistax> Thanks a bunch.
Dec 04 12:42:15 <LetoThe2nd> good luck && have fun
Dec 04 12:45:34 <rokm> Hi, Do I need add something more than KERNEL_MODULE_AUTOLOAD to make module to be loaded on during startup ?
Dec 04 12:46:14 <LetoThe2nd> rokm: besides having it installed, usually not.
Dec 04 12:46:16 <rokm> I added this but there are nothin in /etc/modulles-load.d
Dec 04 12:46:44 <rokm> maybe place is bad
Dec 04 12:46:52 <rokm> I did it in core-image-base.bbappend
Dec 04 12:47:24 <LetoThe2nd> should rather go into your MACHINE conf file, IMHO.
Dec 04 12:48:13 <rokm> but it should not be any difference where I will add this
Dec 04 12:48:23 <rokm> but I will try in machine conf
Dec 04 12:48:54 <LetoThe2nd> oh, it is a difference. things in recipes or recipe appends are only visible during that recipes tasks. whereas things in .conf files are globally visible
Dec 04 12:49:20 <rokm> ah
Dec 04 12:49:22 <rokm> ok I will chec
Dec 04 12:49:25 <rokm> check
Dec 04 13:14:06 <eduardas_m> rburton: do you know who is responsible for ACKing first-time posters to openembedded-devel? the mksh recipe I tried to post there for inclusion in meta-openembedded did not appear
Dec 04 13:24:13 <sveinse> If I change a variable in local.conf, does this have the effect that the signatures for all recipes change? Or only the ones that have used this var?
Dec 04 13:25:06 <sveinse> Likewise for in a distro.conf, and for vars coming from the environment
Dec 04 13:33:37 <_mac13_> Hi, I've been trying to build minimal eSDK but on the last task I have this error Exception: FileNotFoundError: [Errno 2] No such file or directory: '/work/build/tmp-musl/work/my-arm-machine-oe-linux-musleabi/priva-image-minimal/1.0-r0/recipe-sysroot/world-pkgdata/locked-sigs-pkgdata.inc' this occurs during do_populate_sdk_ext task
Dec 04 13:36:00 <_mac13_> and my private-image-minimal.bb : IMAGE_INSTALL = "packagegroup-core-boot ${CORE_IMAGE_EXTRA_INSTALL}"  IMAGE_LINGUAS = " "  LICENSE = "MIT"  inherit core-image  IMAGE_ROOTFS_SIZE ?= "8192"  IMAGE_INSTALL_append = " u-boot-fw-utils"
Dec 04 14:01:36 <_mac13_> to build eSDK I use bitbake private-image-minimal -c populate_sdk_ext and I put this SDK_EXT_TYPE = "minimal" SDK_INCLUDE_PKGDATA = "1" to my local.conf
Dec 04 14:09:32 <jostor> I am trying to build node-red 0.19.5 for raspberrypi3. I am using this recipe: https://layers.openembedded.org/layerindex/recipe/67980/. I have modified the version from 0.18.5 to 0.19.5. This is working fine in sumo, but on thud I get an error:
Dec 04 14:09:37 <jostor> ERROR: Fatal errors occurred in subprocesses, tracebacks printed above
Dec 04 14:10:30 <jostor> ERROR: Function failed: sysroot_strip
Dec 04 14:11:18 <jostor> If I use version 0.18.5 node-red builds fine on both sumo and thud
Dec 04 14:13:04 <jostor> Complete error log can be found here: https://gist.github.com/jostor/d0318ee399ced56b0ae168ae8a72d1a7
Dec 04 14:13:23 <jostor> Does anyone know why this is failing on thud and not on sumo?
Dec 04 15:42:21 <kergoth> wonder if we should look at pysh alternatives. oilshell's osh could be of interest. or https://github.com/idank/bashlex or https://github.com/colis-anr/morbig perhaps
Dec 04 15:44:54 <rburton> not the last one, the depends are huge
Dec 04 15:47:41 <rburton> kanavin: well that perl build got a lot further
Dec 04 15:49:27 <rburton> kanavin: notably the galculator test is failing on testimage, maybe that needs a working perl
Dec 04 15:57:47 <armpit> YPTM: armpit is on
Dec 04 15:58:19 <RP> jostor: thud probably had error handling added. There is a patch in master-next which improves that error message btw
Dec 04 15:58:36 <RP> armpit: you're early? :)
Dec 04 15:58:44 <sjolley1> YPTM: Bridge is with Zoom at: https://zoom.us/j/990892712
Dec 04 15:58:47 <armpit> 2 minutes
Dec 04 15:58:51 <sjolley1> YPTM: Stephen Joined
Dec 04 15:59:10 <JPEW_> YPTM: Joshua Watt here
Dec 04 15:59:38 <Tartarus> YPTM: Tom Rini here
Dec 04 16:00:20 <vmeson> YPTM: Randy MacLeod est la.
Dec 04 16:00:45 <RP> YPTM: Richard joined
Dec 04 16:02:07 <denix> YPTM: Denys joined
Dec 04 16:02:17 <nickpongratz> YPTM: Nick joined
Dec 04 16:05:18 * RP notes he needs crossing/dotting :/
Dec 04 16:05:44 <moto-timo> YPTM: Tim O.
Dec 04 16:06:39 <RP> https://autobuilder.yoctoproject.org/typhoon/#/console
Dec 04 16:08:04 <aehs29> YPTM: Alejandro joined
Dec 04 16:10:14 <NeilSh> HI
Dec 04 16:10:43 <richardg> YPTM Richard G.
Dec 04 16:11:45 <NeilSh> i'm seeing this error "Error running gcc  --version:" which seems to come form def host_gcc_version(d): in utlils.py
Dec 04 16:12:28 <NeilSh> it doens't print the error proprerly first of all and then when i try to fix it it says it returned and error code 111
Dec 04 16:13:16 <vmeson> NeilSh: have you installed gcc on your host as per: https://www.yoctoproject.org/docs/2.0/yocto-project-qs/yocto-project-qs.html
Dec 04 16:13:17 <NeilSh> any ideas?
Dec 04 16:13:59 <NeilSh> yea gcc is installed i had 5.4 I updated to 7.3 yesterday
Dec 04 16:14:04 <vmeson> search for, "The Build Host Packages" for your distro
Dec 04 16:14:20 <vmeson> YPTM: Randy MacLeod est la.
Dec 04 16:14:24 <NeilSh> all of this works with krogoth. I'm trying to update to sumo and i'm seeing this issue
Dec 04 16:15:23 <vmeson> NeilSh: hmmmm, that's odd.
Dec 04 16:17:12 <denix> NeilSh: HOSTTOOLS was added in between those, but native gcc should be whitelisted...
Dec 04 16:20:08 <NeilSh> anything I can try?
Dec 04 16:22:38 <vmeson> NeilSh: does the same thing happen on thud?
Dec 04 16:25:14 <denix> only Intel and Linaro test on real hw?
Dec 04 16:25:15 <jonmason> YPTM: Jon joined (better late than never)
Dec 04 16:25:39 <yocti> New news from stackoverflow: Add custom splash screen image in Yocto (the best way) <https://stackoverflow.com/questions/53616788/add-custom-splash-screen-image-in-yocto-the-best-way>
Dec 04 16:26:03 <NeilSh> actually I believe I even saw it happen on morty. I can re-test and come back
Dec 04 16:26:21 <rburton> oh nuts yptm
Dec 04 16:26:23 <rburton> is it still on?
Dec 04 16:26:26 <NeilSh> i kind of just jumped to sumo. I'll check
Dec 04 16:26:28 <vmeson> rburton: yes
Dec 04 16:26:37 <rburton> that will teach me to sort the garden furniture out without looking at the calendar
Dec 04 16:26:54 * moto-timo snickers at rburton
Dec 04 16:30:24 <rburton> yptm: on, but can't be around for long
Dec 04 16:31:20 <armpit> rburton, you got all the actions
Dec 04 16:31:46 <eduardas_m> just wondering, how many other people using usrmerge actively for their distros?
Dec 04 16:32:16 <eduardas_m> do standard images get tested with this distro features enabled?
Dec 04 16:32:26 <rburton> the yocto autobuilder doesn't test it, no
Dec 04 16:32:52 <eduardas_m> also, to me it appears the feature lacks documentation in the megamanual
Dec 04 16:33:13 <rburton> patches welcome!
Dec 04 16:33:29 <rburton> whoever added the feature didn't document it, presumably
Dec 04 16:33:45 <vmeson> eduardas_m: usrmerge testing is only done occasional at WR, I should add it as a standard item...
Dec 04 16:34:41 <eduardas_m> vmeson: some things that use hardcoded paths instead of variables might get broken when usrmerge is enabled
Dec 04 16:34:53 <eduardas_m> vmeson: it broke toybox for example for me
Dec 04 16:35:05 <sjolley1> YPTM is over.
Dec 04 16:35:52 <eduardas_m> vmeson: http://lists.openembedded.org/pipermail/openembedded-devel/2018-December/197773.html
Dec 04 16:37:06 <eduardas_m> submitted fix to do it more properly for that recipe... does anyone go through meta-openembedded to check whether that is not the case for other stuff?
Dec 04 16:37:55 <vmeson> eduardas_m: I don't know of anyone doing that. It hasn't been a priority yet so if you're keen, go for it.
Dec 04 16:41:28 <eduardas_m> vmeson: thank you for letting me know. That clarifies the situation a bit.
Dec 04 16:48:05 <NeilSh> Ok never mind.. morty is parsing at least. I'm going to incrementally move up and see which version it blows up.
Dec 04 16:48:45 <vmeson> NeilSh: yay!
Dec 04 17:24:57 <NeilSh> quick question.. what are the -next branches?
Dec 04 17:26:02 <halstead> moto-timo, I'll watch for your ping here.
Dec 04 17:32:59 <Crofton> NeilSh, i assume work that is under test before merging to master
Dec 04 17:33:19 <NeilSh> thanks
Dec 04 17:39:35 <RP> armpit, vmeson: https://autobuilder.yoctoproject.org/typhoon/#/builders/80/builds/50 needs a bug filing and someone to look into it :/
Dec 04 17:39:51 <RP> (new unseen failure)
Dec 04 17:40:14 <RP> The other selftest failure was one I thought I'd fixed but seems the patch isn't in -next for reasons I need to figure out
Dec 04 18:14:07 <khem> virtualbox
Dec 04 18:14:29 <khem> nm wrong window
Dec 04 20:27:57 <ak77> hello!, I did EXTRA_IMAGE_FEATURES += " package-management ", rebuild the image, but Packages.gz are not there, what am I missing?
Dec 04 20:36:23 <rburton> ak77: what package manager did you pick?
Dec 04 20:37:36 <ak77> rburton: ipk, ... now i found out about package-index
Dec 04 20:37:48 <ak77> rburton: this is not done automagically
Dec 04 20:37:55 <rburton> well, package-index builds the indexes in the work directory, not on the target
Dec 04 20:38:09 <ak77> rburton: this is what I needed
Dec 04 20:38:18 <ak77> rburton: so that, opkg update, okpg install will work
Dec 04 20:41:19 <ak77> rburton: thank you, none the less
Dec 04 21:40:05 <scottrif> What meta-intel release is associated with upcoming Sumo (2.5.2)?
Dec 04 21:51:07 <scottrif> 19.0.0 ???
Dec 04 21:53:13 <scottrif> 9.2 ??
Dec 04 21:55:33 <cdgarren> I'm trying to build chromium-x11. It was working previously, and I'm not sure what I did to break it, but I'm getting this error in do_prepare_recipe_sysroot:
Dec 04 21:55:33 <cdgarren> Exception: FileExistsError: [Errno 17] File exists: '/home/cdgarren/yocto/build/tmp/sysroots-components/cortexa9hf-neon-mx6qdl/wayland-protocols/usr/share/wayland-protocols/unstable/alpha-compositing/alpha-compositing-unstable-v1.xml' -> '/home/cdgarren/yocto/build/tmp/work/cortexa9hf-neon-mx6qdl-poky-linux-gnueabi/chromium-x11/67.0.3396.99-r0/recipe-sysroot/usr/share/wayland-protocols/unstable/alpha-compositing/alpha-compositing-unstable
Dec 04 21:55:33 <cdgarren> -v1.xml'
Dec 04 21:55:33 <cdgarren> Any ideas?
Dec 04 22:21:14 <ak77> i am looking at pypi class, but can't find if python package installer determines that the package is allarch ?
Dec 04 22:22:31 <linuxjacques> this looks bad (thud): "checking sysdep dirs... configure: error: The e5500 subspecies of powerpc64 is not supported."
Dec 04 22:24:45 <fray> you want PPC64 support, work with GCC community.. they're slowly removing support due to NXP
Dec 04 22:26:50 <yocti> New news from stackoverflow: How to restrict a recipe to native and nativesdk only? <https://stackoverflow.com/questions/53622305/how-to-restrict-a-recipe-to-native-and-nativesdk-only>
Dec 04 22:44:17 <rburton> ak77: if you want a package to be allarch then set that yourself
Dec 04 22:46:19 <ak77> rburton: ok
Dec 04 22:46:34 <rburton> the class doesn't decide that for you because it can't
Dec 04 23:30:23 <ak77> if i want to PACKAGECONFIG something to all machines, but not qemu, is first PACKAGECONFIG_append = "xy" and next line PACKAGECONFIG_remove_qemuall = "xy" correct way?
Dec 05 01:12:12 <khem> cdgarren: remove wayland from DISTRO_FEATURES
**** ENDING LOGGING AT Wed Dec 05 03:00:01 2018