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.
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.
(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...
*** Bug 490030 has been marked as a duplicate of this bug. ***
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.
(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?
Created attachment 342186 [details] Fixes RELEASE build configuration and libdir on x86_64 I'll pass these changes on to upstream.
Created attachment 342187 [details] Fixes build on x86_64
Created attachment 342189 [details] Fixes RELEASE build configuration and libdir on x86_64 Removed make.config and make.log from the patch.
(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
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.
(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.
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?
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.
(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
What is the final status of this packages?, is going to be included in fed11?, as an update in the repos?
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.
(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
What's the state of this? Anyone working on review?
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).
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
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
Created attachment 346464 [details] spec file updated spec file updated
Created attachment 346465 [details] src.rpm package updated
(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
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
Created attachment 346550 [details] release number and devel subpackage added
Created attachment 346551 [details] src rpm created acording the las spec file changes
Created attachment 346553 [details] wrong devel description, fixed
Created attachment 346554 [details] src rpm acording to last spec file
(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
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 :)
Created attachment 346692 [details] new spec file
Created attachment 346693 [details] new src rpm
(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
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> - 2.0-1 --- > * Thu Jun 04 2009 Mauricio Henriquez <buhochileno> - 2.0-3 70c70 < * Sun May 03 2009 Ryan Bair <ryan> - 2.0-1 --- > * Sun May 03 2009 Ryan Bair <ryan> - 2.0-2 73c73 < * Thu Apr 30 2009 Mauricio Henriquez <buhochileno> - 2.0 --- > * Thu Apr 30 2009 Mauricio Henriquez <buhochileno> - 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. :)
(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> - 2.0-1 > --- > > * Thu Jun 04 2009 Mauricio Henriquez <buhochileno> - 2.0-3 > 70c70 > < * Sun May 03 2009 Ryan Bair <ryan> - 2.0-1 > --- > > * Sun May 03 2009 Ryan Bair <ryan> - 2.0-2 > 73c73 > < * Thu Apr 30 2009 Mauricio Henriquez <buhochileno> - 2.0 > --- > > * Thu Apr 30 2009 Mauricio Henriquez <buhochileno> - 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> - 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. :)
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> - 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
Created attachment 346933 [details] changes..
(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> - 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
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.
Created attachment 346937 [details] x86_64 removed
(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.
- 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
(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..
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.
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
(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...
> > 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
(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
Please add a cvs template here so we know what you want: https://fedoraproject.org/wiki/CVS_admin_requests Then reset the cvs flag.
New Package CVS Request ======================= Package Name: monodevelop-debugger-mdb Short Description: MonoDevelop Debugger Addin Owners: buhochileno Branches: devel F-10 F-11 InitialCC: palango
CVS done.
Curious lurker here: What are the remaining hurdles to get this (and the -gdb package, bug 496635) into RawHide or F11?
There shouldn't be any. buhochileno, have you imported the packages? Having any problems?
(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..
This is in F11 and devel. Closing this bug.