+- Kodi Community Forum (https://forum.kodi.tv)
+-- Forum: Support (https://forum.kodi.tv/forumdisplay.php?fid=33)
+--- Forum: General Support (https://forum.kodi.tv/forumdisplay.php?fid=111)
+---- Forum: Linux (https://forum.kodi.tv/forumdisplay.php?fid=52)
+---- Thread: Gotham on Debian? (/showthread.php?tid=177474)
RE: Gotham on Debian? - tesona1977 - 2014-03-14
could be that easy...
http://jenkins-debian-glue.org
includes...packaging, versioning and repository handling. these are the same scripts postgres sql use for their official debian packages. look at the faq on the webpage for details.
its very easy to integrate this into your current jenkins environment.
RE: Gotham on Debian? - GBB1 - 2014-03-14
Man this would be awesome! If it could be directly connected to the current XBMC built system, there's really no manual labor to do at all once it's setup. Please could someone configure this? That would be fully A!
I'll switch back to Debian in a heartbeat if XBMC supports the packages.
RE: Gotham on Debian? - tesona1977 - 2014-03-14
(2014-03-12, 10:11)wsnipex Wrote: the packaging is the easy part and long done. Its about the infrastructure needed for the debian repo. All this has to work automatically, unless somebody is willing to regularly do it manually.
Most of it is already working and I even did a pov repo for wheezy here: http://mirrors.xbmc.org/test-builds/apt/debian/stable/
The xbmc build there rather old though.
This just needs more work that I currently don't have time for. And tbh its not high prio for me.
edit: in the meantime users are encouraged to use the mk-debian-package.sh script.
can you please explain the problem a little bit more
jenkins-debian-glue handles repositories (freight and/or reprepro) by default. you can run it on a jenkins slave for example and afterwards rsync or scp the repo to your external mirrors for example. i dont know your infrastructure details...but i think you can handle that with some effort
RE: Gotham on Debian? - EricV - 2014-03-15
(2014-03-08, 08:18)FernetMenta Wrote: your best option is to leave it. you pretend to distribute working software but actually you don't. you insist on your policies but ignore ours. XBMC is not developed to run with libav.
you rather deliver crap instead of looking for better solutions. I only can recommend every user interested in XBMC to stay far away from Debian.
You blame a linux distribution because its policy is in contradiction with XBMC policy. Debian could blame xbmc policy as well. I think it is sane to avoid duplicating code because it avoid having to fix the same bugs zillion times (especially security ones). The rela fix is to get ffmpeg back into debian first and this has nothing to do with XBMC but rather to individuals. Then it will be XBMC's team job to either make needed fixes to get into upstream ffmpeg, or make sure that they are in the patch set used by debian.
RE: Gotham on Debian? - fritsch - 2014-03-15
:-) ... hahaha - nothing learned from last time ...
@EricV: Come on, you are smarter than that.
RE: Gotham on Debian? - giaur - 2014-03-15
Oh yes, indeed, xbmc doesn't want to accept any policy, it has its own policy and it forked ffmpeg instead of submit useful changes to ffmpeg devs, it's not nice
Quote:Debian could blame xbmc policy as well. I think it is sane to avoid duplicating code because it avoid having to fix the same bugs zillion times (especially security ones). The rela fix is to get ffmpeg back into debian first and this has nothing to do with XBMC but rather to individuals. Then it will be XBMC's team job to either make needed fixes to get into upstream ffmpeg, or make sure that they are in the patch set used by debian.This point of view seems to be right, really. But as end user I just want to have working packages, I don't care how it's done.
RE: Gotham on Debian? - FernetMenta - 2014-03-16
Quote:Oh yes, indeed, xbmc doesn't want to accept any policy, it has its own policy and it forked ffmpeg instead of submit useful changes to ffmpeg devs, it's not nice
This is not true. We have not accepted any ffmpeg patches not accepted upstream for more than a year. Instead we do work with the ffmpeg devs and fix bugs upstream first. Nevertheless XBMC has a different release cycle than ffmpeg it it is necessary to backport patches. We have just backported fixes which are i ffmpeg master but won't be in upcoming release 2.2.
Quote:Then it will be XBMC's team job to either make needed fixes to get into upstream ffmpeg
Further, anybody not happy with the speed we submit those old sins upstream, you know where those patches are. Feel free to pick one and send upstream instead of telling us what our job is.
Regarding policies:
Can the fat man complain about the suit being too small? I would say no, go look for something else to wear. I agree that it would be nice if everything fit together but this is currently not the case. I don't blame debian for their policy, I blame debian for breaking the value chain by making something worse. This I consider a no-go.
RE: Gotham on Debian? - negge - 2014-03-16
(2014-03-08, 12:11)FernetMenta Wrote: Maybe you can blame me for being a bit harsh but I don't get tired to point out that I dislike what he does. Debian treats thousands of users with disrespect in providing those packages knowing they don't work properly.
Even an experienced XBMC user like giaur is irritated.The average user has no clue that Debian offers faulty software. If you can't do it properly (because of this silly policies), just don't do it at all.
It seems everyone is missing the simplest and most effective solution here - remove the --external-ffmpeg switch completely. Having it there is like having a false road sign and then complaining when people complain they got lost. Just remove the sign and it'll all be fine.
RE: Gotham on Debian? - wsnipex - 2014-03-16
removing the switch does not help anything, as it will just be patched in again. You cannot control this in FOSS.
RE: Gotham on Debian? - nickr - 2014-03-16
It seems to me that the problem is the constant instability and change in ffmpeg.
ffmpeg moves fast and things often change.
Multiple linux distros, multiple windows versions, multiple OSX versions, multiple android versions - they all package things slightly different and with different versions of ffmpeg. Some distros won't enable patent encumbered options when packaging ffmpeg, but those options are needed in xbmc.
So it is not surprising XBMC uses it's own internal ffmpeg. That is the only way to get consistency of result. Yes it might be a pain for linux distros that don't allow packaging with internal versions (eg debian and (I think) gentoo) - but neither of those are distros I'd choose to use for a media box anyway.
RE: Gotham on Debian? - fritsch - 2014-03-16
No it's not.
ffmpeg is pretty stable, be it upstream or be it when maintaining old stable branches. I think you are not aware of the "ffmpeg to libav" split and so on ...
RE: Gotham on Debian? - negge - 2014-03-16
(2014-03-16, 21:38)wsnipex Wrote: removing the switch does not help anything, as it will just be patched in again. You cannot control this in FOSS.
You can't know that, it could be that the fact that there's an option to use an external library is why people do it. If you take away the option, no one will bother cause it's too much work.
Removing the option would also send a stronger signal that "we don't want you doing that".
RE: Gotham on Debian? - un1versal - 2014-03-16
The option to use external ffmeg was removed from xbmc source now for quite some time, so ya, not wanted to do be done and now officially completely discouraged from doing it.
RE: Gotham on Debian? - giaur - 2014-03-17
I was unable to build debian packages. It asked for some missing dependencies, libs that are not present in repository. I didn't go deeper but when compiling via make I don't have any problems. Probably package build forces some options to configure, however I have no idea how to satisfy some dependencies on sid to build debs sucessfully.
RE: Gotham on Debian? - un1versal - 2014-03-17
You still need to look at readmes and have some dependencies installed, saying you cant because of missing dependencies is vague and not helpful.