**** BEGIN LOGGING AT Mon Jul 02 03:00:00 2018 Jul 02 08:01:11 hello, does anyone know how to make u-boot splash persist on i.MX6 until a userspace splash is available? Currently u-boot splash disappears when kernel starts loading. Jul 02 08:01:31 i.e. I get a black screen after the u-boot splashscreen Jul 02 08:02:52 An image with a company logo can not be put into the kernel because a trademark is not compatible with GPLv2 as far as I know Jul 02 08:03:25 so I can not use the kernel splashscreen to display the same image as u-boot does Jul 02 08:04:42 so it would be nice if the kernel would not modify the framebuffer when loading and the u-boot initialized splashscreen would remain until a userspace GUI application starts Jul 02 08:06:28 eduardas_m: the splash logo doesn't have any impact on the GPL Jul 02 08:10:07 mckoan: according to this intel document, the image also has to be under GPLv2: https://www.thailand.intel.com/content/dam/www/public/us/en/documents/white-papers/loading-splash-screen-from-initramfs-as-binary-blob.pdf Jul 02 08:11:07 mckoan: they even describe a solution that allows to use a non-GPL image as a loadable binary blob Jul 02 08:11:24 as a workaround to this problem Jul 02 08:11:42 but as far as I understand the solution is Intel platform specific Jul 02 08:13:59 eduardas_m: interestinh, thx Jul 02 08:20:04 mckoan: I can imagine lots of smaller embedded Linux teams and shops simply not caring about this issue, but I still would like to know whether there is any proper solution to this for the i.MX6 platform Jul 02 08:21:03 my colleague has taken a look at Android images shipped by Samsung and LG... it seems they do not use the Linux kernel splash screen... only bootloader initialized splash screen is used Jul 02 08:21:49 however, on i.MX6 it disappears as soon as the kernel starts loading Jul 02 09:01:04 Hello, I have yocto fido (1.8) and boost version 1.57 Jul 02 09:01:20 I want to upgrade to version 1.64 Jul 02 09:01:35 What is the best solution to update to 1.64 ? Jul 02 09:02:18 I have tried to create a recipe boost-1.64 but I have some issues : Failure expanding variable BOOST_VER, expression was ${@bb_parse_BBHandler_vars_from_file(d_getVar('FILE'),d)[1] or '1_0'} which triggered exception NameError: name 'bb_parse_BBHandler_vars_from_file' is not defined Jul 02 09:02:24 Any ideas ? Jul 02 09:07:35 Considered updating your Yocto version? 1.8 seems rather old. Doing this you would get newer version of boost as well. The rocko branch provides boost 1.64 Jul 02 09:27:55 If I update to a newer version of yocto, it can brake some of my recipes already installed ? :-/ Jul 02 09:28:52 pouet_forever: yes, but fixing those is worth it for the sake of being up-to-date..at least from my experience Jul 02 09:30:02 pouet_forever: you will also get access to newer Yocto tools such as wic for image creation and important bug fixes Jul 02 09:31:56 pouet_forever: that is why I have put in some effort in getting on Yocto 2.5 Sumo although the latest Yocto release supported by my SoM vendor is only Rocko Jul 02 09:36:05 eduardas_m: i wiil think about it, but I think it is not feasible for the moment Jul 02 09:54:06 hi, how to build a source and headers only recipe with sumo? we have a gmock recipe which has all files in -dev and main ${PN} is empty, but something is adding a dependency to it from -dev and it's not installable to SDK... Tried ALLOW_EMPTY_${PN} = "1", and RPROVIDES_${PN}-dev = "gmock" already but problem persists. Jul 02 09:57:39 and RDEPENDS_${PN}-dev_remove = "${PN}" just causes a python stacktrace from bitbake Jul 02 10:05:23 that remove is right Jul 02 10:06:29 i'd just set RDEPENDS_${PN}-dev to "" Jul 02 10:07:00 New news from stackoverflow: how to manage external dependencies of a golang project in a yocto recipe Jul 02 10:20:24 is there a mirror of anonscm.debian.org/collab-maint/ltrace.git somewhere in yocto infrastructure? Jul 02 10:37:06 New news from stackoverflow: systemd ignores services from overlayFS Jul 02 10:44:11 rburton: thanks, setting RDEPENDS_${PN}-dev = "" works and the -dev package is installable again. Jul 02 11:20:01 rburton: I kind of hate to mention https://autobuilder.yocto.io/builders/nightly-qa-extras/builds/1113/steps/BuildImages_14/logs/stdio :/ Jul 02 11:20:24 argh Jul 02 11:20:26 seriously Jul 02 11:20:33 with master?! Jul 02 11:51:25 rburton: was -next but don't think it was the -next patchset :( Jul 02 12:36:04 there seem to be certain things (.bbclass files, rootfs layer, etc/) which can be "update" in a project, i.e., pulled from a repo? how is this done? is it a bitbake command? Jul 02 12:36:30 things which, when doing a normal (image) bitbake don't get pulled Jul 02 12:36:38 back in a minute - rebooting. Jul 02 12:39:11 did i miss any responses on my "update" question? Jul 02 12:50:41 I have a system running the "FSLC framebuffer" distro. What legal/license info should I include on my system? I know of the manifests and the licenses-artifact, but I'm not sure what I must include. Jul 02 13:17:16 rburton, etc: i found the problem i/we were chasing last week: the install script was being modified by a .bbappend file in the meta-swupdate layer Jul 02 13:17:25 re: libubi.h not found Jul 02 13:17:32 there you go Jul 02 13:17:45 thats why -e is useful, it will show you where the append is coming from Jul 02 13:21:26 i suppose so. but a) i need to develop more facility in knowing how to use it, and b) it's still a LOT of stuff to look at Jul 02 13:21:40 even for that one recipe Jul 02 13:21:54 26687 lines.. Jul 02 13:22:22 awww we don't show history for functions Jul 02 13:22:39 but just search for 'do_install() {' Jul 02 13:22:53 RP: we don't show variable history for task variables in -e Jul 02 13:23:17 i understand that we don' want to show the *full* history as it could be huge but an abridged form without the values would be useful Jul 02 13:26:45 what would be useful (perhaps?) is, for each function like do_install(), show the files that were consulted to construct it. kinda like a cross-reference. Jul 02 13:27:08 yeah thats exactly what -e does, but not for tasks Jul 02 13:27:29 you mean tasks like do_install? Jul 02 13:27:33 yes Jul 02 13:27:46 why not? Jul 02 13:29:51 seems like it would be a nice thing to provide. for just such an occasion. Jul 02 13:30:04 maybe it's difficult to implement? Jul 02 13:32:00 no Jul 02 13:32:12 i suspect it was by design becayuse the output would be huge Jul 02 13:32:21 but a redacted form would be useful and not huge Jul 02 13:43:57 I have a recipe who needs files contained in udev-dev package, how can I add udev-dev in RDEPENDS ? Jul 02 13:44:33 do you mean depends? Jul 02 13:44:35 I can make RDPENDS in my package-dev but not in my package Jul 02 13:44:44 no, RDEPENDS Jul 02 13:45:01 I need the udev.pc file Jul 02 13:45:08 at *runtime* on the target? Jul 02 13:45:09 very odd Jul 02 13:45:15 Yes Jul 02 13:45:19 RDEPENDS_the-package-name += "udev-dev" Jul 02 13:45:55 I have an error Jul 02 13:47:08 ERROR: QA Issue: zebra-scanner-cross rdepends on udev-dev [dev-deps] Jul 02 13:48:31 The first error was : ERROR: Nothing PROVIDES 'udev-dev' Jul 02 13:49:23 I make a bbappend to PROVIDES and RPROVIDES udev-dev but I can't add it ton my package :( Jul 02 13:49:33 pouet_forever: are you using systemd? Jul 02 13:49:56 provides/rprovides udev-dev would just make it install your hack and not the thing that has udev.pc in Jul 02 13:50:06 if you're using systemd, then the package you want is systemd-dev Jul 02 13:50:46 I am not using systemd Jul 02 13:51:11 then you want eudev-dev if you're using a recent release Jul 02 13:51:27 rburton: when you say tasks, you mean functions? Jul 02 13:51:36 Recent... no ;D 1.8 Jul 02 13:51:37 pouet_forever: oh you got an error. maybe you want to depends=udev first Jul 02 13:51:37 RP: yes Jul 02 13:52:21 rburton: i already have udev in my depends :) Jul 02 13:52:31 DEPENDS += "libconfig libusb udev udev-dev" Jul 02 13:52:47 remove udev-dev from DEPENDS Jul 02 13:53:00 you DEPEND on recipes Jul 02 13:53:04 Okay Jul 02 13:53:18 RP: i see emit_var bails early for funcs Jul 02 13:53:45 But how can i get the udev.pc from de udev-dev ? Jul 02 13:58:23 rburton: right, that was for other reasons, not history iirc Jul 02 13:58:37 rburton: can't remember what if any differences functions have history wise Jul 02 16:50:32 wow this is strange. any task i run on the ptest-runner recipe hangs, including do_fetch and do_cleanall. Jul 02 17:14:25 anyone ever see anything like that? Jul 02 17:34:15 kergoth, nope Jul 02 17:46:25 RP, kergoth: I'm working on hash equivalence. It looks like bitbake tries to avoid anything outside of the python standard library, however http://docs.python-requests.org/en/master/ would be *really* useful and probably more efficent. Thoughts on adding it as dependency? Jul 02 17:47:23 the annoyance/issue is bitbake is generally not properly installed via pip or anything, so it's almost a guaranteed failure to run for every bitbake user until they manually install requests, rather than having it installed as soon as they upgrade bitbake Jul 02 17:47:41 unless we embed it the way we do some of our other formerly external dependencies Jul 02 17:51:21 kergoth: e.g. bs4, ply, progressbar, simplediff et. al. from bitbake/lib? Jul 02 17:53:33 * kergoth nods Jul 02 17:53:51 it's not ideal, but i think we'd have to handle it the same way, at least until/if we change how bitbake is delivered to the user Jul 02 17:56:03 Ok. Does that seem like a reasonable thing to do then? I'd rather not start down the path of using it only to have to rework it all at the end. Jul 02 18:00:36 Although.... that might be a bit more difficult... requests doesn't have what you would probably call "minimal dependencies" Jul 02 18:03:34 if it has a bunch of deps itself, probably a no-go Jul 02 18:03:47 which is unfortunate, requests is one of the best and most ubiquitous python libraries around Jul 02 18:04:17 i wish we should package and distribute bitbake like any other *proper* python project, but it's tough when it's tied so tightly to oe-core Jul 02 18:06:02 Ok, I'll use urllib2 for now and when we figure that out we can upgrade Jul 02 18:24:03 hmm, could probably rig something with a requirements.txt or pipenv in oe-core to ensure the right bitbake version is installed, then potentially enhance oe-init-build-env to check it, and ease creation of a virtualenv. and/or recommend use of a docker image Jul 02 18:31:51 kergoth: Ya, I don't think it would be terribly hard Jul 02 18:36:30 You could also maybe use something like https://github.com/pypa/pipenv which I've used before. It's pretty easy. It does require you to externally install pipenv, but its probably better to install 1 dependency than dozens. Jul 02 18:38:00 i'm having a problem in the do_compile phase of a recipe. i see it is running a bash function "oe_runmake" and that function issues "make ...", but i cannot determine where the Makefile file is coming from. Jul 02 18:39:43 i can't see it in the -e output Jul 02 18:39:54 i can't find one in the meta- lyaer for the recipe Jul 02 18:40:02 i can't find one in the src Jul 02 18:40:10 ... for this recipe Jul 02 18:41:00 i see it in the tmp folder but have no idea where it comes from... Jul 02 18:46:52 JPEW: yeah, pipenv was my thought as well, definitely easier than virtualenv+pip on requirements.txt Jul 02 18:47:13 just alias bitbake='pipenv run bitbake' or something Jul 02 18:47:16 * kergoth shrugs Jul 02 18:50:41 any thoughts? suggestions? Jul 02 18:53:08 here's the bitbake output https://paste.fedoraproject.org/paste/R3Dgfpwp7jSB4BIS8Xt~2A Jul 02 18:53:31 funny, i know what's going on - what needs to be modified in the makefile, i just can't find the bloody makefile! Jul 02 18:53:49 most likely it's an automake based project, so the source tree has Makefile.am, not makefile, since automake genreates Makefile.in from Makefile.am, and ./configure generates Makefile from Makefile.in Jul 02 18:53:58 * yates beats head against wall Jul 02 18:54:07 i'd have to see hte recipe to say with any more detail Jul 02 18:54:32 we just run the underlying buildsystem of the upstream project, we don't write it Jul 02 18:54:41 so if you want to know about that, go look at the project Jul 02 18:54:51 how is automake specified in the recipe? Jul 02 18:55:11 inherit autotools Jul 02 18:55:30 ok, that's a good hint, thanks kergoth Jul 02 18:55:37 those are good hints. Jul 02 18:56:09 read the recipe and the classes it inherits to see what commands we run Jul 02 18:58:07 np Jul 02 20:01:42 if a recipe has both a SRCBRANCH and a SRCREV, does one take priority? Jul 02 20:02:22 wait Jul 02 20:02:48 ignore that Jul 02 20:04:07 if there is a "branch=xyz" in the SRC_URI, AND a hash in the SRCREV, does one have priority? Jul 02 20:04:23 doesn't a branch imply a SRCREV? Jul 02 20:04:31 a hash? Jul 02 20:05:08 no, a branch doesn't imply an SRCREV unless SRCREV is set to AUTOREV Jul 02 20:05:18 AUTOREV == HEAD of the specified branch or master if unspecified Jul 02 20:05:43 if both branch and srcrev are specified, all branch is used for is a sanity check, it makes sure that rev is accessible via the branch head Jul 02 20:26:38 good info, thanks again kergoth Jul 02 20:26:46 np Jul 02 20:32:48 JPEW: Don't underestimate how much work changing bitbake dependencies would be. At first glance it looks "simple", then you consider docs, established workflows, things like build-appliance and so on and it gets messy :/ Jul 02 20:33:17 yeah, it'd be a substantial change, potentially worth postponing to a substantnial version bump Jul 02 20:33:28 RP: Ya, that makes sense. A task for another time perhaps :) Jul 02 20:33:33 JPEW: I do understand the desire... Jul 02 20:33:35 and would require a hell of a lot of consideration of the use cases Jul 02 21:31:27 armpit: thanks for the sumo patches! Jul 02 21:31:42 armpit: sorted out a couple of bitbake tweaks/backports too fwiw Jul 02 21:32:01 there are 3 recipes for swupdate in in meta-swupdate/recipes-support/swupdate: swupdate_2017.11.bb, swupdate_2018.03.bb, and swupdate_git.bb. it appears the swupdate_git.bb is used, but i cannot find any reference to git in the entire meta-swupdate directory. how is the specific swupdate_xyz.bb determined? Jul 02 21:35:22 or 2017 or 2018 either Jul 02 21:35:32 or in my bblayers for the build Jul 02 21:35:44 magic... Jul 02 21:39:00 New news from stackoverflow: How to get Openembedded to compile tar.gz files instead of tar.xz Jul 02 21:40:21 ah Jul 02 21:40:39 is it tied to the SRC_URI type somehow? Jul 02 21:41:07 or the S variable?? Jul 02 21:42:08 yates: you can set PREFFERED_VERSION, I think Jul 02 21:42:56 see https://www.yoctoproject.org/docs/latest/bitbake-user-manual/bitbake-user-manual.html#bb-bitbake-preferences Jul 02 21:43:08 yates: The PV value from the _git.bb file will be used and influenced by PREFERREED_VERSION Jul 02 21:52:05 PREFERRED_VERSION, DEFAULT_PREFERENCE, and layer priority are all a factor Jul 02 21:56:00 i gotta read that manual... Jul 02 21:58:05 lacking any defined preferred version, and lacking a DEFAULT_PREFERENCE in any of the recipes, it's most likely layer priority. regardless, if you want a specific version, define PREFERRED_VERSION Jul 02 21:59:02 ok, thanks neverpanic, RP and kergoth Jul 02 23:53:41 RP, np Jul 03 01:09:32 New news from stackoverflow: How can I get "HelloWorld - BitBake Style" working on a newer version of Yocto? **** ENDING LOGGING AT Tue Jul 03 03:00:00 2018