Bug 1001300 - Review Request: golang-github-gorilla-context - A golang registry for global request variables
Summary: Review Request: golang-github-gorilla-context - A golang registry for global ...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: Package Review
Version: rawhide
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Matthew Miller
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: 1001317
TreeView+ depends on / blocked
 
Reported: 2013-08-26 20:39 UTC by Lokesh Mandvekar
Modified: 2014-07-01 22:59 UTC (History)
5 users (show)

Fixed In Version: golang-github-gorilla-context-0-0.19.git708054d.fc20
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-10-29 03:37:41 UTC
Type: ---
Embargoed:
mattdm: fedora-review+


Attachments (Terms of Use)

Description Lokesh Mandvekar 2013-08-26 20:39:35 UTC
Spec URL: http://lsm5.fedorapeople.org/rpmbuild/SPECS/golang-context.spec

SRPM URL: http://lsm5.fedorapeople.org/rpmbuild/SRPMS/golang-context-0.0.1-1.fc21.src.rpm

Description:
Package gorilla/context stores values shared during a request lifetime.

For example, a router can set variables extracted from the URL and later application handlers can access those values, or it can be used to store sessions values to be saved at the end of a request. There are several others common uses. 

Fedora Account System Username: lsm5

Koji build: http://koji.fedoraproject.org/koji/taskinfo?taskID=5857155

$ rpmlint SPECS/golang-context.spec 
0 packages and 1 specfiles checked; 0 errors, 0 warnings.

$ rpmlint SRPMS/golang-context-0.0.1-1.fc21.src.rpm 
1 packages and 0 specfiles checked; 0 errors, 0 warnings.

 $ rpmlint RPMS/x86_64/golang-context-0.0.1-1.fc21.x86_64.rpm
golang-context.x86_64: E: no-binary
golang-context.x86_64: W: only-non-binary-in-usr-lib
golang-context.x86_64: E: script-without-shebang /usr/lib64/golang/src/cmd/context/context.go
golang-context.x86_64: E: script-without-shebang /usr/lib64/golang/src/cmd/context/doc.go
golang-context.x86_64: E: script-without-shebang /usr/lib64/golang/src/cmd/context/context_test.go
1 packages and 0 specfiles checked; 4 errors, 1 warnings.

Comment 2 Ralf Corsepius 2013-08-29 04:00:16 UTC
This section from your spec longs for explanations:

%global _enable_debug_package 0
%global debug_package %{nil}
%global __os_install_post /usr/lib/rpm/brp-compress %{nil}

Comment 3 Vincent Batts 2013-08-29 15:43:30 UTC
A couple of points:

* as a matter of naming convention, lets include as much of the import path into the package name as possible. Escpecially something like the gorilla project that has a number of libraries
 - golang-github-gorilla-context ?
 - golang-gorilla-context ?

* Since the $GOROOT/src is not presently a symlink to a noarch place, then there is no point to _not_ include the precompiled *.a files

* The path in $GOROOT/src that the source files is being landed does not line up with the import path expected. Also, source in GOROOT should be in $GOROOT/src/pkg, not ./src/cmd/. That directory is for 'go' command itself.
 - expected: "github.com/gorilla/context"
 - rpm: "context"

* The global debug lines are not needed. There is some rpm magic that attempts to strip the *.a archives, but they are not gcc *.a, and do not strip as such. As for the __spec_install_post, I have not found it useful for binaries/libraries built by golang compiler. But are needed for building the compiler itself.

* Include a meta Provide: for the import paths provided in this library.
Require: golang("github.com/gorilla/context")

Comment 5 Lokesh Mandvekar 2013-08-29 19:39:29 UTC
I changed the spec file name because rpmlint was giving me some invalid spec name error.

Spec URL: http://lsm5.fedorapeople.org/rpmbuild/SPECS/golang-github-gorilla-context.spec

SRPM URL: http://lsm5.fedorapeople.org/rpmbuild/SRPMS/golang-github-gorilla-context-0.0.1-3.fc21.src.rpm

Few things I'm unsure of (see inline replies)

(In reply to Vincent Batts from comment #3)
> A couple of points:

>  - golang-github-gorilla-context ?

I've used this for the new package name.

> * Since the $GOROOT/src is not presently a symlink to a noarch place, then
> there is no point to _not_ include the precompiled *.a files

I'm sorry I didn't see any *.a files in the package. Am I missing something? 
 
> * The path in $GOROOT/src that the source files is being landed does not
> line up with the import path expected. Also, source in GOROOT should be in
> $GOROOT/src/pkg, not ./src/cmd/. That directory is for 'go' command itself.
>  - expected: "github.com/gorilla/context"
>  - rpm: "context"

Done (hopefully). Check it out.
 
> * The global debug lines are not needed. There is some rpm magic that
> attempts to strip the *.a archives, but they are not gcc *.a, and do not
> strip as such. As for the __spec_install_post, I have not found it useful
> for binaries/libraries built by golang compiler. But are needed for building
> the compiler itself.

Should be done. Again, unsure about the *.a archives
  
> * Include a meta Provide: for the import paths provided in this library.
> Require: golang("github.com/gorilla/context")

Did you mean Provides instead of Require in the latter line (??). Let me know if I got it wrong.
I have put a:
 Provides: golang("github.com/gorilla/context") = %{version}-%{release}



$ rpmlint RPMS/x86_64/golang-github-gorilla-context-0.0.1-3.fc21.x86_64.rpm
golang-github-gorilla-context.x86_64: E: no-binary
golang-github-gorilla-context.x86_64: W: only-non-binary-in-usr-lib
1 packages and 0 specfiles checked; 1 errors, 1 warnings.

Comment 6 Vincent Batts 2013-08-29 20:31:59 UTC
cool. So as for the allusion to *.a files that aren't present, it is because your spec did not precompile them and I was encouraging such. Here is an example of a library that is packaged http://pastebin.test.redhat.com/161221


One additional note. the %{version} ought to reflect the git commit hash. Likely in the form of git%{shortcommit}
Since many libraries will not have tagged version or otherwise, best to include as much trace-ability as possible.

Comment 7 Lokesh Mandvekar 2013-08-30 03:52:15 UTC
(In reply to Vincent Batts from comment #6)
> cool. So as for the allusion to *.a files that aren't present, it is because
> your spec did not precompile them and I was encouraging such. Here is an
> example of a library that is packaged http://pastebin.test.redhat.com/161221

I'm getting "cannot find package github.com/gorilla/context". Could you please check what I'm doing wrong. The build fails at the go install %{import_path} stage.

Here's the revised spec: http://pastebin.test.redhat.com/161267

And here's the build output: http://pastebin.test.redhat.com/161268
> 
> 
> One additional note. the %{version} ought to reflect the git commit hash.
> Likely in the form of git%{shortcommit}
> Since many libraries will not have tagged version or otherwise, best to
> include as much trace-ability as possible.

Taken care of in the new spec.

Comment 8 Lokesh Mandvekar 2013-09-03 17:30:32 UTC
Looks like the revised spec pastebin I sent earlier isn't available anymore. Here's the same spec again: http://pastebin.test.redhat.com/161713

Comment 9 Vincent Batts 2013-09-03 18:17:42 UTC
http://pastebin.test.redhat.com/pastebin.php?diff=161724 is a diff of the spec including the reason for that build failure, and a couple of additional fixes to get a built rpm.

Comment 10 Lokesh Mandvekar 2013-09-03 18:37:14 UTC
Thanks Vincent!

Spec URL: http://lsm5.fedorapeople.org/rpmbuild/SPECS/golang-github-gorilla-context.spec

SRPM URL: http://lsm5.fedorapeople.org/rpmbuild/SRPMS/golang-github-gorilla-context-git708054d-4.fc21.src.rpm

$ rpmlint SPECS/golang-github-gorilla-context.spec 
0 packages and 1 specfiles checked; 0 errors, 0 warnings.

$ rpmlint SRPMS/golang-github-gorilla-context-git708054d-4.fc21.src.rpm
1 packages and 0 specfiles checked; 0 errors, 0 warnings.

$ rpmlint RPMS/x86_64/golang-github-gorilla-context-git708054d-4.fc21.x86_64.rpm
golang-github-gorilla-context.x86_64: W: binaryinfo-readelf-failed /usr/lib64/golang/pkg/linux_amd64/github.com/gorilla/context.a readelf: Error: Unable to read in 0xb7c2 bytes of section headers
golang-github-gorilla-context.x86_64: W: devel-file-in-non-devel-package /usr/lib64/golang/pkg/linux_amd64/github.com/gorilla/context.a
1 packages and 0 specfiles checked; 0 errors, 2 warnings.

Comment 11 Lokesh Mandvekar 2013-09-03 20:53:11 UTC
Vincent:

Once I install the generated RPM, if I try to build it again, I get this error:
http://pastebin.test.redhat.com/161774

If I uninstall the RPM and build it again, the build goes fine.

Is this expected behavior?

Comment 12 Vincent Batts 2013-09-04 17:25:41 UTC
I'm investigating a solution. While it is not uncommon for an rpm to need to be removed to get an accurate compile of that rpm, I feel this ought not be the case. 
The issue is because when the rpm _is_ installed, then the 'github.com/gorilla/context' is showing in the GOROOT and is up-to-date. So when the rpmbuild is setting a GOPATH and attempting to build that, nothing happens.

After a review of the archlinux and debian packaging guidelines and helpers, it looks like they'll have the same issue.
I'll take the action item to iron this out.

Comment 13 Vincent Batts 2013-09-09 18:57:00 UTC
Lokesh, see http://pastebin.test.redhat.com/162710
This iteration of found directories should be sufficient for most libraries, but could report an error if it find a directory that is not compilable (testing data or such)

Comment 14 Lokesh Mandvekar 2013-09-09 20:30:36 UTC
Vincent, thanks a lot, it worked!

Also, I'm guessing, $plat in the spec you sent would be interchangeable with %{pkgarch} (I picked this one up from your goyaml specfile)

rpmlint complained of .a archives not being in a devel package, so devel package generated as well.

Spec URL: http://lsm5.fedorapeople.org/rpmbuild/SPECS/golang-github-gorilla-context.spec

SRPM URL: http://lsm5.fedorapeople.org/rpmbuild/SRPMS/golang-github-gorilla-context-git708054d-5.fc21.src.rpm

$ rpmlint SPECS/golang-github-gorilla-context.spec 
0 packages and 1 specfiles checked; 0 errors, 0 warnings.

$ rpmlint SRPMS/golang-github-gorilla-context-git708054d-5.fc21.src.rpm
1 packages and 0 specfiles checked; 0 errors, 0 warnings.

$ rpmlint RPMS/x86_64/golang-github-gorilla-context-git708054d-5.fc21.x86_64.rpm
golang-github-gorilla-context.x86_64: W: only-non-binary-in-usr-lib
1 packages and 0 specfiles checked; 0 errors, 1 warnings.

$ rpmlint RPMS/x86_64/golang-github-gorilla-context-devel-git708054d-5.fc21.x86_64.rpm
golang-github-gorilla-context-devel.x86_64: W: summary-not-capitalized C github-gorilla-context pkg archive files
golang-github-gorilla-context-devel.x86_64: W: binaryinfo-readelf-failed /usr/lib64/golang/pkg/linux_amd64/github.com/gorilla/context.a readelf: Error: Unable to read in 0xb7c2 bytes of section headers
golang-github-gorilla-context-devel.x86_64: W: no-documentation
1 packages and 0 specfiles checked; 0 errors, 3 warnings.

Comment 16 Lokesh Mandvekar 2013-09-10 05:07:55 UTC
rpmbuild should now work regardless of package installation status

Spec URL: http://lsm5.fedorapeople.org/rpmbuild/SPECS/golang-github-gorilla-context.spec

SRPM URL: http://lsm5.fedorapeople.org/rpmbuild/SRPMS/golang-github-gorilla-context-git708054d-7.fc21.src.rpm

Koji Build: http://koji.fedoraproject.org/koji/taskinfo?taskID=5916441

Vincent: it looked like your Comment 9 spec file worked when RPM wasn't installed prior and not otherwise, while the Comment 13 spec file worked for the reverse case. So, I combined them like so:

unset GOROOT GOPATH GOOS GOARCH
if [ ! -d %{goroot}/src/pkg/%{import_path} ]; then
    GOPATH=$(readlink -f ./tmp-gopath/) go install %{import_path}
else
    GOPATH=$(readlink -f ./tmp-gopath/)
    pushd $GOPATH/src
    for dir in $(find %{import_path} -type d) ; do
        mkdir -p $GOPATH/pkg/%{pkgarch}/$(dirname $dir)
        go build -o $GOPATH/pkg/%{pkgarch}/${dir}.a %{import_path}
    done
    popd
fi

Hope it's valid. Let me know.

Matt:

$ rpmlint RPMS/x86_64/golang-github-gorilla-context-git708054d-7.fc21.x86_64.rpm
golang-github-gorilla-context.x86_64: W: only-non-binary-in-usr-lib
1 packages and 0 specfiles checked; 0 errors, 1 warnings.

$ rpmlint RPMS/x86_64/golang-github-gorilla-context-devel-git708054d-7.fc21.x86_64.rpm 
golang-github-gorilla-context-devel.x86_64: W: binaryinfo-readelf-failed /usr/lib64/golang/pkg/linux_amd64/github.com/gorilla/context.a readelf: Error: Unable to read in 0xb7c2 bytes of section headers
golang-github-gorilla-context-devel.x86_64: W: no-documentation
1 packages and 0 specfiles checked; 0 errors, 2 warnings.

Comment 18 Matthew Miller 2013-09-10 22:10:21 UTC
I think there's a few more issues there -- I'll try to get them all in one pass to eliminate more back-and-forth work for you. (Tomorrow, though. Long enough day already. :)

Comment 20 Lokesh Mandvekar 2013-09-16 17:14:40 UTC
only devel package generated

Provides:       golang("%{import_path}") = %{version}-%{release}
has been moved to devel package

Spec URL: http://lsm5.fedorapeople.org/rpmbuild/SPECS/golang-github-gorilla-context.spec

SRPM URL: http://lsm5.fedorapeople.org/rpmbuild/SRPMS/golang-github-gorilla-context-git708054d-11.fc21.src.rpm

Comment 21 Vincent Batts 2013-09-16 17:30:01 UTC
this looks good for now, based on the current state of golang-packaging-guidelines for fedora/RHEL. We'll continue firming those guidelines up.
But for now, this 'git708054d-11' iteration looks good. 

Since the resulting RPM will provide 'golang("github.com/gorilla/context")', then any other libraries/binaries needing to build with this need only to Require: golang("github.com/gorilla/context")

Comment 22 Matthew Miller 2013-09-16 20:50:34 UTC
1.

Excitingly, each individual component of the directory needs to be owned by the package -- 

%{goroot}/src/pkg/%{import_path} covers github.com/gorilla/context, but we also need
%{goroot}/src/pkg/github.com and %{goroot}/src/pkg/github.com/gorilla, then %{goroot}/pkg/%{pkgarch}/github.com.

---

2.

The snapshot version should go in the Version, not the Release, shouldn't it? (Since upstream does not seem to actually have any version numbers, use 0.). Otherwise, if they ever _do_ have a 1.0 release, we'll have trouble with a package with a version of "git....". (Is this confusing for packagers? Yes. It's overloading the Release field with two different purposes.)

---

3.

I'm getting an empty debuginfo package. We should either generate no debuginfo or generate a meaningful one. (I'm not sure offhand what the options are there for Go.)

Comment 23 Lokesh Mandvekar 2013-09-16 23:12:40 UTC
(In reply to Matthew Miller from comment #22)
> 1.
> 
> Excitingly, each individual component of the directory needs to be owned by
> the package -- 
> 
> %{goroot}/src/pkg/%{import_path} covers github.com/gorilla/context, but we
> also need
> %{goroot}/src/pkg/github.com and %{goroot}/src/pkg/github.com/gorilla, then
> %{goroot}/pkg/%{pkgarch}/github.com.

so in the case of github.com/{gorilla/{context,mux},kr/pty}} .. do all 3 own github.com? ..and both mux and context own gorilla? .. I have updated my spec to reflect this.

> 
> ---
> 
> 2.
> 
> The snapshot version should go in the Version, not the Release, shouldn't
> it? (Since upstream does not seem to actually have any version numbers, use
> 0.). Otherwise, if they ever _do_ have a 1.0 release, we'll have trouble
> with a package with a version of "git....". (Is this confusing for
> packagers? Yes. It's overloading the Release field with two different
> purposes.)

I'm not sure I understand you fully here, when you say snapshot version, do you mean the shortcommit, or something else? The shortcommit does go into the Version from what I can see.

My personal opinion: Even if upstream comes with version numbers, it could be better to just stick with shortcommits, since version numbers may not change across commits, having the commit number would help us pinpoint the exact version? Maybe I haven't considered everything when I'm saying this.

I haven't made this change in the spec yet though, also, could you take a look at the earlier versions I had in the spec file changelog, and let me know if you'd prefer it that way

> 
> ---
> 
> 3.
> 
> I'm getting an empty debuginfo package. We should either generate no
> debuginfo or generate a meaningful one. (I'm not sure offhand what the
> options are there for Go.)

I put %global debug_package %{nil} right on top

Some additional fixes from release 11 including: devel package BuildRequires golang.

Spec URL: http://lsm5.fedorapeople.org/rpmbuild/SPECS/golang-github-gorilla-context.spec

SRPM URL: http://lsm5.fedorapeople.org/rpmbuild/SRPMS/golang-github-gorilla-context-git708054d-12.fc21.src.rpm

Comment 24 Matthew Miller 2013-09-17 13:32:46 UTC
(In reply to Lokesh Mandvekar from comment #23)ub.com.
> so in the case of github.com/{gorilla/{context,mux},kr/pty}} .. do all 3 own
> github.com? ..and both mux and context own gorilla? .. I have updated my
> spec to reflect this.

Yeah, all of them would own the directory, unless there is some reason to have a common github (or common gorilla) package which would own them and then be a Requires.

> I'm not sure I understand you fully here, when you say snapshot version, do
> you mean the shortcommit, or something else? The shortcommit does go into
> the Version from what I can see.

Yes, shortcommit. See http://fedoraproject.org/wiki/Packaging:SourceURL#Github

   If the release corresponds to a github Tag with a sane numeric version, you 
   must use that version to populate the Version field in the spec file. If it 
   does not, look at the source code to see if a version is indicated there,
   and use that value. If no numeric version is indicated in the code, you
   may set Version to 0, and treat the package as a "pre-release" package (and
   make use of the %{shortcommit} macro). See
   Packaging:NamingGuidelines#Pre-Release_packages for details. 


> My personal opinion: Even if upstream comes with version numbers, it could
> be better to just stick with shortcommits, since version numbers may not
> change across commits, having the commit number would help us pinpoint the
> exact version? Maybe I haven't considered everything when I'm saying this.

That's why the shortcommit does go in the release string. I see your point, but I'm just following the guidelines here. 


> > I'm getting an empty debuginfo package. We should either generate no
> > debuginfo or generate a meaningful one. (I'm not sure offhand what the
> > options are there for Go.)
> I put %global debug_package %{nil} right on top

I think it's *probably* possible to get them working. Vincent, do you have any opinion? (This approach is better than generating empty debuginfo, though).

Comment 26 Matthew Miller 2013-09-17 14:55:34 UTC
Oop, sorry, got another one I didn't catch before. 

For the docs, get rid of 


%docdir %{_docdir}/%{name}-%{version}
%doc %{_docdir}/%{name}-%{version}/LICENSE
%doc %{_docdir}/%{name}-%{version}/README.md

and instead just do

%doc LICENSE README.md

which takes care of putting it into the right place.

I *think* everything else is good to go.

Comment 28 Vincent Batts 2013-09-17 15:57:01 UTC
I have to say, the git%{hash} needs to be in %{version}, not %{release}. This leaves the version as 0, so the docdir like /usr/share/doc/golang-github-gorilla-context-devel-0. Not awful, but not clear either.

And rather than making up an arbitrary version number (0), use the %Y%M%d of when the snapshot was taken. This allows for sorting ascending. (20130626.git708054d.14.el6 or similar)

Comment 29 Matthew Miller 2013-09-17 17:07:22 UTC
(In reply to Vincent Batts from comment #28)
> I have to say, the git%{hash} needs to be in %{version}, not %{release}.

This makes some sense, but putting it in version is actually the official packaging guideline -- http://fedoraproject.org/wiki/Packaging:SourceURL#Github.



(Also, for the docdir in specific, see http://fedoraproject.org/wiki/Changes/UnversionedDocdirs)

Comment 30 Matthew Miller 2013-09-17 17:13:12 UTC
Review passed with the following caveat.

- This package matches in-development ideas for a Go Language packaging
  standard and may need to be revised as those are finalized.
  Of particular note:
  - this library is packaged as static, and therefore just produces a
    -devel package (and as with Haskell packages, does not have a
    virtual provides for a -static package).
  - no debuginfo package is generated (because of the above)
  - we don't have standard compile flags for Go

Comment 31 Gwyn Ciesla 2013-09-17 17:20:09 UTC
No SCM request found.

Comment 32 Lokesh Mandvekar 2013-09-17 17:27:34 UTC
Ohh yes...sorry

New Package SCM Request
=======================
Package Name: golang-github-gorilla-context
Short Description: A golang registry for global request variables
Owners: lsm5
Branches: f19 f20 el6
InitialCC:

Comment 33 Gwyn Ciesla 2013-09-17 18:00:49 UTC
Git done (by process-git-requests).

Comment 34 Fedora Update System 2013-09-17 19:59:52 UTC
golang-github-gorilla-context-0-0.14.git708054d.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/golang-github-gorilla-context-0-0.14.git708054d.fc20

Comment 35 Fedora Update System 2013-09-17 20:00:53 UTC
golang-github-gorilla-context-0-0.14.git708054d.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/golang-github-gorilla-context-0-0.14.git708054d.fc19

Comment 36 Fedora Update System 2013-09-18 13:02:39 UTC
golang-github-gorilla-context-0-0.14.git708054d.fc19 has been pushed to the Fedora 19 testing repository.

Comment 37 Fedora Update System 2013-09-21 18:54:25 UTC
golang-github-gorilla-mux-0-0.5.gite718e93.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/golang-github-gorilla-mux-0-0.5.gite718e93.fc19

Comment 38 Fedora Update System 2013-09-22 06:11:38 UTC
golang-github-gorilla-context-0-0.15.git708054d.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/golang-github-gorilla-context-0-0.15.git708054d.fc20

Comment 39 Fedora Update System 2013-09-22 06:27:59 UTC
golang-github-gorilla-context-0-0.15.git708054d.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/golang-github-gorilla-context-0-0.15.git708054d.fc19

Comment 40 Fedora Update System 2013-09-22 07:10:26 UTC
golang-github-gorilla-mux-0-0.6.gite718e93.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/golang-github-gorilla-mux-0-0.6.gite718e93.fc19

Comment 41 Fedora Update System 2013-09-22 07:42:42 UTC
golang-github-gorilla-context-0-0.15.git708054d.el6 has been submitted as an update for Fedora EPEL 6.
https://admin.fedoraproject.org/updates/golang-github-gorilla-context-0-0.15.git708054d.el6

Comment 42 Fedora Update System 2013-10-07 23:00:52 UTC
golang-github-gorilla-context-0-0.17.git708054d.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/golang-github-gorilla-context-0-0.17.git708054d.fc20

Comment 43 Fedora Update System 2013-10-07 23:08:54 UTC
golang-github-gorilla-context-0-0.17.git708054d.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/golang-github-gorilla-context-0-0.17.git708054d.fc19

Comment 44 Fedora Update System 2013-10-07 23:20:44 UTC
golang-github-gorilla-context-0-0.17.git708054d.el6 has been submitted as an update for Fedora EPEL 6.
https://admin.fedoraproject.org/updates/golang-github-gorilla-context-0-0.17.git708054d.el6

Comment 45 Fedora Update System 2013-10-08 04:04:40 UTC
golang-github-gorilla-mux-0-0.7.gite718e93.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/golang-github-gorilla-mux-0-0.7.gite718e93.fc19

Comment 46 Fedora Update System 2013-10-08 21:52:20 UTC
golang-github-gorilla-context-0-0.18.git708054d.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/golang-github-gorilla-context-0-0.18.git708054d.fc20

Comment 47 Fedora Update System 2013-10-08 21:59:14 UTC
golang-github-gorilla-context-0-0.18.git708054d.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/golang-github-gorilla-context-0-0.18.git708054d.fc19

Comment 48 Fedora Update System 2013-10-08 22:32:09 UTC
golang-github-gorilla-context-0-0.18.git708054d.el6 has been submitted as an update for Fedora EPEL 6.
https://admin.fedoraproject.org/updates/golang-github-gorilla-context-0-0.18.git708054d.el6

Comment 49 Fedora Update System 2013-10-17 03:54:52 UTC
golang-github-gorilla-context-0-0.19.git708054d.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/golang-github-gorilla-context-0-0.19.git708054d.fc20

Comment 50 Fedora Update System 2013-10-17 04:01:53 UTC
golang-github-gorilla-context-0-0.19.git708054d.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/golang-github-gorilla-context-0-0.19.git708054d.fc19

Comment 51 Fedora Update System 2013-10-17 04:13:07 UTC
golang-github-gorilla-context-0-0.19.git708054d.el6 has been submitted as an update for Fedora EPEL 6.
https://admin.fedoraproject.org/updates/golang-github-gorilla-context-0-0.19.git708054d.el6

Comment 52 Fedora Update System 2013-10-17 18:08:00 UTC
Package golang-github-gorilla-context-0-0.19.git708054d.el6:
* should fix your issue,
* was pushed to the Fedora EPEL 6 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=epel-testing golang-github-gorilla-context-0-0.19.git708054d.el6'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-11872/golang-github-gorilla-context-0-0.19.git708054d.el6
then log in and leave karma (feedback).

Comment 53 Fedora Update System 2013-10-19 00:50:20 UTC
golang-github-gorilla-mux-0-0.9.gite718e93.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/golang-github-gorilla-mux-0-0.9.gite718e93.fc19

Comment 54 Peter Lemenkov 2013-10-23 11:08:03 UTC
Package Change Request
======================
Package Name: golang-github-gorilla-context
InitialCC: golang-sig

Comment 55 Gwyn Ciesla 2013-10-23 13:59:56 UTC
Done.

Comment 56 Fedora Update System 2013-10-29 03:37:41 UTC
golang-github-gorilla-context-0-0.19.git708054d.fc19 has been pushed to the Fedora 19 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 57 Fedora Update System 2013-10-29 03:38:46 UTC
golang-github-gorilla-mux-0-0.9.gite718e93.fc19 has been pushed to the Fedora 19 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 58 Fedora Update System 2013-11-01 21:08:35 UTC
golang-github-gorilla-context-0-0.19.git708054d.el6 has been pushed to the Fedora EPEL 6 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 59 Fedora Update System 2013-11-10 07:46:36 UTC
golang-github-gorilla-context-0-0.19.git708054d.fc20 has been pushed to the Fedora 20 stable repository.  If problems still persist, please make note of it in this bug report.


Note You need to log in before you can comment on or make changes to this bug.