xmlformat licensing
by Paul W. Frields
(Excuse the <pedantic> mode, the initial summary is for historical
purposes.)
<pedantic>
The Fedora Documentation Project's (FDP) goal is to "create easy-to-
follow, task-based documentation for Fedora Core users and
developers."[1] The FDP is part of the Fedora Project. The Fedora
Project's overall goal is to "build a complete, general purpose
operating system exclusively from open source software."[2]
For a few days, some of the Fedora Documentation Project folks have been
contemplating using an XML normalization utility to clean up XML into a
standardized presentation before a CVS commit happens. The clean up
would include, but not be limited to, the following:
* set standard fill-column (the columnar position after which
unprotected text is wrapped)
* set indentation size
* set block/inline tag vertical spacing
While performing the cleanup procedure, any utility used must also
protect the DTD block, any CDATA containers, and any similar containers
such as <screen>, <programlisting>, and <literal>. It must be
configurable in such a way that changes to the configuration can be
provided cleanly via CVS. Clients would perform this procedure as part
of a "make" target before committing changes. The details on this part
have yet to be worked out, but we would certainly try to make it as
painless as possible -- possibly even simply making it a prerequisite to
any other constructive "make" target.
Without this step, we are running a risk of generating a lot more white
noise in CVS and on the fedora-docs-commits list. In 2003, with a
smaller, less visible project, the use of Emacs/PSGML was simply
*required*, more or less, so normalization was enforced on the client
side without any additional fuss. With more participants, however, we
have to confront the fact that people want to use their own favorite
tools. XML normalization makes cooperation on the same document
possible for writers and editors who enjoy different tools, by ensuring
that CVS diffs are sensible.
</pedantic>
The "tidy" utility is GPL and in Fedora Extras, and it will do some XML
cleanup, but it is not designed for this purpose. It was designed as an
HTML normalization engine, and simply has some XML functionality. The
"xmlformat" utility is designed from the ground up as an XML normalizer,
but it is *not* GPL. Thankfully, Tommy Reynolds brought the xmlformat
licensing specification to my attention last week, so I've had a little
time to think about it.
The xmlformat utility is still open source software; although IANAL, I
did a pretty thorough review of the licensing of xmlformat and other
open source software requirements, and this seems pretty clear-cut.
Note that the "open source" requirement *does not* mean the software has
to be GPL, or BSD. It merely needs to meet the requirements and
definition of "open source."[3] The terms are clear-cut enough that we
may not need an official legal opinion from Mark Webbink, but I am
willing to put a link to this message at the appropriate wiki location
for him to look at if anyone thinks it's necessary.
Here are the facts of licensing pertaining to xmlformat:
(A) The original portions of xmlformat by Paul DuBois, paul at kitebird
com, are licensed under a BSD-style license.[4] The BSD-style license
is an open source license. The only portion of xmlformat not covered by
this license is the implementation of the REX shallow parser.
(B) The REX shallow parser, which is copyrighted by Robert D. Cameron,
cameron at sfu ca, is licensed under terms shown below in their
entirety:
"The following code may be freely used and distributed provided that
this copyright and citation notice remains intact and that modifications
or additions are clearly identified."[5]
The REX shallow parser clearly meets the requirements of the Open Source
Definition, to wit:
1. No royalties or fees are imposed upon redistribution of REX. The
license specifically and categorically permits free distribution without
additional restrictions.
2. The source code for REX is publicly available.
3. The copyright holder for REX allows modifications or derivative
works. The licensing terms require these be clearly identified, but it
puts no restrictions on their creation. In addition, the terms
explicitly permit free use of the material.
4. The license for REX does not set out any requirements for the
licensing of modified versions, other than to require the modifications
be identified as such. This requirement would allow modified versions
to be distributed as the original version plus patches, as doing so
would clearly identify modifications and thus meet the requirement.
5. The license for REX does not discriminate against persons or groups,
nor against fields of endeavor.
6. The only requirements of the licensing terms flow through to and
with any redistributed versions of REX, that is, the requirements for
the copyright and citation notices to remain intact, and for
modifications to be identified.
7. The license applies to the entire REX implementation. There are no
subordinate parts or components as such.
8. The license does not restrict other software, and in fact REX can be
distributed with other software. The xmlformat utility is itself an
example of this use.
Because the REX software, and thus xmlformat, clearly meet all the
requirements of the open source definition, we should be able to use it
in our toolchain without incurring any difficulty. (REX probably also
meets the definition of "free software," although it is not copylefted
and thus does not share the same distinction as GPL software.) I'll
prepare an RPM of this package and see about getting it into Fedora
Extras. In the meantime, we can keep testing and evaluating other
methods of XML normalization. So far, xmlformat does the best job that
I've seen, but I'm sure there must be other tools out there.
Does anyone know whether Expat could easily do what we are trying to
accomplish, or am I talking apples to oranges?
= = = = =
[1] http://fedora.redhat.com/projects/docs/
[2] http://fedora.redhat.com/about/
[3] http://opensource.org/docs/definition.php
[4] http://www.kitebird.com/software/xmlformat/
[5] http://www.cs.sfu.ca/~cameron/REX.html#AppA
--
Paul W. Frields, RHCE http://paul.frields.org/
gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717
Fedora Documentation Project: http://fedora.redhat.com/projects/docs/
18 years, 10 months
Re: release-notes/FC4 kernel.xml,1.5,1.6
by Patrick W. Barnes
Karsten Wade (kwade) wrote:
>Author: kwade
>
>Update of /cvs/docs/release-notes/FC4
>In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv6186
>
>Modified Files:
> kernel.xml
>Log Message:
>Fixes broken tags during my minor refactoring, indents content.
>
>
>Index: kernel.xml
>===================================================================
>RCS file: /cvs/docs/release-notes/FC4/kernel.xml,v
>retrieving revision 1.5
>retrieving revision 1.6
>diff -u -r1.5 -r1.6
>--- kernel.xml 7 Jun 2005 19:23:54 -0000 1.5
>+++ kernel.xml 7 Jun 2005 19:35:16 -0000 1.6
>@@ -18,9 +18,13 @@
> <section id="sn-kernel-lotsa">
> <title>Version</title>
> <para>
>- The &DISTRO; is based on a 2.6.11 kernel.
>- &FC; may include additional patches for improvements, bug fixes, or additional features.
>- For this reason, the &FC; kernel may not be line-for-line equivalent to the so-called vanilla kernel from the <ulink url="http://ww.kernel.org"><filename>kernel.org</filename></ulink> web site.
>+ The &DISTRO; is based on a 2.6.11 kernel. &FC; may include
>+ additional patches for improvements, bug fixes, or additional
>+ features. For this reason, the &FC; kernel may not be
>+ line-for-line equivalent to the so-called vanilla kernel from the
>+ <ulink
>+ url="http://ww.kernel.org"><filename>kernel.org</filename></ulink>
>
>
ww.kernel.org -> Typo?
>+ web site.
> </para>
> <para>
> You may obtain a list of any such patches by using the command on the &FC; package:
>@@ -37,10 +41,13 @@
> <itemizedlist>
> <listitem>
> <para>
>- Native kernel, in both uniprocessor and <abbrev>SMP</abbrev> varieties.
>+ Native kernel, in both uniprocessor and <abbrev>SMP</abbrev>
>+ varieties.
> </para>
> <para>
>- Configured sources are available in the <filename>kernel-devel-<replaceable><version></replaceable>.<replaceable><arch></replaceable>.rpm</filename> package.
>+ Configured sources are available in the
>+ <filename>kernel-devel-<replaceable><version></replaceable>.<replaceable><arch></replaceable>.rpm</filename>
>+ package.
> </para>
> </listitem>
> <listitem>
>@@ -48,17 +55,20 @@
> Virtual kernel for use with the <wordasword>Xen</wordasword> emulator package.
> </para>
> <para>
>- Configured sources are available in the <filename>kernel-xen0-devel-<replaceable><version></replaceable>.<replaceable><arch></replaceable><filename>.rpm</filename> package.
>+ Configured sources are available in the
>+ <filename>kernel-xen0-devel-<replaceable><version></replaceable>.<replaceable><arch></replaceable>.rpm</filename>
>+ package.
> </para>
> </listitem>
> </itemizedlist>
> <para>
> Sources for both kernel flavors may be installed at the same time.
>- The files will be installed into the <filename>/usr/src/kernels/<replaceable><version></replaceable>[-xen0]-<replaceable><arch></replaceable>/</filename> tree.
>- Use the command:
>+ The files will be installed into the
>+ <filename>/usr/src/kernels/<replaceable><version></replaceable>[-xen0]-<replaceable><arch></replaceable>/</filename>
>+ tree. Use the command:
> </para>
> <screen width="56">
>-<command>rpm</command> <parameter class="option">-Uvh</parameter> <filename>kernel-devel[-xen0]-<replaceable><version></replaceable>.<replaceable><arch></replaceable><filename>.rpm</filename>
>+<command>rpm</command> <parameter class="option">-Uvh</parameter> <filename>kernel-devel[-xen0]-<replaceable><version></replaceable>.<replaceable><arch></replaceable>.rpm</filename>
> </screen>
> <para>
> as appropriate.
>@@ -66,9 +76,12 @@
> <tip>
> <title>Following Generic Textbooks</title>
> <para>
>- Many of the tutorials, examples, and textbooks about Linux kernel development assume the kernel sources are installed under the <filename>/usr/src/linux</filename> directory.
>- If you make a symbolic link, as shown below, you should be able to use those learning materials with the &FC; packages.
>- Install the appropriate kernel sources, as shown earlier, and then:
>+ Many of the tutorials, examples, and textbooks about Linux
>+ kernel development assume the kernel sources are installed under
>+ the <filename>/usr/src/linux</filename> directory. If you make a
>+ symbolic link, as shown below, you should be able to use those
>+ learning materials with the &FC; packages. Install the
>+ appropriate kernel sources, as shown earlier, and then:
> </para>
> <screen width="56">
> <command>ln</command> <parameter class="option">-s</parameter> <filename>/usr/src/kernels/kernel-<replaceable><all-the-rest></replaceable></filename> <filename>/usr/src/linux</filename>
>@@ -95,32 +108,43 @@
> Preparing for Kernel Development
> </title>
> <para>
>- &DISTRO; &DISTROVER; does not include the <filename>kernel-source</filename> package provided by older versions.
>- Instead, configured sources are available as described in <xref linkend="sn-kernel-flavors"/>.
>- Users that require access to &FC; original kernel sources can find them in the <filename>kernel</filename> <filename>.src.rpm</filename> package.
>- To create an exploded source tree from this file, perform the following steps:
>- </para>
>- <warning>
>- <title>These Instructions Refer to the Currently-running Kernel!</title>
>- <para>
>- To simplify the following directions, we have assumed that you want to configure the kernel sources to match your currently-running kernel.
>- In the steps below, you must understand that the phrase
>- <wordasword><version></wordasword> refers to the kernel
>- version shown by this command:
>+ &DISTRO; &DISTROVER; does not include the
>+ <filename>kernel-source</filename> package provided by older
>+ versions. Instead, configured sources are available as described
>+ in <xref
>+ linkend="sn-kernel-flavors"/>. Users that require access to &FC;
>+ original kernel sources can find them in the
>+ <filename>kernel</filename> <filename>.src.rpm</filename> package.
>+ To create an exploded source tree from this file, perform the
>+ following steps:
> </para>
>+ <important>
>+ <title>These Instructions Refer to the Currently-running Kernel!</title>
>+ <para>
>+ To simplify the following directions, we have assumed that you
>+ want to configure the kernel sources to match your
>+ currently-running kernel. In the steps below, you must
>+ understand that the phrase
>+ <replaceable><version></replaceable> refers to the kernel
>+ version shown by this command:
>+ </para>
> <screen width="56">
> <command>uname</command> <parameter class="option">-r</parameter>
> </screen>
>- </warning>
>+ </important>
> <procedure id="sn-kernel-exploding-steps">
> <step>
> <para>
>- Obtain the <filename>kernel-<replaceable><version></replaceable>.src.rpm</filename> file from one of the following sources:
>+ Obtain the
>+ <filename>kernel-<replaceable><version></replaceable>.src.rpm</filename>
>+ file from one of the following sources:
> </para>
> <itemizedlist>
> <listitem>
> <para>
>- The <filename>SRPMS</filename> directory on the appropriate <wordasword>SRPMS</wordasword> <abbrev>CD</abbrev> <filename>iso</filename> image.
>+ The <filename>SRPMS</filename> directory on the
>+ appropriate <wordasword>SRPMS</wordasword>
>+ <abbrev>CD</abbrev> <filename>iso</filename> image.
> </para>
> </listitem>
> <listitem>
>@@ -141,13 +165,17 @@
> </step>
> <step>
> <para>
>- Install <filename>kernel-<replaceable><version></replaceable>.src.rpm</filename> using the command:
>+ Install
>+ <filename>kernel-<replaceable><version></replaceable>.src.rpm</filename>
>+ using the command:
> </para>
> <screen width="56">
> <command>rpm</command> <parameter class="option">-Uvh</parameter> <filename>kernel-<replaceable><version></replaceable>.src.rpm</filename>
> </screen>
> <para>
>- This writes the <abbrev>RPM</abbrev> contents into <filename>/usr/src/redhat/SOURCES</filename> and <filename>/usr/src/redhat/SPECS</filename>.
>+ This writes the <abbrev>RPM</abbrev> contents into
>+ <filename>/usr/src/redhat/SOURCES</filename> and
>+ <filename>/usr/src/redhat/SPECS</filename>.
> </para>
> </step>
> <step>
>@@ -159,8 +187,13 @@
> <command>rpmbuild</command> <parameter class="option">-bp --target $(arch)</parameter> <filename>kernel.spec</filename>
> </screen>
> <para>
>- The kernel source tree will be located in the <filename>/usr/src/redhat/BUILD/kernel-</filename><replaceable><version></replaceable> directory.
>- It is common practice to move the resulting <filename>linux-</filename><replaceable><version></replaceable> directory to the <filename>/usr/src</filename> tree; while not strictly necessary, we suggest that you do this to match the generally-available documentation.
>+ The kernel source tree will be located in the
>+ <filename>/usr/src/redhat/BUILD/kernel-</filename><replaceable><version></replaceable>
>+ directory. It is common practice to move the resulting
>+ <filename>linux-</filename><replaceable><version></replaceable>
>+ directory to the <filename>/usr/src</filename> tree; while not
>+ strictly necessary, we suggest that you do this to match the
>+ generally-available documentation.
> </para>
> <screen width="56">
> <command>cd</command> <filename>/usr/src/redhat/BUILD/kernel-<replaceable><version></replaceable></filename> <filename>/usr/src/</filename>
>@@ -172,9 +205,13 @@
> </step>
> <step>
> <para>
>- The configurations for the specific kernels shipped in &DISTRO; &DISTROVER; are in the <filename>configs/</filename> directory.
>- For example, the i686 SMP configuration file is named <filename>configs/kernel-<replaceable><version></replaceable>-i686-smp.config</filename>.
>- Issue the following command to place the desired configuration file in the proper place for building:
>+ The configurations for the specific kernels shipped in
>+ &DISTRO; &DISTROVER; are in the <filename>configs/</filename>
>+ directory. For example, the i686 SMP configuration file is
>+ named
>+ <filename>configs/kernel-<replaceable><version></replaceable>-i686-smp.config</filename>.
>+ Issue the following command to place the desired configuration
>+ file in the proper place for building:
> </para>
> <screen width="56">
> <command>cp</command> <filename>configs/<replaceable><desired-config-file></replaceable></filename> <filename>.config</filename>
>@@ -196,10 +233,14 @@
> <section id="sn-kernel-3rdparty">
> <title>Building Only Kernel Modules</title>
> <para>
>- An exploded source tree is <emphasis>not</emphasis> required to build a kernel module, such as your own device driver, against the currently in-use kernel.
>+ An exploded source tree is <emphasis>not</emphasis> required to
>+ build a kernel module, such as your own device driver, against the
>+ currently in-use kernel.
> </para>
> <para>
>- For example, to build the <filename>foo.ko</filename> module, create the following <filename>Makefile</filename> in the directory containing the <filename>foo.c</filename> file:
>+ For example, to build the <filename>foo.ko</filename> module,
>+ create the following <filename>Makefile</filename> in the
>+ directory containing the <filename>foo.c</filename> file:
> </para>
> <programlisting width="56">
> obj-m := foo.o
>@@ -218,10 +259,20 @@
> <section id="sn-kernel-coop">
> <title>Userspace Dependancies on the Kernel</title>
> <para>
>- &DISTRO; adds support for clustered systems.
>- This requires a special kernel that works in conjunction with some user-space utilities, such as management daemons.
>- Consequently, to remove such a kernel, perhaps after an update, you <emphasis>cannot</emphasis> simply use the <command>rpm -e kernel-<replaceable><version></replaceable></command> command as in earlier distributions because these userspace packages depend on the kernel package.
>- You may either list both the kernel package and its userspace dependant packages on the <command>rpm -e</command> command, or you may wish to use the <command>yum remove kernel-<replaceable><version></replaceable></command> command instead since <command>yum</command> automatically removes dependant packages if necesssary.
>+ &DISTRO; adds support for clustered systems. This requires a
>+ special kernel that works in conjunction with some user-space
>+ utilities, such as management daemons. Consequently, to remove
>+ such a kernel, perhaps after an update, you
>+ <emphasis>cannot</emphasis> simply use the <command>rpm -e
>+ kernel-<replaceable><version></replaceable></command>
>+ command as in earlier distributions because these userspace
>+ packages depend on the kernel package. You may either list both
>+ the kernel package and its userspace dependant packages on the
>+ <command>rpm -e</command> command, or you may wish to use the
>+ <command>yum remove
>+ kernel-<replaceable><version></replaceable></command>
>+ command instead since <command>yum</command> automatically removes
>+ dependant packages if necesssary.
> </para>
> </section>
> </section>
>
>--
>Fedora-docs-commits mailing list
>Fedora-docs-commits(a)redhat.com
>https://www.redhat.com/mailman/listinfo/fedora-docs-commits
>
>
>
Other than the error in the kernel.org URL, looking good.
--
Patrick "The N-Man" Barnes
nman64(a)n-man.com
www.n-man.com
--
18 years, 10 months
Re: FC4 feature list?
by Rahul Sundaram
Tony Nelson wrote:
>Rahul -- should I keep CC'ing the moderated fedora-docs-list? My last
>reply is held up for moderation and I haven't received approval or
>disapproval yet. Well, likely this is the last reply anyway.
>
Thats because its a weekend. I can post this thread explicitly to the
docs list if it doesnt get moderated. No worries
>Well, good. Now add it! (I'm not trying to make you feel bad through
>criticism; I'm trying to clear up things that would (have) made the
>installation hard for me to do, in hopes of helping others.)
>
>
Yes. I understand that. People were working on the release notes till
the last minute literally. Its a big time drain time drain to collect
the information and present it as what you can see in the release notes.
Makes you want more people to actually read it eh!. Some of these could
be improved by changes in the process that is being done. We really need
more people to step up and share some of the tasks. The following links
contain more information about this if anyone is interested in this
http://fedoraproject.org/wiki/DocsProject/ReleaseNotes/Process
http://fedoraproject.org/wiki/DocsProject/ReleaseNotes/Beats
>>>>
>>>>
>>>!! From the tone, I thought Gnome wouldn't work at all.
>>>
>>>
>>>
>>>
>>It might not.
>>
>>
>
>Wouldn't this leave the user in a confusing state with no UI? Unless they
>went to one of the hidden 6 terminals?
>
>
Not by default. The installer overrides the conflicting Ximian GNOME
packages and installs the ones that are integrated within the release.
If you choose to not use the Fedora packages and use the third party
ones you might be left with a non functional UI. Ximian packages are
just an example. This applies to any packages that result in a
conflict. Unfortunately I dont think there is any silver bullet
solutions to this issue which is why this is being documented in the
first place.
>You're welcome. I didn't test FC4 because I only started using Linux about
>3 weeks ago, and I'm pretty confused even using a stable release.
>
You should get used to the differences pretty soon. Maybe you will even
like at the end of the day !
> That's
>why my comments mostly reflect things that a confused user might have
>trouble with. Maybe I'll be up to testing FC5
>
>
New users are probably the best people to write and review such type of
documentation. They have a fresh insight into this and would have to
revise their own notes into tutorial and short guides for their peers.
For the veterans, being too close to the development has a disadvantage
of missing out some of "obvious" things
regards
Rahul
18 years, 10 months
Re: FC4 feature list?
by Rahul Sundaram
Hi
>Well, I just mention it as something unclear from both FC3 and FC4 release
>notes. It seems odd that mediacheck would need something to read the disk
>successfully, and yet the real install surely doesn't.
>
>
For my understanding this has to do with faulty cd-rom drives which
refuse to turn off dma even when explicitly instructed to do so by the
kernel.
>Well, the release notes would be a good place to put a (full) link to that
>sort of thing. Especially with the bug or whatever in mediacheck, there
>might be lots of people facing this roadblock when installing on a Windows
>machine, as I did, and I had enough trouble figuring out how to do the more
>mature MD5 checksum stuff.
>
>
We could have this in the download page itself now. I googled this
information after the release notes was made.
>>>
>>>
>>After the installation. Run level really doesnt matter.
>>
>>
>
>!! From the tone, I thought Gnome wouldn't work at all.
>
>
It might not.
>
>
>
>>>6.1.2 Does one need to edit the kernel command line to include audit=1 in
>>>order for auditd to be "enabled by default"? Or is it already enabled, and
>>>"auditing within the kernel" is something else that can also be enabled?
>>>
>>>
>>>
>>>
>>As I understand it, the audit daemon is enabled by default but you need
>>to enable the kernel part of it explicitly (probably due to performance
>>hits) either during boot time (audit =1) or for the session (*auditctl
>>-e 1)*
>>
>>
>
>Hmm. So the audit daemon is running by default but not doing anything.
>
>
>
>
>
>>>6.1.4 Is alocate used by Actions -> Search for Files? (Apparantly yes.)
>>>
>>>
>
>Oops, slocate, meant to fix that.
>
>
>
>>I dont think gnome-search-tool using slocate. It is not a build
>>dependency. It doesnt seem to be linked to the binary (ldd). Its not
>>mentioned in the help file either
>>
>>
>
>I saw it in the FC3 Search for Files help Introduction section: "Search for
>Files uses the find, grep, and locate UNIX commands". Maybe that's not
>slocate, but man locate brought up the slocate man page. Don't know about
>FC4.
>
>
I forgot to mention that my current system is RHEL3 one so things might
be different for the search tool in FC4. Many of these problems could be
avoided by having more people look into it during the test releases(Yes,
they had release notes too) . Some of these are just prioritizing for
lack of time in relation to the amount of work necessary . Filing
detailed bug reports and initiating early discussions would be most
helpful. You could even request CVS access and provide content yourself
for that matter. Thank you for your feedback
regards
Rahul
18 years, 10 months
Re: FC4 feature list?
by Rahul Sundaram
Tony Nelson wrote:
>At 9:01 AM -0700 6/11/05, Karsten Wade wrote:
>
>
>>Content-Type: multipart/signed; micalg=pgp-sha1;
>> protocol="application/pgp-signature";
>> boundary="=-pucgnvM1g3z+Q+ket2ma"
>>
>>On Sat, 2005-06-11 at 00:50 +0530, Rahul Sundaram wrote:
>>
>>
>>
>>>Release notes will be available in an hour or so here:
>>>http://fedora.redhat.com/docs/release-notes/
>>>
>>>
>>It took a little longer than an hour, but the release notes are
>>available now.
>>
>>This is the one that we are releasing in an updated errata, which is the
>>one being translated:
>>
>>http://fedora.redhat.com/docs/release-notes/fc4/errata/
>>
>>
>
>Release notes are good.
>
>As Colin Adams says, the page looks odd unless I select UTF-8.
>
>
This should be fixed soon.
>What is the difference between the release notes and the errata? The pages
>look about the same to me.err
>
>
>
Yes. The errata is provided as a place for important updates after the
release has been made or corrections in it. Currently it does have some
differences if you read it carefully
>Some things in the release notes are unclear. If they should be reported
>somewhere else, someone here will let me know. In any event, I'll learn
>something from the discussion (or flaming).
>
>
The errata release notes provides this link http://tinyurl.com/al5g4 for
filing bug reports. If you would like to initiate a discussion or
provide feedback on the release notes or any other Fedora documentation,
fedora docs list (CC'ing this reply) is the best place now. We might
have a separate list for release notes in the near future but we havent
decided on that yet. I do read this list but this is a high traffic one
and not everyone working on the documentation is subscribed to this list
or following any discussions related to it here.
>1.1 Gnome is now 2.10. I read that wrong for a while, as 2.1.0, and was
>confused. If this is happening much, it might be worth spelling it out as
>well, "two point ten".
>
>
Potentially a good idea. Would have to careful not to overdo it
>5.2 When mediacheck says a disk is faulty, but says it is OK when one
>boots the installer with ide=nodma, should the installation be done with
>ide=nodma or without?
>
>
>
Installation can proceed without this option. Using this option would
probably slow down the installation. Using the sha1sum and burning on
slower speeds is pretty reliable
>How does one use sha1sum? From the installation process, or by booting an
>existing linux installation and running it there? (I.e., from where the
>CDs were burned.)
>
>
same as md5sum. Run it on the ISO image and check this page
http://fedora.redhat.com/download after the release is made. Windows
users could use the following link which also contains the rationale for
switching over to sha1sum from previously used md5sum checks
http://lists.gnupg.org/pipermail/gnupg-ru/2004-December/000158.html
Note: I havent tried the Windows version. There might be better options
out there
>5.3 Re. third party package conflicts during upgrades, does the installer
>detect the problem and warn about it? If not, what is a good way to find
>them before installing, other than remembering every package installed and
>just knowing which ones have conflicts?
>
>
No. The installer overrides it if you have a conflicting package.
Solutions to this are pretty tricky. I would suggest relying on official
repositories whenever possible and check whether your packages are
working properly immediately after the installation. An rpm query on the
packager could potentially be used before or after the installation can
be used to find out which ones arent provided by Fedora. There are other
naming conventions which can be helpful too. As an example Rpmforge
repository using the "rf" tag and dag repository uses "dag" (duh!) for
easy identification.
>Re. Ximian Gnome (which I don't use), when the notes say "immediately" do
>they mean during the installations (when?) or during the first boot (from
>runlevel 3?)?
>
>
After the installation. Run level really doesnt matter.
>6.1.2 Does one need to edit the kernel command line to include audit=1 in
>order for auditd to be "enabled by default"? Or is it already enabled, and
>"auditing within the kernel" is something else that can also be enabled?
>
>
As I understand it, the audit daemon is enabled by default but you need
to enable the kernel part of it explicitly (probably due to performance
hits) either during boot time (audit =1) or for the session (*auditctl
-e 1)*
>6.1.4 Is alocate used by Actions -> Search for Files? (Apparantly yes.)
>
>
I dont think gnome-search-tool using slocate. It is not a build
dependency. It doesnt seem to be linked to the binary (ldd). Its not
mentioned in the help file either
>It seems odd that it isn't enabled by default. I expect that there will be
>much confusion (as well as some disk savings) from this. Hopefully Search
>for Files will automatically inform users of the problem. I think the FC4
>release notes should mention the dependency.
>
>
One of the reasons for disabling slocate cron (updatedb) by default is
that we are currently investigating more intelligent and efficient
methods to do this. See "Audit-layer based slocate replacement" in
Fedora bounties for a feasible alternative
http://fedoraproject.org/wiki/FedoraBounties
>6.2.2.3 Step 1: does up2date --get-source kernel work on FC4? It doesn't
>work for me on FC3, with a 404 Not Found error for some header.info page.
>
>
You are talking about
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=141289. I am not
aware whether it has been fixed in FC4 or not
>Step 3: the command "cd/usr/src/redhat/BUILD/ikernel-<version> /usr/src/"
>seems odd to me, having two directories on it.
>
>
>
Good time for a release notes errata I guess ;-)
regards
Rahul
18 years, 10 months
copyrights of wiki contents
by Yoshihiro Totaka
Hi, I may be wrong to ask this question here (if so I apologise), but I
am wondering about the copyright of wiki contents. Wiki document is
getting more and more popular in fedora document, and I am wondering
whether I am allowed to modify(translate) some of the documents.
Can I assume those document similar to wikipedea's copyrights(GFDL)?
http://en.wikipedia.org/wiki/Wikipedia:Copyrights
--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.322 / Virus Database: 267.4.0 - Release Date: 2005/06/01
18 years, 10 months
CVS problem
by Paul W. Frields
Ahoy there doc'ers,
Elliot had a problem with our CVS organization as-is, and Karsten
thought it was a good idea[1] to float this by the list. He, and
presumably other Fedora developers with similar setups -- and I am
assuming he is not the only one -- need an organization for our included
CVS bits (xsl/, common/, etc.) that is not going to clash with their
other environments.
Elliot suggested simply subordinating these to a separate folder, which
we could name appropriately. Some suggestions included docs-setup/ and
docs-common/. This would mean there would now be docs-setup/xsl/, and
so forth. The Makefile we use would have to be patched appropriately,
of course.
Also at issue is the way people get these bits. When we originally put
up the docs-setup module, the assumption was made that we would not be
changing this stuff very much. However, the last couple of months have
shown that is not the case[2,3], as there have been quite a number of
commits there, including:
* chunking XSL changes
* additional/changed XML entities for:
- legal notice
- draft & legacy notices
- relnotes
* CSS changes for HTML rendering
In light of the pace of these changes, and the fact that there are more
on the horizon, I think we should re-examine requiring people do
separate checkouts of a docs-setup module. I believe Karsten agreed
with me, so he can pitch in here if desired. It would be great if the
docs-setup/ stuff simply came down on the same level with the my-
tutorial/ folder, rather than subordinate (my-tutorial/docs-setup/),
since the latter implies multiple redundant copies for people working on
lots of docs. Focus should be on ease of use for the user (who is not
necessarily a developer), maintainability, and maybe other factors I'm
forgetting.
So, let's open the floor for suggestions and input....
[1] http://www.redhat.com/archives/fedora-dsco-list/2005-
June/msg00011.html
[2] http://www.redhat.com/archives/fedora-docs-commits/2005-
May/thread.html
[3] http://www.redhat.com/archives/fedora-docs-commits/2005-
June/thread.html
--
Paul W. Frields, RHCE http://paul.frields.org/
gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717
Fedora Documentation Project: http://fedora.redhat.com/projects/docs/
18 years, 10 months
Re: Fedora HCL guide writers?
by Philip Johnson
On 6/8/05, Colin Charles <byte(a)aeon.com.my> wrote:
> On Wed, 2005-06-08 at 15:50 +0100, Philip Johnson wrote:
> > I'm currently
> > trying to get ubuntu's hardware collection tool working on Fedora
> > (well actually its sorting out the way it uploads files) and then
> > (hopefully) we should be one step further.
>
> Don't. We're hacking on this one and there are some alternatives. And I
> have patches in ~/code/hwdb now too ;-)
>
> How far have you gotten?
>
:) Fair enough. I haven't really spent *that* much time looking at it.
I played around, changed the head graphic, some of the wording, and I
*think* I had pretty much had sorted out stuff server side (apart from
the parsing of the information into a human readable format - well,
something that's lickable =)).
It's pretty simple code from what I looked at, I just spotted its
output xml file the other day and *dribbled* because it seemed perfect
for.
1. Helping you developer fellows with bugs and what not
2. Building our HCL :).
Overall, I'd say I've only put an hour or twos work in - and that
includes redoing everything I did when I installed ubuntu permanently
on my satellite 1110.
*ducks for cover*
It's really my fault we've ended up doing similar things - I only told
one of the docs guys.
> Off-list for a reason atm... more details to fedora-config-list by start
> of next week
Oki Doki.
> --
> Colin Charles, http://www.bytebot.net/
Regards,
--
Philip Johnson (PlasticMonkey)
18 years, 10 months
Fedora HCL guide writers?
by Chida
Hello,
I always wished I could lookup Fedora HCL before making hardware
purchasing decisions and lack of availability of such a guide pushed
me to googling.
I have a crude list of Fedora HCL that I built from experience. T
18 years, 10 months
Fedora Documentation Bounties
by Stuart Ellis
As you're probably aware, Fedora is participating in Google's Summer of
Code. Below is one provisional bounty specifically for Fedora Docs,
involving screencasting, and we'd like your comments and ideas.
Note that projects don't have to involve heavy-duty coding (see the
library.gnome.org bounty on the GNOME Website). Bounties that can open
participation in Fedora Documentation are particularly valuable. For
example, developing features of Docbook Wiki or a similar system.
We will be posting two or three final Docs bounties on the Fedora page
to maximise potential uptake.
Fedora Bounties - http://www.fedoraproject.org/wiki/FedoraBounties
Google Summer of Code - http://code.google.com/summerofcode.html
GNOME Bounties (Documentation) -
http://www.gnome.org/bounties/Documentation.html
** Demonstrate Screencasting on Fedora **
Video screen capture or "screencasting" has multiple applications for
documentation, training and advocacy.
The challenge is to create a working screencast on a Linux desktop using
Open Source software, in such a way that it can be easily reproduced by
a non-programmer. The file format of the screencast must be playable on
a Windows system using either commonly available or pre-installed plug-
ins.
The twist is that the screencast itself must show the process of
installing Fedora Core with the default options. Your screencast should
begin with the boot screen, and end with logging in to the completed
desktop installation for the first time.
How -
This bounty allows a range of possible solutions.
Virtual machine technologies such as Xen and QEMU may be useful.
Alternatively, the Anaconda installation system itself includes support
for remote access through VNC and telnet, and as well as support for
capturing static screenshots.
Pointers -
Software that might be useful starting points:
Istanbul - http://live.gnome.org/Istanbul
VNC2SWF - http://www.unixuser.org/~euske/vnc2swf/
--
Stuart Ellis
stuart(a)elsn.org
Fedora Documentation Project: http://fedora.redhat.com/projects/docs/
GPG key ID: 7098ABEA
GPG key fingerprint: 68B0 E291 FB19 C845 E60E 9569 292E E365 7098 ABEA
18 years, 10 months