Bug 1126100

Hello,

This is my first (hopefully of many) packages, so I am looking for a sponsor.
I have a scratch build completed for both epel7 and f20:

F20:
http://koji.fedoraproject.org/koji/taskinfo?taskID=7229686

EPEL7:
http://koji.fedoraproject.org/koji/taskinfo?taskID=7229296

Disco website: http://discoproject.org

Thanks!
Tait

Rewriting part of the spec file, will update the ticket when I have the new scratch builds.

Updated spec and SRPM are at the original URLs.

Scratch builds:

F20:
http://koji.fedoraproject.org/koji/taskinfo?taskID=7233822

EPEL7:
http://koji.fedoraproject.org/koji/taskinfo?taskID=7233845

1. Drop these 2:

BuildRoot: %{_tmppath}/disco-%{version}-root
Vendor: Disco Authors

Ref: https://fedoraproject.org/wiki/Packaging:Guidelines#Tags

2. All Group: could be dropped as well, as Fedora doesn't need them anymore.

3. Drop obsoleted stuffs:

BuildRoot: %{_tmppath}/disco-%{version}-root

%clean

%defattr(-,root,root)

4. %{__make} -> make
%{_prefix}/bin -> %{_bindir}
%{_prefix}/share -> %{_datadir}
== -> =
%setup -n disco -> %setup -q -n disco

5. cp bin/disco bin/ddfs $RPM_BUILD_ROOT/%{_prefix}/bin

Use install -pm755 to set perms instead of %attr(0755,root,root), the latter one has been abused too much.

6. DISCO_VERSION=%{version}  %{__python} setup.py install -O1 --root=$RPM_BUILD_ROOT

https://fedoraproject.org/wiki/Packaging:Python#Macros

Please set PYTHON to %{__python2} explicitly.

7. %dir %{_prefix}/var/disco
%dir %{_prefix}/lib/disco

Violates FHS.

8. Add %global debug_package %{nil} to the erlang package.

9. Drop the dot:

Summary:  An open-source mapreduce framework.

Not completed, but you should fix them. Basically, not good.

Hi Christopher,

I will read over the Packaging Guidelines carefully, I appreciate you taking the time to give me some pointers and corrections and will update the spec accordingly.

Tait

Hi Tait,
  note that rpm spec files have become a lot saner with time and some of the changes reflect precisely that. An example, why should the BuildRoot be defined in the spec files?

In another case (6) it all comes to the fact that soon we will change our default version of python from 2 to 3 and thus it is better to be explicit and declare what is the version really used. Before python 3 this was not an issue.

In the case of the summary the convention is not to end the sentence with a dot.

So there are reasons for all the changes required and the documentation is thorough, feel free to peruse it. :-)

One advice it to try to build your packages using fedora-review, it is just a program and it does not replace human reasoning but it is a nice starting point. At the same time try to review other submissions to increase your fluency in rpm spec.

I am a sponsor and as you can read the informal review of others request is a major point for approval.

Hi Jose,

I completely understand the reasoning for the peer review process and how important it is to maintain standards. I really appreciate both you and Christopher taking the time to assist me and point out where I need work. Always willing to learn, and I have been reading the guidelines while going through the spec I changed line by line. I'll also take a look at other submissions (maybe for packages I have done "in-house") and learn from those too.

Thanks!
Tait

The purpose of my message was supposed to be lighthearted. :-)

And somehow it missed that tone as I wrote.

What you have is a nice starting point and you can count on us to help. If it sounded other way than that it was my fault. :-)

Don't worry, I read all the messages so far as lighthearted and friendly assistance :)

Mine were too, just emphasizing the gratefulness for the help and pointers because of the importance of packaging correctly. Sorry if mine came off as combative, they were not meant to be!

As for some packaging questions:

For the disco dependencies, they use specific versions of erlang modules and thus were put into a special directory. Would it be OK if I follow the erlang package in putting disco code into /usr/lib64/erlang/lib/disco-%{version} where normal packages have the directory structure of /{ebin,include,priv,src} but disco would be /master/{deps,ebin}?

Found http://fedoraproject.org/wiki/User:Peter/Erlang_Packaging_Guidelines. Will abide by that for the Erlang side of things.

Ran fedora-review (amazing tool by the way!) and went through as much as I could see as being an issue. I also updated my dev box to rawhide.

Rpmlint
-------
Checking: disco-0.5.3-1.fc22.x86_64.rpm
          disco-master-0.5.3-1.fc22.x86_64.rpm
          python-disco-0.5.3-1.fc22.x86_64.rpm
          disco-cli-0.5.3-1.fc22.x86_64.rpm
          disco-0.5.3-1.fc22.src.rpm
disco.x86_64: E: no-binary
disco.x86_64: W: only-non-binary-in-usr-lib
disco-master.x86_64: W: no-documentation
disco.src: W: invalid-url Source0: disco.tar.gz
5 packages and 0 specfiles checked; 1 errors, 3 warnings.

* W: invalid-url Source0: disco.tar.gz - There is a comment in the spec file regarding this warning, disco requires the git repository to set the version for the erlang package from the gitlog.

* E: no-binary - I've seen in some other erlang related packages, no-binary can be safely ignored as it is arch dependant for %{_libdir} (see bug 906473 comment 2). 

Also, in the Erlang guidelines it was asked that any erlang package have erlang-%{name}, but in this case I chose to leave it as disco as it is more of a standalone application and not one people would include in their own apps.

I have not tested disco running on anything other than x86_64 and i686, should these arches be the only ones specified? I can try emulating arm as well and seeing if they run as expected as well.

Spec URL: https://github.com/oldmantaiter/fedpkg/raw/master/disco/disco.spec
SRPM URL: https://github.com/oldmantaiter/fedpkg/raw/master/disco/disco-0.5.3-1.fc22.src.rpm

Koji scratch build for rawhide:
http://koji.fedoraproject.org/koji/taskinfo?taskID=7246422

Thanks!

Oops. Time really flies... :-)

Are you still interested in being sponsored?

https://fedoraproject.org/wiki/How_to_get_sponsored_into_the_packager_group#Sponsorship_model

If so I will help you to go through all the stages to become a packager.

I am definitely still interested, but I am on vacation until August 17th so I will respond when I'm back and can take the time to properly go through the steps.

Thanks for offering to sponsor me, I am looking forward to learning with your guidance and getting to a point where I am able to contribute.

Sure. :-)
I will be away next week so take your time. :-)

This is an automatic check from review-stats script.

This review request ticket hasn't been updated for some time, but it seems
that the review is still being working out by you. If this is right, please
respond to this comment clearing the NEEDINFO flag and try to reach out the
submitter to proceed with the review.

If you're not interested in reviewing this ticket anymore, please clear the
fedora-review flag and reset the assignee, so that a new reviewer can take
this ticket.

Without any reply, this request will shortly be resetted.

I will close this since it is opened for so long.

Feel free to reopen it if you interested in getting this process to continue.