Spec URL: Need hosting space to submit the spec file. SRPM URL: Need hosting space to submit the source RPM. Description: The ccd2iso project converts CD backup files created using the non-free CloneCD program to a format understood by most Free Software CD writing programs. This's my first package and I need a sponsor.
e.g. for hosting space: http://fedoraproject.org/wiki/Infrastructure/fedorapeople.org
It's mentioned under "Accessing Your fedorapeople.org Space", that "2. You must be sponsored in a group (other than the CLA groups)". I'm only a member in CLA groups. As I mentioned in my original review request description, this's my first package, so I amn't sponsored yet.
Hmm, well that's a problem. I started as a translator, so then I already was in a non CLA group. E-Mail /me and I can put it on the web for you.
I'm no sponsor, so just a comment: - You should use %{version} macro in Source0, so you don't need to change that url everytime a new version is out. The rest looks ok at the first sight :) SPEC URL: http://tomspur.fedorapeople.org/other_review/ccd2iso.spec SRPM URL: http://tomspur.fedorapeople.org/other_review/ccd2iso-0.3-1.fc12.src.rpm
Created attachment 394502 [details] new spec file to resolve the review findings Found it easier to attach the new spec file here, after resolving your remarks.
Some other comments, I just noticed ;) - better use 'make install DESTDIR=$RPM_BUILD_ROOT INSTALL="install -p"' This way the timestamps are preserved, when installing. - rpmlint is not clean: ccd2iso.src:51: W: macro-in-%changelog %{version} Use %%{version} in the changelog, so this will not be considered as a macro. This can be done, when a sponsor wants to sponsor you. I think, you should wait for one and do some other informal reviews of other packages. See: http://fedoraproject.org/wiki/PackageMaintainers/HowToGetSponsored#Reviewing_Packages SPEC URL: http://tomspur.fedorapeople.org/other_review/ccd2iso.spec SRPM URL: http://tomspur.fedorapeople.org/other_review/ccd2iso-0.3-2.fc12.src.rpm (Sponsor FYI: I get the source from the src.rpm he sended via mail and not via spectool -g, so 'sources matches upstream' still needs to be verified.)
AFAIK, the GPLv2+ mean GPLv2 and above. But in the project homepage, I can only find that the licence is GPLv2. Should you use GPLv2 instead of GPLv2+? # rpmlint compliance patch is actually convert the DOS text to unix one. You should explicitly explain the patch.
Created attachment 407407 [details] SPEC file It seems at some time I forgot to address Thomas Supra's comments. Anyway you'll find attached the new spec file addressing Spura's comments as well as Liberty's.
Created attachment 408341 [details] source RPM matching the latest SPEC file I uploaded
I am taking the review. The package is mostly in good shape. There are minor things to fix. I made the review a little verbose since this is your first package. Since you need to be sponsored, we expect a little more from you. To show that you understand and work comfortably with the Fedora guidelines, you will need to do either some informal reviews on packages that are awaiting a review (this is the preferred method) http://fedoraproject.org/PackageReviewStatus/ or submit some other packages for review, that are preferably different type of packages. For more detail, see http://fedoraproject.org/wiki/How_to_get_sponsored_into_the_packager_group Here is the review: - rpmlint says: ccd2iso.x86_64: W: no-manual-page-for-binary ccd2iso It would be nice to have a man page. But this is not a blocker. ! Usually the EOL encoding erros are fixed via "sed" or "dos2unix". See http://fedoraproject.org/wiki/Packaging/Guidelines#Rpmlint_Errors A typical way of doing it is: sed 's/\r//' TODO > TODO.tmp touch -r TODO TODO.tmp mv -f TODO.tmp TODO or dos2unix -k TODO So that you preserve the timestamp of the file. Note that for dos2unix, you need to add a BuildRequires. I would say the patch is okay since the file is really small, but I would have preferred one of the above two. ! We don't package the INSTALL files, since they usually tell us how to compile the source. This is not relevant for an RPM user. * The license of the package is determined as follows: - You look at the license file (if it is missing you notify upstream). This one says GPLv2. - We look at the source code. The source code is in directory src/ in this case. - The header of the source code files carry the phrase: * This program is free software; you can redistribute it and/or modify * * it under the terms of the GNU General Public License as published by * * the Free Software Foundation; either version 2 of the License, or * * (at your option) any later version. * Since it says "or any later version", the license of the package must be GPLv2+. (Sometimes the source code does not carry the "or any later version" phrase. In that case we set the license tag to GPLv2. Sometimes the source code does not even specify the GPL version. In this case, even if the COPYING file says GPLv2 or GPLv3, we set the license tag to GPL+, and we notify upstream to add the GPL versions to the source file headers) For more information, see http://fedoraproject.org/wiki/Licensing#Good_Licenses scroll down to "GNU General Public License (no version)" ! You can use the %{name} macro in %files to keep macro usage consistent. * The compiler gives these warnings: ccd2iso.c:61: warning: implicit declaration of function 'strcmp' This can be avoided by adding a #include <string.h> ccd2iso.c:97: warning: format '%d' expects type 'int', but argument 2 has type 'long unsigned int' Replacing the %d with %zd will fix this warning. You can write a patch to fix these and send it upstream.
Mohammed, any progress? Are you still interested in this package?
(In reply to comment #11) > Mohammed, any progress? Are you still interested in this package? Yes, I finished addressing the points you highlighted in your review. I'll upload the the new SPEC and SRPM files tomorrow. Sorry for the delay.
Created attachment 433155 [details] SPEC file
Created attachment 433156 [details] source RPM
I've addressed all the review remarks on the SPEC and source RPM files uploaded in comments 13 and 14 respectively. The only remaining thing is the manual page. The original software package didn't contain a manual page, besides the program is really very easy and doesn't have any options. The only usage scenario can be obtained by typing the program name without any parameters.
No problem. Missing manual page is not a blocker. I will evaluate your update as soon as possible. Meanwhile, let's get you sponsored. Please follow the second paragraph on comment #10 for us to make sure that you are comfortable with the guidelines. Let me know if you have any questions.
Thanks Mohammed. The package is good. Just a little comment: avoiding the %{name} macro in URL is okay, since it gives us the convenience to copy and paste etc. But it is up to you. Normally I would approve the package now, but since you are not sponsored yet, we need to ask you for a little more work. I briefly explained this at the beginning of comment #10. Feel free to ask questions if there is anything not clear. Thanks.
Created attachment 434980 [details] SPEC file after removing %{name} macro from URL links Some URL's are still difficult to simply copy/paste to a browser because they contain the %{version} macro; I was asked to add it on comment 4 https://bugzilla.redhat.com/show_bug.cgi?id=562585#c4 earlier.
Created attachment 434981 [details] source RPM I'll try to accomplish the steps for getting sponsored by reviewing some other packages by the end of this week. Sorry for being late to do.
I see that you have made extensive unofficial reviews on bug 610073, bug 611328, and bug 611454. You did a good job, and you showed us that you are comfortable with following the guidelines. Now I am sponsoring you. Now that the hard part is over, you can now continue with submitting your package by following [1]. Afterwards please follow the guidelines to install koji tools and learn about their usage as described in [2] if you have not done so already. If you want to import this package to other branches of Fedora (12, 13, 14 for the time being) you might want to look at the Bodhi usage page in the wiki [3], which can be used both from the command line or through the web interface. Note that this is to be done after officially building the packages in koji in the respective branch(es). Also note that the master branch (which used to be called devel) corresponds to rawhide (F-15). Moreover, you can now do official reviews. You can also finish the reviews that you started, provided that the review request was filed by a sponsored contributor. Non-sponsored packagers need to wait for a sponsor for a review. From now on please use your fedorapeople.org account to post SPEC and SRPM files for review requests. At any point, if you have questions, feel free to contact me through email or IRC, or other contributors through IRC, or fedora-devel mailing list. Lifting FE-NEEDSPONSOR ------------------------------------------- This package (ccd2iso) was APPROVED by oget ------------------------------------------- Welcome to Fedora. [1] http://fedoraproject.org/wiki/PackageMaintainers/Join#Add_Package_to_Source_Code_Management_.28SCM.29_system_and_Set_Owner [2] http://fedoraproject.org/wiki/PackageMaintainers/Join#Install_the_Client_Tools_.28Koji.29 [3] http://fedoraproject.org/wiki/Bodhi_Guide
New Package SCM Request ======================= Package Name: ccd2iso Short Description: CloneCD image to ISO image file converter Owners: msk61 Branches: f12 f13 f14 InitialCC: msk61
Git done (by process-git-requests).
Hello Mohammed, I see that you didn't import this on git yet. Is there a problem?
Ah, not actually. I just got busy for a while. I was also reading the instructions for using koji and the commands for using git(through fedpkg) as a replacement for CVS and getting myself familiar with the process. I'll make sure to proceed with importing the package into the appropriate repositories ASAP.
I see that the package is still not imported. Mohammed, is there anything I can help you with?
Yes sorry, I know I'm quite late for this. It's just that I don't have a permanent internet connection(; most of the time I'm offline). When I get connected, most probably I don't have my fedora machine with me. Anyway, I'll try hard to get this package imported within a couple of weeks.
Today I've imported the package into the rawhide and f14 branch. I've however run into some annoyance with the f14 branch. I got confused as I was reading two different approaches to import the package into different branches, one at http://fedoraproject.org/wiki/PackageMaintainers/Join#Check_out_the_module by checking out a different directory for each branch, and the other at http://fedoraproject.org/wiki/Using_Fedora_GIT#Merging by checking out a single combined tree for all the branches. This led me to request a build for the package on the f14 branch at an early commit 66ab586444c33ac05f3d5863957aeaa88a53cfb0 and it passed successfully as seen at https://koji.fedoraproject.org/koji/taskinfo?taskID=2564860. However later I had a more recent commit 06534148c82c4015f2dc13362770b74bb4bd1a67 as seen at http://pkgs.fedoraproject.org/gitweb/?p=ccd2iso.git;a=commit;h=06534148c82c4015f2dc13362770b74bb4bd1a67 and http://pkgs.fedoraproject.org/gitweb/?p=ccd2iso.git;a=shortlog;h=f14/master. However since the build task invoked earlier for the older commit succeeded, it seems I can't request another build for that newer commit. When I invoke `fedpkg build', I get the error Could not initiate build: ccd2iso-0.3-6.fc14 has already been built I even tried to request a koji build explicitly for this command by running `koji build dist-f14-updates-candidate git://pkgs.fedoraproject.org/ccd2iso?#06534148c82c4015f2dc13362770b74bb4bd1a67', the created task fails with GenericError: Build already exists (id=202527, state=COMPLETE): {'name': 'ccd2iso', 'task_id': 2564885, 'pkg_id': 10805, 'epoch': None, 'completion_time': None, 'state': 0, 'version': '0.3', 'owner': 1325, 'release': '6.fc14', 'id': 202527} as it can be seen at https://koji.fedoraproject.org/koji/taskinfo?taskID=2564885 for example. Now is there any way to request a build against a specific commit for a branch that has already passed a successful build? Appreciating any suggestions.
It looks like the F-15 and F-14 packages are built fine. If the packages are usable (e.g. generated from the same SPEC file) then you don't need to do anything in koji for F-14 and F-15. Next I see that you messed things up a little with merging, and f14/master is ahead of master. You can leave this as is now, or merge master with f14/master. Later on, when you update to a newer version, or when you fix a bug, I recommend merging everything to master. For now, if you want to build F-12 and F-13 packages, just switch to their branch and merge with master. Then proceed as usual.
ccd2iso-0.3-6.fc14 has been submitted as an update for Fedora 14. https://admin.fedoraproject.org/updates/ccd2iso-0.3-6.fc14
ccd2iso-0.3-6.fc13 has been submitted as an update for Fedora 13. https://admin.fedoraproject.org/updates/ccd2iso-0.3-6.fc13
ccd2iso-0.3-6.fc12 has been submitted as an update for Fedora 12. https://admin.fedoraproject.org/updates/ccd2iso-0.3-6.fc12
I've received a mail today stating that the package couldn't be successfully untagged from dist-f14-updates-testing-pending; the mail looked like this Package: ccd2iso NVR: ccd2iso-0.3-6.fc14 User: bodhi Status: failed Tag Operation: untagged From Tag: dist-f14-updates-testing-pending ccd2iso-0.3-6.fc14 unsuccessfully untagged from dist-f14-updates-testing-pending by bodhi Operation failed with the error: koji.TagError: build ccd2iso-0.3-6.fc14 not in tag dist-f14-updates-testing-pending I've received similar mails for the f13 and f12 builds. However earlier today I received three other mails confirming that the package on the three targets were successfully untagged. Is there anything wrong that I can fix?
Don't worry about those emails. That is RelEng business.
ccd2iso-0.3-6.fc13 has been pushed to the Fedora 13 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update ccd2iso'. You can provide feedback for this update here: https://admin.fedoraproject.org/updates/ccd2iso-0.3-6.fc13
ccd2iso-0.3-6.fc14 has been pushed to the Fedora 14 stable repository. If problems still persist, please make note of it in this bug report.
ccd2iso-0.3-6.fc12 has been pushed to the Fedora 12 stable repository. If problems still persist, please make note of it in this bug report.
ccd2iso-0.3-6.fc13 has been pushed to the Fedora 13 stable repository. If problems still persist, please make note of it in this bug report.
Today I've stumbled upon the ccd2iso package in ubuntu repositories and I've found that they have a manual page for ccd2iso(maybe ubuntu people created it themselves). Can I add this manual to ccd2iso package in fedora since the package always lacked a manual since its creation? If this's possible, I don't know if I should build it for rawhide only or also for testing with other branches as well. I read the updates policy at https://fedoraproject.org/wiki/Updates_Policy?rd=Package_update_guidelines but I'm still confused about which release I should build for.
Hi Mohammed. First of all, it is a good practice to keep an eye on other distro builds to see if there are anything important that we can borrow. Thanks for doing that. There is a clause in the above page that says "Package maintainers MUST ... Avoid updates that are trivial or don't affect any Fedora users." This update might be considered trivial, and therefore one can argue that it won't meet the stable update criteria. On the other hand, this is a very small package and updating it will not cause major bandwidth issues with the users. The benefit of including the documentation might overweigh the triviality of the update. So I think it is at your discretion to submit an update to a stable release. Submitting it to rawhide is never a problem. In any case, a very good thing you can do is (also our policies recommend this) to submit the documentation upstream, so that it gets included in the next proper upstream release, if there will be any.