**** BEGIN LOGGING AT Tue Jan 29 02:59:56 2019
Jan 29 04:40:47 <yocti> New news from stackoverflow: How to install dependencies from requirements.txt in a Yocto recipe for a local Python project <https://stackoverflow.com/questions/54080551/how-to-install-dependencies-from-requirements-txt-in-a-yocto-recipe-for-a-local>
Jan 29 08:19:17 <malanecora> Morniiiing!
Jan 29 08:20:18 <malanecora> As I said yesterday, I'm facing some issues related to a custom CRDA/wireless-regdb patch
Jan 29 08:21:02 <malanecora> Such patch has a couple of py scripts for key-rule generation
Jan 29 08:21:47 <malanecora> It worked as expectend in Rocko, but now I've upgraded the system to Thud, following ERROR arises
Jan 29 08:21:53 <malanecora> https://pastebin.com/f97SUeYx
Jan 29 08:22:32 <malanecora> Something weird is happening with python there
Jan 29 08:28:45 <malanecora> python-attrs doesn't help to fix it
Jan 29 08:46:36 <malanecora> I have to amend my last comment, adding DEPENDS += "python-attrs" to the recipe DOES partially fix the issue
Jan 29 08:48:05 <Crofton|work> Don't forget to let us know if you will be at FOSDEM https://www.openembedded.org/wiki/FOSDEM_2019
Jan 29 10:41:56 <yocti> New news from stackoverflow: undefined reference to `__gcov_exit'? <https://stackoverflow.com/questions/54418831/undefined-reference-to-gcov-exit>
Jan 29 10:50:20 <florian> good morning
Jan 29 10:52:35 <florian> RP: gitsm fetcher from yesterdays master works with the bitbucket.org URIs without hostname.
Jan 29 10:54:04 <kanavin_> rburton: it adds a virtual terminal to the qemu-native gtk window
Jan 29 10:54:10 <RP> florian: great, I did just merge another fix but its good to know we're not regressing
Jan 29 10:54:23 <kanavin_> so you can login and do stuff independently of the virtual graphical device
Jan 29 11:07:57 <ollie> hello. does anyone have experience building (cross-compiling) ruby-augeas within yocto?
Jan 29 11:42:38 <florian> RP: very good... it would be great to get these fixes into stable as well.
Jan 29 11:44:05 <RP> florian: it is risky but I suspect we'll need to
Jan 29 11:48:45 <florian> RP: right
Jan 29 11:48:56 * florian is able to provide some testing at least
Jan 29 11:49:43 <RP> florian: I'm grateful for that!
Jan 29 12:18:03 <malanecora> Which is the best way to modify (add a new band) db.txt from wireless-regdb package?
Jan 29 12:18:52 <malanecora> Would be adding a patch enough?
Jan 29 12:21:24 <aratiu1> malanecora: yes
Jan 29 12:26:53 <malanecora> Enven if I use kernel <=4.14?
Jan 29 12:39:04 <malanecora> The recipe says something about that
Jan 29 12:39:07 <malanecora> https://pastebin.com/WaW4Fkq5
Jan 29 12:42:42 <malanecora> I'm unable to see the changes I made to db.txt
Jan 29 12:44:27 <malanecora> Well, I can in the /tmp/work/.../wireless-regdb/whatever but not in the image
Jan 29 13:16:32 <florian> What's target-sdk-provides-dummy-dev?
Jan 29 13:37:15 <florian> hrm funny... master fails to build me a sdk claiming to be unable to install busybox
Jan 29 13:45:02 <ollie> could anyone offer some help with the following error when building ruby-augeas with yocto?
Jan 29 13:45:03 <ollie> https://pastebin.com/uLhyF8Vr
Jan 29 13:48:23 <florian> ...build/arago-tmp/hosttools/ld: cannot find -laugeas
Jan 29 13:48:53 <ollie> Ya that is what I need to fix ;)
Jan 29 13:49:03 <florian> looks like it fails to find this library building the native bit
Jan 29 13:49:27 <ollie> I'm not sure if there is something missing from the recipe for ruby-augeas and/or augeas itself
Jan 29 13:50:06 <florian> is there some libaugeas* in build/arago-tmp/work/armv7ahf-neon-poky-linux-gnueabi/ruby-augeas/0.5.0-r0/recipe-sysroot-native ?
Jan 29 13:50:28 <ollie> no, there is not even the lib directory under recipe-sysroot-native
Jan 29 13:50:57 <ollie> which is in the include paths for GCC
Jan 29 13:51:05 <ollie> .../build/arago-tmp/work/armv7ahf-neon-poky-linux-gnueabi/ruby-augeas/0.5.0-r0/recipe-sysroot-native/lib
Jan 29 13:52:07 <ollie> there is libaugeas under recipe-sysroot/ , which obviously doesnt help very much in the case of the native build
Jan 29 13:55:44 <BlauskaerM> When going through the manifest, what does it mean when the liecense ends with a plus "+" ?
Jan 29 13:55:56 <BlauskaerM> License manifest
Jan 29 13:57:30 <florian> BlauskaerM: "... or any later version of that license"
Jan 29 13:59:28 <RP> alimon: I think something is mixing up ordering of stdout verses stderr, bad buffering somewhere
Jan 29 13:59:30 <florian> ollie: yes indeed.... I have to admit I do not know that ruby stuff that much. Looks a little bit like the native ruby does not get it right picking up the stuff for crosscompiling.
Jan 29 14:00:13 <ollie> florian: thank you for helping. ill keep looking in that direction
Jan 29 14:00:24 <florian> since building for the target ...hosttools/ld seems to be wron as well.
Jan 29 14:04:43 <malanecora> How can I force it to run?
Jan 29 14:04:59 <malanecora> *I have a task that is being skipped as noexec
Jan 29 14:05:24 <BlauskaerM> florian: So if GPLv4 would exist, recipes with GPLv3+ would automaticly be GPLv4?
Jan 29 14:05:36 <malanecora> Although I'm wirtting a bbappend with a do_compile for the original recipe
Jan 29 14:05:48 <malanecora> No matter what I do, it never compiles
Jan 29 14:06:19 <kanavin_> BlauskaerM: GPLv3 or v4, the copyright holders let you decide
Jan 29 14:07:53 <malanecora> And it is not disabled in the original recipe
Jan 29 14:08:06 <malanecora> Just marked as noexec in the logs anyway
Jan 29 14:09:10 <malanecora> But it does inherit bin_package
Jan 29 14:09:20 <malanecora> Which is a pain in the ass
Jan 29 14:10:39 <malanecora> Can heritage be modified in a bbpappend? (in terms of removing)
Jan 29 14:19:00 <rburton> BlauskaerM: sounds like you need to read the gpl header
Jan 29 15:20:58 <kergoth> BlauskaerM: last paragraph of https://opensource.org/licenses/gpl-license — "Most GPL version 2 software is actually licensed as "GPL version 2 or any later version", or words to similar effect, which is commonly understood as a grant under GPL version 2, section 9 of an "option to follow the terms and conditions . . . of any later version" of the GPL. In this case, even if you are not the original licensor of the GPL version 2 software, you can
Jan 29 15:20:58 <kergoth>  "follow the terms and conditions" of GPL version 3 instead."
Jan 29 15:28:01 <BlauskaerM> Thank you kergoth
Jan 29 15:30:05 <kergoth> np
Jan 29 16:13:04 <yocti> New news from stackoverflow: How to create a custom partition layout using yocto wic? <https://stackoverflow.com/questions/54425095/how-to-create-a-custom-partition-layout-using-yocto-wic>
Jan 29 16:21:35 <GeramyL> Hello Everyone, I been working on a custom layer called meta-surfacego, I got my kernel and everything compiling correctly with the patches I needed to apply to the kernel. I am having an issue with my recipes-core layer, I was trying to add them in by force using, the a machine include file with MACHINE_ESSENTIAL_EXTRA_RDEPENDS_append = " surface-udev surface-ath10k surface-initramfs"
Jan 29 16:21:48 <alimon> RP: ok,  let me review the codebase of ptest-runner
Jan 29 16:22:14 <GeramyL> But I get the following error NOTHING RPROVIDES 'surface_initramfs' blah blah packagegroup-core-boot RDEPENDS on it blah blah.
Jan 29 16:22:34 <GeramyL> Any initial idea's?
Jan 29 16:25:53 <odda> only an initial idea, but try adding it to DISTRO_FEATURES_append in meta-poky/conf/distro/poky.conf
Jan 29 16:27:07 <odda> GeramyL: im not really aware of your circumstances, but this was a fix for me with systemd
Jan 29 16:27:11 <RP> alimon: as yet I don;t know if its the oeqa code or ptest-runner but it does seem to be out of order
Jan 29 16:27:21 <GeramyL> odda I dont want to actually interact with poky itself, I need this layer to be independent.
Jan 29 16:29:11 <GeramyL> odda: that makes sense, but I did have it working earlier before I added more recipes to my layer its why i'm kind of confused right now.
Jan 29 16:29:39 <GeramyL> odda: do you know if there is a way to add the recipes-core to the kernel rather then the machine layer?
Jan 29 16:42:17 <alimon> RP: I'm doing, may be that could explain the issue, http://git.yoctoproject.org/cgit/cgit.cgi/ptest-runner2/tree/utils.c#n291
Jan 29 16:42:54 <odda> GeramyL: im sorry, ive always used this soloution, since i always use poky
Jan 29 16:43:45 <odda> but please let me know if you find an elegant soloution
Jan 29 16:43:53 <RP> alimon: yes, I think that could do it. We need to probably redirect stderr to stdout
Jan 29 16:55:21 <GeramyL> odda: omg smh lol surface_initramfs_1.0.0.bb woooOooowwww!!!! hahahhahaha
Jan 29 16:55:28 <GeramyL> its supposed to be surface-initramfs lol
Jan 29 16:56:04 <GeramyL> how stupid do I feel right now lol I bet you could answer that haha
Jan 29 17:01:01 <odda> well... the soloution turned out more stupid than the problem seemed to me...
Jan 29 17:06:53 <alimon> RP: http://git.yoctoproject.org/cgit/cgit.cgi/ptest-runner2/commit/?h=devel
Jan 29 17:08:01 <alimon> I reproduced the issue and tested the fix with the unit tests in ptest-runner
Jan 29 17:08:16 <RP> alimon: thanks, I'll try a test here with that
Jan 29 17:19:18 <RP> alimon: I have patches for the logparser code btw
Jan 29 17:22:36 <RP> alimon: its running but its a full ptest image so will take a while
Jan 29 17:24:35 <alimon> RP: ok
Jan 29 17:30:39 <RP> alimon: should be 1.5 hours so I'll be afk, will report back later but I'm confident this will look better :)
Jan 29 17:31:00 <RP> alimon: this explains a lot about the random variations we've seen!
Jan 29 17:48:37 <alimon> RP: cool, :)
Jan 29 17:51:07 <Gottox> good evening!
Jan 29 17:51:45 <Gottox> I have a set of patches to make the yocto prelink compile with musl libc. What's the proper place to report those patches?
Jan 29 18:03:29 <kergoth> likely the yocto@ list
Jan 29 18:03:46 <GeramyL> anyone ever seen this error: packagegroup-base-extended : Depends: packagegroup-base but it is not going to be installed
Jan 29 18:08:57 <kergoth> insufficient info. post the log, or a bigger chunkm of it
Jan 29 18:09:14 <kergoth> it said why it wasn't going to be installed further up in the log
Jan 29 18:27:30 <GeramyL> https://pastebin.com/icRF4JeG
Jan 29 18:27:45 <GeramyL> kergoth: Its on pastebin see above link
Jan 29 18:29:03 <GeramyL> kergoth: can you do MACHINE_ESSENTIAL_EXTRA_RDEPENDS on a recipes-core file? I think that's were the error is coming from.
Jan 29 18:30:01 <kergoth> it works fine. can you pastebin your value for that?
Jan 29 18:31:41 <GeramyL> https://pastebin.com/EmHf6sit
Jan 29 18:31:59 <GeramyL> kergoth: see above
Jan 29 18:34:33 <GeramyL> kergoth: if packagegroup-core-boot depends on my surface recipes that means my priority for the bb files need to be 6 and not 5 because they have to be built for packagegroup-core-boot since it depends on them, right?
Jan 29 18:37:47 <kergoth> layer priority only controls selecting which recipe to build. if a given recipe exists in multiple layers, priority controls which is used
Jan 29 18:37:50 <kergoth> that's about it
Jan 29 18:38:00 <kergoth> not required to have cross-layer dependencies
Jan 29 18:38:24 <kergoth> bitbake will actually accumulate layer priorities based on LAYERDEPENDS, so you dont' have to do that yourself
Jan 29 18:39:08 <GeramyL> gotcha, so i can really just remove that piece of configuration.
Jan 29 18:40:04 <GeramyL> oh that makes sense, so if the recipe exists and someone is trying to override it in there layer they can actually adjust the priority.
Jan 29 18:43:39 <GeramyL> kergoth: while i'm here, for some reason on my kernel, when I go to boot from usb it will load to the selection menu, when i select a option such as install; it will start the installer and then stall out at, "Waiting for removable media" then timeout and say "Cannot find rootfs.img in /run/media/*" dropping to shell. Were would I start to debug this? How do I force it to drop to shell were I can actually type commands. right now it
Jan 29 18:45:42 <GeramyL> Is this a microcode issue inside the boot?
Jan 29 18:57:57 <GeramyL> kergoth: so I now have this error, https://pastebin.com/Gnq55Sc9 I swear it just keeps moving and moving
Jan 29 18:59:34 <GeramyL> kergoth: log file https://pastebin.com/tY4tgT59
Jan 29 19:03:22 <Gottox> kergoth: thx
Jan 29 19:44:05 <GeramyL> I cant get past this stupid not installable error
Jan 29 19:44:18 <GeramyL> do i need to implement do_install or something?
Jan 29 19:49:28 <kroon> rburton: Hi Ross, yesterday I mentioned I got problems with autoconf/aclocal on target not working due to missing signals. I checked perl/log.do_configure, and I see lots of "cnf/configure_sigs.sh: line 22: seq: command not found" right after "Checking available signal names". Does that ring any bells to you ?
Jan 29 19:49:49 <kroon> I do have 'seq' working on target
Jan 29 19:50:16 <kroon> oh, and this is on my host build system, so .. nm
Jan 29 19:51:28 <kroon> I dont find 'seq' under tmp/hosttools/, if that would be required
Jan 29 20:05:31 <GeramyL> fyi it looks like do_install is required for anything that is a MACHINE_ESSENTIALS recipe.
Jan 29 20:07:12 <kroon> rburton: but that script that fails, its env doesnt have a PATH containing 'seq'. I suspect 'seq' needs to be added to hosttools ?
Jan 29 20:08:59 <dkc> if I want to create a partition with kernel, dts, initramfs, is there a way to use wic in the initramfs recipe to achieve that? I mean, to generate the wic I need the .cpio.gz, don't know how to order that
Jan 29 20:10:08 <kroon> rburton: yeah, if I symlinked 'seq' in hosttools, log.do_configure looks much better
Jan 29 20:12:02 <kroon> rburton_: ping
Jan 29 20:13:54 <yocti> New news from stackoverflow: DirectFB Error: No resource has been found by the specified ID. KEYBOARD <https://stackoverflow.com/questions/54428881/directfb-error-no-resource-has-been-found-by-the-specified-id-keyboard>
Jan 29 20:15:31 <kroon> RP: maybe you know what would be the right solution this ?
Jan 29 20:33:41 <dkc> unbundled initramfs are not a thing with wic it seems
Jan 29 20:56:46 <GeramyL> Anyone know about the Removable Media issue, were a usb wont install the linux?
Jan 29 21:25:56 <kroon> rburton_: The signal errors I saw was just warnings. Those are fixed by making sure 'seq' is available. What caused the real error was that I didn't have libtool installed. So that might explain why the autobuilders hasn't complained.
Jan 29 21:28:18 <khem> RP: http://errors.yoctoproject.org/Errors/Build/75817/
Jan 29 21:28:44 <khem> th webkit failure can be ignored, but others are new, and seems to be due to same reason
Jan 29 21:30:33 <khem> this is current master-next
Jan 29 22:20:09 <rburton> kroon: our SDKs typically contain libtool
Jan 29 22:21:36 <kroon> rburton: yeah I figured. I guess we still want to fix the warnings though ? Cause those should still be there I think..
Jan 29 22:22:53 <rburton> yeah send a patch to add seq, explaining what recipe was using it
Jan 29 22:23:17 <kroon> rburton: ok
Jan 29 23:24:35 <RP> alimon: good news, the test results look a lot better so that patch helps. Not sure its the only issue but its certainly a good start! :)
Jan 29 23:26:09 <RP> khem: but what is the failure? :/
Jan 29 23:33:38 <khem> RP: http://errors.yoctoproject.org/Errors/Details/220228/
Jan 29 23:33:49 <khem> it seems something is wrong for opkg backend
Jan 29 23:37:36 <RP> khem: we need to get it printing the actual failures. There was a patch the last time this happened but I wasn't sure it fixed one problem but left a load of others open
Jan 29 23:37:47 <RP> khem: I suspect you only see this when large numbers of things repackage
Jan 29 23:38:32 <khem> RP: I am worried that opkg is not tested well as backend
Jan 29 23:39:01 <RP> khem: as I mentioned last time, its tested just as well as any other, we always build ipks as well as rpms and debs on the AB
Jan 29 23:39:05 <khem> adelcast: can you check this error http://errors.yoctoproject.org/Errors/Details/220228/ seems to happen on opkg
Jan 29 23:39:26 <khem> RP: right it just might be meta oe brings in more packages
Jan 29 23:39:27 <RP> khem: the error is pretty much useless without the stderr from when it fails :(
Jan 29 23:39:44 <RP> khem: that may be. To say its less tested isn't fair though
Jan 29 23:40:05 <khem> RP: I guess the reproducer is easy add meta-oe to mix and build gtksourceview2
Jan 29 23:40:38 <khem> or dnsmasq from meta-networking
Jan 29 23:40:53 <khem> I guess that layer is used by many of yocto users
Jan 29 23:42:06 <RP> khem: we need to do what I suggested last time, fix the error reporting for the package backends
Jan 29 23:42:28 <RP> there was a partial patch but it isn't merged yet. Perhaps rerun with that applied?
Jan 29 23:44:34 <yocti> New news from stackoverflow: VIRTUAL-RUNTIME_login_manager alternatives to busybox <https://stackoverflow.com/questions/46034523/virtual-runtime-login-manager-alternatives-to-busybox>
Jan 29 23:47:08 <khem> RP: yeah sounds a good idea
Jan 29 23:47:09 <adelcast> ^khem ^RP, yes, I submitted a patch that should print why opkg-build is failing: http://lists.openembedded.org/pipermail/openembedded-core/2019-January/278096.html
Jan 29 23:47:34 <adelcast> with that patch, the output can give me something to work with
Jan 29 23:47:37 <khem> RP: is there any issue with that patch ?
Jan 29 23:47:44 <khem> that I should be aware of ?
Jan 29 23:48:01 <khem> I dont want to stumble into another ditch before getting to the one I am in :)
Jan 29 23:51:31 <khem> adelcast: RP adding the patch to yoe/mut lets see
Jan 30 00:05:16 <RP> khem: I just don't want to have to add something like this to every subprocess call we have. We also need to fix all the package backends.
Jan 30 01:44:56 <yocti> New news from stackoverflow: Is it possible to pass in command line variables to a bitbake build? <https://stackoverflow.com/questions/17366984/is-it-possible-to-pass-in-command-line-variables-to-a-bitbake-build>
**** ENDING LOGGING AT Wed Jan 30 02:59:57 2019