docs June 2005

docs@lists.fedoraproject.org

33 participants
57 discussions

xmlformat licensing
by Paul W. Frields 13 Jun '05

13 Jun '05

(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/

2 7

Re: release-notes/FC4 kernel.xml,1.5,1.6
by Patrick W. Barnes 13 Jun '05

13 Jun '05

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 --

4 6

Re: FC4 feature list?
by Rahul Sundaram 12 Jun '05

12 Jun '05

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

1 0

Re: FC4 feature list?
by Rahul Sundaram 12 Jun '05

12 Jun '05

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

1 0

Re: FC4 feature list?
by Rahul Sundaram 11 Jun '05

11 Jun '05

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

1 0

copyrights of wiki contents
by Yoshihiro Totaka 09 Jun '05

09 Jun '05

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

2 1

CVS problem
by Paul W. Frields 09 Jun '05

09 Jun '05

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/

3 8

Re: Fedora HCL guide writers?
by Philip Johnson 08 Jun '05

08 Jun '05

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)

1 0

Fedora HCL guide writers?
by Chida 08 Jun '05

08 Jun '05

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

4 3

Fedora Documentation Bounties
by Stuart Ellis 07 Jun '05

07 Jun '05

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

1 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

docs June 2005