Request for exception: seabios-bin on ppc64
by Richard W.M. Jones
[Bug: https://bugzilla.redhat.com/show_bug.cgi?id=866664]
Here's the situation, since the bug doesn't explain it well.
(1) qemu can run any architecture on any other architecture, using
software emulation. eg. It can run x86_64 guest operating systems on
top of ppc64 hosts (albeit not at full speed).
(2) In order to run guests, you have to provide a BIOS (or some sort
of other boot ROM), since most guests wouldn't be able to boot without
BIOS services. This applies for all guests, but of particular
interest to us are i686/x86_64 guests.
(3) SeaBIOS is a free, open source PC BIOS implementation. It is what
we use to provide services to i686/x86_64 PC guests.
(4) Although qemu itself bundles some binary BIOSes, in Fedora we have
chosen to recompile these from source. We now (on i686/x86_64)
compile or cross-compile all ROMs from source.
(5) 'seabios-bin' is the name of the RPM package that contains the
SeaBIOS ROMs. I have no idea why (historical?) this package has
'-bin' in the name, but the important point is that it is NOT a
binary-only package. It is built from source.
(6) In order to compile SeaBIOS you need a program called 'iasl' (part
of the ACPICA.org project). This program is needed to compile the
ACPI tables which are an integral part of the ROM data that is needed
for i686/x86_64 guests to boot.
(7) Unfortunately the iasl program, which runs fine on little-endian
platforms, has endianness issues. Such that when you run it on a
ppc64 host it produces big-endian ACPI tables, which are of course
completely broken. 'iasl' itself is a very large program, and I do
not know the scope of the fix for this issue -- it may be trivial, or
it may require auditing every line of code.
Therefore:
We would like a packaging exception which would allow us to import the
seabios-bin package (built on little-endian) into the ppc & ppc64
buildroots.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine. Supports Linux and Windows.
http://et.redhat.com/~rjones/virt-df/
11 years, 6 months
RFD: C/C++ template packages
by Ralf Corsepius
Hi,
Fedora carries some "C/C++" "template"/"header-only" packages (Packages
which contain C/C++-headers only).
Typically, these packages are being built "BuildArch: noarch".
== These packages are supposed to be arch-independent.
In reality, many of these packages often are wrapper headers, trying to
wrap to something highly OS-/arch-dependent, from system-headers and
compiler built-ins defines.
I.e. though these packages are supposed to be arch-independent, there is
no guarantee nor check whether these packages actually are arch-independent.
I am proposing to:
Proposal:
All "C/C++-template/header-only packages" must be built using an
"arch'ed BuildArch", with the resulting binary packages implemented as
"Arch: noarch"-subpackages.
Benefits:
- This would assure such packages would be built on all architectures
Fedora supports and not only the architecture noarch-packages are being
built.
- This would exercise potentially existing configuration-scripts on all
architectures and would allow to exercise test-scripts rsp. coding
examples (which can be regarded as compilation-checks) on all Fedora
supported architectures.
Comments, opinions?
Ralf
11 years, 6 months
Dependence on initscripts/chkconfig
by Milan Broz
Hi,
there seems to be a lot of packages which still require initscripts and chkconfig.
Majority of them are because of pre/post upgrade scriptlet (sysv->systemd).
Example - rsyslog:
%triggerpostun -n rsyslog-sysvinit -- rsyslog < 5.8.2-3
/sbin/chkconfig --add rsyslog >/dev/null 2>&1 || :
Without removing these triggers it is impossible to get rid of these unnecessary
dependences. (IMHO only *-sysv sub-packages should require it).
It is quite important mainly for minimal install but there are many packages
in the whole distro.
But because Fedora supports only upgrade from N-1 version, I think there
should be some guideline to remove these scriptlets after N+1 release.
Can you provide some guidance what to do here now?
Shouldn't be these triggers removed in rawhide (F19) now?
Thanks,
Milan
11 years, 6 months
APT,YUM and package status
by Mohsen Pahlevanzadeh
Dear all,
Recently, i'm writing a benchmark between APT and YUM, by default i
didn't know yum and know apt, i didn't find the following status in the
yum:
//////////////////////////////////////
PACKAGE STATES
not-installed
The package is not installed on your system.
config-files
Only the configuration files of the package exist on the
system.
half-installed
The installation of the package has been started, but not
completed for some reason.
unpacked
The package is unpacked, but not configured.
half-configured
The package is unpacked and configuration has been
started, but not yet completed for some reason.
triggers-awaited
The package awaits trigger processing by another package.
triggers-pending
The package has been triggered.
installed
The package is unpacked and configured OK.
//////////////////////////////////////////////
Where can i find above feature or yum doesn't has them?
--mohsen
11 years, 6 months
[Guidelines Change] Change to the Packaging Guidelines
by Tom Callaway
A few minor changes to the Fedora Packaging Guidelines have been made:
---
The Ruby Packaging guidelines were updated to reflect the fact that
rubygem packages must have a Requires: rubygems, because that package
(rubygems) owns the RubyGems? directory structure.
https://fedoraproject.org/wiki/Packaging:Ruby#RubyGems
---
The systemd Scriptlets for Fedora 18+ have had their corresponding
scriptlet Requires adjusted from "systemd-units" to "systemd", since
"systemd-units" is provided by the "systemd" package in Fedora 18+.
There is still a separation in previous releases of Fedora (16/17), so
packagers can choose to continue using the old Requires (systemd-units)
if they are targeting multiple versions of Fedora with a single spec file.
https://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Macroized_scri...
---
This guideline change was approved by the Fedora Packaging
Committee (FPC).
Many thanks to Vit Ondruch, Lennart Poettering, and all of the members
of the FPC, for assisting in drafting, refining, and passing these
guidelines.
As a reminder: The Fedora Packaging Guidelines are living documents! If
you find something missing, incorrect, or in need of revision, you can
suggest a draft change. The procedure for this is documented here:
https://fedoraproject.org/wiki/Packaging/Committee#GuidelineChangeProcedure
Thanks,
~tom
11 years, 6 months
requiring a (non-specific) font?
by Matthew Miller
I happened to install Scratch onto a remove VM (on Fedora Infrastructure's
new private cloud, in fact) where no fonts were installed. It runs, but
Pango throws warnings about not having anything for 'latin' or 'common' --
and of course the UI has boxes where the menus and variables should be.
I could require something generic, like 'font(:lang=en)', but that's likely
to pull in a random decorative font.
I could require some specific font, but that seems wrong. (Particularly
since if a "better" match for latin or common happen to be installed,
whatever I said is a requirement will actually be irrelevant.)
Orrr, should I just not worry about this case?
--
Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ <mattdm(a)fedoraproject.org>
11 years, 6 months
