[Bug 1301143] Review Request: skopeo - Get information about Docker images without pulling them

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1301143

Lokesh Mandvekar  changed:

   What|Removed |Added

 Status|ASSIGNED|CLOSED
 Resolution|--- |RAWHIDE
Last Closed||2016-04-02 00:35:50



-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are always notified about changes to this product and component
___
package-review mailing list
package-review@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/package-review

[Bug 1301143] Review Request: skopeo - Get information about Docker images without pulling them

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1301143



--- Comment #26 from Jon Ciesla  ---
Package request has been approved:
https://admin.fedoraproject.org/pkgdb/package/skopeo

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are always notified about changes to this product and component
___
package-review mailing list
package-review@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/package-review

[Bug 1301143] Review Request: skopeo - Get information about Docker images without pulling them

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1301143

Jason Tibbitts  changed:

   What|Removed |Added

 Blocks|177841 (FE-NEEDSPONSOR) |




Referenced Bugs:

https://bugzilla.redhat.com/show_bug.cgi?id=177841
[Bug 177841] Tracker: Review requests from new Fedora packagers who need a
sponsor
-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are always notified about changes to this product and component
___
package-review mailing list
package-review@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/package-review

[Bug 1301143] Review Request: skopeo - Get information about Docker images without pulling them

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1301143

Nalin Dahyabhai  changed:

   What|Removed |Added

 Blocks||177841 (FE-NEEDSPONSOR)




Referenced Bugs:

https://bugzilla.redhat.com/show_bug.cgi?id=177841
[Bug 177841] Tracker: Review requests from new Fedora packagers who need a
sponsor
-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are always notified about changes to this product and component
___
package-review mailing list
package-review@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/package-review

[Bug 1301143] Review Request: skopeo - Get information about Docker images without pulling them

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1301143



--- Comment #23 from Upstream Release Monitoring 
 ---
runcom's scratch build of skopeo-0.1.4-1.fc23.src.rpm for f23 completed
http://koji.fedoraproject.org/koji/taskinfo?taskID=12786664

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are always notified about changes to this product and component
___
package-review mailing list
package-review@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/package-review

[Bug 1301143] Review Request: skopeo - Get information about Docker images without pulling them

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1301143



--- Comment #24 from Antonio Murdaca  ---
Updated everything and it should be good to go:

Spec URL:
https://raw.githubusercontent.com/runcom/fedora-pkgs/master/skopeo/fedora/skopeo/skopeo.spec
SRPM URL:
https://github.com/runcom/fedora-pkgs/raw/master/skopeo/fedora/skopeo/skopeo-0.1.4-1.fc23.src.rpm

Koji builds:

- f23: http://koji.fedoraproject.org/koji/taskinfo?taskID=12786664
- rawhide: http://koji.fedoraproject.org/koji/taskinfo?taskID=12786653

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are always notified about changes to this product and component
___
package-review mailing list
package-review@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/package-review

[Bug 1301143] Review Request: skopeo - Get information about Docker images without pulling them

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1301143



--- Comment #25 from Nalin Dahyabhai  ---
Yup, looks good from here.  Thanks!

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are always notified about changes to this product and component
___
package-review mailing list
package-review@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/package-review

[Bug 1301143] Review Request: skopeo - Get information about Docker images without pulling them

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1301143

Jan Chaloupka  changed:

   What|Removed |Added

 CC||amurd...@redhat.com
  Flags||needinfo?(amurdaca@redhat.c
   ||om)



--- Comment #19 from Jan Chaloupka  ---
After reading [1] I can not figure out why is GO15VENDOREXPERIMENT env needed.
Can you help me to understand?

[1]
https://docs.google.com/document/d/1Bz5-UB7g2uPBdOx-rw5t9MxJwkfpx90cqG9AFL0JAYo/edit

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are always notified about changes to this product and component
___
package-review mailing list
package-review@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/package-review

[Bug 1301143] Review Request: skopeo - Get information about Docker images without pulling them

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1301143

Antonio Murdaca  changed:

   What|Removed |Added

  Flags|needinfo?(amurdaca@redhat.c |
   |om) |



--- Comment #20 from Antonio Murdaca  ---
(In reply to Jan Chaloupka from comment #19)
> After reading [1] I can not figure out why is GO15VENDOREXPERIMENT env
> needed. Can you help me to understand?
> 
> [1]
> https://docs.google.com/document/d/1Bz5-UB7g2uPBdOx-
> rw5t9MxJwkfpx90cqG9AFL0JAYo/edit

Quoting from the doc:

This change will only be enabled if the go command is run with
GO15VENDOREXPERIMENT=1 in its environment.

So, the behavior of looking into $pwd/vendor/... instead of resolving deps from
$GOPATH is only enabled if you pass that env variable - otherwise it uses
$GOPATH (and maybe $GOROOT). This is in go1.5, eventually we will have this as
the default behavior in go1.6, from the doc:

If we decide that the vendor behavior is correct, then in a later release
(possibly Go 1.6) we would make the vendor behavior default on. Projects
containing “vendor” directories could still use “GO15VENDOREXPERIMENT=0” to get
the old behavior while they convert their code. In a still later release
(possibly Go 1.7) we would remove the use of the environment variable, locking
in the vendoring semantics.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are always notified about changes to this product and component
___
package-review mailing list
package-review@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/package-review

[Bug 1301143] Review Request: skopeo - Get information about Docker images without pulling them

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1301143



--- Comment #16 from Antonio Murdaca  ---
(In reply to Nalin Dahyabhai from comment #15)
> runcom is not currently in the packagers group; I can sponsor.
> 
> I've got questions about the license tag when we're bundling, and could
> probably use some clarification about whether or not, and if so, how many,
> of the vendored modules need to be debundled for Fedora.  Otherwise it looks
> pretty straightforward from here.
> 
> fedora-review output:
> 
> Package Review
> ==
> 
> Legend:
> [x] = Pass, [!] = Fail, [-] = Not applicable, [?] = Not evaluated
> [ ] = Manual review needed
> 
> Issues:
> ===
> - Sources used to build the package match the upstream source, as provided
>   in the spec URL.
>   See: http://fedoraproject.org/wiki/Packaging/SourceURL
> 
>   Since you're keeping a .spec file in the repository, I expect you'll be
> keeping it more or less in sync with the one being used for Fedora, so no
> worries there.

I've created https://github.com/runcom/fedora-pkgs where I do have .spec(s) and
SRPM(s)
I'm planning to remove the .spec from the source repo and maintain the .spec at
https://github.com/runcom/fedora-pkgs/tree/master/skopeo/fedora/skopeo

> 
>   The source tarball in the SRPM contained the .git directory and copies of
> generated files, including the binary, which is rather odd.  How was it
> generated?  Will future versions of the package do this as well?

Probably a mistake - I've regenerated the SRPM and it's available at
https://github.com/runcom/fedora-pkgs/raw/master/skopeo/fedora/skopeo/skopeo-0.1.4-1.fc23.src.rpm
It does not contain .git nor binaries anymore.

> 
> - Package uses either %{buildroot} or $RPM_BUILD_ROOT
>   Note: Using both %{buildroot} and $RPM_BUILD_ROOT
>   See: http://fedoraproject.org/wiki/Packaging/Guidelines#macros
> 
>   Stylistically, it's better to choose either %{buildroot} or
> $RPM_BUILD_ROOT and be consistent about it.  You're not doing anything that
> makes either of them not an option, so use whichever you prefer.

Fixed in
https://raw.githubusercontent.com/runcom/fedora-pkgs/master/skopeo/fedora/skopeo/skopeo.spec

> 
> - If (and only if) the source package includes the text of the license(s)
>   in its own file, then that file, containing the text of the license(s)
>   for the package is included in %license.
>   Note: License file LICENSE is marked as %doc instead of %license
>   See:
>   http://fedoraproject.org/wiki/Packaging/LicensingGuidelines#License_Text
> 
>   The main package tags the LICENSE file as %doc rather than %license, which
> is trivially fixable.

Fixed in
https://raw.githubusercontent.com/runcom/fedora-pkgs/master/skopeo/fedora/skopeo/skopeo.spec

> 
> = MUST items =
> 
> Generic:
> [ ]: Package is licensed with an open-source compatible license and meets
>  other legal requirements as defined in the legal section of Packaging
>  Guidelines.
> 
>  I suspect that linking your MIT-licensed main logic with vendored
> sources from other repositories is going to produce
> 
> https://fedoraproject.org/wiki/Packaging:
> LicensingGuidelines#Mixed_Source_Licensing_Scenario
> 
> [ ]: License field in the package spec file matches the actual license.
>  Note: Checking patched sources after %prep for licenses. Licenses
>  found: "MIT/X11 (BSD like)", "BSD (3 clause)", "*No copyright* Apache
>  (v2.0)", "Unknown or generated", "BSD (2 clause)". 371 files have
>  unknown license. Detailed output of licensecheck in /misc/skopeo
>  /review-skopeo/licensecheck.txt
> 
>  If it's not mixed source, then "License: MIT" is correct.

This license stuff is tricky...I've re-licensed my tool with ASL 2.0 since
all my vendors are ASL 2.0 afaict.

> 
> [x]: %build honors applicable compiler flags or justifies otherwise.
>  Uses %gobuild to invoke the go compiler.
> [ ]: Package contains no bundled libraries without FPC exception.
> 
>  Package bundles several libraries.  Does it need to remove them at the
> end of the %setup section when %{with_bundled} is 0 in order to ensure that
> the compiler picks up the debundled copies?  Doesn't Fedora require
> debundling?

I've added the removal of vendor/ when %{with_bundled} is 0
Right now, unluckily, this tool won't build from debundled vendor's copies, and
also not all vendors are already in Fedora - but I'm working on packaging them
with Lokesh and Jan for a future version

> 
> [x]: Changelog in prescribed format.
> [x]: Sources contain only permissible code or content.
> [-]: Package contains desktop file if it is a GUI application.
> [-]: Development files must be in a -devel package
> [x]: Package uses nothing in %doc for runtime.
> [!]: Package consistently uses macros (instead of hard-coded directory
>  names).
> 
>  The package's makefile hardcodes the install locations, and we don't
> force them to match %{_bindir} and %{_mandir}.

Fixed

> 
> [x]: 

[Bug 1301143] Review Request: skopeo - Get information about Docker images without pulling them

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1301143



--- Comment #18 from Upstream Release Monitoring 
 ---
runcom's scratch build of skopeo-0.1.4-1.fc23.src.rpm for f23 completed
http://koji.fedoraproject.org/koji/taskinfo?taskID=12722010

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are always notified about changes to this product and component
___
package-review mailing list
package-review@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/package-review

[Bug 1301143] Review Request: skopeo - Get information about Docker images without pulling them

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1301143



--- Comment #17 from Antonio Murdaca  ---
New stuff (v0.1.4) after Nalin's review:

Spec URL:
https://raw.githubusercontent.com/runcom/fedora-pkgs/master/skopeo/fedora/skopeo/skopeo.spec
SRPM URL:
https://github.com/runcom/fedora-pkgs/raw/master/skopeo/fedora/skopeo/skopeo-0.1.4-1.fc23.src.rpm

Koji builds:

- f23: http://koji.fedoraproject.org/koji/taskinfo?taskID=12722010
- rawhide: http://koji.fedoraproject.org/koji/taskinfo?taskID=12722004

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are always notified about changes to this product and component
___
package-review mailing list
package-review@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/package-review

[Bug 1301143] Review Request: skopeo - Get information about Docker images without pulling them

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1301143



--- Comment #21 from Nalin Dahyabhai  ---
(In reply to Antonio Murdaca from comment #16)
> I've created https://github.com/runcom/fedora-pkgs where I do have .spec(s)
> and SRPM(s)
> I'm planning to remove the .spec from the source repo and maintain the .spec
> at
> https://github.com/runcom/fedora-pkgs/tree/master/skopeo/fedora/skopeo

FWIW, Fedora's packaging repository will keep its own copy in a branch for each
Fedora release (see repositories at http://pkgs.fedoraproject.org/cgit/rpms/
for examples).

> This license stuff is tricky...I've re-licensed my tool with ASL 2.0 since
> all my vendors are ASL 2.0 afaict.

Yeah, that should be accurate either way.

> I've added the removal of vendor/ when %{with_bundled} is 0
> Right now, unluckily, this tool won't build from debundled vendor's copies,
> and
> also not all vendors are already in Fedora - but I'm working on packaging
> them
> with Lokesh and Jan for a future version

Understood, it's a work in progress.

> should I call `make clean` to remove generated files in a %clean section?

Historically, %clean's job was to clean up $RPM_BUILD_ROOT, way back when even
using a buildroot was optional.  Now that the buildroot is set and cleaned up
by default, Fedora doesn't expect you to have a %clean section.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are always notified about changes to this product and component
___
package-review mailing list
package-review@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/package-review

[Bug 1301143] Review Request: skopeo - Get information about Docker images without pulling them

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1301143



--- Comment #11 from Antonio Murdaca  ---
Jan, Lokesh, I should have fixed everything now.

The only thing which doesn't work is removing the `cd $(pwd)/_build/...)` stuff
in %install (as Jan suggested me to do) because I believe it is tied to
$GO15VENDOREXPERIMENT and "go build" only works with "vendor/" if the current
source being built lives under $GOPATH. (you can try this and see it can't
resolves package dependencies)

I've also tagged a new release (v0.1.3)

Spec URL: https://github.com/runcom/skopeo/blob/master/skopeo.spec
SRPM URL: http://runcom.ninja/skopeo-0.1.3-0.1.gitfdb5cac.fc23.src.rpm

Koji builds:

- f23: http://koji.fedoraproject.org/koji/taskinfo?taskID=12713377
- rawhide: http://koji.fedoraproject.org/koji/taskinfo?taskID=12713364

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are always notified about changes to this product and component
___
package-review mailing list
package-review@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/package-review

[Bug 1301143] Review Request: skopeo - Get information about Docker images without pulling them

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1301143



--- Comment #12 from Upstream Release Monitoring 
 ---
runcom's scratch build of skopeo-0.1.3-1.fc23.src.rpm for f23 completed
http://koji.fedoraproject.org/koji/taskinfo?taskID=12716264

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are always notified about changes to this product and component
___
package-review mailing list
package-review@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/package-review

[Bug 1301143] Review Request: skopeo - Get information about Docker images without pulling them

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1301143



--- Comment #13 from Antonio Murdaca  ---
Pulled in the latest Jan's fixes to the spec (thanks a lot)

Spec URL:
https://raw.githubusercontent.com/runcom/fedora-pkgs/master/skopeo/fedora/skopeo/skopeo.spec
SRPM URL:
https://github.com/runcom/fedora-pkgs/raw/master/skopeo/skopeo-0.1.3-1.fc23.src.rpm

Koji builds:

- f23: http://koji.fedoraproject.org/koji/taskinfo?taskID=12716275
- rawhide: http://koji.fedoraproject.org/koji/taskinfo?taskID=12716276

Thanks for the help guys!

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are always notified about changes to this product and component
___
package-review mailing list
package-review@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/package-review

[Bug 1301143] Review Request: skopeo - Get information about Docker images without pulling them

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1301143



--- Comment #14 from Upstream Release Monitoring 
 ---
runcom's scratch build of skopeo-0.1.3-1.fc23.src.rpm for f23 completed
http://koji.fedoraproject.org/koji/taskinfo?taskID=12716275

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are always notified about changes to this product and component
___
package-review mailing list
package-review@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/package-review

[Bug 1301143] Review Request: skopeo - Get information about Docker images without pulling them

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1301143



--- Comment #15 from Nalin Dahyabhai  ---
runcom is not currently in the packagers group; I can sponsor.

I've got questions about the license tag when we're bundling, and could
probably use some clarification about whether or not, and if so, how many, of
the vendored modules need to be debundled for Fedora.  Otherwise it looks
pretty straightforward from here.

fedora-review output:

Package Review
==

Legend:
[x] = Pass, [!] = Fail, [-] = Not applicable, [?] = Not evaluated
[ ] = Manual review needed

Issues:
===
- Sources used to build the package match the upstream source, as provided
  in the spec URL.
  See: http://fedoraproject.org/wiki/Packaging/SourceURL

  Since you're keeping a .spec file in the repository, I expect you'll be
keeping it more or less in sync with the one being used for Fedora, so no
worries there.

  The source tarball in the SRPM contained the .git directory and copies of
generated files, including the binary, which is rather odd.  How was it
generated?  Will future versions of the package do this as well?

- Package uses either %{buildroot} or $RPM_BUILD_ROOT
  Note: Using both %{buildroot} and $RPM_BUILD_ROOT
  See: http://fedoraproject.org/wiki/Packaging/Guidelines#macros

  Stylistically, it's better to choose either %{buildroot} or $RPM_BUILD_ROOT
and be consistent about it.  You're not doing anything that makes either of
them not an option, so use whichever you prefer.

- If (and only if) the source package includes the text of the license(s)
  in its own file, then that file, containing the text of the license(s)
  for the package is included in %license.
  Note: License file LICENSE is marked as %doc instead of %license
  See:
  http://fedoraproject.org/wiki/Packaging/LicensingGuidelines#License_Text

  The main package tags the LICENSE file as %doc rather than %license, which is
trivially fixable.

= MUST items =

Generic:
[ ]: Package is licensed with an open-source compatible license and meets
 other legal requirements as defined in the legal section of Packaging
 Guidelines.

 I suspect that linking your MIT-licensed main logic with vendored sources
from other repositories is going to produce

https://fedoraproject.org/wiki/Packaging:LicensingGuidelines#Mixed_Source_Licensing_Scenario

[ ]: License field in the package spec file matches the actual license.
 Note: Checking patched sources after %prep for licenses. Licenses
 found: "MIT/X11 (BSD like)", "BSD (3 clause)", "*No copyright* Apache
 (v2.0)", "Unknown or generated", "BSD (2 clause)". 371 files have
 unknown license. Detailed output of licensecheck in /misc/skopeo
 /review-skopeo/licensecheck.txt

 If it's not mixed source, then "License: MIT" is correct.

[x]: %build honors applicable compiler flags or justifies otherwise.
 Uses %gobuild to invoke the go compiler.
[ ]: Package contains no bundled libraries without FPC exception.

 Package bundles several libraries.  Does it need to remove them at the end
of the %setup section when %{with_bundled} is 0 in order to ensure that the
compiler picks up the debundled copies?  Doesn't Fedora require debundling?

[x]: Changelog in prescribed format.
[x]: Sources contain only permissible code or content.
[-]: Package contains desktop file if it is a GUI application.
[-]: Development files must be in a -devel package
[x]: Package uses nothing in %doc for runtime.
[!]: Package consistently uses macros (instead of hard-coded directory
 names).

 The package's makefile hardcodes the install locations, and we don't force
them to match %{_bindir} and %{_mandir}.

[x]: Package is named according to the Package Naming Guidelines.
[x]: Package does not generate any conflict.
[x]: Package obeys FHS, except libexecdir and /usr/target.
[-]: If the package is a rename of another package, proper Obsoletes and
 Provides are present.
[-]: Requires correct, justified where necessary.
[ ]: Spec file is legible and written in American English.

 The package could use a longer %description; I think something along the
lines of the paragraph that starts around line 6 of README.md would work.

[-]: Package contains systemd file(s) if in need.
[ ]: Useful -debuginfo package or justification otherwise.

 Why is %{with_debug} disabled?  Rebuilding it with debuginfo enabled
produces files with names that seem to be of some use to my debugger.

[-]: Package is not known to require an ExcludeArch tag.
[-]: Large documentation must go in a -doc subpackage. Large could be size
 (~1MB) or number of files.
 Note: Documentation size is 20480 bytes in 2 files.
[ ]: Package complies to the Packaging Guidelines

 Aside from questions I have about licensing and bundling, this looks fine.

[x]: Package successfully compiles and builds into binary rpms on at least
 one supported primary architecture.
[x]: Package installs 

[Bug 1301143] Review Request: skopeo - Get information about Docker images without pulling them

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1301143

Nalin Dahyabhai  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 Blocks|177841 (FE-NEEDSPONSOR) |




Referenced Bugs:

https://bugzilla.redhat.com/show_bug.cgi?id=177841
[Bug 177841] Tracker: Review requests from new Fedora packagers who need a
sponsor
-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are always notified about changes to this product and component
___
package-review mailing list
package-review@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/package-review

[Bug 1301143] Review Request: skopeo - Get information about Docker images without pulling them

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1301143



--- Comment #10 from Upstream Release Monitoring 
 ---
runcom's scratch build of skopeo-0.1.3-0.1.git572a6b6.fc23.src.rpm for f23
completed http://koji.fedoraproject.org/koji/taskinfo?taskID=12713132

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are always notified about changes to this product and component
___
package-review mailing list
package-review@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/package-review

[Bug 1301143] Review Request: skopeo - Get information about Docker images without pulling them

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1301143



--- Comment #6 from Jan Chaloupka  ---
Wondering if it would be better to create github repository (e.g.
fedora/golang-reviews) and instead of posting links to spec to post links to
pull request and comment in the PR. Missing feature to comment lines of the
spec file.

Well, the devel subpackage is usefull for analysis. When the devel subpackage
is present, it can be scanned for dependencies and other info about the code.
At the moment we are running simple scans of new builds of golang projects in
Koji. In future, we plan to report missing or broken dependencies. So if you
provide the devel subpackage, you get automatic scans and reports about health
of your package.

Second, I would recommend to add some macro at the top of the spec. E.g.
commit, provider_prefix, import_path. They are used for automatic updates of
spec file (e.g. 'gofed bump') and in analysis (as described above).

Third, you are using 'go build' inside Makefile. So your project can be built
on architectures with golang compiler only. If you move the commands into
%build section, you can use %gobuild macro a gain support for debugingo and
architectures with gcc-go compiler.

You can play with gofed for a while, try to run:
# yum install gofed
$ gofed repo2spec --detect github.com/runcom/skopeo --with-build --with-extra

Bad news is it depends on docker so the devel subpackage will not be complete.
The good new is you can build the project from bundled dependencies.

Lokesh, we should definitely do something about the docker. This is another
project that depends on it. If this is happening we should at least partially
built the package from bundled and partially from debundled deps. At this point
this is out of the question as we are still missing automatic tools that would
do all the hard work for us.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are always notified about changes to this product and component
___
package-review mailing list
package-review@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/package-review

[Bug 1301143] Review Request: skopeo - Get information about Docker images without pulling them

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1301143



--- Comment #9 from Jan Chaloupka  ---
Some of them are already packaged, just with a different name.

> should this binary have a golang(...)-like name resolvable via golang(...)
> macro? 

No. golang(...) virtual provides is used only for dependencies

> I've read golang binaries can be named without golang-github-* prefix so
> this won't suffer from renaming

Yeap. It can be named anyway you wish. All projects packaged in fedora with
intent to provide at least one binary are named by repository. The standard way
is to use project name.

> (also this do not provide a devel package)

As I mentioned above. At least you can provide devel package with no
[Build]Requires for sake of analysis. The generated spec file already provides
all code necessary. Just with some small modifications.

> but just let me know and I'll move the repository as fast as I can
> and fix what's needed

If you use generated macros, it is two-liner fix

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are always notified about changes to this product and component
___
package-review mailing list
package-review@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/package-review

[Bug 1301143] Review Request: skopeo - Get information about Docker images without pulling them

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1301143



--- Comment #8 from Antonio Murdaca  ---
(In reply to Jan Chaloupka from comment #7)
> btw. a lot of new dependencies :)
> 
> $ gofed repo2spec --detect github.com/runcom/skopeo --with-build --with-extra
> Repo URL: github.com/runcom/skopeo
> Commit: 572a6b6f537d71f7cabfdcfe185c6d7cb4367272
> Name: golang-github-runcom-skopeo
> 
> (1/4) Checking if the package already exists in PkgDB
> (2/4) Downloading tarball
> (3/4) Generating spec file
> (4/4) Discovering golang dependencies
> Class: github.com/Azure/go-ansiterm (golang-github-Azure-go-ansiterm)
> PkgDB=False
> Class: github.com/Sirupsen/logrus (golang-github-Sirupsen-logrus) PkgDB=True
> Class: github.com/codegangsta/cli (golang-github-codegangsta-cli) PkgDB=True
> Class: github.com/docker/distribution (golang-github-docker-distribution)
> PkgDB=False
> Class: github.com/docker/docker (docker) PkgDB=False
> Class: github.com/docker/engine-api (golang-github-docker-engine-api)
> PkgDB=False
> Class: github.com/docker/go-connections
> (golang-github-docker-go-connections) PkgDB=False
> Class: github.com/docker/go-units (golang-github-docker-go-units) PkgDB=False
> Class: github.com/docker/libtrust (golang-github-docker-libtrust) PkgDB=True
> Class: github.com/go-check/check (golang-github-go-check-check) PkgDB=False
> Class: github.com/gorilla/context (golang-github-gorilla-context) PkgDB=True
> Class: github.com/gorilla/mux (golang-github-gorilla-mux) PkgDB=True
> Class: github.com/opencontainers/runc (golang-github-opencontainers-runc)
> PkgDB=False
> Class: github.com/vbatts/tar-split (golang-github-vbatts-tar-split)
> PkgDB=False
> Class: golang.org/x/net (golang-googlecode-net) PkgDB=True
> 
> Spec file golang-github-runcom-skopeo.spec at
> /home/jchaloup/Packages/reviews/skopeo/golang-github-runcom-skopeo/fedora/
> golang-github-runcom-skopeo

Yes, those new dependencies come from the master branch, I can tag a new
release and add all those dependencies :)

(In reply to Jan Chaloupka from comment #6)
> Wondering if it would be better to create github repository (e.g.
> fedora/golang-reviews) and instead of posting links to spec to post links to
> pull request and comment in the PR. Missing feature to comment lines of the
> spec file.
> 
> Well, the devel subpackage is usefull for analysis. When the devel
> subpackage is present, it can be scanned for dependencies and other info
> about the code. At the moment we are running simple scans of new builds of
> golang projects in Koji. In future, we plan to report missing or broken
> dependencies. So if you provide the devel subpackage, you get automatic
> scans and reports about health of your package.
> 
> Second, I would recommend to add some macro at the top of the spec. E.g.
> commit, provider_prefix, import_path. They are used for automatic updates of
> spec file (e.g. 'gofed bump') and in analysis (as described above).
> 
> Third, you are using 'go build' inside Makefile. So your project can be
> built on architectures with golang compiler only. If you move the commands
> into %build section, you can use %gobuild macro a gain support for debugingo
> and architectures with gcc-go compiler.
> 
> You can play with gofed for a while, try to run:
> # yum install gofed
> $ gofed repo2spec --detect github.com/runcom/skopeo --with-build --with-extra
> 
> Bad news is it depends on docker so the devel subpackage will not be
> complete. The good new is you can build the project from bundled
> dependencies.
> 
> Lokesh, we should definitely do something about the docker. This is another
> project that depends on it. 

> If this is happening we should at least
> partially built the package from bundled and partially from debundled deps.

This is what I'm actually doing - I'm removing each bundled deps with rm -rf
/vendor and just leave under vendor the ones from docker which cannot be
debundled :)

> At this point this is out of the question as we are still missing automatic
> tools that would do all the hard work for us.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are always notified about changes to this product and component
___
package-review mailing list
package-review@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/package-review

[Bug 1301143] Review Request: skopeo - Get information about Docker images without pulling them

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1301143



--- Comment #7 from Jan Chaloupka  ---
btw. a lot of new dependencies :)

$ gofed repo2spec --detect github.com/runcom/skopeo --with-build --with-extra
Repo URL: github.com/runcom/skopeo
Commit: 572a6b6f537d71f7cabfdcfe185c6d7cb4367272
Name: golang-github-runcom-skopeo

(1/4) Checking if the package already exists in PkgDB
(2/4) Downloading tarball
(3/4) Generating spec file
(4/4) Discovering golang dependencies
Class: github.com/Azure/go-ansiterm (golang-github-Azure-go-ansiterm)
PkgDB=False
Class: github.com/Sirupsen/logrus (golang-github-Sirupsen-logrus) PkgDB=True
Class: github.com/codegangsta/cli (golang-github-codegangsta-cli) PkgDB=True
Class: github.com/docker/distribution (golang-github-docker-distribution)
PkgDB=False
Class: github.com/docker/docker (docker) PkgDB=False
Class: github.com/docker/engine-api (golang-github-docker-engine-api)
PkgDB=False
Class: github.com/docker/go-connections (golang-github-docker-go-connections)
PkgDB=False
Class: github.com/docker/go-units (golang-github-docker-go-units) PkgDB=False
Class: github.com/docker/libtrust (golang-github-docker-libtrust) PkgDB=True
Class: github.com/go-check/check (golang-github-go-check-check) PkgDB=False
Class: github.com/gorilla/context (golang-github-gorilla-context) PkgDB=True
Class: github.com/gorilla/mux (golang-github-gorilla-mux) PkgDB=True
Class: github.com/opencontainers/runc (golang-github-opencontainers-runc)
PkgDB=False
Class: github.com/vbatts/tar-split (golang-github-vbatts-tar-split) PkgDB=False
Class: golang.org/x/net (golang-googlecode-net) PkgDB=True

Spec file golang-github-runcom-skopeo.spec at
/home/jchaloup/Packages/reviews/skopeo/golang-github-runcom-skopeo/fedora/golang-github-runcom-skopeo

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are always notified about changes to this product and component
___
package-review mailing list
package-review@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/package-review

[Bug 1301143] Review Request: skopeo - Get information about Docker images without pulling them

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1301143



--- Comment #2 from Antonio Murdaca  ---
I've released a new version, and I've made sure distro-supplied golang libs are
used when possible (in spec), the only leftover are (from gofed):

Class: github.com/docker/distribution (golang-github-docker-distribution)
PkgDB=False
Class: github.com/docker/docker (docker) PkgDB=False
Class: github.com/docker/engine-api (golang-github-docker-engine-api)
PkgDB=False

---

Spec URL: https://github.com/runcom/skopeo/blob/v0.1.2/skopeo.spec
SRPM URL: http://runcom.ninja/skopeo-0.1.2-0.fc23.src.rpm

Koji builds:

- f23: http://koji.fedoraproject.org/koji/taskinfo?taskID=12661579
- rawhide: http://koji.fedoraproject.org/koji/taskinfo?taskID=12661563

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are always notified about changes to this product and component
___
package-review mailing list
package-review@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/package-review

[Bug 1301143] Review Request: skopeo - Get information about Docker images without pulling them

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1301143



--- Comment #3 from Upstream Release Monitoring 
 ---
runcom's scratch build of skopeo-0.1.2-0.fc23.src.rpm for rawhide completed
http://koji.fedoraproject.org/koji/taskinfo?taskID=12661563

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are always notified about changes to this product and component
___
package-review mailing list
package-review@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/package-review

[Bug 1301143] Review Request: skopeo - Get information about Docker images without pulling them

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1301143



--- Comment #1 from Upstream Release Monitoring 
 ---
runcom's scratch build of skopeo-0.1.1-1.fc23.src.rpm for f23 completed
http://koji.fedoraproject.org/koji/taskinfo?taskID=12661477

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are always notified about changes to this product and component
___
package-review mailing list
package-review@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/package-review

[Bug 1301143] Review Request: skopeo - Get information about Docker images without pulling them

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1301143

Lokesh Mandvekar  changed:

   What|Removed |Added

 CC||dwa...@redhat.com



--- Comment #4 from Lokesh Mandvekar  ---
Ohh btw, I feel it'd be best first moved to projectatomic github before we go
ahead with approving this, the only reason being moving from @runcom to
@projectatomic would result in changing golang(github.com/runcom/skopeo) to
golang(github.com/projectatomic/skopeo) in the golang paths provided, not too
big a deal, but imho something best decided beforehand.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are always notified about changes to this product and component
___
package-review mailing list
package-review@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/package-review

[Bug 1301143] Review Request: skopeo - Get information about Docker images without pulling them

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1301143



--- Comment #5 from Antonio Murdaca  ---
(In reply to Lokesh Mandvekar from comment #4)
> Ohh btw, I feel it'd be best first moved to projectatomic github before we
> go ahead with approving this, the only reason being moving from @runcom to
> @projectatomic would result in changing golang(github.com/runcom/skopeo) to
> golang(github.com/projectatomic/skopeo) in the golang paths provided, not
> too big a deal, but imho something best decided beforehand.

should this binary have a golang(...)-like name resolvable via golang(...)
macro? I've read golang binaries can be named without golang-github-* prefix so
this won't suffer from renaming (also this do not provide a devel package) but
just let me know and I'll move the repository as fast as I can and fix what's
needed

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are always notified about changes to this product and component
___
package-review mailing list
package-review@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/package-review

[Bug 1301143] Review Request: skopeo - Get information about Docker images without pulling them

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1301143

Lokesh Mandvekar  changed:

   What|Removed |Added

 CC||jchal...@redhat.com,
   ||l...@redhat.com
   Assignee|nob...@fedoraproject.org|na...@redhat.com



-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are always notified about changes to this product and component
___
package-review mailing list
package-review@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/package-review

[Bug 1301143] Review Request: skopeo - Get information about Docker images without pulling them

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1301143

Lokesh Mandvekar  changed:

   What|Removed |Added

 Blocks||177841 (FE-NEEDSPONSOR)
  Flags||fedora-review?




Referenced Bugs:

https://bugzilla.redhat.com/show_bug.cgi?id=177841
[Bug 177841] Tracker: Review requests from new Fedora packagers who need a
sponsor
-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are always notified about changes to this product and component
___
package-review mailing list
package-review@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/package-review