Bug 189092 - Review Request: boo
Review Request: boo
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: John Mahowald
Fedora Package Reviews List
:
: 189091 (view as bug list)
Depends On: 193957
Blocks: FE-ACCEPT 178904
  Show dependency treegraph
 
Reported: 2006-04-15 20:22 EDT by Paul F. Johnson
Modified: 2007-11-30 17:11 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-07-26 04:26:40 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
patch to add BuildRequires: boo (484 bytes, text/plain)
2006-07-21 21:38 EDT, David Nielsen
no flags Details

  None (edit)
Description Paul F. Johnson 2006-04-15 20:22:37 EDT
Spec URL: http://www.smmp.salford.ac.uk/packages/boo.spec
SRPM URL: http://www.smmp.salford.ac.uk/packages/boo-0.7.5.2013-1
Description: 

Boo is an OO scripting language for the CLI
Comment 1 Paul F. Johnson 2006-04-15 20:27:06 EDT
*** Bug 189091 has been marked as a duplicate of this bug. ***
Comment 2 Paul F. Johnson 2006-04-17 12:48:37 EDT
Spec URL: http://www.smmp.salford.ac.uk/packages/boo.spec
SRPM URL: http://www.smmp.salford.ac.uk/packages/boo-0.7.5.2013-2.src.rpm

Small fix to the spec file
Comment 3 Paul F. Johnson 2006-04-18 18:12:54 EDT
Spec URL: http://www.smmp.salford.ac.uk/packages/boo.spec
SRPM URL: http://www.smmp.salford.ac.uk/packages/boo-0.7.5.2013-3.src.rpm

libdir set to be /usr/lib irrespective of hardware built on
spec file fixes
Comment 4 John Mahowald 2006-04-22 17:36:38 EDT
Not building.

Processing files: boo-0.7.5.2013-3
error: File not found by glob:
/var/tmp/boo-0.7.5.2013-3-root-mockbuild/usr/share/gtksourceview-1.0/language-specs/*
error: File not found by glob:
/var/tmp/boo-0.7.5.2013-3-root-mockbuild/usr/share/mime/packages/*


Consider using cp -p
Comment 5 Paul F. Johnson 2006-04-27 17:13:26 EDT
Odd. This is building fine outside of mock. Could this be an selinux problem
(ISTR seeing something similar with a C# package reported on the extras list)?
Comment 6 Paul Howarth 2006-04-28 02:45:22 EDT
(In reply to comment #5)
> Odd. This is building fine outside of mock. Could this be an selinux problem
> (ISTR seeing something similar with a C# package reported on the extras list)?

This looks to me more like a missing buildreq than an SELinux issue. Are the
missing files generated by some tool that needs to be buildreq-ed?

I think it would be a very good idea for you to try out a local mock setup as
it's *great* for finding things like this.
Comment 7 Paul F. Johnson 2006-04-28 02:59:03 EDT
Not sure. When I look at the built RPM everything is there. I'll give mock a shot
Comment 8 John Mahowald 2006-05-04 18:20:06 EDT
My latest build attempt on FC5 x86_64 at your latest srpm attempt gives:

Processing files: boo-0.7.5.2013-4
error: File not found: /var/tmp/boo-0.7.5.2013-4-root-mockbuild/usr/lib64/boo
error: File not found by glob:
/var/tmp/boo-0.7.5.2013-4-root-mockbuild/usr/lib64/mono/*
error: File not found by glob:
/var/tmp/boo-0.7.5.2013-4-root-mockbuild/usr/lib64/pkgconfig/*.pc
error: File not found by glob:
/var/tmp/boo-0.7.5.2013-4-root-mockbuild/usr/share/mime/packages/*

Note the /usr/lib64. The build logs are installing that stuff in /usr/lib.
Redefining %{_libdir} is one way to fix this.

Also looking the build logs, it's dropping the /usr prefix for the mime stuff
because the configure script is not figuring out a shared-mime-info prefix.

        Summary:

        shared-mime-info prefix:
        gtksourceview-1.0 prefix: /usr
        boo prefix: /usr

test -z "/share/mime/packages/" || mkdir -p --
"/var/tmp/boo-0.7.5.2013-4-root-mockbuild/share/mime/packages/"
Comment 9 Paul F. Johnson 2006-05-04 19:00:34 EDT
Yep - I'm getting that problem here as well. The configure.in script looks fine
and passing --prefix=/usr on the configure line makes no difference
what-so-ever, so something is going wrong somewhere, I'm just at a loss as to where.
Comment 10 Paul F. Johnson 2006-05-05 18:02:48 EDT
Simple fix - add

export PREFIX=/usr

before the configure line. Compiles correctly using mock (well, I'm saying it
is, unfortunately rpmbuild is shot currently, but it's not giving any errors and
is attempting to do the install step)

As to redefining %libdir - it's pointless.

Inside the makefile.am files there is a line like this (well, it's in
monodevelop and a few others)

pkconfigdir=$(prefix)/lib/pkgconfig

which screws things up somewhat for lots of other bits. I've suggested a fix to
the mono guys tonight (5th May) which alters the .am files to read

pkgconfigdir=$(prefix)/$(libdir)/pkgconfig

The configure script then exports either lib or lib64 depending on what is
passed in using --libdir

This should sort the problems with 64 bit systems currently found.
Comment 11 Ville Skyttä 2006-05-06 06:37:21 EDT
(In reply to comment #10)
> pkgconfigdir=$(prefix)/$(libdir)/pkgconfig
> 
> The configure script then exports either lib or lib64 depending on what is
> passed in using --libdir

Without knowing a thing about mono stuff, that looks wrong to me.  Did you mean
$(prefix)/$(lib)/pkgconfig (or something else that doesn't have the potential of
having the prefix inserted twice in the path)?  $(libdir) usually already
contains $(prefix).
Comment 12 Paul F. Johnson 2006-05-06 07:13:50 EDT
No.

libdir is exported from the config script. Looking in the configure script, it's
the only thing it contains.

When I've run the amended makefile, I've looked to see what is created and it's
whatever you pass in

For example

./configure

Makefile contains

--libdir = $(prefix)/lib

(fine for 32 bit - not so good for 64 bit)

Amend makefile.am so pkgconfigdir=$(prefix)/$(libdir)

./configure --libdir=/usr/lib64

--libdir = $(prefix)/lib64

(correct for 64 bit)

Without the patch, pkgconfigdir remains $(prefix)/lib

which causes problems further down the line when building against the created
rpm (say for MonoDevelop)
Comment 13 Paul F. Johnson 2006-06-01 05:04:33 EDT
Spec URL: http://www.smmp.salford.ac.uk/packages/boo.spec
SRPM URL: http://www.smmp.salford.ac.uk/packages/boo-0.7.5.2013-7.src.rpm

Lots of fixes and is now happy on x86_64/ia64
Comment 14 Thomas Moschny 2006-06-01 17:01:50 EDT
(Meanwhile, upstream version is 0.7.6.2237.)
Comment 15 Paul F. Johnson 2006-06-01 18:19:23 EDT
I know - however, I'm working off the released tarballs which currently sit at
0.7.6.2103. Currently, my dev system at work uses 2237 and it has issues.
Comment 16 Paul F. Johnson 2006-06-03 09:41:37 EDT
I've started looking at getting 0.7.6.2237 in instead of 2013. The problem is
that nant (which is now waiting to be included in extras) doesn't seem to have
the equivalent of make install, so I'll have to hack around and basically copy
things manually :-(
Comment 17 Paul F. Johnson 2006-06-04 09:33:25 EDT
Spec URL: http://www.knox.net.nz/~nodoid/boo.spec
SRPM URL: http://www.knox.net.nz/~nodoid/boo-0.7.5.2013-7.src.rpm

Change of URL
Comment 18 Paul F. Johnson 2006-06-04 15:21:43 EDT
Spec URL: http://www.knox.net.nz/~nodoid/boo.spec
SRPM URL: http://www.knox.net.nz/~nodoid/boo-0.7.6.2234-1.src.rpm

Changelog

Bump to newer version (2237 has build issues)
Comment 19 Toshio Kuratomi 2006-06-06 22:45:13 EDT
Unless there's a special exception for mono apps that I don't know about, this
package needs to contain sources.  It currently contains a tarball of boo
binaries, not a tarball of the boo sources.
Comment 20 Paul F. Johnson 2006-06-07 06:15:18 EDT
Good catch. I'm trying to build 2237 which needs nant. However, there doesn't
seem to be a way to pass values to alter the default.build.

I'm chasing the 2234 sources in the meantime
Comment 21 Paul F. Johnson 2006-06-08 04:49:02 EDT
Spec URL: http://www.knox.net.nz/~nodoid/boo.spec
SRPM URL: http://www.knox.net.nz/~nodoid/boo-0.7.6.2237-1.src.rpm

-
Bump to new version
Multiple changes to the spec file
Ensure that there are no ownership problems
Disabled debug package (empty)

Repeat after me...

nant is insane. nant is bad. nant is unpleasant....
Comment 22 Paul F. Johnson 2006-06-14 18:59:13 EDT
Spec URL: http://www.knox.net.nz/~nodoid/boo.spec
SRPM URL: http://www.knox.net.nz/~nodoid/boo-0.7.6.2237-2.src.rpm

- added gtksourceview-1.0 to files as I'd missed it on -1
Comment 23 David Nielsen 2006-07-04 17:09:18 EDT
This needs NAnt to build, NAnt is marked for review here:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=193957

or this happens duing build:

+ nant -D:install.prefix=/usr -D:install.libdir=/usr/lib
/var/tmp/rpm-tmp.63861: line 23: nant: command not found
error: Bad exit status from /var/tmp/rpm-tmp.63861 (%build)


RPM build errors:
    Bad exit status from /var/tmp/rpm-tmp.63861 (%build)
Comment 24 John Mahowald 2006-07-05 23:34:46 EDT
Needs nant to build = needs nant as a BuildRequires.
Comment 25 David Nielsen 2006-07-21 21:38:26 EDT
Created attachment 132855 [details]
patch to add BuildRequires: boo

The following patch adds nant to BuildRequires, thus fixing the compile on my
machine - is this ready to go in Extras?
Comment 26 Toshio Kuratomi 2006-07-21 22:02:23 EDT
Redefining libdir is a no-no.  You could do like alexl did in the mono package
and define a monodir that = %{prefix}/lib if you want until mono-core moves.
(And then change monodir to _libdir)

I don't see a gacutils invocation.  Is nant handling that?
Comment 27 Paul F. Johnson 2006-07-23 09:58:50 EDT
#26 - nant does the gac invocation

Spec URL: http://www.knox.net.nz/~nodoid/boo.spec
SRPM URL: http://www.knox.net.nz/~nodoid/boo-0.7.6.2237-5.src.rpm

Fixes #24, #26

#25 - how can boo require boo to build?
Comment 28 John Mahowald 2006-07-24 20:55:17 EDT
Isn't building, is expecting to be in %{_prefix}/lib. Needs fixing.

After defining a %{monodir} to be %{_prefix}/lib, rpmlint found:

Source RPM:
E: boo hardcoded-library-path in %{_prefix}/lib
Workaround to make it build. Ignore at least for now.

W: boo rpm-buildroot-usage %prep rm -rf %{buildroot}


W: boo mixed-use-of-spaces-and-tabs
Not important but easy to fix.

W: boo patch-not-applied Patch0: build.patch
Drop the patch.

rpmlint of boo-devel:
W: boo-devel no-documentation
Ignore.

rpmlint of boo:
E: boo no-binary
E: boo only-non-binary-in-usr-lib
Expected for mono.

E: boo-debuginfo empty-debuginfo-package
Drop the debuginfo package.


Missing a update-mime-database scriplet.
http://fedoraproject.org/wiki/ScriptletSnippets


Good stuff:
- package meets naming guidelines
- license (MIT) OK, text in %doc, matches source
- spec file legible, in am. english
- source matches upstream
- package compiles on devel (x86_64)
- no missing BR
- no unnecessary BR
- no locales
- not relocatable
- owns all directories that it creates
- no duplicate files
- permissions ok
- %clean ok
- macro use consistent: defined %{monodir}
- code, not content
- no need for -docs
- nothing in %doc affects runtime
- no need for .desktop file




EXTRA STUFF FOR PACKAGES WITH DEVEL
======================================

- devel package ok
- no .la files
- post/postun ldconfig ok
- devel requires base package n-v-r 
Comment 29 John Mahowald 2006-07-24 21:01:25 EDT
Clarification: that %{_libdir} thing is for the lone file in the devel package:
%{_libdir}/pkgconfig/boo.pc.
Comment 30 David Nielsen 2006-07-24 21:17:49 EDT
(In reply to comment #27)

> #25 - how can boo require boo to build?

Actually the patch adds BR nant, I just spaced out when writing the post.
Comment 31 Paul F. Johnson 2006-07-25 04:15:08 EDT
Spec URL: http://www.knox.net.nz/~nodoid/boo.spec
SRPM URL: http://www.knox.net.nz/~nodoid/boo-0.7.6.2237-6.src.rpm

Fixed #28 and #29
rpmlint is much happier now :-)

The only warning is that the devel package contains no documentation. I'm not
overly concerned about this.

Not sure what happened with the -5 spec file I uploaded as it wasn't the one I
built the package with!

#30 - not to worry mate, cold meds do that to you ;-p
Comment 32 John Mahowald 2006-07-25 20:24:45 EDT
Release 6 builds and runs some of the fun things here:
http://boo.codehaus.org/Recipes. APPROVED as per comment 28.
Comment 33 Paul Howarth 2006-07-26 06:05:39 EDT
Shouldn't this package own the %{monodir}/boo directory?
Comment 34 John Mahowald 2006-07-26 09:27:02 EDT
(In reply to comment #33)
> Shouldn't this package own the %{monodir}/boo directory?

Good catch, yes it should. Add it before building.
Comment 35 Paul F. Johnson 2006-07-26 09:37:41 EDT
Currently rebuilding and will upload later today

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