Bug 426884

I've updated the source to the latest version. New spec file and srpm are as
follows:

Spec URL: http://www.matbooth.co.uk/fedora/eclipse-epic.spec
SRPM URL: http://www.matbooth.co.uk/fedora/eclipse-epic-0.6.20-1.fc8.src.rpm

I notice this has been tagged as blocking F-GUIDELINES. Can anybody tell me I'm
doing wrong?

Can anybody tell me *what* I'm doing wrong, even. Bugzilla needs a preview
button, obviously. :-)

I assume this is because the Eclipse guidelines aren't yet finished.  I don't
believe they should be blocking this, but that's not really my call.

I've updated the source to the latest version. New spec file and srpm are as
follows:

Spec URL: http://www.matbooth.co.uk/fedora/eclipse-epic.spec
SRPM URL: http://www.matbooth.co.uk/fedora/eclipse-epic-0.6.22-1.fc9.src.rpm

What happens now F9 is in beta? Will this have to wait 'til F10?

Matt, I don't think this will have to wait until F10. I'm sure that even today,
you can build new packages for F8, for example. Still, could someone please give
the necessary sponsorship and review?

Note that the Eclipse plugin packaging guidelines will hopefully be accepted by
the Fedora Packaging Committee at their meeting this week.

The Eclipse plugin packaging guidelines have now been ratified by the FPC and FESCo.

I have updated this package according to the newly approved guidelines. The spec
and srpm are as follows:

Spec URL: http://www.matbooth.co.uk/fedora/eclipse-epic.spec
SRPM URL: http://www.matbooth.co.uk/fedora/eclipse-epic-0.6.22-2.fc9.src.rpm

Rpmlint on the source rpm is now silent.

Rpmlint on the binary rpms gives the following output, which is the same as in
my original post above:

eclipse-epic.x86_64: W: dangling-symlink
/usr/share/eclipse/plugins/org.epic.lib_0.6.0/lib/brazil.jar
/usr/share/java/brazil.jar
eclipse-epic.x86_64: W: symlink-should-be-relative
/usr/share/eclipse/plugins/org.epic.lib_0.6.0/lib/brazil.jar
/usr/share/java/brazil.jar
eclipse-epic.x86_64: W: dangling-symlink
/usr/share/eclipse/plugins/org.epic.lib_0.6.0/lib/jdom.jar /usr/share/java/jdom.jar
eclipse-epic.x86_64: W: symlink-should-be-relative
/usr/share/eclipse/plugins/org.epic.lib_0.6.0/lib/jdom.jar /usr/share/java/jdom.jar
eclipse-epic.x86_64: W: dangling-symlink
/usr/share/eclipse/plugins/org.epic.lib_0.6.0/lib/antlr.jar
/usr/share/java/antlr.jar
eclipse-epic.x86_64: W: symlink-should-be-relative
/usr/share/eclipse/plugins/org.epic.lib_0.6.0/lib/antlr.jar
/usr/share/java/antlr.jar
eclipse-epic.x86_64: W: dangling-symlink
/usr/share/eclipse/plugins/org.epic.lib_0.6.0/lib/gnu-regexp.jar
/usr/share/java/gnu-regexp.jar
eclipse-epic.x86_64: W: symlink-should-be-relative
/usr/share/eclipse/plugins/org.epic.lib_0.6.0/lib/gnu-regexp.jar
/usr/share/java/gnu-regexp.jar

These are symlinks to libraries provided by other Fedora packages. I still
believe these can safely be ignored.

I'll take this.

I can't build your current SRPM:

+ cd epic-0.6.22
/var/tmp/rpm-tmp.42670: line 33: cd: epic-0.6.22: Permission denied
error: Bad exit status from /var/tmp/rpm-tmp.42670 (%prep)

There seem to be wacky permissions or something.

Rather than doing this:

ln -s %{_javadir}/jdom.jar %{_javadir}/antlr.jar %{_javadir}/gnu-regexp.jar
%{_javadir}/brazil.jar .

You could use build-jar-repository or build-classpath.  I don't think it's a big
deal either way, though.

Otherwise, things look good!

This is a bit confusing; why is the ticket assigned to the reporter?  It should
be assigned to the reviewer.

I thought I had to assign it back to him to indicate I couldn't build the SRPM.
 Should it stay assigned to me after I take the review?  I've always been
unclear on review bug assignments during the process and couldn't find anything
on the wiki.

Yes, the ticket should stay assigned to the reviewer pretty much permanently;
the only situation I can think of when the assignment would change is when a
review ticket is handed off to another reviewer, or assigned back to
nobody in the case that the reviewer is somehow removed from the process.

> I've always been unclear on review bug assignments during the process and
> couldn't find anything on the wiki.

Well, there's http://fedoraproject.org/wiki/PackageReviewProcess which pretty
much sums it up.

(In reply to comment #13)
> > I've always been unclear on review bug assignments during the process and
> > couldn't find anything on the wiki.
> 
> Well, there's http://fedoraproject.org/wiki/PackageReviewProcess which pretty
> much sums it up.

I think I was confused because step 4 under "Reviewer" doesn't specify whether
or not to re-assign to the submitter.  IMO it would make sense to re-assign to
the submitter when work is needed.

Well, it doesn't mention it because it's not something that's done.  It would be
a pretty long document if it had to indicate all of the things that you don't do.

The submitter should know from the comments when there's something for them to
do.  If they don't respond, needinfo(reporter) works just fine.  Keeping the
ticket assigned lets everyone know who the package submitter is (since they show
as "Reporter") and who the reviewer is (since they show up in "Assigned to"). 
Currently it looks like Mat is reviewing this ticket, which throws up various
flags for the people like me who monitor these things.

In any case, this really isn't the place to discuss changing the review process
which has worked about as well as bugzilla will allow for a few thousand
packages.  If you want to have the procedure changed, you're welcome to bring it
up on-list.

Currently, though, if you are going to review this, please assign it to your
self and set the fedora-review flag to '?'.

Removing NEEDSPONSOR since I already sponsored Mat for some other work he did on
the Eclipse package.

Mat:  I still need an SRPM I can build.

I've had a stab (in the dark, since I can't seem to reproduce it) at fixing it.
Also I've used build-jar-repository, that looks a lot cleaner. Thanks for the tip.

Try these:

Spec URL: http://www.matbooth.co.uk/fedora/eclipse-epic.spec
SRPM URL: http://www.matbooth.co.uk/fedora/eclipse-epic-0.6.22-3.fc9.src.rpm

Thanks for the submission, Mat.  Everything looks great.  I have a few
questions below.  When we clear these up, be sure to take EPIC off the
PackageRequests page on the Fedora wiki :)

- there are lots of antlr warnings - do you think these are okay?
- are there any unit tests for EPIC which we can use to verify the JDOM API changes?
- any idea what's going on with the debuginfo extraction?  I get lots of
  the following.  I'm not super-concerned, since this is gcj debuginfo
  and the chances of anyone other than gcj developers being able to use
  it successfully is low :)

  extracting debug info from
/var/tmp/eclipse-epic-0.6.22-3.fc8-root-overholt/usr/lib/gcj/eclipse-epic/org.epic.regexp_0.6.1.jar.so
  extracting debug info from
/var/tmp/eclipse-epic-0.6.22-3.fc8-root-overholt/usr/lib/gcj/eclipse-epic/org.epic.perleditor_0.6.15.jar.so
  extracting debug info from
/var/tmp/eclipse-epic-0.6.22-3.fc8-root-overholt/usr/lib/gcj/eclipse-epic/org.epic.debug_0.6.16.jar.so
  cpio:
epic-0.6.22/aot-compile-rpm/usr/lib/gcj/eclipse-epic/org.epic.debug_0.6.16.jar.1.jar:
Cannot stat: No such file or directory
  cpio:
epic-0.6.22/aot-compile-rpm/usr/lib/gcj/eclipse-epic/org.epic.perleditor_0.6.15.jar.1.jar:
Cannot stat: No such file or directory
  cpio:
epic-0.6.22/aot-compile-rpm/usr/lib/gcj/eclipse-epic/org.epic.perleditor_0.6.15.jar.2.jar:
Cannot stat: No such file or directory
  cpio:
epic-0.6.22/aot-compile-rpm/usr/lib/gcj/eclipse-epic/org.epic.regexp_0.6.1.jar.1.jar:
Cannot stat: No such file or directory
  cpio:
epic-0.6.22/aot-compile-rpm/usr/lib/gcj/eclipse-epic/org/epic/core/Constants.java:
Cannot stat: No such file or directory
  cpio:
epic-0.6.22/aot-compile-rpm/usr/lib/gcj/eclipse-epic/org/epic/core/PerlCore.java:
Cannot stat: No such file or directory

- rpmlint warnings are okay to be waived
- requires and provides look fine
- functionality seems okay but I get an error when trying to debug about
  variable display needing PadWalker.  Should we add perl-PadWalker to
  the Requires?  Even if I have that installed, I don't get variables
  when debugging.  Should I / do you?

Speaking as a long-time EPIC user, yes, perl-PadWalker should be in Requires. By
default, with it installed, you should see 'my' variables when debugging. You
can also turn on global variables (off by default).

Jack:  can you try Mat's packages and install perl-PadWalker and see why
variables aren't showing up?  Or maybe they are and it's just something wacky on
my box.

I was going to test Mat's packages but then I hit bug #444477. Meh.

Mat, could you put up a binary x86-64 RPM of EPIC? (And any runtime requirements?)

Created attachment 304046 [details]
Variables View Screenshot

Sorry guys, yes PadWalker should be required. I must have already had it
installed. It's a bit concerning you can't see any variables even after
installing it. I've attached an example screenshot of what you should be
seeing.

> - there are lots of antlr warnings - do you think these are okay?

To be honest, I don't really know what half of those antlr warnings even mean
since grammar parsing is not something I've ever done myself. Everything seems
to work ok though, so my philosophy on this has been "warnings are not errors."
:-)

I will post links to binary rpms in a minute for you Jack, maybe you can have a
quick check to see if there is anything obviously wrong with the syntax
highlighting, auto-completion and what have you.

> - are there any unit tests for EPIC which we can use to verify the JDOM API
changes?

I don't think so, upstream admits his test suite is "very incomplete." However,
if you add paths to your project's Perl Include Path property sheet, it
correctly saves an xml .includepath settings file in your project directory and
is able to find external Perl modules using it. This is only place where the
code I've patched is used.

> - any idea what's going on with the debuginfo extraction?  I get lots of
>   the following.  I'm not super-concerned, since this is gcj debuginfo
>   and the chances of anyone other than gcj developers being able to use
>   it successfully is low :)

This one I'm not sure about. I just added the gcj lines that the guidelines
told me to add in, so I figured it was normal. Would it be worth asking someone
who knows a bit more about it to see if it's a problem?

I've added the PadWalker dependency and I also noticed the source plugin wasn't
being built properly, so I've fixed that too. New SPEC and SRPM are as follows:

Spec URL: http://www.matbooth.co.uk/misc/fedora/eclipse-epic.spec
SRPM URL: http://www.matbooth.co.uk/misc/fedora/eclipse-epic-0.6.22-4.fc9.src.rpm

(Binaries:)
http://www.matbooth.co.uk/misc/fedora/brazil-2.3-3.fc9.x86_64.rpm
http://www.matbooth.co.uk/misc/fedora/eclipse-epic-0.6.22-4.fc9.x86_64.rpm

(In reply to comment #22)
> > - there are lots of antlr warnings - do you think these are okay?
> 
> To be honest, I don't really know what half of those antlr warnings even mean
> since grammar parsing is not something I've ever done myself. Everything seems
> to work ok though, so my philosophy on this has been "warnings are not errors."
> :-)

That's fine by me :)

> > - are there any unit tests for EPIC which we can use to verify the JDOM API
> changes?
> 
> I don't think so, upstream admits his test suite is "very incomplete." However,
> if you add paths to your project's Perl Include Path property sheet, it
> correctly saves an xml .includepath settings file in your project directory and
> is able to find external Perl modules using it. This is only place where the
> code I've patched is used.

That works for me.

> > - any idea what's going on with the debuginfo extraction?  I get lots of
> >   the following.  I'm not super-concerned, since this is gcj debuginfo
> >   and the chances of anyone other than gcj developers being able to use
> >   it successfully is low :)
> 
> This one I'm not sure about. I just added the gcj lines that the guidelines
> told me to add in, so I figured it was normal. Would it be worth asking someone
> who knows a bit more about it to see if it's a problem?

I think this might be:

http://www.redhat.com/archives/fedora-devel-list/2007-November/msg01948.html

which I'm probably seeing more so because I'm building on an F8 system.

Okay, I'm content to say that it's my system (F8 with lots of odd Eclipse stuff
on it) that's causing my missing-variables-in-debug-perspective issue if you can
see them.  If we run into issues, we can fix them later.

This package is APPROVED.  Thanks, Mat!  Don't forget to take EPIC off the
Packaging/Wishlist on the Fedora wiki :)

(In reply to comment #25)
> Okay, I'm content to say that it's my system (F8 with lots of odd Eclipse stuff
> on it) that's causing my missing-variables-in-debug-perspective issue if you can
> see them.  If we run into issues, we can fix them later.
> 
> This package is APPROVED.  Thanks, Mat!  Don't forget to take EPIC off the
> Packaging/Wishlist on the Fedora wiki :)

Will do, cheers!

New Package CVS Request
=======================
Package Name: eclipse-epic
Short Description: Perl Eclipse plugin
Owners: mbooth
Branches: F-9
InitialCC: 
Cvsextras Commits: yes

Mat: I'd appreciate this in F-8. If you have a reason not to maintain it there,
I'd gladly do so.

cvs done.

Let me know if you want a F-8 branch and who should own it... 

Sure, I don't mind maintaining an F-8 branch.

(In reply to comment #26)
> (In reply to comment #25)
> > Thanks, Mat!  Don't forget to take EPIC off the
> > Packaging/Wishlist on the Fedora wiki :)
> 
> Will do, cheers!

The wiki signup page seems to be out of action at the moment. I was advised in
#fedora-websites to keep trying, so I will.

Package Change Request
======================
Package Name: eclipse-epic
New Branches: F-8

cvs done.

(In reply to comment #26)
> (In reply to comment #25)
> > Thanks, Mat!  Don't forget to take EPIC off the
> > Packaging/Wishlist on the Fedora wiki :)
> 
> Will do, cheers!

Finally got signed up for the wiki. Would you be able to add me to the
EditGroup? My user name there is MatBooth.

(In reply to comment #33)
> (In reply to comment #26)
> > (In reply to comment #25)
> > > Thanks, Mat!  Don't forget to take EPIC off the
> > > Packaging/Wishlist on the Fedora wiki :)
> > 
> > Will do, cheers!
> 
> Finally got signed up for the wiki. Would you be able to add me to the
> EditGroup? My user name there is MatBooth.

Done.  Please create a page for yourself:  MatBooth.  I didn't realize you
hadn't already and you're technically supposed to have one first.  Please do it
quickly :)

Mat's binary RPMS from comment 23 work for me. I do see 'my' variables during
debugging, as expected. Great job, Mat!

I'm a bit curious about gnu-regexp. Why is that actually required?

(In reply to comment #35)
> Mat's binary RPMS from comment 23 work for me. I do see 'my' variables during
> debugging, as expected. Great job, Mat!
> 

Thanks for checking that, cheers.

> I'm a bit curious about gnu-regexp. Why is that actually required?

It's used in the debugger and in the regex view.

The following comments are from the upstream EPIC developer, jploski. See
http://sourceforge.net/forum/message.php?msg_id=4939149

Tracking the unstable branch is good. 
 
Regarding the review, I don't have much to add. The ANTLR warnings are because
the grammar specifications were hacked together in hurry (a trial-and-error
process more than relying on any specifications). As far as the test suites are
concerned, there are two of them: the first one - classes in
"org.epic.perleditor-test/src" - contains low-level standalone JUnit tests that
don't generate false alarms. Perhaps the most valuable among them are those that
exercise the ANTLR grammars. The second test suite - classes in
"org.epic.perleditor-test/src-pde" - contains JUnit tests that can only be run
within a hosted Eclipse workbench. Some of them do generate false alarms
depending on the environment - they are basically only guaranteed to run on my
machine. 

Eclipse-epic should build for rawhide (when xulrunner is next rebuilt) but I'm
not really sure what the crack is with Bodhi, information is a bit scarce on the
wiki. Do I need brazil to be pushed to a repository before I can build
eclipse-epic for the other branches?

Is brazil built for F-9?  If so, and it's available in the F-9 repos, you should
just be able to build eclipse-epic there.  Bodhi is just the update system which
you use to push updates to released distributions.

I dont see brazil in the F-9 repos... it must have been built after the freeze. 
So, you will need to use bodhi to release it as a F-9 update (and F-8). 

If you need it to build other packages (like this one), you can either wait
until it's been pushed in bodhi, or you can mail rel-eng and
request it be added to the buildroot for F-9/F-8 so you can built this and push
it as an update at the same time. ;) 

Make sense?

(In reply to comment #40)
> I dont see brazil in the F-9 repos... it must have been built after the freeze. 

It was.

> So, you will need to use bodhi to release it as a F-9 update (and F-8). 
> 
> If you need it to build other packages (like this one), you can either wait
> until it's been pushed in bodhi, or you can mail rel-eng and
> request it be added to the buildroot for F-9/F-8 so you can built this and push
> it as an update at the same time. ;) 
> 
> Make sense?

Yes, thanks. It wasn't obvious to me that builds don't appear in Koji's build
root (is it just me or is that a bit misleading?) until after it gets pushed as
an update.

Yeah, new packages don't add to the buildroot in release branches to make sure
and prevent something building against an update and then getting pushed out,
but the package it built against not being pushed for some reason. :) 

Built for all requested branches on all arches, finally... Closing.