| RAOF | It's pretty consistent as long as you're familiar enough with the consistency. | 00:00 |
|---|---|---|
| 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:01 |
| 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:03 |
| 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:46 |
| 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:48 |
| 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:49 |
| 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:50 |
| 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:51 |
| === JanC_ is now known as JanC | ||
| 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:52 |
| 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:53 |
| 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:54 |
| 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:55 | |
| 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:56 |
| 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:57 |
| * 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:58 |
| 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) | 00:59 |
| 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:00 |
| ali1234 | well, thanks for your time and thoughts | 01:01 |
| 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:02 | |
| * bschaefer eods | 01:06 | |
| 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:37 |
| duflu | (other than my code change which just means in Mir 0.25 you'll see less logging about "Unknown" output types) | 01:39 |
| RAOF | That's right! That's what I was thinking of. | 01:46 |
| 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>." | 03:09 |
| === chihchun_afk is now known as chihchun | ||
| fritsch | !seen bschaefer | 09:43 |
| ubot5` | I have no seen command | 09:43 |
| alan_g | fritsch: he's likely asleep (on east coast time) | 09:46 |
| 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:13 |
| alan_g | fritsch: that's likely better asked during USA day (not my area of expertise). alf_ ^ any thoughts? | 10:15 |
| alan_g | duflu: ^ | 10:16 |
| 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:17 |
| 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:18 |
| 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:19 |
| 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:20 |
| 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:21 |
| 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:22 |
| 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 | 10:26 |
| === 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 | ||
| Son_Goku | are the mir demo clients supposed to segfault with vmware gfx driver? | 14:29 |
| alan_g | they're not supposed to, but it's a known problem | 14:30 |
| === dandrader is now known as dandrader|afk | ||
| 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:32 |
| Son_Goku | it might not be the same issue | 14:34 |
| * Son_Goku is installing debuginfo packages now | 14:34 | |
| Son_Goku | alan_g: https://paste.fedoraproject.org/477293/78868414 | 14:38 |
| === JanC is now known as Guest87424 | ||
| === JanC_ is now known as JanC | ||
| === chihchun is now known as chihchun_afk | ||
| ogra_ | bschaefer, yo ... i just looked at your kodi snap ... try: --with-ffmpeg=force ... that will build it in-tree | 15:19 |
| 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:20 |
| * ogra_ is trying to get it to build on pi3 currently | 15:21 | |
| 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:22 |
| 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:23 |
| 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_ | INSTALLlibavutil/ffversion.h | 15:24 |
| ogra_ | INSTALLlibavutil/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:24 |
| 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 |
| === dandrader|afk is now known as dandrader | ||
| 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:25 |
| 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:26 |
| 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:27 |
| 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:28 |
| 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:29 |
| 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:30 |
| 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:31 |
| 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:32 |
| 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:33 |
| 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:34 |
| 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:35 |
| 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:36 |
| 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:37 |
| 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:38 |
| === zsombi_ is now known as zsombi | ||
| anpok | pixel format types probably | 15:39 |
| bschaefer | anpok, it was /me attempts to remember... taking an eglimage thats decoded and shoving it into a mir surface | 15:40 |
| 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:41 |
| 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:42 |
| 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:43 |
| 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:44 |
| 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:45 |
| 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:46 |
| 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:48 |
| 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:50 |
| 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:51 |
| bschaefer | haha | 15:52 |
| fritsch | bschaefer: something else concerning ffmpeg, if you run: depends/target/ffmpeg/autobuild.sh -d | 16:06 |
| 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:07 |
| 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:08 |
| 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:09 |
| 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:20 |
| === dandrader is now known as dandrader|afk | ||
| bschaefer | fritsch, for the current build system it pulls directly form the github branch i have up | 16:22 |
| bschaefer | (which i dont wan to commit anything there :) | 16:23 |
| fritsch | oki | 16:23 |
| 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:24 |
| 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:25 |
| 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:26 | |
| bschaefer | thanks! | 16:27 |
| Pharaoh_Atem | anyone have any idea what's going on here? https://paste.fedoraproject.org/477293/78868414/ | 16:40 |
| 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:52 |
| alan_g | We're working on it, but there are known bugs: https://bugs.launchpad.net/mir/+bugs?field.tag=vm | 16:54 |
| === dandrader|afk is now known as dandrader | ||
| anpok | I thought vmware would work | 17:20 |
| alan_g | anpok: it will | 17:23 |
| 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:22 |
| ogra_ | ah | 18:23 |
| * bschaefer pushed that last night but didnt compile that change | 18:23 | |
| 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:24 | |
| 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:51 |
| * 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:52 |
| 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:53 |
| 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:54 |
| ogra_ | a quick and dirty "fix" :) | 18:55 |
| bschaefer | :) | 18:55 |
| bschaefer | yeah thats kind of what i did before | 18:55 |
| 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:56 |
| 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:57 |
| 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 | 18:58 |
| === dandrader is now known as dandrader|afk | ||
| 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:11 | |
| bschaefer | as i really dont want to create an empty EGL Mir type | 19:12 |
| kdub | no one's great at autotools | 19:14 |
| bschaefer | haha | 19:15 |
| * bschaefer may have fixed both autotools and cmake ... | 19:32 | |
| bschaefer | ogra_, fixed, and pushed | 19:58 |
| * bschaefer testing out a new snap setup ... hopefully it'll work | 20:54 | |
| === dandrader|afk is now known as dandrader | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!