[Freeswitch-dev] Video build deps for CentOS 6

[Michael Jerris]

> On Jun 25, 2015, at 11:15 AM, Matteo <mbrancaleoni at voismart.it> wrote:
> 
> Hi,
> 
> ----- Il 25-giu-15, alle 17:00, Michael Jerris mike at 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 at 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 at lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev
> http://www.freeswitch.org