Red Hat Bugzilla – Bug 166255
Review Request: Sprog
Last modified: 2007-11-30 17:11:12 EST
Spec Url: http://www.perl.me.uk/downloads/modules/Sprog.spec
SRPM Url: http://www.perl.me.uk/downloads/modules/Sprog-0.14-2.src.rpm
Description: Sprog is a tool for working with data. It allows you to do all the things those clever Unix geeks can do with their cryptic command lines but you can now do it all with point-n-click and drag-n-drop.
If I change:
The whole build fails.
What is actually wrong with:
Change it to:
The "|| :" after %check is redundant unless you're targeting very old (certainly
pre-Fedora) distros with your specfile.
As I said, the build fails without %check ||:
Created attachment 117906 [details]
New spec file to address %check issue
Try the attached spec file - builds fine for me in FC4. Won't build in the
Extras buildsystem until all the deps are available.
Seems the dep perl-Apache-LogRegex didn't make it through the build process for
the devel branch. The rest of the deps did get built. Can you push out a build
I thought I did. The Makefile seemed to have the name "meld" in it, so make tag
It is queued to build now.
Can't get this to build against current development tree.
The blasted perl-Template-Toolkit package requires perl(XML::DOM)
which used to be provided by perl-libxml-enno
which was removed from Core on 20050921
nothing in developmnent right now provides perl(XML::DOM) so we are kinda stuck.
I've opened a bug ticket against perl-Template-Toolkit
I might be able to dig up a cachsed version of -enno so I can build this locally
outside of mock to get this review done.
okay i dug up a version of perl-libxml-enno and got Sprog to build locally.
Everything checks out on the MUST list of review items... except...
sprog needs a .desktop file since its a gui app.
So there are 2 outstanding issues right now
1) perl(Template) is a requires and a buildrequires.. but is a blocker to
getting this built until perl-Template-Toolkit is corrected to fix its dep problem
2) sprog needs a .desktop file.
Nothing we can do about #1. But in the meantime can you spin up a new srpm that
includes a .desktop file and the associated scriptlets.
I'll see to 2.
Okay looks like the perl(Template) is now available to build against. Are you
prepared to hand out a srpm that takes care of the .desktop file issue? We
might be able to finally get this sucker built against devel tree this weekend
and the review finished.
Yeah. Soon as I get a sec ;-)
Finally done, with correct desktop file, icon as per Grant's request and a patch
to fix some non-fatal build tests failing (provided by Grant).
Sorry it took so long to get back to this.
I'm having trouble getting to the http://www.perl.me.uk/downloads/modules/
Okay... Sprog-0.14-4.noarch.rpm builds in mock against fedora core development
rpnlint returns clean for mock built Sprog-0.14-4.fc5.noarch.rpm
specfile and packagenaming are good
Licensed as perl: GPL or Artistic
Has a desktop file.
no pre/post scriplets
md5sum of Source in srpm agrees with upstream source url in spec.
listed buildrequires look good
no shared or static libs
owns all the directories it creates
no -devel subpackage needed
patch to turn off some bogus test results in mock/buildsystem looks fine
mock built package seems to work on shallow functionality testing
Doesn't BuildRequires: desktop-file-utils
doesn't use desktop-file-install in %install
*need to add desktop-file-utils usage as outlined in
*Need to remove the explicit license files being created from perdoc
There was a policy change the policy now reads:
- MUST: If (and only if) the source package includes the text of the license(s)
in its own file, then that file, containing the text of the license(s) for the
package must be included in %doc.
I've made the necessary changes in Sprog-0.14-5.src.rpm
I'm starting the clock for approval. If I don't hear anything back about
problems with Sprog-0.14-5 I'll approve this in 24 hours.
My fault, sorry. Was setting up Catalyst on that domain, and forgot to put it back.
Okay not quite 24 hours, but close.
Sprog-0.14-5.fc5.src.rpm is approved for FE development.
So is this package in limbo or what?
I don't think so. It's been commited, so not sure what is next.
Cheers for the kick Ignacio
Rebuilt to test everythign is still ok as Sprog-0.14-6.src.rpm. Commited to
I tried installing Sprog for FC-4 from here:
just for kicks, just to see if the appropriate requires would be pulled in from
FE on FC-4, and I found that
have not yet been built for FC-4, although they all _do_ have branches for FC-4
in CVS (and hence work in devel). While you are waiting for the sprog FC-4
branch to be created, perhaps these deps can be built for FC-4 just to make sure
it will work.
(In reply to comment #22)
> While you are waiting for the sprog FC-4 branch to be created, perhaps
> these deps can be built for FC-4 just to make sure it will work.
bug #182455, bug #182458, bug #182459
wtf.. can we PLEASE not overload this initial review bugreport concerning
requests to build the fc4 branch. requests for fc4 branch builds should not
block initial review request report resolution.
as soon as sprog is built in devel.. this bug is going to be closed..
regardless.. of what the blocker status is concerning fc4 branch request.
Because as a reviewer who has taken on assignment for this bug this is outside
the scope of what the review request bug covers.
(In reply to comment #24)
> as soon as sprog is built in devel.. this bug is going to be closed..
> regardless.. of what the blocker status is concerning fc4 branch request.
> Because as a reviewer who has taken on assignment for this bug this is outside
> the scope of what the review request bug covers.
Sprog's been built. Waiting for being signed and pushed. Sorry for the noise,
I didn't realise that Sprog bugzilla component had already been created. I've
created a bug now: bug #182461.
I've opened up bugs on dependent package, but I didn't make them blockers on
this one, I'll switch them to above. ;-) That's the last from me.
Looks like this package is imported and built. Please close this ticket or
explain why it needs to stay open...
package is imported and built... PLEASE remember to close package review when
imported into cvs etc