Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 178904
Summary: | Review Request: Monodevelop | ||||||
---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Paul F. Johnson <paul> | ||||
Component: | Package Review | Assignee: | John Mahowald <jpmahowald> | ||||
Status: | CLOSED NEXTRELEASE | QA Contact: | Fedora Package Reviews List <fedora-package-review> | ||||
Severity: | medium | Docs Contact: | |||||
Priority: | medium | ||||||
Version: | rawhide | CC: | axonrg, caleb, daleemoore, fedora, fedora, gilboad, gnomeuser, jpmahowald, lyz27, nsoranzo | ||||
Target Milestone: | --- | ||||||
Target Release: | --- | ||||||
Hardware: | All | ||||||
OS: | Linux | ||||||
Whiteboard: | |||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||
Doc Text: | Story Points: | --- | |||||
Clone Of: | Environment: | ||||||
Last Closed: | 2006-08-04 21:29:02 UTC | Type: | --- | ||||
Regression: | --- | Mount Type: | --- | ||||
Documentation: | --- | CRM: | |||||
Verified Versions: | Category: | --- | |||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
Cloudforms Team: | --- | Target Upstream Version: | |||||
Embargoed: | |||||||
Bug Depends On: | 178900, 178901, 189092, 200639 | ||||||
Bug Blocks: | 163779 | ||||||
Attachments: |
|
Description
Paul F. Johnson
2006-01-25 11:16:31 UTC
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 |