Spec URL: <http://www.polybus.com/sys_basher_web/> SRPM URL: <http://www.polybus.com/sys_basher/sys_basher-1.1.17-1.fc11.src.rpm> Description: <sys_basher is a multi-threaded harware exerciser. It tests CPUs, RAM and Disk I/O under the most stressful conditions>
The spec url is incorrect. Is this your first package? I could not find you in the Fedora Account system.
Blocking FE-NEEDSPONSOR. To get this package in Fedora you will need to get a sponsor. I can sponsor you if you show me that you know the Fedora guidelines, most importantly http://fedoraproject.org/wiki/Packaging/Guidelines http://fedoraproject.org/wiki/Packaging/ReviewGuidelines http://fedoraproject.org/wiki/Packaging/ScriptletSnippets To do this you need to perform a couple of informal package reviews of packages of other people. You should also make another submission. ** A few notes: - The tabbing of the spec file does not look sane. Please fix it. - License tag is incorrect, should be BSD with advertising. http://fedoraproject.org/wiki/Licensing#Software_License_List - Package does not build in mock; you are missing at least BuildRequires: ncurses-devel. - Explicit Requires: are not allowed, so drop the Requires line altogether. http://fedoraproject.org/wiki/Packaging/Guidelines - You shouldn't need to mkdir -p $RPM_BUILD_ROOT mkdir -p $RPM_BUILD_ROOT%{_sbindir} as this should be done by make install.
This is my first package. I generated the .spec file using rpmdev-newspec and then edited it with Xemacs, the tabs look fine to me. rpmbuild doesn't seem to work without the mkdirs, is it expecting them in Makefile? My license is the original BSD. I have advertising on my sys_basher website for my products and services but there is none in the program or in the source package. The program requires lm_sensors, is rpmbuild smart enough to figure that out from the source code? I'm the author of sys_basher, I wrote it to test hardware reliability and performance. As far as I know it's the only Linux native hardware diagnostic available. The unique feature of sys_basher is that it's multi-threaded which allows it to run CPU, Memory and IO tests on all of the cores in a system simultaneously. I've written it to operate all of the subsystems at their maximum possible speeds which ensures that the greatest amount of heat is generated, the maximum power is used, and the maximum switching noise created. Sys_basher can find RAM errors that memtest86 can't. I've been designing computers for 30 years, currently I sell high-speed commnication IP for ASICs and FPGAs. In the early 90s I had a commercial hardware diagnostic for the Mac which was sold as both as an end user utility and was used by Mac board manufacturers, I sold that product off in the mid-90s. I'm attaching my current spec file.
Created attachment 356883 [details] spc file
Created attachment 356884 [details] source code
You don't need to attach the spec or the source tar ball, you just need to give the new links to the spec and srpm. For example, next time you update the spec file due to some comments (remember to increase the release tag every time you update!), you could give them as e.g. http://www.polybus.com/sys_basher/sys_basher.spec http://www.polybus.com/sys_basher/sys_basher-1.1.17-2.fc11.src.rpm Of course, you would need to make them available at those addresses, first.
(In reply to comment #3) > This is my first package. > > I generated the .spec file using rpmdev-newspec and then edited it with Xemacs, > the tabs look fine to me. When I look at the spec in xemacs I see that Group:, URL: and License: are not aligned with the rest of the lines. As far as I can tell this is not a tab width issue since those are spaces, not tabs, in the spec file. Anyway, this is just an esthetical issue. > rpmbuild doesn't seem to work without the mkdirs, is it expecting them in > Makefile? Yes, normally makefiles have them. As you are upstream, you should add them to the sys_basher release. > My license is the original BSD. I have advertising on my sys_basher website for > my products and services but there is none in the program or in the source > package. Yes, original BSD, i.e. 4 clause BSD is marked in Fedora as "BSD with Advertising" as you could have seen from the link in comment #2. It is *NOT* compatible with GPL. As lm_sensors is under GPLv2+, including this package in Fedora at the moment would break licensing. Blocking FE-LEGAL. > The program requires lm_sensors, is rpmbuild smart enough to figure that out > from the source code? Yes, rpm checks out everything that has been compiled dynamically and requires the relevant libraries.
I'll switch the license to New BSD so that it will be compatible with the GPL. I'll fix the Makefile and clean up the spec file. I'll let you know when I've updated my website.
You can also remove the executable perms from the source files from the tarball. And your headers are lacking the license headers.
Created attachment 356921 [details] source files with New BSD license
Created attachment 356924 [details] updated spec file
I've changed the license from the original BSD to the new BSD. I've also fixed the Makefile and the spec file. My website has been updated to reflect these changes. Please look it over.
(In reply to comment #12) > I've changed the license from the original BSD to the new BSD. I've also fixed > the Makefile and the spec file. My website has been updated to reflect these > changes. Please look it over. As I advised in comment #6, please don't attach the specs or tarballs, just paste the relevant links to the spec & srpm. In this case: http://www.polybus.com/sys_basher/sys_basher.spec http://www.polybus.com/sys_basher/sys_basher-1.1.17-3.fc11.src.rpm would have done nicely. ** Now the license tag is again incorrect, it should be just "BSD" instead of "BSD no advertising". Please see http://fedoraproject.org/wiki/Licensing#Software_License_List ** You are still missing BuildRequires, making the package not build under mock. + make -j4 gcc -c -O2 -Wuninitialized -Wformat -Wno-multichar -Wreturn-type -Wswitch -g sys_main.c gcc -c -O2 -Wuninitialized -Wformat -Wno-multichar -Wreturn-type -Wswitch -g sys_utils.c gcc -c -O2 -Wuninitialized -Wformat -Wno-multichar -Wreturn-type -Wswitch -g sys_disk.c gcc -c -O2 -Wuninitialized -Wformat -Wno-multichar -Wreturn-type -Wswitch -g sys_kernel.c In file included from sys_disk.c:28: In file included from sys_utils.c:28: sys_basher.h:37:21: error: ncurses.h: No such file or directory sys_basher.h:37:21: error: ncurses.h: No such file or directory In file included from sys_main.c:28: sys_basher.h:37:21: error: ncurses.h: No such file or directory You might want to add a clause for ncurses.h, too. Or maybe switch to using e.g. GNU autotools to configure the build process. ** As one can see, the build process does not use the Fedora optimization flags. Use make %{?_smp_mflags} CFLAGS="$RPM_OPT_FLAGS" to fix this. ** On a side note, I'm wondering why you have many variables for the same thing in the Makefile. You should have only the standard variables CC and CFLAGS, and call them in the make process. I'll attach a patch in a moment. ** You are missing changelog entries altogether. Add entries for every change and release you've done so far. ** All of the tarball files (except the spec file) are still executable. Please remove the executable flags from the files in the upstream tarball.
License is now BSD which is GPL compatible, dropping FE-LEGAL.
Created attachment 356931 [details] Patch to clean up upstream make file This patch cleans up the upstream makefile by - letting there be only one compiler variable - using CFLAGS everywhere - dropping mechanical compile commands that can be handled with a general algorithm - making clean clean everything (and not care if no objects exist) - adding a handler if ncurses.h does not exist Please apply this to the upstream makefile. Also run $ chmod 644 * before making the new tarball.
Thanks for the patch to my Makefile, I'll apply it. I'm also removing ncurses from the make file. I was playing with ncurses last year but I decided that it didn't add anything so I dropped it. I'll put up a new release shortly.
I've uploaded a new release to my website. Please check it out.
As instructed in comment #6 and comment #13, please paste new SPEC & SRPM urls in the review whenever you have updated something. ** The package *STILL DOES NOT COMPILE* In file included from sys_main.c:28: sys_basher.h:37:21: error: ncurses.h: No such file or directory In file included from sys_basher.h:49, from sys_main.c:28: sys_curses.h:29: error: expected '=', ',', ';', 'asm' or '__attribute__' before '*' token sys_curses.h:30: error: expected ')' before '*' token sys_curses.h:31: error: expected ')' before '*' token In file included from sys_disk.c:28: sys_basher.h:37:21: error: ncurses.h: No such file or directory In file included from sys_utils.c:28: sys_basher.h:37:21: error: ncurses.h: No such file or directory In file included from sys_basher.h:49, from sys_disk.c:28: sys_curses.h:29: error: expected '=', ',', ';', 'asm' or '__attribute__' before '*' token sys_curses.h:30: error: expected ')' before '*' token sys_curses.h:31: error: expected ')' before '*' tokenIn file included from sys_basher.h:49, from sys_utils.c:28: sys_curses.h:29: error: expected '=', ',', ';', 'asm' or '__attribute__' before '*' token sys_curses.h:30: error: expected ')' before '*' token sys_curses.h:31: error: expected ')' before '*' token make: *** [sys_main.o] Error 1 make: *** Waiting for unfinished jobs.... In file included from sys_kernel.c:28: sys_basher.h:37:21: error: ncurses.h: No such file or directory make: *** [sys_disk.o] Error 1 In file included from sys_basher.h:49, from sys_kernel.c:28: sys_curses.h:29: error: expected '=', ',', ';', 'asm' or '__attribute__' before '*' token sys_curses.h:30: error: expected ')' before '*' token sys_curses.h:31: error: expected ')' before '*' token make: *** [sys_kernel.o] Error 1 make: *** [sys_utils.o] Error 1 If you need ncurses, add BuildRequires: ncurses-devel as instructed in comment #2. ** Makefile, COPYRIGHT and README in the upstream tarball *STILL* have executable flags. Remove them from the upstream release, or remove them in the %prep phase. ** You are missing the -2 release from the changelog.
(In reply to comment #18) > Makefile, COPYRIGHT and README in the upstream tarball *STILL* have executable > flags. Remove them from the upstream release, or remove them in the %prep > phase. "chmod -x"ing then in %prep is what you want.
(In reply to comment #19) > (In reply to comment #18) > > > Makefile, COPYRIGHT and README in the upstream tarball *STILL* have executable > > flags. Remove them from the upstream release, or remove them in the %prep > > phase. > "chmod -x"ing then in %prep is what you want. .. but if one is upstream it is better to do it there since Fedora is not the only distribution suffering from incorrect permissions. ** Your %doc line is empty, add README and COPYRIGHT to %doc.
(In reply to comment #20) > (In reply to comment #19) > > (In reply to comment #18) > > > > > Makefile, COPYRIGHT and README in the upstream tarball *STILL* have executable > > > flags. Remove them from the upstream release, or remove them in the %prep > > > phase. > > "chmod -x"ing then in %prep is what you want. > > .. but if one is upstream it is better to do it there since Fedora is not the > only distribution suffering from incorrect permissions. Upstream is irrelevant at this point. We are talking about Fedora packaging conventions, not about upstream.
http://www.polybus.com/sys_basher/sys_basher-1.1.17-5.fc11.x86_64.rpm http://www.polybus.com/sys_basher/sys_basher-1.1.17-5.fc11.src.rpm http://www.polybus.com/sys_basher/sys_basher.spec I've removed the ncurses.h includes from all of the files. I've also put a chmod into my release script that should fix the flags.
- Your changelog is not ordered in time. Fix it. ** + make -j4 gcc -O2 -Wuninitialized -Wformat -Wno-multichar -Wreturn-type -Wswitch -g -c sys_main.c gcc -O2 -Wuninitialized -Wformat -Wno-multichar -Wreturn-type -Wswitch -g -c sys_utils.c gcc -O2 -Wuninitialized -Wformat -Wno-multichar -Wreturn-type -Wswitch -g -c sys_disk.c gcc -O2 -Wuninitialized -Wformat -Wno-multichar -Wreturn-type -Wswitch -g -c sys_kernel.c gcc -O2 -Wuninitialized -Wformat -Wno-multichar -Wreturn-type -Wswitch -g -c sys_fp.c gcc -O2 -Wuninitialized -Wformat -Wno-multichar -Wreturn-type -Wswitch -g -c sys_int.c gcc -O2 -Wuninitialized -Wformat -Wno-multichar -Wreturn-type -Wswitch -g -c sys_mem.c gcc -O2 -Wuninitialized -Wformat -Wno-multichar -Wreturn-type -Wswitch -g -c lin_utils.c ./build_sensors.csh make[1]: Entering directory `/builddir/build/BUILD/sys_basher-1.1.17' make[1]: warning: jobserver unavailable: using -j1. Add `+' to parent make rule. gcc -O2 -Wuninitialized -Wformat -Wno-multichar -Wreturn-type -Wswitch -g -c sys_sensors3.c make[1]: Leaving directory `/builddir/build/BUILD/sys_basher-1.1.17' gcc -O2 -Wuninitialized -Wformat -Wno-multichar -Wreturn-type -Wswitch -g -lm -pthread -lsensors -lform -o sys_basher sys_main.o sys_utils.o sys_disk.o sys_kernel.o sys_fp.o sys_int.o sys_mem.o lin_utils.o sys_sensors_x.o /usr/bin/ld: cannot find -lform You don't need libform anymore if you've dropped ncurses support. ** Your %doc line is empty, add README and COPYRIGHT to %doc. ** The build process does not use the Fedora optimization flags. Use make %{?_smp_mflags} CFLAGS="$RPM_OPT_FLAGS" instead of make %{?_smp_mflags} to fix this. ** Doesn't this program work as a normal user? Change all occurrences of %{_sbindir} to %{_bindir}.
http://www.polybus.com/sys_basher/sys_basher.spec http://www.polybus.com/sys_basher/sys_basher-1.1.17-6.fc11.src.rpm http://www.polybus.com/sys_basher/sys_basher-1.1.17-6.fc11.x86_64.rpm I've change sbinder to binder, the make statement, removed lform and added the docs.
Good, now the package builds in mock. There are still a few issues to fix: rpmlint reports: sys_basher.src: E: description-line-too-long low level functions including memory bandwidth (at all levels of the hierarchy), sys_basher.src: E: description-line-too-long disk IO bandwidth and integer and floating point operations using unrolled loops. sys_basher.src: W: strange-permission sys_basher.spec 0770 sys_basher.x86_64: E: description-line-too-long low level functions including memory bandwidth (at all levels of the hierarchy), sys_basher.x86_64: E: description-line-too-long disk IO bandwidth and integer and floating point operations using unrolled loops. sys_basher.x86_64: E: non-standard-executable-perm /usr/bin/sys_basher 0775 3 packages and 0 specfiles checked; 5 errors, 1 warnings. To fix these you need to break the description to less than 80 character lines, e.g. sys_basher is a multithreaded system exerciser. It tests the CPU, RAM and Disks under conditions of maximum stress by running CPU, Memory and Disk tests on all Cores simultaneously. In addition to reliablity testing, sys_basher benchmarks low level functions including memory bandwidth (at all levels of the hierarchy), disk IO bandwidth and integer and floating point operations using unrolled loops. ** Change the spec file permission to 0644 (the one you build the srpm from). ** To fix the executable perm issue you can either run chmod 755 $RPM_BUILD_ROOT%{_bindir}/sys_basher or modify the upstream makefile which should use install instead of 'mv': Add the definition INSTALL="install -p" to the top of the makefile and change the install target to install: sys_basher ${INSTALL} -D -m 755 sys_basher ${DESTDIR}/sys_basher This command will automatically create ${DESTDIR} if it does not exist, and copy the executable with 755 permissions. ** After these changes the package should be in order. Then you need to perform the informal reviews to show me that you know the Fedora guidelines as per comment #2.
Removing FE-NEEDSPONSOR.
I'm not getting any rpmlint errors, however I'll shorten those lines anyway. Is install a script of yours? There is no such command as install on my system and I don't see it in yumex. I've created a man page, where do I specify?
(In reply to comment #27) > I'm not getting any rpmlint errors, however I'll shorten those lines anyway. As you can see, I get them from the SRPM, not the spec file. > Is install a script of yours? There is no such command as install on my system > and I don't see it in yumex. install is a standard *nix utility: $ rpm -qf /usr/bin/install coreutils-7.2-2.fc11.x86_64 > I've created a man page, where do I specify? In the upstream makefile you should have ------ BINDIR=/usr/local/bin MANDIR=/usr/local/share/man/ INSTALL="install -p" install: $(INSTALL) -D -m 644 sys_basher.1 $(DESTDIR)$(MANDIR)/man1/sys_basher.1 $(INSTALL) -D -m 755 sys_basher $(DESTDIR)$(BINDIR)/sys_basher ------ In the spec file you run make install DESTDIR=$RPM_BUILD_ROOT BINDIR=%{_bindir} MANDIR=%{_mandir} and just add %{_mandir}/man1/sys_basher.1.* in %files.
http://www.polybus.com/sys_basher/sys_basher-1.1.18-1.fc11.src.rpm http://www.polybus.com/sys_basher/sys_basher-1.1.18-1.fc11.x86_64.rpm http://www.polybus.com/sys_basher/sys_basher.spec I've added the man file and updated the -h section of the program so that it produces output that works well with help2man.
Doesn't compile: help2man -N sys_basher -o sys_basher.1 help2man: can't get `--help' info from sys_basher The command should be help2man -N ./sys_basher -o sys_basher.1
I keep forgetting that the default path setup doesn't search the local directory first, my .cshrc file fixes that. I'll add the ./ to the help2man. rpmlint is giving me an error on the current version of the spec file. Line 40 is %{_mandir}/man1/sys_basher.1.*. What do I need to fix? rpmlint -v sys_basher.spec sys_basher.spec:40: E: files-attr-not-set 0 packages and 1 specfiles checked; 1 errors, 0 warnings. Thanks for all your help
Oh, I was going to comment about that. The reason why you get the error is because you have the entry in the wrong place: before the %defattr line, so there are no attributes (mode & owner) set. Move the man page line to the end of %files.
Thanks, that fixed it. I'm going to check that sys_basher will still build on CentOS and on Ubuntu. Assuming everything is OK there I'll make the next point release. If you approve it I'll make RPMs for 32 bit Fedora 11 and for 32 and 64 bit F10 as well.
(In reply to comment #33) > Thanks, that fixed it. I'm going to check that sys_basher will still build on > CentOS and on Ubuntu. Assuming everything is OK there I'll make the next point > release. If you approve it I'll make RPMs for 32 bit Fedora 11 and for 32 and > 64 bit F10 as well. OK, you might want to clean up the unused variables at the same time. You don't have to paste links to binary RPMs here. Once you have done the informal reviews, I have sponsored you and approved this package you will be able to import it in the Fedora build system and build it on Fedora 10, 11 and RHEL 4 and 5.
Thanks. I'll take your suggestion and clean up the warnings.
I think I'm ready. What's the procedure for submitting the package to the Fedora build system? http://www.polybus.com/sys_basher/sys_basher-1.1.19-1.fc11.src.rpm http://www.polybus.com/sys_basher/sys_basher.spec http://www.polybus.com/sys_basher/sys_basher-1.1.19-1.fc11.x86_64.rpm
It's described in http://fedoraproject.org/wiki/PackageMaintainers/Join but first you need to get sponsored in the packager group, which means you have to do a couple of informal package reviews for me. Please review only bugs not marked with FE-NEEDSPONSOR.
And here's the review of this package: rpmlint output: sys_basher.src: W: strange-permission sys_basher.spec 0770 sys_basher.x86_64: W: incoherent-version-in-changelog 1.1.9-1 ['1.1.19-1.fc11', '1.1.19-1'] 3 packages and 0 specfiles checked; 0 errors, 2 warnings. Still, the spec file you used to generate the srpm has strange permissions. Run chmod 644 on it and regenerate the srpm. Fix the version in the changelog as well. MUST: The package does not yet exist in Fedora. The Review Request is not a duplicate. OK MUST: The spec file for the package is legible and macros are used consistently. OK MUST: The package must be named according to the Package Naming Guidelines. OK MUST: The spec file name must match the base package %{name}. 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: The sources used to build the package must match the upstream source, as provided in the spec URL. NEEDSWORK - You need to fix the source URL: $ spectool -g sys_basher.spec --2009-08-12 20:20:24-- http://www.polybus.com/sys_basher/sys_basher-1.1.19.tar.gz Resolving www.polybus.com... 38.113.1.181 Connecting to www.polybus.com|38.113.1.181|:80... connected. HTTP request sent, awaiting response... 404 Not Found 2009-08-12 20:20:25 ERROR 404: Not Found. MUST: The package MUST successfully compile and build into binary rpms. OK MUST: The spec file MUST handle locales properly. N/A MUST: Optflags are used and time stamps preserved. OK - During compilation I get sys_disk.c: In function 'fileWrite': sys_disk.c:150: warning: implicit declaration of function 'open' you might want to fix this. MUST: Packages containing shared library files must call ldconfig. N/A MUST: A package must own all directories that it creates or require the package that owns the directory. OK MUST: Files only listed once in %files listings. OK MUST: Debuginfo package is complete. OK MUST: Permissions on files must be set properly. OK MUST: Clean section exists. OK MUST: Large documentation files must go in a -doc subpackage. N/A MUST: All relevant items are included in %doc. Items in %doc do not affect runtime of application. OK MUST: Header files must be in a -devel package. N/A MUST: Static libraries must be in a -static package. N/A MUST: Packages containing pkgconfig(.pc) files must 'Requires: pkgconfig'. N/A MUST: If a package contains library files with a suffix then library files ending in .so must go in a -devel package. N/A MUST: In the vast majority of cases, devel packages must require the base package using a fully versioned dependency. N/A MUST: Packages does not contain any .la libtool archives. N/A MUST: Desktop files are installed properly. N/A MUST: No file conflicts with other packages and no general names. OK MUST: Buildroot cleaned before install. OK SHOULD: %{?dist} tag is used in release. OK SHOULD: If the package does not include license text(s) as separate files from upstream, the packager should query upstream to include it. OK SHOULD: The package builds in mock. OK
There are two forms of the open command and I'm using both which is why I wasn't using a prototype on it. I've just changed the second instance to pass a 0 arg for the don't care term. I'm going to have to run the sys_basher disk tests to make sure that this doesn't effect anything. If it works I'll create a 1.20 release which will resolve the warning. I've taken care of the other issues.
http://www.polybus.com/sys_basher/sys_basher-1.1.20-1.fc11.src.rpm http://www.polybus.com/sys_basher/sys_basher-1.1.20-1.fc11.x86_64.rpm I think this should do it. I've installed the koji tools, signed up for an account, uploaded my public key, and installed the cert.
New Package CVS Request ======================= Package Name: sys_basher Short Description: Hardware reliability and performance tester Owners: bjrosen Branches: F-10 F-11 EL-5 InitialCC:
You can't request CVS branches yet, since a) you have not been sponsored yet b) this package has not been approved yet. To get over a) you need to do the couple of informal reviews for me first. When I have checked them out, I will sponsor you and approve this package if I am happy with it (I haven't looked at the new spec yet). Perform the informal reviews first.
Hoefully I've gotten the spec right this time. Let me know what you want me to look at.
OK: rpmlint output is clean NEEDSWORK: source does not match upstream: $ md5sum sys_basher-1.1.20.tar.gz ../SOURCES/sys_basher-1.1.20.tar.gz 729bdb57a9477b9d3c0fdef6bfc31ba9 sys_basher-1.1.20.tar.gz 18b02243dde1bef9560016a947647728 ../SOURCES/sys_basher-1.1.20.tar.gz ** Regenerate the SRPM using the correct tarball, or put the correct tarball on the web site. Do the informal reviews ASAP, give links to them here.
Ugh, and the BuildRoot tag is wrong. Use %(mktemp -ud %{_tmppath}/%{name}-%{version}-%{release}-XXXXXX)
http://www.polybus.com/sys_basher/sys_basher.spec http://www.polybus.com/sys_basher/sys_basher-1.1.21-1.fc11.src.rpm http://www.polybus.com/sys_basher/sys_basher-1.1.21-1.fc11.x86_64.rpm I've created a script that runs rpmlint, md5sums and spectool so I shouldn't have anymore problems with that.
OK, I think this package is good to go now. But I won't approve it formally yet, you have to do the informal reviews first so I can sponsor you.
OK let me know what you want me to review. Also I have a CentOS question. In installed the rpmdevtools on CentOS5.3 and built the package. The distro name was not included in the rpm name, sys_basher-1.1.21-1.i386.rpm Is there something different that I need to do on CentOS to get it to build the packages with the distro name included?
(In reply to comment #48) > OK let me know what you want me to review. https://fedoraproject.org/wiki/PackageReviewProcess Have your pick from the review list at https://fedoraproject.org/wiki/PackageMaintainers/ReviewRequests -> unassigned review requests but please review only bugs not tagged with FE-NEEDSPONSOR. > Also I have a CentOS question. In installed the rpmdevtools on CentOS5.3 and > built the package. The distro name was not included in the rpm name, > > sys_basher-1.1.21-1.i386.rpm > > Is there something different that I need to do on CentOS to get it to build the > packages with the distro name included? Actually I'm not sure which package ships the %{dist} macro, I tried to search for it today. But if you build the package in mock for EPEL it will get the correct value. (And the Fedora build system uses mock.)
I have a review question. I've downloaded the files for 481030, pmd-emacs and fetched the source file using spectool -g. Are all the sources including patches required to be in that file or is reviewer supposed to install the SRPM? Does the source archive format matter? This package was supplies as a .zip instead of a .tar.gz or a .tar.bz2. Zip is not a standard way to archive files on a *nix system although it's fully supported. Also should I be posting my review comments on that bug report given that I'm doing this as a learning experience?
Patches will be in the src.rpm; if all you have is the spec, you will generally not have what you need to build the package although in many situations it's enough. We generally have to consume what upstream provides when it comes to archive format. When given a choice, we prefer whatever is smaller. If upstream provides a .zip, we use a .zip. (And this is by far not uncommon, and certainly nothing against the package.)
One more question. Is there a way to unpack an SRPM into a local directory rather than installing it or should I just do this inside of a VM?
(In reply to comment #52) > One more question. Is there a way to unpack an SRPM into a local directory > rather than installing it or should I just do this inside of a VM? I do all my reviews in mock. It uses a chroot to build the packages, so your build directory is clean. Another option is to have a second user on your system with which you build the packages (better this way, so you don't end up blowing all your files away when building a crappily written spec file). Just run $ rpmdev-setuptree and build the SRPM with $ rpmbuild --rebuild package.src.rpm Or you can build using your normal user name, this way your SPEC, SOURCES and RPMS directories just get messier with every package you review...
Where do we stand on releasing sys_basher?
You've done informal reviews on bug #481030 and bug #483863. You probably hadn't noticed the existence of separate Emacs guidelines, which explains why you didn't pick out the bugs in the former. I've added you to the Packager group and sponsored you. This package has been APPROVED Continue with requesting the CVS branch by copying the contents of comment #41 here so it's easier to be found by the CVS admins and set the fedora_cvs tag to ?.
I don't seem to be able to set the fedora_cvs flag. Should I just wait a couple of hours or do I have to notify someone that I need the right to make a CVS request?
Just wait, it should come up automatically.
CVS done.
I need a little help building the EL5 version. I was able to build the Fedora packages without any problems. My guess is that the problem occurred because I built the SRPM on a CentOS5.3 system, as a result the packages did not include the distro in the label. I tried to do a mock rebuild but I clearly don't know what I'm doing with mock. Here is what I tried, mock -r epel-5-x86_64 --rebuild sys_basher-1.1.23-1.fc11.src.rpm INFO: mock.py version 0.9.16 starting... State Changed: init plugins State Changed: start INFO: Start(sys_basher-1.1.23-1.fc11.src.rpm) Config(epel-5-x86_64) State Changed: lock buildroot State Changed: clean State Changed: init State Changed: lock buildroot Mock Version: 0.9.16 INFO: Mock Version: 0.9.16 INFO: enabled root cache INFO: enabled yum cache State Changed: cleaning yum metadata INFO: enabled ccache State Changed: running yum ERROR: Exception(sys_basher-1.1.23-1.fc11.src.rpm) Config(epel-5-x86_64) 0 minutes 7 seconds INFO: Results and/or logs in: /var/lib/mock/epel-5-x86_64/result ERROR: Command failed: # /usr/bin/yum --installroot /var/lib/mock/epel-5-x86_64/root/ install buildsys-build Not using downloaded repomd.xml because it is older than what we have: Current : Thu Aug 20 10:48:52 2009 Downloaded: Wed Jun 24 19:08:12 2009 ******************************************************************************* koji e-mail Package: sys_basher-1.1.23-1.el5 Tag: dist-5E-epel-testing-candidate Status: failed Built by: bjrosen ID: 128117 Started: Thu, 20 Aug 2009 19:03:44 UTC Finished: Thu, 20 Aug 2009 19:06:02 UTC sys_basher-1.1.23-1.el5 (128117) failed on ppc5.fedora.phx.redhat.com (noarch), ppc7.fedora.phx.redhat.com (ppc): BuildError: error building package (arch ppc), mock exited with status 10; see root.log for more information SRPMS: sys_basher-1.1.23-1.el5.src.rpm Failed tasks: ------------- Task 1618329 on ppc5.fedora.phx.redhat.com Task Type: build (dist-5E-epel-testing-candidate, /cvs/pkgs:rpms/sys_basher/EL-5:sys_basher-1_1_23-1_el5) Task 1618333 on ppc7.fedora.phx.redhat.com Task Type: buildArch (sys_basher-1.1.23-1.el5.src.rpm, ppc) logs: http://koji.fedoraproject.org/koji/getfile?taskID=1618333&name=build.log http://koji.fedoraproject.org/koji/getfile?taskID=1618333&name=root.log http://koji.fedoraproject.org/koji/getfile?taskID=1618333&name=state.log
As you can see from the koji root.log, the error is DEBUG util.py:256: No Package Found for lm_sensors-devel This is probably a package that is only in Client RHEL (and on ppc only Server is available), so you need to put in a %if 0%{?rhel} > 0 ExclusiveArch: %{ix86} x86_64 %endif (or instead of ExclusiveArch put ExcludeArch: ppc). ** To build the srpm in mock for EPEL the srpm must have MD5 checksums instead of SHA1 that Fedora 11 uses. Add %_source_filedigest_algorithm 0 %_binary_filedigest_algorithm 0 to ~/.rpmmacros of the user you build the srpms as. (Or, you can probably also disable the checking of the checksums but I don't remember out of the blue how to do that.)
I added ExcludeArch: ppc, that fixed it. I don't have access to any IBM servers so there is no way for me to test sys_basher on that architecture.
I pushed the F10, F11 and EL5 packages to testing but the F12 package gave me the following error, sys_basher-1.1.23-2.fc12 not tagged as an update candidate
You don't need to issue update requests for rawhide; as long as we are not in a freeze, it will appear with the next compose.
What's the criteria for moving from testing to stable? I figured I'd make an announcement about the testing package in comp.os.linux.hardware and on the Fedora forums, wait a couple of weeks to see if I get any feedback, and then push it to stable.
In Fedora, there is no criteria, it's up to the maintainer, although it is recommended to keep the package in testing for a couple of weeks to see if it picks up any karma from testers. In EPEL it *must* spend the two weeks in testing (or pick up enough karma), unless it is a security update or a critical bug fix.
Seems like you forgot to mark this bug as solved by the first release of the package. Closing now.