Spec URL: http://mtasaka.fedorapeople.org/Review_request/ruby-debug-related/rubygem-linecache19.spec SRPM URL: http://mtasaka.fedorapeople.org/Review_request/ruby-debug-related/rubygem-linecache19-0.5.13-1.fc.src.rpm Description: The LineCache module allows one to get any line from any file, caching the lines and file information on first access to the file. Although the file may be any file, the common use is when the file is a Ruby script since parsing of the file is done to figure out where the statement boundaries are. The routines here may be is useful when a small random sets of lines are read from a single file, in particular in a debugger to show source lines. koji scratch build f18: http://koji.fedoraproject.org/koji/taskinfo?taskID=4048488 f17: http://koji.fedoraproject.org/koji/taskinfo?taskID=4048489
Taking this one.
- License is GPLv2+, not just GPLv2 (try running licensecheck on COPYING or linecache19.rb). - The "gem build" should probably be moved to the %build section according to the guidelines example [1]. - In %check section, the pushd should be associated with popd. - You can run the tests more easily with "testrb -Ilib test/test-*". - As for the docs, I would leave COPYING and possibly README in the main package and move the rest into the doc subpackage. - I would also consider marking the files, that actually are documents, by %doc in -doc subpackage, but this is not a blocker. - Is there any specific reason why the -doc subpackage is not marked as noarch? If not, please make it noarch. [1] https://fedoraproject.org/wiki/Packaging:Ruby#.25build
Thank you for comments! (In reply to comment #2) > - License is GPLv2+, not just GPLv2 (try running licensecheck on COPYING or > linecache19.rb). So please check the above comment on License: line > - The "gem build" should probably be moved to the %build section according to > the guidelines example [1]. I want to clean up unneeded directory on %prep, so I prefer to once "prepare" gem file at %prep. > - In %check section, the pushd should be associated with popd. Well, not necessary... > - You can run the tests more easily with "testrb -Ilib test/test-*". Thank you for information. > - As for the docs, I would leave COPYING and possibly README in the main > package and move the rest into the doc subpackage. Well, this is already done... > - I would also consider marking the files, that actually are documents, by %doc > in -doc subpackage, but this is not a blocker. > - Is there any specific reason why the -doc subpackage is not marked as noarch? > If not, please make it noarch. http://lists.fedoraproject.org/pipermail/packaging/2012-May/008401.html
A bit more explanation: (In reply to comment #3) > > - Is there any specific reason why the -doc subpackage is not marked as noarch? > > If not, please make it noarch. > http://lists.fedoraproject.org/pipermail/packaging/2012-May/008401.html So here the main package is arch specific (i.e. will be built on both i686 and x86_64). When -doc package is marked as %noarch, koji builds -doc subpackage on i686 and x86_64 _anyway_ and checks if the built -doc subpackage actually does not differ between i686 and x86_64, and sadly, currently ri file generation differs between archs. This problem doesn't appear (silently) when main package is also noarch - actually the arch under which the srpm will be rebuilt is either i686 or x86_64 (there is no such "noarch" builder), however only "one" arch is used, so the difference cannot be seen (silently).
(In reply to comment #3) > Thank you for comments! > > (In reply to comment #2) > > - License is GPLv2+, not just GPLv2 (try running licensecheck on COPYING or > > linecache19.rb). > So please check the above comment on License: line > Yep, I saw that. The license in the mentioned files is however clearly GPLv2+. So I would suggest querying the upstream what's actually right. > > - The "gem build" should probably be moved to the %build section according to > > the guidelines example [1]. > I want to clean up unneeded directory on %prep, so I prefer to once "prepare" > gem file at %prep. > Ok, sounds reasonable. > > - In %check section, the pushd should be associated with popd. > Well, not necessary... > No, but cleaner :) (why not use "cd" in that case?) > > - You can run the tests more easily with "testrb -Ilib test/test-*". > Thank you for information. > > > - As for the docs, I would leave COPYING and possibly README in the main > > package and move the rest into the doc subpackage. > Well, this is already done... > Nope, VERSION, NEWS, ChangeLog and AUTHORS files are in the main package - these are the files I am talking about. > > - I would also consider marking the files, that actually are documents, by %doc > > in -doc subpackage, but this is not a blocker. > > > - Is there any specific reason why the -doc subpackage is not marked as noarch? > > If not, please make it noarch. > http://lists.fedoraproject.org/pipermail/packaging/2012-May/008401.html Thanks for the clarification.
(In reply to comment #5) > (In reply to comment #3) > > Thank you for comments! > > > > (In reply to comment #2) > > > - License is GPLv2+, not just GPLv2 (try running licensecheck on COPYING or > > > linecache19.rb). > > So please check the above comment on License: line > > > > Yep, I saw that. The license in the mentioned files is however clearly GPLv2+. > So I would suggest querying the upstream what's actually right. Stricter license tag is no problem here. > > > - In %check section, the pushd should be associated with popd. > > Well, not necessary... > > > > No, but cleaner :) (why not use "cd" in that case?) Will fix when importing to Fedora git, or next update if any blocker remains. > > > - As for the docs, I would leave COPYING and possibly README in the main > > > package and move the rest into the doc subpackage. > > Well, this is already done... > > > > Nope, VERSION, NEWS, ChangeLog and AUTHORS files are in the main package - > these are the files I am talking about. Ah, now I can see what you see. Then IMO at least AUTHORS MUST be in main (copyright holder or so is the important imformation as well as COPYING file). IMO NEWS should also be in main package (well, it is "news"). ChangeLog can be in -doc subpackage, well, however I think either will do.
Bohuslav, would you write what is "really" blocker now?
(In reply to comment #6) > (In reply to comment #5) > > (In reply to comment #3) > > > Thank you for comments! > > > > > > (In reply to comment #2) > > > > - License is GPLv2+, not just GPLv2 (try running licensecheck on COPYING or > > > > linecache19.rb). > > > So please check the above comment on License: line > > > > > > > Yep, I saw that. The license in the mentioned files is however clearly GPLv2+. > > So I would suggest querying the upstream what's actually right. > > Stricter license tag is no problem here. > I do not consider "stricter is no problem" to be a good solution. Sorry, but not having the license clear is a blocker for me. > > > > - In %check section, the pushd should be associated with popd. > > > Well, not necessary... > > > > > > > No, but cleaner :) (why not use "cd" in that case?) > > Will fix when importing to Fedora git, or next update if any blocker remains. > > Sure, good. > > > > - As for the docs, I would leave COPYING and possibly README in the main > > > > package and move the rest into the doc subpackage. > > > Well, this is already done... > > > > > > > Nope, VERSION, NEWS, ChangeLog and AUTHORS files are in the main package - > > these are the files I am talking about. > > Ah, now I can see what you see. Then IMO at least AUTHORS MUST be in main > (copyright holder or so is the important imformation as well as COPYING file). > IMO NEWS should also be in main package (well, it is "news"). ChangeLog can be > in -doc subpackage, well, however I think either will do. Ah, yes, AUTHORS should probably stay in the main package - however this on is really not a blocker. So the only blocker for me is the license.
(In reply to comment #8) > (In reply to comment #6) > > (In reply to comment #5) > > > (In reply to comment #3) > > > > Thank you for comments! > > > > > > > > (In reply to comment #2) > > > > > - License is GPLv2+, not just GPLv2 (try running licensecheck on COPYING or > > > > > linecache19.rb). > > > > So please check the above comment on License: line > > > > > > > > > > Yep, I saw that. The license in the mentioned files is however clearly GPLv2+. > > > So I would suggest querying the upstream what's actually right. > > > > Stricter license tag is no problem here. > > > > I do not consider "stricter is no problem" to be a good solution. Sorry, but > not having the license clear is a blocker for me. So "README" says GPLv2, other parts says GPLv2+ or so, and the license is _clearly_ GPLv2. We can say "GPLv2 and GPLv2+" (license guideline allows this writing: see: https://fedoraproject.org/wiki/Packaging/LicensingGuidelines#Multiple_Licensing_Scenarios ), however in this case, "GPLv2 and GPLv2+" is the same as GPLv2. So the license is actually clear.
(In reply to comment #9) > (In reply to comment #8) > > (In reply to comment #6) > > > (In reply to comment #5) > > > > (In reply to comment #3) > > > > > Thank you for comments! > > > > > > > > > > (In reply to comment #2) > > > > > > - License is GPLv2+, not just GPLv2 (try running licensecheck on COPYING or > > > > > > linecache19.rb). > > > > > So please check the above comment on License: line > > > > > > > > > > > > > Yep, I saw that. The license in the mentioned files is however clearly GPLv2+. > > > > So I would suggest querying the upstream what's actually right. > > > > > > Stricter license tag is no problem here. > > > > > > > I do not consider "stricter is no problem" to be a good solution. Sorry, but > > not having the license clear is a blocker for me. > > > So "README" says GPLv2, other parts says GPLv2+ or so, and > the license is _clearly_ GPLv2. We can say "GPLv2 and GPLv2+" > (license guideline allows this writing: see: > > https://fedoraproject.org/wiki/Packaging/LicensingGuidelines#Multiple_Licensing_Scenarios > ), however in > this case, "GPLv2 and GPLv2+" is the same as GPLv2. So the license > is actually clear. Ok, here is my point: I'm guessing that upstream just filled the license field in Readme wrongly, because why would they license everything under GPLv2+ and then wrote GPLv2 into Readme? That is what puzzles me and why I want clarification from the upstream, to say if that was intentional. And yes, I completely understand how you got GPLv2 out of the Readme and source files, but I am saying that the upstream most probably has the Readme file wrong.
(In reply to comment #10) > Ok, here is my point: I'm guessing that upstream just filled the license field > in Readme wrongly, _Even so_, interpretting the whole license as GPLv2 is _no problem_, because GPLv2+ and GPLv2 does not contradict.
(In reply to comment #11) > (In reply to comment #10) > > Ok, here is my point: I'm guessing that upstream just filled the license field > > in Readme wrongly, > > _Even so_, interpretting the whole license as GPLv2 is _no problem_, because > GPLv2+ and GPLv2 does not contradict. A bit more explanation. So the current license status is _no problem_, as currently there is no license incompatibility. If there is really license incompatibility, we MUST ask the upstream to fix it. however this is not the case.
Well, they don't contradict, but if you say GPLv2, noone will be able to use the library under GPLv3, for example (while with GPLv2+ this would be possible). I know that this is a small issue as you say, but I would really prefer asking upstream to have it 100 % right.
(In reply to comment #13) > Well, they don't contradict, but if you say GPLv2, noone will be able to use > the library under GPLv3, for example (while with GPLv2+ this would be > possible). I know that this is a small issue as you say, but I would really > prefer asking upstream to have it 100 % right. So this is not a blocker. Please make it clear what is really blocker now. The upstream may relicense this, however anyway the current status is no problem.
Ugh, OK. Could you please post the current SPEC/SRPM, so I can have a final look at them and approve (btw have you already tried querying upstream about the licensing?).
(In reply to comment #15) > Ugh, OK. Could you please post the current SPEC/SRPM, Current is the same as above, because currently there is no blocker. (In reply to comment #15) > (btw have you already tried querying upstream about > the licensing?). May try.
Ok, this package is APPROVED. Before committing, please fix the minor issues I pointed out during review. Also, please ask the upstream about the license and if it changes to GPLv2+, fix it ASAP. Thanks.
Thank you! and sorry for delay (for 2 weeks...) New Package SCM Request ======================= Package Name: rubygem-linecache19 Short Description: Read file with caching Owners: mtasaka Branches: f17 InitialCC:
Git done (by process-git-requests).
Built for F-18, F-17, updates requested for F-17. Thank you for the review and git procedure. Closing.
Bohuslav, by the way if you want some swap reviews, please let me know it.