[00:00] <RAOF> It's pretty consistent as long as you're familiar enough with the consistency.
[00:01] <RAOF> Likewise, ${_bindir} in your .spec :)
[00:01] <Pharaoh_Atem> well, I'm referring the packages that basically have dh: $@ and that's it
[00:01] <Pharaoh_Atem> so much automagic I have no idea what happened
[00:03] <RAOF> Yeah, at that point you look at the other files in the debian/ directory.
[00:03] <Pharaoh_Atem> yeah
[00:03] <Pharaoh_Atem> or just make everything verbose and note what the hell happened
[00:46] <ali1234> bschaefer: i have a question about your kodi on mir post. you talked about the raspberry pi. does mir even run on it? if so what driver?
[00:48] <ali1234> also the snap: will you try to make it work as both embedded and as a "normal desktop" app? if so what challenges do you expect to see?
[00:49] <bschaefer> ali1234, hello! So i know mir works on the dragon board (i think it works on the raspi3 .. like 95% sure :)
[00:49] <bschaefer> as for the snap, i have it working on amd64, but for armhf/64 it requires a bit different packages soo ill have to create a different snap for it
[00:50] <bschaefer> but once its all built it should be as simple as installing from the store (ideally)
[00:50] <ali1234> and i guess one final question: i'm working on a custom Qt project for rpi, and at the moment i have to custom build Qt and basically he entire distro to make it truely embedded
[00:50] <ali1234> Qt needs certain configuration options to run on the rpi GPU
[00:50] <bschaefer> (im 95% sure about the raspi3 dont think 2 works)
[00:51] <ali1234> neither ubuntu nor debian nor raspbian builds it with those options
[00:51] <bschaefer> RAOF, do you know if we working raspi3 yet?
[00:51] <ali1234> i don't know about mir support though
[00:51] <bschaefer> yea
[00:51] <bschaefer> thats my next step is to explore that a bit more
[00:51] <RAOF> No idea
[00:51] <ali1234> but would it be worth considering using mir? i'm making a kiosk device that runs only one app
[00:52] <ali1234> at the moment i have no windowing system or display server at all
[00:52] <bschaefer> yeah you can look at miral
[00:52] <bschaefer> miral-examples which installs a miral-kiosk
[00:52] <RAOF> If it runs on the rpi :)
[00:52] <bschaefer> yeah right if it runs on raspi :)
[00:52] <bschaefer> i know the dragon board works but not sure about raspi
[00:52] <ali1234> i've spent about 2 months customizing raspbian to the point where i have a readonly ramfs that does everything and is only 80MB
[00:53] <ali1234> the rpi has no working open source driver yet
[00:53] <ali1234> it has a half finished one, at least last time i checked
[00:54] <RAOF> It doesn't have an android stack, does it?
[00:54] <ali1234> and the proprietary API is not widely supported. actually wayland recently dropped support for it
[00:54] <RAOF> That might be easier for you.
[00:54] <ali1234> rpi? no, not yet
[00:54] <ali1234> supposedly android 7 will be ported
[00:54] <ali1234> i'm not sure why it would be easier though
[00:55] <bschaefer> but yeah *once* mir does work on it, it would be a nice WM
[00:55] <bschaefer> for that
[00:55] <ali1234> i've worked with android before... i ported ubuntu touch to a phone... i probably won't ever go near it again at the system level cos it's horrible
[00:55]  * bschaefer will have to poke someone about the raspi stuff
[00:56] <ali1234> so you didn't really answer my question about "embedded"
[00:56] <ali1234> for example, there's problems with audio
[00:56] <ali1234> if you make a desktop app you must use pulseaudio
[00:57] <ali1234> and give it all the right plugs and etc
[00:57] <ali1234> but if you make an embedded snap you have to use raw alsa
[00:57] <bschaefer> for a snap?
[00:57] <ali1234> yes
[00:57] <bschaefer> yeah
[00:57] <ali1234> desktop snap vs embedded snap
[00:57] <bschaefer> ali1234, im going to have to create a different snap for embedded (as far as i know)
[00:57] <ali1234> there's contradictions that prevent one snap from fulfilling both roles
[00:57] <bschaefer> soo you'll have to maintain two snapcraft.yaml
[00:57] <bschaefer> yeah
[00:58]  * bschaefer doesnt like that either and isnt sure if they are working on a better solution there
[00:58] <ali1234> yeah this is pretty much the conclusion i reached
[00:58] <ali1234> they are working on an "embedded pulseaudio server" type thing
[00:58] <bschaefer> you can always attempt to poke in #snappy
[00:58] <ali1234> that will provide PA services on embedded setups
[00:58] <bschaefer> that would be nice
[00:58] <ali1234> but there are other problems
[00:58] <ali1234> oh believe me i have :)
[00:59] <bschaefer> :), thats good as im still attempting to learn snap fully atm
[00:59] <ali1234> i just wanted to see what you thought about this purely because you used the word "embedded" in that post, and nobody else seems really all that interested in it
[00:59] <bschaefer> (and reaching the same issues)
[00:59] <ali1234> mostly people are making desktop snaps
[00:59] <bschaefer> ali1234, yeah so *the* ideal goal is to make an embedded snap which we have one for the mir server
[00:59] <bschaefer> for arm64 (tested on the dragon board)
[01:00] <bschaefer> and now its to find nice use cases such as kodi/simple 1 application
[01:00] <bschaefer> for a kisok type system
[01:00] <ali1234> yeah that sounds similar to the plan for PA
[01:00] <bschaefer> kiosk*
[01:01] <ali1234> well, thanks for your time and thoughts
[01:02] <bschaefer> np! Hopefully more answer will become clearer soon
[01:02] <ali1234> i guess i'll keep watching for updates, but meanwhile i'll probably continue using my own hand rolled stuff
[01:02]  * bschaefer hopes at lease :)
[01:02] <bschaefer> yeah
[01:02]  * bschaefer will be diving into this next week or so soo... hopefully i can get more info out as well
[01:06]  * bschaefer eods
[01:37] <duflu> ali1234, RAOF: I recall last month during his presentation, kgunn said that tvoss made the step to getting things going on Raspberry Pi.
[01:37] <duflu> Presumably no code change was required because we haven't seen any
[01:39] <duflu> (other than my code change which just means in Mir 0.25 you'll see less logging about "Unknown" output types)
[01:46] <RAOF> That's right! That's what I was thinking of.
[03:09] <duflu> Ha. I just noticed GLX explicitly does not support correct multi-monitor frame sync. Just "the monitor used to determine MSC is screen 0 of <display>."
[09:43] <fritsch> !seen bschaefer
[09:43] <ubot5`> I have no seen command
[09:46] <alan_g> fritsch: he's likely asleep (on east coast time)
[10:13] <fritsch> alan_g: then we let him sleep. Wanted to say thank you for his well written Pull Request to kodi for MIR support
[10:13] <fritsch> alan_g: and discuss if we can get VAAPI support somehow, as this is one - in comparison to vdpau does not need any x11 dependencies
[10:15] <alan_g> fritsch: that's likely better asked during USA day (not my area of expertise). alf_ ^ any thoughts?
[10:16] <alan_g> duflu: ^
[10:17] <duflu> I have no thoughts on that right now. Also it's getting late...
[10:17] <fritsch> :-)
[10:17] <fritsch> no hurry
[10:17] <fritsch> i will idle here for longer
[10:17] <duflu> Night
[10:18] <fritsch> just though it would be nice if a kodi mir variant could also use hw accelerated video decoding
[10:18] <tvoss> fritsch: we have had some initial discussions on vaapi support, we are definitely aiming to support it
[10:18] <fritsch> if you use gles for rendering anyways
[10:19] <fritsch> there is nothing that would disturb that
[10:19] <tvoss> yup, exactly
[10:19] <tvoss> RAOF: if you are still around: did jhodapp talk to you, yet?
[10:20] <fritsch> we also don't use vaPutSurface anymore in kodi
[10:20] <fritsch> which would have this x11 pixmap dependency
[10:20] <fritsch> so, what you get is two textures Y and VU
[10:20] <fritsch> and then can do whatever you want with them
[10:21] <fritsch> I pinged bschaefer about that in the PR, let's see what discussion reveals
[10:21] <fritsch> from code pov, there is nothing that stands in the way merging it into kodi
[10:21] <tvoss> ack and thx, sounds great :)
[10:22] <fritsch> (we are currently only discussing if it can make it into our v17 release, which RC is just some days ahead, we hope we do so)
[10:22] <tvoss> fritsch: great, just let bschaefer know if you need anything for inclusion with your release
[10:26] <fritsch> tvoss: nope, his code is fine - it's us internally, that need discussing. I voted +1 - so let's see
[10:26] <tvoss> ack
[14:29] <Son_Goku> are the mir demo clients supposed to segfault with vmware gfx driver?
[14:30] <alan_g> they're not supposed to, but it's a known problem
[14:32] <alan_g> bug 1639745 is probably the most relevant
[14:32] <ubot5`> bug 1639745 in Mir "Mir GL clients never appear at all on VirtualBox" [High,In progress] https://launchpad.net/bugs/1639745
[14:34] <Son_Goku> it might not be the same issue
[14:34]  * Son_Goku is installing debuginfo packages now
[14:38] <Son_Goku> alan_g: https://paste.fedoraproject.org/477293/78868414
[15:19] <ogra_> bschaefer, yo ... i just looked at your kodi snap ... try: --with-ffmpeg=force ... that will build it in-tree
[15:20] <bschaefer> ogra_, hmm it tired lots of combos (building ffmpeg my self) then it would have a linking error at the end
[15:20] <bschaefer> ogra_, ill try that again though!
[15:21]  * ogra_ is trying to get it to build on pi3 currently 
[15:22] <bschaefer> ogra_, o sweet was wanting to ask if we had kernel support for mir on that :)
[15:22]  * bschaefer only has a dragon board
[15:22] <ogra_> also, once you are done we should roll a dedicated kodi-core image ;)
[15:22] <bschaefer> ogra_, theres also issue with armhf
[15:22] <bschaefer> packaging
[15:22] <bschaefer> like crystal-hd
[15:22] <ogra_> i think there are still kernel patches missing
[15:22] <ogra_> yeah, i had to drop crystal-hd for the moment
[15:22] <bschaefer> dang, well hopefully soon ish
[15:23] <bschaefer> ogra_, yeah i tried to ask around #snappy if there was any arch support
[15:23] <ogra_> (trying to get it to finish a build ... not trying to get it to run yet ;) )
[15:23] <bschaefer> :)
[15:23] <bschaefer> well that works as well (i was planning on tackling that for dragon board next week)
[15:23] <ogra_> i think tvoss and ppisati work together on the kernel patches for dragon and pi support
[15:23] <bschaefer> o nice
[15:24] <bschaefer> ogra_, if you get it working you can throw me a diff :)
[15:24] <ogra_> i surely will
[15:24] <bschaefer> (or create a new kodi-mir-arm snap branch)
[15:24] <bschaefer> since i think we'll need to support two different branches atm
[15:24] <ogra_> INSTALL	libavutil/ffversion.h
[15:24] <ogra_> INSTALL	libavutil/libavutil.pc
[15:24] <ogra_> checking for FFMPEG... yes
[15:24] <ogra_> Checking for SWIG installation
[15:24] <ogra_> that doesnt look to bad
[15:24] <ogra_> (though i'm indeed not at any linking stage yet)
[15:24] <bschaefer> ogra_, yeah ive gotten past that then i hit a linking issue (did you install any extra packages?)
[15:25] <bschaefer> if i tried ffmpeg from universe it would fail to compile
[15:25] <bschaefer> due to some breakage somewhere
[15:25] <ogra_> i used your snapcraft.yaml on a plain rpi3 in the classic shell
[15:25] <ogra_> with the =force added and crystal-hd dropped for now
[15:25] <bschaefer> hopefully thats all! (as i force should work for both desktop/arm)
[15:25] <fritsch> i see kodi's ffmpeg building externally driving you nuts :-)
[15:26] <fritsch> before I forget it
[15:26] <fritsch> bschaefer: https://cgit.freedesktop.org/libva/tree/va/egl/va_backend_egl.h
[15:26] <fritsch> when I build ffmpeg manually I use it like:
[15:26] <bschaefer> fritsch, :) mainly our builders block wget for the package
[15:26] <fritsch> ./configure --prefix=/opt/ffmpeg --extra-version='VERSION=3.0.1-Krypton-alpha' --disable-devices --enable-ffplay --enable-ffmpeg --disable-ffserver --disable-doc --enable-gpl --enable-runtime-cpudetect --enable-postproc --enable-vaapi --enable-vdpau --enable-bzlib --enable-gnutls --enable-muxer=spdif --enable-muxer=adts --enable-muxer=asf --enable-muxer=ipod --enable-encoder=ac3 --enable-encoder=aac --enable-encoder=wmav2 --enable-protocol=http --e
[15:26] <fritsch> to /opt whatever
[15:26] <fritsch> and then tell cmake how to use it
[15:27] <bschaefer> o nice as I can setup a git clone + build (with those commands) and hopefully that'll help
[15:27] <fritsch> cmake -DENABLE_VAAPI=1 -DENABLE_VDPAU=0 -DENABLE_CEC=0 -DCMAKE_BUILD_TYPE=Release -DENABLE_INTERNAL_FFMPEG=0 -DFFMPEG_PATH=/opt/ffmpeg project/cmake/
[15:27] <fritsch> adjust the version above, it's currently 3.1.5-Krypton-something
[15:27] <bschaefer> fritsch, sweet thanks, that should help with that! (was running into issue with our builders nothing local :)
[15:28] <fritsch> i can also get you our build system cmake guy and ppa packager in here
[15:28] <bschaefer> fritsch, hmm and right we do have EGL/DRM support
[15:28] <fritsch> for a "howto build it with standard ubuntu's ffmpeg"
[15:28] <bschaefer> its something i need to look into (was looking into while doing the kodi work but mainly a the heck does this do :)
[15:29] <bschaefer> fritsch, o a ppa would work as well
[15:29] <bschaefer> i should try building it by hand again with those options first
[15:29] <fritsch> we have a ppa for kodi, yes. but that is currently building for x11
[15:29] <bschaefer> i could always roll my own as well
[15:29] <fritsch> jep
[15:30] <bschaefer> didnt think about it :)
[15:30] <fritsch> cmake -DENABLE_VAAPI=1 <- might need to set that to 0
[15:30] <fritsch> until investigated
[15:30] <bschaefer> yup was thinking that
[15:30] <fritsch> btw. I read crystalhd above
[15:30] <fritsch> you plan to bring it back? :-)
[15:31] <ogra_> sigh
[15:31] <ogra_> g++: internal compiler error: Killed (program cc1plus)
[15:31] <ogra_> Please submit a full bug report,
[15:31] <ogra_> with preprocessed source if appropriate.
[15:31] <fritsch> good old times + a whole lot of kernel patches?
[15:31] <bschaefer> fritsch, i had no clue what it did :|
[15:31] <ogra_> ...
[15:31] <bschaefer> i should disable it
[15:31] <bschaefer> ogra_, :(
[15:31] <fritsch> it's a little card that can decode h264 / mpeg2 and sometimes vc1
[15:31] <fritsch> 1080p is max
[15:32] <bschaefer> sounds like something thats not even supported by this
[15:32] <fritsch> if you see it working the first time, you will see a "green dot" in the upper left corner :-)
[15:32]  * bschaefer looks at disabling it
[15:32] <fritsch> the decoder people used this green dot to say: all okay
[15:32] <bschaefer> haha
[15:32] <bschaefer> thats a good way to know if its working!
[15:32] <bschaefer> ogra_, also kodi take a bit of time compiling on arm ...
[15:32] <fritsch> we removed support for it some years ago, but there are a huge load of ATV devices out there, where they removed the wireless lan card
[15:32] <ogra_> yep, i know
[15:32] <fritsch> and added a crystalhd
[15:32] <ogra_> not my first attempt ;)
[15:32] <bschaefer> ogra_, :)
[15:33] <ogra_> (and i usually give up after a few days :P )
[15:33] <bschaefer> o good to know (i just threw that depends when it complained when i was trying to get the snap together)
[15:33] <fritsch> for arm we currently run on amlogic (pretty massive closed blob for the gpu driver), IMX, raspberry pi and related stuff, like odroid
[15:33] <fritsch> pandaboard
[15:34] <ogra_> heh
[15:34] <ogra_> there are still people actively using pandas ?
[15:34] <fritsch> most stuff is pretty useless if you cannot use hw acceleration for gpu decoding
[15:34] <fritsch> not really
[15:34] <fritsch> cause of ^^
[15:34] <bschaefer> i was worried about that
[15:34] <ogra_> yeah, dead since 2012
[15:34] <bschaefer> since with out gpu decoding it looks fine on the desktop
[15:34] <fritsch> jep
[15:34] <bschaefer> but i assumed since better hardware
[15:34] <fritsch> there is currently content approaching VP9, HEVC-10 bit based
[15:35] <fritsch> that no reason CPU will be able to playback
[15:35] <ogra_> pi3 with libreelec and dvb-s2 card is what drivey my TV currently ...
[15:35] <bschaefer> ogra_, o also we cannot use CMake for kodi building sadly since snappy doesnt support non-root cmake files
[15:35] <fritsch> ogra_: jep
[15:35] <ogra_> i want that to be ubuntu-core eventually
[15:35] <fritsch> probably the most optimized kodi device on the planet
[15:35] <ogra_> (but am totally not in a hurry)
[15:35] <fritsch> some say: 1/3 of the pi's firmware is kodi workarounds
[15:35] <ogra_> haha
[15:35]  * bschaefer would like a cmake plugin support for root_dir=/path/to/root/CMakeLists.txt
[15:35] <fritsch> popcornmix, main contributor to pi development is in our kodi team
[15:36] <bschaefer> o very nice!
[15:36] <fritsch> bschaefer: that hw accel stuff is why I jumped in. You won't have happy people on MIR if everything is sw decoded
[15:36] <ogra_> yeah
[15:36] <bschaefer> yeah i can imagine (also why most likely my VM was working very well either :)
[15:37] <bschaefer> it something i had been looking at but i should dig in to see if its supported already and how to use it!
[15:38] <bschaefer> if not it *should* be simple enough according to RAOF, do to a mir backend but we may be missing some API for it specifically (something i hadnt dug further in yet)
[15:39] <anpok> pixel format types probably
[15:40] <bschaefer> anpok, it was /me attempts to remember... taking an eglimage thats decoded and shoving it into a mir surface
[15:41] <anpok> hm getting a mir buffer from an egl image?
[15:41] <anpok> that on our list fro 17.04
[15:41] <anpok> +s
[15:41] <anpok> hm or nearly that
[15:42] <bschaefer> anpok, right for RenderSurface stuff?
[15:42] <bschaefer> or outside that?
[15:42] <anpok> actually outside that for xmir
[15:42] <fritsch> bschaefer: if you can do it with just egl/drm the better
[15:42] <bschaefer> fritsch, i agree (not sure if we are missing some drm support there for it though)
[15:43] <fritsch> cause showing that a display server bases on standards and not setting explicit new ones, would be great
[15:43] <bschaefer> in the driver... ill have to double check
[15:43] <fritsch> vdpau is dead anyways :-)
[15:43] <bschaefer> agreed
[15:43] <bschaefer> o good, dont have to look into that then :)
[15:43]  * bschaefer hadnt yet but was on the list
[15:43] <anpok> fritsch: would it sense at some time.. to turn kodi into a server?
[15:43] <fritsch> anpok: it's on the way
[15:43] <anpok> oh
[15:43] <bschaefer> o sweet
[15:43] <fritsch> we try to separate gui render thread from the rest
[15:43] <fritsch> you know, we started with a mainloop
[15:44] <fritsch> with a huge and ugly mess of global gfx_locks
[15:44] <fritsch> :-(
[15:44] <fritsch> and on that move you get "server" or headless for free
[15:44] <fritsch> but needs a lot architectural cleanup
[15:44] <bschaefer> yeah i can imagine, but thats sounds awesome!
[15:44] <anpok> fritsch: oh ok ... we meant using miral instead of mirclient
[15:44] <tvoss> fritsch: we could theoretically put kodi on top of mir as a "shell"
[15:45] <anpok> and running applications inside of kode
[15:45] <anpok> *kodi
[15:45] <fritsch> we can act as a window manager
[15:45] <tvoss> so you would just transparently become a mir server
[15:45] <fritsch> on x11 already
[15:45] <tvoss> fritsch: hah, interesting
[15:45] <fritsch> but yeah, we cannot open new windows and such
[15:45] <anpok> fritsch: oh where is the code for that?
[15:45] <fritsch> but as bschaefer made a brilliant PR which our chief architect liked very much ...
[15:45] <tvoss> fritsch: miral is our answer there, it's a layer that allows you to specify window mgmt policy
[15:45] <fritsch> I am sure there is a log of credit for something like that in the future
[15:46] <tvoss> fritsch: yeah, probably a step two, get started as a client first
[15:46] <fritsch> though - I also have to say, we are also looking into wayland and also direct DRM direction
[15:46] <fritsch> for settop boxes mainly
[15:46] <fritsch> to run on KMS
[15:46] <bschaefer> fritsch, well your code was quite easy to read (some hiccups) and thanks!
[15:46] <anpok> fritsch: we too for the same purpose
[15:48] <fritsch> but we try very hard to get last release buggers ironed out to release v17 in time
[15:48] <fritsch> wanted to do ReRo, but failed :-)
[15:50] <bschaefer> yeah we had this happen with mir 0.25 (im trying to release that now) but we should have released it a bit ago haha
[15:50] <bschaefer> (always one more blocker/bug you would to get fixed next)
[15:50] <bschaefer> would like to*
[15:51] <fritsch> there is a shirt for that:
[15:51] <fritsch> https://teespring.com/shop/99bugs?aid=marketplace&tsmac=marketplace&tsmic=category#pid=2&cid=2397&sid=front
[15:52] <bschaefer> haha
[16:06] <fritsch> bschaefer: something else concerning ffmpeg, if you run: depends/target/ffmpeg/autobuild.sh -d
[16:07] <fritsch> before hand
[16:07] <fritsch> it will download that ffmpeg tar
[16:07] <fritsch> and you can then build without internet
[16:07] <fritsch> with default options
[16:07] <bschaefer> fritsch, the issue is our build system (iirc) firewalls it for w/e reason? Blocking the download
[16:07] <bschaefer> as thats what its currently trying to do
[16:07] <bschaefer> but fails to download it
[16:08] <fritsch> how do you get kodi.git on tht machine?
[16:08] <fritsch> on the build machine
[16:08] <fritsch> cause if you scp the kodi folder, just scp it after that above command
[16:09] <bschaefer> fritsch, they allow git clone specifically for snapcraft
[16:09] <fritsch> ah okay
[16:09] <bschaefer> so i can git it but it wgets the tar ball
[16:09] <bschaefer> which it fails
[16:09] <bschaefer> (ive also tried the manual grab ffmpeg from git hub as well to build
[16:09] <bschaefer> )
[16:09] <bschaefer> which ill try again but with the arguments you have!
[16:09] <bschaefer> as i added nothing
[16:20] <fritsch> if you want to download everything, that might come during build, you can do that before creating the source package
[16:20] <fritsch> http://paste.ubuntu.com/23456771/
[16:22] <bschaefer> fritsch, for the current build system it pulls directly form the github branch i have up
[16:23] <bschaefer> (which i dont wan to commit anything there :)
[16:23] <fritsch> oki
[16:24] <bschaefer> but i could fork something for it
[16:24] <bschaefer> for now
[16:24] <bschaefer> fritsch, im hoping when i manually grab ffmpeg from github and build it with those args it works, we shall see!
[16:24] <fritsch> jep it works, at least on your local machine
[16:25] <bschaefer> is this the wrong branch? https://github.com/FFmpeg/FFmpeg
[16:25] <bschaefer> as thats something i can pull in for the snap
[16:25] <fritsch> that's ffmpeg's master branch
[16:25] <fritsch> latest and greatest
[16:25] <fritsch> at the moment it should work
[16:25] <fritsch> but we are internally still on 3.1.5
[16:26] <fritsch> though 3.2 is ready and will be upgraded the moment we have branched v17
[16:26] <fritsch> remember your local ubuntu most likely ships 2.8
[16:26] <fritsch> if you are happy
[16:26] <bschaefer> i was building on xenial soo idk how old that was but it was failing
[16:26]  * bschaefer will attempt again from trunk
[16:27] <bschaefer> thanks!
[16:40] <Pharaoh_Atem> anyone have any idea what's going on here? https://paste.fedoraproject.org/477293/78868414/
[16:52] <alan_g> Pharaoh_Atem: probably some failed interaction with drivers. Currently we have Ubuntu on "metal" and qemu-kvm working. This is something else?
[16:52] <Pharaoh_Atem> VMware Fusion
[16:54] <alan_g> We're working on it, but there are known bugs: https://bugs.launchpad.net/mir/+bugs?field.tag=vm
[17:20] <anpok> I thought vmware would work
[17:23] <alan_g> anpok: it will
[18:22] <ogra_> bschaefer, hmm, so i cheated my way around the ffmpeg bits ... but ...
[18:22] <ogra_> /build/kodi-pi/parts/kodi/build/xbmc/windowing/mir/WinSystemMirGLESContext.h:7:43: fatal error: rendering/gl/RenderSystemGLES.h: No such file or directory
[18:22] <ogra_> https://launchpadlibrarian.net/292945257/buildlog_snap_ubuntu_xenial_armhf_kodi-pi_BUILDING.txt.gz
[18:22] <bschaefer> huh
[18:22] <ogra_> any idea where that header should come from ?
[18:22] <bschaefer> ooo dang
[18:22] <bschaefer> yeah im stupid
[18:22] <bschaefer> ogra_, rendering/gles/RenderSystemGLES.h
[18:22]  * bschaefer fixes upstream
[18:22] <bschaefer> my bad
[18:23] <ogra_> ah
[18:23]  * bschaefer pushed that last night but didnt compile that change
[18:24] <bschaefer> ogra_, pushed change
[18:24] <bschaefer> thanks for catching that!
[18:24] <ogra_> thx
[18:24]  * bschaefer compiles it here just to be sure
[18:51] <bschaefer> ogra_, more compiling issues :) I really should have checked after removing more things
[18:51] <bschaefer> ill let you know when i fix them (again my issue :)
[18:51] <ogra_> no hurry
[18:52]  * ogra_ is really only doing that for fun atm ... dont feel pushed
[18:52] <bschaefer> is raspi3 arm64?
[18:52] <ogra_> nope
[18:52] <ogra_> armhf
[18:52] <bschaefer> ogra_, o well its actually really nice since im fixing issues for this PR :)
[18:52] <bschaefer> soo its good
[18:52] <bschaefer> ogra_, dang was hoping once you got a snap made i could use it for dragon board :)
[18:52] <ogra_> (there is an arm64 image in the works though ... but not done yet)
[18:53] <ogra_> well, i'm building on LP ... if armhf builds it shouldnt be any prob to enable arm64 too
[18:53] <bschaefer> ogra_, o very true
[18:53] <bschaefer> ogra_, yeah once i figure out how to disable crystal-hd + (if you fixed that ffmpeg issue)
[18:54] <bschaefer> then we can get one branch for amd64/armhf/64
[18:54] <ogra_> well, i cheated badly :)
[18:54] <bschaefer> :)
[18:54] <ogra_> i git cloned your treee inot the snapcraft bzr tree ... changed snapcraft.yaml to "source: ./xbmc" and copied the ffmpeg tarbal in the right place
[18:55] <ogra_> a quick and dirty "fix" :)
[18:55] <bschaefer> :)
[18:55] <bschaefer> yeah thats kind of what i did before
[18:56] <bschaefer> but i didnt want to push the entire xbmc up to launchpad but i should have for a launchpad snap
[18:56] <ogra_> well, you could include the tarball in your github tree otherwise
[18:57] <ogra_> if the code finds it in the right place it wint wget it ...
[18:57] <ogra_> *wont
[18:57]  * bschaefer just has to figure out why it wants to do the Windowing EGL vs just mir
[18:57] <bschaefer> ogra_, right but i cant do that since my github is in a PR and i dont want to include that in the PR
[18:57] <bschaefer> my plan was to fork it if i couldnt get something working though
[18:57] <ogra_> uh,  yeah
[18:57] <bschaefer> so i could have a copy of kodi with that tarball in it
[18:58] <bschaefer> (super backup case :)
[18:58] <ogra_> well, cjwatson told me there is a fix for the wget issue in LP ... just not landed yet
[18:58] <ogra_> so the hacks are all just interim anyway
[18:58] <ogra_> https://code.launchpad.net/~cjwatson/launchpad-buildd/snap-proxy-allow-build/+merge/310050
[18:58] <ogra_> there
[18:58] <bschaefer> o sweet
[18:58] <bschaefer> yeah i should have poked someone about that
[19:11] <bschaefer> hmm not sure if i can use opengles with out the egl windowing system wanting to be ticked on
[19:11]  * bschaefer is not so great at cmake/autotools haha
[19:12] <bschaefer> as i really dont want to create an empty EGL Mir type
[19:14] <kdub> no one's great at autotools
[19:15] <bschaefer> haha
[19:32]  * bschaefer may have fixed both autotools and cmake ...
[19:58] <bschaefer> ogra_, fixed, and pushed
[20:54]  * bschaefer testing out a new snap setup ... hopefully it'll work