**** BEGIN LOGGING AT Tue Apr 14 02:59:57 2020
Apr 14 07:21:15 <qschulz> $
Apr 14 07:47:56 <tprrt> Hello, I have a question about warrior testsdkext. I tried to run them on Ubuntu 18.04, but the execution fails on the error "ModuleNotFoundError: No module named '_sysconfigdata'". Tests seems to be executed by python3, what is apparently the source of my problem, to be sure, the tests must be by Python2? And maybe you had some recommendations for the testdkext test?
Apr 14 08:54:29 <hmw1> hi what am i doing wrong i have PV = "1.0+git${SRCPV}" but the package name is 1.0+git999-r0 (999 is not in the git string)
Apr 14 08:55:35 <erbo> hmw1: Do you have a "devtool modify" active?
Apr 14 08:56:03 <hmw1> yes
Apr 14 08:56:15 <erbo> I think that is what sets that version
Apr 14 09:01:02 <hmw1> erbo:  tnx that also explanes the app from the ipk that is still buggy
Apr 14 09:30:32 <mous16> Hello everybody
Apr 14 10:33:45 <ikke> A question I can' task at stackoverflow :-)
Apr 14 10:34:22 <ikke> Although Xilinx is member of Yocto, there meta layers are rather old (Warrior) and not that frequently updated.
Apr 14 10:34:28 <ikke> Why?
Apr 14 10:34:55 <ikke> There Petalinux product is in fact Yocto, so they and there customers are using it.
Apr 14 10:35:14 <ikke> But is there no need to have the latest and the greatest?
Apr 14 10:35:53 <erbo> ikke: could you like what layer you mean? Looking at e.g. https://github.com/Xilinx/meta-xilinx/tree/zeus is seem recent?
Apr 14 10:36:15 <ikke> 2 sec, why didn't I found this.
Apr 14 10:36:43 <ikke> https://github.com/Xilinx/meta-xilinx/blob/master/meta-xilinx-bsp/conf/layer.conf#L14
Apr 14 10:37:06 <ikke> Fair, 't is not the same.
Apr 14 10:37:39 <erbo> Don't use master branch then, use the branch that correspond to the yocto release you want to use
Apr 14 10:37:56 <erbo> https://github.com/Xilinx/meta-xilinx/blob/zeus/meta-xilinx-bsp/conf/layer.conf
Apr 14 10:38:32 <ikke> Thanks, I missed that part.
Apr 14 10:39:16 <erbo> No worries, it's confusing with old master branches
Apr 14 10:39:29 <ikke> But still, do they still go 100% for Yocto?  Or is Vitis (or whatever) the latests thing.  I'm still have to found something technical about Vitis behind all there marketing.
Apr 14 10:39:56 <erbo> I have no idea, don't use xilinx. Maybe some other here do though.
Apr 14 10:40:53 <ikke> Anyhow, thanks for pointing me to 'it's not the master'.
Apr 14 10:45:40 <nameclash> ikke: petalinux releases come twice a year YEAR.1 and YEAR.2. The current is 2019.2 which was released before zeus was released
Apr 14 10:46:05 <nameclash> so looking from that point of view I'd say they're pretty up to date in their release cycle
Apr 14 10:46:31 <nameclash> I would expect them to adopt zeus with petalinux 2020.1
Apr 14 10:53:21 <ikke> @nameclash: thanks.  I was just wondering why I see not that much commits on github.  I guess to become active when the release is upcoming.  But on there Linux kernel they seem to have another way of working.
Apr 14 10:54:03 <ikke> Anyhow: I'll give it a try.
Apr 14 11:27:26 <Dima_Sharihin> hi guys. It seems, that dtls in net-snmp 5.8 is kinda broken in package release. Is it hard to migrate to pre-release branch? Bitbake recipe contains a ton of source code patches and that's discourages me
Apr 14 11:29:22 <kanavin_home> Dima_Sharihin: it is better to convince the upstream to make a new release, or backport the patches
Apr 14 11:30:58 <Dima_Sharihin> kanavin_home, its developers live in a interesting world of long release cycles. Net-SNMP was released in a 2018. Their git contains hundreds of commits since then
Apr 14 11:32:37 <kanavin_home> Dima_Sharihin: then backporting the needed patches is probably a better option
Apr 14 11:33:49 <Dima_Sharihin> kanavin_home, or firstly I should implement it... https://github.com/net-snmp/net-snmp/commit/a49aa9c132cd38a9170de19b454dc27a67c2683c
Apr 14 11:34:26 <yocti> New news from stackoverflow: How do I add more python modules to my yocto/openembedded project? <https://stackoverflow.com/questions/38862088/how-do-i-add-more-python-modules-to-my-yocto-openembedded-project>
Apr 14 13:48:47 <PatrickE> Hey, is there a well known alternative for creating GUI applications in Embedded Linux (using Framebuffer) ? I looked at Qt, it looks good but the license is a problem i guess
Apr 14 14:27:48 <JPEW> halstead: I attempted to send an OE TSC reminder email to tsc@lists.openembedded.org and openembedded-memebers@lists.openembedded.org and they both bounced with a 500 permission error?
Apr 14 14:29:49 <RP> JPEW: latter has a typo?
Apr 14 14:29:58 <RP> memebers
Apr 14 14:32:11 <JPEW> ugh, ya. It was correct in my email :)
Apr 14 14:32:43 <JaMa> FWIW: I just received it
Apr 14 14:33:17 <JaMa> from members list
Apr 14 14:34:19 <JaMa> and the tsc one https://lists.openembedded.org/g/tsc/topics doesn't show it yet
Apr 14 14:35:42 <JaMa> JPEW: shouldn't it be 9PM now? I think it's summer time already
Apr 14 14:54:26 <JPEW> JaMa: Yes, sorry
Apr 14 14:54:32 <JPEW> stupid DST
Apr 14 14:55:07 <tlwoerner> YPTM: tlwoerner is on
Apr 14 14:57:42 <dl9pf> YPTM: Jan-Simon is on
Apr 14 14:58:34 <smurray> YPTM: Scott Murray is on
Apr 14 14:58:37 <JPEW> YPTM: Joshua Watt here
Apr 14 15:20:37 <JaMa> YPTM: Martin Jansa is on (muted)
Apr 14 15:33:45 <amgedr> hi everyone
Apr 14 18:05:51 <bluelightning> the npm reworking that got done this release looks really good
Apr 14 18:06:05 <kanavin_home> yup
Apr 14 18:06:13 <kanavin_home> now, rust for 3.2!
Apr 14 18:06:25 <bluelightning> can't say it makes me want to go near npm/node.js, but at least our handling of it is much better...
Apr 14 18:06:44 <bluelightning> indeed
Apr 14 18:32:45 <armpit> kanavin_home, ping vmeson. its on the old 3.1 planning doc. maybe we move it up into the 3.2 area
Apr 14 18:33:24 <kanavin_home> who is vmeson? :)
Apr 14 18:33:51 <rburton> randy macleod
Apr 14 19:48:46 <riz95> If I would like to have "export QT_QPA_PLATFORM=eglfs" built into my image, where in my layers/recipes where I put it?
Apr 14 20:34:10 <riz95> Can IMAGE_INSTALL_append go in my custom distro.conf file as opposed to the build local.conf file? Is there a reason why I would not want to do that?
Apr 14 20:35:46 <bluelightning> riz95: it can, yes... in fact the less you have in local.conf, the better (easier to reproduce if you start a new build dir or even change build machines)
Apr 14 20:36:13 <bluelightning> riz95: only concern in both cases is that it will affect all images, possibly including initramfs images (if you use those)
Apr 14 20:37:47 <riz95> Thanks!
Apr 14 20:38:45 <riz95> I am assuming the same goes for PACKAGECONFIG_appends, etc.
Apr 14 20:39:18 <bluelightning> correct... though PACKAGECONFIG changes would typically go in bbappends for each recipe since they are almost always recipe-specific
Apr 14 20:42:29 <riz95> Actually, wouldn't a better place for all this be in my custom image recipe, my-image.bb?
Apr 14 20:42:48 <bluelightning> you can't set things in an image recipe to affect other recipes
Apr 14 20:43:03 <bluelightning> (actually, any recipe to any other recipe, image or otherwise)
Apr 14 20:44:44 <riz95> I see a few cases of "IMAGE_INSTALL +=" being used to extend the image features
Apr 14 20:44:57 <riz95> In the image recipe file
Apr 14 20:45:27 <bluelightning> yes, that's fine, that's just selecting what's in the image
Apr 14 20:45:40 <bluelightning> in terms of packages produced by other recipes
Apr 14 20:46:21 <riz95> Right.
Apr 14 20:46:32 <bluelightning> so IMAGE_INSTALL should ideally be in a custom image recipe, apologies if that was the only thing you were referring to above
Apr 14 20:46:47 <riz95> Yeah
Apr 14 20:46:54 <riz95> Sorry, I wasnt clear
Apr 14 20:47:04 <riz95> So, I can use append there as well...
Apr 14 20:52:06 <bluelightning> you can, but typically copy-and-modify is recommended for image recipes, you might as well fully define the list of packages in there
**** ENDING LOGGING AT Wed Apr 15 02:59:57 2020