From stuart at elsn.org Sun Oct 2 17:11:22 2005 From: stuart at elsn.org (Stuart Ellis) Date: Sun, 02 Oct 2005 18:11:22 +0100 Subject: Wiki > DocBook guidelines Message-ID: <1128273082.2770.38.camel@localhost.localdomain> Page is here: http://www.fedoraproject.org/wiki/DocsProject/WritingUsingTheWiki The two issues: - Markup for , , , etc. Following the discussion in the FDSCo meeting I've currently specified monospace (backticks) for all of them. The export renders this as whatever. One advantage of monospace over italics is that it isn't used in other contexts. It also looks more like the final document. - Referencing one document section from another. For want of any better options, I'm inclined to use the name of the document section in monospace here, because it isn't ambiguous for humans. This is an issue for both single page or multiple-page documents. MoinMoin does not seem to support internal section links within a page. Links to other Wiki pages that are also part of the same document become invalid on export. For example, as Wiki: == Understanding the Directory Structure == yada yada ya Refer to ../ManagingStorage for details of how to attach drives and disk partitions to your filesystem. MoinMoin > DocBook conversion:
Understanding the Directory Structure yada yada ya ../ManagingStorage Valid DocBook document: Understanding the Directory Structure yada yada ya Refer to for details of how to attach drives and disk partitions to your filesystem. -- Stuart Ellis stuart at 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From rodrigopadula at sagraluzzatto.com.br Sat Oct 8 14:47:10 2005 From: rodrigopadula at sagraluzzatto.com.br (Rodrigo Padula de Oliveira) Date: Sat, 08 Oct 2005 14:47:10 -0000 Subject: Self-Introduction: Rodrigo Padula de Oliveira Message-ID: <41DFE449.2090503@sagraluzzatto.com.br> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi!!! My name is Rodrigo Padula de Oliveira I'm from Juiz de Fora - Brazil. I am graduated in Information System for the Granbery Methodist College - FMG (http://www.granbery.com.br) Currently I am a member of the translation project of Fedora Core and charter member of the Gunix Linux Group ( http://www.gunix.com.br) , where I wrote diverse tutorials and manuals about Slackware, Gnupg, PostgreSQL, PHP and MySQL. GPG-KEY pub 1024D/C2696745 2004-08-16 Key fingerprint = 9CE1 CF53 2CBC 2BA6 FB64 E940 F1AA D8C6 C269 6745 uid Rodrigo Padula de Oliveira (Webmaster) uid [jpeg image of size 5724] sub 2048g/A366D71B 2004-08-16 - -- +================================================+ RODRIGO PADULA DE OLIVEIRA (o- BACHAREL EM SISTEMAS DE INFORMA??O //\ FACULDADE METODISTA GRANBERY - FMG V_/_ PostgreSQL - PHP - Linux +================================================+ Membro Fundador do Gunix Linux http://www.gunix.com.br -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFB3+RI8arYxsJpZ0URAk8uAKCYdtCYCEsw2X4zEtOMa4CMZ8r6RwCg0PUt QTjwuulemNSI5UsS3A5PCPw= =ztLo -----END PGP SIGNATURE----- From stuart at elsn.org Sun Oct 9 21:47:19 2005 From: stuart at elsn.org (Stuart Ellis) Date: Sun, 09 Oct 2005 22:47:19 +0100 Subject: Request for Review - Fedora Security Basics Message-ID: <1128894439.2795.9.camel@localhost.localdomain> http://www.fedoraproject.org/wiki/SecurityBasics This page is intended as a stopgap to cover the basic stuff until tutorials/Guides are released, in particular the "what about viruses" question that pops up semi-regularly. It deliberately isn't linked to the FAQ or other pages, until it has been sanity checked. -- Stuart Ellis stuart at 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From felipe.alfaro at gmail.com Sun Oct 9 22:58:57 2005 From: felipe.alfaro at gmail.com (Felipe Alfaro Solana) Date: Mon, 10 Oct 2005 00:58:57 +0200 Subject: Request for Review - Fedora Security Basics In-Reply-To: <1128894439.2795.9.camel@localhost.localdomain> References: <1128894439.2795.9.camel@localhost.localdomain> Message-ID: <6f6293f10510091558j7874610esa32f867fa5e16598@mail.gmail.com> > http://www.fedoraproject.org/wiki/SecurityBasics If one of the goals of Fedora Core is being secure right from the start, why is the user allowed to enter single-user without supplying the root password (sulogin)? From tdiehl at rogueind.com Sun Oct 9 23:22:43 2005 From: tdiehl at rogueind.com (Tom Diehl) Date: Sun, 9 Oct 2005 19:22:43 -0400 (EDT) Subject: Request for Review - Fedora Security Basics In-Reply-To: <6f6293f10510091558j7874610esa32f867fa5e16598@mail.gmail.com> References: <1128894439.2795.9.camel@localhost.localdomain> <6f6293f10510091558j7874610esa32f867fa5e16598@mail.gmail.com> Message-ID: On Mon, 10 Oct 2005, Felipe Alfaro Solana wrote: > > http://www.fedoraproject.org/wiki/SecurityBasics > > If one of the goals of Fedora Core is being secure right from the > start, why is the user allowed to enter single-user without supplying > the root password (sulogin)? Because requiring a passwd on a box that you can sit in front of and take apart is STUPID!! All requiring a passwd for single user mode does is make me have to go find a rescue disk. What is the point? If you have physical access to the machine you can get into it. You do not need passwds. Some take a little longer than others. Why make the inevitable harder? Think about windoze, Windoze requires a passwd for safe/recovery mode. All that does for me is make me find my CD case, insert the CD into the drive and boot from the CD. Machine does not have a CD you say OK now I have to go find a CD drive to plug into the machine and my CD case. There is a passwd on the BIOS you say, OK now I have to go find the little jumper on the MB to reset the BIOS to the factory defaults. The above applies to windoze and Linux. It does not matter. Where there is a will there is a way. Regards, Tom Diehl tdiehl at rogueind.com Spamtrap address mtd123 at rogueind.com From stickster at gmail.com Sun Oct 9 23:55:57 2005 From: stickster at gmail.com (Paul W. Frields) Date: Sun, 09 Oct 2005 19:55:57 -0400 Subject: Request for Review - Fedora Security Basics In-Reply-To: References: <1128894439.2795.9.camel@localhost.localdomain> <6f6293f10510091558j7874610esa32f867fa5e16598@mail.gmail.com> Message-ID: <1128902157.5396.1.camel@localhost.localdomain> On Sun, 2005-10-09 at 19:22 -0400, Tom Diehl wrote: > On Mon, 10 Oct 2005, Felipe Alfaro Solana wrote: > > > > http://www.fedoraproject.org/wiki/SecurityBasics > > > > If one of the goals of Fedora Core is being secure right from the > > start, why is the user allowed to enter single-user without supplying > > the root password (sulogin)? > > Because requiring a passwd on a box that you can sit in front of and take apart > is STUPID!! All requiring a passwd for single user mode does is make me have to > go find a rescue disk. What is the point? If you have physical access to the > machine you can get into it. You do not need passwds. Some take a little longer > than others. Why make the inevitable harder? > > Think about windoze, Windoze requires a passwd for safe/recovery mode. All that > does for me is make me find my CD case, insert the CD into the drive and boot > from the CD. Machine does not have a CD you say OK now I have to go find a CD > drive to plug into the machine and my CD case. There is a passwd on the BIOS > you say, OK now I have to go find the little jumper on the MB to reset the BIOS > to the factory defaults. > > The above applies to windoze and Linux. It does not matter. Where there is a > will there is a way. And let's not forget the old standby of simply removing the hard disk, attaching it to another system, and getting at any yummy data that way. Security starts with PHYSICAL security, as any security guru will tell you. If a system is not physically protected from unauthorized access, not much else will be very effective. -- 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/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From sundaram at redhat.com Mon Oct 10 04:12:23 2005 From: sundaram at redhat.com (Rahul Sundaram) Date: Mon, 10 Oct 2005 09:42:23 +0530 Subject: Request for Review - Fedora Security Basics In-Reply-To: <6f6293f10510091558j7874610esa32f867fa5e16598@mail.gmail.com> References: <1128894439.2795.9.camel@localhost.localdomain> <6f6293f10510091558j7874610esa32f867fa5e16598@mail.gmail.com> Message-ID: <4349EA27.5060503@redhat.com> Felipe Alfaro Solana wrote: >>http://www.fedoraproject.org/wiki/SecurityBasics >> >> > >If one of the goals of Fedora Core is being secure right from the >start, why is the user allowed to enter single-user without supplying >the root password (sulogin)? > > > You have no real way to protect someone from getting into to your system if the intruder has physical access. Such questions come up pretty frequently. In general, Fedora systems have good defaults where developers have analyzed and settled upon something or the other. While we explain security in such documents we need to document the other potential ways the system can be configured to be secured better and explain why the defaults are such. Its a given that we want the defaults to be as secure as possible, so we shouldnt be proactive about reporting enhancements to make it as such instead of documenting workarounds wherever possible. There is a hardening guide languishing in CVS for quite sometime. Its better to combine the above documents and make it a comprehensive guide. Security is a huge topic to cover. regards Rahul From sundaram at redhat.com Mon Oct 10 04:14:54 2005 From: sundaram at redhat.com (Rahul Sundaram) Date: Mon, 10 Oct 2005 09:44:54 +0530 Subject: Request for Review - Fedora Security Basics In-Reply-To: <4349EA27.5060503@redhat.com> References: <1128894439.2795.9.camel@localhost.localdomain> <6f6293f10510091558j7874610esa32f867fa5e16598@mail.gmail.com> <4349EA27.5060503@redhat.com> Message-ID: <4349EABE.8090504@redhat.com> Hi > so we shouldnt be proactive about reporting enhancements to make it > as such instead of documenting workarounds wherever possible. Umm. I meant to say we *should* be regards Rahul From felipe.alfaro at gmail.com Mon Oct 10 09:02:45 2005 From: felipe.alfaro at gmail.com (Felipe Alfaro Solana) Date: Mon, 10 Oct 2005 11:02:45 +0200 Subject: Request for Review - Fedora Security Basics In-Reply-To: <4349EA27.5060503@redhat.com> References: <1128894439.2795.9.camel@localhost.localdomain> <6f6293f10510091558j7874610esa32f867fa5e16598@mail.gmail.com> <4349EA27.5060503@redhat.com> Message-ID: <6f6293f10510100202r7b011b61y3f3f7fc96063412@mail.gmail.com> > You have no real way to protect someone from getting into to your system > if the intruder has physical access. Such questions come up pretty > frequently. In general, Fedora systems have good defaults where > developers have analyzed and settled upon something or the other. While > we explain security in such documents we need to document the other > potential ways the system can be configured to be secured better and > explain why the defaults are such. Its a given that we want the > defaults to be as secure as possible, so we should be proactive about > reporting enhancements to make it as such instead of documenting > workarounds wherever possible. I agree that having physical access to the machine could make easy for an intruder to get into it, but sometimes the intruder has limited physical access, that is, the intruder can't steal the hard drive or the machine, only sit at the keyboard, restart the machine into single-user mode and reset the root password (and yes, I know I we can use a GRUB password). I think the "you've got physical access, you're lost" sentence is not a reason enough not to modify "/etc/inittab" and put "sulogin" for singleuser. Other distros do it and I really appreciate this extra level of security. It's not usually a burden for a legit sysadmin, and it makes a little bit more difficult to get root access for non authorized people. From felipe.alfaro at gmail.com Mon Oct 10 09:06:00 2005 From: felipe.alfaro at gmail.com (Felipe Alfaro Solana) Date: Mon, 10 Oct 2005 11:06:00 +0200 Subject: Request for Review - Fedora Security Basics In-Reply-To: <1128902157.5396.1.camel@localhost.localdomain> References: <1128894439.2795.9.camel@localhost.localdomain> <6f6293f10510091558j7874610esa32f867fa5e16598@mail.gmail.com> <1128902157.5396.1.camel@localhost.localdomain> Message-ID: <6f6293f10510100206v5aac4a77kaa6f2b8efb993776@mail.gmail.com> > And let's not forget the old standby of simply removing the hard disk, > attaching it to another system, and getting at any yummy data that way. > Security starts with PHYSICAL security, as any security guru will tell > you. If a system is not physically protected from unauthorized access, > not much else will be very effective. That's a valid point, tought some intruders don't want to steal the machine or the hard drive, as that would make the attack extremely evident. Instead, it's easier to break into single-user mode and create a user account used to remotely access the machine by any other means. From tsekine at sdri.co.jp Mon Oct 10 09:34:32 2005 From: tsekine at sdri.co.jp (SEKINE tatz Tatsuo) Date: Mon, 10 Oct 2005 19:34:32 +1000 (EST) Subject: Request for Review - Fedora Security Basics In-Reply-To: <6f6293f10510100202r7b011b61y3f3f7fc96063412@mail.gmail.com> References: <6f6293f10510091558j7874610esa32f867fa5e16598@mail.gmail.com> <4349EA27.5060503@redhat.com> <6f6293f10510100202r7b011b61y3f3f7fc96063412@mail.gmail.com> Message-ID: <20051010.193432.13087757.tsekine@sdri.co.jp> From: Felipe Alfaro Solana Date: Mon, 10 Oct 2005 11:02:45 +0200 > I agree that having physical access to the machine could make easy for > an intruder to get into it, but sometimes the intruder has limited > physical access, that is, the intruder can't steal the hard drive or > the machine, only sit at the keyboard, restart the machine into > single-user mode and reset the root password (and yes, I know I we can > use a GRUB password). If the GRUB password isn't used to protect the machine, the boot parameter is editable. In that case, the intruder can alternate "init" program with /bin/sh, putting "init=/bin/sh" into the boot parameter. It means that modified /etc/inittab can not protect the machine because the file is read by /sbin/init (default "init" programme). -- SEKINE Tatsuo: tsekine at sdri.co.jp System Design & Research Inst. Co.,Ltd. From stickster at gmail.com Mon Oct 10 12:12:44 2005 From: stickster at gmail.com (Paul W. Frields) Date: Mon, 10 Oct 2005 08:12:44 -0400 Subject: Request for Review - Fedora Security Basics In-Reply-To: <20051010.193432.13087757.tsekine@sdri.co.jp> References: <6f6293f10510091558j7874610esa32f867fa5e16598@mail.gmail.com> <4349EA27.5060503@redhat.com> <6f6293f10510100202r7b011b61y3f3f7fc96063412@mail.gmail.com> <20051010.193432.13087757.tsekine@sdri.co.jp> Message-ID: <1128946365.2941.7.camel@localhost.localdomain> On Mon, 2005-10-10 at 19:34 +1000, SEKINE tatz Tatsuo wrote: > From: Felipe Alfaro Solana > Date: Mon, 10 Oct 2005 11:02:45 +0200 > > > I agree that having physical access to the machine could make easy for > > an intruder to get into it, but sometimes the intruder has limited > > physical access, that is, the intruder can't steal the hard drive or > > the machine, only sit at the keyboard, restart the machine into > > single-user mode and reset the root password (and yes, I know I we can > > use a GRUB password). > > If the GRUB password isn't used to protect the machine, the > boot parameter is editable. > > In that case, the intruder can alternate "init" program with > /bin/sh, putting "init=/bin/sh" into the boot parameter. It > means that modified /etc/inittab can not protect the machine > because the file is read by /sbin/init (default "init" > programme). Right. I think the point, Felipe, is that adding a password to single-user mode gives the admin a *FALSE* sense of security. If you need that level of security, you need MORE than that amount of security, if you get my meaning. The only acceptable alternative is to physically secure the machine. This might be a locked room or a locked rack. If the security of a machine is a concern, no unauthorized person should be able to just walk up to it and reboot it. I would think, however, that this sort of topic, and additional security measures, could and should be covered in a more comprehensive security guide. As Rahul mentioned, there is a Hardening Tutorial in CVS. Maybe you should offer to participate with the author to bring this document up to snuff. As I recall, no editor has yet stepped up to work on it. Stuart has started some security material on the wiki as well. Instead of having several efforts floating around in various forms, maybe the three of you (Stuart, Felipe, and Charles Heselton, author of the hardening tutorial) can put your heads *together* and work on something more comprehensive! Three heads are better than one, and all that... -- 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/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From felipe.alfaro at gmail.com Mon Oct 10 12:19:40 2005 From: felipe.alfaro at gmail.com (Felipe Alfaro Solana) Date: Mon, 10 Oct 2005 14:19:40 +0200 Subject: Request for Review - Fedora Security Basics In-Reply-To: <1128946365.2941.7.camel@localhost.localdomain> References: <6f6293f10510091558j7874610esa32f867fa5e16598@mail.gmail.com> <4349EA27.5060503@redhat.com> <6f6293f10510100202r7b011b61y3f3f7fc96063412@mail.gmail.com> <20051010.193432.13087757.tsekine@sdri.co.jp> <1128946365.2941.7.camel@localhost.localdomain> Message-ID: <6f6293f10510100519k10b34a37we12dbd0e8ec83bf3@mail.gmail.com> > I would think, however, that this sort of topic, and additional security > measures, could and should be covered in a more comprehensive security > guide. As Rahul mentioned, there is a Hardening Tutorial in CVS. Maybe > you should offer to participate with the author to bring this document > up to snuff. As I recall, no editor has yet stepped up to work on it. > Stuart has started some security material on the wiki as well. Instead > of having several efforts floating around in various forms, maybe the > three of you (Stuart, Felipe, and Charles Heselton, author of the > hardening tutorial) can put your heads *together* and work on something > more comprehensive! Three heads are better than one, and all that... I would like to add my few cents but sincerely, I don't know where to start, or what to do. I have a few recommendations, in form of firewall rules and sysctl tunable parameters. From tdiehl at rogueind.com Mon Oct 10 15:51:52 2005 From: tdiehl at rogueind.com (Tom Diehl) Date: Mon, 10 Oct 2005 11:51:52 -0400 (EDT) Subject: Request for Review - Fedora Security Basics In-Reply-To: <6f6293f10510100206v5aac4a77kaa6f2b8efb993776@mail.gmail.com> References: <1128894439.2795.9.camel@localhost.localdomain> <6f6293f10510091558j7874610esa32f867fa5e16598@mail.gmail.com> <1128902157.5396.1.camel@localhost.localdomain> <6f6293f10510100206v5aac4a77kaa6f2b8efb993776@mail.gmail.com> Message-ID: On Mon, 10 Oct 2005, Felipe Alfaro Solana wrote: > > And let's not forget the old standby of simply removing the hard disk, > > attaching it to another system, and getting at any yummy data that way. > > Security starts with PHYSICAL security, as any security guru will tell > > you. If a system is not physically protected from unauthorized access, > > not much else will be very effective. > > That's a valid point, tought some intruders don't want to steal the > machine or the hard drive, as that would make the attack extremely > evident. Instead, it's easier to break into single-user mode and > create a user account used to remotely access the machine by any other > means. If it bothers you that much put a passwd on grub. It buys you the same thing. That way it does not cause extra work for people who do not want/need it. Regards, Tom Diehl tdiehl at rogueind.com Spamtrap address mtd123 at rogueind.com From sundaram at redhat.com Mon Oct 10 16:16:17 2005 From: sundaram at redhat.com (Rahul Sundaram) Date: Mon, 10 Oct 2005 21:46:17 +0530 Subject: Request for Review - Fedora Security Basics In-Reply-To: <6f6293f10510100519k10b34a37we12dbd0e8ec83bf3@mail.gmail.com> References: <6f6293f10510091558j7874610esa32f867fa5e16598@mail.gmail.com> <4349EA27.5060503@redhat.com> <6f6293f10510100202r7b011b61y3f3f7fc96063412@mail.gmail.com> <20051010.193432.13087757.tsekine@sdri.co.jp> <1128946365.2941.7.camel@localhost.localdomain> <6f6293f10510100519k10b34a37we12dbd0e8ec83bf3@mail.gmail.com> Message-ID: <434A93D1.70304@redhat.com> Felipe Alfaro Solana wrote: >>I would think, however, that this sort of topic, and additional security >>measures, could and should be covered in a more comprehensive security >>guide. As Rahul mentioned, there is a Hardening Tutorial in CVS. Maybe >>you should offer to participate with the author to bring this document >>up to snuff. As I recall, no editor has yet stepped up to work on it. >>Stuart has started some security material on the wiki as well. Instead >>of having several efforts floating around in various forms, maybe the >>three of you (Stuart, Felipe, and Charles Heselton, author of the >>hardening tutorial) can put your heads *together* and work on something >>more comprehensive! Three heads are better than one, and all that... >> >> > >I would like to add my few cents but sincerely, I don't know where to >start, or what to do. I have a few recommendations, in form of >firewall rules and sysctl tunable parameters. > > > The instructions on getting the relevant docs from cvs and more details on getting started is available from the project pages http://fedora.redhat.com/projects/docs/ The docs team is also working on a stage area to build such docs automatically on a regular basis in the near future. You can also use the wiki for drafts http://fedoraproject.org/wiki/Docs/Drafts http://fedoraproject.org/wiki/WikiEditing If you need edit group access, register in the wiki and let me know your username offlist. regards Rahul From sundaram at redhat.com Mon Oct 10 16:19:36 2005 From: sundaram at redhat.com (Rahul Sundaram) Date: Mon, 10 Oct 2005 21:49:36 +0530 Subject: Request for Review - Fedora Security Basics In-Reply-To: <6f6293f10510100206v5aac4a77kaa6f2b8efb993776@mail.gmail.com> References: <1128894439.2795.9.camel@localhost.localdomain> <6f6293f10510091558j7874610esa32f867fa5e16598@mail.gmail.com> <1128902157.5396.1.camel@localhost.localdomain> <6f6293f10510100206v5aac4a77kaa6f2b8efb993776@mail.gmail.com> Message-ID: <434A9498.9000406@redhat.com> Felipe Alfaro Solana wrote: >>And let's not forget the old standby of simply removing the hard disk, >>attaching it to another system, and getting at any yummy data that way. >>Security starts with PHYSICAL security, as any security guru will tell >>you. If a system is not physically protected from unauthorized access, >>not much else will be very effective. >> >> > >That's a valid point, tought some intruders don't want to steal the >machine or the hard drive, as that would make the attack extremely >evident. Instead, it's easier to break into single-user mode and >create a user account used to remotely access the machine by any other >means. > > > Your concern is addressed by using the installer option to setup grub passwords. The hassle for users while they attempt a recovery seem to outweight the limited security advantage. regards Rahul From stickster at gmail.com Mon Oct 10 16:20:15 2005 From: stickster at gmail.com (Paul W. Frields) Date: Mon, 10 Oct 2005 12:20:15 -0400 Subject: Request for Review - Fedora Security Basics In-Reply-To: <6f6293f10510100519k10b34a37we12dbd0e8ec83bf3@mail.gmail.com> References: <6f6293f10510091558j7874610esa32f867fa5e16598@mail.gmail.com> <4349EA27.5060503@redhat.com> <6f6293f10510100202r7b011b61y3f3f7fc96063412@mail.gmail.com> <20051010.193432.13087757.tsekine@sdri.co.jp> <1128946365.2941.7.camel@localhost.localdomain> <6f6293f10510100519k10b34a37we12dbd0e8ec83bf3@mail.gmail.com> Message-ID: <1128961215.3016.3.camel@localhost.localdomain> On Mon, 2005-10-10 at 14:19 +0200, Felipe Alfaro Solana wrote: > > I would think, however, that this sort of topic, and additional security > > measures, could and should be covered in a more comprehensive security > > guide. As Rahul mentioned, there is a Hardening Tutorial in CVS. Maybe > > you should offer to participate with the author to bring this document > > up to snuff. As I recall, no editor has yet stepped up to work on it. > > Stuart has started some security material on the wiki as well. Instead > > of having several efforts floating around in various forms, maybe the > > three of you (Stuart, Felipe, and Charles Heselton, author of the > > hardening tutorial) can put your heads *together* and work on something > > more comprehensive! Three heads are better than one, and all that... > > I would like to add my few cents but sincerely, I don't know where to > start, or what to do. I have a few recommendations, in form of > firewall rules and sysctl tunable parameters. Feel free to email the authors and discuss with them, or use this list. The Wiki is a very easy way to contribute; just start by going to http://fedoraproject.org/wiki/ and make an account for yourself if you don't have one yet. The important thing is to get involved! That's what the Fedora community is all about. -- 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/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From esm at logic.net Mon Oct 10 18:48:25 2005 From: esm at logic.net (esm at logic.net) Date: Mon, 10 Oct 2005 13:48:25 -0500 Subject: Request for Review - Fedora Security Basics In-Reply-To: References: <1128894439.2795.9.camel@localhost.localdomain> <6f6293f10510091558j7874610esa32f867fa5e16598@mail.gmail.com> Message-ID: <20051010184824.GB11806@talus.logic.net> On Sun, Oct 09, 2005 at 07:22:43PM -0400, Tom Diehl wrote: > Because requiring a passwd on a box that you can sit in front of and take > apart is STUPID!! Invalid assumption; one can have access to the console without having direct physical access. Think IP-based KVMs, where you can go so far as being able to power cycle a system without being able to put hands on the machine. Serial consoles are a similar situation. Requiring a password for single-user login allows for a breach of KVM or serial console server security without opening the attached systems to attack. Grub passwords only solve half the problem (modification or misuse of the bootloader); single-user passwords prevent the attacker from taking advantage of a hardware fault (perhaps one that they triggered). Both are necessary to properly secure the boot process when the console can be reached over a network or from a shared/less-secured console area. Granted, this is only an issue for data-center environments generally. I just wanted to point it out as a use case that I'm familiar with. -- Edward S. Marshall http://esm.logic.net/ Felix qui potuit rerum cognoscere causas. From tdiehl at rogueind.com Mon Oct 10 20:06:41 2005 From: tdiehl at rogueind.com (Tom Diehl) Date: Mon, 10 Oct 2005 16:06:41 -0400 (EDT) Subject: Request for Review - Fedora Security Basics In-Reply-To: <20051010184824.GB11806@talus.logic.net> References: <1128894439.2795.9.camel@localhost.localdomain> <6f6293f10510091558j7874610esa32f867fa5e16598@mail.gmail.com> <20051010184824.GB11806@talus.logic.net> Message-ID: On Mon, 10 Oct 2005 esm at logic.net wrote: > On Sun, Oct 09, 2005 at 07:22:43PM -0400, Tom Diehl wrote: > > Because requiring a passwd on a box that you can sit in front of and take > > apart is STUPID!! > > Invalid assumption; one can have access to the console without having > direct physical access. Think IP-based KVMs, where you can go so far as > being able to power cycle a system without being able to put hands on the > machine. Serial consoles are a similar situation. Well, I will admit I had not thought of that case. :-) In that case they can still play with grub and bypass the root passwd at boot time, so how does that help? I am sure we could argue different corner cases on this forever. :-) I hope you will agree this is a corner case though. > > Requiring a password for single-user login allows for a breach of KVM or > serial console server security without opening the attached systems to > attack. Grub passwords only solve half the problem (modification or misuse > of the bootloader); single-user passwords prevent the attacker from taking > advantage of a hardware fault (perhaps one that they triggered). Both are > necessary to properly secure the boot process when the console can be > reached over a network or from a shared/less-secured console area. How does a grub passwd not solve the problem. As someone else already mentioned if you can modify the bootloader you can run init=/bin/sh from the grub command line and bypass the passwd checks anyway. > Granted, this is only an issue for data-center environments generally. I > just wanted to point it out as a use case that I'm familiar with. But in a data center environment you already control who is sitting in front of the console. If you do not then you have other problems. I will admit that there are exceptions to every rule but in the majority of cases booting to RL 1 without a passwd is the least of your problems, if you are worried about security. My whole point to this goes back to the original concept of "If you have physical access to the machine it is not secure" I will argue that a grub passwd does more to protect from the casual user trying to gain root access, than requiring a passwd for RL-1. It is just too easy to bypass. If as others have argued the would be cracker only has access to the console but no access to the physical machine then a grub passwd or simply disabling is the way to go. If they can't reboot it they will never see grub to play with it. Regards, Tom Diehl tdiehl at rogueind.com Spamtrap address mtd123 at rogueind.com From rostetter at mail.utexas.edu Mon Oct 10 20:51:33 2005 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Mon, 10 Oct 2005 15:51:33 -0500 Subject: Request for Review - Fedora Security Basics In-Reply-To: <20051010184824.GB11806@talus.logic.net> References: <1128894439.2795.9.camel@localhost.localdomain> <6f6293f10510091558j7874610esa32f867fa5e16598@mail.gmail.com> <20051010184824.GB11806@talus.logic.net> Message-ID: <1128977493.3576155ca71b4@mail.ph.utexas.edu> Quoting esm at logic.net: > On Sun, Oct 09, 2005 at 07:22:43PM -0400, Tom Diehl wrote: > > Because requiring a passwd on a box that you can sit in front of and take > > apart is STUPID!! > > Invalid assumption; one can have access to the console without having > direct physical access. Think IP-based KVMs, where you can go so far as > being able to power cycle a system without being able to put hands on the > machine. Serial consoles are a similar situation. Or a machine in a lab, where the machines are on a security loop that prevents the opening of the case without an alarm going off... > Granted, this is only an issue for data-center environments generally. I > just wanted to point it out as a use case that I'm familiar with. There are many others. Once upon a time, almost no unix needed a root password for single user mode. Then suddenly, most versions added that feature. Do you think they would add the feature if there wasn't any reason or need for it? -- Eric Rostetter From rostetter at mail.utexas.edu Mon Oct 10 21:07:18 2005 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Mon, 10 Oct 2005 16:07:18 -0500 Subject: Request for Review - Fedora Security Basics In-Reply-To: References: <1128894439.2795.9.camel@localhost.localdomain> <6f6293f10510091558j7874610esa32f867fa5e16598@mail.gmail.com> <20051010184824.GB11806@talus.logic.net> Message-ID: <1128978438.5ade068266450@mail.ph.utexas.edu> Quoting Tom Diehl : > Well, I will admit I had not thought of that case. :-) In that case they can > still play with grub and bypass the root passwd at boot time, so how does > that help? > > I am sure we could argue different corner cases on this forever. :-) I hope > you will agree this is a corner case though. Since there are likely to be multiple such cases, why discount them? > How does a grub passwd not solve the problem. As someone else already > mentioned > if you can modify the bootloader you can run init=/bin/sh from the grub > command > line and bypass the passwd checks anyway. If you want to limit the discussion to only machines running grub, then the argument becomes somewhat easier. But maybe some people want the docs to pertain to alternative boot loaders also? Maybe not... I don't know the scope of the doc myself. But, there is of course always the defense in depth argument. Always use as many layers of defense as you can. Say they manage to somehow know your grub password (they watched you type it, it was easy to guess, they used to be an employee of yours and you didn't change it since they left, etc). But if they don't also know the root password, then the defense in depth strategy stops them. Your strategy (rely only on grub) does not stop them. > But in a data center environment you already control who is sitting in front > of the console. No, you don't. Someone can come in (janitor, repair man, someone who was able to social-engineer his way in, someone who broke in, etc) who isn't supposed to. And can you really trust all your employees anyway? > If you do not then you have other problems. We all have problems... > My whole point to this goes back to the original concept of "If you have > physical access to the machine it is not secure" I will argue that a grub My whole point is we can make it as secure as possible by using the security in depth principal, to cover all cases. Sometimes (a university computer lab) we let people have physical access to the machine, but we still want to keep them from playing with it as root, to the best extent possible. So, we disable the power button, put on a bios password, disable booting from external media, put a grub/lilo/milo/etc. password on, put a single user password on, put an alarm on the system that prevents opening the case without the alarm going off, etc. Now, what if you *forget* to do one of those? Don't you want a backup to be there? I'm not perfect, and it is possible someday I might make a mistake and accidently leave one of the above security features disabled after working on a machine. I'd like to think that I've got additional backup security methods in place to help protect me even if I do mess up one of them. (yeah, if I mess up too many, I'm hosed, but...) > passwd does more to protect from the casual user trying to gain root access, > than requiring a passwd for RL-1. It is just too easy to bypass. If as others > have argued the would be cracker only has access to the console but no access > to the physical machine then a grub passwd or simply disabling > > is the way to go. But what if an upgrade, or a new admin who doesn't know better, accidently enables on it? What then? > If they can't reboot it they will never see grub to play > with > it. Uhm, what if they just pull the power cord? Or trip the breaker? Or find a way to short it out. Or there is a power outage in the building. Or... > Regards, > > Tom Diehl tdiehl at rogueind.com Spamtrap address mtd123 at rogueind.com -- Eric Rostetter From green at redhat.com Tue Oct 11 00:35:09 2005 From: green at redhat.com (Anthony Green) Date: Mon, 10 Oct 2005 17:35:09 -0700 Subject: Self Introduction: Anthony Green Message-ID: <1128990910.3243.11.camel@localhost.localdomain> Date: Mon, 10 Oct 2005 13:22:19 -0700 Hello, my name is Anthony Green. I currently live in Menlo Park, CA, USA. I work in Runtime and Embedded Sales for Red Hat. I'd like to help write the "Java" section of the FC Release Notes. I can commit to getting the content right, but would appreciate some editing help (grammar, spelling, etc). I'm qualified to help write this documentation because of my long history with the gcj project, which forms the core of FC's "Java"-like offering. pub 1024D/8E2F07F0 2005-09-02 Key fingerprint = 87F4 E1FA FCE4 13A4 FDCB 3A04 5025 EA2C 8E2F 07F0 uid Anthony Green sub 2048g/4BF9E433 2005-09-02 AG From stickster at gmail.com Tue Oct 11 11:32:37 2005 From: stickster at gmail.com (Paul W. Frields) Date: Tue, 11 Oct 2005 07:32:37 -0400 Subject: Self Introduction: Anthony Green In-Reply-To: <1128990910.3243.11.camel@localhost.localdomain> References: <1128990910.3243.11.camel@localhost.localdomain> Message-ID: <1129030357.2950.2.camel@localhost.localdomain> On Mon, 2005-10-10 at 17:35 -0700, Anthony Green wrote: > Hello, my name is Anthony Green. I currently live in Menlo Park, CA, > USA. > > I work in Runtime and Embedded Sales for Red Hat. > > I'd like to help write the "Java" section of the FC Release Notes. I > can commit to getting the content right, but would appreciate some > editing help (grammar, spelling, etc). > > I'm qualified to help write this documentation because of my long > history with the gcj project, which forms the core of FC's "Java"-like > offering. > > pub 1024D/8E2F07F0 2005-09-02 > Key fingerprint = 87F4 E1FA FCE4 13A4 FDCB 3A04 5025 EA2C 8E2F 07F0 > uid Anthony Green > sub 2048g/4BF9E433 2005-09-02 Welcome Anthony! We appreciate all assistance, and don't worry, we will help out with the editing as needed. If you can commit to taking that beat for the Release Notes, just get a wiki account at http://fedoraproject.org/wiki/ and let us know when you have it. Someone here will add you to the EditGroup and fill your name in for the Java beat. Thanks for volunteering, and we look forward to working with you. -- 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/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From green at redhat.com Tue Oct 11 13:37:54 2005 From: green at redhat.com (Anthony Green) Date: Tue, 11 Oct 2005 06:37:54 -0700 Subject: Self Introduction: Anthony Green In-Reply-To: <1129030357.2950.2.camel@localhost.localdomain> References: <1128990910.3243.11.camel@localhost.localdomain> <1129030357.2950.2.camel@localhost.localdomain> Message-ID: <1129037875.3243.82.camel@localhost.localdomain> On Tue, 2005-10-11 at 07:32 -0400, Paul W. Frields wrote: > If you can commit to taking that > beat for the Release Notes, just get a wiki account at > http://fedoraproject.org/wiki/ and let us know when you have it. Done. AG From stickster at gmail.com Tue Oct 11 14:33:56 2005 From: stickster at gmail.com (Paul W. Frields) Date: Tue, 11 Oct 2005 10:33:56 -0400 Subject: Self Introduction: Anthony Green In-Reply-To: <1129037875.3243.82.camel@localhost.localdomain> References: <1128990910.3243.11.camel@localhost.localdomain> <1129030357.2950.2.camel@localhost.localdomain> <1129037875.3243.82.camel@localhost.localdomain> Message-ID: <1129041236.2950.15.camel@localhost.localdomain> On Tue, 2005-10-11 at 06:37 -0700, Anthony Green wrote: > On Tue, 2005-10-11 at 07:32 -0400, Paul W. Frields wrote: > > If you can commit to taking that > > beat for the Release Notes, just get a wiki account at > > http://fedoraproject.org/wiki/ and let us know when you have it. > > Done. Your account name's AnthonyGreen, right? You're now in the EditGroup. -- 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/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From stickster at gmail.com Tue Oct 11 22:02:11 2005 From: stickster at gmail.com (Paul W. Frields) Date: Tue, 11 Oct 2005 18:02:11 -0400 Subject: CVSROOT avail,1.13,1.14 In-Reply-To: <1128093026.5399.19.camel@localhost.localdomain> References: <200509282221.j8SMLYIP018948@cvs-int.fedora.redhat.com> <1127947434.2944.11.camel@localhost.localdomain> <1128093026.5399.19.camel@localhost.localdomain> Message-ID: <1129068131.4381.7.camel@localhost.localdomain> Seth and Ray, Referencing reply from Ray to me and other CC's... > > Ha! Just republishing as UTF-8 for now. But this would be the right > > place to canonize what's on the Wiki for posterity, methinks. > > > > Call to a few select RH'ers... Do you think the maintainers of > > redhat-menus (hopefully I hit at least one of them on the CC list above) > > would have a problem issuing an update that puts the "Documentation" > > directory back in the menu system? > > I think this is a question for Seth. I'll defer to him. If he thinks > it's a good idea, then we can figure something out. > > > I can't seem to figure out a graceful way of adding our stuff into the > > Main Menu without it -- it just ends up in "Other" when I use the > > "Documentation" category, and I haven't been able to figure out how to > > make a drop-file for /etc/xdg/menus/applications-merged/ to make this > > work. If either of them had input, that would be great, even if that > > input is "you're an idiot, here's the drop file you need." (The first > > part all by itself is not as helpful, probably.) > > There might be a way, I'd have to investigate. Mark, do you know? Any indicators on this issue? Filed bug to track: https://bugzilla.redhat.com/169627 -- 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/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From stickster at gmail.com Tue Oct 11 22:36:27 2005 From: stickster at gmail.com (Paul W. Frields) Date: Tue, 11 Oct 2005 18:36:27 -0400 Subject: Minutes FDSCo 11 Oct 2005 Message-ID: <1129070187.4381.21.camel@localhost.localdomain> Canonical schedule and tasks: http://fedoraproject.org/wiki/DocsProject/FedoraDocsSchedule Summary of Updates and New Tasks: ================================= * Gavin will send emails this week soliciting beat writers and general contributors to the wiki (and possibly CVS). Some of these writers will hopefully help with the burgeoning need for guidebooks which are currently being drafted on the wiki. * New contributors should probably submit a CLA via https://admin.fedora.redhat.com/accounts/ so they understand legal requirements on Fedora work, even for docs. Docs work should also be free of legal encumbrance. * Stuart and others continue to be available on #fedora-wiki to help new contributors. Stuart has posted his hours of availability at http://fedoraproject.org/wiki/StuartEllis * Paul has drafted packaging scripts in the example-tutorial CVS module. He is still working on the fedora-doc-common RPM build, as well as word from the redhat-menus maintainers on adding a "Documentation" menu back into Fedora. (This menu does not supersede yelp/khelpviewer.) He will need help (Tommy?) in making the Makefile additions i18n-compatible. * Stuart and Paul will start sweeping out old bug cruft where possible. Attending: ========== Gavin Henry (G2) Tammy Fox (tcf) Stuart Ellis (elliss) Paul W. Frields (stickster) -- 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/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From stuart at elsn.org Tue Oct 11 23:10:00 2005 From: stuart at elsn.org (Stuart Ellis) Date: Wed, 12 Oct 2005 00:10:00 +0100 Subject: Test of Docs Packaging Message-ID: <1129072200.3562.16.camel@localhost.localdomain> Just to confirm that I've now tried the packaging for example-tutorial, and got the expected result :) On a standard FC4 system: - yum install rpm-build - cvs up docs-common - cvs up example-tutorial - cd example-tutorial/ - make rpm Produces: fedora-doc-example-tutorial-0.14-1.noarch.rpm containing .xml, .omf, and .desktop files. - sudo rpm -ivh fedora-doc-example-tutorial-0.14-1.noarch.rpm Produces: error: Failed dependencies: fedora-doc-common is needed by fedora-doc-example-tutorial-0.14-1.noarch -- Stuart Ellis stuart at 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From ghenry at suretecsystems.com Wed Oct 12 12:06:47 2005 From: ghenry at suretecsystems.com (Gavin Henry) Date: Wed, 12 Oct 2005 13:06:47 +0100 (BST) Subject: Minutes FDSCo 11 Oct 2005 In-Reply-To: <1129070187.4381.21.camel@localhost.localdomain> References: <1129070187.4381.21.camel@localhost.localdomain> Message-ID: <50148.195.38.86.72.1129118807.squirrel@webmail.suretecsystems.com> > Canonical schedule and tasks: > > http://fedoraproject.org/wiki/DocsProject/FedoraDocsSchedule > > Summary of Updates and New Tasks: > ===============================* Gavin will send emails this week > soliciting beat writers and general > contributors to the wiki (and possibly CVS) Shall I do this in the same format as last time, or do we have any key points to put across on how "easy" it will be to help? . Some of these writers will > hopefully help with the burgeoning need for guidebooks which are > currently being drafted on the wiki. Hope so. > > * New contributors should probably submit a CLA via > https://admin.fedora.redhat.com/accounts/ so they understand legal > requirements on Fedora work, even for docs. Docs work should also be > free of legal encumbrance. I'll also add them to the docs wiki list this week too. > > * Stuart and others continue to be available on #fedora-wiki to help new > contributors. Stuart has posted his hours of availability at > http://fedoraproject.org/wiki/StuartEllis Must have missed this channel, I'll add it to my favourites. > > * Paul has drafted packaging scripts in the example-tutorial CVS module. > He is still working on the fedora-doc-common RPM build, as well as word > from the redhat-menus maintainers on adding a "Documentation" menu back > into Fedora. (This menu does not supersede yelp/khelpviewer.) He will > need help (Tommy?) in making the Makefile additions i18n-compatible. > > * Stuart and Paul will start sweeping out old bug cruft where possible. > > > Attending: > =========Gavin Henry (G2) > Tammy Fox (tcf) > Stuart Ellis (elliss) > Paul W. Frields (stickster) > > -- > 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/ > -- > fedora-docs-list mailing list > fedora-docs-list at redhat.com > To unsubscribe: > https://www.redhat.com/mailman/listinfo/fedora-docs-list From stickster at gmail.com Wed Oct 12 15:12:58 2005 From: stickster at gmail.com (Paul W. Frields) Date: Wed, 12 Oct 2005 11:12:58 -0400 Subject: CVSROOT avail,1.13,1.14 In-Reply-To: <1129124796.3861.6.camel@blaa> References: <200509282221.j8SMLYIP018948@cvs-int.fedora.redhat.com> <1127947434.2944.11.camel@localhost.localdomain> <1128093026.5399.19.camel@localhost.localdomain> <1129068131.4381.7.camel@localhost.localdomain> <1129124796.3861.6.camel@blaa> Message-ID: <1129129979.4681.6.camel@localhost.localdomain> On Wed, 2005-10-12 at 09:46 -0400, Mark McLoughlin wrote: > On Tue, 2005-10-11 at 18:02 -0400, Paul W. Frields wrote: > > > > I can't seem to figure out a graceful way of adding our stuff into the > > > > Main Menu without it -- it just ends up in "Other" when I use the > > > > "Documentation" category, and I haven't been able to figure out how to > > > > make a drop-file for /etc/xdg/menus/applications-merged/ to make this > > > > work. If either of them had input, that would be great, even if that > > > > input is "you're an idiot, here's the drop file you need." (The first > > > > part all by itself is not as helpful, probably.) > > > > > > There might be a way, I'd have to investigate. Mark, do you know? > > > > Any indicators on this issue? Filed bug to track: > > > > https://bugzilla.redhat.com/169627 > > I thought I'd replied to this already, maybe not. I've replied in the > bug now. Thanks to Mark correcting my ill-fated attempts to drop in a docs menu, we're in business. The docs-common module is updated and if you "make rpm" from that module and the example-tutorial module, you'll be able to install both on your system and see a Documentation menu magically appear! As mentioned before, yelp and khelpviewer will also see these docs through scrollkeeper, but they are not as easy to find. Currently the menu entry just calls "gnome-help ", but this will be replaced with "fedora-docviewer ," which will point to a script that will figure out which viewer is proper for the user's desktop environment, and set the URI accordingly. Any assistance here would be gratefully accepted. I think Mr. Laska is going to help me clean up these ugly Makefiles, at which point they will be incorporated properly into Makefile.common as necessary. -- 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/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From stickster at gmail.com Wed Oct 12 12:41:17 2005 From: stickster at gmail.com (Paul W. Frields) Date: Wed, 12 Oct 2005 08:41:17 -0400 Subject: Minutes FDSCo 11 Oct 2005 In-Reply-To: <50148.195.38.86.72.1129118807.squirrel@webmail.suretecsystems.com> References: <1129070187.4381.21.camel@localhost.localdomain> <50148.195.38.86.72.1129118807.squirrel@webmail.suretecsystems.com> Message-ID: <1129120878.2901.14.camel@localhost.localdomain> On Wed, 2005-10-12 at 13:06 +0100, Gavin Henry wrote: > > > Canonical schedule and tasks: > > > > http://fedoraproject.org/wiki/DocsProject/FedoraDocsSchedule > > > > Summary of Updates and New Tasks: > > ===============================* Gavin will send emails this week > > soliciting beat writers and general > > contributors to the wiki (and possibly CVS) > > Shall I do this in the same format as last time, or do we have any key > points to put across on how "easy" it will be to help? The key points I can think of are that the Wiki is actively being used as the draft pad, so you may want to emphasize how easy it is to get started using that medium. Also mention, if you would, #fedora-docs and #fedora-wiki on IRC. You might want to give out Stuart's wiki page since he has information there on hours when he's around. Most of all, of course, point people to this list and let them know we are here and willing to help them get started, gently and patiently. My biggest fear is that people don't speak up on this list because they are worried about the environment being similar to a developers' list -- i.e. not really welcoming to rank newbies -- which is definitely not the case. We want to encourage people who want to do "low-impact" contribution, so they can be useful members of the community. Anyway, preaching to the choir, I know. ;-) > > * New contributors should probably submit a CLA via > > https://admin.fedora.redhat.com/accounts/ so they understand legal > > requirements on Fedora work, even for docs. Docs work should also be > > free of legal encumbrance. > > I'll also add them to the docs wiki list this week too. That would be great, thanks! Does anyone else have anything that could go in the email without making it too long to inspire enthusiasm? -- 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/ From stickster at gmail.com Wed Oct 12 01:44:04 2005 From: stickster at gmail.com (Paul W. Frields) Date: Tue, 11 Oct 2005 21:44:04 -0400 Subject: Test of Docs Packaging In-Reply-To: <1129072200.3562.16.camel@localhost.localdomain> References: <1129072200.3562.16.camel@localhost.localdomain> Message-ID: <1129081444.2907.6.camel@localhost.localdomain> On Wed, 2005-10-12 at 00:10 +0100, Stuart Ellis wrote: > Just to confirm that I've now tried the packaging for example-tutorial, > and got the expected result :) > > On a standard FC4 system: > > - yum install rpm-build > - cvs up docs-common > - cvs up example-tutorial > - cd example-tutorial/ > - make rpm > > Produces: fedora-doc-example-tutorial-0.14-1.noarch.rpm > containing .xml, .omf, and .desktop files. > > - sudo rpm -ivh fedora-doc-example-tutorial-0.14-1.noarch.rpm > > Produces: > > error: Failed dependencies: > fedora-doc-common is needed by > fedora-doc-example-tutorial-0.14-1.noarch Right. If you update your docs-common module again, you'll get the new stuff to package fedora-doc-common. Of course, once you make and install that and the f-d-e-t RPM, you'll see the problem created by not having a Documentation menu properly set up in /etc/xdg. However, if you use your "Help" function and navigate to "Other Documentation" (this will be under "Scrollkeeper" if you're using khelpviewer), you'll see the working docs! I'm not saying I'm proud of it, but it does at least work. I'm hoping for positive word from the redhat-menus guys, at which point you'll magically see these appear in your main menu. The current launcher there, "gnome-help," will be replaced by a helper script stored with the common stuff, to launch the correct help viewer for the user's desktop environment. -- 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/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From jlaska at redhat.com Thu Oct 13 12:51:22 2005 From: jlaska at redhat.com (James Laska) Date: Thu, 13 Oct 2005 08:51:22 -0400 Subject: CVSROOT avail,1.13,1.14 In-Reply-To: <1129129979.4681.6.camel@localhost.localdomain> References: <200509282221.j8SMLYIP018948@cvs-int.fedora.redhat.com> <1127947434.2944.11.camel@localhost.localdomain> <1128093026.5399.19.camel@localhost.localdomain> <1129068131.4381.7.camel@localhost.localdomain> <1129124796.3861.6.camel@blaa> <1129129979.4681.6.camel@localhost.localdomain> Message-ID: <1129207882.4791.12.camel@flatline.devel.redhat.com> On Wed, 2005-10-12 at 11:12 -0400, Paul W. Frields wrote: > Any assistance here would be gratefully > accepted. I think Mr. Laska is going to help me clean up these ugly > Makefiles, at which point they will be incorporated properly into > Makefile.common as necessary. Hey Paul, great work on the Makefile logic. This will be very helpful for allowing other groups inside Red Hat to produce documentation against a common/maintained set of tools/css/xsl. I filed bug#170522 to work with the newly created docs-common/Makefile. Basically I'm just adding upon what you've done in an effort to have the Makefile and spec file work well outside of the fedora-docs proper (for internal documentation). I've pulled upon other packages for this logic (anaconda, kudzu ...). It lends well to creating a fedora-doc-common rpm from the local CVS checkout, and from cvs tagged copies. $ patch -p1 < /tmp/docs-common.patch patching file Makefile patching file packaging/fedora-doc-common.spec patching file packaging/fedora-doc-common.spec.in After patching, you now can do the same rpm magic as before, but now you can decide whether to make a package from what's in CVS, or from local files. $ make rpm # makes rpm out of a specific CVS revision (defaults to HEAD) $ make local-rpm # makes rpm out of local checkout This patch also adds an "install:" target which helps clean up the specfile. I also added a target "all:" at the top, which currently is empty. Before that the default target was clean, which probably isn't what one would expect when typing `make`. This patch also turns the packaging/fedora-doc-common.spec file into a preprocessed file called packaging/fedora-doc-common.spec.in. This then mimics the behavior of other files in the packaging/ directory, and allows for VERSION and RELEASE variable expansion when creating an archive (or rpm). Thoughts/comments/concerns? Many thanks, James -- ========================================== James Laska -- jlaska at redhat.com Quality Engineering -- Red Hat, Inc. ========================================== From Tommy.Reynolds at MegaCoder.com Thu Oct 13 14:27:57 2005 From: Tommy.Reynolds at MegaCoder.com (Tommy Reynolds) Date: Thu, 13 Oct 2005 09:27:57 -0500 Subject: Test of Docs Packaging In-Reply-To: <1129081444.2907.6.camel@localhost.localdomain> References: <1129072200.3562.16.camel@localhost.localdomain> <1129081444.2907.6.camel@localhost.localdomain> Message-ID: <20051013092757.00a4398b.Tommy.Reynolds@MegaCoder.com> Uttered "Paul W. Frields" , spake thus: > Right. If you update your docs-common module again, you'll get the new > stuff to package fedora-doc-common. Paul, Two issues have slowly emerged from the recesses of my mind (which is always in recess, if you get my drift). Forgive me if they have already been discussed: 1. This all looks quite compilated to leave in Makefile.. Do you think that packaging this as a shell script would be cleaner and easier to maintain? Just use the same Makefile.common technology I used for the i18n conversion to generate the per-language targets and pickle off the shell script from there. 2. The "noarch" RPM's actually contain the source; that's more a "src.rpm" or "-devel.noarch.rpm" to me. Don't we need room in the namespace for a PDF / HTML flavor of the RPM? Perhaps "foo-html.noarch.rpm"? Late to the party, but Cheers -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jlaska at redhat.com Fri Oct 14 16:48:13 2005 From: jlaska at redhat.com (James Laska) Date: Fri, 14 Oct 2005 12:48:13 -0400 Subject: Test of Docs Packaging In-Reply-To: <1129081444.2907.6.camel@localhost.localdomain> References: <1129072200.3562.16.camel@localhost.localdomain> <1129081444.2907.6.camel@localhost.localdomain> Message-ID: <1129308494.2761.6.camel@flatline.devel.redhat.com> I sent this earlier but was experiencing mail issues this morning ... resending ... >>>>> Greetings, So I have some local changes to the Makefile.common that will add support for archiving and packaging (rpm) documentation. The changes will not require individual doc writers to modify their Makefile as all the wholesome goodness is placed into the Makefile.common. While doing this I did run into some issues that I'm sure you folks have already addressed/discussed. I thought perhaps it would be better to raise the issues for discussion before submitting patches. The first issue was how to handle CVS versus packaging. By that I mean when working out of CVS, you are expected to have a path "../docs-common/" that resolves. That isn't necessarily true when working out of the archive (tarball) or the rpm. So, when using the tarball or rpm I took the assumption that you must have the fedora-doc-common.rpm installed (or the tarball installed). That seemed to me like a sane transition since you are leaving the CVS realm at that point. This then provides for package work and building of your docs outside of CVS. To complete this transition, I have a rule in Makefile.common that changes a variable FDC_PREFIX from "../docs-common/" to "/usr/share/fedora/doc/docs-common/". This change works it's way into the documents Makefile and xml. Thoughts/concerns? An alternative is to drop the dependency on the CVS module docs-common completely. This change would involve requiring doc writers to install the fedora-doc-common-*.rpm in order to have the required css,stylesheet-images,xsl. If we adopt this, all doc references to "../docs-common" will need to be changed. There are a few other nits that I've encountered while making some changes. But overall, it was much easier than I anticipated. The current Makefile.common is well structured and easy to follow for this type of work. Another future concern is that every document includes it's own css and stylesheet-images. While there isn't much there in terms of file size, it does some like we should be able to share these items. Does anyone have thoughts/preference as to whether it might be better to change file paths for "{admon,callout}.graphics.path" in the html-common.xsl to point to a system-wide location? Including these files does offer the benefit of portable documents since they include their own images and css. The more I think about it the more it seems like removing the ../docs-common/ CVS paths is the way to go. In favor of having doc-writers install the fedora-doc-common rpm. I could be missing something, but it seems like there are fewer prickly thorns down that path. Thoughts/comments/concerns? Many thanks! James Laska On Thu, 2005-10-13 at 09:27 -0500, Tommy Reynolds wrote: > Uttered "Paul W. Frields" , spake thus: > > > Right. If you update your docs-common module again, you'll get the new > > stuff to package fedora-doc-common. > > Paul, > > Two issues have slowly emerged from the recesses of my mind (which is > always in recess, if you get my drift). Forgive me if they have > already been discussed: > > 1. This all looks quite compilated to leave in Makefile.. > Do you think that packaging this as a shell script would be > cleaner and easier to maintain? Just use the same > Makefile.common technology I used for the i18n conversion to > generate the per-language targets and pickle off the shell script > from there. > > 2. The "noarch" RPM's actually contain the source; that's more a > "src.rpm" or "-devel.noarch.rpm" to me. Don't we need room in the > namespace for a PDF / HTML flavor of the RPM? Perhaps > "foo-html.noarch.rpm"? > > Late to the party, but Cheers > -- > fedora-docs-list mailing list > fedora-docs-list at redhat.com > To unsubscribe: > https://www.redhat.com/mailman/listinfo/fedora-docs-list -- ========================================== James Laska -- jlaska at redhat.com Quality Engineering -- Red Hat, Inc. ========================================== From jlaska at redhat.com Fri Oct 14 16:49:10 2005 From: jlaska at redhat.com (James Laska) Date: Fri, 14 Oct 2005 12:49:10 -0400 Subject: Test of Docs Packaging In-Reply-To: <20051013092757.00a4398b.Tommy.Reynolds@MegaCoder.com> References: <1129072200.3562.16.camel@localhost.localdomain> <1129081444.2907.6.camel@localhost.localdomain> <20051013092757.00a4398b.Tommy.Reynolds@MegaCoder.com> Message-ID: <1129308551.2761.8.camel@flatline.devel.redhat.com> On Thu, 2005-10-13 at 09:27 -0500, Tommy Reynolds wrote: > 2. The "noarch" RPM's actually contain the source; that's more a > "src.rpm" or "-devel.noarch.rpm" to me. Don't we need room in the > namespace for a PDF / HTML flavor of the RPM? Perhaps > "foo-html.noarch.rpm"? Any objections to having the rpm contain all flavors? Seems like less hassle with that approach. But we could benefit from standardizing on the location of how those files get dropped onto the system. How about the following: /usr/share/fedora/doc/$docbase/$lang/$docbase-$lang/ # chunked html /usr/share/fedora/doc/$docbase/$lang/$docbase-$lang.html # nochunk html /usr/share/fedora/doc/$docbase/$lang/$docbase-$lang.pdf # pdf /usr/share/fedora/doc/$docbase/$lang/$docbase-$lang.txt # plain txt /usr/share/fedora/doc/$docbase/$lang/$docbase-$lang.omf (perhaps a symlink from /usr/share/omf or vice-versa) Thanks, James Laska -- ========================================== James Laska -- jlaska at redhat.com Quality Engineering -- Red Hat, Inc. ========================================== From jlaska at redhat.com Fri Oct 14 15:05:57 2005 From: jlaska at redhat.com (James Laska) Date: Fri, 14 Oct 2005 11:05:57 -0400 Subject: Test of Docs Packaging In-Reply-To: <20051013092757.00a4398b.Tommy.Reynolds@MegaCoder.com> References: <1129072200.3562.16.camel@localhost.localdomain> <1129081444.2907.6.camel@localhost.localdomain> <20051013092757.00a4398b.Tommy.Reynolds@MegaCoder.com> Message-ID: <1129302357.2761.2.camel@flatline.devel.redhat.com> On Thu, 2005-10-13 at 09:27 -0500, Tommy Reynolds wrote: > 2. The "noarch" RPM's actually contain the source; that's more a > "src.rpm" or "-devel.noarch.rpm" to me. Don't we need room in the > namespace for a PDF / HTML flavor of the RPM? Perhaps > "foo-html.noarch.rpm"? Any objections to having the rpm contain all flavors? Seems like less hassle with that approach. But we could benefit from standardizing on the location of how those files get dropped onto the system. How about the following: /usr/share/fedora/doc/$docbase/$lang/$docbase-$lang/ # chunked html /usr/share/fedora/doc/$docbase/$lang/$docbase-$lang.html # nochunk html /usr/share/fedora/doc/$docbase/$lang/$docbase-$lang.pdf # pdf /usr/share/fedora/doc/$docbase/$lang/$docbase-$lang.txt # plain txt /usr/share/fedora/doc/$docbase/$lang/$docbase-$lang.omf (perhaps a symlink from /usr/share/omf or vice-versa) Thanks, James Laska -- ========================================== James Laska -- jlaska at redhat.com Quality Engineering -- Red Hat, Inc. ========================================== From jlaska at redhat.com Fri Oct 14 12:41:59 2005 From: jlaska at redhat.com (James Laska) Date: Fri, 14 Oct 2005 08:41:59 -0400 Subject: Test of Docs Packaging In-Reply-To: <20051013092757.00a4398b.Tommy.Reynolds@MegaCoder.com> References: <1129072200.3562.16.camel@localhost.localdomain> <1129081444.2907.6.camel@localhost.localdomain> <20051013092757.00a4398b.Tommy.Reynolds@MegaCoder.com> Message-ID: <1129293719.28625.40.camel@flatline.devel.redhat.com> On Thu, 2005-10-13 at 09:27 -0500, Tommy Reynolds wrote: > 2. The "noarch" RPM's actually contain the source; that's more a > "src.rpm" or "-devel.noarch.rpm" to me. Don't we need room in the > namespace for a PDF / HTML flavor of the RPM? Perhaps > "foo-html.noarch.rpm"? Any objections to having the rpm contain all flavors? Seems like less hassle with that approach. But we could benefit from standardizing on the location of how those files get dropped onto the system. How about the following: /usr/share/fedora/doc/$docbase/$lang/$docbase-$lang/ # chunked html /usr/share/fedora/doc/$docbase/$lang/$docbase-$lang.html # nochunk html /usr/share/fedora/doc/$docbase/$lang/$docbase-$lang.pdf # pdf /usr/share/fedora/doc/$docbase/$lang/$docbase-$lang.txt # plain txt /usr/share/fedora/doc/$docbase/$lang/$docbase-$lang.omf (perhaps a symlink from /usr/share/omf or vice-versa) Thanks, James Laska -- ========================================== James Laska -- jlaska at redhat.com Quality Engineering -- Red Hat, Inc. ========================================== From jlaska at redhat.com Fri Oct 14 12:33:51 2005 From: jlaska at redhat.com (James Laska) Date: Fri, 14 Oct 2005 08:33:51 -0400 Subject: Test of Docs Packaging In-Reply-To: <20051013092757.00a4398b.Tommy.Reynolds@MegaCoder.com> References: <1129072200.3562.16.camel@localhost.localdomain> <1129081444.2907.6.camel@localhost.localdomain> <20051013092757.00a4398b.Tommy.Reynolds@MegaCoder.com> Message-ID: <1129293231.28625.31.camel@flatline.devel.redhat.com> Greetings, So I have some local changes to the Makefile.common that will add support for archiving and packaging (rpm) documentation. The changes will not require individual doc writers to modify their Makefile as all the wholesome goodness is placed into the Makefile.common. While doing this I did run into some issues that I'm sure you folks have already addressed/discussed. I thought perhaps it would be better to raise the issues for discussion before submitting patches. The first issue was how to handle CVS versus packaging. By that I mean when working out of CVS, you are expected to have a path "../docs-common/" that resolves. That isn't necessarily true when working out of the archive (tarball) or the rpm. So, when using the tarball or rpm I took the assumption that you must have the fedora-doc-common.rpm installed (or the tarball installed). That seemed to me like a sane transition since you are leaving the CVS realm at that point. This then provides for package work and building of your docs outside of CVS. To complete this transition, I have a rule in Makefile.common that changes a variable FDC_PREFIX from "../docs-common/" to "/usr/share/fedora/doc/docs-common/". This change works it's way into the documents Makefile and xml. Thoughts/concerns? An alternative is to drop the dependency on the CVS module docs-common completely. This change would involve requiring doc writers to install the fedora-doc-common-*.rpm in order to have the required css,stylesheet-images,xsl. If we adopt this, all doc references to "../docs-common" will need to be changed. There are a few other nits that I've encountered while making some changes. But overall, it was much easier than I anticipated. The current Makefile.common is well structured and easy to follow for this type of work. Another future concern is that every document includes it's own css and stylesheet-images. While there isn't much there in terms of file size, it does some like we should be able to share these items. Does anyone have thoughts/preference as to whether it might be better to change file paths for "{admon,callout}.graphics.path" in the html-common.xsl to point to a system-wide location? The more I think about it the more it seems like removing the ../docs-common/ CVS paths is the way to go. In favor of having doc-writers install the fedora-doc-common rpm. I could be missing something, but it seems like there are fewer prickly thorns down that path. Thoughts/comments/concerns? Many thanks! James Laska On Thu, 2005-10-13 at 09:27 -0500, Tommy Reynolds wrote: > Uttered "Paul W. Frields" , spake thus: > > > Right. If you update your docs-common module again, you'll get the new > > stuff to package fedora-doc-common. > > Paul, > > Two issues have slowly emerged from the recesses of my mind (which is > always in recess, if you get my drift). Forgive me if they have > already been discussed: > > 1. This all looks quite compilated to leave in Makefile.. > Do you think that packaging this as a shell script would be > cleaner and easier to maintain? Just use the same > Makefile.common technology I used for the i18n conversion to > generate the per-language targets and pickle off the shell script > from there. > > 2. The "noarch" RPM's actually contain the source; that's more a > "src.rpm" or "-devel.noarch.rpm" to me. Don't we need room in the > namespace for a PDF / HTML flavor of the RPM? Perhaps > "foo-html.noarch.rpm"? > > Late to the party, but Cheers > -- > fedora-docs-list mailing list > fedora-docs-list at redhat.com > To unsubscribe: > https://www.redhat.com/mailman/listinfo/fedora-docs-list -- ========================================== James Laska -- jlaska at redhat.com Quality Engineering -- Red Hat, Inc. ========================================== From stickster at gmail.com Fri Oct 14 11:40:24 2005 From: stickster at gmail.com (Paul W. Frields) Date: Fri, 14 Oct 2005 07:40:24 -0400 Subject: Test of Docs Packaging In-Reply-To: <20051013092757.00a4398b.Tommy.Reynolds@MegaCoder.com> References: <1129072200.3562.16.camel@localhost.localdomain> <1129081444.2907.6.camel@localhost.localdomain> <20051013092757.00a4398b.Tommy.Reynolds@MegaCoder.com> Message-ID: <1129290024.2961.7.camel@localhost.localdomain> On Thu, 2005-10-13 at 09:27 -0500, Tommy Reynolds wrote: > Uttered "Paul W. Frields" , spake thus: > > > Right. If you update your docs-common module again, you'll get the new > > stuff to package fedora-doc-common. > > Paul, > > Two issues have slowly emerged from the recesses of my mind (which is > always in recess, if you get my drift). Forgive me if they have > already been discussed: > > 1. This all looks quite compilated to leave in Makefile.. > Do you think that packaging this as a shell script would be > cleaner and easier to maintain? Just use the same > Makefile.common technology I used for the i18n conversion to > generate the per-language targets and pickle off the shell script > from there. This is an excellent idea. I will try my best. :-) > 2. The "noarch" RPM's actually contain the source; that's more a > "src.rpm" or "-devel.noarch.rpm" to me. Don't we need room in the > namespace for a PDF / HTML flavor of the RPM? Perhaps > "foo-html.noarch.rpm"? I wouldn't see a problem with putting HTML in the package and maybe using "htmlview" as the way to access documentation from the Applications menu. When PDF is available we can package that as a namespace "-pdf" as you suggest. Let me work on the HTML part at least -- that should be simple to implement in time for FC5 (cross fingers)! -- 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/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From jlaska at redhat.com Fri Oct 14 16:49:10 2005 From: jlaska at redhat.com (James Laska) Date: Fri, 14 Oct 2005 12:49:10 -0400 Subject: Test of Docs Packaging In-Reply-To: <20051013092757.00a4398b.Tommy.Reynolds@MegaCoder.com> References: <1129072200.3562.16.camel@localhost.localdomain> <1129081444.2907.6.camel@localhost.localdomain> <20051013092757.00a4398b.Tommy.Reynolds@MegaCoder.com> Message-ID: <1129308551.2761.8.camel@flatline.devel.redhat.com> On Thu, 2005-10-13 at 09:27 -0500, Tommy Reynolds wrote: > 2. The "noarch" RPM's actually contain the source; that's more a > "src.rpm" or "-devel.noarch.rpm" to me. Don't we need room in the > namespace for a PDF / HTML flavor of the RPM? Perhaps > "foo-html.noarch.rpm"? Any objections to having the rpm contain all flavors? Seems like less hassle with that approach. But we could benefit from standardizing on the location of how those files get dropped onto the system. How about the following: /usr/share/fedora/doc/$docbase/$lang/$docbase-$lang/ # chunked html /usr/share/fedora/doc/$docbase/$lang/$docbase-$lang.html # nochunk html /usr/share/fedora/doc/$docbase/$lang/$docbase-$lang.pdf # pdf /usr/share/fedora/doc/$docbase/$lang/$docbase-$lang.txt # plain txt /usr/share/fedora/doc/$docbase/$lang/$docbase-$lang.omf (perhaps a symlink from /usr/share/omf or vice-versa) Thanks, James Laska -- ========================================== James Laska -- jlaska at redhat.com Quality Engineering -- Red Hat, Inc. ========================================== From jlaska at redhat.com Fri Oct 14 17:48:55 2005 From: jlaska at redhat.com (James Laska) Date: Fri, 14 Oct 2005 13:48:55 -0400 Subject: Test of Docs Packaging In-Reply-To: <1129308551.2761.8.camel@flatline.devel.redhat.com> References: <1129072200.3562.16.camel@localhost.localdomain> <1129081444.2907.6.camel@localhost.localdomain> <20051013092757.00a4398b.Tommy.Reynolds@MegaCoder.com> <1129308551.2761.8.camel@flatline.devel.redhat.com> Message-ID: <1129312136.3848.3.camel@flatline.devel.redhat.com> /me watches as imap comes back to life ;( My apologies for the spam, James Laska On Fri, 2005-10-14 at 12:49 -0400, James Laska wrote: > On Thu, 2005-10-13 at 09:27 -0500, Tommy Reynolds wrote: > > 2. The "noarch" RPM's actually contain the source; that's more a > > "src.rpm" or "-devel.noarch.rpm" to me. Don't we need room in the > > namespace for a PDF / HTML flavor of the RPM? Perhaps > > "foo-html.noarch.rpm"? > > Any objections to having the rpm contain all flavors? Seems like less > hassle with that approach. But we could benefit from standardizing on > the location of how those files get dropped onto the system. > > How about the following: > > /usr/share/fedora/doc/$docbase/$lang/$docbase-$lang/ # chunked html > /usr/share/fedora/doc/$docbase/$lang/$docbase-$lang.html # nochunk html > /usr/share/fedora/doc/$docbase/$lang/$docbase-$lang.pdf # pdf > /usr/share/fedora/doc/$docbase/$lang/$docbase-$lang.txt # plain txt > /usr/share/fedora/doc/$docbase/$lang/$docbase-$lang.omf (perhaps a > symlink from /usr/share/omf or vice-versa) > > Thanks, > James Laska > > -- > ========================================== > James Laska -- jlaska at redhat.com > Quality Engineering -- Red Hat, Inc. > ========================================== From Tommy.Reynolds at MegaCoder.com Fri Oct 14 17:58:36 2005 From: Tommy.Reynolds at MegaCoder.com (Tommy Reynolds) Date: Fri, 14 Oct 2005 12:58:36 -0500 Subject: Test of Docs Packaging In-Reply-To: <1129293231.28625.31.camel@flatline.devel.redhat.com> References: <1129072200.3562.16.camel@localhost.localdomain> <1129081444.2907.6.camel@localhost.localdomain> <20051013092757.00a4398b.Tommy.Reynolds@MegaCoder.com> <1129293231.28625.31.camel@flatline.devel.redhat.com> Message-ID: <20051014125836.6cfa09d8.Tommy.Reynolds@MegaCoder.com> Uttered James Laska , spake thus: > The first issue was how to handle CVS versus packaging. By that I mean > when working out of CVS, you are expected to have a path > "../docs-common/" that resolves. That isn't necessarily true when > working out of the archive (tarball) or the rpm. I don't envision the tarballs nor the RPM's to be used in the authoring process. I think we want the authors working in the CVS arena and use the RPM/tarball as a distribution method for the finished goods. Read that as "end-user". However, I like the idea of the RPM/tarball packaging process to include the CSS and stylesheet images in the fedora-doc-common RPM. Do you or Paul want to do the surgery? We already browse the DOM for info... Cheers -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jlaska at redhat.com Fri Oct 14 18:09:28 2005 From: jlaska at redhat.com (James Laska) Date: Fri, 14 Oct 2005 14:09:28 -0400 Subject: Test of Docs Packaging In-Reply-To: <20051014125836.6cfa09d8.Tommy.Reynolds@MegaCoder.com> References: <1129072200.3562.16.camel@localhost.localdomain> <1129081444.2907.6.camel@localhost.localdomain> <20051013092757.00a4398b.Tommy.Reynolds@MegaCoder.com> <1129293231.28625.31.camel@flatline.devel.redhat.com> <20051014125836.6cfa09d8.Tommy.Reynolds@MegaCoder.com> Message-ID: <1129313368.3848.17.camel@flatline.devel.redhat.com> On Fri, 2005-10-14 at 12:58 -0500, Tommy Reynolds wrote: > I don't envision the tarballs nor the RPM's to be used in the > authoring process. I think we want the authors working in the CVS > arena and use the RPM/tarball as a distribution method for the > finished goods. Read that as "end-user". > Of course, what I meant was that once you package (tarball or rpm) the document up, non of those entity or xml includes that reference "../docs-common/" will work anymore will they? That isn't entirely true, as once the doc lands in /usr/share/fedora/doc/*, and fedora-doc-common.rpm is installed, the links will resolve again. Unfortunately, there is the interim phase where you must build the package. When that process is unfolding (in /usr/src/redhat/BUILD/$docbase-$lang), the "../docs-common/" directory structure will not map correctly. Does that makes sense? > However, I like the idea of the RPM/tarball packaging process to > include the CSS and stylesheet images in the fedora-doc-common RPM. > Do you or Paul want to do the surgery? We already browse the DOM for > info... I agree, but it seems like a similar issue as the ../docs-common stuff. Reference other files using an absolute or relative path. I'm still not clear on which solution makes the most sense. But when moving docs in and out of CVS, into rpms, into tarballs, into build-roots ... it is starting to seem like absolute file paths are the way to go. This isn't such a bad thing if we just require authors to install fedora-doc-common when authoring. Thanks, James -- ========================================== James Laska -- jlaska at redhat.com Quality Engineering -- Red Hat, Inc. ========================================== From Tommy.Reynolds at MegaCoder.com Fri Oct 14 20:41:39 2005 From: Tommy.Reynolds at MegaCoder.com (Tommy Reynolds) Date: Fri, 14 Oct 2005 15:41:39 -0500 Subject: Test of Docs Packaging In-Reply-To: <1129313368.3848.17.camel@flatline.devel.redhat.com> References: <1129072200.3562.16.camel@localhost.localdomain> <1129081444.2907.6.camel@localhost.localdomain> <20051013092757.00a4398b.Tommy.Reynolds@MegaCoder.com> <1129293231.28625.31.camel@flatline.devel.redhat.com> <20051014125836.6cfa09d8.Tommy.Reynolds@MegaCoder.com> <1129313368.3848.17.camel@flatline.devel.redhat.com> Message-ID: <20051014154139.6b9b4b67.Tommy.Reynolds@MegaCoder.com> Uttered James Laska , spake thus: > On Fri, 2005-10-14 at 12:58 -0500, Tommy Reynolds wrote: > > I don't envision the tarballs nor the RPM's to be used in the > > authoring process. > Unfortunately, there is the interim phase where you must build the > package. When that process is unfolding > (in /usr/src/redhat/BUILD/$docbase-$lang), the "../docs-common/" > directory structure will not map correctly. Does that makes sense? Not to me ;-{ Could someone (Paul?) please clarify who is supposed to be using what? I confess to active avoidance of all things GUI, so I may not be clear on the purpose of these RPM's in association with YELP and all that. Does it do the XML rendering on the fly, or something? If not, why put XML in the RPM's at all? I don't think we want any author to be mucking about with the RPM's and tarball's: authors should use CVS, period. What I'm looking for is an explanation from the _end_ _user's_ point of view of how the RPM's will be used. Cheers -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From dmalcolm at redhat.com Fri Oct 14 22:03:02 2005 From: dmalcolm at redhat.com (David Malcolm) Date: Fri, 14 Oct 2005 18:03:02 -0400 Subject: Test of Docs Packaging In-Reply-To: <20051014154139.6b9b4b67.Tommy.Reynolds@MegaCoder.com> References: <1129072200.3562.16.camel@localhost.localdomain> <1129081444.2907.6.camel@localhost.localdomain> <20051013092757.00a4398b.Tommy.Reynolds@MegaCoder.com> <1129293231.28625.31.camel@flatline.devel.redhat.com> <20051014125836.6cfa09d8.Tommy.Reynolds@MegaCoder.com> <1129313368.3848.17.camel@flatline.devel.redhat.com> <20051014154139.6b9b4b67.Tommy.Reynolds@MegaCoder.com> Message-ID: <1129327382.3442.10.camel@cassandra.boston.redhat.com> On Fri, 2005-10-14 at 15:41 -0500, Tommy Reynolds wrote: > Uttered James Laska , spake thus: > > > On Fri, 2005-10-14 at 12:58 -0500, Tommy Reynolds wrote: > > > I don't envision the tarballs nor the RPM's to be used in the > > > authoring process. > > Unfortunately, there is the interim phase where you must build the > > package. When that process is unfolding > > (in /usr/src/redhat/BUILD/$docbase-$lang), the "../docs-common/" > > directory structure will not map correctly. Does that makes sense? > > Not to me ;-{ > > Could someone (Paul?) please clarify who is supposed to be using > what? I confess to active avoidance of all things GUI, so I may not > be clear on the purpose of these RPM's in association with YELP and all > that. Does it do the XML rendering on the fly, or something? If > not, why put XML in the RPM's at all? > > I don't think we want any author to be mucking about with the RPM's > and tarball's: authors should use CVS, period. What I'm looking for > is an explanation from the _end_ _user's_ point of view of how the > RPM's will be used. (I'm coming in late to this discussion, so my apologies if this has already been covered) Yelp can render DocBook XML "on the fly" (actually it converts it internally to HTML with a heavily-optimised stylesheet, and renders it using the Gtk embedded gecko widget). Currently in rawhide if you click on Desktop->Help (or "Help Topics" in Yelp) you don't get a very helpful list. I'd love it if FC5 out of the box had a good contents page there, with some initial description of what Fedora is, and how to get involved, perhaps followed by top-level categories for end-user documentation, and sysadmin documentation. The various DocBook XML files could be hooked in there somehow... There's a bug to cover this here: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=170847 Would it be useful for this mailing list to come up with a scheme for what ought to be displayed on the front page of Yelp, and we can take it from there? Dave From stickster at gmail.com Sat Oct 15 14:48:07 2005 From: stickster at gmail.com (Paul W. Frields) Date: Sat, 15 Oct 2005 10:48:07 -0400 Subject: Test of Docs Packaging In-Reply-To: <1129327382.3442.10.camel@cassandra.boston.redhat.com> References: <1129072200.3562.16.camel@localhost.localdomain> <1129081444.2907.6.camel@localhost.localdomain> <20051013092757.00a4398b.Tommy.Reynolds@MegaCoder.com> <1129293231.28625.31.camel@flatline.devel.redhat.com> <20051014125836.6cfa09d8.Tommy.Reynolds@MegaCoder.com> <1129313368.3848.17.camel@flatline.devel.redhat.com> <20051014154139.6b9b4b67.Tommy.Reynolds@MegaCoder.com> <1129327382.3442.10.camel@cassandra.boston.redhat.com> Message-ID: <1129387688.7677.3.camel@localhost.localdomain> On Fri, 2005-10-14 at 18:03 -0400, David Malcolm wrote: > I'd love it if FC5 out of the box had a good contents page there, with > some initial description of what Fedora is, and how to get involved, > perhaps followed by top-level categories for end-user documentation, and > sysadmin documentation. The various DocBook XML files could be hooked > in there somehow... > > There's a bug to cover this here: > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=170847 > > Would it be useful for this mailing list to come up with a scheme for > what ought to be displayed on the front page of Yelp, and we can take it > from there? While I would *love* it if we could do this, the fact remains that Fedora developers are committed to sticking closer to upstream GNOME on this issue. If they choose to deviate on this front, I for one will be overjoyed! Right now our docs get added to "Other Documentation" because Yelp has no way to drop in a modular reconfiguration of the .cl (contents list), AFAIK. -- 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/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From mclasen at redhat.com Mon Oct 17 19:21:43 2005 From: mclasen at redhat.com (Matthias Clasen) Date: Mon, 17 Oct 2005 15:21:43 -0400 Subject: Including Fedora documentation in yelp Message-ID: <1129576903.2998.11.camel@golem.boston.redhat.com> We want to integrate Fedora documentation a bit better with the desktop for FC5 (see https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=170813 and https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=170847) I have patched yelp in rawhide to include documents on the front page which are registered with scrollkeeper in the category General|Linux|Distributions|Other (scrollkeeper uses a fixed set of categories, and there is no Fedora category). It would be great to have at least a short introduction ("About Fedora"), the release notes, and a user guide visible there. Regards, Matthias From kwade at redhat.com Thu Oct 20 00:05:33 2005 From: kwade at redhat.com (Karsten Wade) Date: Wed, 19 Oct 2005 17:05:33 -0700 Subject: Fedora docs processing (Was: [fedora-java] batik [Fwd: Re: com.sun.image.*]) In-Reply-To: <1129763488.2843.19.camel@dhcp-172-16-25-224.sfbay.redhat.com> References: <433B8965.5040802@pobox.com> <1129744425.2969.14.camel@localhost.localdomain> <4356911D.3040205@pobox.com> <1129763488.2843.19.camel@dhcp-172-16-25-224.sfbay.redhat.com> Message-ID: <1129766733.18168.386.camel@erato.phig.org> (setting reply-to for f-docs-l, pardon the cross-post, feel free to override headings in replies) On Wed, 2005-10-19 at 16:11 -0700, Anthony Green wrote: > On Wed, 2005-10-19 at 11:31 -0700, Brion Vibber wrote: > > I've looked a little bit at the files but haven't had a chance to try > > actually working on it. If someone else is itching to work on it, PLEASE > > feel free to start! > > Ok, thanks for the update Brion. > > I'm wondering if the simplest solution for the Fedora Docs team is for > us to strip out Batik's JPEG handling. Perhaps it's not required for > their work-flow. > > Karsten - can you provide some simple docs and show us how you would > process them using a proprietary Java solution? We should be able to > determine from this whether or not we can ignore the problem classes (as > a near term solution). AFAIK, we are using PNG and EPS only for our graphics. I don't know of any reason we cannot strip out JPEG handling. Fedora doc folk, what think ye? - Karsten -- Karsten Wade, RHCE * Sr. Tech Writer * http://people.redhat.com/kwade/ gpg fingerprint: 2680 DBFD D968 3141 0115 5F1B D992 0E06 AD0E 0C41 Red Hat SELinux Guide http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/selinux-guide/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From stuart at elsn.org Thu Oct 20 00:15:02 2005 From: stuart at elsn.org (Stuart Ellis) Date: Thu, 20 Oct 2005 01:15:02 +0100 Subject: Fedora docs processing (Was: [fedora-java] batik [Fwd: Re: com.sun.image.*]) In-Reply-To: <1129766733.18168.386.camel@erato.phig.org> References: <433B8965.5040802@pobox.com> <1129744425.2969.14.camel@localhost.localdomain> <4356911D.3040205@pobox.com> <1129763488.2843.19.camel@dhcp-172-16-25-224.sfbay.redhat.com> <1129766733.18168.386.camel@erato.phig.org> Message-ID: <1129767302.9167.4.camel@localhost.localdomain> On Wed, 2005-10-19 at 17:05 -0700, Karsten Wade wrote: > > I'm wondering if the simplest solution for the Fedora Docs team is for > > us to strip out Batik's JPEG handling. Perhaps it's not required for > > their work-flow. > > > > Karsten - can you provide some simple docs and show us how you would > > process them using a proprietary Java solution? We should be able to > > determine from this whether or not we can ignore the problem classes (as > > a near term solution). > > AFAIK, we are using PNG and EPS only for our graphics. I don't know of > any reason we cannot strip out JPEG handling. > > Fedora doc folk, what think ye? Sounds fine. AFAIK, the Install Guide is the only document that uses graphics, and it uses PNG and EPS for screenshots. The Documentation Guide recommends that graphics should be avoided, and specifies those two file types for essential graphics. So if there are JPEGs in our docs, they shouldn't be there :) -- Stuart Ellis stuart at 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From stuart at elsn.org Thu Oct 20 00:18:45 2005 From: stuart at elsn.org (Stuart Ellis) Date: Thu, 20 Oct 2005 01:18:45 +0100 Subject: FC4 Release Notes Imported into Wiki Message-ID: <1129767525.9167.7.camel@localhost.localdomain> http://www.fedoraproject.org/wiki/Docs/Beats/ I've imported the material as-is, except for essential edits. Note that the FC4 Release Notes also Overview, Splash, Project Overview, and Feedback sections, which don't correspond to any Beats. -- Stuart Ellis stuart at 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From kwade at redhat.com Thu Oct 20 00:23:20 2005 From: kwade at redhat.com (Karsten Wade) Date: Wed, 19 Oct 2005 17:23:20 -0700 Subject: Test of Docs Packaging In-Reply-To: <20051014154139.6b9b4b67.Tommy.Reynolds@MegaCoder.com> References: <1129072200.3562.16.camel@localhost.localdomain> <1129081444.2907.6.camel@localhost.localdomain> <20051013092757.00a4398b.Tommy.Reynolds@MegaCoder.com> <1129293231.28625.31.camel@flatline.devel.redhat.com> <20051014125836.6cfa09d8.Tommy.Reynolds@MegaCoder.com> <1129313368.3848.17.camel@flatline.devel.redhat.com> <20051014154139.6b9b4b67.Tommy.Reynolds@MegaCoder.com> Message-ID: <1129767800.18168.397.camel@erato.phig.org> On Fri, 2005-10-14 at 15:41 -0500, Tommy Reynolds wrote: > Could someone (Paul?) please clarify who is supposed to be using > what? I confess to active avoidance of all things GUI, so I may not > be clear on the purpose of these RPM's in association with YELP and all > that. Does it do the XML rendering on the fly, or something? If > not, why put XML in the RPM's at all? While it is true that Yelp does display XML, the real point is that XML is not just for source breakfast anymore. It is a full-fledged distributed meal in its own right. Which brings up the point ... we will have identical XML in .src.rpm as well as docs .rpms. Hmmm ... - Karsten -- Karsten Wade, RHCE * Sr. Tech Writer * http://people.redhat.com/kwade/ gpg fingerprint: 2680 DBFD D968 3141 0115 5F1B D992 0E06 AD0E 0C41 Red Hat SELinux Guide http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/selinux-guide/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From kwade at redhat.com Thu Oct 20 00:26:34 2005 From: kwade at redhat.com (Karsten Wade) Date: Wed, 19 Oct 2005 17:26:34 -0700 Subject: Test of Docs Packaging In-Reply-To: <1129327382.3442.10.camel@cassandra.boston.redhat.com> References: <1129072200.3562.16.camel@localhost.localdomain> <1129081444.2907.6.camel@localhost.localdomain> <20051013092757.00a4398b.Tommy.Reynolds@MegaCoder.com> <1129293231.28625.31.camel@flatline.devel.redhat.com> <20051014125836.6cfa09d8.Tommy.Reynolds@MegaCoder.com> <1129313368.3848.17.camel@flatline.devel.redhat.com> <20051014154139.6b9b4b67.Tommy.Reynolds@MegaCoder.com> <1129327382.3442.10.camel@cassandra.boston.redhat.com> Message-ID: <1129767994.18168.401.camel@erato.phig.org> On Fri, 2005-10-14 at 18:03 -0400, David Malcolm wrote: > Would it be useful for this mailing list to come up with a scheme for > what ought to be displayed on the front page of Yelp, and we can take it > from there? In theory, yes. FDP _is_ documentation for Fedora, although we can't do everything we should be doing ... yet. ;-> How do we handle the upstream issues with Yelp? Is this within our capability to control now? - Karsten -- Karsten Wade, RHCE * Sr. Tech Writer * http://people.redhat.com/kwade/ gpg fingerprint: 2680 DBFD D968 3141 0115 5F1B D992 0E06 AD0E 0C41 Red Hat SELinux Guide http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/selinux-guide/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From kwade at redhat.com Thu Oct 20 00:28:45 2005 From: kwade at redhat.com (Karsten Wade) Date: Wed, 19 Oct 2005 17:28:45 -0700 Subject: FC4 Release Notes Imported into Wiki In-Reply-To: <1129767525.9167.7.camel@localhost.localdomain> References: <1129767525.9167.7.camel@localhost.localdomain> Message-ID: <1129768125.18168.404.camel@erato.phig.org> On Thu, 2005-10-20 at 01:18 +0100, Stuart Ellis wrote: > http://www.fedoraproject.org/wiki/Docs/Beats/ > > I've imported the material as-is, except for essential edits. > > Note that the FC4 Release Notes also Overview, Splash, Project Overview, > and Feedback sections, which don't correspond to any Beats. FWIW, these beats cross over with the marketing project, Rahul and I have been handling these. I'm keeping my eyes open for a successor. :) - Karsten -- Karsten Wade, RHCE * Sr. Tech Writer * http://people.redhat.com/kwade/ gpg fingerprint: 2680 DBFD D968 3141 0115 5F1B D992 0E06 AD0E 0C41 Red Hat SELinux Guide http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/selinux-guide/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From kwade at redhat.com Thu Oct 20 00:59:18 2005 From: kwade at redhat.com (Karsten Wade) Date: Wed, 19 Oct 2005 17:59:18 -0700 Subject: minutes FDSCo 18-Oct-2005 Message-ID: <1129769958.18168.416.camel@erato.phig.org> Hi, I'm just back from vacation and catching up. Sorry if you didn't know I was away, I was practicing Red Hat tradition of working like crazy then disappearing for two weeks. I was not allowed to work on Fedora stuff during my vacation. ;-) Attendees: ========== Karsten Wade Tommy Reynolds Stuart Elliss Gavin Henry Paul Frields Here is the page that we updated: http://fedoraproject.org/wiki/DocsProject/FedoraDocsSchedule We are now working from this page. I am trying out new formats for these minutes that just highlight what happened. Highlights: =========== * First, temporary translation process is not at: http://fedoraproject.org/wiki/DocsProject/Translation * Seeking, still seeking help with a gcj compiled FOP (and Saxon). Anthony Green is helping us find a developer to fix our problems, perhaps to carry the package into Fedora Extras. * DocsRawhide is the nickname for the structure that is going to extract all versions of a document from CVS (tagged by release and HEAD), build them to all targets (HTML, PDF, RPM, etc.) in all languages, and make these URLs available via a webpage. This process happens as a rolling build, making it possible to distribute links to your latest documents that are in CVS. We have hardware identified and are working out technical responsibilities and scheduling to make this happen. * Beat writer positions are starting to fill up with developers from individual projects. You can still get yourself involved, working directly with the developers. More at: http://fedoraproject.org/wiki/DocsProject/ReleaseNotes/Beats . * We are doing out first MoinMoin Wiki to DocBook XML conversion for the release notes based on a snapshot to be taken on 22 December. Wish us luck! If you want to help, contact kwade at redhat.com. ## 30 ## -- Karsten Wade, RHCE * Sr. Tech Writer * http://people.redhat.com/kwade/ gpg fingerprint: 2680 DBFD D968 3141 0115 5F1B D992 0E06 AD0E 0C41 Red Hat SELinux Guide http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/selinux-guide/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From kwade at redhat.com Thu Oct 20 07:38:08 2005 From: kwade at redhat.com (Karsten Wade) Date: Thu, 20 Oct 2005 00:38:08 -0700 Subject: minutes FDSCo 18-Oct-2005 In-Reply-To: <1129769958.18168.416.camel@erato.phig.org> References: <1129769958.18168.416.camel@erato.phig.org> Message-ID: <1129793888.18168.455.camel@erato.phig.org> On Wed, 2005-10-19 at 17:59 -0700, Karsten Wade wrote: > Highlights: > =========== > > * First, temporary translation process is not at: This sentence was extremely poor, please ignore it. This makes more sense: "A temporary translation process has been posted at:" > http://fedoraproject.org/wiki/DocsProject/Translation - Karsten -- Karsten Wade, RHCE * Sr. Tech Writer * http://people.redhat.com/kwade/ gpg fingerprint: 2680 DBFD D968 3141 0115 5F1B D992 0E06 AD0E 0C41 Red Hat SELinux Guide http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/selinux-guide/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From Tommy.Reynolds at MegaCoder.com Thu Oct 20 15:35:46 2005 From: Tommy.Reynolds at MegaCoder.com (Tommy Reynolds) Date: Thu, 20 Oct 2005 10:35:46 -0500 Subject: Fedora docs processing (Was: [fedora-java] batik [Fwd: Re: com.sun.image.*]) In-Reply-To: <1129766733.18168.386.camel@erato.phig.org> References: <433B8965.5040802@pobox.com> <1129744425.2969.14.camel@localhost.localdomain> <4356911D.3040205@pobox.com> <1129763488.2843.19.camel@dhcp-172-16-25-224.sfbay.redhat.com> <1129766733.18168.386.camel@erato.phig.org> Message-ID: <20051020103546.98ddc670.Tommy.Reynolds@MegaCoder.com> Uttered Karsten Wade , spake thus: > AFAIK, we are using PNG and EPS only for our graphics. I don't know of > any reason we cannot strip out JPEG handling. > > Fedora doc folk, what think ye? Well, we are not really using even EPS at the moment since we are not actually producing any PDF's to speak of. And at that, EPS is needed only because the passivetex backend doesn't understand anything else. However, I think limiting the supported graphics to, in order of listing, is: SVG, EPS, and PNG. I do all my graphics work in SVG and then render appropriately. Regardless of how it gets produced, we can render a PNG into whatever is necessary using ImageMajick or netpbm. Both these tools are part of the Fedora distribution and are thus fully blessed already. Preliminary SVG support is provided by the librsvg2 RPM, also blessed by the distro. Sorry, JPG, it was nice while it lasted, but now it's over. Anytime we see jaggies, we'll think of you... Cheers -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From partha_26786794123 at yahoo.com Thu Oct 20 16:41:56 2005 From: partha_26786794123 at yahoo.com (Partha Goswami) Date: Thu, 20 Oct 2005 09:41:56 -0700 (PDT) Subject: translation Message-ID: <20051020164156.90749.qmail@web33603.mail.mud.yahoo.com> hi there, I have decideded to translate the Reslease Note in Bengali. I have seen that there is a problem in office software in FC3 . when You select Bengali lanuagge , in your system , it's almost ok . But when you want close any window ,particularly in word the three option viz. save, discard , cancel are shown in coding system. It's difficult to understand . I have think when all things including help material will translate into Bengali lanuagge. So, how it will? send coment. thanks . partha goswami __________________________________ Yahoo! Music Unlimited Access over 1 million songs. Try it free. http://music.yahoo.com/unlimited/ From stickster at gmail.com Thu Oct 20 21:27:40 2005 From: stickster at gmail.com (Paul W. Frields) Date: Thu, 20 Oct 2005 17:27:40 -0400 Subject: Test of Docs Packaging In-Reply-To: <1129767994.18168.401.camel@erato.phig.org> References: <1129072200.3562.16.camel@localhost.localdomain> <1129081444.2907.6.camel@localhost.localdomain> <20051013092757.00a4398b.Tommy.Reynolds@MegaCoder.com> <1129293231.28625.31.camel@flatline.devel.redhat.com> <20051014125836.6cfa09d8.Tommy.Reynolds@MegaCoder.com> <1129313368.3848.17.camel@flatline.devel.redhat.com> <20051014154139.6b9b4b67.Tommy.Reynolds@MegaCoder.com> <1129327382.3442.10.camel@cassandra.boston.redhat.com> <1129767994.18168.401.camel@erato.phig.org> Message-ID: <1129843660.2973.1.camel@localhost.localdomain> On Wed, 2005-10-19 at 17:26 -0700, Karsten Wade wrote: > On Fri, 2005-10-14 at 18:03 -0400, David Malcolm wrote: > > > Would it be useful for this mailing list to come up with a scheme for > > what ought to be displayed on the front page of Yelp, and we can take it > > from there? > > In theory, yes. FDP _is_ documentation for Fedora, although we can't do > everything we should be doing ... yet. ;-> > > How do we handle the upstream issues with Yelp? Is this within our > capability to control now? Matthias (Clasen) has already patched Yelp appropriately. The 2.12.x version in FC5 now directs docs in the General|Linux|Distributions|Other category onto the front page -- which now will include our docs. -- 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/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From stickster at gmail.com Thu Oct 20 21:33:17 2005 From: stickster at gmail.com (Paul W. Frields) Date: Thu, 20 Oct 2005 17:33:17 -0400 Subject: Test of Docs Packaging In-Reply-To: <1129767800.18168.397.camel@erato.phig.org> References: <1129072200.3562.16.camel@localhost.localdomain> <1129081444.2907.6.camel@localhost.localdomain> <20051013092757.00a4398b.Tommy.Reynolds@MegaCoder.com> <1129293231.28625.31.camel@flatline.devel.redhat.com> <20051014125836.6cfa09d8.Tommy.Reynolds@MegaCoder.com> <1129313368.3848.17.camel@flatline.devel.redhat.com> <20051014154139.6b9b4b67.Tommy.Reynolds@MegaCoder.com> <1129767800.18168.397.camel@erato.phig.org> Message-ID: <1129843997.2973.8.camel@localhost.localdomain> On Wed, 2005-10-19 at 17:23 -0700, Karsten Wade wrote: > On Fri, 2005-10-14 at 15:41 -0500, Tommy Reynolds wrote: > > Could someone (Paul?) please clarify who is supposed to be using > > what? I confess to active avoidance of all things GUI, so I may not > > be clear on the purpose of these RPM's in association with YELP and all > > that. Does it do the XML rendering on the fly, or something? If > > not, why put XML in the RPM's at all? > > While it is true that Yelp does display XML, the real point is that XML > is not just for source breakfast anymore. It is a full-fledged > distributed meal in its own right. > > Which brings up the point ... we will have identical XML in .src.rpm as > well as docs .rpms. Hmmm ... Same goes for a lot of Perl/Python libraries -- well OK, maybe not XML in those cases, but you see my point. Not a big deal IMHO. This may point to the need for our Makefile.common to provide a use case for a locally installed fedora-doc-common RPM. IOW, pointing to (if it's available, or possibly if nothing else is available, or... some combination thereof?) /usr/share/fedora/doc/docs-common/* for supporting stuff with which to build docs "standalone" without CVS. Does that make sense? -- 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/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From stickster at gmail.com Thu Oct 20 21:34:33 2005 From: stickster at gmail.com (Paul W. Frields) Date: Thu, 20 Oct 2005 17:34:33 -0400 Subject: Fedora docs processing (Was: [fedora-java] batik [Fwd: Re: com.sun.image.*]) In-Reply-To: <20051020103546.98ddc670.Tommy.Reynolds@MegaCoder.com> References: <433B8965.5040802@pobox.com> <1129744425.2969.14.camel@localhost.localdomain> <4356911D.3040205@pobox.com> <1129763488.2843.19.camel@dhcp-172-16-25-224.sfbay.redhat.com> <1129766733.18168.386.camel@erato.phig.org> <20051020103546.98ddc670.Tommy.Reynolds@MegaCoder.com> Message-ID: <1129844073.2973.10.camel@localhost.localdomain> On Thu, 2005-10-20 at 10:35 -0500, Tommy Reynolds wrote: > Uttered Karsten Wade , spake thus: > > > AFAIK, we are using PNG and EPS only for our graphics. I don't know of > > any reason we cannot strip out JPEG handling. > > > > Fedora doc folk, what think ye? > > Well, we are not really using even EPS at the moment since we are not > actually producing any PDF's to speak of. And at that, EPS is needed > only because the passivetex backend doesn't understand anything else. > > However, I think limiting the supported graphics to, in order of > listing, is: SVG, EPS, and PNG. I do all my graphics > work in SVG and then render appropriately. Regardless of how it > gets produced, we can render a PNG into whatever is necessary using > ImageMajick or netpbm. Both these tools are part of the Fedora > distribution and are thus fully blessed already. Preliminary SVG > support is provided by the librsvg2 RPM, also blessed by the distro. > > Sorry, JPG, it was nice while it lasted, but now it's over. Anytime > we see jaggies, we'll think of you... Hear, hear. -- 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/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From Tommy.Reynolds at MegaCoder.com Thu Oct 20 21:48:59 2005 From: Tommy.Reynolds at MegaCoder.com (Tommy Reynolds) Date: Thu, 20 Oct 2005 16:48:59 -0500 Subject: Test of Docs Packaging In-Reply-To: <1129843997.2973.8.camel@localhost.localdomain> References: <1129072200.3562.16.camel@localhost.localdomain> <1129081444.2907.6.camel@localhost.localdomain> <20051013092757.00a4398b.Tommy.Reynolds@MegaCoder.com> <1129293231.28625.31.camel@flatline.devel.redhat.com> <20051014125836.6cfa09d8.Tommy.Reynolds@MegaCoder.com> <1129313368.3848.17.camel@flatline.devel.redhat.com> <20051014154139.6b9b4b67.Tommy.Reynolds@MegaCoder.com> <1129767800.18168.397.camel@erato.phig.org> <1129843997.2973.8.camel@localhost.localdomain> Message-ID: <20051020164859.6bdad5df.Tommy.Reynolds@MegaCoder.com> Uttered "Paul W. Frields" , spake thus: > This may point to the need for our Makefile.common to provide a use case > for a locally installed fedora-doc-common RPM. IOW, pointing to (if > it's available, or possibly if nothing else is available, or... some > combination thereof?) /usr/share/fedora/doc/docs-common/* for supporting > stuff with which to build docs "standalone" without CVS. Does that make > sense? Not to me as a doc developer. See, I've got to have CVS for my document anyway, so I just may as well keep the ../docs-common stuff checked out. Why be "slightly pregnant"? I keep envisioning only two use cases: 1) Developer -- eveything local from a CVS checkout, even if I don't have CVS write permission. 2) End user, aka read-only -- install the RPM's and yelp away. What am I missing? Cheers -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From stickster at gmail.com Thu Oct 20 22:16:56 2005 From: stickster at gmail.com (Paul W. Frields) Date: Thu, 20 Oct 2005 18:16:56 -0400 Subject: Test of Docs Packaging In-Reply-To: <20051020164859.6bdad5df.Tommy.Reynolds@MegaCoder.com> References: <1129072200.3562.16.camel@localhost.localdomain> <1129081444.2907.6.camel@localhost.localdomain> <20051013092757.00a4398b.Tommy.Reynolds@MegaCoder.com> <1129293231.28625.31.camel@flatline.devel.redhat.com> <20051014125836.6cfa09d8.Tommy.Reynolds@MegaCoder.com> <1129313368.3848.17.camel@flatline.devel.redhat.com> <20051014154139.6b9b4b67.Tommy.Reynolds@MegaCoder.com> <1129767800.18168.397.camel@erato.phig.org> <1129843997.2973.8.camel@localhost.localdomain> <20051020164859.6bdad5df.Tommy.Reynolds@MegaCoder.com> Message-ID: <1129846616.2973.18.camel@localhost.localdomain> On Thu, 2005-10-20 at 16:48 -0500, Tommy Reynolds wrote: > Uttered "Paul W. Frields" , spake thus: > > > This may point to the need for our Makefile.common to provide a use case > > for a locally installed fedora-doc-common RPM. IOW, pointing to (if > > it's available, or possibly if nothing else is available, or... some > > combination thereof?) /usr/share/fedora/doc/docs-common/* for supporting > > stuff with which to build docs "standalone" without CVS. Does that make > > sense? > > Not to me as a doc developer. See, I've got to have CVS for my > document anyway, so I just may as well keep the ../docs-common stuff > checked out. Why be "slightly pregnant"? > > I keep envisioning only two use cases: > > 1) Developer -- eveything local from a CVS checkout, even if I don't > have CVS write permission. > > 2) End user, aka read-only -- install the RPM's and yelp away. > > What am I missing? I'm thinking of the fact that there's no other piece of stuff in Fedora that can't be built or rebuilt entirely from a .src.rpm and assorted BuildRequires. If someone "in the know" @RH says "Shut up, nobody cares," that's good enough for me. :-) -- 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/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From Tommy.Reynolds at MegaCoder.com Thu Oct 20 23:01:04 2005 From: Tommy.Reynolds at MegaCoder.com (Tommy Reynolds) Date: Thu, 20 Oct 2005 18:01:04 -0500 Subject: Test of Docs Packaging In-Reply-To: <1129846616.2973.18.camel@localhost.localdomain> References: <1129072200.3562.16.camel@localhost.localdomain> <1129081444.2907.6.camel@localhost.localdomain> <20051013092757.00a4398b.Tommy.Reynolds@MegaCoder.com> <1129293231.28625.31.camel@flatline.devel.redhat.com> <20051014125836.6cfa09d8.Tommy.Reynolds@MegaCoder.com> <1129313368.3848.17.camel@flatline.devel.redhat.com> <20051014154139.6b9b4b67.Tommy.Reynolds@MegaCoder.com> <1129767800.18168.397.camel@erato.phig.org> <1129843997.2973.8.camel@localhost.localdomain> <20051020164859.6bdad5df.Tommy.Reynolds@MegaCoder.com> <1129846616.2973.18.camel@localhost.localdomain> Message-ID: <20051020180104.2d2cc8aa.Tommy.Reynolds@MegaCoder.com> Uttered "Paul W. Frields" , spake thus: > > What am I missing? > I'm thinking of the fact that there's no other piece of stuff in Fedora > that can't be built or rebuilt entirely from a .src.rpm and assorted > BuildRequires. If someone "in the know" @RH says "Shut up, nobody > cares," that's good enough for me. :-) This seems empty form to me but I ain't @RH anymore. Quaid? Final answer? Cheers -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From kwade at redhat.com Fri Oct 21 12:27:21 2005 From: kwade at redhat.com (Karsten Wade) Date: Fri, 21 Oct 2005 05:27:21 -0700 Subject: Test of Docs Packaging In-Reply-To: <20051020180104.2d2cc8aa.Tommy.Reynolds@MegaCoder.com> References: <1129072200.3562.16.camel@localhost.localdomain> <1129081444.2907.6.camel@localhost.localdomain> <20051013092757.00a4398b.Tommy.Reynolds@MegaCoder.com> <1129293231.28625.31.camel@flatline.devel.redhat.com> <20051014125836.6cfa09d8.Tommy.Reynolds@MegaCoder.com> <1129313368.3848.17.camel@flatline.devel.redhat.com> <20051014154139.6b9b4b67.Tommy.Reynolds@MegaCoder.com> <1129767800.18168.397.camel@erato.phig.org> <1129843997.2973.8.camel@localhost.localdomain> <20051020164859.6bdad5df.Tommy.Reynolds@MegaCoder.com> <1129846616.2973.18.camel@localhost.localdomain> <20051020180104.2d2cc8aa.Tommy.Reynolds@MegaCoder.com> Message-ID: <1129897641.18168.582.camel@erato.phig.org> On Thu, 2005-10-20 at 18:01 -0500, Tommy Reynolds wrote: > Uttered "Paul W. Frields" , spake thus: > > > > What am I missing? > > I'm thinking of the fact that there's no other piece of stuff in Fedora > > that can't be built or rebuilt entirely from a .src.rpm and assorted > > BuildRequires. If someone "in the know" @RH says "Shut up, nobody > > cares," that's good enough for me. :-) > > This seems empty form to me but I ain't @RH anymore. > > I keep envisioning only two use cases: > > 1) Developer -- eveything local from a CVS checkout, even if I don't > have CVS write permission. > > 2) End user, aka read-only -- install the RPM's and yelp away. > > What am I missing? 3) People who want to use the FDP structure to write their own documentation. They don't necessarily care a whit about our content, so CVS access and associated is not valuable. Having a complete document building environment is. I don't know that this was an FDP intention from the start, but the fact is people use our DocBook templates. When we get PDF working, I expect we'll see that number increase, mainly because we then have the most complete DocBook toolchain that is also 100% free. I think it is a good idea to have a common documentation infrastructure RPM that is separate from the content packages. Interacting like this? 1. Document package, foo-en.rpm -- stand-alone, has all build targets and copy of XML for Yelp et al. 2. Document source package, foo-en.src.rpm -- requires doc infrastructure package to build, this package is mainly XML, Makefile, and images. 3. Document infrastructure package -- all that you need to build one of the .src.rpms, to roll your own docs packages, or to roll your own documentation set. > Quaid? Final answer? As long as I have addressed every point? I do think I have. - Karsten -- Karsten Wade, RHCE * Sr. Tech Writer * http://people.redhat.com/kwade/ gpg fingerprint: 2680 DBFD D968 3141 0115 5F1B D992 0E06 AD0E 0C41 Red Hat SELinux Guide http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/selinux-guide/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From ghenry at suretecsystems.com Fri Oct 21 13:15:33 2005 From: ghenry at suretecsystems.com (Gavin Henry) Date: Fri, 21 Oct 2005 14:15:33 +0100 (BST) Subject: [Fwd: printing changes for FC5] Message-ID: <37747.195.38.86.72.1129900533.squirrel@webmail.suretecsystems.com> Initial relnote for Printing. See Tim's last question. ---------------------------- Original Message ---------------------------- Subject: printing changes for FC5 From: "Tim Waugh" Date: Fri, October 21, 2005 1:56 pm To: "Gavin Henry" -------------------------------------------------------------------------- Hi Gavin, Sorry I didn't get to sending this to you yesterday. Here are some noteworthy things that have changed in FC5: o HPLIP is now included, and replaces HPOJ. HPLIP is the transport mechanism for HP printers including OfficeJet multifunction devices. It also includes an update version of the HPIJS inkjet driver, and a new program `hp-toolbox' for monitoring the status of attached devices (such as ink levels etc). o ESP Ghostscript is now included instead of GPL Ghostscript. ESP Ghostscript includes many cross-vendor fixes on top of GPL Ghostscript. o New major version of Ghostscript: ESP Ghostcript 8.15.1 included, replacing GPL Ghostscript 7.07. Do we need to mention things like that CUPS is now compiled using -fstack-protector-all for better protection against stack overflow security exploits? Tim. */ -------------- next part -------------- A non-text attachment was scrubbed... Name: untitled-2 Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From stickster at gmail.com Fri Oct 21 13:52:37 2005 From: stickster at gmail.com (Paul W. Frields) Date: Fri, 21 Oct 2005 09:52:37 -0400 Subject: Test of Docs Packaging In-Reply-To: <1129897641.18168.582.camel@erato.phig.org> References: <1129072200.3562.16.camel@localhost.localdomain> <1129081444.2907.6.camel@localhost.localdomain> <20051013092757.00a4398b.Tommy.Reynolds@MegaCoder.com> <1129293231.28625.31.camel@flatline.devel.redhat.com> <20051014125836.6cfa09d8.Tommy.Reynolds@MegaCoder.com> <1129313368.3848.17.camel@flatline.devel.redhat.com> <20051014154139.6b9b4b67.Tommy.Reynolds@MegaCoder.com> <1129767800.18168.397.camel@erato.phig.org> <1129843997.2973.8.camel@localhost.localdomain> <20051020164859.6bdad5df.Tommy.Reynolds@MegaCoder.com> <1129846616.2973.18.camel@localhost.localdomain> <20051020180104.2d2cc8aa.Tommy.Reynolds@MegaCoder.com> <1129897641.18168.582.camel@erato.phig.org> Message-ID: <1129902757.2994.11.camel@localhost.localdomain> On Fri, 2005-10-21 at 05:27 -0700, Karsten Wade wrote: > > > > What am I missing? > > > I'm thinking of the fact that there's no other piece of stuff in Fedora > > > that can't be built or rebuilt entirely from a .src.rpm and assorted > > > BuildRequires. If someone "in the know" @RH says "Shut up, nobody > > > cares," that's good enough for me. :-) > > > > This seems empty form to me but I ain't @RH anymore. > > > > I keep envisioning only two use cases: > > > > 1) Developer -- eveything local from a CVS checkout, even if I don't > > have CVS write permission. > > > > 2) End user, aka read-only -- install the RPM's and yelp away. > > > > What am I missing? > > 3) People who want to use the FDP structure to write their own > documentation. > > They don't necessarily care a whit about our content, so CVS access and > associated is not valuable. Having a complete document building > environment is. Right, the same way that someone who doesn't care about having CVS access to Extras or Core is able to patch and roll their own RPMs from that content. > I don't know that this was an FDP intention from the start, but the fact > is people use our DocBook templates. When we get PDF working, I expect > we'll see that number increase, mainly because we then have the most > complete DocBook toolchain that is also 100% free. > > I think it is a good idea to have a common documentation infrastructure > RPM that is separate from the content packages. Interacting like this? > > 1. Document package, foo-en.rpm -- stand-alone, has all build targets > and copy of XML for Yelp et al. > > 2. Document source package, foo-en.src.rpm -- requires doc > infrastructure package to build, this package is mainly XML, Makefile, > and images. > > 3. Document infrastructure package -- all that you need to build one of > the .src.rpms, to roll your own docs packages, or to roll your own > documentation set. > > > Quaid? Final answer? > > As long as I have addressed every point? I do think I have. I thought originally that fedora-doc-common-.noarch.rpm might provide this (all other RPMs would have a BuildRequires pointing thereto) but I am not sure if that's appropriate, or whether we should have a separate fedora-doc-devel RPM instead. The difference would be that f-d-common would include content files that are shared by all installed documents, whereas f-d-devel would package build components that are not used outside the building process. I don't know where to draw that line. But I can see that this line of thinking might shift our process subtly. For instance, it might open the process a bit to automation, in the same way that the brilliant plague/buildsys component has in Fedora Extras. Rather than asking for CVS access, people could "yum install fedora-doc-devel" and use our toolchain to build their own doc sets the way Karsten described, or they might use them for drafting, only applying for CVS when it was comfortable. I'm not sure I can fully articulate how/if this is better than what we're doing currently. Any ideas? -- 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/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From kwade at redhat.com Fri Oct 21 14:43:57 2005 From: kwade at redhat.com (Karsten Wade) Date: Fri, 21 Oct 2005 07:43:57 -0700 Subject: establishing a timezone for FDP Message-ID: <1129905837.18168.689.camel@erato.phig.org> There are two reasons I use Eastern Daylight/Standard time: * That is where the QA and release engineering teams for Fedora are primarily based. Working off a schedule that is intuitive for them reduces the chances of miscommunication and mistakes. * The same intuitiveness is currently spread throughout the Fedora development community. Should this change, or we want to lead a charge for UTC on all things, feel free to challenge this concept. Meanwhile, if we ever set a deadline, e.g. 24 October, this is what it means: 24 October 23:59 Eastern Time Yes, that means right before Midnight. This way we provide the most time for completing deadlines without having confusion about Midnight meaning the start of the end of which day. Alternately, we can set deadlines as COB (close of business), for an additional cushion of time. That would be: 24 October 17:00 Easter Time Does this make sense? When doing the scheduling for translation, I tried to add in a calendar day as a cushion against any problems caused by a deadline being late afternoon in APAC. http://fedoraproject.org/wiki/DocsProject/Schedule - Karsten -- Karsten Wade, RHCE * Sr. Tech Writer * http://people.redhat.com/kwade/ gpg fingerprint: 2680 DBFD D968 3141 0115 5F1B D992 0E06 AD0E 0C41 Red Hat SELinux Guide http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/selinux-guide/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From kwade at redhat.com Fri Oct 21 14:46:08 2005 From: kwade at redhat.com (Karsten Wade) Date: Fri, 21 Oct 2005 07:46:08 -0700 Subject: Test of Docs Packaging In-Reply-To: <1129902757.2994.11.camel@localhost.localdomain> References: <1129072200.3562.16.camel@localhost.localdomain> <1129081444.2907.6.camel@localhost.localdomain> <20051013092757.00a4398b.Tommy.Reynolds@MegaCoder.com> <1129293231.28625.31.camel@flatline.devel.redhat.com> <20051014125836.6cfa09d8.Tommy.Reynolds@MegaCoder.com> <1129313368.3848.17.camel@flatline.devel.redhat.com> <20051014154139.6b9b4b67.Tommy.Reynolds@MegaCoder.com> <1129767800.18168.397.camel@erato.phig.org> <1129843997.2973.8.camel@localhost.localdomain> <20051020164859.6bdad5df.Tommy.Reynolds@MegaCoder.com> <1129846616.2973.18.camel@localhost.localdomain> <20051020180104.2d2cc8aa.Tommy.Reynolds@MegaCoder.com> <1129897641.18168.582.camel@erato.phig.org> <1129902757.2994.11.camel@localhost.localdomain> Message-ID: <1129905968.18168.693.camel@erato.phig.org> On Fri, 2005-10-21 at 09:52 -0400, Paul W. Frields wrote: > I thought originally that fedora-doc-common-.noarch.rpm might > provide this (all other RPMs would have a BuildRequires pointing > thereto) but I am not sure if that's appropriate, or whether we should > have a separate fedora-doc-devel RPM instead. The difference would be > that f-d-common would include content files that are shared by all > installed documents, whereas f-d-devel would package build components > that are not used outside the building process. I don't know where to > draw that line. But I can see that this line of thinking might shift > our process subtly. > > For instance, it might open the process a bit to automation, in the same > way that the brilliant plague/buildsys component has in Fedora Extras. > Rather than asking for CVS access, people could "yum install > fedora-doc-devel" and use our toolchain to build their own doc sets the > way Karsten described, or they might use them for drafting, only > applying for CVS when it was comfortable. > > I'm not sure I can fully articulate how/if this is better than what > we're doing currently. Any ideas? You are going down the correct thought path. Automation, yes. There is going to be lots of that. Easy-to-install distributed build systems. There will always be one-true-CVS, but we can work out how to federate content. This is the real reason we are XML-centric, not because we {heart} Emacs and DocBook. This list makes sense to me and matches what happens with application packages: * fedora-doc-common-.noarch.rpm, no requires /usr/share/fedora/doc/$docbase/$lang/docs-common/ or /usr/share/fedora/doc/docs-common/ -- I think there are common pieces that require localization -- should the localized content be broken out from the non-localized? * fedora-doc-devel-.noarch.rpm, requires f-d-common /usr/share/fedora/doc/$docbase/devel/ ??? * fedora-doc-docname-.noarch.rpm, requires f-d-common /usr/share/fedora/doc/$docbase/$lang/$docname-$lang* Anything missing? (/me pokes jlaska for comment) - Karsten -- Karsten Wade, RHCE * Sr. Tech Writer * http://people.redhat.com/kwade/ gpg fingerprint: 2680 DBFD D968 3141 0115 5F1B D992 0E06 AD0E 0C41 Red Hat SELinux Guide http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/selinux-guide/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From dwmw2 at infradead.org Fri Oct 21 14:49:47 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Fri, 21 Oct 2005 15:49:47 +0100 Subject: establishing a timezone for FDP In-Reply-To: <1129905837.18168.689.camel@erato.phig.org> References: <1129905837.18168.689.camel@erato.phig.org> Message-ID: <1129906187.15431.122.camel@baythorne.infradead.org> On Fri, 2005-10-21 at 07:43 -0700, Karsten Wade wrote: > 24 October 17:00 Easter Time > > Does this make sense? Make sense? It has absolutely no meaning to me at all. I couldn't keep track of when you changed to/from daylight savings time even _before_ you started mucking around with the dates. People often say 'EST' when they mean 'EDT' and vice versa too, which makes it worse. Use UTC everywhere; it's not really that hard to expect someone to know their _own_ timezone. To expect others around the world to keep track of your own random localtime is bizarre and going to lead to mistakes. For much the same reasons, when speaking to an international audience we all usually quote prices in US Dollars or Euros instead of whatever currency we have in our pocket at the time, and we should always give dates as '2005-10-21' instead of making the recipient guess whether we mean mm/dd/yy or dd/mm/yy. It just makes sense. -- dwmw2 From Tommy.Reynolds at MegaCoder.com Fri Oct 21 16:06:01 2005 From: Tommy.Reynolds at MegaCoder.com (Tommy Reynolds) Date: Fri, 21 Oct 2005 11:06:01 -0500 Subject: Test of Docs Packaging In-Reply-To: <1129897641.18168.582.camel@erato.phig.org> References: <1129072200.3562.16.camel@localhost.localdomain> <1129081444.2907.6.camel@localhost.localdomain> <20051013092757.00a4398b.Tommy.Reynolds@MegaCoder.com> <1129293231.28625.31.camel@flatline.devel.redhat.com> <20051014125836.6cfa09d8.Tommy.Reynolds@MegaCoder.com> <1129313368.3848.17.camel@flatline.devel.redhat.com> <20051014154139.6b9b4b67.Tommy.Reynolds@MegaCoder.com> <1129767800.18168.397.camel@erato.phig.org> <1129843997.2973.8.camel@localhost.localdomain> <20051020164859.6bdad5df.Tommy.Reynolds@MegaCoder.com> <1129846616.2973.18.camel@localhost.localdomain> <20051020180104.2d2cc8aa.Tommy.Reynolds@MegaCoder.com> <1129897641.18168.582.camel@erato.phig.org> Message-ID: <20051021110601.49ab9f80.Tommy.Reynolds@MegaCoder.com> Uttered Karsten Wade , spake thus: > > What am I missing? > 3) People who want to use the FDP structure to write their own > documentation. > > They don't necessarily care a whit about our content, so CVS access and > associated is not valuable. Having a complete document building > environment is. Ah! Clarity! "I see", said the blind man. Much grass. The key to cleanly producing the three RPM flavors your mentioned is to provide a unique .spec.in for each type. In the "%install" section for a flavor, we can hide all the sed/awk/install-fu we will need. Leave the "Makefile" and "Makefile.common" pretty much unchanged and transform any necessary paths from the spec file. I'll give this some thought, now that I understand the need. Cheers -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From kwade at redhat.com Fri Oct 21 16:07:24 2005 From: kwade at redhat.com (Karsten Wade) Date: Fri, 21 Oct 2005 09:07:24 -0700 Subject: establishing a timezone for FDP In-Reply-To: <1129906187.15431.122.camel@baythorne.infradead.org> References: <1129905837.18168.689.camel@erato.phig.org> <1129906187.15431.122.camel@baythorne.infradead.org> Message-ID: <1129910844.18168.701.camel@erato.phig.org> On Fri, 2005-10-21 at 15:49 +0100, David Woodhouse wrote: > On Fri, 2005-10-21 at 07:43 -0700, Karsten Wade wrote: > > 24 October 17:00 Easter Time > > > > Does this make sense? > > Make sense? It has absolutely no meaning to me at all. Well, that's fine, and we can just as easily all say UTC. You know why I do this practice, not because it is right or good, but because it resolves most easily in the greatest percentage of Red Hat brains. I know, I know, the higher calling is to teach the best practice. What else I want to know is, what is the right time to set a deadline? * One minute before midnight * Midnight * Noon * COB in UTC * Other From when do you start counting days? There has to be some balance between intuitive and always having to calculate your local timezone and how many real days it is to you. Is this possible, given our limitations? - Karsten -- Karsten Wade, RHCE * Sr. Tech Writer * http://people.redhat.com/kwade/ gpg fingerprint: 2680 DBFD D968 3141 0115 5F1B D992 0E06 AD0E 0C41 Red Hat SELinux Guide http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/selinux-guide/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From sopwith at redhat.com Fri Oct 21 16:13:17 2005 From: sopwith at redhat.com (Elliot Lee) Date: Fri, 21 Oct 2005 12:13:17 -0400 (EDT) Subject: Fedora web team Message-ID: Hey all, It seems like there are at least a few people who are interested in reworking the Fedora web site. I think it would be good to have more coordination on our efforts. So, please visit: http://fedoraproject.org/wiki/Fedora/Web and let's all get together and figure things out. This may just be my way of catching up with everyone else who is already working nicely together - please bring me up to speed. :) Best, -- Elliot From Tommy.Reynolds at MegaCoder.com Fri Oct 21 16:06:01 2005 From: Tommy.Reynolds at MegaCoder.com (Tommy Reynolds) Date: Fri, 21 Oct 2005 11:06:01 -0500 Subject: Test of Docs Packaging In-Reply-To: <1129897641.18168.582.camel@erato.phig.org> References: <1129072200.3562.16.camel@localhost.localdomain> <1129081444.2907.6.camel@localhost.localdomain> <20051013092757.00a4398b.Tommy.Reynolds@MegaCoder.com> <1129293231.28625.31.camel@flatline.devel.redhat.com> <20051014125836.6cfa09d8.Tommy.Reynolds@MegaCoder.com> <1129313368.3848.17.camel@flatline.devel.redhat.com> <20051014154139.6b9b4b67.Tommy.Reynolds@MegaCoder.com> <1129767800.18168.397.camel@erato.phig.org> <1129843997.2973.8.camel@localhost.localdomain> <20051020164859.6bdad5df.Tommy.Reynolds@MegaCoder.com> <1129846616.2973.18.camel@localhost.localdomain> <20051020180104.2d2cc8aa.Tommy.Reynolds@MegaCoder.com> <1129897641.18168.582.camel@erato.phig.org> Message-ID: <20051021110601.49ab9f80.Tommy.Reynolds@MegaCoder.com> Uttered Karsten Wade , spake thus: > > What am I missing? > 3) People who want to use the FDP structure to write their own > documentation. > > They don't necessarily care a whit about our content, so CVS access and > associated is not valuable. Having a complete document building > environment is. Ah! Clarity! "I see", said the blind man. Much grass. The key to cleanly producing the three RPM flavors your mentioned is to provide a unique .spec.in for each type. In the "%install" section for a flavor, we can hide all the sed/awk/install-fu we will need. Leave the "Makefile" and "Makefile.common" pretty much unchanged and transform any necessary paths from the spec file. I'll give this some thought, now that I understand the need. Cheers -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Tommy.Reynolds at MegaCoder.com Fri Oct 21 16:20:17 2005 From: Tommy.Reynolds at MegaCoder.com (Tommy Reynolds) Date: Fri, 21 Oct 2005 11:20:17 -0500 Subject: Saxon, FOP, and xmlto Message-ID: <20051021112017.c0ef4870.Tommy.Reynolds@MegaCoder.com> Hello, List! While thinking about finetuning our toolchain, bringing it more into line with what the Red Hatters are using, it looks as if FOP is the future. Along with that, the most up-to-date XSLT tool seems to be saxon. This leads me to the questions: 1) Has anyone here personally used saxon? Can you share your favorite command line with us? 2) Does anyone know when / if FOP will become part of the mainline distro? Cheers -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From kwade at redhat.com Fri Oct 21 16:35:37 2005 From: kwade at redhat.com (Karsten Wade) Date: Fri, 21 Oct 2005 09:35:37 -0700 Subject: Fedora web team In-Reply-To: References: Message-ID: <1129912537.18168.707.camel@erato.phig.org> On Fri, 2005-10-21 at 12:13 -0400, Elliot Lee wrote: > Hey all, > > It seems like there are at least a few people who are interested in > reworking the Fedora web site. I think it would be good to have more > coordination on our efforts. So, please visit: > http://fedoraproject.org/wiki/Fedora/Web > and let's all get together and figure things out. > > This may just be my way of catching up with everyone else who is already > working nicely together - please bring me up to speed. :) I purposely did not put on the regular base fields for the new fedora- websites component. I want to have our teams triage the bugs first, then escalate appropriate ones to you/other sudoers. So, there is the beginning of a process. :) I also tried to define what are "Formal" websites, within the bugzilla description ... which doesn't show up anywhere except in CVS, right now: "Problems and requests for all formal Fedora Project websites. This list is currently: fedoraproject.org and fedora.redhat.com." We can add to that description, but the site has to be one we control, obviously. - Karsten -- Karsten Wade, RHCE * Sr. Tech Writer * http://people.redhat.com/kwade/ gpg fingerprint: 2680 DBFD D968 3141 0115 5F1B D992 0E06 AD0E 0C41 Red Hat SELinux Guide http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/selinux-guide/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From nman64 at n-man.com Fri Oct 21 16:49:17 2005 From: nman64 at n-man.com (Patrick Barnes) Date: Fri, 21 Oct 2005 11:49:17 -0500 Subject: establishing a timezone for FDP In-Reply-To: <1129910844.18168.701.camel@erato.phig.org> References: <1129905837.18168.689.camel@erato.phig.org> <1129906187.15431.122.camel@baythorne.infradead.org> <1129910844.18168.701.camel@erato.phig.org> Message-ID: <43591C0D.4000307@n-man.com> Karsten Wade wrote: > On Fri, 2005-10-21 at 15:49 +0100, David Woodhouse wrote: > >> On Fri, 2005-10-21 at 07:43 -0700, Karsten Wade wrote: >> >>> 24 October 17:00 Easter Time >>> >>> Does this make sense? >>> >> Make sense? It has absolutely no meaning to me at all. >> > > Well, that's fine, and we can just as easily all say UTC. > > You know why I do this practice, not because it is right or good, but > because it resolves most easily in the greatest percentage of Red Hat > brains. > > I know, I know, the higher calling is to teach the best practice. > > What else I want to know is, what is the right time to set a deadline? > > * One minute before midnight > * Midnight > * Noon > * COB in UTC > * Other > > From when do you start counting days? > > There has to be some balance between intuitive and always having to > calculate your local timezone and how many real days it is to you. Is > this possible, given our limitations? > > - Karsten > I certainly agree with David on this one. UTC works great. As far as deadlines, 23:59 UTC is pretty standard and also works well. The date can also be easily tracked with UTC. Once someone learns the appropriate offset, all conversions become easy. Since daylight savings does not affect UTC, that hassle is eliminated. Since different regions treat daylight savings differently, that causes a lot of confusion. Conversions against UTC are going to be a lot easier for anyone outside of U.S. Eastern Time. Even if a large number of participants are in U.S. Eastern Time, there are many who are not. If we make a habit of using U.S. Eastern Time now, it may also complicate things in the future as the participation becomes even more widespread. Although the conversion is easy for me (+/- 1 hour), what about participants in Australia? India? There's no reason to make them learn U.S. Eastern Time rules. It is easy enough for people in the eastern U.S. to learn when to adjust +/- 4/5 hours. Any time we must specify a local time, it is also best to specify the offset (eg. RFC-2822: Fri, 21 Oct 2005 23:59:00 -0400). Let's stick to global standards as much as possible. The same applies to other regional considerations. ISO dates (YYYY-MM-DD), common currencies (U.S.D. & Euro), metric measurements, etc. should be preferred. We adhere to standards in our software, why not our communications? -- Patrick "The N-Man" Barnes nman64 at n-man.com www.n-man.com -- -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From stickster at gmail.com Fri Oct 21 17:02:41 2005 From: stickster at gmail.com (Paul W. Frields) Date: Fri, 21 Oct 2005 13:02:41 -0400 Subject: establishing a timezone for FDP In-Reply-To: <43591C0D.4000307@n-man.com> References: <1129905837.18168.689.camel@erato.phig.org> <1129906187.15431.122.camel@baythorne.infradead.org> <1129910844.18168.701.camel@erato.phig.org> <43591C0D.4000307@n-man.com> Message-ID: <1129914162.2994.12.camel@localhost.localdomain> On Fri, 2005-10-21 at 11:49 -0500, Patrick Barnes wrote: [..snip...] > ... Let's stick to global standards as much as possible. > > The same applies to other regional considerations. ISO dates > (YYYY-MM-DD), common currencies (U.S.D. & Euro), metric measurements, > etc. should be preferred. We adhere to standards in our software, why > not our communications? Concur here. -- 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/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From hballal at gmail.com Fri Oct 21 21:51:00 2005 From: hballal at gmail.com (Hrishikesh Ballal) Date: Fri, 21 Oct 2005 17:51:00 -0400 Subject: Self-Introduction: Hrishikesh Ballal Message-ID: <1129931461.2570.2.camel@localhost.localdomain> Name: Hrishikesh Ballal Location: Eastern Time Zone, USA Profession: Process Specialist Your goals in the Fedora Project I wish to contribute to the web / infrastructure team. I have intermediate coding skills and am looking to contribute with the website and other web related backend systems. Historical qualifications What other projects or writing have you worked on in the past? - I have worked on the new design on www.fedoraproject.org website, wiki and other components of the website including Fedora Accounts System. - I have worked with Yumex with some documentation and am currently helping the project with testing and optimization. - I am currently working on www.fedoratracker.org Anything else special? Nope. Everything else is at http://www.hrishikeshballal.net/ http://www.fedoraproject.org/wiki/HrishikeshBallal What level and type of computer skills do you have? As far as Fedora is concerned, I have intermediate coding skills in Python, PHP, SQL. What other skills do you have that might be applicable? User interface design, other so-called soft skills (people skills), programming, etc. I have project management and project planning skills. Professionally, I am involved in optimizing IT systems and processes. I have experience in process control, optimization and feedback systems. GPG KeyID and Fingerprint pub 1024D/DECEE55D 2005-06-16 Key fingerprint = D2F7 2117 6C27 519A 3FA3 A2C5 5934 5083 DECE E55D uid Hrishikesh Ballal sub 1024g/CE27A608 2005-06-16 From bbbush.yuan at gmail.com Sat Oct 22 06:17:43 2005 From: bbbush.yuan at gmail.com (Yuan Yijun) Date: Sat, 22 Oct 2005 14:17:43 +0800 Subject: Self-Introduction: Yuan Yijun Message-ID: <76e72f800510212317q32f7577fj@mail.gmail.com> Name: Yuan Yijun (???, in Chinese) City & Country: Shenzhen, Guangdong, China (tz: +0800) Profession: Programmer Company: Morningstar, Inc. Your goals in the Fedora Project - I want to help document translation. I want to see more Chinese documents in fedora. Historical qualifications - I contributed some translations to Chinese Man Page Project (http://cmpp.linuxforum.net ), include bash.1, etc. - I'm working on http://fedora.gro.clinux.org Computer skills - I'm a linux user since redhat 7.3. - I will become a excellent c++ programmer. GPG KEYID and fingerprint pub 1024D/83349285 2005-10-22 [expires: 2007-01-01] Key fingerprint = DCCE E98A DBBC 71F6 57D8 C2BA CF7A 52BD 8334 9285 uid Yuan Yijun (bbbush) sub 2048g/CDB2236B 2005-10-22 [expires: 2007-01-01] -- bbbush ^_^ From nman64 at n-man.com Sat Oct 22 15:43:43 2005 From: nman64 at n-man.com (Patrick Barnes) Date: Sat, 22 Oct 2005 10:43:43 -0500 Subject: Self-Introduction: Yuan Yijun In-Reply-To: <76e72f800510212317q32f7577fj@mail.gmail.com> References: <76e72f800510212317q32f7577fj@mail.gmail.com> Message-ID: <435A5E2F.6030001@n-man.com> Yuan Yijun wrote: > Name: Yuan Yijun (???, in Chinese) > City & Country: Shenzhen, Guangdong, China (tz: +0800) > Profession: Programmer > Company: Morningstar, Inc. > > Your goals in the Fedora Project > - I want to help document translation. I want to see more Chinese > documents in fedora. > > Historical qualifications > - I contributed some translations to Chinese Man Page Project > (http://cmpp.linuxforum.net ), include bash.1, etc. > - I'm working on http://fedora.gro.clinux.org > Computer skills > - I'm a linux user since redhat 7.3. > - I will become a excellent c++ programmer. > > GPG KEYID and fingerprint > pub 1024D/83349285 2005-10-22 [expires: 2007-01-01] > Key fingerprint = DCCE E98A DBBC 71F6 57D8 C2BA CF7A 52BD 8334 9285 > uid Yuan Yijun (bbbush) > sub 2048g/CDB2236B 2005-10-22 [expires: 2007-01-01] > > > > > > -- > bbbush ^_^ > > Welcome to the team, ???. Have you created a wiki account? You might also be interested in some of the other list options - http://fedoraproject.org/wiki/Communicate -- Patrick "The N-Man" Barnes nman64 at n-man.com www.n-man.com -- -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From bbbush.yuan at gmail.com Sun Oct 23 07:06:07 2005 From: bbbush.yuan at gmail.com (Yuan Yijun) Date: Sun, 23 Oct 2005 15:06:07 +0800 Subject: Self-Introduction: Yuan Yijun In-Reply-To: <435A5E2F.6030001@n-man.com> References: <76e72f800510212317q32f7577fj@mail.gmail.com> <435A5E2F.6030001@n-man.com> Message-ID: <76e72f800510230006h73bcf8cdw@mail.gmail.com> 2005/10/22, Patrick Barnes : > Welcome to the team, ???. Have you created a wiki account? You > might also be interested in some of the other list options - > http://fedoraproject.org/wiki/Communicate > Yes, I have a wiki account 'YuanYijun' but I cannot create my personal page,:( and this account info is not required in the Self-Introduction instructions right? -- bbbush ^_^ From nman64 at n-man.com Sun Oct 23 07:26:49 2005 From: nman64 at n-man.com (Patrick Barnes) Date: Sun, 23 Oct 2005 02:26:49 -0500 Subject: Self-Introduction: Yuan Yijun In-Reply-To: <76e72f800510230006h73bcf8cdw@mail.gmail.com> References: <76e72f800510212317q32f7577fj@mail.gmail.com> <435A5E2F.6030001@n-man.com> <76e72f800510230006h73bcf8cdw@mail.gmail.com> Message-ID: <435B3B39.3020908@n-man.com> Yuan Yijun wrote: > 2005/10/22, Patrick Barnes : > >> Welcome to the team, ???. Have you created a wiki account? You >> might also be interested in some of the other list options - >> http://fedoraproject.org/wiki/Communicate >> >> > > Yes, I have a wiki account 'YuanYijun' but I cannot create my personal > page,:( and this account info is not required in the Self-Introduction > instructions right? > > > -- > bbbush ^_^ > > I've added you to the EditGroup, so you can create your wiki homepage now. Although that information is not (yet) explicitly required, it is strongly encouraged. -- Patrick "The N-Man" Barnes nman64 at n-man.com www.n-man.com -- -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From bbbush.yuan at gmail.com Sun Oct 23 07:39:09 2005 From: bbbush.yuan at gmail.com (Yuan Yijun) Date: Sun, 23 Oct 2005 15:39:09 +0800 Subject: Self-Introduction: Yuan Yijun In-Reply-To: <435B3B39.3020908@n-man.com> References: <76e72f800510212317q32f7577fj@mail.gmail.com> <435A5E2F.6030001@n-man.com> <76e72f800510230006h73bcf8cdw@mail.gmail.com> <435B3B39.3020908@n-man.com> Message-ID: <76e72f800510230039x4ba04ffu@mail.gmail.com> 2005/10/23, Patrick Barnes : > I've added you to the EditGroup, so you can create your wiki homepage > now. Although that information is not (yet) explicitly required, it is > strongly encouraged. > Thank you very much. And that link is pretty helpful, :) -- bbbush ^_^ From kwade at redhat.com Mon Oct 24 14:19:38 2005 From: kwade at redhat.com (Karsten Wade) Date: Mon, 24 Oct 2005 07:19:38 -0700 Subject: release-notes Makefile,1.1,1.2 In-Reply-To: <200510241408.j9OE8vhT017956@cvs-int.fedora.redhat.com> References: <200510241408.j9OE8vhT017956@cvs-int.fedora.redhat.com> Message-ID: <1130163578.5528.103.camel@erato.phig.org> Tommy or Paul: Can you look at this change and give us a better way to do it? Or am I missing the existence of this functionality in Makefile.common? thx - Karsten On Mon, 2005-10-24 at 10:08 -0400, Karsten Wade wrote: > Author: kwade > > Update of /cvs/docs/release-notes > In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv17937 > > Modified Files: > Makefile > Log Message: > Need to find a way to do this better, and I think it should be in the Makefile.common instead. However, my method here is obviously sub-par and throws an error, so I'll be punting for help. The objective is to make certain that the figs/ directory gets copied over to the HTML directories in all languages. Actually, the figs-/ needs to get copied to foo-/ HTML directory. This requires some consideration and kung-fu. It should copy over the language specific figures if they exist, otherwise use the English by default so as to not break the build. > > > Index: Makefile > =================================================================== > RCS file: /cvs/docs/release-notes/Makefile,v > retrieving revision 1.1 > retrieving revision 1.2 > diff -u -r1.1 -r1.2 > --- Makefile 24 Oct 2005 13:13:33 -0000 1.1 > +++ Makefile 24 Oct 2005 14:08:53 -0000 1.2 > @@ -1,90 +1,100 @@ > -LANG = en > -DOCS_SETUP_PATH= ../../docs-common > -XSLPDF = $(DOCS_SETUP_PATH)/xsl/main-pdf.xsl > -XSLHTML = $(DOCS_SETUP_PATH)/xsl/main-html-nochunks-relnotes.xsl > - > -XSLPDFCOMMONS = ${XSLPDF} > -XSLHTMLCOMMONS = ${XSLHTML} > - > -XMLCOMMONSPATH=${DOCS_SETUP_PATH}/common > -XMLCOMMONS=${XMLCOMMONSPATH}/cvs-en.xml \ > - ${XMLCOMMONSPATH}/draftnotice-en.xml \ > - ${XMLCOMMONSPATH}/fedora-entities-en.ent \ > - ${XMLCOMMONSPATH}/fedora-entities-en.xml \ > - ${XMLCOMMONSPATH}/legacynotice-en.xml \ > - ${XMLCOMMONSPATH}/legalnotice-en.xml \ > - ${XMLCOMMONSPATH}/obsoletenotice-en.xml > - > -.SUFFIXES: > -.SUFFIXES: .html .pdf .xml > - > -all: README-${LANG}.html \ > - RELEASE-NOTES-${LANG}.html \ > - RELEASE-NOTES-${LANG}.txt \ > - README-${LANG}.txt > - > -#README-${LANG}.pdf RELEASE-NOTES-${LANG}.pdf > - > -%.pdf: %.xml > - xmlto pdf -x ${XSLPDF} $< > - > -%.html: %.xml > - ${RM} -r ${@:.html=} > - xmlto html -x ${XSLHTML} -o ${@:.html=} $< > - mkdir -p ${@:.html=}/stylesheet-images > - mkdir -p ${@:.html=}/figs > - cp $(DOCS_SETUP_PATH)/stylesheet-images/*.png ${@:.html=}/stylesheet-images > - cp ./figs/*.png ${@:.html=}/figs > - cp $(DOCS_SETUP_PATH)/css/fedora.css ${@:.html=} > - mv ${@:.html=}/${@:.html=.proc} ${@:.html=}/$@ > - ln -sf ${@:.html=}/$@ $@ > - > -%.txt: %.xml > - xmlto txt $< > -# mv $@ RELEASE-NOTES-${LANG} > - > -# FIXME eula.txt: eula.py > -# FIXME python -c "import py_compile; py_compile.compile('eula.py')" > - > -# Note: keep "RELEASE-NOTES-en.xml" first, for now. > - > -RNFILES=RELEASE-NOTES-en.xml daemons.xml database-servers.xml \ > - desktop.xml development-tools.xml feedback.xml file-servers.xml \ > - file-systems.xml hardware-reqs.xml install-notes.xml intro.xml \ > - java-package.xml kernel.xml misc-server.xml multimedia.xml \ > - networking.xml overview.xml package-movement.xml \ > - package-notes.xml printing.xml project-overview.xml samba.xml \ > - security.xml server-tools.xml splash.xml web-servers.xml \ > - xorg.xml > - > -# README-${LANG}.pdf: README-en.xml > -# README-${LANG}.html: README-en.xml > -RELEASE-NOTES-${LANG}.pdf: ${RNFILES} ${XMLCOMMONS} ${XSLPDFCOMMONS} > -RELEASE-NOTES-${LANG}.html: ${RNFILES} ${XMLCOMMONS} ${XSLHTMLCOMMONS} > -RELEASE-NOTES-${LANG}.txt: ${RNFILES} ${XMLCOMMONS} > - > -clean: > - ${RM} ChangeLog ChangeLog.xml > - > -distclean clobber: clean > - ${RM} ChangeLog-${LANG}.html ChangeLog.txt > - ${RM} -r README-${LANG}.pdf README-${LANG}.html README-${LANG}.txt > - ${RM} -r RELEASE-NOTES-${LANG}.pdf RELEASE-NOTES-${LANG}.html \ > - RELEASE-NOTES-${LANG} RELEASE-NOTES-${LANG}.txt > - > -# If you have the "cvs2cl" package installed, then you can make > -# fancy HTML ChangeLogs > - > -ChangeLogs: > - ${RM} ChangeLog* > - ${MAKE} ChangeLog.txt > - ${MAKE} ChangeLog-${LANG}.html > - > -ChangeLog.txt: > - LANG=C cvs2cl -f ChangeLog.txt > - > -ChangeLog.xml: > - LANG=C cvs2cl --xml --xml-encoding UTF-8 -f ChangeLog.xml > - > -ChangeLog-${LANG}.html: ChangeLog.xml > - xsltproc -o $@ /usr/share/xml/cvs2cl/cl2html.xslt $< > +############################################################################### > +# Makefile for RHLP docs project > +# Created by: Tammy Fox > +# Last edited by: Tommy Reynolds > +# WARNING: need passivetex 1.24 for pdf generation to work > +# License: GPL > +# Copyright 2003 Tammy Fox, Red Hat, Inc. > +# Copyright 2005 Tommy Reynolds, MegaCoder.com > +############################################################################### > +# > +# Document-specific definitions. > +# > +LANGUAGES = en > +DOCBASE = RELEASE-NOTES > +XMLEXTRAFILES-en=daemons.xml database-servers.xml desktop.xml development-tools.xml feedback.xml file-servers.xml file-systems.xml hardware-reqs.xml install-notes.xml intro.xml java-package.xml kernel.xml misc-server.xml multimedia.xml networking.xml overview.xml package-movement.xml package-notes.xml printing.xml project-overview.xml samba.xml security.xml server-tools.xml splash.xml web-servers.xml xorg.xml > +# > +###################################################### > +include ../docs-common/Makefile.common > +###################################################### > +# > +# If you want to add additional steps to any of the > +# targets defined in "Makefile.common", be sure to use > +# a double-colon in your rule here. For example, to > +# print the message "FINISHED AT LAST" after building > +# the HTML document version, uncomment the following > +# line: > +#${DOCBASE}-en/index.html:: > +# echo FINISHED AT LAST > + > +# Need to copy over the figures for this directory. Should > +# this be a common action instead? > +${DOCBASE}-en/index.html:: > + mkdir -p ${DOCBASE}-${LANGUAGES}/figs > + cp figs/* ${DOCBASE}-${LANGUAGES}/figs > + > +###################################################### > +# Some packaging specific vars > +VERSION=$(shell grep BOOKID $(DOCBASE)-en.xml | sed 's/ +DATE=${shell grep BOOKID $(DOCBASE)-en.xml | sed 's/.\+(//' | sed 's/).\+//' } > +NOW=$(shell date +"%a %b %e %Y") > +SPECIN=../docs-common/packaging/fedora-doc.spec.in.common > +OMFIN=../docs-common/packaging/fedora-doc.omf.in.common > +DESKTOPIN=../docs-common/packaging/fedora-doc.desktop.in.common > +DOCSPEC=$(PWD)/SPECS/$(DOCBASE).spec > +DOCOMF=$(PWD)/SOURCES/fedora-doc-$(DOCBASE)-C.omf > +DOCDESKTOP=$(PWD)/SOURCES/fedora-doc-$(DOCBASE).desktop > +DOCSRCTAR=$(PWD)/SOURCES/$(DOCBASE)-$(VERSION).src.tar.gz > +TITLE=$(shell ../docs-common/packaging/titlegrab.py $(DOCBASE)-en.xml | sed 's/^ \+//') > +###################################################### > +# Some RPM flags... > +###################################################### > +RPMFLAGS=--define "docbase $(DOCBASE)" --define "version $(VERSION)" --define "_topdir $(PWD)" > +###################################################### > + > + > +clean:: > + rm -rf fedora-doc-$(DOCBASE)*.rpm > + > + > +rpm: clean > +# > +# Make RPM-compliant tarball of source XML and other stuff > + mkdir $(DOCBASE)-$(VERSION) > + find . -maxdepth 1 -type f ! \( -name '*~' -o -name 'Makefile*' \) \ > + | cpio -pamdv $(DOCBASE)-$(VERSION) > + find . -maxdepth 1 -type d ! \( -name '$(DOCBASE)-$(VERSION)' \ > + -o -name 'CVS' -o -name '*~' -o -name '$(DOCBASE)*' \) \ > + | cpio -pamdv $(DOCBASE)-$(VERSION) > +# > +# Make RPM build tree; don't rely on local user's setup > + mkdir -p {BUILD,RPMS/noarch,SOURCES,SPECS,SRPMS} > + tar -zcvf $(DOCSRCTAR) $(DOCBASE)-$(VERSION) > + rm -rf $(DOCBASE)-$(VERSION)/ > +# > +# Make rpmlint happy with a changelog entry > +# FIXME: Maybe more magic would make this stickier; pity > +# I'm no magician... > + sed 's/\(%changelog\)/\1\n* $(NOW) Fedora Docs Project - $(VERSION)-1\n- Update to version $(VERSION)\n/' \ > + $(SPECIN) > $(DOCSPEC) > +# > +# Fill in files > +# FIXME: Needs to be multiplexed for LANGUAGES (see above) > + cp $(OMFIN) $(DOCOMF) > + cp $(DESKTOPIN) $(DOCDESKTOP) > + sed -i 's/@VERSION@/$(VERSION)/g' $(DOCOMF) > + sed -i 's/@DATE@/$(DATE)/g' $(DOCOMF) > + sed -i 's/@TITLE@/$(TITLE)/g' $(DOCOMF) > + sed -i 's/@DOCBASE@/$(DOCBASE)/g' $(DOCOMF) > + sed -i 's/@VERSION@/$(VERSION)/g' $(DOCDESKTOP) > + sed -i 's/@DATE@/$(DATE)/g' $(DOCDESKTOP) > + sed -i 's/@TITLE@/$(TITLE)/g' $(DOCDESKTOP) > + sed -i 's/@DOCBASE@/$(DOCBASE)/g' $(DOCDESKTOP) > +# > +# Do the build... > +# > + rpmbuild -bb $(RPMFLAGS) $(DOCSPEC) > + mv RPMS/noarch/*.rpm . > + rpmbuild --clean --rmsource $(RPMFLAGS) $(DOCSPEC) > + rm -rf {BUILD,RPMS,SOURCES,SPECS,SRPMS} > + rm -rf $(DOCBASE)-$(VERSION) > > -- > Fedora-docs-commits mailing list > Fedora-docs-commits at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-docs-commits -- Karsten Wade, RHCE * Sr. Tech Writer * http://people.redhat.com/kwade/ gpg fingerprint: 2680 DBFD D968 3141 0115 5F1B D992 0E06 AD0E 0C41 Red Hat SELinux Guide http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/selinux-guide/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From kwade at redhat.com Mon Oct 24 14:36:18 2005 From: kwade at redhat.com (Karsten Wade) Date: Mon, 24 Oct 2005 07:36:18 -0700 Subject: establishing a timezone for FDP In-Reply-To: <1129914162.2994.12.camel@localhost.localdomain> References: <1129905837.18168.689.camel@erato.phig.org> <1129906187.15431.122.camel@baythorne.infradead.org> <1129910844.18168.701.camel@erato.phig.org> <43591C0D.4000307@n-man.com> <1129914162.2994.12.camel@localhost.localdomain> Message-ID: <1130164578.5528.118.camel@erato.phig.org> On Fri, 2005-10-21 at 13:02 -0400, Paul W. Frields wrote: > On Fri, 2005-10-21 at 11:49 -0500, Patrick Barnes wrote: > [..snip...] > > ... Let's stick to global standards as much as possible. > > > > The same applies to other regional considerations. ISO dates > > (YYYY-MM-DD), common currencies (U.S.D. & Euro), metric measurements, > > etc. should be preferred. We adhere to standards in our software, why > > not our communications? > > Concur here. I have seen the error of my provincial thinking. Henceforth, we are adhering to all such standards, including the metric system.[1] The FDP timezone is UTC. The default FDP deadline is 23:59 UTC on the day specified. This is done to make the timing unambiguous. Thanks - Karsten [1] GIYF -- http://www.google.com/search?q=98.6+F+in+C -- Karsten Wade, RHCE * Sr. Tech Writer * http://people.redhat.com/kwade/ gpg fingerprint: 2680 DBFD D968 3141 0115 5F1B D992 0E06 AD0E 0C41 Red Hat SELinux Guide http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/selinux-guide/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From kwade at redhat.com Mon Oct 24 14:39:58 2005 From: kwade at redhat.com (Karsten Wade) Date: Mon, 24 Oct 2005 07:39:58 -0700 Subject: invitation to hack the relnotes tonight Message-ID: <1130164798.5528.123.camel@erato.phig.org> I was unable to work on the relnotes this weekend, and we have had a temporary staffing shortage for the release notes team. For both of these reasons, I have extended the freeze for translation by seven hours, to give me time to sweep the relnotes together for trans for FC5 test1. Highlights: * Patrick did some tricky coolness to get us Wiki > XML, gracias * First pull from Wiki beats into relnotes * New structure in CVS If you are interested in this, I'll be on #fedora-docs working on this starting after Midnight UTC (25 October). - Karsten -- Karsten Wade, RHCE * Sr. Tech Writer * http://people.redhat.com/kwade/ gpg fingerprint: 2680 DBFD D968 3141 0115 5F1B D992 0E06 AD0E 0C41 Red Hat SELinux Guide http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/selinux-guide/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From stickster at gmail.com Mon Oct 24 14:47:09 2005 From: stickster at gmail.com (Paul W. Frields) Date: Mon, 24 Oct 2005 10:47:09 -0400 Subject: release-notes Makefile,1.1,1.2 In-Reply-To: <1130163578.5528.103.camel@erato.phig.org> References: <200510241408.j9OE8vhT017956@cvs-int.fedora.redhat.com> <1130163578.5528.103.camel@erato.phig.org> Message-ID: <1130165229.3022.2.camel@localhost.localdomain> On Mon, 2005-10-24 at 07:19 -0700, Karsten Wade wrote: > Tommy or Paul: > > Can you look at this change and give us a better way to do it? Or am I > missing the existence of this functionality in Makefile.common? Could I suggest you drop all the RPM packaging stuff off this Makefile for now? It is only entered in example-tutorial for testing purposes and shouldn't be used elsewhere for now. That really has nothing to do with your request, just a point of order. As for the actual request, Tommy's the one with the kung-fu. I have something more like kung-splat (q.v. aforementioned packaging munge) so I doubt you want me working on this particular facet, at least if you want it done well. -- 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/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From Tommy.Reynolds at MegaCoder.com Mon Oct 24 15:33:29 2005 From: Tommy.Reynolds at MegaCoder.com (Tommy Reynolds) Date: Mon, 24 Oct 2005 10:33:29 -0500 Subject: release-notes Makefile,1.1,1.2 In-Reply-To: <1130163578.5528.103.camel@erato.phig.org> References: <200510241408.j9OE8vhT017956@cvs-int.fedora.redhat.com> <1130163578.5528.103.camel@erato.phig.org> Message-ID: <20051024103329.2e4adf70.Tommy.Reynolds@MegaCoder.com> Uttered Karsten Wade , spake thus: > Can you look at this change and give us a better way to do it? Or am I > missing the existence of this functionality in Makefile.common? I'm looking, I'm looking! Cheers -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From bbbush.yuan at gmail.com Tue Oct 25 01:23:20 2005 From: bbbush.yuan at gmail.com (Yuan Yijun) Date: Tue, 25 Oct 2005 09:23:20 +0800 Subject: About release-notes, what should translators commit to cvs? Message-ID: <76e72f800510241823t6a591718r@mail.gmail.com> a single release-notes-xxx.xml file? or multiple xml files each in correspondence with an xml in the cvs? There are so many xml files which don't have a -en suffix in name. -- bbbush ^_^ From kwade at redhat.com Tue Oct 25 02:48:02 2005 From: kwade at redhat.com (Karsten Wade) Date: Mon, 24 Oct 2005 19:48:02 -0700 Subject: About release-notes, what should translators commit to cvs? In-Reply-To: <76e72f800510241823t6a591718r@mail.gmail.com> References: <76e72f800510241823t6a591718r@mail.gmail.com> Message-ID: <1130208482.12794.8.camel@erato.phig.org> On Tue, 2005-10-25 at 09:23 +0800, Yuan Yijun wrote: > a single release-notes-xxx.xml file? or multiple xml files each in > correspondence with an xml in the cvs? There are so many xml files > which don't have a -en suffix in name. Oh, I hate renaming in CVS. :) This has been solved, it was a silly mistake of mine to not fix this when redoing the module today. All of the English files have -en suffixes, and yes, there are a lot of them. Each top level
has its own file, which corresponds to a writing beat. - Karsten -- Karsten Wade, RHCE * Sr. Tech Writer * http://people.redhat.com/kwade/ gpg fingerprint: 2680 DBFD D968 3141 0115 5F1B D992 0E06 AD0E 0C41 Red Hat SELinux Guide http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/selinux-guide/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From kwade at redhat.com Tue Oct 25 09:16:07 2005 From: kwade at redhat.com (Karsten Wade) Date: Tue, 25 Oct 2005 02:16:07 -0700 Subject: FC5 test1 relnotes for translation Message-ID: <1130231767.12794.26.camel@erato.phig.org> Now ready in CVS, tagged as "FC-5-TEST1-TRANS-FREEZE". Someone here can correct me, but I believe you do this: echo $CVSROOT :ext:username at cvs.fedora.redhat.com:/cvs/docs cvs co -r FC-5-TEST1-TRANS-FREEZE -d release-notes-FC5test1 release notes Be sure to grab that tagged branch, as we will probably be adding to the HEAD (and tagging, eventually, as FC-5-TEST1-LATEST. cheers - Karsten -- Karsten Wade, RHCE * Sr. Tech Writer * http://people.redhat.com/kwade/ gpg fingerprint: 2680 DBFD D968 3141 0115 5F1B D992 0E06 AD0E 0C41 Red Hat SELinux Guide http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/selinux-guide/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From tsekine at sdri.co.jp Tue Oct 25 09:36:03 2005 From: tsekine at sdri.co.jp (SEKINE tatz Tatsuo) Date: Tue, 25 Oct 2005 19:36:03 +1000 (EST) Subject: FC5 test1 relnotes for translation In-Reply-To: <1130231767.12794.26.camel@erato.phig.org> References: <1130231767.12794.26.camel@erato.phig.org> Message-ID: <20051025.193603.111289002.tsekine@sdri.co.jp> Hi, From: Karsten Wade Date: Tue, 25 Oct 2005 02:16:07 -0700 > echo $CVSROOT > :ext:username at cvs.fedora.redhat.com:/cvs/docs > cvs co -r FC-5-TEST1-TRANS-FREEZE -d release-notes-FC5test1 release notes It could be: cvs co -r FC-5-TEST1-TRANS-FREEZE -d release-notes-FC5test1 release-notes -- SEKINE Tatsuo: tsekine at sdri.co.jp System Design & Research Inst. Co.,Ltd. From nman64 at n-man.com Tue Oct 25 09:58:20 2005 From: nman64 at n-man.com (Patrick Barnes) Date: Tue, 25 Oct 2005 04:58:20 -0500 Subject: FC5 test1 relnotes for translation In-Reply-To: <20051025.193603.111289002.tsekine@sdri.co.jp> References: <1130231767.12794.26.camel@erato.phig.org> <20051025.193603.111289002.tsekine@sdri.co.jp> Message-ID: <435E01BC.7010409@n-man.com> SEKINE "tatz" Tatsuo wrote: > Hi, > > From: Karsten Wade > Date: Tue, 25 Oct 2005 02:16:07 -0700 > > >> echo $CVSROOT >> :ext:username at cvs.fedora.redhat.com:/cvs/docs >> cvs co -r FC-5-TEST1-TRANS-FREEZE -d release-notes-FC5test1 release notes >> > > It could be: > cvs co -r FC-5-TEST1-TRANS-FREEZE -d release-notes-FC5test1 release-notes > > And, if trying to set up the environment, it is necessary to set the appropriate variables, not just view CVSROOT, making the full sequence: export CVS_RSH=ssh export CVSROOT=:ext:username at cvs.fedora.redhat.com:/cvs/docs cvs co -r FC-5-TEST1-TRANS-FREEZE -d release-notes-FC5test1 release-notes Where 'username' is, of course, replaced appropriately. http://fedoraproject.org/wiki/DocsProject/CvsUsage http://cvs.fedora.redhat.com/docs.shtml -- Patrick "The N-Man" Barnes nman64 at n-man.com www.n-man.com -- -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From dwmw2 at infradead.org Tue Oct 25 10:06:57 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Tue, 25 Oct 2005 11:06:57 +0100 Subject: FC5 test1 relnotes for translation In-Reply-To: <435E01BC.7010409@n-man.com> References: <1130231767.12794.26.camel@erato.phig.org> <20051025.193603.111289002.tsekine@sdri.co.jp> <435E01BC.7010409@n-man.com> Message-ID: <1130234817.6932.276.camel@baythorne.infradead.org> On Tue, 2005-10-25 at 04:58 -0500, Patrick Barnes wrote: > Where 'username' is, of course, replaced appropriately. Or simply omitted, for that matter. Having checked out the release notes I see that where I correctly wrote 'MiB' in the RAM requirements for PPC, it's been changed to the more vague and strictly incorrect 'MB'. Was that intentional? -- dwmw2 From bbbush.yuan at gmail.com Tue Oct 25 12:21:02 2005 From: bbbush.yuan at gmail.com (Yuan Yijun) Date: Tue, 25 Oct 2005 20:21:02 +0800 Subject: RELEASE-NOTES-master-en.xml and README-en.xml Message-ID: <76e72f800510250521g11e7b191r@mail.gmail.com> Should I translate RELEASE-NOTES-master-en.xml and README-en.xml even if they are not needed in build? They are so much out-of-date! :) -- bbbush ^_^ From Tommy.Reynolds at MegaCoder.com Tue Oct 25 15:43:21 2005 From: Tommy.Reynolds at MegaCoder.com (Tommy Reynolds) Date: Tue, 25 Oct 2005 10:43:21 -0500 Subject: FC5 test1 relnotes for translation In-Reply-To: <1130231767.12794.26.camel@erato.phig.org> References: <1130231767.12794.26.camel@erato.phig.org> Message-ID: <20051025104321.23396eda.Tommy.Reynolds@MegaCoder.com> Uttered Karsten Wade , spake thus: > Someone here can correct me, but I believe you do this: > echo $CVSROOT > :ext:username at cvs.fedora.redhat.com:/cvs/docs > cvs co -r FC-5-TEST1-TRANS-FREEZE -d release-notes-FC5test1 release notes You need not muck with $CVSROOT for a one-time checkout. Assuming that $CVS_RSH is set to: $ export CVS_RSH=ssh you can first do: $ cvs -d :ext:username at cvs.fedora.redhat.com:/cvs/docs co \ -r FC-5-TEST1-TRANS-FREEZE -d release-notes-FC5test1 \ release_notes $ cd release-notes-FC5test1 and then $ cvs update --or-- $ cvs commit to your heart's content needing neither "$CVSROOT" nor "-d $CVSROOT" again, as long as your $PWD is "release-notes-FC5test1" or deeper. I use a small shell script, "cvs-fdp": ==CUT===CUT===CUT===CUT===CUT===CUT===CUT===CUT== #!/bin/sh CVS_RSH=ssh export CVS_RSH exec cvs -d :ext:username at cvs.fedora.redhat.com:/cvs/docs $@ ==CUT===CUT===CUT===CUT===CUT===CUT===CUT===CUT== and then use it like this: $ cvs-fdp co -d release-notes-FC5test1 release_notes -r \ FC-5-TEST1-TRANS_FREESZE I use this technique for every CVS repository I deal with. Goodbye $CVSROOT, you are evil! Cheers -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mumumu at mumumu.org Tue Oct 25 16:08:28 2005 From: mumumu at mumumu.org (Yoshinari Takaoka) Date: Wed, 26 Oct 2005 01:08:28 +0900 Subject: FC5 test1 relnotes make problem(two xml file broken) Message-ID: <200510260108.28890.mumumu@mumumu.org> hi, all. i checked out fc5 test1 relnotes, and tried to make with the following steps. ---- $ echo $CVSROOT :ext:username at cvs.fedora.redhat.com:/cvs/docs $ cvs co -r FC-5-TEST1-TRANS-FREEZE -d release-notes-FC5test1 release-notes $ cvs co docs-common $ cd release-notes-FC5test1 $ cp RELEASE-NOTES-en.xml RELEASE-NOTES-ja.xml $ vi Makefile ....here, i editied "LANGUAGES" parameter, and replaced 'en' with 'ja'. and tried to make, but i got the following error. ---- $ make LANG=ja.UTF-8 xmlto html -x ../docs-common/xsl/main-html.xsl -o RELEASE-NOTES-ja RELEASE-NOTES-ja.xml xmlto: input does not validate (status 1) /home/mumumu/work/release-notes-FC5test1/package-notes-en.xml:40: parser error : expected '>' ^ /home/mumumu/work/release-notes-FC5test1/package-notes-en.xml:288: parser error : chunk is not well balanced ^ /home/mumumu/work/release-notes-FC5test1/RELEASE-NOTES-ja.xml:74: parser error : chunk is not well balanced &PACKAGE-NOTES; ^ make: *** [RELEASE-NOTES-ja/index.html] error 1 ---- this error was caused because "para" tag was not closed in package-notes-en.xml line 39. http://cvs.fedora.redhat.com/viewcvs/release-notes/package-notes-en.xml?annotate=1.3&root=docs i fixed this and tried once more. but i got error again. ---- $ make LANG=ja.UTF-8 xmlto html -x ../docs-common/xsl/main-html.xsl -o RELEASE-NOTES-ja RELEASE-NOTES-ja.xml xmlto: input does not validate (status 1) /home/mumumu/work/release-notes-FC5test1/package-movement-en.xml:1055: parser error : Opening and ending tag mismatch: para line 1052 and emphasis ) ^ /home/mumumu/work/release-notes-FC5test1/package-movement-en.xml:1056: parser error : Opening and ending tag mismatch: section line 1044 and para ^ /home/mumumu/work/release-notes-FC5test1/package-movement-en.xml:1065: parser error : chunk is not well balanced
^ /home/mumumu/work/release-notes-FC5test1/package-movement-en.xml:1065: parser error : chunk is not well balanced
^ /home/mumumu/work/release-notes-FC5test1/RELEASE-NOTES-ja.xml:76: parser error : chunk is not well balanced &PACKAGE-MOVEMENT; ^ make: *** [RELEASE-NOTES-ja/index.html] error 1 ---- this is because the start "emphasis" tag is missing in package-movement-en.xml line 1055. http://cvs.fedora.redhat.com/viewcvs/release-notes/package-movement-en.xml?annotate=1.3&root=docs i fixed this and tried again. this time, "make" worked fine and i could get release-note-ja directory and tar archive. Regards. -- Yoshinari Takaoka(mumumu at IRC) reversethis -> {gro} {tod} {umumum} {ta} {umumum} From Tommy.Reynolds at MegaCoder.com Tue Oct 25 18:48:57 2005 From: Tommy.Reynolds at MegaCoder.com (Tommy Reynolds) Date: Tue, 25 Oct 2005 13:48:57 -0500 Subject: XMLTO and SAXON In-Reply-To: <1130227071.4304.1.camel@cyberelk.elk> References: <20051023131742.18dfce67.Tommy.Reynolds@MegaCoder.com> <1130152117.4280.1.camel@cyberelk.elk> <20051024095014.bb889950.Tommy.Reynolds@MegaCoder.com> <1130166203.4280.5.camel@cyberelk.elk> <20051024180250.cedfc5d7.Tommy.Reynolds@MegaCoder.com> <1130227071.4304.1.camel@cyberelk.elk> Message-ID: <20051025134857.95fbe673.Tommy.Reynolds@MegaCoder.com> Tim, I've attached my saxon patch, too. It adds a new command line switch (-X saxon) or (-X xsltproc), defaulting to what's in the ${XSLT_PROCESSOR} environment variable and if not set, to "xsltproc", as usual. Lemme know how this works out. All you FDP lot can just ignore these patches for now. I've CC'ed you just to let you know the patches have gone upstream. Cheers -------------- next part -------------- A non-text attachment was scrubbed... Name: xmlto-saxon.patch Type: application/octet-stream Size: 3403 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: xmlto-fop.patch Type: application/octet-stream Size: 12120 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From kwade at redhat.com Tue Oct 25 19:36:25 2005 From: kwade at redhat.com (Karsten Wade) Date: Tue, 25 Oct 2005 12:36:25 -0700 Subject: FC5 test1 relnotes for translation In-Reply-To: <1130234817.6932.276.camel@baythorne.infradead.org> References: <1130231767.12794.26.camel@erato.phig.org> <20051025.193603.111289002.tsekine@sdri.co.jp> <435E01BC.7010409@n-man.com> <1130234817.6932.276.camel@baythorne.infradead.org> Message-ID: <1130268985.12794.118.camel@erato.phig.org> On Tue, 2005-10-25 at 11:06 +0100, David Woodhouse wrote: > On Tue, 2005-10-25 at 04:58 -0500, Patrick Barnes wrote: > > Where 'username' is, of course, replaced appropriately. > > Or simply omitted, for that matter. > > Having checked out the release notes I see that where I correctly wrote > 'MiB' in the RAM requirements for PPC, it's been changed to the more > vague and strictly incorrect 'MB'. Was that intentional? Yes, but not as a position statement in a 'MiB' v. 'MB' debate. It was done to keep the language using the same style as the rest of Fedora Documentation. If your next question is, where is the style guidelines and list of approved word usages? the answer is, it doesn't really exist. Therefore, if you want to influence/convince FDP to use MiB instead of MB, please feel free to do so. Whatever consensus we reach becomes our standard, and we can start a Wiki page on the subject. Again, we would be doing the right thing and trying to lead the way with standards. Makes sense on the face of it. - Karsten -- Karsten Wade, RHCE * Sr. Tech Writer * http://people.redhat.com/kwade/ gpg fingerprint: 2680 DBFD D968 3141 0115 5F1B D992 0E06 AD0E 0C41 Red Hat SELinux Guide http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/selinux-guide/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From kwade at redhat.com Tue Oct 25 19:38:45 2005 From: kwade at redhat.com (Karsten Wade) Date: Tue, 25 Oct 2005 12:38:45 -0700 Subject: FC5 test1 relnotes make problem(two xml file broken) In-Reply-To: <200510260108.28890.mumumu@mumumu.org> References: <200510260108.28890.mumumu@mumumu.org> Message-ID: <1130269125.12794.120.camel@erato.phig.org> On Wed, 2005-10-26 at 01:08 +0900, Yoshinari Takaoka wrote: > hi, all. > > i checked out fc5 test1 relnotes, and tried to make with the following steps. I'm looking into this right now. I guess I can only test in -en but if it works for me ... I'll reply back soon with more info. - Karsten > ---- > > $ echo $CVSROOT > :ext:username at cvs.fedora.redhat.com:/cvs/docs > $ cvs co -r FC-5-TEST1-TRANS-FREEZE -d release-notes-FC5test1 release-notes > $ cvs co docs-common > $ cd release-notes-FC5test1 > $ cp RELEASE-NOTES-en.xml RELEASE-NOTES-ja.xml > $ vi Makefile > > ....here, i editied "LANGUAGES" parameter, and replaced 'en' with 'ja'. > and tried to make, but i got the following error. > > ---- > > $ make > LANG=ja.UTF-8 xmlto html -x ../docs-common/xsl/main-html.xsl -o > RELEASE-NOTES-ja RELEASE-NOTES-ja.xml > xmlto: input does not validate (status 1) > /home/mumumu/work/release-notes-FC5test1/package-notes-en.xml:40: parser > error : expected '>' > > ^ > /home/mumumu/work/release-notes-FC5test1/package-notes-en.xml:288: parser > error : chunk is not well balanced > > ^ > /home/mumumu/work/release-notes-FC5test1/RELEASE-NOTES-ja.xml:74: parser > error : chunk is not well balanced > &PACKAGE-NOTES; > ^ > make: *** [RELEASE-NOTES-ja/index.html] error 1 > > ---- > > this error was caused because "para" tag was not closed in > package-notes-en.xml line 39. > > http://cvs.fedora.redhat.com/viewcvs/release-notes/package-notes-en.xml?annotate=1.3&root=docs > > i fixed this and tried once more. but i got error again. > > ---- > > $ make > LANG=ja.UTF-8 xmlto html -x ../docs-common/xsl/main-html.xsl -o > RELEASE-NOTES-ja RELEASE-NOTES-ja.xml > xmlto: input does not validate (status 1) > /home/mumumu/work/release-notes-FC5test1/package-movement-en.xml:1055: parser > error : Opening and ending tag mismatch: para line 1052 and emphasis > ) > ^ > /home/mumumu/work/release-notes-FC5test1/package-movement-en.xml:1056: parser > error : Opening and ending tag mismatch: section line 1044 and para > > ^ > /home/mumumu/work/release-notes-FC5test1/package-movement-en.xml:1065: parser > error : chunk is not well balanced > > ^ > /home/mumumu/work/release-notes-FC5test1/package-movement-en.xml:1065: parser > error : chunk is not well balanced > > ^ > /home/mumumu/work/release-notes-FC5test1/RELEASE-NOTES-ja.xml:76: parser > error : chunk is not well balanced > &PACKAGE-MOVEMENT; > ^ > make: *** [RELEASE-NOTES-ja/index.html] error 1 > > ---- > > this is because the start "emphasis" tag is missing in package-movement-en.xml > line 1055. > > http://cvs.fedora.redhat.com/viewcvs/release-notes/package-movement-en.xml?annotate=1.3&root=docs > > i fixed this and tried again. > this time, "make" worked fine and i could get release-note-ja directory and > tar archive. > > Regards. > > -- > Yoshinari Takaoka(mumumu at IRC) > reversethis -> {gro} {tod} {umumum} {ta} {umumum} > -- Karsten Wade, RHCE * Sr. Tech Writer * http://people.redhat.com/kwade/ gpg fingerprint: 2680 DBFD D968 3141 0115 5F1B D992 0E06 AD0E 0C41 Red Hat SELinux Guide http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/selinux-guide/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From kwade at redhat.com Tue Oct 25 19:42:37 2005 From: kwade at redhat.com (Karsten Wade) Date: Tue, 25 Oct 2005 12:42:37 -0700 Subject: FC5 test1 relnotes make problem(two xml file broken) In-Reply-To: <200510260108.28890.mumumu@mumumu.org> References: <200510260108.28890.mumumu@mumumu.org> Message-ID: <1130269357.12794.123.camel@erato.phig.org> On Wed, 2005-10-26 at 01:08 +0900, Yoshinari Takaoka wrote: > hi, all. > > i checked out fc5 test1 relnotes, and tried to make with the following steps. I made some typos when too sleepy last night (this morning) and forgot to check the build before committing. Sorry. :( This is now fixed, and the two broken files (package-movement-en.xml and package-notes-en.xml) are changed in CVS and retagged FC-5-TEST1-TRANS- FREEZE. thx - Karsten -- Karsten Wade, RHCE * Sr. Tech Writer * http://people.redhat.com/kwade/ gpg fingerprint: 2680 DBFD D968 3141 0115 5F1B D992 0E06 AD0E 0C41 Red Hat SELinux Guide http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/selinux-guide/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From dwmw2 at infradead.org Tue Oct 25 20:21:32 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Tue, 25 Oct 2005 21:21:32 +0100 Subject: FC5 test1 relnotes for translation In-Reply-To: <1130268985.12794.118.camel@erato.phig.org> References: <1130231767.12794.26.camel@erato.phig.org> <20051025.193603.111289002.tsekine@sdri.co.jp> <435E01BC.7010409@n-man.com> <1130234817.6932.276.camel@baythorne.infradead.org> <1130268985.12794.118.camel@erato.phig.org> Message-ID: <1130271692.6932.378.camel@baythorne.infradead.org> On Tue, 2005-10-25 at 12:36 -0700, Karsten Wade wrote: > Therefore, if you want to influence/convince FDP to use MiB instead of > MB, please feel free to do so. OK :) > Whatever consensus we reach becomes our standard, and we can start a > Wiki page on the subject. Again, we would be doing the right thing > and trying to lead the way with standards. Makes sense on the face of > it. The standard in this case is the second edition of IEC 60027-2, discussed at http://physics.nist.gov/cuu/Units/binary.html Using the SI decimal prefixes for binary multiples is, strictly speaking, incorrect. That just isn't what they mean. Obviously in some cases it doesn't really matter much or it's obvious from the context -- we'd never actually _mean_ '128MB', for example, in the context of the amount of physical RAM available in the system. It would always be 128MiB. But that still doesn't give any reason for choosing to continue to get it wrong, even in those cases. There's a reason to get it _right_ though, aside from the simple fact that we should be striving to be pedantically correct just to quiet the voices in our heads -- or is that just me?. By being strict about it, we can ensure that our meaning is perfectly understood in those (admittedly relatively infrequent) cases where it _does_ matter. When you see a binary 'Mi' used, you know precisely what it means -- it's a power-of-two multiple. On the other hand, when you see the SI decimal prefixes used, you sometimes don't know if they were used incorrectly and should actually have been a binary prefix. By implementing a policy of using the decimal and binary prefixes correctly, we can ensure that such ambiguity is removed in FDP output. Not using the correct prefixes is like not bothering to spell correctly. You might be perfectly understood almost all of the time, but that isn't really the point. -- dwmw2 From mumumu at mumumu.org Tue Oct 25 22:05:54 2005 From: mumumu at mumumu.org (Yoshinari Takaoka) Date: Wed, 26 Oct 2005 07:05:54 +0900 Subject: FC5 test1 relnotes make problem(two xml file broken) In-Reply-To: <1130269357.12794.123.camel@erato.phig.org> References: <200510260108.28890.mumumu@mumumu.org> <1130269357.12794.123.camel@erato.phig.org> Message-ID: <200510260705.54301.mumumu@mumumu.org> hi. Wednesday 26 October 2005 04:42 +0900?Karsten Wade wrote: > I made some typos when too sleepy last night (this morning) and forgot > to check the build before committing. Sorry. :( > > This is now fixed, and the two broken files (package-movement-en.xml and > package-notes-en.xml) are changed in CVS and retagged FC-5-TEST1-TRANS- > FREEZE. i confirmed that this probrem was fixed. thanks quaid. Regards. -- Yoshinari Takaoka(mumumu at IRC) reversethis -> {gro} {tod} {umumum} {ta} {umumum}v From kwade at redhat.com Wed Oct 26 09:13:02 2005 From: kwade at redhat.com (Karsten Wade) Date: Wed, 26 Oct 2005 02:13:02 -0700 Subject: minutes FDSCo 25 Oct. 2005 Message-ID: <1130317982.12794.193.camel@erato.phig.org> Today we were not able to have a quorum, but no decisions came up that required one. :) Attendees: ========== Stuart Elliss Karsten Wade Tommy Reynolds Updated activities: =================== http://fedoraproject.org/wiki/DocsProject/FedoraDocsSchedule Highlights: =========== * Tommy has worked with Tim Waugh to get changes to xmlto upstream. The changes let us use xmlto with Saxon, and defaults to xsltproc if Saxon is not installed. Meanwhile, the status of FOP is still in question. * Elliot is working on DocsRawhide, which will pull from CVS, build, and publish documentation. * Beat writing coverage has increased, thanks to the participation of more active developers. * Conversion of Wiki to XML went fairly well for the test1 relnotes. Patrick did some work to automate the export of the URL. We have a big challenge keeping the XML in CVS and the Wiki in sync. We need to work out how to have a canonical, meaning that syncing needs to be seamless. * The RPM Guide is in CVS. Help is needed to clean up the XML, then work can begin on updating the content. ## 30 ## -- Karsten Wade, RHCE * Sr. Tech Writer * http://people.redhat.com/kwade/ gpg fingerprint: 2680 DBFD D968 3141 0115 5F1B D992 0E06 AD0E 0C41 Red Hat SELinux Guide http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/selinux-guide/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From jlaska at redhat.com Fri Oct 28 13:38:52 2005 From: jlaska at redhat.com (James Laska) Date: Fri, 28 Oct 2005 09:38:52 -0400 Subject: Local document customizations Message-ID: <1130506732.20337.15.camel@flatline.devel.redhat.com> Hi folks, Some of our process documents can become somewhat large, which lends well to the chunked html output. Taking that a step further we've found it helpful to have 2 toc settings where the main table of contents only goes one level deep (chapter). Once you click on a chapter you then see the detailed toc for that section. This has received some good mileage and seems break up a document into manageable chunks. To see an example of the output see http://people.redhat.com/~jlaska/documentation-guide-en/ . Curious what folks think about this, is there a way to allow doc writers to make this customization without modifying main-html.xsl? Thanks, James -- ========================================== James Laska -- jlaska at redhat.com Quality Engineering -- Red Hat, Inc. ========================================== -------------- next part -------------- A non-text attachment was scrubbed... Name: fdp-toc.patch Type: text/x-patch Size: 1409 bytes Desc: not available URL: From Tommy.Reynolds at MegaCoder.com Fri Oct 28 15:18:14 2005 From: Tommy.Reynolds at MegaCoder.com (Tommy Reynolds) Date: Fri, 28 Oct 2005 10:18:14 -0500 Subject: Local document customizations In-Reply-To: <1130506732.20337.15.camel@flatline.devel.redhat.com> References: <1130506732.20337.15.camel@flatline.devel.redhat.com> Message-ID: <20051028101814.3e4bfdc3.Tommy.Reynolds@MegaCoder.com> Uttered James Laska , spake thus: > Some of our process documents can become somewhat large, which lends > well to the chunked html output. Taking that a step further we've found > it helpful to have 2 toc settings where the main table of contents only > goes one level deep (chapter). Once you click on a chapter you then see > the detailed toc for that section. This has received some good mileage > and seems break up a document into manageable chunks. Both the document ToC and the chapter ToC seems to share a common setting "doc.section.depth", so they can't be set independantly. However, since a chapter is a level down inside the document, a 1-level deep ToC there does provide a bit more detail that was hidden in the document ToC. > Curious what folks think about this, is there a way to allow doc > writers to make this customization without modifying main-html.xsl? I can add this capability to the "docs-common" infrastructure if the consensus is to do this. My question is this: do we want document authors to have that much control over the rendering, or is this a more project-level choice? Cheers -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jlaska at redhat.com Fri Oct 28 15:43:47 2005 From: jlaska at redhat.com (James Laska) Date: Fri, 28 Oct 2005 11:43:47 -0400 Subject: Local document customizations In-Reply-To: <20051028101814.3e4bfdc3.Tommy.Reynolds@MegaCoder.com> References: <1130506732.20337.15.camel@flatline.devel.redhat.com> <20051028101814.3e4bfdc3.Tommy.Reynolds@MegaCoder.com> Message-ID: <1130514228.20337.22.camel@flatline.devel.redhat.com> On Fri, 2005-10-28 at 10:18 -0500, Tommy Reynolds wrote: > My question is this: do we want document authors to have that much > control over the rendering, or is this a more project-level choice? Excellent question, and I'm not sure of the answer. I added some local customizations (trying to yank them out now to get in sync with fdp) that allowed doc authors to pass in xsltproc --param and --stringparam values (via the document Makefile). This allowed for local changes to the toc depth, or even adding glossary.collection generation. It's nice because it acts as an "opt-in" type service, and is not required for basic documentation building. -James -- ========================================== James Laska -- jlaska at redhat.com Quality Engineering -- Red Hat, Inc. ========================================== From Tommy.Reynolds at MegaCoder.com Fri Oct 28 16:32:55 2005 From: Tommy.Reynolds at MegaCoder.com (Tommy Reynolds) Date: Fri, 28 Oct 2005 11:32:55 -0500 Subject: Local document customizations In-Reply-To: <1130514228.20337.22.camel@flatline.devel.redhat.com> References: <1130506732.20337.15.camel@flatline.devel.redhat.com> <20051028101814.3e4bfdc3.Tommy.Reynolds@MegaCoder.com> <1130514228.20337.22.camel@flatline.devel.redhat.com> Message-ID: <20051028113255.e1033992.Tommy.Reynolds@MegaCoder.com> Uttered James Laska , spake thus: > > My question is this: do we want document authors to have that much > > control over the rendering, or is this a more project-level choice? > Excellent question, and I'm not sure of the answer. My hesitation here is that whatever rendering an author does locally is completely irrelavant to the final rendering done by the project before publication. In fact, we reserve the right to use whatever stylesheet we like, even one the authors have never seen, do whatever render styling is appropriate for the media and circumstances. So, I can add infrastructure to let an author provide additional stylesheet snippets, or paramter settings, but all must realize their efforts will be ignored in the final product. That's why I thought this question needing escalating to the entire project. Cheers -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From tsekine at sdri.co.jp Sat Oct 29 14:21:41 2005 From: tsekine at sdri.co.jp (SEKINE tatz Tatsuo) Date: Sun, 30 Oct 2005 00:21:41 +1000 (EST) Subject: FC5 test1 relnotes make problem(two xml file broken) In-Reply-To: <1130269125.12794.120.camel@erato.phig.org> References: <200510260108.28890.mumumu@mumumu.org> <1130269125.12794.120.camel@erato.phig.org> Message-ID: <20051030.002141.115070803.tsekine@sdri.co.jp> Hi, From: Karsten Wade Date: Tue, 25 Oct 2005 12:38:45 -0700 > On Wed, 2005-10-26 at 01:08 +0900, Yoshinari Takaoka wrote: > > hi, all. > > > > i checked out fc5 test1 relnotes, and tried to make with the following steps. > > I'm looking into this right now. I guess I can only test in -en but if > it works for me ... I found a problem in the Makefile. In the case that multiple languages were specifide in LANGUAGES variable, the command $ make html failed. This problem was already fixed in HEAD. So, if you try adding (not alternating) a new language in the Makefile, please update the Makefile before that. If you are using "FC-5-TEST1-TRANS-FREEZE" sticky tag in your local repository, please don't forget to clear sticky tag of the Makefile as below: $ cvs update -A Makefile Regards, -- SEKINE Tatsuo: tsekine at sdri.co.jp System Design & Research Inst. Co.,Ltd. From mumumu at mumumu.org Sat Oct 29 16:01:00 2005 From: mumumu at mumumu.org (Yoshinari Takaoka) Date: Sun, 30 Oct 2005 01:01:00 +0900 Subject: Guides content frozen for trans delayed? Message-ID: <200510300101.00623.mumumu@mumumu.org> hi all. according to DocsProject/Schedule, fedora installation guide contents freeze for trans is Oct 28, but its CVS contents are unchanged. http://fedoraproject.org/wiki/DocsProject/Schedule schedule is delayed? Regards. -- Yoshinari Takaoka(mumumu at IRC) reversethis -> {gro} {tod} {umumum} {ta} {umumum} From stuart at elsn.org Sat Oct 29 17:12:54 2005 From: stuart at elsn.org (Stuart Ellis) Date: Sat, 29 Oct 2005 18:12:54 +0100 Subject: Guides content frozen for trans delayed? In-Reply-To: <200510300101.00623.mumumu@mumumu.org> References: <200510300101.00623.mumumu@mumumu.org> Message-ID: <1130605974.2841.5.camel@localhost.localdomain> On Sun, 2005-10-30 at 01:01 +0900, Yoshinari Takaoka wrote: > hi all. > > according to DocsProject/Schedule, fedora installation guide contents freeze > for trans is Oct 28, but its CVS contents are unchanged. > > http://fedoraproject.org/wiki/DocsProject/Schedule > > schedule is delayed? There won't be an update for test 1 - the reworking of installation for yum support means that it hasn't stabilised in time for the content to be revised. -- Stuart Ellis stuart at 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From kwade at redhat.com Sun Oct 30 05:17:50 2005 From: kwade at redhat.com (Karsten Wade) Date: Sat, 29 Oct 2005 22:17:50 -0700 Subject: FC5 test1 relnotes make problem(two xml file broken) In-Reply-To: <20051030.002141.115070803.tsekine@sdri.co.jp> References: <200510260108.28890.mumumu@mumumu.org> <1130269125.12794.120.camel@erato.phig.org> <20051030.002141.115070803.tsekine@sdri.co.jp> Message-ID: <1130649470.12794.570.camel@erato.phig.org> On Sun, 2005-10-30 at 00:21 +1000, SEKINE tatz Tatsuo wrote: > If you are using "FC-5-TEST1-TRANS-FREEZE" sticky tag in > your local repository, please don't forget to clear sticky > tag of the Makefile as below: > $ cvs update -A Makefile I probably should not have tagged the Makefile. I removed the tag (cvs tag -d FC-5-TEST1-TRANS-FREEZE Makefile). The Makefile should operate independently from the XML, so you can have the latest version of that file without having to do anything more than 'cvs up Makefile'. - Karsten -- Karsten Wade, RHCE * Sr. Tech Writer * http://people.redhat.com/kwade/ gpg fingerprint: 2680 DBFD D968 3141 0115 5F1B D992 0E06 AD0E 0C41 Red Hat SELinux Guide http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/selinux-guide/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From sundaram at redhat.com Sun Oct 30 18:54:17 2005 From: sundaram at redhat.com (Rahul Sundaram) Date: Mon, 31 Oct 2005 00:24:17 +0530 Subject: Fedora websites mailing list and Wiki ownership Message-ID: <436516D9.5070703@redhat.com> Hi We have been managing feedback on the official Fedora websites, currently http://fedora.redhat.com and http://fedoraproject.org/wiki through bugzilla and discussions in the marketing list. It makes sense to have a independent mailing list -> fedora-websites-list which can also be used for discussing wiki pages. The wiki has good amount of community buy-in and the amount of content being added is growing rapidly. While this is indeed a positive development we need to make sure the content is organized and kept updated. Patrick Barnes has been keeping a good eye on this in general and I guess we can declare him the wiki master which is essentially the role he is performing .Going ahead, it might be a good idea to introduce a concept of "ownership" to each of the wiki pages. Every page would have a comment on top which declares the owner. Everyone in the edit group should have their own wiki pages filled out with atleast the contact information . Every page is also subscribed atleast by the owner of that page to monitor changes and keep the content relevant and updated. This process would help us make sure that unmaintained pages are marked as such and provide hints to users on what could be potentially outdated. It would also provide a list of pages that new wiki users can take care of and it provides accountability for the wiki itself. Suggestions welcome. regards Rahul From ed at rpath.com Sun Oct 30 19:13:06 2005 From: ed at rpath.com (Edward C. Bailey) Date: Sun, 30 Oct 2005 14:13:06 -0500 Subject: Tech writing position available... Message-ID: <7spspmhl8d.fsf@lambchop.rdu.rpath.com> (Before the flames about off-topic/commercial/whatever posts start, be aware that, before posting, I asked Karsten if he thought this was an appropriate use of the list. His response was that he personally thought people might be interested in job opportunities, but felt my post would be a good opportunity for people to weigh in with their own thoughts on the matter.) ---------------------------------------------------------------------- rPath is currently searching for a technical writer to join our team. The person hired for this position will be responsible for documenting rPath's technologies, such as Conary and rBuilder. We're looking for people with: o A well-developed writing style o Experience documenting complex technical subject matter, from initial concept through final editing o Strong spelling, grammar, and writing o The ability to edit and perform peer reviews of others' work o At least two years of recent Linux experience o Proven expertise in DocBook (XML or SGML), and HTML o Familiarity with open source authoring tools for the above formats o The ability to thrive in a fast-paced work environment (this is a startup, after all) Any of the following would be a definite plus: o Linux system administration experience -- even if it's just your own system(s) o Familiarity with one or more software packaging technologies (such as Conary, RPM, and dpkg) o Knowledge of XSL/XSLT o CSS experience o Familiarity with wikis o Programming experience (Python preferably) Writing samples will be requested, so be prepared to give us online pointers, emails bulging with attached PDFs, or even offer to send us a FedEx'ed package full of manuals. This position is located in Raleigh, NC -- if you're not local, you must be willing to relocate. Interested? Get in touch with us via this page: http://www.rpath.com/corp/about/employment/ -- Ed Bailey http://public.xdi.org/=edward.c.bailey rPath, Inc. http://www.rpath.com/ From Tommy.Reynolds at MegaCoder.com Sun Oct 30 19:24:28 2005 From: Tommy.Reynolds at MegaCoder.com (Tommy Reynolds) Date: Sun, 30 Oct 2005 13:24:28 -0600 Subject: Tech writing position available... In-Reply-To: <7spspmhl8d.fsf@lambchop.rdu.rpath.com> References: <7spspmhl8d.fsf@lambchop.rdu.rpath.com> Message-ID: <20051030132428.5b8cf63a.Tommy.Reynolds@MegaCoder.com> Uttered "Edward C. Bailey" , spake thus: > (Before the flames about off-topic/commercial/whatever posts start, be > aware that, before posting, I asked Karsten if he thought this was an > appropriate use of the list. His response was that he personally thought > people might be interested in job opportunities, but felt my post would be > a good opportunity for people to weigh in with their own thoughts on the > matter.) I am in favor of allowing principals-only to make such requests here but I don't think headhunters should be allowed the same grace. Why the difference? I would hate wading through off-topic solicitations, cattle-call resume/CV requests and the like. Allowing first-person requests here will still require that we politely correct any body shop that finds out about it, but that would be OK: we would be protecting our own interests. Summary: principal or first-person solicitations only, no advertising nor any headhunters. Your opinion may differ and that's OK with me. I'm not trying to convert anybody. Cheers -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From kwade at redhat.com Sun Oct 30 22:00:42 2005 From: kwade at redhat.com (Karsten Wade) Date: Sun, 30 Oct 2005 14:00:42 -0800 Subject: Tech writing position available... In-Reply-To: <20051030132428.5b8cf63a.Tommy.Reynolds@MegaCoder.com> References: <7spspmhl8d.fsf@lambchop.rdu.rpath.com> <20051030132428.5b8cf63a.Tommy.Reynolds@MegaCoder.com> Message-ID: <1130709642.12794.574.camel@erato.phig.org> On Sun, 2005-10-30 at 13:24 -0600, Tommy Reynolds wrote: > Summary: principal or first-person solicitations only, no advertising > nor any headhunters. +1 I think this is the time-honored practice of LUGs, right? That is the model I was thinking of. As Ed's post points out, I didn't feel qualified to decide for all of you what you think. If you have a different opinion, please let us know. - Karsten -- Karsten Wade, RHCE * Sr. Tech Writer * http://people.redhat.com/kwade/ gpg fingerprint: 2680 DBFD D968 3141 0115 5F1B D992 0E06 AD0E 0C41 Red Hat SELinux Guide http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/selinux-guide/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From nman64 at n-man.com Mon Oct 31 00:12:50 2005 From: nman64 at n-man.com (Patrick Barnes) Date: Sun, 30 Oct 2005 18:12:50 -0600 Subject: Fedora websites mailing list and Wiki ownership In-Reply-To: <436516D9.5070703@redhat.com> References: <436516D9.5070703@redhat.com> Message-ID: <43656182.9080601@n-man.com> Rahul Sundaram wrote: > Hi > > We have been managing feedback on the official Fedora websites, > currently http://fedora.redhat.com and http://fedoraproject.org/wiki > through bugzilla and discussions in the marketing list. It makes sense > to have a independent mailing list -> fedora-websites-list which can > also be used for discussing wiki pages. The wiki has good amount of > community buy-in and the amount of content being added is growing > rapidly. While this is indeed a positive development we need to make > sure the content is organized and kept updated. Also worth noting is that creating fedora-websites-list vs. fedora-wiki-list allows this to cover not just the wiki, but f.r.c and other websites that may now or in the future be under the umbrella of the Fedora Project. We can also allow others who run third-party sites, such as Thomas Chung and Bob Jensen, to weigh in on the official sites and follow along with the direction the project is taking. This perfectly compliments the new Bugzilla component created for the same purpose. > > Patrick Barnes has been keeping a good eye on this in general and I > guess we can declare him the wiki master which is essentially the role > he is performing .Going ahead, it might be a good idea to introduce a > concept of "ownership" to each of the wiki pages. Every page would > have a comment on top which declares the owner. Everyone in the edit > group should have their own wiki pages filled out with atleast the > contact information . Every page is also subscribed atleast by the > owner of that page to monitor changes and keep the content relevant > and updated. It may take time to establish 'best practices' for new EditGroup members, but having a head to roll if problems occur is the entire reason we have the EditGroup in the first place. We should encourage all EditGroup members to provide at least one method of contact on their wiki homepage. > > This process would help us make sure that unmaintained pages are > marked as such and provide hints to users on what could be potentially > outdated. It would also provide a list of pages that new wiki users > can take care of and it provides accountability for the wiki itself. Encouraging EditGroup members to take up unmaintained pages will also help us clean up areas of the site that have long been ignored, and will help us reduce the number of orphaned pages on the wiki. Accountability really isn't the top concern here, IMHO. It is a measure that can greatly benefit the quality of the wiki. Translating this same idea to other Fedora materials that don't already have this kind of measure would surely also be advantageous. Applying this particular method to the Docs arena would be doubly valuable. I would imagine that this would be easier and more reliable than simply maintaining a long list of writers and editors. Since this will be implemented as comments, it would both be very flexible and would be easy to filter out or parse where needed when converting or publishing documents. > > Suggestions welcome. > > regards > Rahul > For reference, a line declaring the owner of a document can be added to the beginning of the document to look like this: ##owner FooBar = Document Title = And document contents. As a matter of best practice, these comments should probably come after parsing instructions or ACL lines. For Docs, using ##writer and ##editor might also be of interest. Any thoughts? -- Patrick "The N-Man" Barnes nman64 at n-man.com www.n-man.com -- -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From nman64 at n-man.com Mon Oct 31 00:17:08 2005 From: nman64 at n-man.com (Patrick Barnes) Date: Sun, 30 Oct 2005 18:17:08 -0600 Subject: Tech writing position available... In-Reply-To: <1130709642.12794.574.camel@erato.phig.org> References: <7spspmhl8d.fsf@lambchop.rdu.rpath.com> <20051030132428.5b8cf63a.Tommy.Reynolds@MegaCoder.com> <1130709642.12794.574.camel@erato.phig.org> Message-ID: <43656284.8080108@n-man.com> Karsten Wade wrote: > On Sun, 2005-10-30 at 13:24 -0600, Tommy Reynolds wrote: > > >> Summary: principal or first-person solicitations only, no advertising >> nor any headhunters. >> > > +1 > > I think this is the time-honored practice of LUGs, right? That is the > model I was thinking of. > +1 Such a practice has worked well for many LUGs for many years. I think it is a suitable way to allow limited, targeted offers to reach an audience which will often include capable and interested parties. I think that such a practice is beneficial to both sides. -- Patrick "The N-Man" Barnes nman64 at n-man.com www.n-man.com -- -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From Tommy.Reynolds at MegaCoder.com Mon Oct 31 13:40:55 2005 From: Tommy.Reynolds at MegaCoder.com (Tommy Reynolds) Date: Mon, 31 Oct 2005 07:40:55 -0600 Subject: RFC: RPM Changelog thoughts Message-ID: <20051031074055.9bf0fe90.Tommy.Reynolds@MegaCoder.com> I'm looking at the RPM packaging steps that Paul has done. AIUI, he uses a small python script to pick the changelog information out of the document's XML. Cool idea. My question is this: should we build the RPM changelog from the XML content or from the CVS check-in log? Using the XML info is way cool, but we can get more file-specific information from the CVS log. I think developers, er, RPM users, would like the additional details. Opinions? Cheers -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From tsekine at sdri.co.jp Mon Oct 31 14:04:06 2005 From: tsekine at sdri.co.jp (SEKINE tatz Tatsuo) Date: Tue, 01 Nov 2005 01:04:06 +1100 (EST) Subject: The translation of legal notice Message-ID: <20051101.010406.43309441.tsekine@sdri.co.jp> Hi, Now I'm translating the release notes into Japanese. Unfortunately, Legal Notice written in English might lose its legality on some level in Japan. Then, I'm thinking about adding translated one into Appendix as a guide (i.e. not replacing English one). If it is possible, could I put some files under docs-common/common directory? -- SEKINE Tatsuo: tsekine at sdri.co.jp System Design & Research Inst. Co.,Ltd. From Tommy.Reynolds at MegaCoder.com Mon Oct 31 14:21:05 2005 From: Tommy.Reynolds at MegaCoder.com (Tommy Reynolds) Date: Mon, 31 Oct 2005 08:21:05 -0600 Subject: The translation of legal notice In-Reply-To: <20051101.010406.43309441.tsekine@sdri.co.jp> References: <20051101.010406.43309441.tsekine@sdri.co.jp> Message-ID: <20051031082105.9de74670.Tommy.Reynolds@MegaCoder.com> Uttered SEKINE "tatz" Tatsuo , spake thus: > Unfortunately, Legal Notice written in English might lose > its legality on some level in Japan. Then, I'm thinking > about adding translated one into Appendix as a guide > (i.e. not replacing English one). I think this is going to be an issue with every new translated language. This is probably a time for Karsten to consult the legal department. > If it is possible, could I put some files under > docs-common/common directory? You can just send it to this list and either Karsten, Paul or I will add it. Cheers -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From kwade at redhat.com Mon Oct 31 15:06:53 2005 From: kwade at redhat.com (Karsten Wade) Date: Mon, 31 Oct 2005 07:06:53 -0800 Subject: The translation of legal notice In-Reply-To: <20051101.010406.43309441.tsekine@sdri.co.jp> References: <20051101.010406.43309441.tsekine@sdri.co.jp> Message-ID: <1130771214.12794.594.camel@erato.phig.org> On Tue, 2005-11-01 at 01:04 +1100, SEKINE tatz Tatsuo wrote: > Hi, > > Now I'm translating the release notes into Japanese. > > Unfortunately, Legal Notice written in English might lose > its legality on some level in Japan. Yes, AIUI, every single translation requires a separate legal approval. Naturally, that lawyer needs to know the language. Sorry for forgetting about this one, it has been a question since FC1. I'll look into this immediately. > Then, I'm thinking > about adding translated one into Appendix as a guide > (i.e. not replacing English one). Interesting. As Tommy has pointed out, putting it in the Appendix removes some of the legal imperative. By being an attachment instead of part of the main body, we reduce it's relevance. I wonder ... if it is clearly marked as being a non-legal approved translation, will that work? - Karsten -- Karsten Wade, RHCE * Sr. Tech Writer * http://people.redhat.com/kwade/ gpg fingerprint: 2680 DBFD D968 3141 0115 5F1B D992 0E06 AD0E 0C41 Red Hat SELinux Guide http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/selinux-guide/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From Tommy.Reynolds at MegaCoder.com Mon Oct 31 15:18:01 2005 From: Tommy.Reynolds at MegaCoder.com (Tommy Reynolds) Date: Mon, 31 Oct 2005 09:18:01 -0600 Subject: The translation of legal notice In-Reply-To: <1130771214.12794.594.camel@erato.phig.org> References: <20051101.010406.43309441.tsekine@sdri.co.jp> <1130771214.12794.594.camel@erato.phig.org> Message-ID: <20051031091801.d89fb908.Tommy.Reynolds@MegaCoder.com> Uttered Karsten Wade , spake thus: > I wonder ... if it is clearly marked as being a non-legal approved > translation, will that work? IANAL* A non-legal legal notice? Equally well as an empty paragraph, I would suppose; probably not worth the trouble. Cheers * IANAL: "I am not a lawer". Intended to introduce a legal opinion made by an author with no legal knowlege. Effectively identical to the "--" used to mark a message signature. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From kwade at redhat.com Mon Oct 31 15:28:51 2005 From: kwade at redhat.com (Karsten Wade) Date: Mon, 31 Oct 2005 07:28:51 -0800 Subject: The translation of legal notice In-Reply-To: <20051031091801.d89fb908.Tommy.Reynolds@MegaCoder.com> References: <20051101.010406.43309441.tsekine@sdri.co.jp> <1130771214.12794.594.camel@erato.phig.org> <20051031091801.d89fb908.Tommy.Reynolds@MegaCoder.com> Message-ID: <1130772531.12794.612.camel@erato.phig.org> On Mon, 2005-10-31 at 09:18 -0600, Tommy Reynolds wrote: > Uttered Karsten Wade , spake thus: > > > I wonder ... if it is clearly marked as being a non-legal approved > > translation, will that work? > > IANAL* > > A non-legal legal notice? Equally well as an empty paragraph, I would > suppose; probably not worth the trouble. The more I think about this, the more I want to save us from wasting anyone's time. I've asked Sarah Wang and Greg DeKoenigsberg to help be resolve this. Ultimately, the translation decision does not lie within the FDP. Also, we need to update the legalnotice. If you look at this: http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/selinux-guide/legalnotice.html versus this http://fedora.redhat.com/docs/release-notes/fc4/errata/#sn-legalnotice You'll notice that the RHEL notice says, "All other trademarks referenced herein are the property of their respective owners." That is instead of tracking all the nuances of all the different trademarks we use. That language is lawyer-approved, and saves us much hassle. This means, once we translate the legalnotice, we won't have to again for a long time ... I hope. I'll make this change in HEAD. - Karsten -- Karsten Wade, RHCE * Sr. Tech Writer * http://people.redhat.com/kwade/ gpg fingerprint: 2680 DBFD D968 3141 0115 5F1B D992 0E06 AD0E 0C41 Red Hat SELinux Guide http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/selinux-guide/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From kwade at redhat.com Mon Oct 31 16:07:43 2005 From: kwade at redhat.com (Karsten Wade) Date: Mon, 31 Oct 2005 08:07:43 -0800 Subject: Fedora websites mailing list and Wiki ownership In-Reply-To: <43656182.9080601@n-man.com> References: <436516D9.5070703@redhat.com> <43656182.9080601@n-man.com> Message-ID: <1130774863.12794.623.camel@erato.phig.org> On Sun, 2005-10-30 at 18:12 -0600, Patrick Barnes wrote: > For Docs, using ##writer and ##editor might also be of interest. ##technical-contact This is especially important for Beat pages. It might be more than a page needs, though. > Any thoughts? Is this how other, successful Wiki projects handle it? I was under the impression that it was normally more chaotic than that. My instinct is always to exert some control.[1] Thus, I don't trust my own thinking when it comes to managing the Wiki overall. That is why I have tried to limit the FDP control to just certain pages.[2] What Rahul and Patrick are proposing is that the FDP be the accountable party for all formal[3] Fedora websites. This is an addition to our existing mission, or perhaps just an extension. I agree with it 100%. - Karsten [1] This is the control-freak in me. One thing that FDP brings to me is a chance to not be so controlling and to delegate, so thanks to all for the constant chance at self-improvement. :) [2] Meaning: wiki/Docs/* wiki/DocsProject/* [3] I use formal because 'official' is a word loaded with meaning, yet means something different to all. 'Official' is an overused word for these contexts, IME. -- Karsten Wade, RHCE * Sr. Tech Writer * http://people.redhat.com/kwade/ gpg fingerprint: 2680 DBFD D968 3141 0115 5F1B D992 0E06 AD0E 0C41 Red Hat SELinux Guide http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/selinux-guide/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From stickster at gmail.com Mon Oct 31 17:23:54 2005 From: stickster at gmail.com (Paul W. Frields) Date: Mon, 31 Oct 2005 12:23:54 -0500 Subject: RFC: RPM Changelog thoughts In-Reply-To: <20051031074055.9bf0fe90.Tommy.Reynolds@MegaCoder.com> References: <20051031074055.9bf0fe90.Tommy.Reynolds@MegaCoder.com> Message-ID: <1130779434.5412.11.camel@localhost.localdomain> On Mon, 2005-10-31 at 07:40 -0600, Tommy Reynolds wrote: > I'm looking at the RPM packaging steps that Paul has done. AIUI, he > uses a small python script to pick the changelog information out of > the document's XML. Cool idea. It is, if only I were indeed doing that! The only thing I do is a grab of the title information out of within the <book> or <article>. I am just learning Python baby steps, so even that was a stretch. Didn't want to take credit where it wasn't due. I had considered this, though, as an eventual goal for Python learning... if I could figure out enough SAX stuff to make this work, that would be a real coup as far as I'm concerned. I was under the impression that there were ways to even parse and read back entities, but I have no idea if that's a correct impression. > My question is this: should we build the RPM changelog from the XML > content or from the CVS check-in log? Using the XML info is way > cool, but we can get more file-specific information from the CVS log. > I think developers, er, RPM users, would like the additional details. > > Opinions? I think the CVS log would be nice, but my understanding is that it's difficult to parse for this content. A couple difficulties that occurred to me were (1) tying the CVS login name to an email address, which is normally used in the spec file's %changelog; (2) mitigating the situation with the CVS changelog having entries that do not correspond to RPM package versions -- in other words, CVS gets revisions for which a new package is not rolled; and (3) tying the CVS revision number into a version number used for the RPM package. I don't know if any of these are showstoppers, but they are definitely gobsmackers, if you get my meaning. On the other hand, the DocBook XML <revisionhistory> at least has a "rational" version number and date which should roughly correspond with packaging. We still have the email address problem, however, and other problems likely exist with this way of doing it. *sigh* This is so much easier dealing with regular code like in Extras! -- 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/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: <http://listman.redhat.com/archives/fedora-docs-list/attachments/20051031/eae07e56/attachment.sig> From mumumu at mumumu.org Mon Oct 31 17:46:39 2005 From: mumumu at mumumu.org (Yoshinari Takaoka) Date: Tue, 1 Nov 2005 02:46:39 +0900 Subject: translated screen image Message-ID: <200511010246.39638.mumumu@mumumu.org> hi all. as you know, fedora installation guide has many figures, and they are english screen. i want to relpace them with translated (in my case, japanese) screen. can i commit translated images (i.e *-ja_JP.png, *-ja_JP.eps) to the install-guide/figs/ directory? -- Yoshinari Takaoka(mumumu at IRC) reversethis -> {gro} {tod} {umumum} {ta} {umumum} From Tommy.Reynolds at MegaCoder.com Mon Oct 31 17:55:08 2005 From: Tommy.Reynolds at MegaCoder.com (Tommy Reynolds) Date: Mon, 31 Oct 2005 11:55:08 -0600 Subject: translated screen image In-Reply-To: <200511010246.39638.mumumu@mumumu.org> References: <200511010246.39638.mumumu@mumumu.org> Message-ID: <20051031115508.34e4d2fd.Tommy.Reynolds@MegaCoder.com> Uttered Yoshinari Takaoka <mumumu at mumumu.org>, spake thus: > as you know, fedora installation guide has many figures, and they are english > screen. i want to relpace them with translated (in my case, japanese) screen. > can i commit translated images (i.e *-ja_JP.png, *-ja_JP.eps) to the > install-guide/figs/ directory? Yes. Name the figure similarly to "picture-<locale>.png" and use the name "picture-<locale>.png" in your <imagedata> elements. If a graphic applies to all languages, name it "picture.png" or "picture-en.png". If a graphic has been i18n'ed, then name it "picture-<locale>.png". The "docs-common/Makefile.common" already has rules to copy the graphics into your HTML output "figs/" subdirectory. Cheers -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <http://listman.redhat.com/archives/fedora-docs-list/attachments/20051031/adeed020/attachment.sig> From sundaram at redhat.com Mon Oct 31 18:02:14 2005 From: sundaram at redhat.com (Rahul Sundaram) Date: Mon, 31 Oct 2005 23:32:14 +0530 Subject: translated screen image In-Reply-To: <20051031115508.34e4d2fd.Tommy.Reynolds@MegaCoder.com> References: <200511010246.39638.mumumu@mumumu.org> <20051031115508.34e4d2fd.Tommy.Reynolds@MegaCoder.com> Message-ID: <43665C26.6000508@redhat.com> Tommy Reynolds wrote: >Uttered Yoshinari Takaoka <mumumu at mumumu.org>, spake thus: > > > >>as you know, fedora installation guide has many figures, and they are english >>screen. i want to relpace them with translated (in my case, japanese) screen. >>can i commit translated images (i.e *-ja_JP.png, *-ja_JP.eps) to the >>install-guide/figs/ directory? >> >> > >Yes. Name the figure similarly to "picture-<locale>.png" and use the name >"picture-<locale>.png" in your <imagedata> elements. > >If a graphic applies to all languages, name it "picture.png" or >"picture-en.png". If a graphic has been i18n'ed, then name it >"picture-<locale>.png". > >The "docs-common/Makefile.common" already has rules to copy the >graphics into your HTML output "figs/" subdirectory. > > Additional note that you should usually retain the default settings and theme for consistency. regards Rahul From Tommy.Reynolds at MegaCoder.com Mon Oct 31 18:49:33 2005 From: Tommy.Reynolds at MegaCoder.com (Tommy Reynolds) Date: Mon, 31 Oct 2005 12:49:33 -0600 Subject: RFC: RPM Changelog thoughts In-Reply-To: <1130779434.5412.11.camel@localhost.localdomain> References: <20051031074055.9bf0fe90.Tommy.Reynolds@MegaCoder.com> <1130779434.5412.11.camel@localhost.localdomain> Message-ID: <20051031124933.a68c503e.Tommy.Reynolds@MegaCoder.com> Uttered "Paul W. Frields" <stickster at gmail.com>, spake thus: > I think the CVS log would be nice, but my understanding is that it's > difficult to parse for this content. I hacked together the attached shell script and ran it against the current "release-notes/" document. It gave this output: ==[release-notes/rpm-Changelog]== * Mon Oct 31 2005 04:48 bbbush <fedora-docs-list at redhat.com> - RELEASE-NOTES-zh_CN.xml (1.1), daemons-zh_CN.xml (1.1), - desktop-zh_CN.xml (1.1), development-tools-zh_CN.xml (1.1), - entertainment-zh_CN.xml (1.1), feedback-zh_CN.xml (1.1), - file-servers-zh_CN.xml (1.1), hardware-reqs-zh_CN.xml (1.1), - i18n-zh_CN.xml (1.1), install-notes-zh_CN.xml (1.1), intro-zh_CN.xml - (1.1), java-package-zh_CN.xml (1.1), kernel-zh_CN.xml (1.1), - legacy-zh_CN.xml (1.1), misc-server-zh_CN.xml (1.1), - multimedia-zh_CN.xml (1.1), networking-zh_CN.xml (1.1), - overview-zh_CN.xml (1.1), package-movement-zh_CN.xml (1.1), - package-notes-zh_CN.xml (1.1), printing-zh_CN.xml (1.1), - project-overview-zh_CN.xml (1.1), samba-zh_CN.xml (1.1), - security-zh_CN.xml (1.1), server-tools-zh_CN.xml (1.1), - splash-zh_CN.xml (1.1), web-servers-zh_CN.xml (1.1), xorg-zh_CN.xml - (1.1): Simplified Chinese translations of relnotes of fc5test1, of - test and incomplete quality. Problems in package-notes-en.xml are - translated AS-IS because of the freeze. * Sat Oct 29 2005 21:36 Tommy Reynolds <Tommy.Reynolds at MegaCoder.com> - Makefile (1.5): If the document directory has a "figs/" subdirectory, - create an "figs/" subdirectory in the HTML output directory. Copy any - ordinary files with a dot in their names to the newly-created - "${DOCBASE}-${LANG}/figs/" subdirectory. To be copied, a graphics - file must: 1) Have an extention that is NOT ".eps", since HTML - doesn't grok EPS files. 2) Have a filename matching "*-${LANG}.*" -- - be a graphic for the selected language. 3) Have a filename that DOES - NOT HAVE A DASH at all -- this allows for "language-independent" - graphics. * Sat Oct 29 2005 08:26 tsekine <fedora-docs-list at redhat.com> - Makefile (1.4): fix the figs directory making rule so that 2 or more - lauguages are able to be specified in LANGUAGES variable * Tue Oct 25 2005 14:40 Karsten Wade <Karsten.Wade at RedHat.com> - package-movement-en.xml (1.4), package-notes-en.xml (1.4) (utags: - FC-5-TEST1-TRANS-FREEZE): Typos that broke the build, sorry, forgot - to test the build before I did my last commits. <snip> In addition to the attached shell script, I propose adding an "AUTHORS" file to each document. The example one I used above is: ==[release-notes/AUTHORS]== ######################################################################## # We use this AUTHORS file to map CVS checkin names to real names and # email addresses. ######################################################################## # DEFAULT fedora-docs-list at redhat.com - jtr Tommy.Reynolds at MegaCoder.com Tommy Reynolds kwade Karsten.Wade at RedHat.com Karsten Wade Now that I look at the voluminous output, I'm less sure that we want the CVS log in the RPM. I think your current dummied-up %changelog is perhaps more useful. Cheers -------------- next part -------------- A non-text attachment was scrubbed... Name: rpm-changelog Type: application/octet-stream Size: 1689 bytes Desc: not available URL: <http://listman.redhat.com/archives/fedora-docs-list/attachments/20051031/81b9c701/attachment.obj> -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <http://listman.redhat.com/archives/fedora-docs-list/attachments/20051031/81b9c701/attachment.sig> From stickster at gmail.com Mon Oct 31 19:04:30 2005 From: stickster at gmail.com (Paul W. Frields) Date: Mon, 31 Oct 2005 14:04:30 -0500 Subject: RFC: RPM Changelog thoughts In-Reply-To: <20051031124933.a68c503e.Tommy.Reynolds@MegaCoder.com> References: <20051031074055.9bf0fe90.Tommy.Reynolds@MegaCoder.com> <1130779434.5412.11.camel@localhost.localdomain> <20051031124933.a68c503e.Tommy.Reynolds@MegaCoder.com> Message-ID: <1130785470.3288.4.camel@localhost.localdomain> On Mon, 2005-10-31 at 12:49 -0600, Tommy Reynolds wrote: > Uttered "Paul W. Frields" <stickster at gmail.com>, spake thus: > > > I think the CVS log would be nice, but my understanding is that it's > > difficult to parse for this content. > > I hacked together the attached shell script and ran it against the > current "release-notes/" document. It gave this output: > [...snip...] > In addition to the attached shell script, I propose adding an > "AUTHORS" file to each document. The example one I used above is: > > ==[release-notes/AUTHORS]== > > ######################################################################## > # We use this AUTHORS file to map CVS checkin names to real names and > # email addresses. > ######################################################################## > # DEFAULT fedora-docs-list at redhat.com - > jtr Tommy.Reynolds at MegaCoder.com Tommy Reynolds > kwade Karsten.Wade at RedHat.com Karsten Wade This is probably a good idea regardless of the route we choose for populating the %changelog, IMHO. > Now that I look at the voluminous output, I'm less sure that we want > the CVS log in the RPM. I think your current dummied-up %changelog > is perhaps more useful. I think James Laska had some input on the %changelog hacking, in that just setting a dummy was neither helpful nor advisable. (I'm kind of putting words in his mouth; he was less unkind, but in all honesty my solution didn't deserve a lot of kindness.) ;-) I think he suggested keeping a ChangeLog with the documents that would be used only for packaging. I am still mulling that over... -- 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/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: <http://listman.redhat.com/archives/fedora-docs-list/attachments/20051031/47ccb806/attachment.sig> From sundaram at redhat.com Mon Oct 31 19:25:23 2005 From: sundaram at redhat.com (Rahul Sundaram) Date: Tue, 01 Nov 2005 00:55:23 +0530 Subject: RFC: RPM Changelog thoughts In-Reply-To: <20051031124933.a68c503e.Tommy.Reynolds@MegaCoder.com> References: <20051031074055.9bf0fe90.Tommy.Reynolds@MegaCoder.com> <1130779434.5412.11.camel@localhost.localdomain> <20051031124933.a68c503e.Tommy.Reynolds@MegaCoder.com> Message-ID: <43666FA3.9020203@redhat.com> Hi >Now that I look at the voluminous output, I'm less sure that we want >the CVS log in the RPM. I think your current dummied-up %changelog >is perhaps more useful. > > I think dummying up the change log might be the wrong solution here. Changelog should be split up from the RPM spec and stored seperately. File a enhancement request? regards Rahul From andrewm at inventa.ru Mon Oct 31 21:14:00 2005 From: andrewm at inventa.ru (Andrew Martynov) Date: Tue, 1 Nov 2005 00:14:00 +0300 Subject: Self-Introduction: Andrew Martynov Message-ID: <20051031211400.GA24305@mk61.inventa.ru> Full Name: Andrew Martynov City & Country: Moscow, Russian Federation (GMT+0300) Profession: Trainer, Support Engineer Company: Inventa Your goals in the Fedora Project: Translation of Docs of Fedora Project into Russian language Historical qualifications: - maintainer of FC translation project into Russian - paticipant of translation RHEL manuals at www.rhd.ru/docs/ Computer skills: - linux user since 1999 - RHCE/RHCX certifications GPG KeyID and fingerprint: pub 1024D/30E45693 2005-03-18 Andrew Martynov <andrewm at inventa.ru> Key fingerprint = 0AF4 0070 E8A7 8C14 F9E0 97D9 320E 10AB 30E4 5693 sub 2048g/37A9C84D 2005-03-18 [expires: 2010-03-17] Other Details: fedoraproject.org wiki username: AndrewMartynov contact e-mail: andrewm at inventa.ru -- Andrew Martynov Inventa phone +7(095)7758777 fax +7(095)9270981 http://www.rhd.ru andrewm at inventa.ru From stuart at elsn.org Mon Oct 31 21:53:50 2005 From: stuart at elsn.org (Stuart Ellis) Date: Mon, 31 Oct 2005 21:53:50 +0000 Subject: Fedora websites mailing list and Wiki ownership In-Reply-To: <1130774863.12794.623.camel@erato.phig.org> References: <436516D9.5070703@redhat.com> <43656182.9080601@n-man.com> <1130774863.12794.623.camel@erato.phig.org> Message-ID: <1130795630.2811.17.camel@localhost.localdomain> On Mon, 2005-10-31 at 08:07 -0800, Karsten Wade wrote: > On Sun, 2005-10-30 at 18:12 -0600, Patrick Barnes wrote: > > > For Docs, using ##writer and ##editor might also be of interest. > > ##technical-contact > > This is especially important for Beat pages. It might be more than a > page needs, though. > > > Any thoughts? I think that different types of content require different arrangements, and the same considerations probably apply whatever the technology (Wiki or static pages). Pages with certain kinds of content need to be carefully maintained, and may need more stringent change control than is usual. Material like: - Legal and policy statements - Project admin, e.g. schedules - Download pages (with URLs and checksums) - "Shop-front" pages, like the front page and FAQ, intended to be seen by the new and unwary For other stuff, it may be best to let people get on and produce whatever they need. Having one person per category to act as a maintainer, moderator and point of contact is probably enough. FWIW, I really like Patrick's idea of having of a mailing list for official and third-party Website maintainers to get together. -- Stuart Ellis stuart at 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: <http://listman.redhat.com/archives/fedora-docs-list/attachments/20051031/54bb3f50/attachment.sig>