**** BEGIN LOGGING AT Sun May 10 02:59:57 2020
May 10 11:36:37 <leon-anavi> khem, so far I haven't been able to reproduce the lirc 0.10.1 issue even on the yoe setup with docker: https://gist.github.com/leon-anavi/7c3c2e41604b8d40c981a2f12567f3fc#file-lirc-0-10-1-qemux86-64-yoe-log
May 10 11:37:26 <leon-anavi> I'm probably doing something wrong with my attempts. I have a clue where this error might be coming from, just need to reproduce it to be able to test the potential fix.
May 10 15:08:02 <khem> leon-anavi: yes mee too, I think it must have been some oe-core master-next cruft 
May 10 15:10:52 <leon-anavi> I am not feeling comfortable making a new version of the patch for upgrading lirc in an attempt to fix this issue python-pkg/VERSION without being able to properly reproduce and test it locally.
May 10 15:25:16 <khem> no worries I will queue it and watch for few CI cycles 
May 10 15:29:18 <leon-anavi> ok, thanks for helping me out with this patch!
May 10 16:07:27 <armpit> khem, c4 build fails with cc1: error: switch '-mcpu=armv8.2-a' conflicts with '-march=armv8-a' switch [-Werror]
May 10 16:08:52 <armpit> will poke at it a bit
May 10 17:24:36 <Jin^eLD> heh, timed out and did notice..
May 10 17:24:41 <Jin^eLD> I am wondering, how are dependencies handled with pypi? if a package has a gazillion of dependencies that are not available as recipes, what will happen? will they get pulled in or will it fail?
May 10 17:24:51 <Jin^eLD> I guess I just need to try..
May 10 17:25:34 <Jin^eLD> packaging python applications seems to be quite a PITA not only due to the number of python modules they depend on, but also when they depend on specific versions of those modules...
May 10 17:29:08 <kergoth> heh, there's a reason most people on desktop systems don't distribute their python projects as distro packages :)
May 10 17:29:38 <kergoth> don't usually, rather
May 10 17:31:12 <Jin^eLD> kergoth: its an extreme PITA :)
May 10 17:31:21 <Jin^eLD> and I guess I now know why "virtual env" came around
May 10 17:31:54 <kergoth> exactly. easier to just ship the whole damn thing in a self contained blob. sometimes even more so, include the interpreter too in a single executable :)
May 10 17:32:01 <kergoth> or docker image, or..
May 10 17:32:02 <Jin^eLD> as easy as it is to develop in python, this forest of modules and their versions, which actually makes it so easy to develop stuff, is a major PITA when trying to get something to work...
May 10 17:32:18 <Jin^eLD> doh
May 10 17:32:36 <Jin^eLD> so how do we handle that?
May 10 17:33:04 <Jin^eLD> will those deps get pulled and packaged with the main app or do I need to go through each single one of the dependencies and create a recipe for it if its not yet available?
May 10 17:33:31 <kergoth> my guess is it's the latter, but haven't read the bbclasses, so can't say with much confidence
May 10 17:33:47 <kergoth> presumably we could create new classes to do it differently if that's the xcase, though. to make something more self contained
May 10 17:34:09 <kergoth> hmm
May 10 17:34:30 <Jin^eLD> well, one problem I see is that this is no leightweight at all, I ended up with +150MB of python deps in the rootfs, so I guess blobbing is not a good idea in Yocto context
May 10 17:34:41 <kergoth> oof
May 10 17:34:56 <Jin^eLD> but resolving that stuff manually is so damn teadious :)
May 10 17:35:32 <Jin^eLD> I was looking at meta-maker, which packaged a pre-release octoprint
May 10 17:35:43 <Jin^eLD> and upping it to the release version turned out to be quite an effort
May 10 17:36:11 <Jin^eLD> gazillon of deps pinned to specific versions
May 10 17:36:25 <Jin^eLD> and of course the work meta-maker guys did is somewhat outdated now and the versions do not match anymore
May 10 17:41:05 <Jin^eLD> moto-timo: btw are you guys maintaining meta-maker any longer or is it dead? i.e. would you be interested in some updates or should I not bother and publish them in my own layer?
May 10 17:50:48 <khem> armpit: try with oe-core/master-next you need a patch from there https://git.openembedded.org/openembedded-core/commit/?h=master-next&id=14cbd2c4e1b300fbafbd8f221c2c3f5cff1d5811
May 10 17:51:41 <khem> armpit: once in master they should be backported to dunfell too, I will send a request eventually
May 10 17:53:55 <khem> armpit: send another pull for meta-odroid to get x11 going 
May 10 17:54:04 <khem> s/send/sent/
May 10 19:40:28 <armpit> yep. saw it. thanks
May 10 19:42:35 <armpit> I am working on dunfell meta-odroid for the c4 backports.. 
May 10 19:43:36 <armpit> I lost on of my build systems do to "dd" the wrong device name... its why I don't fly 
**** ENDING LOGGING AT Mon May 11 02:59:57 2020