Bug 496633 - Review Request: monodevelop-debugger-gdb - GDB Debugger Addin for MonoDevelop
Review Request: monodevelop-debugger-gdb - GDB Debugger Addin for MonoDevelop
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
10
All Linux
low Severity medium
: ---
: ---
Assigned To: Toshio Ernie Kuratomi
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-04-20 09:24 EDT by Mauricio Henriquez
Modified: 2009-12-18 04:17 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-12-18 04:17:44 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
a.badger: fedora‑review+


Attachments (Terms of Use)

  None (edit)
Description Mauricio Henriquez 2009-04-20 09:24:58 EDT
Spec URL: http://www.ic.uach.cl/mhenriquez/fedora10-monoRPMS/monodevelop-debugger-gdb.spec
SRPM URL: http://www.ic.uach.cl/mhenriquez/fedora10-monoRPMS/monodevelop-debugger-gdb-2.0-1.1.src.rpm	
Description: GDB Debugger Addin for MonoDevelop.
This is my first package, and I'm seeking for a sponsor
Comment 1 Toshio Ernie Kuratomi 2009-04-22 16:55:47 EDT
A few links to packaging guidelines:

List of important guideline points that all packages are reviewed for:
https://fedoraproject.org/wiki/Packaging:ReviewGuidelines

Main Guidelines page:
https://fedoraproject.org/wiki/Packaging:Guidelines

Guidelines for packaging mono packages in Fedora:
https://fedoraproject.org/wiki/Packaging:Mono

Review:
Good:
* Package is named according to the naming Guidelines
* Spec file name matches the package name
* License of the software is MIT 
* Source matches the upstream tarball
* No locales
* No shared libraries
* No Prefix specified
* No duplicate files or directories
* Proper %clean section
* Package is code, not content
* No documentation, so no %doc subpackage
* Not a standalone GUI app so no .desktop

Needswork:
* Spec file readability -- In Fedora the sections are usually in a different order.  Having them be in a standard order doesn't help the package build but it does help other people reviewing the spec or who work on it later.  There's many simple spec files in cvs to look at.  For instance:
  - http://cvs.fedoraproject.org/viewvc/rpms/monodoc/devel/monodoc.spec
* License tag should just be "MIT"
  - https://fedoraproject.org/wiki/Packaging:LicensingGuidelines#Valid_License_Short_Names
* The Source: line needs to have the full URL to the source
  - https://fedoraproject.org/wiki/Packaging:SourceURL
* The vendor: tag should not be present in Fedora specfiles.  It will be automatically files in by the buildsystem.
* Autoreqprov should normally not be in Fedora spec files.  It is on by defaul.
* BuildArch: i386 does not belong in the spec file.  In Fedora we really only use "BuildArch: noarch" which specifies that the package can be built on any architecture and will create an architecture independent package.  If we need to limit the arches that the package builds on, we use ExcludeArch or ExclusiveArch
* env_options isn't a macro used in Fedora
* You should use %configure rather than ./configure unless there's a reason.
* --prefix=%_prefix is included in the %configure macro so you don't need it if you use the %configure macro.
* In Fedora, mono libraries are installed in %{_libdir} instead of /usr/lib.  On x86_64 systems, that expands to /usr/lib6 instead of /usr/lib.  So use this in the %files section:
  %{_libdir}/monodevelop/AddIns/MonoDevelop.Debugger/MonoDevelop.Debugger.Gdb.dll*
* package needs to rm -rf %{buildroot} at the beginning of %install
* All filenames are UTF-8
* No license file is included in the tarball so you should ask upstream if they'll provide one with their next release.

Trying a build in mock now.
Comment 2 Toshio Ernie Kuratomi 2009-04-23 12:52:27 EDT
Needswork:

* Does not build in mock/koji:
http://koji.fedoraproject.org/koji/taskinfo?taskID=1317154 
http://koji.fedoraproject.org/koji/getfile?taskID=1317154&name=build.log

Looks like you need to BuildRequire: monodevelop-devel rather than monodevelop.
Comment 3 Mauricio Henriquez 2009-04-23 16:56:58 EDT
First the doubts:
you say: "* Package is named according to the naming Guidelines"
My packages don't end with .fc10.rpm , don't know how to instruct rpmbuild to use that kind of name convention.

On "*Needswork" section you say: "* All filenames are UTF-8", that is good or bad?, need to change the text encoding?

Fixed:
* Spec file readability - DONE
* License tag should just be "MIT" - DONE
* The Source: line needs to have the full URL to the source - DONE
* The vendor: tag should not be present in Fedora specfiles. - DONE
* Autoreqprov should normally not be in Fedora spec files. - DONE
* BuildArch: i386 does not belong in the spec file: Here some doubts don't know if this addins are goin to compile fine in all architectures, it seems to me that it have to just x86/x86_64 for now, how do I mix the "BuildArch: noarh" and "ExclusiveArch: x86 x86_64"?
* env_options isn't a macro used in Fedora - DONE
* You should use %configure rather than ./configure: Problem here, using "%configure" I get:

ind-tables -I/usr/lib/gfortran/modules'
+ export FFLAGS
+ ./configure --build=i686-pc-linux-gnu --host=i686-pc-linux-gnu --target=i386-redhat-linux-gnu --program-prefix= --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc --datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib --libexecdir=/usr/libexec --localstatedir=/var --sharedstatedir=/var/lib --mandir=/usr/share/man --infodir=/usr/share/info
Unknown argument --build=i686-pc-linux-gnu
Usage : configure [OPTION]... [--config=CONFIG]

So, it seems to me that the "%configure" macro use something that the package script don't know, so I use again "./configure" witch give now a error message:

RPM build errors:
    File not found by glob: /home/buho/rpmbuild/BUILDROOT/monodevelop-debugger-gdb-2.0-1.1.i386/usr/lib/lib/monodevelop/AddIns/MonoDevelop.Debugger/MonoDevelop.Debugger.Gdb.dll*

Witch is related to the use of: 

%{_libdir}/lib/monodevelop/AddIns/MonoDevelop.Debugger/MonoDevelop.Debugger.Gdb.dll*

instead of the original:

%{_prefix}/lib/monodevelop/AddIns/MonoDevelop.Debugger/MonoDevelop.Debugger.Gdb.dll*

* --prefix=%_prefix is included in the %configure macro so you don't need it if
you use the %configure macro. - SEE PREVIOUS

* In Fedora, mono libraries are installed in %{_libdir} instead of /usr/lib. 
On x86_64 systems, that expands to /usr/lib6 instead of /usr/lib.- SEE PREVIOUS
 
* package needs to rm -rf %{buildroot} at the beginning of %install - DONE
* All filenames are UTF-8 - GOOD/BAD?

* No license file is included in the tarball so you should ask upstream if
they'll provide one with their next release. - ASKING

* Looks like you need to BuildRequire: monodevelop-devel rather than monodevelop. - DONE

Reviewed file can be found:
http://www.ic.uach.cl/mhenriquez/fedora10-monoRPMS/monodevelop-debugger-gdb.spec.review1


Thanks Toshio


Mauricio
Comment 4 Toshio Ernie Kuratomi 2009-04-23 20:16:08 EDT
(In reply to comment #3)
> First the doubts:
> you say: "* Package is named according to the naming Guidelines"
> My packages don't end with .fc10.rpm , don't know how to instruct rpmbuild to
> use that kind of name convention.
> 
Ah... this is optional, but it actually is a good thing to do (so upgrades between releases work).  Change the Release tag to:

  Release: 2%{?dist}

The %{dist} macro expands to fc10 on fedora 10, fc11 on Fedora 11, etc.  The "?" in the macro allows the rpm to build if the macro isn't defined on the system on which you're building.

> On "*Needswork" section you say: "* All filenames are UTF-8", that is good or
> bad?, need to change the text encoding?
> 
Ah.  Sorry.  I should have put that in the Good section.  Your encoding is fine.

> Fixed:
> * Spec file readability - DONE

* Still need to move the %file section to just before the %changelog section

> * BuildArch: i386 does not belong in the spec file: Here some doubts don't know
> if this addins are goin to compile fine in all architectures, it seems to me
> that it have to just x86/x86_64 for now, how do I mix the "BuildArch: noarh"
> and "ExclusiveArch: x86 x86_64"?

* You would do:
    ExclusiveArch: %ix86 x86_64
But what keeps the addins from compiling on other arches?  mono itself is being built on:
    %ix86 x86_64 ia64 armv4l sparcv9 alpha s390 s390x ppc ppc64

monodevelop is being built on:
    ExclusiveArch:  %ix86 x86_64 ia64 armv4l sparc alpha

You probably want to go with monodevelop's version as it is the more restricted of the two.  Since ppc and ppc64 is left off of there, you want to follow the directions here:
  http://fedoraproject.org/wiki/Packaging:Guidelines#Architecture_Support

So that people associated with ppc and ppc64 ports can track this bug and attempt to fix it.

> * You should use %configure rather than ./configure: Problem here, using
> "%configure" I get:

Yeah... I took a look.  The package has a hand-coded configure script instead of an autoconf generated one so it has limited options.  Try this for the configure line:

./configure --prefix=%{_prefix} --bindir=%{_bindir} --datadir=%{_datadir} --libdir=%{_libdir}

And it looks like you'll also have to patch one of the make files.

MonoDevelop.Debugger.Gdb.make hardcodes $(prefix)/lib/ instead of allowing libdir to override that.  You can patch the file or put this sed line into your %prep section:

  sed -i 's!INSTALL_DIR = $(DESTDIR)$(prefix)/lib/monodevelop/AddIns/MonoDevelop.Debugger!INSTALL_DIR = $(DESTDIR)%{_libdir}/monodevelop/AddIns/MonoDevelop.Debugger!' MonoDevelop.Debugger.Gdb.make


> RPM build errors:
>     File not found by glob:
> /home/buho/rpmbuild/BUILDROOT/monodevelop-debugger-gdb-2.0-1.1.i386/usr/lib/lib/monodevelop/AddIns/MonoDevelop.Debugger/MonoDevelop.Debugger.Gdb.dll*
> 
> Witch is related to the use of: 
> 
> %{_libdir}/lib/monodevelop/AddIns/MonoDevelop.Debugger/MonoDevelop.Debugger.Gdb.dll*

the goal is to be able to use:
  %{_libdir}/monodevelop/AddIns/MonoDevelop.Debugger/MonoDevelop.Debugger.Gdb.dll*

So it looks like you'll need to modify the file line a little.


New things:

* You need to bump the Release: field with every revision.  Since you also want to add the disttag, the next release should be:
  Release: 2%{?dist}


I was able to build in mock with the changes mentioned here.  So rpmlint output from the packages:

monodevelop-debugger-gdb.src: E: no-changelogname-tag
monodevelop-debugger-gdb.x86_64: E: no-changelogname-tag

* You need to add a %changelog entry to tell what you've done.  the format is shown here:
  https://fedoraproject.org/wiki/Packaging:Guidelines#Changelogs

monodevelop-debugger-gdb.src: W: strange-permission monodevelop-debugger-gdb-2.0.tar.bz2 0755

* 0644 would be the normal permissions for a tarball.

monodevelop-debugger-gdb.src: W: mixed-use-of-spaces-and-tabs (spaces: line 2, tab: line 1)

* Converting all tabs in the specfile into spaces would be a good idea.

monodevelop-debugger-gdb.x86_64: E: no-binary
monodevelop-debugger-gdb.x86_64: W: only-non-binary-in-usr-lib

* mono packages that only contain assemblies have no ELF files but they use architecture specific directories so they cannot be noarch.

monodevelop-debugger-gdb.x86_64: W: no-documentation

* In this case upstream is not providing any documentation files

monodevelop-debugger-gdb-debuginfo.x86_64: E: empty-debuginfo-package

* Presently, rpm doesn't know how to pull debug information from mono assemblies.  So we should be stopping the generation of debuginfo files.  This will change in the future.  This page has details of how to fix this:
   https://fedoraproject.org/wiki/Packaging:Debuginfo#Useless_or_incomplete_debuginfo_packages_due_to_other_reasons
 
You want to add this to your spec file:
  # rpm does not currently pull debuginfo out of mono packages
  %global debug_package %{nil}
Comment 5 Toshio Ernie Kuratomi 2009-04-23 20:17:46 EDT
I realized that it's a little ambiguous which of the rpmlint output you have to act on.  These are the ones that are false positives for this package:

monodevelop-debugger-gdb.x86_64: E: no-binary
monodevelop-debugger-gdb.x86_64: W: only-non-binary-in-usr-lib
monodevelop-debugger-gdb.x86_64: W: no-documentation
Comment 6 Mauricio Henriquez 2009-04-24 11:34:18 EDT
(In reply to comment #4)

> Change the Release tag to:
> 
DONE

> 
> Ah.  Sorry.  I should have put that in the Good section.  Your encoding is
> fine.
Great

> * Still need to move the %file section to just before the %changelog section
DONE
 
> monodevelop is being built on:
>     ExclusiveArch:  %ix86 x86_64 ia64 armv4l sparc alpha
> 
> You probably want to go with monodevelop's version as it is the more restricted
> of the two.  Since ppc and ppc64 is left off of there, you want to follow the
Ok yes, using the monodevelop one, please check that my ExclusiveArch is ok then, I remove the Build: noarch, that ok then?

 
> Yeah... I took a look.  The package has a hand-coded configure script instead
> of an autoconf generated one so it has limited options.  Try this for the
> configure line:
> 
> ./configure --prefix=%{_prefix} --bindir=%{_bindir} --datadir=%{_datadir}
> --libdir=%{_libdir}
DONE

 
> And it looks like you'll also have to patch one of the make files.
> 
> MonoDevelop.Debugger.Gdb.make hardcodes $(prefix)/lib/ instead of allowing
> libdir to override that.  You can patch the file or put this sed line into your
> %prep section:
> 
>   sed -i 's!INSTALL_DIR =
> $(DESTDIR)$(prefix)/lib/monodevelop/AddIns/MonoDevelop.Debugger!INSTALL_DIR =
> $(DESTDIR)%{_libdir}/monodevelop/AddIns/MonoDevelop.Debugger!'
> MonoDevelop.Debugger.Gdb.make
DONE, added the "sed" thing, don't quite sure about not make a mess with a patch.


> So it looks like you'll need to modify the file line a little.
DONE, using: %{_libdir}/monodevelop/AddIns/MonoDevelop.Debugger/MonoDevelop.Debugger.Gdb.dll* now


> New things:
> 
> * You need to bump the Release: field with every revision.  Since you also want
> to add the disttag, the next release should be:
>   Release: 2%{?dist}
not sure about what to do with this, I added that and package end with fc10.rpm...

> 
> I was able to build in mock with the changes mentioned here.  
Great, reviewd file can be found here:
http://www.ic.uach.cl/mhenriquez/fedora10-monoRPMS/monodevelop-debugger-gdb.spec.review2

> So rpmlint output
> from the packages:
> 
> monodevelop-debugger-gdb.src: E: no-changelogname-tag
> monodevelop-debugger-gdb.x86_64: E: no-changelogname-tag
> 
> * You need to add a %changelog entry to tell what you've done.  the format is
> shown here:
>   https://fedoraproject.org/wiki/Packaging:Guidelines#Changelogs
Ok I add a simple one, I try to put one in more details but as soon as I write things like "Add sed to the %prep section.." or stuff like taht, rpmbuild claim about thing tha he think that are "sections" and not take the text as just comments even if put %prep in quotations..

> monodevelop-debugger-gdb.src: W: strange-permission
> monodevelop-debugger-gdb-2.0.tar.bz2 0755
> 
> * 0644 would be the normal permissions for a tarball.
Can this be fixed in the tarball on koji?, or I have to change the permission of the tarball on the site that I put it?

> monodevelop-debugger-gdb.src: W: mixed-use-of-spaces-and-tabs (spaces: line 2,
> tab: line 1)
DONE, tabs removed
 
> * mono packages that only contain assemblies have no ELF files but they use
> architecture specific directories so they cannot be noarch.
Not sure what to do about this.
 
> monodevelop-debugger-gdb.x86_64: W: no-documentation
> 
> * In this case upstream is not providing any documentation files
Yeap no doc at the moment, so not my fault ;-) , probably because this is a really new addin.
 
> monodevelop-debugger-gdb-debuginfo.x86_64: E: empty-debuginfo-package
> 
> * Presently, rpm doesn't know how to pull debug information from mono
> assemblies.  So we should be stopping the generation of debuginfo files.  This
> will change in the future.  This page has details of how to fix this:
>   
> https://fedoraproject.org/wiki/Packaging:Debuginfo#Useless_or_incomplete_debuginfo_packages_due_to_other_reasons
> 
> You want to add this to your spec file:
>   # rpm does not currently pull debuginfo out of mono packages
>   %global debug_package %{nil}  
Yeap, I read about that fixing other package, so I add the line to this one, DONE

Thanks,

Mauricio
Comment 7 Mauricio Henriquez 2009-04-24 11:35:32 EDT
(In reply to comment #5)
> I realized that it's a little ambiguous which of the rpmlint output you have to
> act on.  These are the ones that are false positives for this package:
> 
> monodevelop-debugger-gdb.x86_64: E: no-binary
> monodevelop-debugger-gdb.x86_64: W: only-non-binary-in-usr-lib
> monodevelop-debugger-gdb.x86_64: W: no-documentation  

mmm, not sure what to do about this, is that a good or bad thing? (probably a bad one :-)
Comment 8 Toshio Ernie Kuratomi 2009-04-24 12:48:29 EDT
(In reply to comment #6)
> > monodevelop is being built on:
> >     ExclusiveArch:  %ix86 x86_64 ia64 armv4l sparc alpha
> > 
> Ok yes, using the monodevelop one, please check that my ExclusiveArch is ok
> then, I remove the Build: noarch, that ok then?

Yep, your ExclusiveArch line is fine now.

> DONE, added the "sed" thing, don't quite sure about not make a mess with a
> patch.
> 
heh.  You'll have to learn about diff and patch sooner or later since it's an integral part of package building but the sed line is fine for this package.

> > 
> > * You need to bump the Release: field with every revision.  Since you also want
> > to add the disttag, the next release should be:
> >   Release: 2%{?dist}
> not sure about what to do with this, I added that and package end with
> fc10.rpm...

Yep.  %{?dist} is a macro.  So when rpm builds the package on F-10, it expands
  Release: 2%{?dist}
into:
  Release: 2.fc10

When you build on F-11 it expands to:
  Release: 2.fc11

and so on.

> > * You need to add a %changelog entry to tell what you've done.  the format is
> > shown here:
> >   https://fedoraproject.org/wiki/Packaging:Guidelines#Changelogs
> Ok I add a simple one, I try to put one in more details but as soon as I write
> things like "Add sed to the %prep section.." or stuff like taht, rpmbuild claim
> about thing tha he think that are "sections" and not take the text as just
> comments even if put %prep in quotations..
> 

What happens is that macros/section headers are always expanded by rpmbuild.  (Note: This happens even when the macro is commented out.)  To get around that, escape the % with another %.  So your changelog could look like:

%changelog
* Fri Apr 24 2009 Mauricio Henriquez <buhochileno@gmail.com> - 2.0
- Fix the install directory via sed in the %%prep section.


> > monodevelop-debugger-gdb.src: W: strange-permission
> > monodevelop-debugger-gdb-2.0.tar.bz2 0755
> > 
> > * 0644 would be the normal permissions for a tarball.
> Can this be fixed in the tarball on koji?, or I have to change the permission
> of the tarball on the site that I put it?
>
This would be fixed by changing the permissions before you build the package/checkin the source.  I got the tarball out of your source rpm originally.
 
>> monodevelop-debugger-gdb.x86_64: E: no-binary
>> monodevelop-debugger-gdb.x86_64: W: only-non-binary-in-usr-lib
>> monodevelop-debugger-gdb.x86_64: W: no-documentation  

> mmm, not sure what to do about this, is that a good or bad thing? (probably a
bad one :-)  

In this case, these are false positives so they can all be ignored.  The reason they're false positives for this package are written in comment #6

The only other thing I notice in the updated spec is the buildroot tag.  If you look here:
  http://fedoraproject.org/wiki/Packaging/Guidelines#BuildRoot_tag

BuildRoot: %(mktemp -ud %{_tmppath}/%{name}-%{version}-%{release}-XXXXXX)
Comment 9 Toshio Ernie Kuratomi 2009-04-24 12:54:07 EDT
Oh -- and this just a readability nit.  I'd move this up to the top:
  # rpm does not currently pull debuginfo out of mono packages
  %global debug_package %{nil}
Comment 10 Mauricio Henriquez 2009-04-27 15:38:36 EDT
(In reply to comment #9)
> Oh -- and this just a readability nit.  I'd move this up to the top:
>   # rpm does not currently pull debuginfo out of mono packages
>   %global debug_package %{nil}  

Ok, I have to move that to the tip of the file? or just before %description ?

Also, waiting Paul answer about take over the mdb package, as soon as I get the response I going to apply what I learn with this review to that one for your review...
Comment 11 Mauricio Henriquez 2009-04-27 15:58:20 EDT
(In reply to comment #8)
> (In reply to comment #6)
> > > monodevelop is being built on:
> > >     ExclusiveArch:  %ix86 x86_64 ia64 armv4l sparc alpha
> > > 
> > Ok yes, using the monodevelop one, please check that my ExclusiveArch is ok
> > then, I remove the Build: noarch, that ok then?
> 
> Yep, your ExclusiveArch line is fine now.
Good :-)
> 
> > DONE, added the "sed" thing, don't quite sure about not make a mess with a
> > patch.
> > 
> heh.  You'll have to learn about diff and patch sooner or later since it's an
> integral part of package building but the sed line is fine for this package.
> 
yeap I know basic diff/patch commands, just that I don't want to mess my first package and the "sed" command seems to be more proved for now...

> > > 
> > > * You need to bump the Release: field with every revision.  Since you also want
> > > to add the disttag, the next release should be:
> > >   Release: 2%{?dist}
> > not sure about what to do with this, I added that and package end with
> > fc10.rpm...
> 
> Yep.  %{?dist} is a macro.  So when rpm builds the package on F-10, it expands
>   Release: 2%{?dist}
> into:
>   Release: 2.fc10
> 
> When you build on F-11 it expands to:
>   Release: 2.fc11
> 
> and so on.
> 
> > > * You need to add a %changelog entry to tell what you've done.  the format is
> > > shown here:
> > >   https://fedoraproject.org/wiki/Packaging:Guidelines#Changelogs
> > Ok I add a simple one, I try to put one in more details but as soon as I write
> > things like "Add sed to the %prep section.." or stuff like taht, rpmbuild claim
> > about thing tha he think that are "sections" and not take the text as just
> > comments even if put %prep in quotations..
> > 
> 
> What happens is that macros/section headers are always expanded by rpmbuild. 
> (Note: This happens even when the macro is commented out.)  To get around that,
> escape the % with another %.  So your changelog could look like:
> 
> %changelog
> * Fri Apr 24 2009 Mauricio Henriquez <buhochileno@gmail.com> - 2.0
> - Fix the install directory via sed in the %%prep section.
> 
ok, I apply this to the following changelog comments..
> 
> > > monodevelop-debugger-gdb.src: W: strange-permission
> > > monodevelop-debugger-gdb-2.0.tar.bz2 0755
> > > 
> > > * 0644 would be the normal permissions for a tarball.
> > Can this be fixed in the tarball on koji?, or I have to change the permission
> > of the tarball on the site that I put it?
> >
> This would be fixed by changing the permissions before you build the
> package/checkin the source.  I got the tarball out of your source rpm
> originally.
Ok changed

> 
> >> monodevelop-debugger-gdb.x86_64: E: no-binary
> >> monodevelop-debugger-gdb.x86_64: W: only-non-binary-in-usr-lib
> >> monodevelop-debugger-gdb.x86_64: W: no-documentation  
> 
> > mmm, not sure what to do about this, is that a good or bad thing? (probably a
> bad one :-)  
> 
> In this case, these are false positives so they can all be ignored.  The reason
> they're false positives for this package are written in comment #6
> 
> The only other thing I notice in the updated spec is the buildroot tag.  If you
> look here:
>   http://fedoraproject.org/wiki/Packaging/Guidelines#BuildRoot_tag
> 
> BuildRoot: %(mktemp -ud %{_tmppath}/%{name}-%{version}-%{release}-XXXXXX)  

Ok, updated files are:

http://www.ic.uach.cl/mhenriquez/fedora10-monoRPMS/monodevelop-debugger-gdb-2.0-2.fc10.src.rpm	

http://www.ic.uach.cl/mhenriquez/fedora10-monoRPMS/monodevelop-debugger-gdb.spec.review3

By the way, my main goal is to have this also for fed10, for that all the mono and monodevelop packages for fed11 from koji have to be rebuilded for fed10, currently I made that by hand, but the idea is to let koji to do that right?

As soon as I get the Paul answer I going to apply what I learn here to the mdb and other packages for your review...

Thanks for your kind help Toshio

Mauricio
Comment 12 Toshio Ernie Kuratomi 2009-04-27 17:01:39 EDT
(In reply to comment #10)
> (In reply to comment #9)
> > Oh -- and this just a readability nit.  I'd move this up to the top:
> >   # rpm does not currently pull debuginfo out of mono packages
> >   %global debug_package %{nil}  
> 
> Ok, I have to move that to the tip of the file? or just before %description ?
> 
top of the file.  It's easiest to spot definitions of global variables when they're at the top.
Comment 13 Mauricio Henriquez 2009-04-30 11:43:12 EDT
(In reply to comment #12)
> (In reply to comment #10)
> > (In reply to comment #9)
> > > Oh -- and this just a readability nit.  I'd move this up to the top:
> > >   # rpm does not currently pull debuginfo out of mono packages
> > >   %global debug_package %{nil}  
> > 
> > Ok, I have to move that to the tip of the file? or just before %description ?
> > 
> top of the file.  It's easiest to spot definitions of global variables when
> they're at the top.  

Sorry for the delay, to bussy the last ones...Ok, here is the new review:
http://www.ic.uach.cl/mhenriquez/fedora10-monoRPMS/monodevelop-debugger-gdb.spec.review4

I get the Paul answer for the mdb package, so I going to apply what to learn here...stay tune..

Thanks Toshio

Mauricio
Comment 14 Mauricio Henriquez 2009-05-06 16:46:11 EDT
(In reply to comment #12)
> (In reply to comment #10)
> > (In reply to comment #9)
> > > Oh -- and this just a readability nit.  I'd move this up to the top:
> > >   # rpm does not currently pull debuginfo out of mono packages
> > >   %global debug_package %{nil}  
> > 
> > Ok, I have to move that to the tip of the file? or just before %description ?
> > 
> top of the file.  It's easiest to spot definitions of global variables when
> they're at the top.  

what is the status of this package then?, can be say it that is
ready?, is going to be included into fed11, fed12?, any chance that can be
rebuilded with all mono/monodevelop stack for fed10?

Thanks

Mauricio
Comment 15 Mauricio Henriquez 2009-05-12 09:26:58 EDT
What is the final status of this packages?, is going to be included in fed11?, as an update in the repos?
Comment 16 Toshio Ernie Kuratomi 2009-06-11 21:15:46 EDT
Okay, so Paul's finished the review of the other package.
This package is APPROVED
Comment 17 Bug Zapper 2009-11-18 06:47:51 EST
This message is a reminder that Fedora 10 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 10.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '10'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 10's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 10 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 18 Bug Zapper 2009-12-18 04:17:44 EST
Fedora 10 changed to end-of-life (EOL) status on 2009-12-17. Fedora 10 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

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