Spec URL: http://ausil.us/packages/silo.spec SRPM URL: http://ausil.us/packages/silo-1.4.13-3.al3.src.rpm Description: The silo package installs the SILO (Sparc Improved LOader) boot loader, which you'll need to boot the Linux kernel on a SPARC. SILO installs onto your system's boot block and can be configured to boot Linux, Solaris and SunOS.
There are a few small problems with the spec - I'd say that /usr/share/man/man1/tilo.1* /usr/share/man/man1/maketilo.1* /usr/share/man/man5/silo.conf.5* /usr/share/man/man8/silo.8* should use %{_mandir} (for instance %{_mandir}/man?/*), /usr/sbin/silocheck should be replaced with %{_sbindir}/silocheck, /usr/bin/stuff with %{_bindir}/stuff ... (Packaging/Guidelines#macros) - According to Packaging/Guidelines#parallelmake SMP flags should be used if possible - mock build fails with No Package Found for elftoaout Cannot find build req elftoaout. Exiting. ending done I assume this comes from testing being done on x86 ?
Teach me for submitting a package before i go to bed. elftoaout needs adding also i submitted a review for it. Fixed the issues and built in mock. If you want to build on sparc i can give you access to a machine. SPEC: http://ausil.us/packages/silo.spec SRPM: http://ausil.us/packages/silo-1.4.13-4.fc8.src.rpm
SRPM: http://ausil.us/packages/silo-1.4.13-5.fc8.src.rpm SPEC: http://ausil.us/packages/silo.spec use smp flags for building.
OK - Spec in American English OK - Spec is legible. OK - Spec provides updated License tag OK - Sources match upstream md5sum: 7039aabf3c1b3858ae8d0ccdde21343e silo-1.4.13.tar.bz2 7039aabf3c1b3858ae8d0ccdde21343e silo-1.4.13.tar.bz2.1 OK - BuildRequires correct See below (#1) - Package has %defattr and permissions on files is good. OK - Package has a correct %clean section. OK - Package has correct buildroot OK - Package is code or permissible content. OK - Packages %doc files don't affect runtime. OK - Package compiles and builds on at least one arch. OK - Package has no duplicate files in %files. OK - Package doesn't own any directories other packages own. OK - Package owns all the directories it creates. See below (#2) - No rpmlint output. OK - final provides and requires are sane: Provides: silo = 1.4.13-5.fc8 Requires: /bin/sh /bin/sh libc.so.6 libc.so.6(GLIBC_2.0) libc.so.6(GLIBC_2.1) libc.so.6(GLIBC_2.1.3) libc.so.6(GLIBC_2.3) libc.so.6(GLIBC_2.4) rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1 rtld(GNU_HASH) SHOULD Items: OK - Should build in mock. See below (#3) - Should build on all supported archs OK - Should function as described. OK - Should have dist tag OK - Should package latest version 0 bugs - check for outstanding bugs on package. Notes: #1: %defattr(-,root,root) -> %defattr(-,root,root,-) #2: $ rpmlint silo-1.4.13-5.fc8.sparc.rpm silo.sparc: E: statically-linked-binary /boot/ieee32.b Is this a blocker? Considering it appears to be a first-stage bootloader, I'm quite hesitant to say so. #3: Ha, ha, ha. I think we can safely ignore this for an arch-specific bootloader. Fix #1, and provide some feedback on #2 and #3 (Spot? Peter?), and I think we're good. Also, this bug depends on BZ#253043, which is (I believe) approved and built. Care to close that? :-)
SRPM: http://ausil.us/packages/silo-1.4.13-6.fc8.src.rpm SPEC: http://ausil.us/packages/silo.spec #2 i dont think is a problem. it will get called very early in the boot process #3 it builds on sparc :) which is all supported archs there is no need to build silo as a sparc64 binary.
#1: clearly addressed. #2: shouldn't be an issue. #3: do we need to file ExclusiveArch bugs? Whatever, not exactly a blocker. I'm going to deem silo APPROVED.
New Package CVS Request ======================= Package Name: silo Short Description: The SILO boot loader for SPARCs Owners: ausil spot pjones Branches: devel InitialCC: jima Cvsextras Commits: yes
cvs done
Finally getting around to addressing #3 (since you and I keep forgetting to file ExclusiveArch bugs): I looked at aboot, grub, and yaboot, and found none of them have bugs filed. I ran it by my sponsor (and the author of http://fedoraproject.org/wiki/Architectures), Spot, and he agreed that there was no point in filing EA bugs. I think we can consider our bases covered.