[Gt-eos] GCT build system

[Brian Lin]

Hi all,

Stealing Mat's thunder since he's out of the office -- we've got 
pre-release tarballs and SRPMs available 
(https://github.com/gridcf/gct/releases/tag/v0.20180103-pre)! At this 
point, I think the next step is to get binary RPMs based off of the 
pre-release so we can test them, perhaps in EPEL?

Regarding distribution of binary RPMs, copr/opensuse build services 
seems like overkill if we can get them into EPEL, imo.

- Brian

On 12/22/2017 12:24 PM, Dave Dykstra wrote:
> I use the OpenSUSE Build Service for making signed centos yum
> repositories and debian/ubuntu apt repositories
>      https://build.opensuse.org/repositories/home:cvmfs:contrib
>
> It reads all the source from github, and I have heard that builds can be
> automated based on github triggers, but I haven't tried that yet.
> Instead so far I manually update the configuration when it is time for a
> new release.
>
> Dave
>
> On Thu, Dec 21, 2017 at 03:36:30PM +0100, Mischa Salle wrote:
>> Hi Mátyás,
>>
>> it's for Mattias Ellert to further decide what to do, but in any case,
>> it makes sense to me to only make src, not binary RPMs.
>>
>> Personally I'm not sure I would like to have binary RPMs directly made
>> by travis. I don't know whether it could produce signed RPMs from it,
>> a koji-based approach seems more reasonable. Perhaps we can use
>> https://copr.fedorainfracloud.org/
>> For 'our' RPMs we could also use the open(suse) build service, which
>> produces signed RPMs, but copr seems more logical.
>> For debs, I would say it might be better to just use the src
>> distribution tarball, since you typically also want to sign the src
>> packages, and do a manual update of the changelog.
>>
>> But perhaps Mattias has different ideas?
>>
>>      Cheers,
>>      Mischa
>>
>> On Wed, Dec 20, 2017 at 03:45:30PM -0600, Mátyás Selmeci wrote:
>>> Hi folks,
>>>
>>> Just to let you know where we are in regards to getting a build system
>>> going. I???ve put together a PR for automated builds (using Travis-CI) such
>>> that whenever a GitHub Release is tagged, automated tests are kicked off
>>> and, if successful, tarballs and source RPMs for the individual components
>>> are added to the download page for the release.
>>>
>>> I have not included binary RPMs because
>>>
>>> a) we???re probably going to get them from EPEL anyway;
>>> b) deployment is unreliable when you have too many files in a release;
>>> c) without a YUM repo, downloading and installing those RPMs would be too
>>> painful anyway.
>>>
>>> I have provided a script and a Vagrantfile in case anyone does want to build
>>> the binary RPMs for themselves. I haven???t done anything with debs because I
>>> have no experience with Debian packaging, but if someone wants to put
>>> something together for that, I can help them figure out the build system.
>>>
>>> The pull request is PR #10 <https://github.com/gridcf/gct/pull/10>; reviews
>>> are welcome.
>>>
>>> What???s the next step?
>>>
>>> Thanks,
>>> -Mat
>>>
>>> ???
>>>
>>> -- 
>>> Mátyás (Mat) Selmeci
>>> Open Science Grid Software Team / Center for High-Throughput Computing
>>> University of Wisconsin-Madison Department of Computer Sciences
>>>
>>> _______________________________________________
>>> Gt-eos mailing list
>>> Gt-eos at mailman.egi.eu
>>> http://mailman.egi.eu/mailman/listinfo/gt-eos
>>
>> -- 
>> Nikhef                      Room  H155
>> Science Park 105            Tel.  +31-20-592 5102
>> 1098 XG Amsterdam           Fax   +31-20-592 5155
>> The Netherlands             Email msalle at nikhef.nl
>>    __ .. ... _._. .... ._  ... ._ ._.. ._.. .._..
>
>
>> _______________________________________________
>> Gt-eos mailing list
>> Gt-eos at mailman.egi.eu
>> http://mailman.egi.eu/mailman/listinfo/gt-eos
> _______________________________________________
> Gt-eos mailing list
> Gt-eos at mailman.egi.eu
> http://mailman.egi.eu/mailman/listinfo/gt-eos