On Jun 25, 2015, at 11:15 AM, Matteo <mbrancaleoni@voismart.it> wrote:

Hi,

----- Il 25-giu-15, alle 17:00, Michael Jerris mike@jerris.com ha scritto:

...

Please do not publish private repos. We should work this in to the system we have for our official rpm repos. the first steps would be to coordinate with us and do any pull requests needed on the dependencies in the SD project in stash and work with us on getting a cent6 repo

sure no problem with it.

Right now I have a list with all needed specs and sources.

Basically same dir struct as in various build server, which holds specs, sources, patches and additional files.

I've looked into SD repo, and to be 100% honest I don't like having "external" sources in it, with custom mods into sources itself (read: debian/redhat dirs, helpers script).

The correct approach, imho, is how distro builds works:

* create a ftp/http server with vanilla sources, which works as "cache". Having the vanilla tgz untouched into the SD repo is acceptable, if simplifies things.

We generate these tarballs already from bamboo jobs, and post them at http://files.freeswitch.org/downloads/libs. So this already exists.

* the SD repo should have a dir for each dep, which contains only spec file and additional files like patches against vanilla and additional files if any

Then an external builder (bamboo) should checkout SD, downloads sources from the "cache" server and builds the packages. Mock will be used for redhat like.

We are using mock already. we use commit triggers on the individual repos to trigger the jobs. We don't plan on changing it like you describe.

So, let me know If I can help, I've almost finished everything. I can provide specs, and all needed stuff to build.

We need these changes as pull requests to the repos that exist already on SD.

For CentOS 6 there're a lot of packages to add, and some needs to be updated, but nothing that "hurts" the core packages.

I never used bamboo (using koji rightnow for this stuff), but I think it will be easy to install.

We don't need you to do the actual bamboo jobs, we can take care of that for the ones that are missing. First step wold be to get pull requests in to modify the spec and any other code changes that are necessary, then coordinate with Ken Rice on the mock command. Our current command in bamoboo looks something like this: ls -al mkdir -p {RPMS,el6-x86_64,el6-i386,el7-x86_64} #mock -v -r /etc/mock/epel-6-x86_64.cfg --resultdir=./el6-x86_64 rebuild SRPMS/freeswitch-1.*.el7.centos.src.rpm || exit 1 #mock -v -r /etc/mock/epel-6-i386.cfg --resultdir=./el6-i386 rebuild SRPMS/freeswitch-1.*-1.el7.centos.src.rpm || exit 1 mock -v -r /etc/mock/freeswitch-epel-7-x86_64.cfg --resultdir=./el7-x86_64 rebuild SRPMS/freeswitch-1.7.0.${bamboo.buildNumber}-1.el7.centos.src.rpm || exit 1 You can let us know via the pull requests when its good to enable additional mock commands and if there is any tweaking to the mock commands.

What do you think?

Regards, Matteo

PS @Ken : already submitted several pull requests for other tickets, so I know the standard FS flow for adding patches. Just wanting to discuss which is the better way to share the work I've done for my internal use. Obviously if someone is interested in :)

We don't plan on changing the approach we are doing to packaging, but i understand your points, its just not practical for us to do it that way and not have to redo a ton of work for each distro when the packages require patches to work properly. We are working to get our patches upstreamed to the package maintainers where appropriate. On many of these packages (all of the codec libs for example) we are actually the upstream maintainer.

_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com

Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com

FreeSWITCH-dev mailing list FreeSWITCH-dev@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev http://www.freeswitch.org

You know in the spec files you can if things for specific versions... You'll just have to figure out the correct Ifs for Cent7 vs Cent6 vs say Suse On 6/25/15, 11:03 AM, "Matteo" <mbrancaleoni@voismart.it> wrote:

Ok,

since some packages are only centos 6 specific updates, how do you plan to handle them?

For example, nasm is a required update to CentOS 6 in order to build other stuff, but is not needed for debian or CentOS 7

Right now in the repo I don't see anything distro-specific .

Regards, Matteo

_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com

Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com

FreeSWITCH-dev mailing list FreeSWITCH-dev@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev http://www.freeswitch.org

-- Ken http://www.FreeSWITCH.org http://www.ClueCon.com http://www.OSTAG.org irc.freenode.net #freeswitch Twitter: @FreeSWITCH

for things like nasm, is that newer version out there for example in epel? that would be the best case. Backup would be to take a source pacakge from something newer and just rebuild in a way that doesn't require any modifications, fallback we can put the src out on our download servers and create a job for it. As for x264, we will not be putting that in our repo, you'll have to find some way to get that into some official repo that we can reference, maybe see if you can get it into epel? The best case would be to get as much as possible directly into epel so it leaves us having to manage as little as possible. On Thursday, June 25, 2015, Matteo <mbrancaleoni@voismart.it> wrote:

I know how specs works, I'm maintaining a private repo like epel with tens of packages since years, using the same tools used by fedora ( koji, mock, mash).

My intent is not to create a custom build of freeswitch, but a repo like epel or rpmfusion with only the needed build deps.

What is not clear to me is the flow to add a new dep.

Let's say I need to add a bunch of new libs, like gpac, nasm, x264, to name a few.

Which is the correct approach to fit into Fs build structure?

Mat

Inviato da iPhone

...

Il giorno 25/giu/2015, alle ore 18:08, Ken Rice ha scritto:

You know in the spec files you can if things for specific versions... You'll just have to figure out the correct Ifs for Cent7 vs Cent6 vs say Suse

...

On 6/25/15, 11:03 AM, "Matteo" wrote:

Ok,

since some packages are only centos 6 specific updates, how do you plan to handle them?

For example, nasm is a required update to CentOS 6 in order to build other stuff, but is not needed for debian or CentOS 7

Right now in the repo I don't see anything distro-specific .

Regards, Matteo

---

...

...

Professional FreeSWITCH Consulting Services: consulting@freeswitch.org <javascript:_e(%7B%7D,'cvml','consulting@freeswitch.org');> http://www.freeswitchsolutions.com

Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com

FreeSWITCH-dev mailing list FreeSWITCH-dev@lists.freeswitch.org <javascript:_e(%7B%7D,'cvml','FreeSWITCH-dev@lists.freeswitch.org');> http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev http://www.freeswitch.org

-- Ken http://www.FreeSWITCH.org http://www.ClueCon.com http://www.OSTAG.org irc.freenode.net #freeswitch Twitter: @FreeSWITCH

_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org <javascript:_e(%7B%7D,'cvml','consulting@freeswitch.org');> http://www.freeswitchsolutions.com

Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com

FreeSWITCH-dev mailing list FreeSWITCH-dev@lists.freeswitch.org <javascript:_e(%7B%7D,'cvml','FreeSWITCH-dev@lists.freeswitch.org');> http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev http://www.freeswitch.org

I have no issues rebuilding some packages for never version in our repos... The big issues are, we will not put binaries of any of the mp3 or h264 code in our repos, and we are not going to include documentation pointing to non-reputable 3rd party repos. I'm open to pointing to rpmforge if we can put together some documentation that won't result in complete nightmares from version conflicts from all the different repos, but I'm not sure this is possible, can we craft a meta package that helps nail down the specific versions to use, or to somehow blacklist all but a small list of packages from rpmforge? In regards to VLC, to be honest, I'd skip it completely, it adds little value and doesn't work great. The one you want to get working is libav or ffmpeg built against x264. The trick is you'll need to audit the versions of all these things you are talking about updating and figuring out if the upgrades are even actually necessary Please note that libav will need to be rebuilt for sure so its built against our version of libvpx, and if not already done, some other libs will need to be rebuilt against libpng 1.6 or greater. Those 2 libraries for sure need to be updated to our versions. Additionally some of the libs in our tree may exist in other distros, but ours are actually different api/abi but have the same name, and the ones in the distros are broken. For example libilbc. I have not yet audited to see if ours has enough backwards api that it could be updated in distro repos to replace their broken one. Most of the version limits that are in place are those versions based on thats what we have in debian jessie that is tested and confirmed working. Its likely you can use older versions, but functionality will need to be tested to confirm on a library by library basis. Hi, ----- Il 25-giu-15, alle 19:45, Michael Jerris mike at jerris.com <http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev> ha scritto:

for things like nasm, is that newer version out there for example in epel? that would be the best case.

Sure, the work I've done is already based on epel, so what is in epel is not built again. I've rebuilt some epel packages only when a newer version is needed.

Backup would be to take a source pacakge from something newer and just rebuild in a way that doesn't require any modifications, fallback we can put the src out on our download servers and create a job for it. As for x264, we will not be putting that in our repo, you'll have to find some way to get that into some official repo that we can reference, maybe see if you can get it into epel? The best case would be to get as much as possible directly into epel so it leaves us having to manage as little as possible.

The main "source" of deps (and troubles) is vlc 2.2, which needs a lot of stuff. I've taken some packages from rpmfusion and rebuilt them, updating when needed. So while epel is needed for deps, rpmfusion is not because all needed rpmfusion packages have been rebuilt by me using same sources/specs (if not updated) I don't know if epel will ever accept all packages, because some are also updates to base system, like opencv which is present on CentOS base but too old and ImageMagick, to name few. So the picture is: if you want to have video under CentOS 6 without hosting something (mainly vlc stuff and it's deps), you're out of luck since FS requirements are on very recent packages. Just a quick list of stuff needed: base CentOS updates not present anywhere: ImageMagick (updated), nasm(updated), libvncserver(updated), opencv(updated) ** from rpmfusion: a52dec, faad2, gpac, lame, vlc(updated), libmad, mpg123(updated), x264(updated for vlc 2.2), xvidcore ** from epel (rebuilt because different version) libmpv2(updated), libshout(updated) ** from Freeswitch SD: g722_1, broadvoice, libav, libcodec2, libsilk, libvpx, libyuv(updated), opus, soundtouch, openh264, flite, ilbc (epel has a newer one, pay attention!) This is the list (should be almost complete, I'm not in the office right now) of what I've rebuit to have video running. Is possible to reduce by 6 packages if rpmfusion is added with repo. Dunno if is wanted or not. I think that epel will never accept updates to packages that are already into base distro. And don't know about vlc and its deps... if rpmfusion exists maybe is because patents does not allow it into epel? What do you think? Matteo

On Jun 25, 2015, at 1:45 PM, Michael Jerris <mike@jerris.com> wrote:

for things like nasm, is that newer version out there for example in epel? that would be the best case. Backup would be to take a source pacakge from something newer and just rebuild in a way that doesn't require any modifications, fallback we can put the src out on our download servers and create a job for it. As for x264, we will not be putting that in our repo, you'll have to find some way to get that into some official repo that we can reference, maybe see if you can get it into epel? The best case would be to get as much as possible directly into epel so it leaves us having to manage as little as possible.

On Thursday, June 25, 2015, Matteo <mbrancaleoni@voismart.it <mailto:mbrancaleoni@voismart.it>> wrote: I know how specs works, I'm maintaining a private repo like epel with tens of packages since years, using the same tools used by fedora ( koji, mock, mash).

My intent is not to create a custom build of freeswitch, but a repo like epel or rpmfusion with only the needed build deps.

What is not clear to me is the flow to add a new dep.

Let's say I need to add a bunch of new libs, like gpac, nasm, x264, to name a few.

Which is the correct approach to fit into Fs build structure?

Mat

Inviato da iPhone

...

Il giorno 25/giu/2015, alle ore 18:08, Ken Rice ha scritto:

You know in the spec files you can if things for specific versions... You'll just have to figure out the correct Ifs for Cent7 vs Cent6 vs say Suse

...

On 6/25/15, 11:03 AM, "Matteo" wrote:

Ok,

since some packages are only centos 6 specific updates, how do you plan to handle them?

For example, nasm is a required update to CentOS 6 in order to build other stuff, but is not needed for debian or CentOS 7

Right now in the repo I don't see anything distro-specific .

Regards, Matteo

_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org <javascript:_e(%7B%7D,'cvml','consulting@freeswitch.org');> http://www.freeswitchsolutions.com <http://www.freeswitchsolutions.com/>

Official FreeSWITCH Sites http://www.freeswitch.org <http://www.freeswitch.org/> http://wiki.freeswitch.org <http://wiki.freeswitch.org/> http://www.cluecon.com <http://www.cluecon.com/>

FreeSWITCH-dev mailing list FreeSWITCH-dev@lists.freeswitch.org <javascript:_e(%7B%7D,'cvml','FreeSWITCH-dev@lists.freeswitch.org');> http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev <http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev <http://lists.freeswitch.org/mailman/options/freeswitch-dev> http://www.freeswitch.org <http://www.freeswitch.org/>

-- Ken http://www.FreeSWITCH.org <http://www.freeswitch.org/> http://www.ClueCon.com <http://www.cluecon.com/> http://www.OSTAG.org <http://www.ostag.org/> irc.freenode.net <http://irc.freenode.net/> #freeswitch Twitter: @FreeSWITCH

_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org <javascript:_e(%7B%7D,'cvml','consulting@freeswitch.org');> http://www.freeswitchsolutions.com <http://www.freeswitchsolutions.com/>

Official FreeSWITCH Sites http://www.freeswitch.org <http://www.freeswitch.org/> http://wiki.freeswitch.org <http://wiki.freeswitch.org/> http://www.cluecon.com <http://www.cluecon.com/>

FreeSWITCH-dev mailing list FreeSWITCH-dev@lists.freeswitch.org <javascript:_e(%7B%7D,'cvml','FreeSWITCH-dev@lists.freeswitch.org');> http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev <http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev <http://lists.freeswitch.org/mailman/options/freeswitch-dev> http://www.freeswitch.org <http://www.freeswitch.org/>

On Jun 25, 2015, at 4:02 PM, Matteo <mbrancaleoni@voismart.it> wrote:

well, rpmforge is even older than rpmfusion.

Rpmfusion is well known, but if vlc is going to be dropped (will it?) we can skip it entirely and reduce the number of packages.

It's not getting dropped but it is of limited value, mod_av does nearly everything mod_vlc does, and does it better, the only thing it doesn't do is play youtube videos by youtube url. Seems a minor feature for a massive dependency chain. I'd say just don't bother trying to include it. In regards to mod_av, you only get the functionality people probably want (and same for vlc) if its built against x264, which again, we may have issues finding a package in a reputable repo.

Imagemagick is needed to be updated only for mod_imagick, otherwise is not needed.

mod_imagick supports playing pdf files like videos. Its useful but your call.

If we limit everything on what is on SD repo (and exclude vlc+mod_imagick) well I think (but must check) that epel is enough and only few stuff must be added (mpg123, lame?, libshout, libmpv2 and maybe nasm). But I need to recheck it since I tried to have everything fs 1.6 needs, with the correct versions.

Just to be completely 100% clear, we will not be serving up mp3 or h264 binaries from our repos.

there's one dep on freetype2 is FS which is not really needed, I'll file a pull rq for it, so we can avoid updating it. (you need 2.4.something but with 2.3.11 compiles and works ok)

We for sure need freetype to support a bunch of features that have to do with putting text on video, and it will require rebuilding it against libpng 1.6 for some basic functionality, while these are already optional, this will significantly impact some conference functionality.

About libpng: I've used the CentOS shipped one and seems to work ok (version 1.2.49) to me.

libpng1.6 is required for some transparency functionality that we use heavily. It will build with older versions, but functionality will be significantly diminished.

So, I think most of the work is around vlc: you say that does not work well, what will be it's destiny?

We are not getting rid of it, but my recommendation would be to not try to build it. I already spend significant time telling people to use mod_av instead.

If is just an experiment I can try to rebuild everything without it and check what is needed again in order to shrink that list (it will be a lot shorter) and report back.

I'm not sure about mod_imagick, not tested it yet.

Another question about mp3 code: what about mpg123/lame that is needed by FS?

These can't go into our repo, but any moderately recent one should be fine. I think the api is stable. The issue with using older versions would be if it will cause stability issues and crashing, as there has been a long list of buffer overflow issues in that code over the years.

If you're not willing to add it to your repo, how mp3 files are handled ? using libav ?

If there is no other place to get packages for that library, the module simply wouldn't be built, and that feature would not be available.

If yes, another dep can be removed.

matteo

----- Il 25-giu-15, alle 21:22, Michael Jerris mike@jerris.com ha scritto:

...

I have no issues rebuilding some packages for never version in our repos... The big issues are, we will not put binaries of any of the mp3 or h264 code in our repos, and we are not going to include documentation pointing to non-reputable 3rd party repos. I'm open to pointing to rpmforge if we can put together some documentation that won't result in complete nightmares from version conflicts from all the different repos, but I'm not sure this is possible, can we craft a meta package that helps nail down the specific versions to use, or to somehow blacklist all but a small list of packages from rpmforge? In regards to VLC, to be honest, I'd skip it completely, it adds little value and doesn't work great. The one you want to get working is libav or ffmpeg built against x264. The trick is you'll need to audit the versions of all these things you are talking about updating and figuring out if the upgrades are even actually necessary Please note that libav will need to be rebuilt for sure so its built against our version of libvpx, and if not already done, some other libs will need to be rebuilt against libpng 1.6 or greater. Those 2 libraries for sure need to be updated to our versions. Additionally some of the libs in our tree may exist in other distros, but ours are actually different api/abi but have the same name, and the ones in the distros are broken. For example libilbc. I have not yet audited to see if ours has enough backwards api that it could be updated in distro repos to replace their broken one. Most of the version limits that are in place are those versions based on thats what we have in debian jessie that is tested and confirmed working. Its likely you can use older versions, but functionality will need to be tested to confirm on a library by library basis.

Hi,

----- Il 25-giu-15, alle 19:45, Michael Jerris mike at jerris.com ha scritto:

...

for things like nasm, is that newer version out there for example in epel? that

...

would be the best case. Sure, the work I've done is already based on epel, so what is in epel is not built again.

I've rebuilt some epel packages only when a newer version is needed.

...

Backup would be to take a source pacakge from something > newer and just rebuild in a way that doesn't require any modifications, > fallback we can put the src out on our download servers and create a job for > it. As for x264, we will not be putting that in our repo, you'll have to find > some way to get that into some official repo that we can reference, maybe see > if you can get it into epel? The best case would be to get as much as possible > directly into epel so it leaves us having to manage as little as possible. The main "source" of deps (and troubles) is vlc 2.2, which needs a lot of stuff.

I've taken some packages from rpmfusion and rebuilt them, updating when needed.

So while epel is needed for deps, rpmfusion is not because all needed rpmfusion packages have been rebuilt by me using same sources/specs (if not updated)

I don't know if epel will ever accept all packages, because some are also updates to base system, like opencv which is present on CentOS base but too old and ImageMagick, to name few.

So the picture is: if you want to have video under CentOS 6 without hosting something (mainly vlc stuff and it's deps), you're out of luck since FS requirements are on very recent packages.

Just a quick list of stuff needed:

base CentOS updates not present anywhere: ImageMagick (updated), nasm(updated), libvncserver(updated), opencv(updated)

** from rpmfusion: a52dec, faad2, gpac, lame, vlc(updated), libmad, mpg123(updated), x264(updated for vlc 2.2), xvidcore

** from epel (rebuilt because different version) libmpv2(updated), libshout(updated)

** from Freeswitch SD: g722_1, broadvoice, libav, libcodec2, libsilk, libvpx, libyuv(updated), opus, soundtouch, openh264, flite, ilbc (epel has a newer one, pay attention!)

This is the list (should be almost complete, I'm not in the office right now) of what I've rebuit to have video running.

Is possible to reduce by 6 packages if rpmfusion is added with repo. Dunno if is wanted or not.

I think that epel will never accept updates to packages that are already into base distro.

And don't know about vlc and its deps... if rpmfusion exists maybe is because patents does not allow it into epel?

What do you think?

Matteo

On Jun 25, 2015, at 1:45 PM, Michael Jerris < mike@jerris.com > wrote:

for things like nasm, is that newer version out there for example in epel? that would be the best case. Backup would be to take a source pacakge from something newer and just rebuild in a way that doesn't require any modifications, fallback we can put the src out on our download servers and create a job for it. As for x264, we will not be putting that in our repo, you'll have to find some way to get that into some official repo that we can reference, maybe see if you can get it into epel? The best case would be to get as much as possible directly into epel so it leaves us having to manage as little as possible.

On Thursday, June 25, 2015, Matteo < mbrancaleoni@voismart.it > wrote:

I know how specs works, I'm maintaining a private repo like epel with tens of packages since years, using the same tools used by fedora ( koji, mock, mash).

My intent is not to create a custom build of freeswitch, but a repo like epel or rpmfusion with only the needed build deps.

What is not clear to me is the flow to add a new dep.

Let's say I need to add a bunch of new libs, like gpac, nasm, x264, to name a few.

Which is the correct approach to fit into Fs build structure?

Mat

Inviato da iPhone

...

Il giorno 25/giu/2015, alle ore 18:08, Ken Rice ha scritto:

You know in the spec files you can if things for specific versions... You'll just have to figure out the correct Ifs for Cent7 vs Cent6 vs say Suse

...

On 6/25/15, 11:03 AM, "Matteo" wrote:

Ok,

since some packages are only centos 6 specific updates, how do you plan to handle them?

For example, nasm is a required update to CentOS 6 in order to build other stuff, but is not needed for debian or CentOS 7

Right now in the repo I don't see anything distro-specific .

Regards, Matteo

_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com

Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com

FreeSWITCH-dev mailing list FreeSWITCH-dev@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev UNSUBSCRIBE: http://lists.freeswitch.org/mailman/options/freeswitch-dev http://www.freeswitch.org

-- Ken http://www.FreeSWITCH.org http://www.ClueCon.com http://www.OSTAG.org irc.freenode.net #freeswitch Twitter: @FreeSWITCH

_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com

Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com

FreeSWITCH-dev mailing list FreeSWITCH-dev@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev UNSUBSCRIBE: http://lists.freeswitch.org/mailman/options/freeswitch-dev http://www.freeswitch.org

_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com

Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com

FreeSWITCH-dev mailing list FreeSWITCH-dev@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev http://www.freeswitch.org

_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com

Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com

FreeSWITCH-dev mailing list FreeSWITCH-dev@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev http://www.freeswitch.org

On Jun 25, 2015, at 5:38 PM, Matteo <mbrancaleoni@voismart.it> wrote:

Uhm,

while I get more informations, I get more confused :) Or, at least, seems to be that is not possible to have a 100% working install on CentOS 6.

This is likely.

Both rpmforge and rpmfusion has mpg123 and lame, so mp3 functions can be kept. Dropping mp3 support is just not feasible imho, since is a heavily used format.

I agree we shouldn't drop it, just need to figure out how to handle it. My concerns about these non-centos/epel repos is package version conflicts with other packages, and how much chrun/version conflict issues we might have. We need a good way to address those issues, I'm not sure what that is.

If rpmfusion is not very trusted (nothing for el7 yet) there's handbrake repo which is heavily focused on video ( http://negativo17.org/repos/HandBrake/ ) and has (updated) x264 stuff. x264 stuff on rpmforge is just too old.

I'm open to this. I'd like to hear others opinions if we could consider this repo trusted, and if we think its going to be stable and not break randomly on us.

( handbrake is a really powerful video transcoder, so for me can be trusted :) )

Combining both we may have a full mp3/h264 support. What do you think?

I think thats the right goal.

libpng 1.6 and freetype2 compiled against it is a different story. Even CentOS 7 does not have libpng 1.6. And since is a quite "basic" lib I think is not sane to try to update it.

Take a look how we did this in SD. We built it as an alternate package name so it can be installed along side the system version. That leaves us only having to update packages we are linking to in freewitch process to build against this. We have very similar issues with vpx in cent7 as well.

How do you handle them in jessie ? With two separate packages that do not overlap with system one and pointing FS build to it? (I see that also jessie has libpng12 and freetype linked against it)

we build a libpng16 or something similar package name, but the headers and libs in subdirs of where they would typically be, update the pc file references to point to these locations, andrename the .pc file (take a peek in configure.ac and you will se a number of libraries where we search for one of several package config file names in order) This has required some minor patches to libs that need to be rebuilt against our "special" versions to use those, libav in SD has an example of that, i think that particular trick uses a combination of a packaging system patch, and a configure arg to work right, but all are slightly different. You can check commit history on those repos to see what we did exactly for cent7 for the best guidance.

So, to sum up, right now I see this:

* include 2 new repos: rpmforge and handbrake for mp3+h264 . The question is if both are trusted enough. Of course testing is needed.

This is indeed the main question, plus stability and version conflicts between them. Of course also we will have to use our own repo as well

* try to build a separate freetype2+libpng16 and out that into SD repo for CentOS

* regarding mod_imagick, I'm still testing the situation, while I've already updated ImageMagick for fax conversion purposes since months without issues in production, I need to check it better with the new Fs module.

we technically only need the imagick core lib stuff, its possible to not touch the system imagick and still have it work, but not sure if there is value or not or other conflict issues. Also not sure of the exact version requirements, you'll have to look at api usage and bug/release notes and testing to confirm this for sure.

What do you think?

sounds like we are on the right track. also sounds like some of this may be a good path for resolving the x264 and mp3 issues for cent7 as well. The good sign on handbreak repo is it appears to track epel repos, so likely won't have any version conflicts. I'm a bit more concerned with rpmforge, but not sure if there is a better solution out there... will need to be very careful where there are conflicts between rpmforge and epel and have a full audit of potential problems this may cause.

regards, Matteo

PS: just for curiosity, why you do not want to host mp3 and h264 code? You already host openh264, is not the same issue?

----- Il 25-giu-15, alle 22:23, Michael Jerris mike@jerris.com ha scritto:

...

...

On Jun 25, 2015, at 4:02 PM, Matteo <mbrancaleoni@voismart.it> wrote:

well, rpmforge is even older than rpmfusion.

Rpmfusion is well known, but if vlc is going to be dropped (will it?) we can skip it entirely and reduce the number of packages.

It's not getting dropped but it is of limited value, mod_av does nearly everything mod_vlc does, and does it better, the only thing it doesn't do is play youtube videos by youtube url. Seems a minor feature for a massive dependency chain. I'd say just don't bother trying to include it. In regards to mod_av, you only get the functionality people probably want (and same for vlc) if its built against x264, which again, we may have issues finding a package in a reputable repo.

...

Imagemagick is needed to be updated only for mod_imagick, otherwise is not needed.

mod_imagick supports playing pdf files like videos. Its useful but your call.

...

If we limit everything on what is on SD repo (and exclude vlc+mod_imagick) well I think (but must check) that epel is enough and only few stuff must be added (mpg123, lame?, libshout, libmpv2 and maybe nasm). But I need to recheck it since I tried to have everything fs 1.6 needs, with the correct versions.

Just to be completely 100% clear, we will not be serving up mp3 or h264 binaries from our repos.

...

there's one dep on freetype2 is FS which is not really needed, I'll file a pull rq for it, so we can avoid updating it. (you need 2.4.something but with 2.3.11 compiles and works ok)

We for sure need freetype to support a bunch of features that have to do with putting text on video, and it will require rebuilding it against libpng 1.6 for some basic functionality, while these are already optional, this will significantly impact some conference functionality.

...

About libpng: I've used the CentOS shipped one and seems to work ok (version 1.2.49) to me.

libpng1.6 is required for some transparency functionality that we use heavily. It will build with older versions, but functionality will be significantly diminished.

...

So, I think most of the work is around vlc: you say that does not work well, what will be it's destiny?

We are not getting rid of it, but my recommendation would be to not try to build it. I already spend significant time telling people to use mod_av instead.

...

If is just an experiment I can try to rebuild everything without it and check what is needed again in order to shrink that list (it will be a lot shorter) and report back.

I'm not sure about mod_imagick, not tested it yet.

Another question about mp3 code: what about mpg123/lame that is needed by FS?

These can't go into our repo, but any moderately recent one should be fine. I think the api is stable. The issue with using older versions would be if it will cause stability issues and crashing, as there has been a long list of buffer overflow issues in that code over the years.

...

If you're not willing to add it to your repo, how mp3 files are handled ? using libav ?

If there is no other place to get packages for that library, the module simply wouldn't be built, and that feature would not be available.

...

If yes, another dep can be removed.

matteo

----- Il 25-giu-15, alle 21:22, Michael Jerris mike@jerris.com ha scritto:

...

I have no issues rebuilding some packages for never version in our repos... The big issues are, we will not put binaries of any of the mp3 or h264 code in our repos, and we are not going to include documentation pointing to non-reputable 3rd party repos. I'm open to pointing to rpmforge if we can put together some documentation that won't result in complete nightmares from version conflicts from all the different repos, but I'm not sure this is possible, can we craft a meta package that helps nail down the specific versions to use, or to somehow blacklist all but a small list of packages from rpmforge? In regards to VLC, to be honest, I'd skip it completely, it adds little value and doesn't work great. The one you want to get working is libav or ffmpeg built against x264. The trick is you'll need to audit the versions of all these things you are talking about updating and figuring out if the upgrades are even actually necessary Please note that libav will need to be rebuilt for sure so its built against our version of libvpx, and if not already done, some other libs will need to be rebuilt against libpng 1.6 or greater. Those 2 libraries for sure need to be updated to our versions. Additionally some of the libs in our tree may exist in other distros, but ours are actually different api/abi but have the same name, and the ones in the distros are broken. For example libilbc. I have not yet audited to see if ours has enough backwards api that it could be updated in distro repos to replace their broken one. Most of the version limits that are in place are those versions based on thats what we have in debian jessie that is tested and confirmed working. Its likely you can use older versions, but functionality will need to be tested to confirm on a library by library basis.

Hi,

----- Il 25-giu-15, alle 19:45, Michael Jerris mike at jerris.com ha scritto:

...

for things like nasm, is that newer version out there for example in epel? that

...

would be the best case. Sure, the work I've done is already based on epel, so what is in epel is not built again.

I've rebuilt some epel packages only when a newer version is needed.

...

Backup would be to take a source pacakge from something > newer and just rebuild in a way that doesn't require any modifications, > fallback we can put the src out on our download servers and create a job for > it. As for x264, we will not be putting that in our repo, you'll have to find > some way to get that into some official repo that we can reference, maybe see > if you can get it into epel? The best case would be to get as much as possible > directly into epel so it leaves us having to manage as little as possible. The main "source" of deps (and troubles) is vlc 2.2, which needs a lot of stuff.

I've taken some packages from rpmfusion and rebuilt them, updating when needed.

So while epel is needed for deps, rpmfusion is not because all needed rpmfusion packages have been rebuilt by me using same sources/specs (if not updated)

I don't know if epel will ever accept all packages, because some are also updates to base system, like opencv which is present on CentOS base but too old and ImageMagick, to name few.

So the picture is: if you want to have video under CentOS 6 without hosting something (mainly vlc stuff and it's deps), you're out of luck since FS requirements are on very recent packages.

Just a quick list of stuff needed:

base CentOS updates not present anywhere: ImageMagick (updated), nasm(updated), libvncserver(updated), opencv(updated)

** from rpmfusion: a52dec, faad2, gpac, lame, vlc(updated), libmad, mpg123(updated), x264(updated for vlc 2.2), xvidcore

** from epel (rebuilt because different version) libmpv2(updated), libshout(updated)

** from Freeswitch SD: g722_1, broadvoice, libav, libcodec2, libsilk, libvpx, libyuv(updated), opus, soundtouch, openh264, flite, ilbc (epel has a newer one, pay attention!)

This is the list (should be almost complete, I'm not in the office right now) of what I've rebuit to have video running.

Is possible to reduce by 6 packages if rpmfusion is added with repo. Dunno if is wanted or not.

I think that epel will never accept updates to packages that are already into base distro.

And don't know about vlc and its deps... if rpmfusion exists maybe is because patents does not allow it into epel?

What do you think?

Matteo

On Jun 25, 2015, at 1:45 PM, Michael Jerris < mike@jerris.com > wrote:

for things like nasm, is that newer version out there for example in epel? that would be the best case. Backup would be to take a source pacakge from something newer and just rebuild in a way that doesn't require any modifications, fallback we can put the src out on our download servers and create a job for it. As for x264, we will not be putting that in our repo, you'll have to find some way to get that into some official repo that we can reference, maybe see if you can get it into epel? The best case would be to get as much as possible directly into epel so it leaves us having to manage as little as possible.

On Thursday, June 25, 2015, Matteo < mbrancaleoni@voismart.it > wrote:

I know how specs works, I'm maintaining a private repo like epel with tens of packages since years, using the same tools used by fedora ( koji, mock, mash).

My intent is not to create a custom build of freeswitch, but a repo like epel or rpmfusion with only the needed build deps.

What is not clear to me is the flow to add a new dep.

Let's say I need to add a bunch of new libs, like gpac, nasm, x264, to name a few.

Which is the correct approach to fit into Fs build structure?

Mat

Inviato da iPhone

...

Il giorno 25/giu/2015, alle ore 18:08, Ken Rice ha scritto:

You know in the spec files you can if things for specific versions... You'll just have to figure out the correct Ifs for Cent7 vs Cent6 vs say Suse

...

On 6/25/15, 11:03 AM, "Matteo" wrote:

Ok,

since some packages are only centos 6 specific updates, how do you plan to handle them?

For example, nasm is a required update to CentOS 6 in order to build other stuff, but is not needed for debian or CentOS 7

Right now in the repo I don't see anything distro-specific .

Regards, Matteo

_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com

Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com

FreeSWITCH-dev mailing list FreeSWITCH-dev@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev UNSUBSCRIBE: http://lists.freeswitch.org/mailman/options/freeswitch-dev http://www.freeswitch.org

-- Ken http://www.FreeSWITCH.org http://www.ClueCon.com http://www.OSTAG.org irc.freenode.net #freeswitch Twitter: @FreeSWITCH

_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com

Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com

FreeSWITCH-dev mailing list FreeSWITCH-dev@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev UNSUBSCRIBE: http://lists.freeswitch.org/mailman/options/freeswitch-dev http://www.freeswitch.org

_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com

Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com

FreeSWITCH-dev mailing list FreeSWITCH-dev@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev http://www.freeswitch.org

_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com

Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com

FreeSWITCH-dev mailing list FreeSWITCH-dev@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev http://www.freeswitch.org

_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com

Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com

FreeSWITCH-dev mailing list FreeSWITCH-dev@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev http://www.freeswitch.org

_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com

Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com

FreeSWITCH-dev mailing list FreeSWITCH-dev@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev http://www.freeswitch.org