[Gt-eos] GCT build system

Mischa Salle msalle at nikhef.nl
Fri Jan 5 11:05:55 CET 2018


Hi Brian, Mátyás,

good news, thanks for all the hard work!!

A few small remarks:
- I noticed that we will need to change the spec files, they now still
  contain e.g.
    [...]
    Vendor      : Globus Support
    URL         : http://toolkit.globus.org/
    Summary     : Globus Toolkit - Globus GSI Proxy Core Library
    Description :
    The Globus Toolkit is an open source software toolkit used for
    building Grid systems and applications. It is being developed by the
    Globus Alliance and many others all over the world. A growing number
    of projects and companies are using the Globus Toolkit to unlock the
    potential of grids for their cause.

- concerning binary RPMs, copr is very straightforward, and easily
  scriptable (I have just started a build using cURL for a test project,
  see attached 2 scripts, plus the content of
  https://copr.fedorainfracloud.org/api/, I also use the OBS for addons
  for OpenSUSE, but actually find copr even easier). It would be
  straightforward to run this for all the new src RPMs by making a
  new gct project or so. It looks like it's possible to trigger the copr
  build directly from git tags.
  For a prerelease it doesn't make so much difference, especially if we
  never will build our own production binary RPMs, there isn't much
  point in spending effort getting it right, since for EPEL/Fedora we
  will only need the src RPMs.

Mischa

On Thu, Jan 04, 2018 at 11:18:39AM -0600, Brian Lin wrote:
> 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
> 
> _______________________________________________
> 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
  __ .. ... _._. .... ._  ... ._ ._.. ._.. .._..
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3402 bytes
Desc: not available
URL: <http://mailman.egi.eu/pipermail/discuss/attachments/20180105/cc273984/attachment.p7s>


More information about the discuss mailing list