**** BEGIN LOGGING AT Thu Feb 14 02:59:57 2019
Feb 14 05:55:28 <yocti> New news from stackoverflow: Yocto (Dora) QT5 on IMX6 : where is qmake <https://stackoverflow.com/questions/33808081/yocto-dora-qt5-on-imx6-where-is-qmake>
Feb 14 08:37:45 <didile> hi
Feb 14 09:17:31 <moemoe> hey, I'm struggling a bit with using the rtc on 2.6.1 with systemd - meta/recipes-core/systemd/systemd-compat-units.bb seems to disable the hwclock service, but I didn't manage to make systemd-timedated set the time from the rtc.
Feb 14 09:19:16 <moemoe> hmm, according to https://lists.freedesktop.org/archives/systemd-devel/2011-May/002526.html this should happen automatically in "PID 1"
Feb 14 09:20:32 <moemoe> "timedatectl show" states "LocalRTC=no"?
Feb 14 09:28:49 <sideralis> Hi all
Feb 14 09:29:03 <sideralis> Is there anyone familiar with including java in yocto ?
Feb 14 09:32:03 <rburton> presumably you're having problems with meta-java
Feb 14 09:32:13 <sideralis> Yes :)
Feb 14 09:32:30 <rburton> probably best to mail the list as java isn't hugely used
Feb 14 09:33:16 <sideralis> I tried to find some guides to include java. From what I found I need to add few lines PREFERRED_PROVIDER_virtual/java* in my local.Conf
Feb 14 09:33:38 <sideralis> and add 2 layers meta-oe and meta-java
Feb 14 09:34:18 <sideralis> Ok, you mean the list openembedded-devel@lists.openembedded.org
Feb 14 09:34:21 <sideralis> ?
Feb 14 10:38:51 <didile> I've an error at do_package_qa with my own recipe: ERROR: vesta-app-2.0.0-r0 do_package_qa: QA Issue: /home/root/VestaApp contained in package vesta-app requires libmonocypher.so, but no providers found in RDEPENDS_vesta-app? [file-rdeps]
Feb 14 10:39:37 <didile> the libmonocypher is in "DEPENDS"
Feb 14 10:40:11 <didile> here you can see the monocypher.bb recipe: https://paste.ofcode.org/nR63pfafbcNBnKMkPuepiX
Feb 14 10:41:15 <didile> and the vesta-app.bb recipe: https://paste.ofcode.org/aYZaAJCrAeYexhnUtBa2SM
Feb 14 10:41:44 <didile> I'm on thud
Feb 14 10:42:39 <didile> and idea how to solve this issue?
Feb 14 10:42:54 <didile> I already tried to add monocypher to "RDEPENDS"
Feb 14 10:43:48 <didile> the monocypher Makefile install a libmonocypher.so.2 and a symlink libmonocypher.so
Feb 14 11:26:36 <yocti> New news from stackoverflow: How oe_runmake uses makefile flags while compiling the code using bitbake <https://stackoverflow.com/questions/54689237/how-oe-runmake-uses-makefile-flags-while-compiling-the-code-using-bitbake>
Feb 14 11:36:04 <JaMa> RP: the "virglrenderer: add a recipe" commit in master-next is older version than what kanavin has in the branch, missing the fix for gold
Feb 14 11:36:28 <kanavin> JaMa, no worries, I'll rebase if needed
Feb 14 11:36:41 <JaMa> RP: it causes rebuilds for pretty much everything, so better to get the right revision in
Feb 14 11:39:08 <JaMa> kanavin: why did you change the author of the fix? it's nice that it was merged, but how should the original author (gentoo dev) feel about it when you don't even include his Signed-off-by?
Feb 14 11:40:26 <kanavin> JaMa, I wrote my own patch, as the original patch wouldn't apply with git am
Feb 14 11:40:47 <kanavin> I don't think the original author would make a fuss about it
Feb 14 11:40:49 <JaMa> it did apply with git am for me
Feb 14 11:41:18 <JaMa> probably not, but stealing someone's work isn't nice
Feb 14 11:42:26 <kanavin> did you get a response from them?
Feb 14 11:42:35 <JaMa> no, not yet
Feb 14 11:42:50 <JaMa> https://bugs.gentoo.org/571124#c5
Feb 14 11:46:46 <RP> JaMa: right, I need to update
Feb 14 11:48:23 <jpnurmi_> what's the trick with meta-qt5 to get qmlcachegen deployed on the sdk?
Feb 14 11:49:40 <jpnurmi_> i was hoping to get it from nativesdk-qtdeclarative
Feb 14 11:50:07 <jpnurmi_> + populate_sdk_qt5
Feb 14 12:44:51 <didile> populate_sdk doesn't work on thud
Feb 14 12:44:56 <didile> with meta-qt5
Feb 14 12:45:10 <didile> qtwebkit compilation fails
Feb 14 12:48:11 <jpnurmi> i'm stuck on sumo, actually
Feb 14 12:50:46 <didile> ok
Feb 14 12:50:56 <didile> I've this issue in my side
Feb 14 12:56:25 <jpnurmi> build/tmp/sysroots-components/x86_64-nativesdk/nativesdk-qtdeclarative/opt/myos/2.5.1/sysroots/x86_64-myossdk-linux/usr  does not seem to contain bin/ at all, only include/ and lib/
Feb 14 12:57:37 <jpnurmi> all qtdeclarative tools are missing: qml, qmlcachegen, qmlmin, ...
Feb 14 13:34:10 <JaMa> zeddii: LINUX_VERSION ?= "5.0-rc+" this will sort higher than final 5.0, use ~ which sorts lower
Feb 14 14:23:15 <tsjsieb> I'm trying to do create a qt5-static sdk with thud and I think dependency on qtdeclarative-native is missing in qtdeclarative recipe. How should I add it specifically for the PACKAGECONFIG[static] case
Feb 14 15:06:55 <mabnhdev> I need to support a cortexa72 processor in AArch32 profile.  Yocto (master) seems to only support AArch64.  Could someone provide guidance on getting to AArch32?
Feb 14 15:07:44 <JPEW> mabnhdev: aarch32 is just "traditional" arm?
Feb 14 15:09:25 <mabnhdev> @JPEW I would consider AArch64 to be the "traditional" for the armv8-A architectures.
Feb 14 15:10:34 <mabnhdev> AArch32 is just the 32-bit variant for the armv8-a processors.
Feb 14 15:10:37 <rburton> RP: when connectivity check uris is added to core, i've some patches to start pruning poky.conf
Feb 14 15:12:06 <mabnhdev> @JPEW Sorry, yes, we are talking about ARM processors.
Feb 14 15:12:24 <rburton> mabnhdev: arch-arm64 suggests that if the machine is using arm64 but TUNE_FEATURES doesn't contain aarch64 you get 32-bit
Feb 14 15:13:15 <mabnhdev> @rburton Interesting... I'll give that a try.  Thanks.
Feb 14 15:15:24 <kanavin> rburton, FYI :) http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=akanavin/package-version-updates
Feb 14 15:15:32 <kanavin> I'm converting more recipes at the moment
Feb 14 15:18:17 <Marex> khem: well, I tried building latest meta-qt5 master and in eglfs, the qtwebengine part still doesn't get any input :)
Feb 14 15:18:22 <Piraty> adelcast: do you have a comprehensive list of the opkg-utils and their purpose? so i don't have to dive into the code to check?
Feb 14 15:22:45 <JPEW> kanavin: Are you going to add meson to the MinGW SDK?
Feb 14 15:22:51 <adelcast> Piraty, sorry, no...but they are pretty simple utils
Feb 14 15:23:07 <Piraty> some have intro header, some dont...
Feb 14 15:23:19 <Piraty> one even has a manpage that is unreachable from cli
Feb 14 15:23:22 <kanavin> JPEW, no, I am trying to migrate glib off autotools to meson, which includes getting the mingw nativesdk version of that to build
Feb 14 15:23:32 <adelcast> the main ones are opkg-build (to build packages) & opkg-make-index (create Package indexes),
Feb 14 15:23:48 <Piraty> yeah i figured...
Feb 14 15:23:49 <adelcast> one has a man page yea, you need to build and make install to get it
Feb 14 15:24:01 <adelcast> (opkg-build)
Feb 14 15:24:08 <Piraty> na i mean opkg-build itself. in the script
Feb 14 15:24:09 <adelcast> this repo could use some love
Feb 14 15:24:57 <Piraty> adelcast: hey, i have a question about ipk format. is it mandatory to be ar archive? i thnk openwrt uses tar as the wrapper for data.tar.gz and control.tar.gz
Feb 14 15:24:59 <adelcast> check the Makefile, that script si processed via pod2man to create a manpage
Feb 14 15:25:21 <Piraty> also we doung that dpkg cannot handle them if the order within ar is different (wich is silly!)
Feb 14 15:25:46 <Piraty> ah yes i have the manpage
Feb 14 15:26:18 <adelcast> Piraty, yes I think you are right: https://git.yoctoproject.org/cgit/cgit.cgi/opkg/commit/libopkg/opkg_archive.c?id=44ad8888728959ea0c9eedddeff449b8112e01f5
Feb 14 15:28:13 <Piraty> thanks
Feb 14 15:28:21 <adelcast> np
Feb 14 15:28:36 <Piraty> contribution only via mailing list?
Feb 14 15:29:21 <adelcast> yep,  opkg-devel@googlegroups.com
Feb 14 15:59:28 <inisider> hello. cat anyone explain me how in yocto sysroot is constructed? f.e. in ./tmp/work/aarch64-iosxe-linux/kexec-tools/2.0.17-r0/ there is folder recipe-sysroot. how it was created?
Feb 14 16:02:18 <rburton> bitbake fills it based on DEPENDS
Feb 14 16:02:49 <inisider> thanks.
Feb 14 16:14:20 <Marex> JaMa: you happen to be around ?
Feb 14 16:50:28 <manuel_> i'm having an annoying issue that i can't seem to google away. we are building some packages using go dep, and require ssh agent to fetch some repositories. but in the do_compile step of our recipe, SSH_AGENT_PID is gone from the environment
Feb 14 16:50:47 <manuel_> it is not if i run a devshell, for example. any idea how i can whitelist SSH_AGENT_PID for the go dep step?
Feb 14 16:52:56 <manuel_> SSH_AGENT_PID and SSH_AUTH_SOCK are in BB_ENV_EXTRAWHITE already
Feb 14 16:54:00 <kergoth> might need to add 'export SSH_AGENT_PID' and 'export SSH_AUTH_SOCK' in local.conf to re-export them in the shell environment, rather than only allowing them into the metadata
Feb 14 16:59:06 <manuel_> thx!
Feb 14 17:02:48 <khem> manuel_: http://ix.io/1B3X this is what I do
Feb 14 17:07:15 <manuel_> yeah this is what my colleage had so  far
Feb 14 17:07:23 <manuel_> but it breaks on our ec2 on-demand provisioned build machine
Feb 14 17:07:35 <manuel_> where the ssh-agent is setup by some magic j enkins plugin
Feb 14 17:08:02 <manuel_> and then he would source the environment file in the recipe
Feb 14 17:09:02 <khem> see its setting it /tmp
Feb 14 17:09:09 <khem> which is accessible to other users
Feb 14 17:09:20 <khem> thats the whole point
Feb 14 17:09:39 <manuel_> not sure i follow
Feb 14 18:00:24 <Quazil> Is there a rule for why sometimes patch files go under ${THISDIR}/files: and othertimes under ${THISDIR}/${PN}: ?
Feb 14 18:01:57 <Crofton> both are in the search path I think
Feb 14 18:03:39 <Quazil> You have to add ${PN} to the list - is files automatic?
Feb 14 18:03:40 <Crofton> or the recipe manipulated the FILES PATH :)
Feb 14 18:05:45 <Quazil> I guess what I'm asking is why this deviated from the ebuild legacy of 'files'.
Feb 14 18:05:45 <Quazil> A ton of recipes use ${PN} or both files and ${PN}
Feb 14 18:05:56 <Quazil> So that we know when to do it which way
Feb 14 18:06:29 <Crofton> People can't agree what to do :)
Feb 14 18:19:46 <Quazil> We settled on 'files' and if you need/want more dirs those go under 'files'.
Feb 14 18:20:27 <Crofton> people like versio specific dirs
Feb 14 18:20:36 <Crofton> if yu have more than one version of a recipe
Feb 14 18:20:47 <Crofton> which was more common in the good old days
Feb 14 18:20:55 <Crofton> and gave us something to fight over :)
Feb 14 18:21:08 <Quazil> Sure but that would be ${PNV}
Feb 14 18:21:10 <JPEW> Quazil: I usually tell my co workers to use ${THISDIR}/${PN} unless there is a reason to use file (like the patch, etc. needs to be shared my multiple recipes in the same directory, which does rarely happen). It's really just to have a consistent position more than anything
Feb 14 18:21:56 <Quazil> JPEW: I really do not like using ${PN} because THISDIR is typucally the same as PN which makes it looks like a cp mistake.
Feb 14 18:22:21 <Quazil> files or PNV
Feb 14 18:22:43 <JPEW> sure. I like it because if you *do* have multiple recipes in a directory that aren't sharing files, it's easy to see what files go with what recipe
Feb 14 18:22:57 <Quazil> That I understand
Feb 14 18:23:05 <JPEW> P = "${PN}-${PN}" which I think is what you are looking for :)
Feb 14 18:23:08 <JPEW> arg
Feb 14 18:23:09 <Quazil> So we said that should be files/${PN} :)
Feb 14 18:23:19 <JPEW> P = "${PN}-${PV}"
Feb 14 18:23:26 <Quazil> Yeah
Feb 14 18:23:36 <JPEW> lol, a compromise I guess :)
Feb 14 18:23:44 <Quazil> but files/${PN} or files/${PN}-${PV}
Feb 14 18:24:31 <JPEW> I like ${PN} because it doesn't require moving anything if you upgrade the recipe
Feb 14 18:24:56 <Quazil> JPEW: That necessarily means the patch was not version specific.
Feb 14 18:25:02 <JPEW> Again, this is sort of tenenuous, the same argument could be made for just "files" ;)
Feb 14 18:25:17 <Quazil> I have too much Gentoo in me, can't let go of files
Feb 14 18:25:53 <JPEW> It's fine, I was just giving the advice I usually give when people ask... I think in most cases it's not going to matter
Feb 14 18:38:02 <kergoth> i li ke PN/BPN since you can rearrange recipe locations in the repository without having to rename files if you move two recipes to the same subdir. its repetitive, but consistent
Feb 14 18:47:04 <JPEW> I feel like I'm in good company then ;)
Feb 14 18:49:47 <RP> Quazil: where there are multiple recipes in a given directory files is misleading so we settled on trying to use BPN everywhere
Feb 14 18:50:08 <RP> Quazil: files still has its place but BPN is the recommendation
Feb 14 18:58:08 <yocti> New news from stackoverflow: Python paths not being set on embedded installation <https://stackoverflow.com/questions/54697220/python-paths-not-being-set-on-embedded-installation>
Feb 14 19:05:13 <JaMa> khem: are github PR's for meta-oe now automatically merged by some script from halstead? https://github.com/openembedded/meta-openembedded/pull/120 shows it was merged by him
Feb 14 19:05:58 <JaMa> there are no SOB lines, maybe you merged it exactly as-is to the git.oe.org repo and github shows it on mirror as merged?
Feb 14 20:52:39 <emg> I have a repo with a bunch of shell scripts and one go file. Originally my recipe just created a directory and copied the scripts in the do_install(). Now I want to build that one go file and have it end up in the same place as the scripts. What's the easiest way to do that?
Feb 14 21:07:06 <rburton> emg: there's a load of go classes in oe-core
Feb 14 21:28:28 <yates> is there a good scriptable alternative to fdisk (with a consistent operation between versions)?
Feb 14 21:28:39 <yocti> New news from stackoverflow: How do I get GTK based GUI in a Yocto project? <https://stackoverflow.com/questions/54699001/how-do-i-get-gtk-based-gui-in-a-yocto-project>
Feb 14 21:28:51 <JPEW> yates: sfdisk
Feb 14 21:29:16 <yates> JPEW: isn't that just a wrapper on top of fdisk?
Feb 14 21:29:20 <JPEW> No
Feb 14 21:29:38 <yates> it's a whole different utility?
Feb 14 21:29:56 <JPEW> It might use the same library or something, but it's designed to be scriptable
Feb 14 21:30:31 <JPEW> Although, if you don't want to get stuck calculating C/H/S geometry, I suggest you find a recent version :)
Feb 14 21:31:00 <yates> i have a script based on fdisk, but it doesn't operate the same between 2.29 and 2.32
Feb 14 21:32:08 <yates> ok, hold on. nm!
Feb 14 21:32:40 <yates> no, that is correct
Feb 14 21:33:42 <JPEW> yates: sfdisk adds new formats and options, but AFAIK if you write a script with one version, it should continue to work the same going forward on newer versions
Feb 14 22:21:57 <arielm> I created a recipe to add udev rules, fairly simple, it works
Feb 14 22:22:21 <arielm> but somehow it doesn't get cached, every time i bitbake something, it get's built again
Feb 14 22:22:49 <arielm> any ideas what to look for?
Feb 14 22:24:17 <arielm> to be honest i copy/pasted from another recipe
Feb 14 22:24:35 <arielm> the only thing i see is a do_install[nostamp] = "1"
Feb 14 22:24:35 <arielm> do_unpack[nostamp] = "1"
Feb 14 22:24:42 <arielm> could that be the problem ?
Feb 14 23:01:10 <khem> JaMa: its a script
Feb 14 23:02:23 <JaMa> khem: you mean the hook which is publishing the read-only mirror to github or some other script which merges the PRs from there?
Feb 14 23:02:46 <khem> yes
Feb 14 23:02:56 <khem> I do pull from github pulls into master-next though
Feb 14 23:03:00 <khem> I have workflow for that
Feb 14 23:03:09 <khem> but merged from gh are not done
Feb 14 23:03:16 <khem> I wish we started doing that
Feb 14 23:03:46 <JaMa> ok, than it's just strange comment from gh
Feb 14 23:04:26 <JaMa> it was merged by you to master-next and halstead's account just pushed it to gh with the hook
Feb 14 23:09:07 <aehs29_> do we have the update-alternatives util somewhere? (not the busybox one)
Feb 14 23:10:27 <aehs29_> it looks like we do keep track of the alternatives on /usr/lib/opkg/alternatives, but the busybox update-alternative does not provide a way to just switch to one of those
Feb 14 23:20:45 <RP> aehs29_: its part of opkg-utils
Feb 14 23:21:06 <aehs29_> RP: thanks
Feb 14 23:24:02 <khem> JaMa: hmm
Feb 15 01:29:25 <yocti> New news from stackoverflow: How to bring php5 in yocto image? <https://stackoverflow.com/questions/51627349/how-to-bring-php5-in-yocto-image>
**** ENDING LOGGING AT Fri Feb 15 02:59:56 2019