Packaging upstream with released tarballs in Copr

[Martin Novák]

Hello,

It appears there's currently no option to build a package by just a
SPEC file which contains valid Source0 URL.

There's a project on GitHub with released tarballs, which I'd like to
package in Copr (and later in Fedora perhaps). The easiest method for
building that package in Copr for me would be to link a SPEC file from
my GitHub repository which I'd regulary update with new project
releases.*

Copr however offers only Tito and Mock SCM builds. From what I read,
it seems to me that both methods expect upstream and packaging files
to be in same repository. Is it true? If not, is there any example of
a Tito/MockSCM project linking external tarball which builds on Copr?

If yes, then maintaining a forked repository seems a bit cumbersome to
me. For each release Git tag in the upstream repository, I'd have to
create a new child tag for the release with a SPEC file and it doesn't
seem Tito automates this case so I'd have to cherry-pick the SPEC file
from my master branch and modify it. Of course I can automate this
with a script also in my master branch, but it feels "custom" to me.
Is there any proper method?

Even though I've researched the topic I'm still newbie to packaging
and Git so please have mercy.

Thank you.

* Or linking repository and specifying subdirectory and SPEC file name
  so that the repository could contain more projects and a project
  could contain patches.

[Igor Gnatenko]

I think MockSCM is that what you need.

----- Original Message -----
> From: "Martin Novák" 
> To: [e-mail]
> Sent: Sunday, April 17, 2016 5:38:48 PM
> Subject: Packaging upstream with released tarballs in Copr
>
> Hello,
>
> It appears there's currently no option to build a package by just a
> SPEC file which contains valid Source0 URL.
>
> There's a project on GitHub with released tarballs, which I'd like to
> package in Copr (and later in Fedora perhaps). The easiest method for
> building that package in Copr for me would be to link a SPEC file from
> my GitHub repository which I'd regulary update with new project
> releases.*
>
> Copr however offers only Tito and Mock SCM builds. From what I read,
> it seems to me that both methods expect upstream and packaging files
> to be in same repository. Is it true? If not, is there any example of
> a Tito/MockSCM project linking external tarball which builds on Copr?
>
> If yes, then maintaining a forked repository seems a bit cumbersome to
> me. For each release Git tag in the upstream repository, I'd have to
> create a new child tag for the release with a SPEC file and it doesn't
> seem Tito automates this case so I'd have to cherry-pick the SPEC file
> from my master branch and modify it. Of course I can automate this
> with a script also in my master branch, but it feels "custom" to me.
> Is there any proper method?
>
> Even though I've researched the topic I'm still newbie to packaging
> and Git so please have mercy.
>
> Thank you.
> Or linking repository and specifying subdirectory and SPEC file name
> so that the repository could contain more projects and a project
> could contain patches.
>
> copr-devel mailing list
> [e-mail]
> https://lists.fedorahosted.org/admin/lists/[e-mail]

[Sérgio Basto]

On Dom, 2016-04-17 at 11:50 -0400, Igor Gnatenko wrote:
> I think MockSCM is that what you need.

Here is a very good example of using MockSCM https://fedoraproject.org/
wiki/Projects/Mock/Plugin/Scm#Example , but looks to me that is useful
for developers of the source of one package ... 
I'd like to, as packager maintainer, avoid upload tarball every time I
change my spec, for example, I'm packaging opencv-3.1, when I just
modify two or three letters in opencv.spec, I have to do :

rpmbuild -bs opencv.spec --define "_sourcedir ." --define '_srcrpmdir
.' && copr-cli build  sergiomb/opencv ./opencv-3.1.0-3.fc23.src.rpm

and I have to upload 123M every time , I think that is that Martin (and
me ) want to avoid .

Best regards.
> ----- Original Message -----
> > From: "Martin Novák" 
> > To: [e-mail]
> > Sent: Sunday, April 17, 2016 5:38:48 PM
> > Subject: Packaging upstream with released tarballs in Copr
> >
> > Hello,
> >
> > It appears there's currently no option to build a package by just a
> > SPEC file which contains valid Source0 URL.
> >
> > There's a project on GitHub with released tarballs, which I'd like
> > to
> > package in Copr (and later in Fedora perhaps). The easiest method
> > for
> > building that package in Copr for me would be to link a SPEC file
> > from
> > my GitHub repository which I'd regulary update with new project
> > releases.*
> >
> > Copr however offers only Tito and Mock SCM builds. From what I
> > read,
> > it seems to me that both methods expect upstream and packaging
> > files
> > to be in same repository. Is it true? If not, is there any example
> > of
> > a Tito/MockSCM project linking external tarball which builds on
> > Copr?
> >
> > If yes, then maintaining a forked repository seems a bit cumbersome
> > to
> > me. For each release Git tag in the upstream repository, I'd have
> > to
> > create a new child tag for the release with a SPEC file and it
> > doesn't
> > seem Tito automates this case so I'd have to cherry-pick the SPEC
> > file
> > from my master branch and modify it. Of course I can automate this
> > with a script also in my master branch, but it feels "custom" to
> > me.
> > Is there any proper method?
> >
> > Even though I've researched the topic I'm still newbie to packaging
> > and Git so please have mercy.
> >
> > Thank you.
> > Or linking repository and specifying subdirectory and SPEC file
> >
> > name
> >   so that the repository could contain more projects and a project
> >   could contain patches.
> > _______________________________________________
> > copr-devel mailing list
> > [e-mail]
> > https://lists.fedorahosted.org/admin/lists/[e-mail]
> > osted.org

[Miroslav Suchý]

Dne 24.4.2016 v 03:59 Sérgio Basto napsal(a):
> and I have to upload 123M every time , I think that is that Martin (and
> me ) want to avoid .

Until we open dist-git for writing (not likely in very near future) there is no way to workaround it. Either you must
upload it or Copr have to download it each time.

[Pavel Raiskup]

On Monday 25 of April 2016 10:57:26 Miroslav Suchý wrote:
> Dne 24.4.2016 v 03:59 Sérgio Basto napsal(a):
> > and I have to upload 123M every time , I think that is that Martin (and
> > me ) want to avoid .
>
> Until we open dist-git for writing (not likely in very near future)
> there is no way to workaround it. Either you must upload it or Copr have
> to download it each time.

The issue, I believe, is re-uploading -- at least for me on asymmetric
internet connection.  Re-downloading is probably not that big issue for
copr and people might see this as detail.

---

I must give +1 to the feature which would allow us to trigger build by
webhook against git repository having spec file (while downloading of the
sources would have be done automatically, `spectool *.spec -S`).  This
should of course be configured in git directly (.copr.yml file?) --
while I'm 100% giving -1 to turing-complete programmable way (shell script
in git?) how to generate source rpm.

To me, this is not feature which goes against dist-git-with-write-access
feature, both are needed.  Should I write a patch?  I know at least about
one upstream I'm not part of (pgjdbc) who would love to pioneer the
testing ...

Pavel

[Miroslav Suchý]

Dne 26.4.2016 v 15:37 Pavel Raiskup napsal(a):
> I must give +1 to the feature which would allow us to trigger build by
> webhook against git repository having spec file (while downloading of the
> sources would have be done automatically, `spectool *.spec -S`).  This
> should of course be configured in git directly (.copr.yml file?) --
> while I'm 100% giving -1 to turing-complete programmable way (shell script
> in git?) how to generate source rpm.
>
> To me, this is not feature which goes against dist-git-with-write-access
> feature, both are needed.  Should I write a patch?  I know at least about
> one upstream I'm not part of (pgjdbc) who would love to pioneer the
> testing ...

That sounds reasonable. But I do not want this in Copr. I would like to have it as standalone tool (or part of mock).
And then when this tool will be reasonable good, only then I'm willing to incorporate it in Copr.

[Miroslav Suchý]

Dne 17.4.2016 v 17:38 Martin Novák napsal(a):
> Copr however offers only Tito and Mock SCM builds. From what I read,
> it seems to me that both methods expect upstream and packaging files
> to be in same repository. Is it true? If not, is there any example of
> a Tito/MockSCM project linking external tarball which builds on Copr?

To be honest - tito and mock-scm was just proof of concept for building
directly from pypi, rubygems... Albeit still useful in some situation.
You can always create SRPM on your own and submit it to Copr.

Example of building using Tito:
  https://github.com/xsuchy/packaging/tree/master/glacier-cli
  https://github.com/xsuchy/packaging/blob/master/rel-eng/tito.props
This is example where tar.gz is stored in the same reposority.
However Tito support git-annex so you can utilize this. E.g. see this
blog post:

http://m0dlx.com/blog/Reproducible_builds_on_Copr_with_tito_and_git_annex.ht...

Mirek