Taking this review.

It would have been nice if you provided a successful koji scratch build for rawhide - it shows that the package builds and that tests succeed on all architectures. [0]


I see two issues with the current .spec and package:


1. Why are you packaging a specific commit that is over half a year old, and not the latest git master?

2. Is it reasonable to include the sources+provides for
> golang(github.com/google/go-github/tests/integration)
in the package, e.g. are those sources imported by any packages using this library, or are they only internal tests?

If the tests are just used internally, exclude them from the -devel and -unit-test-devel package (for example by removing the sources before running the scripts generated by gofed). I had to do that for one of my packages, see [1].


[0]: https://koji.fedoraproject.org/koji/taskinfo?taskID=18265357

[1]: https://src.fedoraproject.org/cgit/rpms/golang-github-d4l3k-messagediff.git/tree/golang-github-d4l3k-messagediff.spec#n93

I'll run the next update through koji (or at least add all arches to the copr repo); I've been using copr for my workflow for this as I've been wading through dependencies and it makes working with a large group of packages easier, but at the level of individual reviews, koji is probably better on a few fronts.

Re: the older version, I'm building this as a dependency for Hashicorp Vault, and the version I'm able to build against the dependencies in Fedora today (specifically, Consul is pretty far out of date, and updating it is a bit messy: #1348906) means back-dating this dependency before sweeping API change was made (contexts were added to most of the API).

Do you see the older version as a sticking point? There's an argument to be made for just bringing the newest version in how, with the assumption that everything else will have caught up by the time I'm trying to package Vault, but I've learned to be conservative when estimating the rate of updates for golang dependencies in Fedora. ;)

Tests/provides: good catch, and you're right; I'll clean that up.

COPR doesn't support all arches that fedora itself supports (aarch64, armv7hl, ppc64 are not available as targets in COPR, but are official arches in rawhide), that's why a koji scratch build is preferable.


If you are packaging the old version because of compatibility issues with pre-existing packages, mention that in a comment in the .spec file (somewhere near the %commit variable definition). Of course, it would be preferable to update the existing packages to compatible versions.

I see 2 possible courses of action here:

1. - package the older snapshot of this package
   - mention the reason explicitly in the .spec file
   - add package to fedora
   - create a tracking bug for bumping this package to a new version, report bugs for packages incompatible with the new version and mark them as blockers.

2. report bugs against the incompatible packages now and mark them as blockers for this review (which would be the cleaner approach IMO)

Spec URL: https://fedorapeople.org/cgit/logic/public_git/golang-github-google-go-github.git/plain/golang-github-google-go-github.spec
SRPM URL: https://kojipkgs.fedoraproject.org//work/tasks/860/18310860/golang-github-google-go-github-0-0.1.git553fda4.fc27.src.rpm

You know what, lets just go with the latest version; it's arguably more correct, and I'll just open blockers elsewhere as I go if needed. I also figured out what was causing the test failure (mailcap buildreq; part of me wonders if golang itself shouldn't have a requires for mailcap), so unit tests are enabled in this build.

Scratch build is at: https://koji.fedoraproject.org/koji/taskinfo?taskID=18310859

Damn, I was too slow replying (somehow I missed the bugzilla mail notification) ... now your newest commit is not the newest anymore ;)

But that's not your fault. The package looks good, and successful scratch build is nice.

Approved.

Package request has been approved: https://admin.fedoraproject.org/pkgdb/package/rpms/golang-github-google-go-github

*** Bug 1297537 has been marked as a duplicate of this bug. ***

Could you package for EPEL7 at the same time?

golang-github-google-go-github-0-0.1.git553fda4.fc25 has been submitted as an update to Fedora 25. https://bodhi.fedoraproject.org/updates/FEDORA-2017-552cd630c4

golang-github-google-go-github-0-0.1.git553fda4.fc26 has been submitted as an update to Fedora 26. https://bodhi.fedoraproject.org/updates/FEDORA-2017-7527b97f87

marcindulak: I requested a branch for EPEL7, but can't build because of a couple of missing dependencies:

Error: No Package found for golang(github.com/google/go-querystring/query)
Error: No Package found for golang(golang.org/x/oauth2)

You'll proably want to follow up with the maintainers of those packages if you want to see this in EPEL; I don't have any personal need for it, so it's not something I'm going to be able to commit any time to.

golang-github-google-go-github-0-0.1.git553fda4.fc26 has been pushed to the Fedora 26 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-7527b97f87

Thanks. For the reference, here are the dependencies

bug #1435824
bug #1227273

golang-github-google-go-github-0-0.1.git553fda4.fc25 has been pushed to the Fedora 25 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-552cd630c4

Please push to stable.

golang-github-google-go-github-0-0.1.git553fda4.fc25 has been pushed to the Fedora 25 stable repository. If problems still persist, please make note of it in this bug report.

golang-github-google-go-github-0-0.1.git553fda4.fc26 has been pushed to the Fedora 26 stable repository. If problems still persist, please make note of it in this bug report.