Bug 818454 - Review Request: rubygem-linecache19 - Read file with caching
Review Request: rubygem-linecache19 - Read file with caching
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Bohuslav "Slavek" Kabrda
Fedora Extras Quality Assurance
:
Depends On:
Blocks: 818457
  Show dependency treegraph
 
Reported: 2012-05-03 03:13 EDT by Mamoru TASAKA
Modified: 2012-09-24 12:22 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-06-12 04:21:06 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
bkabrda: fedora‑review+
limburgher: fedora‑cvs+


Attachments (Terms of Use)

  None (edit)
Description Mamoru TASAKA 2012-05-03 03:13:20 EDT
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
Comment 1 Bohuslav "Slavek" Kabrda 2012-05-07 07:55:20 EDT
Taking this one.
Comment 2 Bohuslav "Slavek" Kabrda 2012-05-07 08:40:26 EDT
- 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
Comment 3 Mamoru TASAKA 2012-05-07 09:23:37 EDT
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
Comment 4 Mamoru TASAKA 2012-05-07 09:37:37 EDT
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).
Comment 5 Bohuslav "Slavek" Kabrda 2012-05-07 09:39:17 EDT
(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.
Comment 6 Mamoru TASAKA 2012-05-07 10:16:16 EDT
(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.
Comment 7 Mamoru TASAKA 2012-05-07 19:01:20 EDT
Bohuslav, would you write what is "really" blocker now?
Comment 8 Bohuslav "Slavek" Kabrda 2012-05-09 01:30:00 EDT
(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.
Comment 9 Mamoru TASAKA 2012-05-09 07:49:07 EDT
(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.
Comment 10 Bohuslav "Slavek" Kabrda 2012-05-09 07:57:46 EDT
(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.
Comment 11 Mamoru TASAKA 2012-05-09 08:04:45 EDT
(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.
Comment 12 Mamoru TASAKA 2012-05-09 08:06:36 EDT
(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.
Comment 13 Bohuslav "Slavek" Kabrda 2012-05-09 08:19:55 EDT
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.
Comment 14 Mamoru TASAKA 2012-05-10 11:20:23 EDT
(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.
Comment 15 Bohuslav "Slavek" Kabrda 2012-05-11 01:42:38 EDT
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?).
Comment 16 Mamoru TASAKA 2012-05-12 12:27:28 EDT
(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.
Comment 17 Bohuslav "Slavek" Kabrda 2012-05-14 01:41:23 EDT
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.
Comment 18 Mamoru TASAKA 2012-05-28 05:08:44 EDT
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:
Comment 19 Gwyn Ciesla 2012-05-29 08:30:17 EDT
Git done (by process-git-requests).
Comment 20 Mamoru TASAKA 2012-06-12 04:21:06 EDT
Built for F-18, F-17, updates requested for F-17.
Thank you for the review and git procedure. Closing.
Comment 21 Mamoru TASAKA 2012-06-12 04:23:13 EDT
Bohuslav, by the way if you want some swap reviews, please let me know it.

Note You need to log in before you can comment on or make changes to this bug.