Can't build until gtksourceview-sharp (#178900) is installed.

Re comment #1 - it built ok for me with mono-develop as the  only dependency I
needed to satisfy.


A bit heavy going for a specfile & mono newbie, but here goes for what it's
worth ...



      - MUST: rpmlint must be run on every package. The output should be posted
in the review.


# rpmlint -v RPMS/i386/monodoc-1.1.9-2.i386.rpm
I: monodoc checking
E: monodoc no-binary
E: monodoc only-non-binary-in-usr-lib

I pulled the rpm apart with rpm2cpio | cpio -id and had a look inside
I presume the no-binary is because it produces PE rather than ELF executables?
What do beagle/fspot do in this case? 

W: monodoc no-documentation

Ironic!

W: monodoc devel-file-in-non-devel-package /usr/lib/pkgconfig/monodoc.pc

Don't know what this is, so no clue why rpmlint moans about it

# rpmlint -v RPMS/i386/monodoc-debuginfo-1.1.9-2.i386.rpm
I: monodoc-debuginfo checking

OK

# rpmlint -v SRPMS/monodoc-1.1.9-2.src.rpm
I: monodoc checking
E: monodoc hardcoded-library-path in %{buildroot}/usr/lib/mono/gac
E: monodoc hardcoded-library-path in %{buildroot}/usr/lib

within %install any reason you've used some with /usr/lib instead of %{_libdir} ?
e.g.
  %{__mkdir} -p %{buildroot}%{_libdir}/pkgconfig
  %{__mkdir} -p %{buildroot}/usr/lib/mono/gac

E: monodoc hardcoded-library-path in /usr/lib/mono/gac/monodoc
E: monodoc hardcoded-library-path in /usr/lib/mono/monodoc/monodoc.dll

similar from %files shodle these be %{_libdir} too?
  /usr/lib/mono/gac/monodoc
  /usr/lib/mono/monodoc/monodoc.dll


      - MUST: The package must be named according to the Package Naming Guidelines.


OK


      - MUST: The spec file name must match the base package %{name}, in the
format %{name}.spec

OK

      - MUST: The package must meet the Packaging Guidelines.


NOT CHECKED


      - MUST: The package must be licensed with an open-source compatible
license and meet other legal requirements as defined in the legal section of
Packaging Guidelines.


"COPYING" file shows GPL
If REDHAT can't comment about legal matters on mono/.net I'm sure I'm not
qualified to :-(
In general found individual sorce fiels didn't have licence info contained


      - MUST: The License field in the package spec file must match the actual
license.


GPL in .spec and "COPYING"


      - 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.


No %doc in %files, shoul dit be added and COPYING placed there?


      - MUST: The spec file must be written in American English.


Didn't spot any Britishisms ;-)


      - MUST: The spec file for the package MUST be legible.


Clean


      - MUST: The sources used to build the package must match the upstream source

# md5sum /usr/src/redhat/SOURCES/monodoc-1.1.9.tar.gz
2b8548b7160c1f3124c9f7b8f2044a88  /usr/src/redhat/SOURCES/monodoc-1.1.9.tar.gz

# wget -O upstream.tgz http://go-mono.com/sources/monodoc/monodoc-1.1.9.tar.gz
--23:35:38--  http://go-mono.com/sources/monodoc/monodoc-1.1.9.tar.gz
           => `upstream.tgz'
Resolving go-mono.com... 64.14.94.188
Connecting to go-mono.com|64.14.94.188|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 17,328,634 (17M) [application/x-gzip]

100%[==================================================================================================>]
17,328,634   111.94K/s    ETA 00:00

23:38:09 (111.73 KB/s) - `upstream.tgz' saved [17328634/17328634]

# md5sum /root/upstream.tgz
2b8548b7160c1f3124c9f7b8f2044a88  /root/upstream.tgz


OK


      - MUST: The package must successfully compile and build into binary rpms
on at least one supported architecture.


OK for me on i386
FAILED to compile for me on x86_64 (likely flaky mono on my machine beagle is
acting up to)

      - MUST: If the package does not successfully compile, build or work on an
architecture, then those architectures should be listed in the spec in
ExcludeArch. Each architecture listed in ExcludeArch needs to have a bug filed
in bugzilla, describing the reason that the package does not compile/build/work
on that architecture. The bug number should then be placed in a comment, next to
the corresponding ExcludeArch line. New packages will not have bugzilla entries
during the review process, so they should put this description in the comment
until the package is approved, then file the bugzilla entry, and replace the
long explanation with the bug number. The bug should be marked as blocking one
(or more) of the following bugs to simplify tracking such issues: [WWW]
FE-ExcludeArch-x86, [WWW] FE-ExcludeArch-x64, [WWW] FE-ExcludeArch-ppc


NOT CHECKED


      - MUST: A package must not contain any BuildRequires that are listed in
the exceptions section of Packaging Guidelines.


OK

      - MUST: All other Build dependencies must be listed in BuildRequires.


SEEMED OK, I had to install mono-devel


      - MUST: The spec file MUST handle locales properly. This is done by using
the %find_lang macro. Using %{_datadir}/locale/* is strictly forbidden.


NO /locale/* files at all, not sure if monodoc has any i18n at all


      - MUST: If the package contains shared library files located in the
dynamic linker's default paths,


No .so files, whether it needs to do anything similar with it's .dll files I
don't know


      - MUST: If the package is designed to be relocatable, the packager must
state this fact in the request for review, along with the rationalization for
relocation of that specific package. Without this, use of Prefix: /usr is
considered a blocker.


Dont think so


      - MUST: A package must own all directories that it creates. If it does not
create a directory that it uses, then it should require a package which does
create that directory. The exception to this are directories listed explicitly
in the Filesystem Hierarchy Standard ([WWW]
http://www.pathname.com/fhs/pub/fhs-2.3.html), as it is safe to assume that
those directories exist.

Not checked


      - MUST: A package must not contain any duplicate files in the %files listing.

No wildcards used at all, disn't spot any dupes


      - MUST: Permissions on files must be set properly. Executables should be
set with executable permissions, for example. Every %files section must include
a %defattr(...) line.


No %defattr, can't see a reason why it would hurt to have one


      - MUST: Each package must have a %clean section, which contains rm -rf
%{buildroot} (or $RPM_BUILD_ROOT).


yes


      - MUST: Each package must consistently use macros, as described in the
macros section of Packaging Guidelines.

yes

      - MUST: The package must contain code, or permissable content. This is
described in detail in the code vs. content section of Packaging Guidelines.


seems OK, rpmlint doesn't acknowledge PE as code, but it plainly is also the
actual monodoc content seems to be in xml bundles


      - MUST: Large documentation files should go in a -docs subpackage. (The
definition of large is left up to the packager's best judgement, but is not
restricted to size. Large can refer to either size or quantity)


This *is* a docs package

      - MUST: If a package includes something as %doc, it must not affect the
runtime of the application. To summarize: If it is in %doc, the program must run
properly if it is not present.


No %doc at all at present, should be fixed


      - MUST: Header files or static libraries must be in a -devel package.


Didn't check


      - MUST: Files used by pkgconfig (.pc files) must be in a -devel package.


There is a monodoc.pc file being packaged, I don't kneo if ".pc" files are
significant in some other way 
(apart from pgkconfig) to mono?


      - MUST: If a package contains library files with a suffix (e.g.
libfoo.so.1.1), then library files that end in .so (without suffix) must go in a
-devel package.


No .so files


      - MUST: In the vast majority of cases, devel packages must require the
base package using a fully versioned dependency.


No separate -devel


      - MUST: Packages must NOT contain any .la libtool archives, these should
be removed in the spec.


No .la files


      - MUST: Packages containing GUI applications must include a
%{name}.desktop file, and that file must be properly installed with
desktop-file-install in the %install section. This is described in detail in the
desktop files section of Packaging Guidelines. If you feel that your packaged
GUI application does not need a .desktop file, you must put a comment in the
spec file with your explanation.


No .desktop file, unclear to me now if monodocs actually displays docs, in GUI,
or just prepares thenm for later display, or browser based display.


      - MUST: Packages must not own files or directories already owned by other
packages. The rule of thumb here is that the first package to be installed
should own the files or directories that other packages may rely upon. This
means, for example, that no package in Fedora Extras should ever share ownership
with any of the files or directories owned by the filesystem or man package. If
you feel that you have a good reason to own a file or directory that another
package owns, then please present that at package review time.


Didn't check


      - SHOULD: If the source package does not include license text(s) as a
separate file from upstream, the packager SHOULD query upstream to include it.


It does include separate licence file


      - SHOULD: The description and summary sections in the package spec file
should contain translations for supported Non-English languages, if available.


No extra translations provided


      - SHOULD: The reviewer should test that the package builds in mock.


not done


      - SHOULD: The package should compile and build into binary rpms on all
supported architectures.


Only done on i386, tried and failed  on x86_64 (probably not this packages fault)


      - SHOULD: The reviewer should test that the package functions as
described. A package should not segfault instead of running, for example.


Installed ok in i386 machine that was used to build
no info how to start, or what it should do
I tried "mono mod.exe" at least it gave a polite error rather than crashing


      - SHOULD: If scriptlets are used, those scriptlets must be sane. This is
vague, and left up to the reviewers judgement to determine sanity.


None used


      - SHOULD: Usually, subpackages other than devel should require the base
package using a fully versioned dependency.


None

Err, apoligies all round

first sorry rowan, you din't mid-flight collide over me
second this review belongs on BZ#178900 i've already send a copy of it there

Hi,

> # rpmlint -v RPMS/i386/monodoc-1.1.9-2.i386.rpm
> I: monodoc checking
> E: monodoc no-binary
> E: monodoc only-non-binary-in-usr-lib

Um, this is a bugzilla report for monodoc and not monodevelop...

(In reply to comment #4)

> Um, this is a bugzilla report for monodoc and not monodevelop...

Err yes, I though I'd coughed up to my mistake in comment #3

Claiming for review.

There are a few typos:

--- monodevelop-orig.spec       2006-01-25 12:10:29.000000000 +0100
+++ monodevelop.spec    2006-04-03 23:23:00.000000000 +0200
@@ -53,19 +53,19 @@
 %{__install} -c -m 644 Core/src/MonoDevelop.Core/MonoDevelop.Core.addin.xml
%{monodevdir}/AddIns/MonoDevelop.Core.addin.xml
 %{__install} -c -m 644 build/bin/MonoDevelop.Core.dll
%{monodevdir}/bin/MonoDevelop.Core.dll
 %{__install} -c -m 644 build/AddIns/MonoDevelop.Components.dll
%{monodevdir}/bin/MonoDevelop.Components.dll
-%{__install} -c -m 644
Core/src/MonoDevelop.Core.Gui/MonoDevelop.Core.Gui.addin.xml
%{monodevdir}/AddIns/MonoDevelop.Core.Gui.xml
+%{__install} -c -m 644
Core/src/MonoDevelop.Core.Gui/MonoDevelop.Core.Gui.addin.xml
%{monodevdir}/AddIns/MonoDevelop.Core.Gui.addin.xml
 %{__install} -c -m 644 build/AddIns/MonoDevelop.Core.Gui.dll
%{monodevdir}/AddIns/MonoDevelop.Core.Gui.dll
 %{__install} -c -m 644
Core/src/MonoDevelop.Documentation/MonoDevelop.Documentation.addin.xml
%{monodevdir}/AddIns/MonoDevelop.Documentation.addin.xml
 %{__install} -c -m 644 build/AddIns/MonoDevelop.Documentation.dll
%{monodevdir}/AddIns/MonoDevelop.Documentation.dll
-%{__install} -c -m 644
Core/src/MonoDevelop.Projects/MonoDevelop.Projects.addin.xml
%{monodevdir}/AddIns/MonoDevelop.Projects.adding.xml
+%{__install} -c -m 644
Core/src/MonoDevelop.Projects/MonoDevelop.Projects.addin.xml
%{monodevdir}/AddIns/MonoDevelop.Projects.addin.xml
 %{__install} -c -m 644 build/AddIns/MonoDevelop.Projects.dll
%{monodevdir}/AddIns/MonoDevelop.Projects.dll
-%{__install} -c -m 644
Core/src/MonoDevelop.Projects.Gui/MonoDevelop.Projects.Gui.addin.xml
%{monodevdir}/AddIns/MonoDevelop.Projects.Gui.adding.xml
+%{__install} -c -m 644
Core/src/MonoDevelop.Projects.Gui/MonoDevelop.Projects.Gui.addin.xml
%{monodevdir}/AddIns/MonoDevelop.Projects.Gui.addin.xml
 %{__install} -c -m 644 build/AddIns/MonoDevelop.Projects.Gui.dll
%{monodevdir}/AddIns/MonoDevelop.Projects.Gui.dll
-%{__install} -c -m 644 Core/src/MonoDevelop.Ide/MonoDevelop.Ide.addin.xml
%{monodevdir}/AddIns/MonoDevelop.Ide.adding.xml
+%{__install} -c -m 644 Core/src/MonoDevelop.Ide/MonoDevelop.Ide.addin.xml
%{monodevdir}/AddIns/MonoDevelop.Ide.addin.xml
 %{__install} -c -m 644 build/AddIns/MonoDevelop.Ide.dll
%{monodevdir}/AddIns/MonoDevelop.Ide.dll
 %{__install} -c -m 644 build/data/options/DefaultEditingLayout.xml
%{monodevdir}/data/options/DefaultEditingLayout.xml
-%{__install} -c -m 644 build/data/options/MonoDevelopProperties.xml
%{monodevdir}/data/options/MonoDevlopProperties.xml
-%{__install} -c -m 644 build/data/options/MonoDevelop-templates.xml
%{monodevdir}/data/options/MonoDevelop-Templates.xml
+%{__install} -c -m 644 build/data/options/MonoDevelopProperties.xml
%{monodevdir}/data/options/MonoDevelopProperties.xml
+%{__install} -c -m 644 build/data/options/MonoDevelop-templates.xml
%{monodevdir}/data/options/MonoDevelop-templates.xml
 %{__install} -c -m 644 build/data/options/MonoDevelop-tools.xml
%{monodevdir}/data/options/MonoDevelop-tools.xml
 %{__install} -c -m 644 build/data/options/TipsOfTheDay.xml
%{monodevdir}/data/options/TipsOfTheDay.xml
 %{__install} -c -m 644 build/bin/MonoDevelop.exe %{monodevdir}/bin/MonoDevelop.exe

SPEC file: 

http://www.smmp.salford.ac.uk/packages/monodevelop.spec

SRPM

http://www.smmp.salford.ac.uk/packages/monodevelop-0.9-3.src.rpm

In addition to the typo corrections, I've made some really minor alterations to
the spec file (basically, a few more typos fixed)

Builds fine on x86. Not tested on x86_64

SPEC file: 

http://www.smmp.salford.ac.uk/packages/monodevelop.spec

SRPM

http://www.smmp.salford.ac.uk/packages/monodevelop-0.10-1.src.rpm

Bump to new version (less than 2 hours old!) with a small tweak to the spec file
to accommodate

Builds fine on x86_64. Not tested on x86

The #9 rpm won't build without: mono-data-postgresql, mono-data-oracle,
mono-data-sybase and mono-nunit. And monodevelop won't run at least without
mono-nunit.

There are also two more typos:

51c51
< %{__install} -c -m 644
Core/src/MonoDevelop.Core.Gui/MonoDevelop.Core.Gui.addin.xml
%{monodevdir}/AddIns/MonoDevelop.CoreGui..addin.xml
---
> %{__install} -c -m 644 Core/src/MonoDevelop.Core/MonoDevelop.Core.addin.xml
%{monodevdir}/AddIns/MonoDevelop.Core.addin.xml
54c54
< %{__install} -c -m 644
Core/src/MonoDevelop.Core.Gui/MonoDevelop.Core.Gui.addin.xml
%{monodevdir}/AddIns/MonoDevelop.Core.Gui.xml
---
> %{__install} -c -m 644
Core/src/MonoDevelop.Core.Gui/MonoDevelop.Core.Gui.addin.xml
%{monodevdir}/AddIns/MonoDevelop.Core.Gui.addin.xml

SPEC file: 

http://www.smmp.salford.ac.uk/packages/monodevelop.spec

SRPM

http://www.smmp.salford.ac.uk/packages/monodevelop-0.10-2.src.rpm

Fixes and buildreqs added. Thank Angel :-)

The first typo is already there. You've removed the double dot, but the real
issue is that that line is handling
MonoDevelop.Core.Gui/MonoDevelop.Core.Gui.addin.xml while it should be about
MonoDevelop.Core/MonoDevelop.Core.addin.xml. Core.Gui.* is already handled a few
lines below in the spec :)

The gtksourceview-sharp source rpm won't build without gtk-sharp2-gapi.  Please
add dependancy there.  

Running monodevelop gives
Unhandled Exception: System.ArgumentException: The addin 'MonoDevelop.Core'
v0.10.0 is not installed.
in <0x004c4> MonoDevelop.Core.AddIns.AddInService:ResolveLoadDependencies
(System.Collections.ArrayList addins, System.Collections.Stack depCheck,
System.String id, System.String version)
in <0x0024f> MonoDevelop.Core.AddIns.AddInService:ResolveLoadDependencies
(System.Collections.ArrayList addins, System.Collections.Stack depCheck,
System.String id, System.String version)
in <0x000d3> MonoDevelop.Core.AddIns.AddInService:PreloadAddin (IProgressMonitor
monitor, System.String id)
in <0x00107> MonoDevelop.Core.AddIns.AddInService:StartApplication
(System.String addinId, System.String[] parameters)
in <0x00054> MonoDevelop.Startup.SharpDevelopMain:Main (System.String[] args)

This is on fc5 on a x86_64 box.

Spec Name or Url: http://www.smmp.salford.ac.uk/packages/monodevelop.spec
SRPM Name or Url: http://www.smmp.salford.ac.uk/packages/monodevelop-0.10-3.src.rpm

Updated to now require mono-debugger and boo. Also contains a number of fixes. 

Spec Name or Url: http://www.smmp.salford.ac.uk/packages/monodevelop.spec
SRPM Name or Url: http://www.smmp.salford.ac.uk/packages/monodevelop-0.10-4.src.rpm

More fixes and a slimmed down spec file

The boo spec needed to be modified to use the -root option for gacutil.
for lib in bin/Boo.Lang.dll bin/Boo.Lang.Useful.dll bin/Boo.Lang.Compiler.dll
bin/Boo.Lang.Parser.dll bin/Boo.Lang.Interpreter.dll bin/Boo.Lang.CodeDom.dll
bin/pt/Boo.Lang.resources.dll; do gacutil -i ${lib} -f -package boo -root
${RPM_BUILD_ROOT}%{_libdir}; done

Unfortunatly.. It still doesn't work as

[root@localhost /]# cat `which booc`
#!/bin/sh
env /usr/bin/mono /usr/lib/boo/booc.exe "$@"

doesn't work as the exe is under /usr/lib64/boo not /usr/lib

Yep - this is down to mono wanting *everything* to be in /usr/lib rather than
say /usr/lib64 (and adding --libdir=/usr/lib64 doesn't help either).

I have a fix which I'll apply to all of the packages so that they all build to
/usr/lib instead of /usr/lib64

Spec Name or Url: http://www.smmp.salford.ac.uk/packages/monodevelop.spec
SRPM Name or Url: http://www.smmp.salford.ac.uk/packages/monodevelop-0.10-4.src.rpm

libdir now set to /usr/lib irrespective of hardware (fixes the boo bug in part)
spec file changes
forgot to change the version number to -5 for some reason!!!

boo compiles and installs cleanly now.  Thanks
There may be a tiny bug though

In the created bin/Makefile , the test command looks in one place and then
creates a directory somewhere else

install-booDATA: $(boo_DATA)
        @$(NORMAL_INSTALL)
        test -z "$(boodir)" || $(mkdir_p) "$(DESTDIR)$(boodir)"

On my machine this did

test -z "/usr/lib/boo" || mkdir -p --
"/var/tmp/boo-0.7.5.2013-3-root-root/usr/lib/boo"

What it's doing is it's looking for /usr/lib/boo and when it's not found,
creating it in %{buildroot} which is correct (the spec file says to do that).

If you were building the rpm not in the FC rpmbuild system, but using the old,
bung it into /usr/src/SOURCES, change to root, build, it would look for
/usr/lib/boo and then create /usr/lib/boo if it wasn't found.

At least, that's how I understand it!

Ok.  Good deal.

Couple more things:
I think that you need to add --enable-boo to the configure of monodevelop.spec
to enable boo.  
Even after this change, it doesn't work on 64 bit systems since the check for
boo in the monodevelop configure script runs the command: pkg-config --exists
"boo >= 0.7.5.2013" will not work as pkg-config will look for the .pc files
under /usr/lib64/pkgconfig and the .pc file for boo is under /usr/lib/pkgconfig .

The build of mono-debugger fails.  I believe that this is a bug with the source
code, not the package.  I downloaded the package from the go-mono site and got
the same error.  I'm hoping someone knows where to redirect this better than I.

[root@localhost server]# make
if /bin/sh ../../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I.
-I../.. -D_REENTRANT -pthread -I/usr/lib64/pkg config/../../include
-I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include   -D_GNU_SOURCE    -g
-Wall -Wunused -Wmissing-p rototypes -Wmissing-declarations -Wstrict-prototypes
 -Wmissing-prototypes -Wnested-externs  -Wshadow -Wpointer-arith -Wno- cast-qual
-Wcast-align -Wwrite-strings -MT x86-ptrace.lo -MD -MP -MF
".deps/x86-ptrace.Tpo" -c -o x86-ptrace.lo x86-ptrace. c; \
then mv -f ".deps/x86-ptrace.Tpo" ".deps/x86-ptrace.Plo"; else rm -f
".deps/x86-ptrace.Tpo"; exit 1; fi
 gcc -DHAVE_CONFIG_H -I. -I. -I../.. -D_REENTRANT -pthread
-I/usr/lib64/pkgconfig/../../include -I/usr/include/glib-2.0 -I/
usr/lib64/glib-2.0/include -D_GNU_SOURCE -g -Wall -Wunused -Wmissing-prototypes
-Wmissing-declarations -Wstrict-prototypes -Wmissing-prototypes -Wnested-externs
-Wshadow -Wpointer-arith -Wno-cast-qual -Wcast-align -Wwrite-strings -MT
x86-ptrace.l o -MD -MP -MF .deps/x86-ptrace.Tpo -c x86-ptrace.c  -fPIC -DPIC -o
.libs/x86-ptrace.o
In file included from /usr/include/asm/user.h:4,
                 from x86_64-arch.h:10,
                 from x86-arch.h:45,
                 from x86-linux-ptrace.h:4,
                 from x86-ptrace.c:35:
/usr/include/asm-x86_64/user.h:56: error: expected specifier-qualifier-list
before 'u64'
In file included from x86-ptrace.c:437:
x86-linux-ptrace.c: In function 'do_wait':
x86-linux-ptrace.c:128: warning: pointer targets in passing argument 2 of
'waitpid' differ in signedness
x86-linux-ptrace.c: In function 'server_ptrace_global_wait':
x86-linux-ptrace.c:160: warning: pointer targets in passing argument 2 of
'do_wait' differ in signedness
x86-linux-ptrace.c: In function '_server_ptrace_setup_inferior':
x86-linux-ptrace.c:293: warning: pointer targets in passing argument 2 of
'do_wait' differ in signedness
x86-linux-ptrace.c: In function 'server_ptrace_get_application':
x86-linux-ptrace.c:461: warning: assignment makes pointer from integer without a
cast
In file included from x86-ptrace.c:447:
x86_64-arch.c: In function 'server_ptrace_call_method_1':
x86_64-arch.c:707: warning: pointer targets in passing argument 1 of 'strcpy'
differ in signedness
x86-ptrace.c: At top level:
x86-ptrace.c:474: warning: initialization from incompatible pointer type
x86-ptrace.c:492: warning: initialization from incompatible pointer type
make: *** [x86-ptrace.lo] Error 1

Thanks for the report, I'll enable boo and see what happens with the built. The
other one is a bug not with the mono-debugger source but with one of the FC
packages. I'll find out which and enter it into the main BZ (it's prob. a gcc one)

That error comes from glibc-kernheaders

(In reply to comment #20)
> What it's doing is it's looking for /usr/lib/boo and when it's not found,
> creating it in %{buildroot} which is correct (the spec file says to do that).

But why does it say that? What's the point?

Supposing /usr/lib/boo *does* ecist on the build system. The directory won't get
created in the buildroot then. Looks horribly wrong to me.

> If you were building the rpm not in the FC rpmbuild system, but using the old,
> bung it into /usr/src/SOURCES, change to root, build, it would look for
> /usr/lib/boo and then create /usr/lib/boo if it wasn't found.
> 
> At least, that's how I understand it!

If you've specified a buildroot in your spec file (as you must), it'll be
honoured whether you build it as a regular user or as root. But no sane person
builds packages as root.

"If you've specified a buildroot in your spec file (as you must), it'll be
honoured whether you build it as a regular user or as root. But no sane person
builds packages as root."

True, but as I've said, when RPMS were built prior to the incredibly useful
fedora-rpmdev system, rpm building was performed in /usr/src or as a priviledged
user (or at least that's the way I was always told to do it - which is why I
never did - it was a recipe for disaster!)

(In reply to comment #25)
> "If you've specified a buildroot in your spec file (as you must), it'll be
> honoured whether you build it as a regular user or as root. But no sane person
> builds packages as root."
> 
> True, but as I've said, when RPMS were built prior to the incredibly useful
> fedora-rpmdev system, rpm building was performed in /usr/src or as a priviledged
> user (or at least that's the way I was always told to do it - which is why I
> never did - it was a recipe for disaster!)

Even when building as root under /usr/src/redhat, rpmbuild would honour the
BuildRoot: setting in your spec file and not go creating /usr/lib/boo or
whatever if the construct described in Comment #19 was used.

It would only create /usr/lib/boo if the Makefile was broken and didn't use
DESTDIR properly.

If you don't believe me, try it with a simple spec/Makefile that just creates
the directory.

There is currently a problem with --enable-boo and --enable-debugger

debugger is not supported due to API changes and --enable-boo just seems to be
broken (monodevelop refuses to build with it enabled)

Can you give me the bug number on the glibc-kernheaders issue?  I would like to
check the status and help out if I can.  I tried the packages that are in the
development branch and they produced the same error.  

189324

Neither boo or ikvm can be included with MonoDevelop currently. I can build all
of the packages for x86, but there is a problem (down to I think the way mono
packages it's bits and pieces) for x86_64. The i386 rpms work fine under x86_64
though.

Spec Name or Url: http://www.smmp.salford.ac.uk/packages/monodevelop.spec
SRPM Name or Url: http://www.smmp.salford.ac.uk/packages/monodevelop-0.10-8.src.rpm

Boo and java support are now built as part of the package.

As before, the x86_64 version has problems due to packaging, but the i386
version works fine on both x86_64 and i386 without a hitch.

Spec Name or Url: http://www.smmp.salford.ac.uk/packages/monodevelop.spec
SRPM Name or Url: http://www.smmp.salford.ac.uk/packages/monodevelop-0.11-2.src.rpm

Bump to 0.11
Fixes for x86_64/ia64
PKG_CONFIG_PATH fix added in
Includes devel package

It seems this package owns some directories already owned by shared-mime-info,
as well as some other directories onto /usr/share/mime.

[iago@puhisher share]$ rpm -qf /usr/share/mime
shared-mime-info-0.17-1.fc5.1
monodevelop-0.11-2
[iago@puhisher share]$ rpm -qf /usr/share/mime/packages
shared-mime-info-0.17-1.fc5.1
monodevelop-0.11-2

[iago@puhisher share]$ rpm -ql monodevelop | grep mime | grep -v .xml$
/usr/share/mime
/usr/share/mime/XMLnamespaces
/usr/share/mime/aliases
/usr/share/mime/application
/usr/share/mime/globs
/usr/share/mime/magic
/usr/share/mime/mime.cache
/usr/share/mime/packages
/usr/share/mime/subclasses
/usr/share/mime/

May be it's worth to fix it now  to avoid the case of /usr/share/applications.

[iago@puhisher share]$ rpm -q --whatprovides /usr/share/applications
gnome-media-2.14.0-2
bug-buddy-2.14.0-1
glade2-2.12.1-2
gnome-utils-2.14.0-4.fc5.1
nautilus-2.14.1-1.fc5.1
openoffice.org-calc-2.0.2-5.12.2
gthumb-2.7.5.1-1.fc5.1
openoffice.org-impress-2.0.2-5.12.2
eog-2.14.1-1.fc5.1
file-roller-2.14.2-1.fc5.1
gnome-system-monitor-2.14.1-1.fc5.1
gedit-2.14.2-1.fc5.1
openoffice.org-draw-2.0.2-5.12.2
openoffice.org-writer-2.0.2-5.12.2
gnome-session-2.14.1-1.fc5.1
openoffice.org-math-2.0.2-5.12.2
gdm-2.14.4-1.fc5.1
gnome-terminal-2.14.1-1.fc5.1
gnome-games-2.14.1-1.fc5.3
gftp-2.0.18-3.2.1
filesystem-2.3.7-1.2.1
monodevelop-0.11-2

I think all those packages should require filesystem to avoid this mess up - or
 require nothing explicitly, assuming filesystem is already installed.

Otherwise the monodevelop package looks and works fine here.

(In reply to comment #33)
> It seems this package owns some directories already owned by shared-mime-info,
> as well as some other directories onto /usr/share/mime.
> 

This is due to problems in the %files section of the spec file (in particular
the '%{_datadir}/*').  This seems to be a constant problem, which I've noticed
with other packages I've reviewed for Paul. 

Spec Name or Url: http://www.smmp.salford.ac.uk/packages/monodevelop.spec
SRPM Name or Url: http://www.smmp.salford.ac.uk/packages/monodevelop-0.11-3.src.rpm

Addresses the problems in #33 and #34

I've also addressed the same issue in gtksourceview-sharp (178902 IIRC).

Couple of quick items:

1. Dekstop file is not handled correctly.
2. Locals are no handled correctly.
3. In the files section to simplify it, why don't you use
'%{_datadir}/mime/application/*.xml'?  This would be much easier than listing
each file.
4. Don't package the generic INSTALL file.

Also, don't add filesystem as a Requirement.  Comment #33 was incorrect in
suggesting this, since the error was due to your handling of directories in the
%file section

Okay, I've sorted #36 and #37 for the most part, except I'm not sure how to
handle the desktop file and for the LOCALES, am I okay to just have

%{_datadir}/locale/*

or would that cause problems?

(In reply to comment #38)
> Okay, I've sorted #36 and #37 for the most part, except I'm not sure how to
> handle the desktop file and for the LOCALES, am I okay to just have
> 
> %{_datadir}/locale/*
> 
> or would that cause problems?

That is a blocker.  Packages MUST handle locales correctly, which is done by
using the %find_lang macro.  Refer to
http://fedoraproject.org/wiki/Packaging/Guidelines#head-8c605ebf8330f6d505f384e671986fa99a8f72ee

Information on how to handle desktop files can be found
here:http://fedoraproject.org/wiki/Packaging/Guidelines#head-254ddf07aae20a23ced8cecc219d8f73926e9755

Also, you missing the scriptlets needed to for mimeinfo.

Most of the issues can be solved by reading the Packaging Guideline fully.
http://fedoraproject.org/wiki/Packaging/Guidelines

Spec Name or Url: http://www.smmp.salford.ac.uk/packages/monodevelop.spec
SRPM Name or Url: http://www.smmp.salford.ac.uk/packages/monodevelop-0.11-4.src.rpm

All of points #36 and #37 are addressed in this build

You need to remove the duplicate desktop file.  Add the '--delete-original' to
your desktop-file-install line, and remove the
'%{_datadir}/applications/monodevelop.desktop' from the file section.

Spec Name or Url: http://www.smmp.salford.ac.uk/packages/monodevelop.spec
SRPM Name or Url: http://www.smmp.salford.ac.uk/packages/monodevelop-0.11-5.src.rpm

Point #41 addressed - however, it's not as cleanly as I'd like.

Not sure if it's a bug in desktop-file-install or just me, but I've had to
manually removed monodevelop.desktop from %datadir/applications using rm -f. It
does the same job, but it's not as nice

Spec Name or Url: http://www.knox.net.nz/~nodoid/monodevelop.spec
SRPM Name or Url: http://www.knox.net.nz/~nodoid/monodevelop-0.11-6.src.rpm

Fixed #42
Change of URL

Spec Name or Url: http://www.knox.net.nz/~nodoid/monodevelop.spec
SRPM Name or Url: http://www.knox.net.nz/~nodoid/monodevelop-0.11-7.src.rpm

Additional 64 bit fix

Spec Name or Url: http://www.knox.net.nz/~nodoid/monodevelop.spec
SRPM Name or Url: http://www.knox.net.nz/~nodoid/monodevelop-0.11-8.src.rpm

- removed libdir hack
- added BR pkgconfig
- now BuildArch noarch
- altered configure to include a valid target

Spec Name or Url: http://www.knox.net.nz/~nodoid/monodevelop.spec
SRPM Name or Url: http://www.knox.net.nz/~nodoid/monodevelop-0.11-9.src.rpm

Follows packaging guidelines

http://fedorared.org/~john/review/monodevelop-0.11-10.src.rpm

This patches the build scripts to respect %(libdir). Also adds missing
BuildRequires like ivkm-devel and mono-data-sqlite.

Spec Name or Url: http://www.knox.net.nz/~nodoid/monodevelop.spec
SRPM Name or Url: http://www.knox.net.nz/~nodoid/monodevelop-0.11-11.src.rpm

Minor cosmetic changes to satisfy rpmlint

When compiling -11 I get the following output when installing the resulting rpm
on my x86_64 machine:

/var/tmp/rpm-tmp.82507: line 1: 1: command not found
which: no 2 in (/sbin:/bin:/usr/sbin:/usr/bin:/usr/X11R6/bin)

and when running monodevelop in a terminal the output is:

/usr/bin/monodevelop: line 51: cd: /usr/lib/monodevelop/bin: No such file or
directory
cannot open assembly ./MonoDevelop.exe

Looks like it's the ol' needs to be in %{_prefix}/lib problem again. I've fixed
the which problem and will fix the other problem shortly.

Spec Name or Url: http://www.knox.net.nz/~nodoid/monodevelop.spec
SRPM Name or Url: http://www.knox.net.nz/~nodoid/monodevelop-0.11-12.src.rpm

Sorts out the lib problem and which problem

I built and installed -12 on my rawhide x86_64 box.
After creating a symlink /usr/lib/monodevelop -> ../lib64/monodevelop
to get the wrapper script to run, I get a backtrace dialogue
listing missing addins it can't find (Monodevelop.SourceEditor.addin,
CSharpBinding.addin, ...).  Ignoring that and continuing startup
finally it throws an exception:


System.Reflection.TargetInvocationException: Exception has been thrown by the
target of an invocation. ---> System.NullReferenceException: Object reference
not set to an instance of an object
  at <0x00000> <unknown method>
  at (wrapper managed-to-native) System.Reflection.MonoCMethod:InternalInvoke
(object,object[])
  at System.Reflection.MonoCMethod.Invoke (System.Object obj, BindingFlags
invokeAttr, System.Reflection.Binder binder, System.Object[] parameters,
System.Globalization.CultureInfo culture) [0x00000] --- End of inner exception
stack trace ---

  at System.Reflection.MonoCMethod.Invoke (System.Object obj, BindingFlags
invokeAttr, System.Reflection.Binder binder, System.Object[] parameters,
System.Globalization.CultureInfo culture) [0x00000] 
  at System.Reflection.MonoCMethod.Invoke (BindingFlags invokeAttr,
System.Reflection.Binder binder, System.Object[] parameters,
System.Globalization.CultureInfo culture) [0x00000] 
  at System.Reflection.ConstructorInfo.Invoke (System.Object[] parameters)
[0x00000] 
  at System.Activator.CreateInstance (System.Type type, Boolean nonPublic)
[0x00000] 
  at System.Activator.CreateInstance (System.Type type) [0x00000] 
  at MonoDevelop.Core.AddIns.AddIn.CreateObject (System.String className) [0x00000] 
  at MonoDevelop.Ide.Codons.PadCodon.CreatePad () [0x00000] 
  at MonoDevelop.Ide.Codons.PadCodon.BuildItem (System.Object owner,
System.Collections.ArrayList subItems,
MonoDevelop.Core.AddIns.ConditionCollection conditions) [0x00000] 
  at MonoDevelop.Core.AddIns.DefaultAddInTreeNode.BuildChildItems (System.Object
caller) [0x00000] 
  at MonoDevelop.Core.AddIns.AddInService.GetTreeItems (System.String path,
System.Type itemType) [0x00000] 
  at MonoDevelop.Ide.Gui.DefaultWorkbench.InitializeLayout (IWorkbenchLayout
workbenchLayout) [0x00000] 
  at MonoDevelop.Ide.Gui.Workbench.Initialize (IProgressMonitor monitor) [0x00000] 
  at MonoDevelop.Ide.Gui.IdeApp.Initialize (IProgressMonitor monitor) [0x00000] 
  at MonoDevelop.Ide.Gui.IdeStartup.Run (System.String[] args) [0x00000] 

Spec Name or Url: http://www.knox.net.nz/~nodoid/monodevelop.spec
SRPM Name or Url: http://www.knox.net.nz/~nodoid/monodevelop-0.11-13.src.rpm

*should* sort out the 64 bit problem in #52

Certain Requires are not being picked up automatically, including at least: 

gtksourceview-sharp, gecko-sharp2, mono-data-oracle, mono-data-sybase,
mono-data-postgresql, bytefx-data-mysql

This results in monodevelop complaining on startup about addins as mentioned.

With these installed I do get a workbench, but creating a new project results in
a SIGSEGV on i386, apparently somewhere in the gecko or glib bindings.

Created attachment 133273 [details]
stack trace when creating new project

#54 I know they're needed to build, but at least on my test rig, they're not 
needed to run. I can certainly add them as R:s

I'll report the throwback to the main mono package on the FC BZ for advice.

Spec Name or Url: http://www.knox.net.nz/~nodoid/monodevelop.spec

I've only updated the spec file as nothing in the srpm has changed! This sorts 
out the problems in #54.

The geckosharp issue has been reported : #200639

Truncated 'l' on bytefx-data-mysq for some reason. Also, need to Requires
mono-nunit.

Not building on rawhide at the moment due to "Missing Dependency: mozilla is
needed by package gecko-sharp2", but builds on FC5 x86_64, and runs "hello
world" sucessfully.

update-mime-database is noisy. The test redirects to /dev/null but the actual
call does not. This will confuse users and tools. Recommend something like
http://fedoraproject.org/wiki/ScriptletSnippets  which are one line, and silent.

Also from http://fedoraproject.org/wiki/ScriptletSnippets, add the
update-desktop=database entry.

No SMP flags or note as to why they would not be a good idea.

Spec Name or Url: http://www.knox.net.nz/~nodoid/monodevelop.spec

SRPM is the same (other than the spec file needing to be the one here!)

fixes #58
In addition, I've removed which from the main R and added pkgconfig to the
-devel package

I can't fix the gecko-sharp2 problem though ;-p

+ sources match
+ GPL'd
+ builds in mock, FC5 x86_64
+ no missing BRs
+ devel package for .pc
+ spec readable
+ locales handled by %find_lang
+ .desktop file
+ proper scriptlets
+ runs, builds Hello World.
+ permissions OK
+ file ownerships OK

rpmlint: 
W: monodevelop strange-permission monodevelop.spec 0666
Ignore.

E: monodevelop hardcoded-library-path in %{_prefix}/lib
E: monodevelop hardcoded-library-path in 
%{_prefix}/lib/pkgconfig/:%{_datadir}/pkgconfig/:$PKG_CONFIG_PATH
Both needed for libdir hack. 

E: monodevelop no-binary
E: monodevelop only-non-binary-in-usr-lib
Expected for mono.

E: monodevelop-debuginfo empty-debuginfo-package
Not much debug info in mono packages. Remove.

W: monodevelop-devel no-documentation
Ignore.


Note that this does not install to %{_libdir} yet

APPROVED