Red Hat Bugzilla – Bug 294641
Review Request: aboot - A bootloader which can be started from the SRM console.
Last modified: 2007-11-30 17:12:16 EST
Spec URL: http://buildsys.zero42.at/mnt/koji/packages/aboot/1.0_pre20040408/1.fc8/src/aboot.spec
SRPM URL: http://buildsys.zero42.at/mnt/koji/packages/aboot/1.0_pre20040408/1.fc8/src/aboot-1.0_pre20040408-1.fc8.src.rpm
The aboot program is the preferred way of booting Linux when using SRM
firmware (the firmware normally used to boot an DEC UNIX). Aboot supports
the creation of bootable block devices and contains a program which can
load Linux kernels from a filesystem which is bootable by SRM. Aboot
also supports direct booting from various filesystems (ext2, ISO9660,
UFS), booting of executable object files (ELF and ECOFF), booting of
compressed kernels, network booting (using bootp), partition tables in
DEC UNIX format, and interactive booting and default configurations for
SRM consoles that cannot pass long option strings.
If you are installing Fedora or Red Hat Linux on an Alpha, you'll need to
install the aboot package.
It's going to be tough for many people to review this since we don't have Alphas
so ExclusiveArch will stop us. I actually have Alphas (Some PW500s and a DS20)
but I'm not up to digging them out of storage at the moment.
Any chance you could provide links to a built package and the build logs? And
maybe some rpmlint output as well?
I've checked rpmlint. Yes, there where some small warnings that where fixed now.
My only problem is:
[oliver@gosa SPECS]$ rpmbuild -bs aboot.spec --nodeps
[oliver@gosa SPECS]$ rpmlint
aboot.src: W: invalid-license GPL
I don't know how to handle this. The source doesn't state the exact version and
SF project page also states GPL. Is there some Wiki for such issues?
I've locally built aboot pkg on my Alpha and then imported; However, after I
have fixed the rpmlint warnings now, I've submitted a new build to alpha koji.
Please stand by, I will make a note within this bug as soon as the build is done.
and jason, if you find some time, get your alphas out, update 'em to latest and
greatest devel tree and put it online for our alpha koji :-P
(In reply to comment #2)
> [oliver@gosa SPECS]$ rpmlint
> aboot.src: W: invalid-license GPL
> I don't know how to handle this. The source doesn't state the exact version and
> SF project page also states GPL. Is there some Wiki for such issues?
License policy is changed and you have to specify the version
for GPL/LGPL. Please refer to:
From my quick check license seems GPLv2+.
Without having read both wikis... How did you find out?
I have changed the spec to GPLv2+.
(In reply to comment #6)
> Without having read both wikis... How did you find out?
The source tarball contains GPLv2 text file and GPL license
Each version is given a distinguishing version number. If the Program
specifies a version number of this License which applies to it and "any
later version", you have the option of following the terms and conditions
either of that version or of any later version published by the Free
Software Foundation. If the Program does not specify a version number of
this License, you may choose any version ever published by the Free Software
From (quick) check of the source codes, some codes says
"GPLv2 and any later", other says nothing. In this case
license is GPLv2+.
Any chance you'd have a link to the build package and build logs I could take a
I actually have one Alhpa machine handy (a Compaq XP1000), but I've never
installed Linux on it and have no idea how to begin, assuming that it's not too
ancient to actually run anything useful.
Buildlogs will be here: http://buildsys.zero42.at/koji/taskinfo?taskID=42104, as
soon as finished....
XP1000 is fine, not the fastest one, but for testing well enough. Installing
Fedora Linux on that machine, I would wait for our new isos that I will
hopefully produce soon... It will include new kernel and new glibc - some
syscall fixes that I currently don't want to ship via yum, as it might break
(many) things - especially if you don't install it the RightWay(tm). :-)
Build is done. You can now have a look at it....
just *bing* :-)
Duh? Why 4Suite!?
Sometimes the component gets changed randomly. I don't know if this is a
firefox bug or a bugzilla bug. It's no big deal; I just change it back when I
have something else to add.
A few complaints:
the manpages are executable, which rpmlint dutifully complains about:
aboot.alpha: W: spurious-executable-perm /usr/share/man/man8/e2writeboot.8.gz
aboot.alpha: W: spurious-executable-perm /usr/share/man/man8/sdisklabel.8.gz
aboot.alpha: W: spurious-executable-perm /usr/share/man/man1/isomarkboot.1.gz
aboot.alpha: W: spurious-executable-perm /usr/share/man/man8/swriteboot.8.gz
aboot.alpha: W: spurious-executable-perm /usr/share/man/man8/abootconf.8.gz
aboot.alpha: W: spurious-executable-perm /usr/share/man/man1/netabootwrap.1.gz
aboot.alpha: W: spurious-executable-perm /usr/share/man/man5/aboot.conf.5.gz
aboot.alpha: W: spurious-executable-perm /usr/share/man/man8/aboot.8.gz
I notice that the normal set of compiler flags aren't used. Now, this is a
bootloader so I can understand why, although there are userspace programs
included which perhaps should be built like any other userspace program. Given
that this is for Alpha, though, I can't even be truly sure what the proper
compilation flags are.
This package does not meet the versioning guidelines; when 1.0 is released, it
will sort lower than the current package name. The guidelines specify the
proper version and release to be used as:
You can increment the '2' for each new revision, and when 1.0 is released you
can just use "1.0-1" without worrying about any sorting issues.
There's a COPYING file in the tarball, which must be included in the package.
* source files match upstream:
X package does not meet versioning guidelines.
* specfile is properly named, is cleanly written and uses macros consistently.
* summary is OK.
* description is OK.
* dist tag is present.
* build root is OK.
* license field matches the actual license.
* license is open source-compatible.
X license text included in tarball but not in package.
* latest version is being packaged.
* BuildRequires are proper.
? compiler flags are appropriate.
* %clean is present.
* package builds in mock (development, alpha).
* debuginfo package looks complete.
X rpmlint has valid complaints.
* final provides and requires are sane.
* %check is not present; no test suite upstream. I have no way to test this
* no shared libraries are added to the regular linker search paths.
* owns the directories it creates.
* doesn't own any directories it shouldn't.
* no duplicates in %files.
X file permissions are not appropriate (executable manpages)
* no scriptlets present.
* code, not content.
* documentation is small, so no -docs subpackage is necessary.
* %docs are not necessary for the proper functioning of the package.
* no headers.
* no pkgconfig files.
* no static libraries.
* no libtool .la files.
I think I have fixed everything now:
[oliver@gosa alpha]$ rpmlint aboot-1.0-0.1.pre20040408.fc8.alpha.rpm
Please note. I've added a patch to include the rpm optflags... I don't know if
the package is *working*. But next time I boot my as1000a i will install updated
aboot and try... I don't think that the optflags will break anything.
OK, cool. rpmlint shuts up, the COPYING file is in there, the manpages aren't
executable, and the version looks good.
Of course you know I can't test this so I'll leave that to you; if the compiler
flag change breaks things then I have no issues with you reverting it.
Thx for the review. It was a pleasure for me.
Well, yes if the compiler flags break something I have to revert it, but I don't
think they will.
New Package CVS Request
Package Name: aboot
Short Description: A bootloader which can be started from the SRM console
Cvsextras Commits: yes