Bug 426884 - Review Request: eclipse-epic - Perl Eclipse plugin
Review Request: eclipse-epic - Perl Eclipse plugin
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
rawhide
All Linux
low Severity medium
: ---
: ---
Assigned To: Andrew Overholt
Fedora Extras Quality Assurance
:
Depends On: 426883
Blocks:
  Show dependency treegraph
 
Reported: 2007-12-27 18:14 EST by Mat Booth
Modified: 2008-05-18 20:56 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-05-18 20:56:44 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
overholt: fedora‑review+
kevin: fedora‑cvs+


Attachments (Terms of Use)
Variables View Screenshot (29.12 KB, image/png)
2008-04-28 17:19 EDT, Mat Booth
no flags Details

  None (edit)
Description Mat Booth 2007-12-27 18:14:05 EST
Spec URL: http://www.matbooth.co.uk/fedora/eclipse-epic.spec
SRPM URL: http://www.matbooth.co.uk/fedora/eclipse-epic-0.6.17-1.fc8.src.rpm
Description: EPIC is an open source Perl IDE based on the Eclipse platform. Features supported are syntax highlighting, on-the-fly syntax check, content assist, perldoc support, source formatter, templating support, a regular expression view and a Perl debugger.

This package was originally requested in bug #315661.

This package is dependent on brazil (bug #426883), which EPIC uses for its embedded CGI webserver, so please build and install that package before attempting to build this one.

---

Rpmlint on the source rpm gives the following:

eclipse-epic.src: W: strange-permission get-epic.sh 0755

This is only the script that checks the source out of CVS and generates the source tarball, which is deliberately executable. It can safely be ignored.

Rpmlint also gives the following warnings:

eclipse-epic.i386: W: dangling-symlink /usr/share/eclipse/plugins/org.epic.lib_0.6.0/lib/antlr.jar /usr/share/java/antlr.jar
eclipse-epic.i386: 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.i386: W: dangling-symlink /usr/share/eclipse/plugins/org.epic.lib_0.6.0/lib/brazil.jar /usr/share/java/brazil.jar
eclipse-epic.i386: 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.i386: W: dangling-symlink /usr/share/eclipse/plugins/org.epic.lib_0.6.0/lib/jdom.jar /usr/share/java/jdom.jar
eclipse-epic.i386: 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.i386: 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.i386: 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 links are necessary to tell EPIC where certain libraries are that it needs in order to run, these libs are listed as dependencies so they will always be present. I've based my package somewhat on other eclipse-* packages, some of whom have done the same as I have here (eclipse-quickrex, for example), so I believe these can also be safely ignored.

---

I've also submitted another package for review (bug #426883) which this package is dependent on. These are my first packages so I'm also looking for sponsorship. While I've been working on this package I've given some pre-reviews on bug #417711 and bug #420161 and I'm planning to do more as time permits.

Thanks for your time.
Comment 1 Mat Booth 2008-02-20 15:30:54 EST
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
Comment 2 Mat Booth 2008-02-26 14:56:33 EST
I notice this has been tagged as blocking F-GUIDELINES. Can anybody tell me I'm
doing wrong?
Comment 3 Mat Booth 2008-02-26 14:58:06 EST
Can anybody tell me *what* I'm doing wrong, even. Bugzilla needs a preview
button, obviously. :-)
Comment 4 Andrew Overholt 2008-02-26 15:02:23 EST
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.
Comment 5 Mat Booth 2008-03-30 10:42:50 EDT
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?
Comment 6 Jack Tanner 2008-03-30 11:40:17 EDT
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?
Comment 7 Andrew Overholt 2008-03-31 09:25:45 EDT
Note that the Eclipse plugin packaging guidelines will hopefully be accepted by
the Fedora Packaging Committee at their meeting this week.
Comment 8 Andrew Overholt 2008-04-09 11:56:01 EDT
The Eclipse plugin packaging guidelines have now been ratified by the FPC and FESCo.
Comment 9 Mat Booth 2008-04-13 09:18:02 EDT
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.
Comment 10 Andrew Overholt 2008-04-17 11:59:27 EDT
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!
Comment 11 Jason Tibbitts 2008-04-17 15:20:00 EDT
This is a bit confusing; why is the ticket assigned to the reporter?  It should
be assigned to the reviewer.
Comment 12 Andrew Overholt 2008-04-17 16:00:06 EDT
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.
Comment 13 Jason Tibbitts 2008-04-17 17:58:04 EDT
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@fp.org 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.

Comment 14 Andrew Overholt 2008-04-18 08:27:29 EDT
(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.
Comment 15 Jason Tibbitts 2008-04-18 14:21:16 EDT
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 '?'.
Comment 16 Andrew Overholt 2008-04-18 14:41:21 EDT
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.
Comment 17 Mat Booth 2008-04-19 04:16:48 EDT
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

Comment 18 Andrew Overholt 2008-04-21 10:31:42 EDT
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?
Comment 19 Jack Tanner 2008-04-21 21:16:11 EDT
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).
Comment 20 Andrew Overholt 2008-04-22 08:34:36 EDT
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.
Comment 21 Jack Tanner 2008-04-28 11:46:22 EDT
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?)
Comment 22 Mat Booth 2008-04-28 17:19:02 EDT
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?
Comment 23 Mat Booth 2008-04-28 20:46:20 EDT
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
Comment 24 Andrew Overholt 2008-04-28 22:56:39 EDT
(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.
Comment 25 Andrew Overholt 2008-04-28 23:07:03 EDT
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 :)
Comment 26 Mat Booth 2008-04-29 04:32:05 EDT
(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!
Comment 27 Mat Booth 2008-04-29 04:34:50 EDT
New Package CVS Request
=======================
Package Name: eclipse-epic
Short Description: Perl Eclipse plugin
Owners: mbooth
Branches: F-9
InitialCC: 
Cvsextras Commits: yes
Comment 28 Lubomir Kundrak 2008-04-29 07:55:16 EDT
Mat: I'd appreciate this in F-8. If you have a reason not to maintain it there,
I'd gladly do so.
Comment 29 Kevin Fenzi 2008-04-29 11:18:21 EDT
cvs done.

Let me know if you want a F-8 branch and who should own it... 
Comment 30 Mat Booth 2008-04-29 18:36:18 EDT
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.
Comment 31 Mat Booth 2008-04-29 18:39:22 EDT
Package Change Request
======================
Package Name: eclipse-epic
New Branches: F-8
Comment 32 Kevin Fenzi 2008-04-29 19:04:12 EDT
cvs done.
Comment 33 Mat Booth 2008-04-30 10:53:41 EDT
(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.
Comment 34 Andrew Overholt 2008-04-30 11:22:13 EDT
(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 :)
Comment 35 Jack Tanner 2008-04-30 15:03:17 EDT
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?
Comment 36 Mat Booth 2008-04-30 16:00:41 EDT
(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.
Comment 37 Jack Tanner 2008-05-01 13:18:32 EDT
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. 
Comment 38 Mat Booth 2008-05-08 08:32:13 EDT
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?
Comment 39 Andrew Overholt 2008-05-08 09:38:07 EDT
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.
Comment 40 Kevin Fenzi 2008-05-08 11:53:09 EDT
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@fedoraproject.org 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?
Comment 41 Mat Booth 2008-05-08 12:23:18 EDT
(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@fedoraproject.org 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.
Comment 42 Kevin Fenzi 2008-05-08 13:23:50 EDT
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. :) 
Comment 43 Mat Booth 2008-05-18 20:56:44 EDT
Built for all requested branches on all arches, finally... Closing.

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