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