Bug 496635 - Review Request: monodevelop-debugger-mdb - Mono Debugger Addin for MonoDevelop
Review Request: monodevelop-debugger-mdb - Mono Debugger Addin for MonoDevelop
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
rawhide
All Linux
low Severity medium
: ---
: ---
Assigned To: Paul Lange
Fedora Extras Quality Assurance
:
: 490030 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-04-20 09:29 EDT by Mauricio Henriquez
Modified: 2009-10-08 06:12 EDT (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-10-08 06:12:26 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
palango: fedora‑review+
tibbs: fedora‑cvs+


Attachments (Terms of Use)
Fixes RELEASE build configuration and libdir on x86_64 (3.62 KB, patch)
2009-05-02 13:57 EDT, Ryan Bair
no flags Details | Diff
Fixes build on x86_64 (1.03 KB, patch)
2009-05-02 13:59 EDT, Ryan Bair
no flags Details | Diff
Fixes RELEASE build configuration and libdir on x86_64 (4.01 KB, patch)
2009-05-02 14:09 EDT, Ryan Bair
no flags Details | Diff
Update spec file (1.87 KB, application/octet-stream)
2009-05-03 20:01 EDT, Ryan Bair
no flags Details
spec file updated (1.89 KB, application/octet-stream)
2009-06-03 17:34 EDT, Mauricio Henriquez
no flags Details
src.rpm package updated (118.61 KB, application/x-rpm)
2009-06-03 17:35 EDT, Mauricio Henriquez
no flags Details
release number and devel subpackage added (2.47 KB, application/octet-stream)
2009-06-04 11:23 EDT, Mauricio Henriquez
no flags Details
src rpm created acording the las spec file changes (118.95 KB, application/x-rpm)
2009-06-04 11:24 EDT, Mauricio Henriquez
no flags Details
wrong devel description, fixed (2.41 KB, application/octet-stream)
2009-06-04 11:34 EDT, Mauricio Henriquez
no flags Details
src rpm acording to last spec file (118.88 KB, application/x-rpm)
2009-06-04 11:36 EDT, Mauricio Henriquez
no flags Details
new spec file (2.41 KB, application/octet-stream)
2009-06-05 13:32 EDT, Mauricio Henriquez
no flags Details
new src rpm (44.74 KB, application/x-rpm)
2009-06-05 13:32 EDT, Mauricio Henriquez
no flags Details
changes.. (2.13 KB, application/octet-stream)
2009-06-08 17:02 EDT, Mauricio Henriquez
no flags Details
x86_64 removed (2.13 KB, application/octet-stream)
2009-06-08 17:39 EDT, Mauricio Henriquez
no flags Details

  None (edit)
Description Mauricio Henriquez 2009-04-20 09:29:01 EDT
Spec URL: http://www.ic.uach.cl/mhenriquez/fedora10-monoRPMS/monodevelop-debugger-mdb.spec
SRPM URL: http://www.ic.uach.cl/mhenriquez/fedora10-monoRPMS/monodevelop-debugger-mdb-2.0-1.1.src.rpm
Description: Mono Debugger Addin for MonoDevelop.
This package is for Fedora 10 and 11 (rawhide).
This is my first package, so I need a sponsor.
Comment 1 Toshio Ernie Kuratomi 2009-04-24 12:57:27 EDT
So this package has already been submitted for review by Paul Lange:
  https://bugzilla.redhat.com/show_bug.cgi?id=490030

It's polite to ask Paul if he wants to update his package or would be alright if you take over the package.  If he updates his package, you can do a review of his package.  If he would rather you take over you can look at his spec file for ideas, update your package with ideas from his spec and the other review we've done, and I'll review.
Comment 2 Mauricio Henriquez 2009-04-27 15:31:14 EDT
(In reply to comment #1)
> So this package has already been submitted for review by Paul Lange:
>   https://bugzilla.redhat.com/show_bug.cgi?id=490030
> 
> It's polite to ask Paul if he wants to update his package or would be alright
> if you take over the package.  If he updates his package, you can do a review
> of his package.  If he would rather you take over you can look at his spec file
> for ideas, update your package with ideas from his spec and the other review
> we've done, and I'll review.  

Your are absolutly right, I'm asking him...
Comment 3 Paul Lange 2009-04-27 18:55:30 EDT
*** Bug 490030 has been marked as a duplicate of this bug. ***
Comment 4 Paul Lange 2009-04-27 18:56:58 EDT
I don't have time to work on this right now, so I declared my review request at duplicate of this.

Move on Mauricio! Thanks for the help.
Comment 5 Mauricio Henriquez 2009-04-30 12:12:24 EDT
(In reply to comment #1)
> So this package has already been submitted for review by Paul Lange:
>   https://bugzilla.redhat.com/show_bug.cgi?id=490030
> 
> It's polite to ask Paul if he wants to update his package or would be alright
> if you take over the package.  If he updates his package, you can do a review
> of his package.  If he would rather you take over you can look at his spec file
> for ideas, update your package with ideas from his spec and the other review
> we've done, and I'll review.  

Ok, Paul marked his package as duplicated, so you can find the new ones that I'm submiting at:

Spec
http://www.ic.uach.cl/mhenriquez/fedora10-monoRPMS/monodevelop-debugger-mdb.spec

Source RPM
http://www.ic.uach.cl/mhenriquez/fedora10-monoRPMS/monodevelop-debugger-mdb-2.0-1.1.fc10.src.rpm	

I apply all the thing that you told (at least I think that I not forget nothing...but probably I do :-S

Please check the all the spec file, but specially the %install and %file sections in witch I have more doubts..

The package seems to be builded ok, as soon as you tell me that is ok I going to test it in some machines here...

Thanks again Toshio...

P.D: What about the full mono/monodevelop plus the mdb and gdb packages for fed10?, how to procede with that?
Comment 6 Ryan Bair 2009-05-02 13:57:49 EDT
Created attachment 342186 [details]
Fixes RELEASE build configuration and libdir on x86_64

I'll pass these changes on to upstream.
Comment 7 Ryan Bair 2009-05-02 13:59:19 EDT
Created attachment 342187 [details]
Fixes build on x86_64
Comment 8 Ryan Bair 2009-05-02 14:09:41 EDT
Created attachment 342189 [details]
 Fixes RELEASE build configuration and libdir on x86_64 

Removed make.config and make.log from the patch.
Comment 9 Mauricio Henriquez 2009-05-02 15:13:23 EDT
(In reply to comment #8)
> Created an attachment (id=342189) [details]
>  Fixes RELEASE build configuration and libdir on x86_64 
> 
> Removed make.config and make.log from the patch.  

Hi Ryan, are you making those changes?, where can I find the modified files?, I was under the impression that I was commiting this packages and I was in charge of make the modifications (also to learn and hopefully at some point don't need a sponsor..)

So is summary, you are going to make the necesary changes and I don't have to do anithing else?

I'm sure that you are concern about upcomming fedora releases, but I'm also worrie about the current state of the stable fedora release (the 10, remember that one??)

I also have semi-prapered other monodevelop packages for fedora that need a reviewer/sponsor, is this the way in witch you are going to deal with my packages?

Mauricio
Comment 10 Ryan Bair 2009-05-03 09:45:01 EDT
I added the two patches as attachments to the bug. The first patch is against the spec file and the second patch is against the unpacked source tarball. Both patches fix the assumption that the libdir should be in prefix/lib (/usr/lib) which works on x86 but not on x86_64 (where it is /usr/lib64). Also, the x86_64 build does not work because of the pc file issue described in bug 490025 (which I also wrote a patch for yesterday). I would mark it as a blocker, but I don't seem to have access to do so. 

I'm not trying to take over your package, just fixing a few miscellaneous issues that prevented me from compiling/installing/using/enjoying the package myself. 

As a warning, I am new to both RPM packaging and the Fedora guidelines so I could have committed a major sin. Please check my patches.
Comment 11 Mauricio Henriquez 2009-05-03 18:05:48 EDT
(In reply to comment #10)
> I added the two patches as attachments to the bug. The first patch is against
> the spec file and the second patch is against the unpacked source tarball. Both
> patches fix the assumption that the libdir should be in prefix/lib (/usr/lib)
> which works on x86 but not on x86_64 (where it is /usr/lib64). Also, the x86_64
> build does not work because of the pc file issue described in bug 490025 (which
> I also wrote a patch for yesterday). I would mark it as a blocker, but I don't
> seem to have access to do so. 
> 
> I'm not trying to take over your package, just fixing a few miscellaneous
> issues that prevented me from compiling/installing/using/enjoying the package
> myself. 
Is not what I meant, is just that you are making changes to a also newbie guy package, so I don't have a clue if your patchs are correct or not, thats is way I was waiting to some sponsor/experienced guys to let what to do with the packaes. But sure, if in the meantime you test some of your patch and you know that makes the magic, so then is a step forward, is just that we are going to wait for someone that really tell us that our changes are correct...Still have lot of doubts about how koji works, etc...

Thanks!!

Mauricio..

> 
> As a warning, I am new to both RPM packaging and the Fedora guidelines so I
> could have committed a major sin. Please check my patches.
Comment 12 Ryan Bair 2009-05-03 20:01:51 EDT
Created attachment 342262 [details]
Update spec file

Going the (seemingly) preferred route of fixing the install process in the spec as opposed to the source itself. I feel pretty good with this one. Comments?
Comment 13 Toshio Ernie Kuratomi 2009-05-04 13:56:44 EDT
Mauricio, I'd apply the changes from Ryan to fix outstanding issues.  If you don't understand why something is being done, go ahead and ask here before applying that section and either Ryan or I can explain what's being done and whether there are other/better ways.
Comment 14 Mauricio Henriquez 2009-05-06 16:43:53 EDT
(In reply to comment #13)
> Mauricio, I'd apply the changes from Ryan to fix outstanding issues.  If you
> don't understand why something is being done, go ahead and ask here before
> applying that section and either Ryan or I can explain what's being done and
> whether there are other/better ways.  

Ok, sure, what is the final 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:36 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-05-12 09:56:21 EDT
Sorry, I've been busy this past week.

I'm waiting on you to merge the changes from Ryan that you think are appropriate and then post new versions of the spec file and srpm.
Comment 17 Mauricio Henriquez 2009-05-12 13:25:18 EDT
(In reply to comment #16)
> Sorry, I've been busy this past week.
> 
> I'm waiting on you to merge the changes from Ryan that you think are
> appropriate and then post new versions of the spec file and srpm.  

Ok, that is the kind of stuff that I don't know hoe to procede, that is way I ask things like "that is the way in witch packages are treated..", meaning that I don't know ho is making the changes and from ho are they take it....I was under the impresion that the Ryan attached .spec files was the "updated ones", so no idea that you was waiting to me to merge the changes...

So, ok here are the updated files:
http://www.ic.uach.cl/mhenriquez/fedora10-monoRPMS/monodevelop-debugger-mdb.spec
http://www.ic.uach.cl/mhenriquez/fedora10-monoRPMS/monodevelop-debugger-mdb-2.0-1.1.fc10.src.rpm	

Hope that sitll can make it at least for fed11 updates...what about the gdb one?

Cheers,

Mauricio
Comment 18 Paul Lange 2009-06-01 14:34:17 EDT
What's the state of this? Anyone working on review?
Comment 19 Toshio Ernie Kuratomi 2009-06-01 14:57:55 EDT
Paul, if you want it, feel free to take over the review.  I've gotten suddenly busy with the release looming.  (I can still sponsor if you are satisfied with Mauricio's work).
Comment 20 Paul Lange 2009-06-02 15:20:10 EDT
OK Toshio, I'm taking this over.

Mauricio: it's a good practice to try building packages in mock. It looks difficult at the beginning (I know this from my own experience) but helps you to create high-quality packages.
For stepping in have a look at http://fedoraproject.org/wiki/PackageMaintainers/MockTricks
 
With using mock you'll find out that you need to more build dependencies:
* mono-debugger-devel instead of mono-debugger
* mono-addins-devel

Furthermore I would prefer to adjust the release number to a single number.

The %defattr macro in %files should be %defattr(-,root,root,-)

At the end it would be great if you could split out the *.pc file in a *-devel package.


The rest looks really good and builds well. If we solve this last errors I'll do the full review. 
Thanks also to Ryan for creating the fixes!

Paul
Comment 21 Mauricio Henriquez 2009-06-02 15:59:01 EDT
Ok, Paul, thank for the sugestions, is going to take me a couple of days to try the mock thing (very bussy this week), but the rest of the changes may be tomorrow..

Mauricio
Comment 22 Mauricio Henriquez 2009-06-03 17:34:03 EDT
Created attachment 346464 [details]
spec file updated

spec file updated
Comment 23 Mauricio Henriquez 2009-06-03 17:35:16 EDT
Created attachment 346465 [details]
src.rpm package updated
Comment 24 Mauricio Henriquez 2009-06-03 17:39:10 EDT
(In reply to comment #20)
> OK Toshio, I'm taking this over.
> 
> Mauricio: it's a good practice to try building packages in mock. It looks
> difficult at the beginning (I know this from my own experience) but helps you
> to create high-quality packages.
> For stepping in have a look at
> http://fedoraproject.org/wiki/PackageMaintainers/MockTricks
> 
Ok, this is going to take me a while, currently very bussy and I have to make some space to do the local mirror, etc...so hopefully the packages created without mock are at least at a decent quality :-)
> With using mock you'll find out that you need to more build dependencies:
> * mono-debugger-devel instead of mono-debugger
> * mono-addins-devel
fixed in the attached files...
> 
> Furthermore I would prefer to adjust the release number to a single number.
> 
> The %defattr macro in %files should be %defattr(-,root,root,-)
done...
> 
> At the end it would be great if you could split out the *.pc file in a *-devel
> package.
> 
no idea how to do that, if you teach me with this package I can apply it ot the other mono packages that I'm preparing..The mainstream don't do that with the package, at least not with the opensuse one...
> 
> The rest looks really good and builds well. If we solve this last errors I'll
> do the full review. 
great!!, thanks, what about the gdb package?, both debuggers addins (mdb and gdb) for monodevelop are very handy..

> Thanks also to Ryan for creating the fixes!
Yeap, thanks Ryan!!
> 
> Paul  

Mauricio
Comment 25 Paul Lange 2009-06-03 18:42:45 EDT
You can find a simple example for creating a devel-subpackage in my flickrnet package here:
http://cvs.fedoraproject.org/viewvc/rpms/flickrnet/devel/flickrnet.spec?view=markup

More complete information is at http://www.rpm.org/max-rpm/ch-rpm-subpack.html

Could you please adjust the release number to a single number (not 1.1; and please adjust the changelog accordingly)


If you create some packages for the gdb-debugger I'll have a look at them too!

Paul
Comment 26 Mauricio Henriquez 2009-06-04 11:23:16 EDT
Created attachment 346550 [details]
release number and devel subpackage added
Comment 27 Mauricio Henriquez 2009-06-04 11:24:52 EDT
Created attachment 346551 [details]
src rpm created acording the las spec file changes
Comment 28 Mauricio Henriquez 2009-06-04 11:34:46 EDT
Created attachment 346553 [details]
wrong devel description, fixed
Comment 29 Mauricio Henriquez 2009-06-04 11:36:03 EDT
Created attachment 346554 [details]
src rpm acording to last spec file
Comment 30 Mauricio Henriquez 2009-06-04 11:37:17 EDT
(In reply to comment #25)
> You can find a simple example for creating a devel-subpackage in my flickrnet
> package here:
> http://cvs.fedoraproject.org/viewvc/rpms/flickrnet/devel/flickrnet.spec?view=markup
> 
> More complete information is at http://www.rpm.org/max-rpm/ch-rpm-subpack.html
> 
done..hope that it is ok..
> Could you please adjust the release number to a single number (not 1.1; and
> please adjust the changelog accordingly)
done...
> 
> 
> If you create some packages for the gdb-debugger I'll have a look at them too!
> 
https://bugzilla.redhat.com/show_bug.cgi?id=496633
> Paul  

Mauricio
Comment 31 Paul Lange 2009-06-04 13:04:38 EDT
Maricio, your source tarball includes a folder called 'build' which shouldn't be there. Have you packed it yourself? I checked the tarball from the website and it's not included there. Please replace the tarball with the correct one.

Please make the release numbers increasing (latest should be 3). Furthermore we can simplify the ./configure... line through the use of the %configure macro.

btw, we are on a good way :)
Comment 32 Mauricio Henriquez 2009-06-05 13:32:06 EDT
Created attachment 346692 [details]
new spec file
Comment 33 Mauricio Henriquez 2009-06-05 13:32:54 EDT
Created attachment 346693 [details]
new src rpm
Comment 34 Mauricio Henriquez 2009-06-05 13:37:17 EDT
(In reply to comment #31)
> Maricio, your source tarball includes a folder called 'build' which shouldn't
> be there. Have you packed it yourself? I checked the tarball from the website
> and it's not included there. Please replace the tarball with the correct one.
> 
sorry, it was from a previous work when I use the debugger addins compiling and installing before the package creation, removed..hope that the configure.log and may be other files are ok to be there..
> Please make the release numbers increasing (latest should be 3).
ok increased to 3, don't know if you mean in a "auto" way..
> Furthermore we
> can simplify the ./configure... line through the use of the %configure macro.
> 
can't, using %configure macro I get:
+ ./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]

> btw, we are on a good way :)  
hopefully, btw I forget to add another log entry about the incresing realease number and the build folder removed, hope that don't matter..


Mauricio
Comment 35 Paul Lange 2009-06-05 14:05:26 EDT
The source tarball has to be exactly the same as the upstream release. You can check that with md5sum:
[paul@papaya SOURCES]$ md5sum monodevelop-debugger-mdb-2.0.tar.bz2 
55f225ffb47a67289d342bf389e133c8  monodevelop-debugger-mdb-2.0.tar.bz2
[paul@papaya SOURCES]$ md5sum ../../Downloads/monodevelop-debugger-mdb-2.0.tar.bz2 
b60e9a0783f294aaa137c78e32c4f6be  ../../Downloads/monodevelop-debugger-mdb-2.0.tar.bz2

Please use the upstream tarball.

I know it's nutpicking - but lets make it right: What I meant with change the changelog is this diff:
67c67
< * Thu Jun 04 2009 Mauricio Henriquez <buhochileno@gmail.com> - 2.0-1
---
> * Thu Jun 04 2009 Mauricio Henriquez <buhochileno@gmail.com> - 2.0-3
70c70
< * Sun May 03 2009 Ryan Bair <ryan@thebairs.info> - 2.0-1
---
> * Sun May 03 2009 Ryan Bair <ryan@thebairs.info> - 2.0-2
73c73
< * Thu Apr 30 2009 Mauricio Henriquez <buhochileno@gmail.com> - 2.0
---
> * Thu Apr 30 2009 Mauricio Henriquez <buhochileno@gmail.com> - 2.0-1


The last entry should always be equal to the version and release number. Hope that makes sense to you.

OK, only the tarball left for the review. :)
Comment 36 Mauricio Henriquez 2009-06-05 14:57:23 EDT
(In reply to comment #35)
> The source tarball has to be exactly the same as the upstream release. You can
> check that with md5sum:
> [paul@papaya SOURCES]$ md5sum monodevelop-debugger-mdb-2.0.tar.bz2 
> 55f225ffb47a67289d342bf389e133c8  monodevelop-debugger-mdb-2.0.tar.bz2
> [paul@papaya SOURCES]$ md5sum
> ../../Downloads/monodevelop-debugger-mdb-2.0.tar.bz2 
> b60e9a0783f294aaa137c78e32c4f6be 
> ../../Downloads/monodevelop-debugger-mdb-2.0.tar.bz2
> 
> Please use the upstream tarball.
using the upstream packages I get:
.0.0.0 mono(mscorlib) = 2.0.0.0
Processing files: monodevelop-debugger-mdb-devel-2.0-3.fc10
rpmbuild: rpmfc.c:407: rpmfcHelper: Assertion `EVR != ((void *)0)' failed.
Aborted

That is a bug in rpmbuild tools that crash with certain missing info in the sources, now I don't remeber what exactly wha tit was, but if I remember correctly was the missing Version info at:
mono.debugging.backend.mdb.pc.in

> 
> I know it's nutpicking - but lets make it right: What I meant with change the
> changelog is this diff:
> 67c67
> < * Thu Jun 04 2009 Mauricio Henriquez <buhochileno@gmail.com> - 2.0-1
> ---
> > * Thu Jun 04 2009 Mauricio Henriquez <buhochileno@gmail.com> - 2.0-3
> 70c70
> < * Sun May 03 2009 Ryan Bair <ryan@thebairs.info> - 2.0-1
> ---
> > * Sun May 03 2009 Ryan Bair <ryan@thebairs.info> - 2.0-2
> 73c73
> < * Thu Apr 30 2009 Mauricio Henriquez <buhochileno@gmail.com> - 2.0
> ---
> > * Thu Apr 30 2009 Mauricio Henriquez <buhochileno@gmail.com> - 2.0-1
> 
> 
> The last entry should always be equal to the version and release number. Hope
> that makes sense to you.
nop, sorry not at all :-S

Something like this for the last one then?:
* Thu Jun 05 2009 Mauricio Henriquez <buhochileno@gmail.com> - 2.0-3
- Source tarball changed to the upstream one
..also why we are using "3" as the release number?
> 
> OK, only the tarball left for the review. :)
Comment 37 Paul Lange 2009-06-06 21:38:15 EDT
Hey Mauricio,

the upstream tarball build well in mock. What have you tried and whats your system? (btw, the diff between your tarball and the official one shows no changes at mono.debugging.backend.mdb.pc.in)
s the version of 
To version numbers:
Every version of your package needs an unique identifier. We use a [project-version]-[package-release] form, where [project-version] is the version of the upstream project and [package-release] the version of the package (which starts from 1 for each new upstream version btw)

The release number at the beginning of the spec-file should be the same as the latest changelog entry. Because of this I said we should take three, because there currently are 3 entries. We could replace them by one, then we would set release number to 1 again. I would support that, maybe with a text like this:
* Thu Jun 04 2009 Mauricio Henriquez <buhochileno@gmail.com> - 2.0-1
- Initial packaging with help by Ryan Bair

Hope this makes things clearer for you!?

Furthermore could we have a better package description?

Thanks for your work!
Paul
Comment 38 Mauricio Henriquez 2009-06-08 17:02:25 EDT
Created attachment 346933 [details]
changes..
Comment 39 Mauricio Henriquez 2009-06-08 17:10:23 EDT
(In reply to comment #37)
> Hey Mauricio,
> 
> the upstream tarball build well in mock. What have you tried and whats your
> system?
Fedora 10  2.6.27.15-170.2.24.fc10.i686, rpm tools:

rpm-4.6.0-2.fc10.i386
rpmrebuild-2.3-1.fc10.noarch
rpm-devel-4.6.0-2.fc10.i386
rpm-build-4.6.0-2.fc10.i386
rpm-apidocs-4.6.0-1.fc10.i386
rpmdevtools-7.0-1.fc10.noarch
rpm-libs-4.6.0-2.fc10.i386

 (btw, the diff between your tarball and the official one shows no
> changes at mono.debugging.backend.mdb.pc.in)
yeap, I try it again, I have to add version info (Version: 2.0) in mono.debugging.backend.mdb.pc.in file, due to that, I only attach you the .spec file, becouse I can't generate the src.rpm package:
rpmbuild: rpmfc.c:407: rpmfcHelper: Assertion `EVR != ((void *)0)' failed.
Aborted

I find it as a bug in rpmbuild tools, can't find the link now, To generate the src.rpm package I need to modifie sources and since that package is not going to have original upstream source tarbal....
> s the version of 
> To version numbers:
> Every version of your package needs an unique identifier. We use a
> [project-version]-[package-release] form, where [project-version] is the
> version of the upstream project and [package-release] the version of the
> package (which starts from 1 for each new upstream version btw)
> 
> The release number at the beginning of the spec-file should be the same as the
> latest changelog entry. Because of this I said we should take three, because
> there currently are 3 entries. We could replace them by one, then we would set
> release number to 1 again. I would support that, maybe with a text like this:
> * Thu Jun 04 2009 Mauricio Henriquez <buhochileno@gmail.com> - 2.0-1
> - Initial packaging with help by Ryan Bair
> 
> Hope this makes things clearer for you!?
dummy me!! :-) , yeap sure, have prefect sense for me now, sorry :-S, think that this time is going to be ok..

> 
> Furthermore could we have a better package description?
>
I prefer not, that is the original upstream description that is showed in diferent places, don't want to put some mistake in there , and is quite clear to me actually..
> Thanks for your work!
your wellcome..
> Paul  

Mauricio
Comment 40 Paul Lange 2009-06-08 17:25:47 EDT
Hey Mauricio,

I don't need to add anything. Look at http://koji.fedoraproject.org/koji/taskinfo?taskID=1400013

It builds well on i586 with the original tarball. We should remove x86_64 for now because of bug #490025
https://bugzilla.redhat.com/show_bug.cgi?id=490025

Thanks.
Comment 41 Mauricio Henriquez 2009-06-08 17:39:06 EDT
Created attachment 346937 [details]
x86_64 removed
Comment 42 Mauricio Henriquez 2009-06-08 17:40:33 EDT
(In reply to comment #40)
> Hey Mauricio,
> 
> I don't need to add anything. Look at
> http://koji.fedoraproject.org/koji/taskinfo?taskID=1400013
I believe you, glad it work, still same thing here, so I just attach the spec file
> 
> It builds well on i586 with the original tarball. We should remove x86_64 for
> now because of bug #490025
> https://bugzilla.redhat.com/show_bug.cgi?id=490025
ok, removed..
> 
> Thanks.
Comment 43 Paul Lange 2009-06-09 20:26:38 EDT
- MUST: rpmlint must be run on every package. The output should be posted
in the review:
monodevelop-debugger-mdb.i586: E: no-binary
monodevelop-debugger-mdb.i586: W: only-non-binary-in-usr-lib
monodevelop-debugger-mdb.i586: W: no-documentation
monodevelop-debugger-mdb.src:47: E: hardcoded-library-path in %{_prefix}/lib/monodevelop/AddIns/MonoDevelop.Debugger/DebuggerClient.dll*
monodevelop-debugger-mdb.src:49: E: hardcoded-library-path in %{_prefix}/lib/monodevelop/AddIns/MonoDevelop.Debugger/DebuggerServer.exe*
monodevelop-debugger-mdb.src:51: E: hardcoded-library-path in %{buildroot}/usr/lib
monodevelop-debugger-mdb-devel.i586: E: description-line-too-long The monodevelop-debugger-mdb-devel package contains development files for monodevelop-debugger-mdb.
monodevelop-debugger-mdb-devel.i586: W: no-documentation
3 packages and 0 specfiles checked; 5 errors, 3 warnings.

* hardcoded paths are only the old location - OK
* no-documentation: no docs available
* no-binary, only-non-bin...: mono bins are not recognized

* TODO: shorten description line


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

- MUST: The package must be licensed with a Fedora approved license and meet
the Licensing Guidelines.
OK

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

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

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

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

- MUST: The sources used to build the package must match the upstream source,
as provided in the spec URL. Reviewers should use md5sum for this task. If no
upstream URL can be specified for this package, please see the Source URL
Guidelines for how to deal with this.
OK - b60e9a0783f294aaa137c78e32c4f6be - md5 of the original tarball

- MUST: The package MUST successfully compile and build into binary rpms on at
least one primary architecture.
OK - i386

- 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 MUST have a bug filed in
bugzilla, describing the reason that the package does not compile/build/work on
that architecture. The bug number MUST be placed in a comment, next to the
corresponding ExcludeArch line.
OK - bug in x86_64 and mono-debugger not available on other architectures

- MUST: All build dependencies must be listed in BuildRequires, except for any
that are listed in the exceptions section of the Packaging Guidelines ;
inclusion of those as BuildRequires is optional. Apply common sense.
OK

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

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

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

- MUST: Each package must consistently use macros.
OK

- MUST: The package must contain code, or permissable content.
OK

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

- MUST: At the beginning of %install, each package MUST run rm -rf %{buildroot}
(or $RPM_BUILD_ROOT).
OK

- MUST: All filenames in rpm packages must be valid UTF-8.
OK

############################################################

One thing left before you can upload the package in CVS:

- Please shorten the Description line. (Simply place the %{name} variable in a 
new line.

This is the only thing left. It's only minor, so I'm going to approve this 
package right now. Thank you for the hard work. Do you already have been 
sponsored?

More info for the next steps: 
http://fedoraproject.org/wiki/PackageMaintainers/Join#Get_Sponsored

APPROVED
Comment 44 Mauricio Henriquez 2009-06-09 20:55:36 EDT
(In reply to comment #43)
> - MUST: rpmlint must be run on every package. The output should be posted
> in the review:
> monodevelop-debugger-mdb.i586: E: no-binary
> monodevelop-debugger-mdb.i586: W: only-non-binary-in-usr-lib
> monodevelop-debugger-mdb.i586: W: no-documentation
> monodevelop-debugger-mdb.src:47: E: hardcoded-library-path in
> %{_prefix}/lib/monodevelop/AddIns/MonoDevelop.Debugger/DebuggerClient.dll*
> monodevelop-debugger-mdb.src:49: E: hardcoded-library-path in
> %{_prefix}/lib/monodevelop/AddIns/MonoDevelop.Debugger/DebuggerServer.exe*
> monodevelop-debugger-mdb.src:51: E: hardcoded-library-path in
> %{buildroot}/usr/lib
> monodevelop-debugger-mdb-devel.i586: E: description-line-too-long The
> monodevelop-debugger-mdb-devel package contains development files for
> monodevelop-debugger-mdb.
> monodevelop-debugger-mdb-devel.i586: W: no-documentation
> 3 packages and 0 specfiles checked; 5 errors, 3 warnings.
> 
> * hardcoded paths are only the old location - OK
> * no-documentation: no docs available
> * no-binary, only-non-bin...: mono bins are not recognized
> 
> * TODO: shorten description line
> 
> 
> - 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.
> OK
> 
> - MUST: The package must be licensed with a Fedora approved license and meet
> the Licensing Guidelines.
> OK
> 
> - MUST: The License field in the package spec file must match the actual
> license.
> OK
> 
> - 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.
> OK
> 
> - MUST: The spec file must be written in American English.
> OK
> 
> - MUST: The spec file for the package MUST be legible.
> OK
> 
> - MUST: The sources used to build the package must match the upstream source,
> as provided in the spec URL. Reviewers should use md5sum for this task. If no
> upstream URL can be specified for this package, please see the Source URL
> Guidelines for how to deal with this.
> OK - b60e9a0783f294aaa137c78e32c4f6be - md5 of the original tarball
> 
> - MUST: The package MUST successfully compile and build into binary rpms on at
> least one primary architecture.
> OK - i386
> 
> - 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 MUST have a bug filed in
> bugzilla, describing the reason that the package does not compile/build/work on
> that architecture. The bug number MUST be placed in a comment, next to the
> corresponding ExcludeArch line.
> OK - bug in x86_64 and mono-debugger not available on other architectures
> 
> - MUST: All build dependencies must be listed in BuildRequires, except for any
> that are listed in the exceptions section of the Packaging Guidelines ;
> inclusion of those as BuildRequires is optional. Apply common sense.
> OK
> 
> - MUST: A package must not contain any duplicate files in the %files listing.
> OK
> 
> - 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.
> OK
> 
> - MUST: Each package must have a %clean section, which contains rm -rf
> %{buildroot} (or $RPM_BUILD_ROOT).
> OK
> 
> - MUST: Each package must consistently use macros.
> OK
> 
> - MUST: The package must contain code, or permissable content.
> OK
> 
> - 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 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.
> OK
> 
> - MUST: At the beginning of %install, each package MUST run rm -rf %{buildroot}
> (or $RPM_BUILD_ROOT).
> OK
> 
> - MUST: All filenames in rpm packages must be valid UTF-8.
> OK
> 
> ############################################################
> 
> One thing left before you can upload the package in CVS:
> 
> - Please shorten the Description line. (Simply place the %{name} variable in a 
> new line.
you mean just this?:

%description
%{name} 

> 
> This is the only thing left. It's only minor, so I'm going to approve this 
> package right now. Thank you for the hard work. Do you already have been 
> sponsored?
Think not, Toshio help me at the beggining but think that no one officially sponsor me...
> 
> More info for the next steps: 
> http://fedoraproject.org/wiki/PackageMaintainers/Join#Get_Sponsored
reading...
> 
> APPROVED  
Great!!!, uuhhuuu, finally my first package...what a ride ;-)

Thanks Paul..
Comment 45 Paul Lange 2009-06-11 16:33:13 EDT
make
The %{name}-devel package contains development files for %{name}.
to
The %{name}-devel package contains development files for 
%{name}.

%{name} is replaced with monodevelop-debugger-mdb and so the line gets longer than 80 characters which we want to avoid.

I'll write Toshio a mail.
Comment 46 Toshio Ernie Kuratomi 2009-06-11 21:19:40 EDT
Excellent. Mauricio, please go to the account system and apply for the packager group:

  https://admin.fedoraproject.org/accounts/

I'll sponsor you in and then you can import and build your packages.

Paul has agreed to guide you in your work (since I don't do very much with mono packaging) so when you do your cvs request you can put him on the package as well.

Note that once I've sponsored you, you'll be on step #4 here: http://fedoraproject.org/wiki/Package_Review_Process
Comment 47 Mauricio Henriquez 2009-06-15 15:41:09 EDT
(In reply to comment #46)
> Excellent. Mauricio, please go to the account system and apply for the packager
> group:
> 
>   https://admin.fedoraproject.org/accounts/
mmm, kind of lost here, I have a fedora account but I supose to "join a group"?, is that is the case, what is the mono group name?

> 
> I'll sponsor you in and then you can import and build your packages.

great..
> 
> Paul has agreed to guide you in your work (since I don't do very much with mono
> packaging) so when you do your cvs request you can put him on the package as
> well.
> 
more great...

> Note that once I've sponsored you, you'll be on step #4 here:
> http://fedoraproject.org/wiki/Package_Review_Process  
don't know what to do with that :-S ...thanks Toshio...
Comment 48 Paul Lange 2009-06-16 00:11:33 EDT
> > Excellent. Mauricio, please go to the account system and apply for the packager
> > group:
> > 
> >   https://admin.fedoraproject.org/accounts/
> mmm, kind of lost here, I have a fedora account but I supose to "join a
> group"?, is that is the case, what is the mono group name?

The group is called 'packager'
 
> > Note that once I've sponsored you, you'll be on step #4 here:
> > http://fedoraproject.org/wiki/Package_Review_Process  
> don't know what to do with that :-S ...thanks Toshio...  

Look at this to http://fedoraproject.org/wiki/PackageMaintainers/Join#Get_Sponsored

Paul
Comment 49 Mauricio Henriquez 2009-06-17 16:19:43 EDT
(In reply to comment #48)
> > > Excellent. Mauricio, please go to the account system and apply for the packager
> > > group:
> > > 
> > >   https://admin.fedoraproject.org/accounts/
> > mmm, kind of lost here, I have a fedora account but I supose to "join a
> > group"?, is that is the case, what is the mono group name?
> 
> The group is called 'packager'
ok "buhochileno has applied to packager! ", sorry for the late...I'm really bussy right now, so hope that there is not to much step on front!!!
> 
> > > Note that once I've sponsored you, you'll be on step #4 here:
> > > http://fedoraproject.org/wiki/Package_Review_Process  
> > don't know what to do with that :-S ...thanks Toshio...  
> 
> Look at this to
> http://fedoraproject.org/wiki/PackageMaintainers/Join#Get_Sponsored
looking...
> 
> Paul  

Mauricio
Comment 50 Kevin Fenzi 2009-06-22 22:13:04 EDT
Please add a cvs template here so we know what you want: 

https://fedoraproject.org/wiki/CVS_admin_requests

Then reset the cvs flag.
Comment 51 Mauricio Henriquez 2009-06-23 08:59:07 EDT
New Package CVS Request
=======================
Package Name: monodevelop-debugger-mdb
Short Description: MonoDevelop Debugger Addin
Owners: buhochileno 
Branches: devel F-10 F-11 
InitialCC: palango
Comment 52 Jason Tibbitts 2009-06-23 13:53:55 EDT
CVS done.
Comment 53 Benjamin Podszun 2009-07-13 08:00:38 EDT
Curious lurker here: What are the remaining hurdles to get this (and the -gdb package, bug 496635) into RawHide or F11?
Comment 54 Toshio Ernie Kuratomi 2009-07-15 03:15:45 EDT
There shouldn't be any.

buhochileno, have you imported the packages?  Having any problems?
Comment 55 Mauricio Henriquez 2009-07-15 09:07:21 EDT
(In reply to comment #54)
> There shouldn't be any.
> 
> buhochileno, have you imported the packages?  Having any problems?  

I was unable to build the proper final src.rpm due to a bug with the current rpmbuild tools related to a missing "Version" info at one of the .pc.in files included in the upstream sources (currently I'm still in fed10 with no plans to move to fed11 yet..), so Paul finish the building process, at least koji send me the info that the tasks was complete...

http://koji.fedoraproject.org/koji/buildinfo?buildID=112911

also koji system inform me by mail this:

monodevelop-debugger-mdb-2.0-2.fc11 successfully moved from dist-f11-updates-candidate into dist-f11-updates by bodhi

So, don't know if there is another step missed, but honestly I don't have more time for this, it was a really, really long process and I give it to it all the time that I can, so feel free to take over the gdb package to...BTW, as far as I know, there is no much people using the gdb addin, so don't know if is really urgent to have it..

Mauricio

P.S: if I find some time next week and nobody else take over the gdb one I going to see if I can check the spec file to add the necesary modifications..
Comment 56 Paul Lange 2009-10-08 06:12:26 EDT
This is in F11 and devel. Closing this bug.

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