Hi.

1. [!]: MUST Package does not run rm -rf %{buildroot} (or $RPM_BUILD_ROOT) at the
     beginning of %install.

2. Add COPYING MANIFEST and README to %files section like %doc.

3. rpmlint error:
    sugar-kuku.noarch: E: script-without-shebang /usr/share/sugar/activities/KukuAnakula.activity/kuku_config.py

Please correct this and check with fedora-review.

Review:

+ koji scratch build ->http://koji.fedoraproject.org/koji/taskinfo?taskID=4246775

- rpmlint on rpms gave
sugar-kuku.noarch: W: no-documentation
sugar-kuku.noarch: E: script-without-shebang /usr/share/sugar/activities/KukuAnakula.activity/kuku_config.py
2 packages and 0 specfiles checked; 1 errors, 1 warnings.

+ Source verified with upstream as (sha1sum)
a424a2ed5995262aa88f2a926f06348f2b8f64fd  kuku_anakula-4.xo
a424a2ed5995262aa88f2a926f06348f2b8f64fd  ../SOURCES/kuku_anakula-4.xo

- License is GPLv3.


suggestions:
1) Change the license tag to GPLv3+
https://fedoraproject.org/wiki/Packaging:LicensingGuidelines#.22or_later_version.22_licenses

2) Remove the following lines from spec
rm -rf $RPM_BUILD_ROOT
and 
%defattr(-,root,root,-)

3)Good to add documentation files as suggested in above comment.

4) fix the rpmlint error by using
http://fedoraproject.org/wiki/PackageMaintainers/Packaging_Tricks#Add_shebang
in %prep.

Fixed all suggestions

http://snavin.fedorapeople.org/packages/sugar-kuku/sugar-kuku.spec

http://snavin.fedorapeople.org/packages/sugar-kuku/sugar-kuku-4-4.fc17.src.rpm

Remove %defattr(-,root,root,-)

forgot the %defattr(-,root,root,-). fixed it

http://snavin.fedorapeople.org/packages/sugar-kuku/sugar-kuku.spec

http://snavin.fedorapeople.org/packages/sugar-kuku/sugar-kuku-4-5.fc17.src.rpm

I can still see defattr in spec

also, start reviewing other packages. This will help you to get sponsorship soon.

my bad forget to delete the entry but modify the changedlog

http://snavin.fedorapeople.org/packages/sugar-kuku/sugar-kuku.spec

http://snavin.fedorapeople.org/packages/sugar-kuku/sugar-kuku-4-6.fc17.src.rpm

do i need to run fedora-review on my system when I am reviewing a package?

i try to run the fedora-review on my own package but could not get an result.
looking for a guide.
i used the following format.

$fedora-review - <bug-number>

fedora-review -b <bug-number>

And read man fedora-review.

I am still not in support for any automated tool for a package review. Good to look package manually and learn the packaging by finding problems and suggesting solutions.

Recent update looks Ok.

Package APPROVED.

Thanks Parag
Btw, i was wondering how comment#10 like report produce?

why you revoked the fedora-review+ flag? Don't want me to review this package?

I have never used fedora-review.

i think it was happened when we both commented at the same time.

i did not purposely change or revoked the fedora-review+ flag.

i was suppose to reply to your comment#11. Really sorry for the incontinence.

Ok. Please read http://fedoraproject.org/wiki/How_to_get_sponsored_into_the_packager_group#Reviewing_packages and do unofficial reviews.

fedora‑cvs if not active for me and i can't set fedora-cvs flag to "?"

'If you are newly sponsored member of the Fedora Packager group you might have to wait an hour before you will get the permission to set the flag in Bugzilla as the sync is done hourly.'

i was waiting for few hours :)

previous comment should be correct as follows

fedora‑cvs is not active for me and i can't set fedora-cvs flag to "?

Hi,
  I have not yet sponsored you. That is why the next step I asked to do reviews. Once you do sufficient say 5 different in detail package reviews, I will sponsor you. That is reason I have not yet removed FE-NEEDSPONSOR flag from this bug.

Once you get sponsored, you will get email about that. Accepting review is different that getting sponsored. 

Read "Although FE-NEEDSPONSOR is set on the package's review request, it is the person that needs to be sponsored into the packager group, not the package. The package undergoes a review and approval that is separate from someone sponsoring you." from http://fedoraproject.org/wiki/How_to_get_sponsored_into_the_packager_group#Submitting_quality_new_packages

i got a mail that saying 

'Thank you for applying for the packager group.

Welcome to the Fedora packager group. Please continue the process from: https://fedoraproject.org/wiki/PackageMaintainers/Join#Add_Package_to_Source_Code_Management_.28SCM.29_system_and_Set_Owner'

01. Do I need to set the FE-NEEDSPONSOR flag in each bug I create? I am keep packaging.

just now created the bug 841239

02. I try my best to work on reviews but my mail target was helping both Sugar and Fedora communities get most of activities packaged. :)
Since this not personally affecting me as this is just the way i spent my free time but not for my day job i may put less priority for reviewing.
But i do respect community formalities and the culture. :)

Thanks Parag & Vasiliy

The Sponsor who want to sponsor contributor need to add his fas name in packager group. As I will sponsor you, I have added your request for packager group and you got automatic email notification. When I will move this request to Sponsored then you will again get one more automatic email that you have been sponsored.

As you want to create more review requests and I decided to sponsor you provided you will do in detail full package review, I will remove FE-NEEDSPONSOR from existing reviews and you don't need to add it for other reviews. 

But if other reviews get approved in meantime, you still unable to request cvs flag for them.

So, Do some reviews and tell me here.

anyway how these approved packages moving to build system?

and can i use the koji?

and why I can't run fedora-review against this approved bug?

I have try to review my own package, just for testing.
But I do not get proper report.

This the result.

fedora-review -b 840551
Processing bugzilla bug: 840551
Bugzilla v0.7.0 initializing
Chose subclass RHBugzilla v0.1
Trying bugzilla cookies for authentication
Getting .spec and .srpm Urls from : 840551
  --> SRPM url: http://snavin.fedorapeople.org/packages/sugar-kuku/sugar-kuku-4-6.fc17.src.rpm
  --> Spec url: http://snavin.fedorapeople.org/packages/sugar-kuku/sugar-kuku.spec
Using review directory: /home/danishka/rpmbuild/840551-sugar-kuku
Downloading .spec and .srpm files
Downloading (Source0): http://mirrors.mit.edu/sugarlabs/activities/4526/kuku_anakula-4.xo
Running checks and generate report

Rebuilding /home/danishka/rpmbuild/840551-sugar-kuku/srpm/sugar-kuku-4-6.fc17.src.rpm using default root
ERROR: Exception(/home/danishka/rpmbuild/840551-sugar-kuku/srpm/sugar-kuku-4-6.fc17.src.rpm) Config(fedora-17-x86_64) 0 minutes 0 seconds
INFO: Results and/or logs in: /home/danishka/rpmbuild/840551-sugar-kuku/results
ERROR: Command failed. See logs for output.
Build failed rc = Build error(s)
Exception down the road...
[danishka@localhost rpmbuild]$ cat /home/danishka/rpmbuild/840551-sugar-kuku/results/
build.log  root.log   state.log 
[danishka@localhost rpmbuild]$ cat /home/danishka/rpmbuild/840551-sugar-kuku/results/build.log
Mock Version: 1.1.22
[danishka@localhost rpmbuild]$ cat /home/danishka/rpmbuild/840551-sugar-kuku/results/root.log
INFO backend.py:928:  Mock Version: 1.1.22
DEBUG backend.py:286:  rootdir = /var/lib/mock/fedora-17-x86_64/root/
DEBUG backend.py:287:  resultdir = /home/danishka/rpmbuild/840551-sugar-kuku/results
INFO backend.py:290:  calling preinit hooks
DEBUG util.py:57:  ensuring that dir exists: /var/cache/mock/fedora-17-x86_64/root_cache/
DEBUG util.py:307:  Executing command: ['tar', '--use-compress-program', 'pigz', '-xf', '/var/cache/mock/fedora-17-x86_64/root_cache/cache.tar.gz', '-C', '/var/lib/mock/fedora-17-x86_64/root/'] with env {'LANG': 'en_US.UTF-8', 'TERM': 'vt100', 'SHELL': '/bin/bash', 'HOSTNAME': 'mock', 'HOME': '/builddir', 'PATH': '/usr/bin:/bin:/usr/sbin:/sbin'}
DEBUG util.py:257:  pigz abort: corrupted input -- invalid deflate data: <stdin>
DEBUG util.py:257:  tar: Unexpected EOF in archive
DEBUG util.py:257:  tar: Unexpected EOF in archive
DEBUG util.py:257:  tar: Error is not recoverable: exiting now
DEBUG util.py:347:  Child return code was: 2
DEBUG util.py:111:  kill orphans
[danishka@localhost rpmbuild]$ cat /home/danishka/rpmbuild/840551-sugar-kuku/results/state.log
2012-07-18 19:33:05,146 - Mock Version: 1.1.22
2012-07-18 19:33:05,148 - State Changed: unpacking root cache

(In reply to comment #22)
> anyway how these approved packages moving to build system?

Once you raise fedora-cvs? flag, someone will create git module for your package in dist-git by changing flag to fedora-cvs+

Then you import the approved srpm in dist-git.

I think you better first read all the links here http://fedoraproject.org/wiki/PackageMaintainers/Join

then http://fedoraproject.org/wiki/Package_Review_Process

I ran fedora-review command on this bug. I used fedora-review first time and it executed successfully.

INFO: Done(/home/parag/Downloads/840551/sugar-kuku-4-6.fc17.src.rpm) Config(fedora-rawhide-i386) 16 minutes 25 seconds
INFO: Results and/or logs in: /var/lib/mock/fedora-rawhide-i386/result
State Changed: end
Build completed ok

i know but was it was not working on my Fedora 17 x86_64 box?

i was using it as local user.

if you can understand me correctly, 

is there a person who can move this to the build system other than myself ?

I won't available for next week but i want to get the work do.
Since we all work for the community and why the hell some one can do that on behalf of myself. 

I am not going to do any reviews within next two weeks as I have some other work to do. To be honest tomorrow morning I am going to a remote site, for a school lab project.

Just try to understand what I am saying.

Anyway I noticed that there is no such mandatory for doing 5 unofficial reviews and also some people did not any of review.

So why do you pushing back?

I do not want to add 'package manager' label to my profile but i want to contribute. 

Dear Parag,
Working for day job and working for the community spirit is different. :)

You are asking me to get you sponsored based that you don't have time to review other packages? What if all new people coming with this mindset. Then, we will endup with so many package reviews waiting. This reviewing work not only demonstrate that you understand rpm packaging well but help other people who used to wait years and years to get first initial comment on their package review.

So tell me who is pushing? There are reviews lying since years in Fedora and still some of them getting regularly updated but not yet finished.

There is no precise definition given for sponsorship by FESCo. So its upto sponsor to decide criteria for sponsorship and I can see you are still not familiar with recent fedora packaging changes. So I asked to do reviews and its also written in sponsorship policy.

You can even search in bugzilla that other sponsor not even approve the package before they can see contributor has done reviews.

So if you have no time in next 2 weeks then you can resume work after that. Else, find someone who is already in packager group and he can take over these reviews and request fedora-cvs and build it in fedora.

If you think my criteria of asking people to do 5 reviews is wrong then I will not proceed here and remove your packager request.

Please reply so that I can add back FE-NEEDSPONSOR in your all reviews so that other sponsor can look into your reviews and then sponsor you.

If I remember I didn't even sponsor my team members just because they need sponsorship and has not done any reviews. For me reviews are necessary to get sponsorship.

From http://fedoraproject.org/wiki/How_to_get_sponsored_into_the_packager_group#Submitting_quality_new_packages

"The sponsors that look at new package submissions often ask new packagers to do some package reviews in order to further show that they know what they're doing. If you do some reviews ahead of time, you can show the sponsors that you've both read these pages and understand the guidelines. Go ahead and link to other package review requests where you've left comments and reviews"

Here meaning of "some reviews" is not defined and is upto sponsor.

i came with a spirit to work on packaging.. Specially had an idea of packaging all the activities for fedora.

but i feel.. i should give up this.

Whoever want to learn packaging, he will try different packages or review different kind of package like perl, python, gnome or library packages. I think if anyone knows well packaging then he can finish 5 reviews in whole day easily.

anyway, I consider above reply mean you don't want to review other packages.

Package Review
==============

Key:
- = N/A
x = Pass
! = Fail
? = Not evaluated



==== Generic ====
[x]: EXTRA Rpmlint is run on all installed packages.
     Note: There are rpmlint messages (see attachment).
[x]: EXTRA Spec file according to URL is the same as in SRPM.
[x]: MUST Package is licensed with an open-source compatible license and meets
     other legal requirements as defined in the legal section of Packaging
     Guidelines.
[x]: MUST Package successfully compiles and builds into binary rpms on at
     least one supported primary architecture.
[x]: MUST %build honors applicable compiler flags or justifies otherwise.
[x]: MUST All build dependencies are listed in BuildRequires, except for any
     that are listed in the exceptions section of Packaging Guidelines.
[x]: MUST Buildroot is not present
     Note: Unless packager wants to package for EPEL5 this is fine
[x]: MUST Package contains no bundled libraries.
[x]: MUST Changelog in prescribed format.
[x]: MUST Package has no %clean section with rm -rf %{buildroot} (or
     $RPM_BUILD_ROOT)
     Note: Clean would be needed if support for EPEL is required
[x]: MUST Sources contain only permissible code or content.
[x]: MUST Each %files section contains %defattr if rpm < 4.4
     Note: Note: defattr macros not found. They would be needed for EPEL5
[-]: MUST Macros in Summary, %description expandable at SRPM build time.
[-]: MUST Package contains desktop file if it is a GUI application.
[-]: MUST Development files must be in a -devel package
[x]: MUST Package requires other packages for directories it uses.
[x]: MUST Package uses nothing in %doc for runtime.
[x]: MUST Package is not known to require ExcludeArch.
[x]: MUST Permissions on files are set properly.
[x]: MUST Package does not contain duplicates in %files.
[x]: MUST Package complies to the Packaging Guidelines
[x]: MUST Spec file lacks Packager, Vendor, PreReq tags.
[x]: MUST Package does not run rm -rf %{buildroot} (or $RPM_BUILD_ROOT) at the
     beginning of %install.
     Note: rm -rf would be needed if support for EPEL5 is required
[-]: MUST Large documentation files are in a -doc subpackage, if required.
[x]: MUST 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 %doc.
[x]: MUST License field in the package spec file matches the actual license.
     Note: Checking patched sources after %prep for licenses. Licenses found:
     "*No copyright* UNKNOWN", "GPL (v3 or later)" For detailed output of
     licensecheck see file: /home/vascom/840551-sugar-kuku/licensecheck.txt
[x]: MUST Package consistently uses macro is (instead of hard-coded directory
     names).
[x]: MUST Package is named using only allowed ascii characters.
[x]: MUST Package is named according to the Package Naming Guidelines.
[x]: MUST Package does not generate any conflict.
     Note: Package contains no Conflicts: tag(s)
[x]: MUST Package obeys FHS, except libexecdir and /usr/target.
[x]: MUST Package must own all directories that it creates.
[x]: MUST Package does not own files or directories owned by other packages.
[x]: MUST Package installs properly.
[x]: MUST Package is not relocatable.
[x]: MUST Requires correct, justified where necessary.
[x]: MUST Rpmlint is run on all rpms the build produces.
     Note: No rpmlint messages.
[x]: MUST Sources used to build the package match the upstream source, as
     provided in the spec URL.
[x]: MUST Spec file is legible and written in American English.
[x]: MUST Spec file name must match the spec package %{name}, in the format
     %{name}.spec.
[-]: MUST Package contains systemd file(s) if in need.
[x]: MUST File names are valid UTF-8.
[x]: SHOULD Reviewer should test that the package builds in mock.
[-]: SHOULD If the source package does not include license text(s) as a
     separate file from upstream, the packager SHOULD query upstream to
     include it.
[x]: SHOULD Dist tag is present.
[x]: SHOULD No file requires outside of /etc, /bin, /sbin, /usr/bin,
     /usr/sbin.
[x]: SHOULD Final provides and requires are sane (rpm -q --provides and rpm -q
     --requires).
[?]: SHOULD Package functions as described.
[x]: SHOULD Latest version is packaged.
[x]: SHOULD Package does not include license text files separate from
     upstream.
[!]: SHOULD SourceX / PatchY prefixed with %{name}.
     Note: Source0 (kuku_anakula-4.xo)
[x]: SHOULD SourceX is a working URL.
[x]: SHOULD Description and summary sections in the package spec file contains
     translations for supported Non-English languages, if available.
[x]: SHOULD Package should compile and build into binary rpms on all supported
     architectures.
[-]: SHOULD %check is present and all tests pass.
[?]: SHOULD Packages should try to preserve timestamps of original installed
     files.
[x]: SHOULD Spec use %global instead of %define.

Rpmlint
-------
Checking: sugar-kuku-4-6.fc17.src.rpm
          sugar-kuku-4-6.fc17.noarch.rpm
2 packages and 0 specfiles checked; 0 errors, 0 warnings.


Rpmlint (installed packages)
----------------------------
Cannot parse rpmlint output:
Requires
--------
sugar-kuku-4-6.fc17.noarch.rpm (rpmlib, GLIBC filtered):
    
    /usr/bin/env  
    /usr/bin/python  
    sugar  

Provides
--------
sugar-kuku-4-6.fc17.noarch.rpm:
    
    sugar-kuku = 4-6.fc17

MD5-sum check
-------------
http://mirrors.mit.edu/sugarlabs/activities/4526/kuku_anakula-4.xo :
  MD5SUM this package     : 05e0ed5cdb577bbe61341446e8bc5829
  MD5SUM upstream package : 05e0ed5cdb577bbe61341446e8bc5829


Generated by fedora-review 0.2.0 (53cc903) last change: 2012-07-09
Command line :/usr/bin/fedora-review -b 840551
External plugins:

Parag,

Do you mind sponsoring, based on following information?

Created 8 packages including this package

https://bugzilla.redhat.com/show_bug.cgi?id=841239
https://bugzilla.redhat.com/show_bug.cgi?id=842101
https://bugzilla.redhat.com/show_bug.cgi?id=842107
https://bugzilla.redhat.com/show_bug.cgi?id=843646
https://bugzilla.redhat.com/show_bug.cgi?id=843678
https://bugzilla.redhat.com/show_bug.cgi?id=840425
https://bugzilla.redhat.com/show_bug.cgi?id=840437
https://bugzilla.redhat.com/show_bug.cgi?id=840551


Unofficial Reviews:

https://bugzilla.redhat.com/show_bug.cgi?id=772521
https://bugzilla.redhat.com/show_bug.cgi?id=838540
https://bugzilla.redhat.com/show_bug.cgi?id=839730
https://bugzilla.redhat.com/show_bug.cgi?id=843029
https://bugzilla.redhat.com/show_bug.cgi?id=842667

Sorry I have lost interest in sponsoring you based on comment#27. I am revoking this package approval as its of no use if you have no packager group commit access. I will keep other package approvals for now.

Please find some other sponsor whom you can convince that how you are working for Fedora packages, its fixes and willing to actively maintain packages in Fedora.

Revoking this package approval is needed for me as it will let other sponsor to look your work and then approve this package again and accordingly sponsor you.

Another thing I want to note here from my side is that , I am still not in favour to use fedora-review command to post unoffical reviews where you are just posting the results and not even looking inside tarball and spec for any other issues.

Please add FE-NEEDSPONSOR in your other package submissions.

Parag,
Regarding fedora-review tool results came from as part of a package sponsorship, I validate sponsored applicants on their ability to use fedora review tool, and actually review the package by examining tarball and spec and have a running conversation with the original packager.

I agree with you though, if folks are doing only fedora-review tool running without examining the spec file manually and conversing with the unofficial package reviewer, that is not sufficient.

Thanks for your comment. I was of the same opinion. I have also reported upstream developers of fedora-review that such things are happening by using fedora-review tool.  They assured me that they are not going to market this tool for new contributors easy way to get sponsorship. They are also thinking to add some comment at the start of auto generated review text file.

Dear Parag and Steven,

I am not here to do master in reviewing or put my free time on reviewing.

I was suppose to package sugar activities for fedora which are having same structure. 

Please try to understand what i was trying to and i do not want to contribute as a reviewer as I do not have much free time.

Due to this reviewing thing all packaged sugar activities are on hold and i do not have nothing to do.

And next thing is other sugar activity packages did not follow this 5 reviews rule.

You guys should think again about how to get people in to reviewing but not forcing others to review to reduce the number of pending reviews.

I have packaged more than 8  sugar activities but i did not continue after this incident.

I do not work on each and every application  but i just want to stick in to sugar activities.

(In reply to comment #37)
> Dear Parag and Steven,
> 
> I am not here to do master in reviewing or put my free time on reviewing.
> 
> I was suppose to package sugar activities for fedora which are having same
> structure. 
> 
> Please try to understand what i was trying to and i do not want to
> contribute as a reviewer as I do not have much free time.
> 
> Due to this reviewing thing all packaged sugar activities are on hold and i
> do not have nothing to do.
> 
> And next thing is other sugar activity packages did not follow this 5
> reviews rule.
> 
Note: again this is my criteria to get sponsored from me. I already said there are may packager sponsors in Fedora. Try to contact any one of them and they if like your work will sponsor you.

> You guys should think again about how to get people in to reviewing but not
> forcing others to review to reduce the number of pending reviews.

If people think like this then as I said already we will end up with so many package reviews waiting for their initial comment at least.

> 
> I have packaged more than 8  sugar activities but i did not continue after
> this incident.
> 
> I do not work on each and every application  but i just want to stick in to
> sugar activities.

If you have no time they why not ask on devel list to either work on these packages or submit these packages again with fresh review request with new owners?

I am serious, we should find a way hire new volunteers for reviewing.

I will write to ambassadors list.

We must try to increase our resource base.

Somehow I got CC'd on this.  I'm not really sure why, but a couple of points:

1) I've been on vacation for a month.  For longer the lifetime of this package.  I'm not really back to reviewing packages yet.

2) I don't know anything about sugar, so I'm not sure there's much I can do.  I prefer to stick to things I understand when sponsoring new contributors.

There was a sugar package from a different contributor where I offered to sponsor if I could get a sugar expert to join in, and couldn't even get that.  To me it seems like this is a failing with the sugar community, not really the package review process.  It's true we have a number of waiting packages, but the number is pretty much stable.  Besides, this one isn't really even that old so I'm not sure what's up with the grumbling.

If someone's going to pay for reviewers, that's great, but some of us have been reviewing a large number of packages for years without compensation and I don't really think money would help the process.

Finally, I personally dispensed with requiring people to review other packages in order to receive sponsorship some time ago.  Sometimes it makes sense, sometimes it doesn't.  But each sponsor is allowed to sponsor according to their own personal beliefs, so I'm certainly not going to say that my way is somehow better.

Thanks for your comment. Sorry for not mentioning why I cc'ed you. I know that you have done a HUGE work(contribution) to Fedora and its Package Review process and policies. 

also, if you remember few times when I got some issues in review process, I used to talk to you on IRC specially when topics used to come up for minimizing package review tickets.

Now reason to CC you is in case you may want to say anything on this review progress which you already said.

Thanks.

Parag,

Do I need to add python2-devel here?
Btw, there is no update in the upstream since I packaged this. I hope there is no issue with this package. :)

Got the request from Danishka again for this review as he has been sponsored now. So, someone will be there for taking care of his work from Sugar group. 

Danishka,
  Yes. Check if upstream is providing python2 or python3 files and then accordingly add versioned Buildrequires. Like for this package python2-devel. And remove BuildRequires: python.

Please provide again SPEC and SRPM for final look on this package.

SPEC file URL: http://snavin.fedorapeople.org/packages/sugar-kuku/sugar-kuku.spec

SRPM URL: http://snavin.fedorapeople.org/packages/sugar-kuku/sugar-kuku-4-7.fc18.src.rpm

Review:-

+ Package builds in mock successfully

+ rpmlint on rpms gave
2 packages and 0 specfiles checked; 0 errors, 0 warnings.

+ Source verified with upstream as (sha256sum)
srpm tarball : adbfda234c4c5d31c0acd25b65e42d50cd9baacd1e171f5bcc4d96a3438fa308
upstream tarball : adbfda234c4c5d31c0acd25b65e42d50cd9baacd1e171f5bcc4d96a3438fa308

+ License tag is valid GPLv3+

+ Rest looks as per packaging guidelines.


Suggestions:
1)  Don't use any backslash between %{buildroot} and %{_prefix}, so your %install should look like
%{__python} ./setup.py install --prefix=%{buildroot}%{_prefix}

2) Why is changelog for -6 and -7 is same? Add correct changelog

3) You don't need to set again executable bits. remove following from spec
#chmod +x  kuku_config.py

Danishka,
 Can you fix above issues and submit a new srpm?

Sure!

Spec URL: http://snavin.fedorapeople.org/packages/sugar-kuku/sugar-kuku.spec

SRPM URL: http://snavin.fedorapeople.org/packages/sugar-kuku/sugar-kuku-4-6.fc18.src.rpm

spec file inside srpm does not match with above spec file.

Uploaded the correct SRPM

Spec URL: http://snavin.fedorapeople.org/packages/sugar-kuku/sugar-kuku.spec

SRPM URL: http://snavin.fedorapeople.org/packages/sugar-kuku/sugar-kuku-4-6.fc18.src.rpm

koji scratch build failed for f20, http://koji.fedoraproject.org/koji/taskinfo?taskID=5783085

you need to have correct BR: sugar-toolkit and not sugar-toolkit-gtk3

Also, add correct changelog like what got changed from previous srpm release.

Hi Parag,

I am using F18 box for packaging. There is no BR:sugar-toolkit package 

error: Failed build dependencies:
	BR:sugar-toolkit is needed by sugar-kuku-4-7.fc18.noarch

ah! I mean use it like this

BuildRequires: sugar-toolkit

fixed the spec file as per comment #52

SRPM URL: http://snavin.fedorapeople.org/packages/sugar-kuku/sugar-kuku-4-8.fc18.src.rpm

SPEC UEL: http://snavin.fedorapeople.org/packages/sugar-kuku/sugar-kuku.spec

APPROVED.

New Package SCM Request
=======================
Package Name: sugar-kuku
Short Description: arithmetic education game
Owners: snavin
Branches: f17 f18 f19 f20
InitialCC:

SCM is invalid. 

Please drop f17 and f20.

Thanks.

New Package SCM Request
=======================
Package Name: sugar-kuku
Short Description: arithmetic education game
Owners: snavin
Branches: f18 f19
InitialCC:

Git done (by process-git-requests).

sugar-kuku-4-8.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/sugar-kuku-4-8.fc18

sugar-kuku-4-8.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/sugar-kuku-4-8.fc19

sugar-kuku-4-8.fc19 has been pushed to the Fedora 19 testing repository.

Can this be pushed to stable now and closed this review?

sugar-kuku-4-8.fc19 has been pushed to the Fedora 19 stable repository.

sugar-kuku-4-8.fc18 has been pushed to the Fedora 18 stable repository.

sugar-kuku-5-0.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/sugar-kuku-5-0.fc18

sugar-kuku-5-0.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/sugar-kuku-5-0.fc19

sugar-kuku-5-0.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/sugar-kuku-5-0.fc20

Package sugar-kuku-5-0.fc20:
* should fix your issue,
* was pushed to the Fedora 20 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing sugar-kuku-5-0.fc20'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-21698/sugar-kuku-5-0.fc20
then log in and leave karma (feedback).

sugar-kuku-5-0.fc18 has been pushed to the Fedora 18 stable repository.  If problems still persist, please make note of it in this bug report.

sugar-kuku-5-0.fc19 has been pushed to the Fedora 19 stable repository.  If problems still persist, please make note of it in this bug report.

sugar-kuku-5-0.fc20 has been pushed to the Fedora 20 stable repository.  If problems still persist, please make note of it in this bug report.