Bug 299171

Could someone review this package, as this is an interesting tool to help with
development of SELinux policies.

Ah..

Please include the real tarball in srpm.
Also please check:
http://fedoraproject.org/wiki/Packaging/SourceURL

Ok, I have updated the SRPM to include the .tar.gz file of the source.  But I am
still pulling the source directly from the SVN tree and I'm hoping this is ok. 
I'm doing it this way because the version number comes from stuff specified in
eclipse and this make it so that the versions don't get out of sync between the
rpm and the eclispe plugin.

URLs list above are updated.

(In reply to comment #3)
> Ok, I have updated the SRPM to include the .tar.gz file of the source.  But I am
> still pulling the source directly from the SVN tree and I'm hoping this is ok. 

You cannot do this. Fedora koji builder does not support this.

ping?

pong.

Sorry for the delay, I have been working on some other things and just had time
today to get back to the spec file.  But, I have gotten back to it and updated
the .spec and .src.rpm files referecned above.

This should be ok now.  It now references a .tar.gz file built from the svn tree.

Please let me know.

Thanks

Well,

* Please change release number or version every time you fix
  your spec/srpm.
  http://fedoraproject.org/wiki/Packaging/FrequentlyMadeMistakes

* You cannot extract files before %prep stage
  http://koji.fedoraproject.org/koji/getfile?taskID=224225&name=root.log  

Any suggestions on how else to get the version?  I'm untaring on line 26-28. 
Since this is an eclipse plugin there are versions set in multiple places. 
feature.xml and the MANIFEST.MF.  I'm using this to get the version for the RPM.
 This way there is no chance of forgetting to set the version in the .spec file,
which I had done several times before changing the .spec to get it from the
source directly.

Am I forced to have the version in the spec file or is there a way I can get it
from the tar file during build?

(In reply to comment #7)
> Well,
> 
> * Please change release number or version every time you fix
>   your spec/srpm.
>   http://fedoraproject.org/wiki/Packaging/FrequentlyMadeMistakes
> 
> * You cannot extract files before %prep stage
>   http://koji.fedoraproject.org/koji/getfile?taskID=224225&name=root.log  

(In reply to comment #8)
> I'm using this to get the version for the RPM.
>  This way there is no chance of forgetting to set the version in the .spec file,
> which I had done several times before changing the .spec to get it from the
> source directly.

the fedora build system prevents duplicate builds, so that should be a
sufficient reminder. :)

the spec for the only package i could find in fedora that sets its version based
on a source file is here:
http://cvs.fedora.redhat.com/viewcvs/rpms/func/F-7/func.spec?view=markup

however, the func spec reads the version from a source file rather than
extracting from a source tarball.

i could not find any specific packaging guidelines about whether or not versions
MUST be hardcoded in spec files, but this approach is very unusual.

i would suggest moving to versioned tarballs and hard coded versions in spec
files if for no other reason than to expedite the fedora package review process.
 but other solutions may be possible....

Ok, I have gone ahead and moved the major version into the SPEC file because I
can't think of any other way to get it from the source.  I am still pulling the
versions for the various directories during the install time.  

Spec URL (same as before):
http://oss.tresys.com/projects/slide/browser/trunk/build/SPEC/eclipse-slide.spec
SRPM URL (new):
http://oss.tresys.com/projects/slide/chrome/site/srpm/eclipse-slide-1.2.4-4.src.rpm

Well,
http://koji.fedoraproject.org/koji/taskinfo?taskID=248358

root.log says:
0:perl-XML-XPath-1.13-4.fc8.1.noarch
0:jpackage-utils-1.7.3-1jpp.3.fc8.noarch
1:eclipse-pde-3.3.0-30.fc8.ppc
0:ant-1.7.0-1jpp.2.fc8.ppc
0:javacc-4.0-3jpp.3.ppc
No Package Found for eclipse-setools

Sorry about that.  The eclipse-setools plugin is something created to expose the
SETools Java bindings into eclispe and still keep SLIDE platform independent.

I have created a new review request for the eclipse-setools RPM.  It is bug
390571.  I'm not sure I have added this in the 'depends on' list.

I'm not sure if that needs to be accepted before this can continue or what?

Yes, eclipse-setools must be accepted first in this case.

Update your srpm if you have some fixes for it (now I approved
eclipse-setools)

Yes, I have made fixes based on the experience of eclipse-setools.  I have
posted updated the SPEC and src.rpm

Spec URL (same as before):
http://oss.tresys.com/projects/slide/browser/trunk/build/SPEC/eclipse-slide.spec
SRPM URL (new):
http://oss.tresys.com/projects/slide/chrome/site/srpm/eclipse-slide-1.3.4-0.1.svn2002.src.rpm

I guess this still needs to wait for eclipse-setools to actually be in rawhide
though.

(Removing NEEDSPOSOR as I am now sponsoring)

(In reply to comment #16)
> I guess this still needs to wait for eclipse-setools to actually be in rawhide
> though.

Well, actually I want to wait...

I think this should be ready to be looked at again.  The dependency
eclipse-setools-3.3.2 is now comitted into rawhide.

Spec URL (same as before):
http://oss.tresys.com/projects/slide/browser/trunk/build/SPEC/eclipse-slide.spec
SRPM URL (new):
http://oss.tresys.com/projects/slide/chrome/site/srpm/eclipse-slide-1.3.4-1.src.rpm

I just tried to rebuild 1.3.4-1 but it failed.
http://koji.fedoraproject.org/koji/taskinfo?taskID=276128

Note:
Now you can try to rebuild arbitrary srpm on koji by:
$ koji build --scratch <target> <srpm_you_want_to_try>

Currently <target> can be dist-f9, dist-f8-updates-candidate,
or dist-fc7-updates-candidate.
If your scratch build is successful, the result rpms and some logs are
put under
http://koji.fedoraproject.org/scratch/<your_FAS_name>/task_<task_id>/

Ok, looks like I was missing a BuildRequires for a required library.  It built
ok for me http://koji.fedoraproject.org/koji/taskinfo?taskID=276513

Spec URL (same as before):
http://oss.tresys.com/projects/slide/browser/trunk/build/SPEC/eclipse-slide.spec
SRPM URL (new):
http://oss.tresys.com/projects/slide/chrome/site/srpm/eclipse-slide-1.3.4-2.src.rpm

Thanks

Well, for 1.3.4-2:

* tarball
----------------------------------------------------
[tasaka1@localhost eclipse-slide]$ md5sum */*gz *gz
70bb33c5cefa58dee2f37d7b517f36d4  eclipse-slide-1.3.4-1/eclipse-slide-1.3.4.tar.gz
907a77bf709a4a571c6013bf73988297 
eclipse-slide-1.3.4-2.fc9/eclipse-slide-1.3.4.tar.gz
70bb33c5cefa58dee2f37d7b517f36d4  eclipse-slide-1.3.4.tar.gz
----------------------------------------------------
  - The tarball in -2 srpm differs from what I downloaded from
    the URL written as Source0 ?

* License
  - This software is licensed under GPLv2
      by slide-plugin/COPYING and slide-plugin/lib/output.py)

    However some files are licensed under EPL (Eclipse Public
    License 1.0) which is GPL _incompatible_
----------------------------------------------------
(Under slide-plugin)
./src/com/tresys/slide/plugin/views/policyexplorer/IPolicyExplorer.java
./src/com/tresys/slide/plugin/views/policyexplorer/PolicyExplorerView.java
./src/com/tresys/slide/plugin/views/policyexplorer/PolicyFrameSource.java
(and many others)
----------------------------------------------------

    And eclipse(-platform) itself is licensed under EPL and
    policycoreutils is licensed under GPLv2+ ???

* Vendor tag
----------------------------------------------------
Vendor: Tresys Technology, LLC
----------------------------------------------------
  - I forgot to mention on eclipse-setools review request,
    however please remove this line (for Fedora packaging).
    Fedora automatically uses "Fedora Project" for Vendor.

Setting FE-Legal

Ok,

I'm not sure why the didn't match.  But I have made a clean source tarball and
fresh src.rpm.  

I checked each file that was not correctly licensed and what happened is that a
developer copied sample code (including the license).  The code is significantly
different than the original sample so I have corrected the license (in the new
tarball and src.rpm).

No problem with the vendor tag - in both spec files.

I'm not exactly sure what your question is about eclispe(-platform) being
licensed at EPL and policycoreutils at GPLv2+.  eclipse-slide wouldn't need to
match the license of any of the code it is dependant on.  

Spec URL (same as before):
http://oss.tresys.com/projects/slide/browser/trunk/build/SPEC/eclipse-slide.spec
SRPM URL
(new):ttp://oss.tresys.com/projects/slide/chrome/site/srpm/eclipse-slide-1.3.4-3.src.rpm

the above URL should be:
http://oss.tresys.com/projects/slide/chrome/site/srpm/eclipse-slide-1.3.4-3.src.rpm

Well,
- Still slide-plugin/src/com/tresys/slide/utility/StringMatcher.java
  is licensed under EPL
- And do you surely have the right to relicense the files you did?
- Also I still wonder if eclipse-slide (licensed under GPLv2) can be
  used with eclipse-platform (GPL incompatible). Spot, would you
  suggest to us?

Note:
- You should not change the "formal" tarball you once released
  without changing version of the tarball.

Ok, sorry, I missed StringMatcher - that was a recent addition by someone
working with me.  We have removed that file and did the same functionality a
different way. 

I did not change the formal tarball version because there was no funtional
changes, just comments.  With this version I have gone back to the SVN
versioning because it is again a pre-release and there are functional changes to
the 1.3.4 public release.

Spec URL (same as before):
http://oss.tresys.com/projects/slide/browser/trunk/build/SPEC/eclipse-slide.spec
SRPM URL (new):
http://oss.tresys.com/projects/slide/chrome/site/srpm/eclipse-slide-1.3.5-0.1.svn2022.src.rpm


I think this URL describes answers the question if we have the right to
relicense the files that we did.  Because we only used the files as a starting
point and they were significantly changed from the original it is ok.
http://www.eclipse.org/legal/eplfaq.php#EXAMPLE

Well, now I want to wait a comment from spot.

Yup, that seems like a good action, I just wanted to get my comments in.

Looks ok to me. Lifting FE-Legal.

Well,
For 1.3.5-0.1.svn2022:

* Release number
  - Please use 0.X.svnYYYY%{?dist} to avoid EVR
    (Epoch-Version-Release) path problem between different branches.

Okay.
--------------------------------------------------------
   This package (eclipse-slide) is APPROVED by me
--------------------------------------------------------

I have changed the release number, thanks.

New Package CVS Request
=======================
Package Name: eclipse-slide
Short Description: SELinux Policy IDE Eclipse Plugin
Owners: dsugar
Branches: F-7 F-8 EL-5
InitialCC: 
Cvsextras Commits: yes

cvs done.

committed into cvs and built under devel. 
marking ready for NEXTRELEASE