Status and outlook of LSB and FHS compliance of Fedora.
by Phil Knirsch
Hi folks.
I've been looking at how well Fedora is compliant with the latest LSB
and FHS specifications lately.
I came up with a small list of packages that, due to the change in the
latest FHS-2.3 and the addition of /srv and /media would seem likely
candidates for partiall data migration to /srv:
bind
arpwatch
mailman
krb5-server
httpd
tomcat
htdig
openldap
mysql
namazu
inn
postgresql
webalizer
vsftpd
Quite a few of those packages could keep their data in /var as their are
either minor packages or uncritical in general.
Only bind, httpd and vsftpd are the really imporant packages with lots
of data. Bind will stay where it is mainly for historical reasons as
everyone excpects /var/named to exist and contain all the important bind
configuration and data.
That only leaves vsftpd and httpd. The problem with those packages is
how to ensure and guarantee a 100% safe data migration of data during an
upgrade. For that reason we probably will keep them where they are for
now, too. For httpd it would also probably brake quite a few 3rd party
applications that either directly write to /var/www/html or which do
some other work with /var/www and expect it to be there as currently.
So mainly for historical and data migration reasons we have decided to
only provide /media and /srv for FHS-2.3 compliant applications in the
near future but won't move any of the existing package data there for now.
Hope this explains a little our reasoning and motivations related to and
concerning the LSB/FHS and where we stand and want to go in the future.
Any comments/concerns/ideas/flamewars are, as always very welcome. :-)
Read ya, Phil
--
Philipp Knirsch | Tel.: +49-711-96437-470
Development | Fax.: +49-711-96437-111
Red Hat GmbH | Email: Phil Knirsch <phil(a)redhat.de>
Hauptstaetterstr. 58 | Web: http://www.redhat.de/
D-70178 Stuttgart
Motd: You're only jealous cos the little penguins are talking to me.
19 years, 12 months
Dropping python-optik?
by Mihai Ibanescu
Hello,
As of python 2.3, Optik is included in the mainline python (although it's
called optparse now).
Fedora currently ships python 2.3.3 (2.3.4 in rawhide), so we may consider
dropping the python-optik package.
If we are to do this, the main python package would have to obsolete
python-optik and have a virtual provides for python-optik; but then again,
if your script worked with optik it would have to adjust its imports to use
optparse instead. So it's quite messy.
Any preference on how to handle this? Drop the package and deal with the mess?
Keep the package and deal with the mess? :-)
Cheers,
Misa
19 years, 12 months
Re: P2 CPU "class, " but 386/486 ISA "core" are commonplace -- embedded developers use what they know ...
by Bryan Smith
Although a very simplistic viewpoint, eWeek's Peter Coffee pointed out
this exact phenomenon:
http://www.eweek.com/article2/0,1759,1607953,00.asp
Far too many times, developers plunk a full, desktop-level OS on
embedded systems _when_ the have the CPU, memory and disk resources to
run it. As an engineer who worked years in this industry, I can tell
you this with certainty. That's why many projects just opt for the
extra goodies in an embedded board -- so they can run a full-up OS.
So, again, I re-iterate that Fedora Core should continue to be at least
an i486 ISA compatible distro. To keep engineering support at a minimum
on embedded platforms that have the power and resources to run a full
distro. It's more than just install-time, but service-time too.
--
Bryan J. Smith, E.I. -- b.j.smith(a)ieee.org
19 years, 12 months
Re: P2 CPU "class, " but 386/486 ISA "core" are commonplace -- AMD5x86 = 486 ISA
by Bryan Smith
Per Bjornsson wrote:
> Pentium = 586 obviously.
I like to refer to it as the Pentium ISA. The "586" moniker can be
marketing-based.
> Also a 586:
> "The ÉlanSC520 microcontroller combines a 32-bit, low-voltage Am5x86
> CPU with a complete set of integrated peripherals..."
No. The AMD 5x86 is a 486 _ISA_. The name "586" is _marketing_.
Understand that the AMD 5x86 _is_ the AMD 486 with some performance
tweaks (FSB, speed, cache, etc...). It's a 486 _ISA_.
The AMD 5x86 _pre-dates_ the K5. It was always debated if the K5 was
Pentium or 486 ISA. It seemed thave some issues with some Pentium
instructions.
The K5 redesign, or those with more than a 120MHz "rating" -- wasn't
actual speed, were based on the 2nd generation NexGen Nx586 with FPU.
The original NexGen Nx586 was a 4-issue i386 if you can believe that!
I believe these latter K5s were i486 ISA with most Pentium ISA
compatibility.
[ NexGen's RISC86 sub-ISA core is at the heart of all current AMD
processors ]
It actually wasn't until the AMD K6 that it was fully Pentium ISA
compatible.
Cyrix had the same issues. Not only was the Cyrix 5x86 also only a 486
ISA, but the 6x86 through P200+ (150MHz) was _still_ a 486 ISA.
I don't think it was until the "L" version or the "M2" that Cyrix made
it to full Pentium ISA compliance.
> Basically I think that I'm more or less agreeing with you: Fedora
> shouldn't dump old ISAs unless there is a real, tangible gain; moving
> beyond 486 doesn't really seems to give us that. Where we differ is
> that I think that ignoring the 386 by explicitly using NPTL is a good
> idea and very much in line with the Fedora goals.
If NPTL require an 486 ISA, then a 486 ISA should be the standard, I'll
concede. There are various segmenting/table paging issues that I
understand even the 386 MMU doesn't handle.
--
Bryan J. Smith, E.I. -- b.j.smith(a)ieee.org
19 years, 12 months
RE: QA Application XML save formats.
by Toshio Kuratomi
> Sorry I haven't been following your qa-assistant very closely, I don't
run
> X most of the time. I did download the rpm from sourceforge, and took
a look
> at it. I'm assuming that version doesn't know how to save the .xml
files you
> referred to?
>
Yes. I wanted to get some feedback on the XML save format before
releasing something that has a format that's just going to be changed in
the next version. I've put up a snapshot of my current tree here (using
the current DTD):
http://qa-assistant.sf.net/snaps/
It has "save as" functionality but loading is currently broken.
> Since you have taken the time to encapsulate the checklist as an XML
file,
> I think we should all start adopting THAT as the canonical reference,
> including going so far as to write an xslt sheet to render it as html
and
> posting it on the website.
>
> I've created a first round xslt stylesheet, which can see the results
of at
> http://www.ilsw.com/~erik/fedoraus.xml
>
> The xslt stylesheet is at
> http://www.ilsw.com/~erik/checklist.xsl
>
I like that idea alot. Your stylesheet is nice too. The text of the
various entries could use some going over by others since they're
currently just my interpretation of the wiki and a few other
non-controversial suggestions. They could probably do with a bit of
reformatting as well as I didn't anticipate them being displayed on a
web page.
> I also spent some time thinking about how to integrate our code. I'm
going to
> throw out an idea here, and you can see what you think. If you look at
the
> changes I made to the first couple of entries in fedoraus.xml, you can
see I
> added a <script> section, with some simple code in it. My thought is
that the
> best way to enforce a policy is to put the code to do it in the same
place as
> the policy definition, aka the checklist definition.
>
This is a great plan. I've been trying to think of the best way to add
automated checking into QA Assistant and this definitely beats the pants
off of anything I was thinking of. I'd call it <test> instead of
<script> as that's more specific to what we're doing but the idea seems
very sound.
I'd like to integrate some sort of signature on the checklist though.
That way people can tell they're about to execute a script that's part
of an official Fedora Checklist, Michael Schwendt's Alternate Fedora
Checklist, or Vader's Join The Darkside Luke Checklist. Not sure the
best way to achieve this so the programs that utilize the checklist can
check it, though.
> I also created a simple python script to walk through the checklist,
find the
> scripts, and run them. With some tweaking, I think it could work
admirably
> both for an unattended checker, or integrated into a gui like yours.
The
> script is at http://www.ilsw.com/~erik/runchecklist.py
>
> Outstanding issues:
> We need to agree on a way to define input parameters to pass into
scripts,
> ie things like a gpg keyring file, or the srpm filename, or ??? You
can see
> I started doing this, but I haven't finished the job by any means.
>
Do we want to allow different scripting languages to be used?
For most scripting languages we could write the variables directly into
the scriptlets. Alternately we could pass them as environment variables
and have the script (or shell wrapper) compose them. Using these
methods we don't need to worry about the order of the arguments, just
what they are named.
What things would it be okay for the scriptlet to ask for? Somehow the
program either has to know or ask the user to supply the information the
script wants in the first place. Should we have
<param name="srpm_filename" query="What is the SRPM filename?">
so the program can supply srpm_filename if it already knows it or query
the user for it when the script runs?
> We need to agree on an output method. I think the easy way to do it is
by
> mapping return codes to states like I show in the example, or taking
the
> entire textual output of the program and matching it to a state name.
We can
> do both, they're both easy.
>
Return value is good for most things but sometimes the scriptlet could
return a better output message than the program would otherwise. I don't
want to teach the program what to do for each individual case in the
checklist, however. Should we have a tag specify if it returns a
message? <message>True</message>
Should such scripts output the message as the last line?
(We could have all scriptlets be in python and run them in-process so we
can retrieve complex return values directly....)
> Other comments:
> I'm not sure I entirely understand the difference between qasave.dtd
and
> checklist.dtd. My personal preference is to generate the qasave dtd
(xml
> schema would be better) and xml directly from the checklist xml. Then
there
> is 1 and only 1 definition of the policy, description, and storage
format.
>
Could definitely be done. Frugality of disk space led me to define two
separate formats but now that I've implemented it once I think it adds
unnecessary complexity.
My thought on creating one format are that we'd have a base checklist
that merged the checklist.dtd and qasave.dtd information together.
The resolution would be set to 'Needs-Reviewing' for all entries. When
a program ran through a checklist and wanted to save state it would
write out a complete checklist file that was based on the original but
with changes where the user changed states, edited the output message
for a review item, etc.
The properties element could use some reworking here as well. The base
checklist could specify the properties the checklist supports and the
type each is.
[Thought: perhaps all input that the scriptlets could use should be a
checklist property. Are there times when a scriptlet would need to know
something that wasn't a property? gpg keyring is really a program
preference for instance... I'd store preferences in GConf and the
scriplets could extract it... but you might not want the command line
script to need GConf (GConf isn't graphical, but it isn't something you
expect a standard command-line app to need....)]
> I think the checklist probably needs to carry more of the policy
information
> we've argued about (and not decided on) with it. IE I'd like for each
entry
> to have a "class" or something indicating if it was a Blocker,
Non-Blocker,
> Important, or Cosmetic only.
>
Each checklist item has a list of allowable resolution states:
Needs-Reviewing, Pass, Fail, Non-Blocker, Not-Applicable.
Each item must have Pass and Needs-Reviewing. Depending on whether I
thought the item was definitively a Blocker or Minor or could fall into
either category I added other resolutions. We could change names, add
resolution states, and reassign which set of resolutions are available
for each item pretty easily. Will that work or do you think we should
have actual "classes" that predefine which set of resolutions are
available? We'd still need to have the states array as we need to set
the output messages on a per state basis....
> I think the checklist xml also needs to carry whatever information
might be
> needed to create a QA report in the affirmative or negative for that
> particular entry. IE you should be able to create some sort of human
friendly
> listing of the packages status by transforming a "checklist data file"
and a
> "checklist" together. Maybe you already have this?
>
If I understand what your asking, this is basically what QA Assistant
does. (Or will once loading of save files works correctly.)
There might be some value to creating a command line tool to do this as
well. Perhaps the commandline script that runs tests embedded in the
checklist could use xml as its internal representation and then xslt
transform it into a QA Report. Then, run-checklist.py --notest save.xml
could do the transform on a saved checklist without running any new
tests.
-Toshio
--
_______S________U________B________L________I________M________E_______
t o s h i o + t i k i - l o u n g e . c o m
GA->ME 1999
19 years, 12 months
Error rebuilding Arjan's 422 kenrel
by Chris Kloiber
I don't have it on my screen anymore to copy, but having rebuilt the 422
kernel, I am getting errors for unpackaged debug files like
/usr/lib/debug/<kernel-ver>/System.Map and others. I see that most of
the logic for building the kernel-debuginfo rpm has vanished, perhaps
this is just a holdover?
--
Chris Kloiber
19 years, 12 months
fc2, xorg, 2.6.x, scheduling latency peaks
by Fernando Lopez-Lezcano
Hi all. I'm trying to track the cause of high scheduling latency peaks
in FC2 that make the system unusable for low latency audio work.
Test systems: PIV laptop, radeon video chipset, AMD64 desktop, radeon
video chipset. How I test: I run the Jack (Jack Audio Connection Kit)
sound server with 2 or 3 128 frame buffers for low latency operation
through the Qjackctl gui front-end. I then start GUI apps that use Jack
(for example Freqtweak, Hydrogen and Jamin). I see plenty of buffer
xruns of varying durations during the app load process and afterwards.
The same (laptop) system booting FC1 + XFree + 2.4.26 + low latency
patches has rock solid performance and no xruns in the same conditions.
If I boot FC2 into 2.4.26 + low latency patches I _still_ see xruns, so
it looks like the kernel itself is not triggering them. At least not all
of them.
I have no hard data but the xruns appear to coincide with X activity. If
I turn off video acceleration I see _more_ xruns (significantly more).
If I switch to the vesa driver I still see xruns (so it would seem that
the radeon driver itself is not to blame).
Does anyone out there know if something has changed between XFree and
xorg that may account for this change in behavior?
Thanks for _any_ help.... (I also tried several other configuration
options for xorg.conf with no effect whatsoever[*]).
-- Fernando
[*] and even tried to downgrade to FC1's XFree86 just to see if I could
isolate the cause but the result was too unstable and messy to draw any
conclusions :-)
19 years, 12 months
Re: Fedora Core 2 upgrade FAILURE
by Richard Emberson
SUCCESS (see below)
Richard Emberson wrote:
> I have an older machine that can not boot from cdrom. Also, I had
> some user data in one of the accounts.
>
> So I mounted disc1, copied vmlinuz and initrd.img to /boot, unmounted
> disc1, added entry to /etc/grub.conf, then rebooted:
>
> mount /dev/cdrom
> cp -a /mnt/cdrom/isolinux/vmlinuz /boot/FC2-install
> cp -a /mnt/cdrom/isolinux/initrd.img /boot/FC2-install.img
> umount /mnt/cdrom
> and add entry like:
> title Fedora Core 2 Installation
> root (hd0,0)
> kernel /FC2-install
> initrd /FC2-install.img
> to /etc/grub.conf (use /boot/FC2... when not relative to /boot)
>
> Everything was going along fine; I did an upgrade (not install) and
> after 1 1/2 hours it said that the installation was a success and that
> I should click the reboot button ... which I did.
>
> Well, reboot started out ok, there was a single boot option on the
> grub boot page, but then it asked me to insert disc1. I did so
> and it then asked me if I wanted to upgrade or install.
>
> hmmm.....
>
> I selected upgrade and it proceeded to "upgrade" a php rpm from disc1
> and compat-db rpm from disc3 and announced that the installation was
> successful and that I should click on the reboot button.
>
> Ok, reboot started and then once again it requested that I insert disc1
> and once again it installed the same two rpm's, php from disc1 and
> compat-db from disc3 and announced that the installation was a success.
>
> I tried one more time with the same result.
>
> So how do I break out of this? I really dont care about either
> php or compat-db, I'd like to somehow bypass installing them and
> get on with the boot. Are there parameters one can give at the grub
> command line to force a kernel load?
>
> Help! Thanks.
>
>
>
> Richard
>
>
Thanks to the many replies.
What I ended up doing ....
My original system had two scsi disks: disk1 with /boot and /
and the other, disk2, with /home and /usr/local and I did not want to
lose /home and /usr/local - which is why I wanted to upgrade,
not install.
So I bought a new scsi (I do plan to build a new machine at home
some time this Summer, so its not as extreme as one might think)
using it to replace disk2
and did a redhat 9.0 on my old machine.
I then mounted FC2 disc1 and copied vmlinux and initrd as described
above. I then via grub booted using the FC2 code and did a full
install. It worked. Now I can just replace the new disk2 with the
old and the upgrade is complete.
IMPORTANT: the first time I did this - yes I did this twice - I
for some unknown reason had disk1 contain /boot and /usr while
the new disk2 had / - the redhat 9 install succeeded this succeeded but
not the subsequent FC2 install!! - so the second time I had disk1
contain /boot and / while the new disk2 had /home and /usr/local and
for this combination FC2 install (after installing redhat 9 a
second time) worked.
Thanks again.
Richard
19 years, 12 months
SUMMARY: 3 similar, but distinct, discussions on "Core" changes ...
by Bryan Smith
I just wanted to take the time to introduce this post, possibly as a
reference for others to send when it gets difficult to look at the
similar, but distinct differences between these discussions.
1. Minimizing, shrinking, splitting up "Core"
2. 386/486/etc... Instruction Set Architecture (ISA) compatibility
3. A "common denominator" Fedora package set
1. Minimizing, shrinking, splitting up "Core"
Trying to address the bloating of "Core" at the same time as addressing
the legacy support path of Red Hat Linux (RHL). This is the discussion
most people assume is always going on. Be sure it's not #2 or #3 below.
2. 386/486/etc... Instruction Set Architecture (ISA) compatibility
This is _not_ about a "lite" distro. Numerous vendors are selling
literally millions of "high speed" chips with lots of memory and storage
built around them, but they are "system-on-a-chip" systems. Most have
an i486 ISA compatible core -- despite being marketed as a "Pentium
II/III class." They are more than capable of running GNOME so, again,
it's _not_ about a "lite distro."
And yes, Linux runs on _many_ of them today! These are not just
"speciality" systems, but kiosks, terminals, etc... -- so it makes sense
from an engineering standpoint to offer Fedora while makes it far easier
for engineers to maintain a distro.
To this point, Red Hat has stood by with target i386, optimize for
i686. That addresses the majority of the modern chips out there within
5-10% of optimal performance, while preserving compatibility. But it
seems NPTL will force the i486 issue, and the question is should we just
move the "target" higher than i486 and break compatibility? And should
be just start targetting i486 anyway?
Because of these SoC systems are still around, and _will_ be for years
to come, there is no reason to go beyond targetting i486 IMHO. Since
none I know of are i386, and i486 offers all sorts of paging and other
capabilities, there is little reason not to move away from i386.
Combined with the i686 optimizations, it's a great setup, and the
kernel/GLibC is still available in a CPU-optimized version.
_Furthermore_, with x86-64 now being adopted, there is little sense to
optimize default packages any farther than i486, as most modern systems
are going to be x86-64 in short order, with a x86-64 built distro.
3. A "common denominator" Fedora package set
Lastly and more eccentric, I'm talking about taking the "minimization"
to a new level. The idea here is to provide a "common denominator"
Fedora package set. More than the 90MB "minimal" install, but one that
distro off-shoots, corporations, developers and others can use as a
"base."
It's _not_ an end-user usable distro. But it _is_ a bootable distro
with a GUI, just enough to fetch everything else via Apt/Yam. And it
doesn't have too much where people would disagree.
The Rules:
- All packages must be in Fedora "Core" (no Extras)
- No package included may have a dependency on another included
- If dependency issues arise, work with Fedora "Core" to see the
dependencies are either corrected, changed in a future version,
segmented into multiple packages or just don't use the package (if at
all possible)
The Goals: "Common Denominator"
- For new off-shoot distros (e.g., should be a subset of Cobind)
- For developers (e.g., want to know what libraries to aim for)
- For corporations (e.g., who will maintain their own internal
repository, and just need a standard, "base" install)
Eventually: Additional distributed package management tools/support
Ideal/Future: The package lists would be included as part of "Core" --
e.g.,
Quark: Std Desktop -- Minimal
Quark: LAN Server -- Directory/Name/Time Server
Quark: LAN Server -- File/Print Server
Quark: LAN Server -- Kerberos Distribution Center (KDC)
Quark: WAN Server -- Directory
Quark: WAN Server -- FTP/Web
Quark: WAN Server -- Remote Access
etc...
In every case, the service support is _minimal_, very basic. The idea
is to start "small" (e.g., PHP is not even included, so the web server
is _basic_), and move from there. Furthermore, the "Server" components
are easily separated out and not included if desired, for a "pure"
desktop base.
The Design:
- Services:
A. All basic clients/services for authentication, directory and network
access
B. All basic UNIX bash shell scripting, plus Perl and Python
C. Console configuration tools (Newt libraries)
D. Distributed package manager (Apt, possibly Yum)
- GUI:
E. Simple GTK+ or Qt-based GUI (elementary GTK+/Qt support)
G. Perl/Python bindings for GTK+/Qt
H. GUI configuration tools (GTK+ libraries)
I. GUI distributed package manager (Synapic)
What window manager is used? I don't know. But it _must_ be in Fedora
"Core" itself. Maybe just XFWM will do (but not the full XFCE
framework), now that XFCE is included in Fedora Core 2.
This is just to get the system "up and running" with a GUI. All other
customization is done post-install with distributed repository access.
--
Bryan J. Smith, E.I. -- b.j.smith(a)ieee.org
19 years, 12 months