From stuart at elsn.org Thu Jun 4 22:08:11 2015 Content-Type: multipart/mixed; boundary="===============4098809668906415617==" MIME-Version: 1.0 From: Stuart Ellis To: docs at lists.fedoraproject.org Subject: Wiki > DocBook guidelines Date: Sun, 02 Oct 2005 18:11:22 +0100 Message-ID: <1128273082.2770.38.camel@localhost.localdomain> --===============4098809668906415617== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable 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: =3D=3D Understanding the Directory Structure =3D=3D 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(a)elsn.org Fedora Documentation Project: http://fedora.redhat.com/projects/docs/ GPG key ID: 7098ABEA GPG key fingerprint: 68B0 E291 FB19 C845 E60E 9569 292E E365 7098 ABEA=20 --===============4098809668906415617== Content-Type: application/pgp-signature MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="signature.asc" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4xIChHTlUv TGludXgpCgppRDhEQlFCRFFCUzVLUzdqWlhDWXErb1JBbG5kQUtDWEdkUER3dnp0RFNXM2ZvZDNw ei9BMk9laVFRQ2ZVdEljCnZSSzVWdTlaaGN1bXBtZUlXMldmYmVRPQo9UlEyMgotLS0tLUVORCBQ R1AgU0lHTkFUVVJFLS0tLS0K --===============4098809668906415617==-- From rodrigopadula at sagraluzzatto.com.br Thu Jun 4 22:08:11 2015 Content-Type: multipart/mixed; boundary="===============6344684222803359176==" MIME-Version: 1.0 From: Rodrigo Padula de Oliveira To: docs at lists.fedoraproject.org Subject: Self-Introduction: Rodrigo Padula de Oliveira Date: Sat, 08 Oct 2005 14:47:10 +0000 Message-ID: <41DFE449.2090503@sagraluzzatto.com.br> --===============6344684222803359176== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable -----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 =3D 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 - -- +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+ RODRIGO PADULA DE OLIVEIRA (o- BACHAREL EM SISTEMAS DE INFORMA=C3=87=C3=83O //\ FACULDADE METODISTA GRANBERY - FMG V_/_ PostgreSQL - PHP - Linux +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+ 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=3D =3DztLo -----END PGP SIGNATURE----- --===============6344684222803359176==-- From stuart at elsn.org Thu Jun 4 22:08:11 2015 Content-Type: multipart/mixed; boundary="===============7419197592469323922==" MIME-Version: 1.0 From: Stuart Ellis To: docs at lists.fedoraproject.org Subject: Request for Review - Fedora Security Basics Date: Sun, 09 Oct 2005 22:47:19 +0100 Message-ID: <1128894439.2795.9.camel@localhost.localdomain> --===============7419197592469323922== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable 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(a)elsn.org Fedora Documentation Project: http://fedora.redhat.com/projects/docs/ GPG key ID: 7098ABEA GPG key fingerprint: 68B0 E291 FB19 C845 E60E 9569 292E E365 7098 ABEA=20 --===============7419197592469323922== Content-Type: application/pgp-signature MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="signature.asc" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4xIChHTlUv TGludXgpCgppRDhEQlFCRFNZL21LUzdqWlhDWXErb1JBajNmQUo5NGkzVHFpNFpPdWRKN1JKL1Y1 VkFBOVpSZFdnQ2VJRnpGCnRXcHFhV1ZnOXI2ZTNjT0t2S1BRT0VjPQo9eURDVQotLS0tLUVORCBQ R1AgU0lHTkFUVVJFLS0tLS0K --===============7419197592469323922==-- From felipe.alfaro at gmail.com Thu Jun 4 22:08:11 2015 Content-Type: multipart/mixed; boundary="===============4252030580940512349==" MIME-Version: 1.0 From: Felipe Alfaro Solana To: docs at lists.fedoraproject.org Subject: Re: Request for Review - Fedora Security Basics Date: Mon, 10 Oct 2005 00:58:57 +0200 Message-ID: <6f6293f10510091558j7874610esa32f867fa5e16598@mail.gmail.com> In-Reply-To: 1128894439.2795.9.camel@localhost.localdomain --===============4252030580940512349== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable > 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)? --===============4252030580940512349==-- From tdiehl at rogueind.com Thu Jun 4 22:08:12 2015 Content-Type: multipart/mixed; boundary="===============4102558363105801111==" MIME-Version: 1.0 From: Tom Diehl To: docs at lists.fedoraproject.org Subject: Re: Request for Review - Fedora Security Basics Date: Sun, 09 Oct 2005 19:22:43 -0400 Message-ID: In-Reply-To: 6f6293f10510091558j7874610esa32f867fa5e16598@mail.gmail.com --===============4102558363105801111== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable 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 a= part is STUPID!! All requiring a passwd for single user mode does is make me hav= e 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 lo= nger 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 bo= ot 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(a)rogueind.com Spamtrap address mtd123(a)rogueind.com --===============4102558363105801111==-- From stickster at gmail.com Thu Jun 4 22:08:12 2015 Content-Type: multipart/mixed; boundary="===============2709490171680953024==" MIME-Version: 1.0 From: Paul W. Frields To: docs at lists.fedoraproject.org Subject: Re: Request for Review - Fedora Security Basics Date: Sun, 09 Oct 2005 19:55:57 -0400 Message-ID: <1128902157.5396.1.camel@localhost.localdomain> In-Reply-To: Pine.LNX.4.58.0510091913230.26189@tigger.rogueind.com --===============2709490171680953024== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable 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 h= ave 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. Al= l 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 B= IOS > you say, OK now I have to go find the little jumper on the MB to reset th= e BIOS > to the factory defaults. > = > The above applies to windoze and Linux. It does not matter. Where there i= s 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/ --===============2709490171680953024== Content-Type: application/pgp-signature MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="signature.asc" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4xIChHTlUv TGludXgpCgppRDhEQlFCRFNhNE5yTnZKTjcwUk54Y1JBbXM1QUtDYWtXV1RMK3BEV2ROMk1Ld3g0 QmxVS2lNWXVRQ2VQZ0taCmo1eHhpTEhkZFVqd0k1TkQ2dXVmcUp3PQo9cWpNUgotLS0tLUVORCBQ R1AgU0lHTkFUVVJFLS0tLS0K --===============2709490171680953024==-- From sundaram at redhat.com Thu Jun 4 22:08:12 2015 Content-Type: multipart/mixed; boundary="===============8914488450574769827==" MIME-Version: 1.0 From: Rahul Sundaram To: docs at lists.fedoraproject.org Subject: Re: Request for Review - Fedora Security Basics Date: Mon, 10 Oct 2005 09:42:23 +0530 Message-ID: <4349EA27.5060503@redhat.com> In-Reply-To: 6f6293f10510091558j7874610esa32f867fa5e16598@mail.gmail.com --===============8914488450574769827== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable 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 --===============8914488450574769827==-- From sundaram at redhat.com Thu Jun 4 22:08:12 2015 Content-Type: multipart/mixed; boundary="===============1428563785805817654==" MIME-Version: 1.0 From: Rahul Sundaram To: docs at lists.fedoraproject.org Subject: Re: Request for Review - Fedora Security Basics Date: Mon, 10 Oct 2005 09:44:54 +0530 Message-ID: <4349EABE.8090504@redhat.com> In-Reply-To: 4349EA27.5060503@redhat.com --===============1428563785805817654== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable 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 --===============1428563785805817654==-- From felipe.alfaro at gmail.com Thu Jun 4 22:08:12 2015 Content-Type: multipart/mixed; boundary="===============3663985525246289257==" MIME-Version: 1.0 From: Felipe Alfaro Solana To: docs at lists.fedoraproject.org Subject: Re: Request for Review - Fedora Security Basics Date: Mon, 10 Oct 2005 11:02:45 +0200 Message-ID: <6f6293f10510100202r7b011b61y3f3f7fc96063412@mail.gmail.com> In-Reply-To: 4349EA27.5060503@redhat.com --===============3663985525246289257== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable > 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. --===============3663985525246289257==-- From felipe.alfaro at gmail.com Thu Jun 4 22:08:12 2015 Content-Type: multipart/mixed; boundary="===============6521914748408423738==" MIME-Version: 1.0 From: Felipe Alfaro Solana To: docs at lists.fedoraproject.org Subject: Re: Request for Review - Fedora Security Basics Date: Mon, 10 Oct 2005 11:06:00 +0200 Message-ID: <6f6293f10510100206v5aac4a77kaa6f2b8efb993776@mail.gmail.com> In-Reply-To: 1128902157.5396.1.camel@localhost.localdomain --===============6521914748408423738== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable > 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. --===============6521914748408423738==-- From tsekine at sdri.co.jp Thu Jun 4 22:08:12 2015 Content-Type: multipart/mixed; boundary="===============2770335625959416339==" MIME-Version: 1.0 From: SEKINE Tatsuo To: docs at lists.fedoraproject.org Subject: Re: Request for Review - Fedora Security Basics Date: Mon, 10 Oct 2005 19:34:32 +1000 Message-ID: <20051010.193432.13087757.tsekine@sdri.co.jp> In-Reply-To: 6f6293f10510100202r7b011b61y3f3f7fc96063412@mail.gmail.com --===============2770335625959416339== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable 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=3D/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(a)sdri.co.jp System Design & Research Inst. Co.,Ltd. --===============2770335625959416339==-- From stickster at gmail.com Thu Jun 4 22:08:12 2015 Content-Type: multipart/mixed; boundary="===============2328528507949257636==" MIME-Version: 1.0 From: Paul W. Frields To: docs at lists.fedoraproject.org Subject: Re: Request for Review - Fedora Security Basics Date: Mon, 10 Oct 2005 08:12:44 -0400 Message-ID: <1128946365.2941.7.camel@localhost.localdomain> In-Reply-To: 20051010.193432.13087757.tsekine@sdri.co.jp --===============2328528507949257636== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable 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=3D/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/ --===============2328528507949257636== Content-Type: application/pgp-signature MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="signature.asc" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4xIChHTlUv TGludXgpCgppRDhEQlFCRFNscThyTnZKTjcwUk54Y1JBZ2lwQUpvRG00NmFBS0dmK3NlZGxUNEp3 WkFySENFMEpBQ2dsRlFZCktmQ3lkU1lCbDA5S0NTRm5mUEZ2eGJzPQo9UDFCNgotLS0tLUVORCBQ R1AgU0lHTkFUVVJFLS0tLS0K --===============2328528507949257636==-- From felipe.alfaro at gmail.com Thu Jun 4 22:08:12 2015 Content-Type: multipart/mixed; boundary="===============1953213274696035813==" MIME-Version: 1.0 From: Felipe Alfaro Solana To: docs at lists.fedoraproject.org Subject: Re: Request for Review - Fedora Security Basics Date: Mon, 10 Oct 2005 14:19:40 +0200 Message-ID: <6f6293f10510100519k10b34a37we12dbd0e8ec83bf3@mail.gmail.com> In-Reply-To: 1128946365.2941.7.camel@localhost.localdomain --===============1953213274696035813== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable > 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. --===============1953213274696035813==-- From tdiehl at rogueind.com Thu Jun 4 22:08:12 2015 Content-Type: multipart/mixed; boundary="===============1252689396460965688==" MIME-Version: 1.0 From: Tom Diehl To: docs at lists.fedoraproject.org Subject: Re: Request for Review - Fedora Security Basics Date: Mon, 10 Oct 2005 11:51:52 -0400 Message-ID: In-Reply-To: 6f6293f10510100206v5aac4a77kaa6f2b8efb993776@mail.gmail.com --===============1252689396460965688== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable 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 thin= g. That way it does not cause extra work for people who do not want/need it. Regards, Tom Diehl tdiehl(a)rogueind.com Spamtrap address mtd123(a)rogueind.com --===============1252689396460965688==-- From sundaram at redhat.com Thu Jun 4 22:08:12 2015 Content-Type: multipart/mixed; boundary="===============9023260036367878201==" MIME-Version: 1.0 From: Rahul Sundaram To: docs at lists.fedoraproject.org Subject: Re: Request for Review - Fedora Security Basics Date: Mon, 10 Oct 2005 21:46:17 +0530 Message-ID: <434A93D1.70304@redhat.com> In-Reply-To: 6f6293f10510100519k10b34a37we12dbd0e8ec83bf3@mail.gmail.com --===============9023260036367878201== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable 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 --===============9023260036367878201==-- From sundaram at redhat.com Thu Jun 4 22:08:12 2015 Content-Type: multipart/mixed; boundary="===============2910530609604490800==" MIME-Version: 1.0 From: Rahul Sundaram To: docs at lists.fedoraproject.org Subject: Re: Request for Review - Fedora Security Basics Date: Mon, 10 Oct 2005 21:49:36 +0530 Message-ID: <434A9498.9000406@redhat.com> In-Reply-To: 6f6293f10510100206v5aac4a77kaa6f2b8efb993776@mail.gmail.com --===============2910530609604490800== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable 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 --===============2910530609604490800==-- From stickster at gmail.com Thu Jun 4 22:08:12 2015 Content-Type: multipart/mixed; boundary="===============2155958653579950445==" MIME-Version: 1.0 From: Paul W. Frields To: docs at lists.fedoraproject.org Subject: Re: Request for Review - Fedora Security Basics Date: Mon, 10 Oct 2005 12:20:15 -0400 Message-ID: <1128961215.3016.3.camel@localhost.localdomain> In-Reply-To: 6f6293f10510100519k10b34a37we12dbd0e8ec83bf3@mail.gmail.com --===============2155958653579950445== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable 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/ --===============2155958653579950445== Content-Type: application/pgp-signature MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="signature.asc" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4xIChHTlUv TGludXgpCgppRDhEQlFCRFNwUytyTnZKTjcwUk54Y1JBbGhzQUtDbEd5UGdienNEMm9MWFNzWHVK dlJqY3RIWGVnQ2cwVW9XCk80cHJSSkNxWUY2QjAxMDJsR0ZuU2ZvPQo9L0paLwotLS0tLUVORCBQ R1AgU0lHTkFUVVJFLS0tLS0K --===============2155958653579950445==-- From esm at logic.net Thu Jun 4 22:08:12 2015 Content-Type: multipart/mixed; boundary="===============2583637852472670328==" MIME-Version: 1.0 From: Ed Marshall To: docs at lists.fedoraproject.org Subject: Re: Request for Review - Fedora Security Basics Date: Mon, 10 Oct 2005 13:48:25 -0500 Message-ID: <20051010184824.GB11806@talus.logic.net> In-Reply-To: Pine.LNX.4.58.0510091913230.26189@tigger.rogueind.com --===============2583637852472670328== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable 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. --===============2583637852472670328==-- From tdiehl at rogueind.com Thu Jun 4 22:08:13 2015 Content-Type: multipart/mixed; boundary="===============0520493370817989141==" MIME-Version: 1.0 From: Tom Diehl To: docs at lists.fedoraproject.org Subject: Re: Request for Review - Fedora Security Basics Date: Mon, 10 Oct 2005 16:06:41 -0400 Message-ID: In-Reply-To: 20051010184824.GB11806@talus.logic.net --===============0520493370817989141== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable On Mon, 10 Oct 2005 esm(a)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 ta= ke > > 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 menti= oned if you can modify the bootloader you can run init=3D/bin/sh from the grub c= ommand 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 th= at 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 abo= ut 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 othe= rs have argued the would be cracker only has access to the console but no acce= ss to the physical machine then a grub passwd or simply disabling <= del> is the way to go. If they can't reboot it they will never see grub to play = with it. Regards, Tom Diehl tdiehl(a)rogueind.com Spamtrap address mtd123(a)rogueind.com --===============0520493370817989141==-- From rostetter at mail.utexas.edu Thu Jun 4 22:08:13 2015 Content-Type: multipart/mixed; boundary="===============7459941193718277051==" MIME-Version: 1.0 From: Eric Rostetter To: docs at lists.fedoraproject.org Subject: Re: Request for Review - Fedora Security Basics Date: Mon, 10 Oct 2005 15:51:33 -0500 Message-ID: <1128977493.3576155ca71b4@mail.ph.utexas.edu> In-Reply-To: 20051010184824.GB11806@talus.logic.net --===============7459941193718277051== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Quoting esm(a)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 ta= ke > > 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 preve= nts 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 --===============7459941193718277051==-- From rostetter at mail.utexas.edu Thu Jun 4 22:08:13 2015 Content-Type: multipart/mixed; boundary="===============8641909906832696813==" MIME-Version: 1.0 From: Eric Rostetter To: docs at lists.fedoraproject.org Subject: Re: Request for Review - Fedora Security Basics Date: Mon, 10 Oct 2005 16:07:18 -0500 Message-ID: <1128978438.5ade068266450@mail.ph.utexas.edu> In-Reply-To: Pine.LNX.4.58.0510101538480.26189@tigger.rogueind.com --===============8641909906832696813== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable 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 ho= pe > 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=3D/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 fr= ont > 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 acce= ss, > than requiring a passwd for RL-1. It is just too easy to bypass. If as ot= hers > have argued the would be cracker only has access to the console but no ac= cess > 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(a)rogueind.com Spamtrap address mtd123(a)rogueind.com -- = Eric Rostetter --===============8641909906832696813==-- From green at redhat.com Thu Jun 4 22:08:13 2015 Content-Type: multipart/mixed; boundary="===============8111262099736454499==" MIME-Version: 1.0 From: Anthony Green To: docs at lists.fedoraproject.org Subject: Self Introduction: Anthony Green Date: Mon, 10 Oct 2005 17:35:09 -0700 Message-ID: <1128990910.3243.11.camel@localhost.localdomain> --===============8111262099736454499== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable 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 =3D 87F4 E1FA FCE4 13A4 FDCB 3A04 5025 EA2C 8E2F 07F0 uid Anthony Green sub 2048g/4BF9E433 2005-09-02 AG --===============8111262099736454499==-- From stickster at gmail.com Thu Jun 4 22:08:13 2015 Content-Type: multipart/mixed; boundary="===============7027266948336535098==" MIME-Version: 1.0 From: Paul W. Frields To: docs at lists.fedoraproject.org Subject: Re: Self Introduction: Anthony Green Date: Tue, 11 Oct 2005 07:32:37 -0400 Message-ID: <1129030357.2950.2.camel@localhost.localdomain> In-Reply-To: 1128990910.3243.11.camel@localhost.localdomain --===============7027266948336535098== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable 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 =3D 87F4 E1FA FCE4 13A4 FDCB 3A04 5025 EA2C 8E2F 0= 7F0 > 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/ --===============7027266948336535098== Content-Type: application/pgp-signature MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="signature.asc" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4xIChHTlUv TGludXgpCgppRDhEQlFCRFM2TFVyTnZKTjcwUk54Y1JBc0s0QUo5NDFCRHF0ZjQ1MkVpUDZQU0dE eFJ3SzJ5ejNnQ2ZTdTFxCnU3aVVnWjdqUnNEcWN2ZkJpdXN4U25FPQo9ekpLVQotLS0tLUVORCBQ R1AgU0lHTkFUVVJFLS0tLS0K --===============7027266948336535098==-- From green at redhat.com Thu Jun 4 22:08:13 2015 Content-Type: multipart/mixed; boundary="===============5171151205690939767==" MIME-Version: 1.0 From: Anthony Green To: docs at lists.fedoraproject.org Subject: Re: Self Introduction: Anthony Green Date: Tue, 11 Oct 2005 06:37:54 -0700 Message-ID: <1129037875.3243.82.camel@localhost.localdomain> In-Reply-To: 1129030357.2950.2.camel@localhost.localdomain --===============5171151205690939767== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable 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 --===============5171151205690939767==-- From stickster at gmail.com Thu Jun 4 22:08:13 2015 Content-Type: multipart/mixed; boundary="===============7812691014861122362==" MIME-Version: 1.0 From: Paul W. Frields To: docs at lists.fedoraproject.org Subject: Re: Self Introduction: Anthony Green Date: Tue, 11 Oct 2005 10:33:56 -0400 Message-ID: <1129041236.2950.15.camel@localhost.localdomain> In-Reply-To: 1129037875.3243.82.camel@localhost.localdomain --===============7812691014861122362== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable 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/ --===============7812691014861122362== Content-Type: application/pgp-signature MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="signature.asc" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4xIChHTlUv TGludXgpCgppRDhEQlFCRFM4MVVyTnZKTjcwUk54Y1JBdGs4QUo5OUZkaldQb3hYSkMrRE5sbDF4 ekVEQ0p3WUpRQ2cyMW03CnFoQnV1M05PM2o5eG91cUZVTHQyK21rPQo9aUpMQwotLS0tLUVORCBQ R1AgU0lHTkFUVVJFLS0tLS0K --===============7812691014861122362==-- From stickster at gmail.com Thu Jun 4 22:08:13 2015 Content-Type: multipart/mixed; boundary="===============4339526252204147406==" MIME-Version: 1.0 From: Paul W. Frields To: docs at lists.fedoraproject.org Subject: Re: CVSROOT avail,1.13,1.14 Date: Tue, 11 Oct 2005 18:02:11 -0400 Message-ID: <1129068131.4381.7.camel@localhost.localdomain> In-Reply-To: 1128093026.5399.19.camel@localhost.localdomain --===============4339526252204147406== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable 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/ --===============4339526252204147406== Content-Type: application/pgp-signature MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="signature.asc" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4xIChHTlUv TGludXgpCgppRDhEQlFCRFREWmpyTnZKTjcwUk54Y1JBZ280QUo5TkxmMWp2ZWNONVRhL0FiRzUz KzhrdGVhYjFnQ2c1WllECldidUFlK2NWS2drNVNtS2svTHFkamRBPQo9VzNDTwotLS0tLUVORCBQ R1AgU0lHTkFUVVJFLS0tLS0K --===============4339526252204147406==-- From stickster at gmail.com Thu Jun 4 22:08:13 2015 Content-Type: multipart/mixed; boundary="===============1024065211020029264==" MIME-Version: 1.0 From: Paul W. Frields To: docs at lists.fedoraproject.org Subject: Minutes FDSCo 11 Oct 2005 Date: Tue, 11 Oct 2005 18:36:27 -0400 Message-ID: <1129070187.4381.21.camel@localhost.localdomain> --===============1024065211020029264== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Canonical schedule and tasks: http://fedoraproject.org/wiki/DocsProject/FedoraDocsSchedule Summary of Updates and New Tasks: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D * 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: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 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/ --===============1024065211020029264== Content-Type: application/pgp-signature MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="signature.asc" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4xIChHTlUv TGludXgpCgppRDhEQlFCRFRENXJyTnZKTjcwUk54Y1JBa0pPQUo0bnlnZXF1R3ZibW5LWnp4YnVr YkdKQ0NQbStBQ2VPbzlhCkt0cmhrem9aTllvQ2NDMjVhZmNiTkJzPQo9VWdTKwotLS0tLUVORCBQ R1AgU0lHTkFUVVJFLS0tLS0K --===============1024065211020029264==-- From stuart at elsn.org Thu Jun 4 22:08:13 2015 Content-Type: multipart/mixed; boundary="===============5427423107199237245==" MIME-Version: 1.0 From: Stuart Ellis To: docs at lists.fedoraproject.org Subject: Test of Docs Packaging Date: Wed, 12 Oct 2005 00:10:00 +0100 Message-ID: <1129072200.3562.16.camel@localhost.localdomain> --===============5427423107199237245== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable 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(a)elsn.org Fedora Documentation Project: http://fedora.redhat.com/projects/docs/ GPG key ID: 7098ABEA GPG key fingerprint: 68B0 E291 FB19 C845 E60E 9569 292E E365 7098 ABEA --===============5427423107199237245== Content-Type: application/pgp-signature MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="signature.asc" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4xIChHTlUv TGludXgpCgppRDhEQlFCRFRFWklLUzdqWlhDWXErb1JBanZhQUo5Z2I4c09PQ0VWWk0vNGY2bVY4 b29KRmt5UWV3Q2VQMkVWCkFqR1RMQmEzbldPM284ejlYT0x2dzVFPQo9WEFoLwotLS0tLUVORCBQ R1AgU0lHTkFUVVJFLS0tLS0K --===============5427423107199237245==-- From ghenry at suretecsystems.com Thu Jun 4 22:08:14 2015 Content-Type: multipart/mixed; boundary="===============6438745257566631360==" MIME-Version: 1.0 From: Gavin Henry To: docs at lists.fedoraproject.org Subject: Re: Minutes FDSCo 11 Oct 2005 Date: Wed, 12 Oct 2005 13:06:47 +0100 Message-ID: <50148.195.38.86.72.1129118807.squirrel@webmail.suretecsystems.com> In-Reply-To: 1129070187.4381.21.camel@localhost.localdomain --===============6438745257566631360== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable > Canonical schedule and tasks: > > http://fedoraproject.org/wiki/DocsProject/FedoraDocsSchedule > > Summary of Updates and New Tasks: > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D* 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: > =3D=3D=3D=3D=3D=3D=3D=3D=3DGavin 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(a)redhat.com > To unsubscribe: > https://www.redhat.com/mailman/listinfo/fedora-docs-list --===============6438745257566631360==-- From stickster at gmail.com Thu Jun 4 22:08:14 2015 Content-Type: multipart/mixed; boundary="===============0376037545768066298==" MIME-Version: 1.0 From: Paul W. Frields To: docs at lists.fedoraproject.org Subject: Re: CVSROOT avail,1.13,1.14 Date: Wed, 12 Oct 2005 11:12:58 -0400 Message-ID: <1129129979.4681.6.camel@localhost.localdomain> In-Reply-To: 1129124796.3861.6.camel@blaa --===============0376037545768066298== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable 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 th= is > > > > work. If either of them had input, that would be great, even if th= at > > > > input is "you're an idiot, here's the drop file you need." (The fi= rst > > > > 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/ --===============0376037545768066298== Content-Type: application/pgp-signature MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="signature.asc" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4xIChHTlUv TGludXgpCgppRDhEQlFCRFRTZjZyTnZKTjcwUk54Y1JBdURVQUtEQkFHVFlCS0JYREpNUWxBSHFP MFliUWdoTUFRQ2NDNjdFCjdCTXJ1UEpmdHdTNXVLYkg1WGhKSFVNPQo9dUV1ZgotLS0tLUVORCBQ R1AgU0lHTkFUVVJFLS0tLS0K --===============0376037545768066298==-- From stickster at gmail.com Thu Jun 4 22:08:14 2015 Content-Type: multipart/mixed; boundary="===============6727356136472941027==" MIME-Version: 1.0 From: Paul W. Frields To: docs at lists.fedoraproject.org Subject: Re: Minutes FDSCo 11 Oct 2005 Date: Wed, 12 Oct 2005 08:41:17 -0400 Message-ID: <1129120878.2901.14.camel@localhost.localdomain> In-Reply-To: 50148.195.38.86.72.1129118807.squirrel@webmail.suretecsystems.com --===============6727356136472941027== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable 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: > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D* 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/ --===============6727356136472941027==-- From stickster at gmail.com Thu Jun 4 22:08:14 2015 Content-Type: multipart/mixed; boundary="===============1339478385515654787==" MIME-Version: 1.0 From: Paul W. Frields To: docs at lists.fedoraproject.org Subject: Re: Test of Docs Packaging Date: Tue, 11 Oct 2005 21:44:04 -0400 Message-ID: <1129081444.2907.6.camel@localhost.localdomain> In-Reply-To: 1129072200.3562.16.camel@localhost.localdomain --===============1339478385515654787== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable 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/ --===============1339478385515654787== Content-Type: application/pgp-signature MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="signature.asc" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4xIChHTlUv TGludXgpCgppRDhEQlFCRFRHcGtyTnZKTjcwUk54Y1JBdlFjQUtEUmJibDFOZitBUU4xWTk1ekhX a3ZkQzRVc0NRQ2c4YWh2CkNIZjEwNEhVY2VjNFVWZzdSdFBMZzk0PQo9RXlOQQotLS0tLUVORCBQ R1AgU0lHTkFUVVJFLS0tLS0K --===============1339478385515654787==-- From jlaska at redhat.com Thu Jun 4 22:08:14 2015 Content-Type: multipart/mixed; boundary="===============6042287923304783575==" MIME-Version: 1.0 From: James Laska To: docs at lists.fedoraproject.org Subject: Re: CVSROOT avail,1.13,1.14 Date: Thu, 13 Oct 2005 08:51:22 -0400 Message-ID: <1129207882.4791.12.camel@flatline.devel.redhat.com> In-Reply-To: 1129129979.4681.6.camel@localhost.localdomain --===============6042287923304783575== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable 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 H= EAD) $ 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 -- = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D James Laska -- jlaska(a)redhat.com Quality Engineering -- Red Hat, Inc. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --===============6042287923304783575==-- From Tommy.Reynolds at MegaCoder.com Thu Jun 4 22:08:14 2015 Content-Type: multipart/mixed; boundary="===============5505076877453852647==" MIME-Version: 1.0 From: Tommy Reynolds To: docs at lists.fedoraproject.org Subject: Re: Test of Docs Packaging Date: Thu, 13 Oct 2005 09:27:57 -0500 Message-ID: <20051013092757.00a4398b.Tommy.Reynolds@MegaCoder.com> In-Reply-To: 1129081444.2907.6.camel@localhost.localdomain --===============5505076877453852647== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable 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 --===============5505076877453852647== Content-Type: application/pgp-signature MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="attachment.sig" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4xIChHTlUv TGludXgpCgppRDhEQlFGRFRtN3gvMHlkcWtRRGxRRVJBa0krQUo5NkQ4WGZ1RjdGeDU2ZldMQ2M2 ZFhvRUtJdVd3Q2ZZQkRxCmo5dE9PbUZJNGoxa2xmY1JHRU1rcDAwPQo9RTZqQQotLS0tLUVORCBQ R1AgU0lHTkFUVVJFLS0tLS0K --===============5505076877453852647==-- From jlaska at redhat.com Thu Jun 4 22:08:14 2015 Content-Type: multipart/mixed; boundary="===============1682091985967325170==" MIME-Version: 1.0 From: James Laska To: docs at lists.fedoraproject.org Subject: Re: Test of Docs Packaging Date: Fri, 14 Oct 2005 12:48:13 -0400 Message-ID: <1129308494.2761.6.camel@flatline.devel.redhat.com> In-Reply-To: 1129081444.2907.6.camel@localhost.localdomain --===============1682091985967325170== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable 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(a)redhat.com > To unsubscribe: = > https://www.redhat.com/mailman/listinfo/fedora-docs-list -- = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D James Laska -- jlaska(a)redhat.com Quality Engineering -- Red Hat, Inc. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --===============1682091985967325170==-- From jlaska at redhat.com Thu Jun 4 22:08:14 2015 Content-Type: multipart/mixed; boundary="===============4837004773469873914==" MIME-Version: 1.0 From: James Laska To: docs at lists.fedoraproject.org Subject: Re: Test of Docs Packaging Date: Fri, 14 Oct 2005 12:49:10 -0400 Message-ID: <1129308551.2761.8.camel@flatline.devel.redhat.com> In-Reply-To: 20051013092757.00a4398b.Tommy.Reynolds@MegaCoder.com --===============4837004773469873914== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable 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 -- = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D James Laska -- jlaska(a)redhat.com Quality Engineering -- Red Hat, Inc. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --===============4837004773469873914==-- From jlaska at redhat.com Thu Jun 4 22:08:14 2015 Content-Type: multipart/mixed; boundary="===============8181650558345728458==" MIME-Version: 1.0 From: James Laska To: docs at lists.fedoraproject.org Subject: Re: Test of Docs Packaging Date: Fri, 14 Oct 2005 11:05:57 -0400 Message-ID: <1129302357.2761.2.camel@flatline.devel.redhat.com> In-Reply-To: 20051013092757.00a4398b.Tommy.Reynolds@MegaCoder.com --===============8181650558345728458== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable 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 -- = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D James Laska -- jlaska(a)redhat.com Quality Engineering -- Red Hat, Inc. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --===============8181650558345728458==-- From jlaska at redhat.com Thu Jun 4 22:08:14 2015 Content-Type: multipart/mixed; boundary="===============5423792492923636651==" MIME-Version: 1.0 From: James Laska To: docs at lists.fedoraproject.org Subject: Re: Test of Docs Packaging Date: Fri, 14 Oct 2005 08:41:59 -0400 Message-ID: <1129293719.28625.40.camel@flatline.devel.redhat.com> In-Reply-To: 20051013092757.00a4398b.Tommy.Reynolds@MegaCoder.com --===============5423792492923636651== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable 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 -- = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D James Laska -- jlaska(a)redhat.com Quality Engineering -- Red Hat, Inc. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --===============5423792492923636651==-- From jlaska at redhat.com Thu Jun 4 22:08:14 2015 Content-Type: multipart/mixed; boundary="===============3308361039515324842==" MIME-Version: 1.0 From: James Laska To: docs at lists.fedoraproject.org Subject: Re: Test of Docs Packaging Date: Fri, 14 Oct 2005 08:33:51 -0400 Message-ID: <1129293231.28625.31.camel@flatline.devel.redhat.com> In-Reply-To: 20051013092757.00a4398b.Tommy.Reynolds@MegaCoder.com --===============3308361039515324842== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable 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(a)redhat.com > To unsubscribe: = > https://www.redhat.com/mailman/listinfo/fedora-docs-list -- = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D James Laska -- jlaska(a)redhat.com Quality Engineering -- Red Hat, Inc. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --===============3308361039515324842==-- From stickster at gmail.com Thu Jun 4 22:08:14 2015 Content-Type: multipart/mixed; boundary="===============6660680618665044872==" MIME-Version: 1.0 From: Paul W. Frields To: docs at lists.fedoraproject.org Subject: Re: Test of Docs Packaging Date: Fri, 14 Oct 2005 07:40:24 -0400 Message-ID: <1129290024.2961.7.camel@localhost.localdomain> In-Reply-To: 20051013092757.00a4398b.Tommy.Reynolds@MegaCoder.com --===============6660680618665044872== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable 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/ --===============6660680618665044872== Content-Type: application/pgp-signature MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="signature.asc" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4xIChHTlUv TGludXgpCgppRDhEQlFCRFQ1a29yTnZKTjcwUk54Y1JBc0czQUtEU2MwV1AwK2ZoR1JjOW5ESnBU WlYwVGYrT0p3Q2RIZUdrClF1TGJiZm9pMnQ0eW5SWktVSStSRGZzPQo9bmZzdgotLS0tLUVORCBQ R1AgU0lHTkFUVVJFLS0tLS0K --===============6660680618665044872==-- From jlaska at redhat.com Thu Jun 4 22:08:15 2015 Content-Type: multipart/mixed; boundary="===============7638265355186706920==" MIME-Version: 1.0 From: James Laska To: docs at lists.fedoraproject.org Subject: Re: Test of Docs Packaging Date: Fri, 14 Oct 2005 13:48:55 -0400 Message-ID: <1129312136.3848.3.camel@flatline.devel.redhat.com> In-Reply-To: 1129308551.2761.8.camel@flatline.devel.redhat.com --===============7638265355186706920== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable /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 > = > -- = > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > James Laska -- jlaska(a)redhat.com > Quality Engineering -- Red Hat, Inc. > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --===============7638265355186706920==-- From Tommy.Reynolds at MegaCoder.com Thu Jun 4 22:08:15 2015 Content-Type: multipart/mixed; boundary="===============2498756243403499902==" MIME-Version: 1.0 From: Tommy Reynolds To: docs at lists.fedoraproject.org Subject: Re: Test of Docs Packaging Date: Fri, 14 Oct 2005 12:58:36 -0500 Message-ID: <20051014125836.6cfa09d8.Tommy.Reynolds@MegaCoder.com> In-Reply-To: 1129293231.28625.31.camel@flatline.devel.redhat.com --===============2498756243403499902== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable 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 --===============2498756243403499902== Content-Type: application/pgp-signature MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="attachment.sig" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4xIChHTlUv TGludXgpCgppRDhEQlFGRFQvSFEvMHlkcWtRRGxRRVJBc1ZJQUtDSkpIRE9taGxWdkw5djA2YU45 MkZ3SFRuU3FnQ2dxMFVPClRkbnAzRHAyYVdyd1hWbjlXN3dheWY0PQo9ZExldgotLS0tLUVORCBQ R1AgU0lHTkFUVVJFLS0tLS0K --===============2498756243403499902==-- From jlaska at redhat.com Thu Jun 4 22:08:15 2015 Content-Type: multipart/mixed; boundary="===============1811011676173839783==" MIME-Version: 1.0 From: James Laska To: docs at lists.fedoraproject.org Subject: Re: Test of Docs Packaging Date: Fri, 14 Oct 2005 14:09:28 -0400 Message-ID: <1129313368.3848.17.camel@flatline.devel.redhat.com> In-Reply-To: 20051014125836.6cfa09d8.Tommy.Reynolds@MegaCoder.com --===============1811011676173839783== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable 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 = -- = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D James Laska -- jlaska(a)redhat.com Quality Engineering -- Red Hat, Inc. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --===============1811011676173839783==-- From Tommy.Reynolds at MegaCoder.com Thu Jun 4 22:08:15 2015 Content-Type: multipart/mixed; boundary="===============0461087477429883749==" MIME-Version: 1.0 From: Tommy Reynolds To: docs at lists.fedoraproject.org Subject: Re: Test of Docs Packaging Date: Fri, 14 Oct 2005 15:41:39 -0500 Message-ID: <20051014154139.6b9b4b67.Tommy.Reynolds@MegaCoder.com> In-Reply-To: 1129313368.3848.17.camel@flatline.devel.redhat.com --===============0461087477429883749== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable 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 --===============0461087477429883749== Content-Type: application/pgp-signature MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="attachment.sig" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4xIChHTlUv TGludXgpCgppRDhEQlFGRFVCZ0gvMHlkcWtRRGxRRVJBZzdiQUtEQXJqbzlXYytOVlFNc3dGVWMy a2ZEV2JYVVdRQ2dnVUxsCkVQbkZzY3FEWXcyN291aEVXU0N0TGFjPQo9d0xhUgotLS0tLUVORCBQ R1AgU0lHTkFUVVJFLS0tLS0K --===============0461087477429883749==-- From dmalcolm at redhat.com Thu Jun 4 22:08:15 2015 Content-Type: multipart/mixed; boundary="===============4082868005506155858==" MIME-Version: 1.0 From: David Malcolm To: docs at lists.fedoraproject.org Subject: Re: Test of Docs Packaging Date: Fri, 14 Oct 2005 18:03:02 -0400 Message-ID: <1129327382.3442.10.camel@cassandra.boston.redhat.com> In-Reply-To: 20051014154139.6b9b4b67.Tommy.Reynolds@MegaCoder.com --===============4082868005506155858== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable 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=3D170847 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 --===============4082868005506155858==-- From stickster at gmail.com Thu Jun 4 22:08:15 2015 Content-Type: multipart/mixed; boundary="===============6280536745979931876==" MIME-Version: 1.0 From: Paul W. Frields To: docs at lists.fedoraproject.org Subject: Re: Test of Docs Packaging Date: Sat, 15 Oct 2005 10:48:07 -0400 Message-ID: <1129387688.7677.3.camel@localhost.localdomain> In-Reply-To: 1129327382.3442.10.camel@cassandra.boston.redhat.com --===============6280536745979931876== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable 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=3D170847 > = > 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/ --===============6280536745979931876== Content-Type: application/pgp-signature MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="signature.asc" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4xIChHTlUv TGludXgpCgppRDhEQlFCRFVSYW5yTnZKTjcwUk54Y1JBcUszQUpvQ3VkYmNLQzRKVTRhYk9SRTVM SkZsdG10ZHhBQ2ZhZHdrCkFBMVpYRndSZVEyNUFQVUZwMDlqMTRRPQo9eElYSAotLS0tLUVORCBQ R1AgU0lHTkFUVVJFLS0tLS0K --===============6280536745979931876==-- From mclasen at redhat.com Thu Jun 4 22:08:15 2015 Content-Type: multipart/mixed; boundary="===============2305715976629651353==" MIME-Version: 1.0 From: Matthias Clasen To: docs at lists.fedoraproject.org Subject: Including Fedora documentation in yelp Date: Mon, 17 Oct 2005 15:21:43 -0400 Message-ID: <1129576903.2998.11.camel@golem.boston.redhat.com> --===============2305715976629651353== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable We want to integrate Fedora documentation a bit better with the desktop for FC5 (see https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=3D170813 and https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=3D170847) 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 --===============2305715976629651353==-- From kwade at redhat.com Thu Jun 4 22:08:15 2015 Content-Type: multipart/mixed; boundary="===============5370389610074280066==" MIME-Version: 1.0 From: Karsten Wade To: docs at lists.fedoraproject.org Subject: Re: Fedora docs processing (Was: [fedora-java] batik [Fwd: Re: com.sun.image.*]) Date: Wed, 19 Oct 2005 17:05:33 -0700 Message-ID: <1129766733.18168.386.camel@erato.phig.org> In-Reply-To: 1129763488.2843.19.camel@dhcp-172-16-25-224.sfbay.redhat.com --===============5370389610074280066== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable (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/ --===============5370389610074280066== Content-Type: application/pgp-signature MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="signature.asc" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4xIChHTlUv TGludXgpCgppRDhEQlFCRFZ0OU4yWklPQnEwT0RFRVJBdHhUQUtEbGNTQUpmUEZ0bUx1Sm40RnZr dnBvMUJ0SkJRQ2JCZFJ2CkMvT0ZwSitNUXVDcGdwMTVkREhpeURvPQo9NmF0aAotLS0tLUVORCBQ R1AgU0lHTkFUVVJFLS0tLS0K --===============5370389610074280066==-- From stuart at elsn.org Thu Jun 4 22:08:15 2015 Content-Type: multipart/mixed; boundary="===============0803409874885219359==" MIME-Version: 1.0 From: Stuart Ellis To: docs at lists.fedoraproject.org Subject: Re: Fedora docs processing (Was: [fedora-java] batik [Fwd: Re: com.sun.image.*]) Date: Thu, 20 Oct 2005 01:15:02 +0100 Message-ID: <1129767302.9167.4.camel@localhost.localdomain> In-Reply-To: 1129766733.18168.386.camel@erato.phig.org --===============0803409874885219359== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable 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(a)elsn.org Fedora Documentation Project: http://fedora.redhat.com/projects/docs/ GPG key ID: 7098ABEA GPG key fingerprint: 68B0 E291 FB19 C845 E60E 9569 292E E365 7098 ABEA --===============0803409874885219359== Content-Type: application/pgp-signature MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="signature.asc" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4xIChHTlUv TGludXgpCgppRDhEQlFCRFZ1R0dLUzdqWlhDWXErb1JBdVRIQUo5blRmOTN6SXM5czRoTXNSWnlQ Yk9XZHgxOGtnQ2ZaOU4vCldBdytsZnpVZmVMUEkzUTJTSVpHUWJvPQo9NUZzOQotLS0tLUVORCBQ R1AgU0lHTkFUVVJFLS0tLS0K --===============0803409874885219359==-- From stuart at elsn.org Thu Jun 4 22:08:15 2015 Content-Type: multipart/mixed; boundary="===============3156857418631163949==" MIME-Version: 1.0 From: Stuart Ellis To: docs at lists.fedoraproject.org Subject: FC4 Release Notes Imported into Wiki Date: Thu, 20 Oct 2005 01:18:45 +0100 Message-ID: <1129767525.9167.7.camel@localhost.localdomain> --===============3156857418631163949== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable 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(a)elsn.org Fedora Documentation Project: http://fedora.redhat.com/projects/docs/ GPG key ID: 7098ABEA GPG key fingerprint: 68B0 E291 FB19 C845 E60E 9569 292E E365 7098 ABEA --===============3156857418631163949== Content-Type: application/pgp-signature MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="signature.asc" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4xIChHTlUv TGludXgpCgppRDhEQlFCRFZ1SmxLUzdqWlhDWXErb1JBamt1QUo0empQZTJJdHhHdm9LSE10WWIz czNCSDRuQjJRQ1pBUmsvCmt1ZG41UEZPNW9UbVJKdUkrUlcrSmdvPQo9eTNkYgotLS0tLUVORCBQ R1AgU0lHTkFUVVJFLS0tLS0K --===============3156857418631163949==-- From kwade at redhat.com Thu Jun 4 22:08:16 2015 Content-Type: multipart/mixed; boundary="===============2305654375357738008==" MIME-Version: 1.0 From: Karsten Wade To: docs at lists.fedoraproject.org Subject: Re: Test of Docs Packaging Date: Wed, 19 Oct 2005 17:23:20 -0700 Message-ID: <1129767800.18168.397.camel@erato.phig.org> In-Reply-To: 20051014154139.6b9b4b67.Tommy.Reynolds@MegaCoder.com --===============2305654375357738008== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable 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/ --===============2305654375357738008== Content-Type: application/pgp-signature MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="signature.asc" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4xIChHTlUv TGludXgpCgppRDhEQlFCRFZ1TjMyWklPQnEwT0RFRVJBcllKQUo0aS81czVpZmRldVJ3Nk00cDhY MWszcnBpYVZRQ2d5T3YzCnh6NWt2REdBdk5VYkNvT2tMSFBremM4PQo9bFJmUgotLS0tLUVORCBQ R1AgU0lHTkFUVVJFLS0tLS0K --===============2305654375357738008==-- From kwade at redhat.com Thu Jun 4 22:08:16 2015 Content-Type: multipart/mixed; boundary="===============7564456589656150769==" MIME-Version: 1.0 From: Karsten Wade To: docs at lists.fedoraproject.org Subject: Re: Test of Docs Packaging Date: Wed, 19 Oct 2005 17:26:34 -0700 Message-ID: <1129767994.18168.401.camel@erato.phig.org> In-Reply-To: 1129327382.3442.10.camel@cassandra.boston.redhat.com --===============7564456589656150769== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable 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/ --===============7564456589656150769== Content-Type: application/pgp-signature MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="signature.asc" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4xIChHTlUv TGludXgpCgppRDhEQlFCRFZ1UTYyWklPQnEwT0RFRVJBb1dOQUo5d2Z5dlJsU0p1MEppYmFvYkc5 cVB4aWZLbDl3Q2d4b1EwCkFqMFBuQ25JTnF6bnBZL1VzNHBiQWR3PQo9bXZZdAotLS0tLUVORCBQ R1AgU0lHTkFUVVJFLS0tLS0K --===============7564456589656150769==-- From kwade at redhat.com Thu Jun 4 22:08:16 2015 Content-Type: multipart/mixed; boundary="===============1344445086078684437==" MIME-Version: 1.0 From: Karsten Wade To: docs at lists.fedoraproject.org Subject: Re: FC4 Release Notes Imported into Wiki Date: Wed, 19 Oct 2005 17:28:45 -0700 Message-ID: <1129768125.18168.404.camel@erato.phig.org> In-Reply-To: 1129767525.9167.7.camel@localhost.localdomain --===============1344445086078684437== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable 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/ --===============1344445086078684437== Content-Type: application/pgp-signature MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="signature.asc" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4xIChHTlUv TGludXgpCgppRDhEQlFCRFZ1UzkyWklPQnEwT0RFRVJBczZqQUtDZllKZmtPK055RTNUSkFvRmJF dVllbCtKRS93Q2dzaWgxCnI0SVk4bHlDd1l6aGE5OTJZU3o5a0ZJPQo9MWIvbQotLS0tLUVORCBQ R1AgU0lHTkFUVVJFLS0tLS0K --===============1344445086078684437==-- From kwade at redhat.com Thu Jun 4 22:08:16 2015 Content-Type: multipart/mixed; boundary="===============3012855228296356223==" MIME-Version: 1.0 From: Karsten Wade To: docs at lists.fedoraproject.org Subject: minutes FDSCo 18-Oct-2005 Date: Wed, 19 Oct 2005 17:59:18 -0700 Message-ID: <1129769958.18168.416.camel@erato.phig.org> --===============3012855228296356223== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable 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: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 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: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D * 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(a)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/ --===============3012855228296356223== Content-Type: application/pgp-signature MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="signature.asc" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4xIChHTlUv TGludXgpCgppRDhEQlFCRFZ1dm0yWklPQnEwT0RFRVJBdmlUQUo5anBDQmtJYXV6OEZEdnZDa0or dG96Qk1Nc05RQ2dxenpNCno3cUtvSzJLSXNsdWFMNTBLUEF2bWRvPQo9a3RZZwotLS0tLUVORCBQ R1AgU0lHTkFUVVJFLS0tLS0K --===============3012855228296356223==-- From kwade at redhat.com Thu Jun 4 22:08:16 2015 Content-Type: multipart/mixed; boundary="===============0140235066864616584==" MIME-Version: 1.0 From: Karsten Wade To: docs at lists.fedoraproject.org Subject: Re: minutes FDSCo 18-Oct-2005 Date: Thu, 20 Oct 2005 00:38:08 -0700 Message-ID: <1129793888.18168.455.camel@erato.phig.org> In-Reply-To: 1129769958.18168.416.camel@erato.phig.org --===============0140235066864616584== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable On Wed, 2005-10-19 at 17:59 -0700, Karsten Wade wrote: > Highlights: > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > = > * 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/ --===============0140235066864616584== Content-Type: application/pgp-signature MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="signature.asc" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4xIChHTlUv TGludXgpCgppRDhEQlFCRFYwbGcyWklPQnEwT0RFRVJBdVRnQUo5MFJ6T3llbE1uMTg4TVBzMGFM b1lwSVUvalFBQ2ZUNFZmClY2NENHTGhwc1dJK0JvMzNHYWNWZnE4PQo9Nm1SUQotLS0tLUVORCBQ R1AgU0lHTkFUVVJFLS0tLS0K --===============0140235066864616584==-- From Tommy.Reynolds at MegaCoder.com Thu Jun 4 22:08:16 2015 Content-Type: multipart/mixed; boundary="===============8357468204746789634==" MIME-Version: 1.0 From: Tommy Reynolds To: docs at lists.fedoraproject.org Subject: Re: Fedora docs processing (Was: [fedora-java] batik [Fwd: Re: com.sun.image.*]) Date: Thu, 20 Oct 2005 10:35:46 -0500 Message-ID: <20051020103546.98ddc670.Tommy.Reynolds@MegaCoder.com> In-Reply-To: 1129766733.18168.386.camel@erato.phig.org --===============8357468204746789634== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable 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 --===============8357468204746789634== Content-Type: application/pgp-signature MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="attachment.sig" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4xIChHTlUv TGludXgpCgppRDhEQlFGRFY3bFMvMHlkcWtRRGxRRVJBc2hXQUo5ODd6TnpIK0t0dk9KWTFTeWx3 R2RTUTZVdDBnQ2d2WU9tCkR2RkU5NHBVck01K25uc0p6RlBSTm5VPQo9b0h5RQotLS0tLUVORCBQ R1AgU0lHTkFUVVJFLS0tLS0K --===============8357468204746789634==-- From partha_26786794123 at yahoo.com Thu Jun 4 22:08:16 2015 Content-Type: multipart/mixed; boundary="===============8288503031803652257==" MIME-Version: 1.0 From: Partha Goswami To: docs at lists.fedoraproject.org Subject: translation Date: Thu, 20 Oct 2005 09:41:56 -0700 Message-ID: <20051020164156.90749.qmail@web33603.mail.mud.yahoo.com> --===============8288503031803652257== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable 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/ --===============8288503031803652257==-- From stickster at gmail.com Thu Jun 4 22:08:16 2015 Content-Type: multipart/mixed; boundary="===============1427336070540716818==" MIME-Version: 1.0 From: Paul W. Frields To: docs at lists.fedoraproject.org Subject: Re: Test of Docs Packaging Date: Thu, 20 Oct 2005 17:27:40 -0400 Message-ID: <1129843660.2973.1.camel@localhost.localdomain> In-Reply-To: 1129767994.18168.401.camel@erato.phig.org --===============1427336070540716818== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable 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/ --===============1427336070540716818== Content-Type: application/pgp-signature MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="signature.asc" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4xIChHTlUv TGludXgpCgppRDhEQlFCRFdBdk1yTnZKTjcwUk54Y1JBaVFuQUo5cHFiRmpIM3QvMm0vNVZPaExN d2Y2OWFMVktRQ2czQXBpCkJURFRkbDl2VDMrQ2RZR0VHTkljakJVPQo9bndZdAotLS0tLUVORCBQ R1AgU0lHTkFUVVJFLS0tLS0K --===============1427336070540716818==-- From stickster at gmail.com Thu Jun 4 22:08:16 2015 Content-Type: multipart/mixed; boundary="===============2409205626968498988==" MIME-Version: 1.0 From: Paul W. Frields To: docs at lists.fedoraproject.org Subject: Re: Test of Docs Packaging Date: Thu, 20 Oct 2005 17:33:17 -0400 Message-ID: <1129843997.2973.8.camel@localhost.localdomain> In-Reply-To: 1129767800.18168.397.camel@erato.phig.org --===============2409205626968498988== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable 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/ --===============2409205626968498988== Content-Type: application/pgp-signature MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="signature.asc" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4xIChHTlUv TGludXgpCgppRDhEQlFCRFdBMGNyTnZKTjcwUk54Y1JBalJCQUo0NkVibnNUbDZydXZYRWU2R2hq TUVzWHhOK1BBQ2VPRE5oCkc0MXJrcHM2MlQ1bHRqU2xycHJKNmlzPQo9QVVnMgotLS0tLUVORCBQ R1AgU0lHTkFUVVJFLS0tLS0K --===============2409205626968498988==-- From stickster at gmail.com Thu Jun 4 22:08:17 2015 Content-Type: multipart/mixed; boundary="===============7994371723100994569==" MIME-Version: 1.0 From: Paul W. Frields To: docs at lists.fedoraproject.org Subject: Re: Fedora docs processing (Was: [fedora-java] batik [Fwd: Re: com.sun.image.*]) Date: Thu, 20 Oct 2005 17:34:33 -0400 Message-ID: <1129844073.2973.10.camel@localhost.localdomain> In-Reply-To: 20051020103546.98ddc670.Tommy.Reynolds@MegaCoder.com --===============7994371723100994569== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable 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/ --===============7994371723100994569== Content-Type: application/pgp-signature MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="signature.asc" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4xIChHTlUv TGludXgpCgppRDhEQlFCRFdBMXByTnZKTjcwUk54Y1JBa3Q0QUo5Slo2endXdlY2cTRzVW5wcEJG cU5QNFg4K093Q2NDVkJmCmo1Kzg5dEhvYmFwVkk0V2VVUjRmOHU4PQo9K1dQdwotLS0tLUVORCBQ R1AgU0lHTkFUVVJFLS0tLS0K --===============7994371723100994569==-- From Tommy.Reynolds at MegaCoder.com Thu Jun 4 22:08:17 2015 Content-Type: multipart/mixed; boundary="===============2490167051983000764==" MIME-Version: 1.0 From: Tommy Reynolds To: docs at lists.fedoraproject.org Subject: Re: Test of Docs Packaging Date: Thu, 20 Oct 2005 16:48:59 -0500 Message-ID: <20051020164859.6bdad5df.Tommy.Reynolds@MegaCoder.com> In-Reply-To: 1129843997.2973.8.camel@localhost.localdomain --===============2490167051983000764== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable 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 --===============2490167051983000764== Content-Type: application/pgp-signature MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="attachment.sig" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4xIChHTlUv TGludXgpCgppRDhEQlFGRFdCREwvMHlkcWtRRGxRRVJBaDFNQUo0d1htYkpYc2RNRWIxeVNXK1cy eHZubytoakJRQ2JCV0Y2Cjc1THBGNHdZNFNMSDN6bDdvRGZob3NjPQo9WG9SegotLS0tLUVORCBQ R1AgU0lHTkFUVVJFLS0tLS0K --===============2490167051983000764==-- From stickster at gmail.com Thu Jun 4 22:08:17 2015 Content-Type: multipart/mixed; boundary="===============6175254035659547551==" MIME-Version: 1.0 From: Paul W. Frields To: docs at lists.fedoraproject.org Subject: Re: Test of Docs Packaging Date: Thu, 20 Oct 2005 18:16:56 -0400 Message-ID: <1129846616.2973.18.camel@localhost.localdomain> In-Reply-To: 20051020164859.6bdad5df.Tommy.Reynolds@MegaCoder.com --===============6175254035659547551== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable 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/ --===============6175254035659547551== Content-Type: application/pgp-signature MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="signature.asc" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4xIChHTlUv TGludXgpCgppRDhEQlFCRFdCZFlyTnZKTjcwUk54Y1JBaUhoQUo5dkhpWmRiV0NNQk4weTdEZTJE WHNMVEdSelRRQ2c5Vk5KCkpiRENZdGl2MFlpUDF5OVd1RkcwUmtrPQo9ZWVUYQotLS0tLUVORCBQ R1AgU0lHTkFUVVJFLS0tLS0K --===============6175254035659547551==-- From Tommy.Reynolds at MegaCoder.com Thu Jun 4 22:08:17 2015 Content-Type: multipart/mixed; boundary="===============3046009825307045337==" MIME-Version: 1.0 From: Tommy Reynolds To: docs at lists.fedoraproject.org Subject: Re: Test of Docs Packaging Date: Thu, 20 Oct 2005 18:01:04 -0500 Message-ID: <20051020180104.2d2cc8aa.Tommy.Reynolds@MegaCoder.com> In-Reply-To: 1129846616.2973.18.camel@localhost.localdomain --===============3046009825307045337== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable 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 --===============3046009825307045337== Content-Type: application/pgp-signature MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="attachment.sig" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4xIChHTlUv TGludXgpCgppRDhEQlFGRFdDRzAvMHlkcWtRRGxRRVJBdU9NQUo5bXVoQUIwMk5RRTlkY1pibnR2 aDl1L0ZTZTZnQ2dpcHlsCmRDUUVUaGpsNjdTQjdtTzI3VFJlbzVzPQo9azNaeAotLS0tLUVORCBQ R1AgU0lHTkFUVVJFLS0tLS0K --===============3046009825307045337==-- From kwade at redhat.com Thu Jun 4 22:08:17 2015 Content-Type: multipart/mixed; boundary="===============4815333136814640180==" MIME-Version: 1.0 From: Karsten Wade To: docs at lists.fedoraproject.org Subject: Re: Test of Docs Packaging Date: Fri, 21 Oct 2005 05:27:21 -0700 Message-ID: <1129897641.18168.582.camel@erato.phig.org> In-Reply-To: 20051020180104.2d2cc8aa.Tommy.Reynolds@MegaCoder.com --===============4815333136814640180== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable 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/ --===============4815333136814640180== Content-Type: application/pgp-signature MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="signature.asc" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4xIChHTlUv TGludXgpCgppRDhEQlFCRFdONnAyWklPQnEwT0RFRVJBbEUxQUp3UC9Xb0RrbS9HbHFsV1Njb1R6 eWRoRzFvZGFBQ2RGcnJJCktqVy9LZU82MjQrcGRBTG53SmE3QlRRPQo9azhmNgotLS0tLUVORCBQ R1AgU0lHTkFUVVJFLS0tLS0K --===============4815333136814640180==-- From ghenry at suretecsystems.com Thu Jun 4 22:08:17 2015 Content-Type: multipart/mixed; boundary="===============5243066791816341239==" MIME-Version: 1.0 From: Gavin Henry To: docs at lists.fedoraproject.org Subject: [Fwd: printing changes for FC5] Date: Fri, 21 Oct 2005 14:15:33 +0100 Message-ID: <37747.195.38.86.72.1129900533.squirrel@webmail.suretecsystems.com> --===============5243066791816341239== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable 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. */ --===============5243066791816341239== Content-Type: application/pgp-signature MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="untitled-2.sig" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4yIChHTlUv TGludXgpCgppRDhEQlFGRFdPVjRMRitMWWFGOTRGRVJBc1pPQUowVXJDVlZvRWNYTkF3Rnh2ZXQw VVk3aFBudXFnQ2VMeTVsCnlLR2dScHRscTlQWXY0cVl1Q1Y1dFYwPQo9ckdPNwotLS0tLUVORCBQ R1AgU0lHTkFUVVJFLS0tLS0K --===============5243066791816341239==-- From stickster at gmail.com Thu Jun 4 22:08:17 2015 Content-Type: multipart/mixed; boundary="===============4437705565616470248==" MIME-Version: 1.0 From: Paul W. Frields To: docs at lists.fedoraproject.org Subject: Re: Test of Docs Packaging Date: Fri, 21 Oct 2005 09:52:37 -0400 Message-ID: <1129902757.2994.11.camel@localhost.localdomain> In-Reply-To: 1129897641.18168.582.camel@erato.phig.org --===============4437705565616470248== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable 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 Fedo= ra > > > 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/ --===============4437705565616470248== Content-Type: application/pgp-signature MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="signature.asc" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4xIChHTlUv TGludXgpCgppRDhEQlFCRFdQS2xyTnZKTjcwUk54Y1JBaW9DQUtESWhCb09rUVBodE5RZ1lKVkJ1 L0N0dk9Kam5BQ2ZXT1NlClZRWVRjdEdPL2ppYVpyQkoxQll6UE0wPQo9TndWRAotLS0tLUVORCBQ R1AgU0lHTkFUVVJFLS0tLS0K --===============4437705565616470248==-- From kwade at redhat.com Thu Jun 4 22:08:17 2015 Content-Type: multipart/mixed; boundary="===============7915767419490746907==" MIME-Version: 1.0 From: Karsten Wade To: docs at lists.fedoraproject.org Subject: establishing a timezone for FDP Date: Fri, 21 Oct 2005 07:43:57 -0700 Message-ID: <1129905837.18168.689.camel@erato.phig.org> --===============7915767419490746907== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable 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/ --===============7915767419490746907== Content-Type: application/pgp-signature MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="signature.asc" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4xIChHTlUv TGludXgpCgppRDhEQlFCRFdQNnQyWklPQnEwT0RFRVJBZ0NkQUo5ZlN0eDNocmlrd016QUNQTE0v MUFoV3ZmRGx3Q2VLdDc5CjVNY0lSM0dhbUdTTmxkaHdiOUVpRE5zPQo9TjlvSQotLS0tLUVORCBQ R1AgU0lHTkFUVVJFLS0tLS0K --===============7915767419490746907==-- From kwade at redhat.com Thu Jun 4 22:08:17 2015 Content-Type: multipart/mixed; boundary="===============8520163778439084815==" MIME-Version: 1.0 From: Karsten Wade To: docs at lists.fedoraproject.org Subject: Re: Test of Docs Packaging Date: Fri, 21 Oct 2005 07:46:08 -0700 Message-ID: <1129905968.18168.693.camel@erato.phig.org> In-Reply-To: 1129902757.2994.11.camel@localhost.localdomain --===============8520163778439084815== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable 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/ --===============8520163778439084815== Content-Type: application/pgp-signature MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="signature.asc" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4xIChHTlUv TGludXgpCgppRDhEQlFCRFdQOHcyWklPQnEwT0RFRVJBbmc1QUo5ejk4T3hIbldBcW00TXBFWDZW L2NObDdlemd3Q2c0QlFoCjZNekJ0R2VhOHNwVVpKdTFpQlQxelc4PQo9QUNPLwotLS0tLUVORCBQ R1AgU0lHTkFUVVJFLS0tLS0K --===============8520163778439084815==-- From dwmw2 at infradead.org Thu Jun 4 22:08:18 2015 Content-Type: multipart/mixed; boundary="===============0639614531765144687==" MIME-Version: 1.0 From: David Woodhouse To: docs at lists.fedoraproject.org Subject: Re: establishing a timezone for FDP Date: Fri, 21 Oct 2005 15:49:47 +0100 Message-ID: <1129906187.15431.122.camel@baythorne.infradead.org> In-Reply-To: 1129905837.18168.689.camel@erato.phig.org --===============0639614531765144687== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable 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 --===============0639614531765144687==-- From Tommy.Reynolds at MegaCoder.com Thu Jun 4 22:08:18 2015 Content-Type: multipart/mixed; boundary="===============1336091329482408825==" MIME-Version: 1.0 From: Tommy Reynolds To: docs at lists.fedoraproject.org Subject: Re: Test of Docs Packaging Date: Fri, 21 Oct 2005 11:06:01 -0500 Message-ID: <20051021110601.49ab9f80.Tommy.Reynolds@MegaCoder.com> In-Reply-To: 1129897641.18168.582.camel@erato.phig.org --===============1336091329482408825== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable 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 --===============1336091329482408825== Content-Type: application/pgp-signature MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="attachment.sig" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4xIChHTlUv TGludXgpCgppRDhEQlFGRFdSSHQvMHlkcWtRRGxRRVJBcUNQQUtDeC9ZL0FhQWVXdEJqanNKQXdY bnBXT21Hd2xRQ2ZRV1NZCmxyVkJkczBwdG1CTEluV2tmR0x0dkxZPQo9bWt3cQotLS0tLUVORCBQ R1AgU0lHTkFUVVJFLS0tLS0K --===============1336091329482408825==-- From kwade at redhat.com Thu Jun 4 22:08:18 2015 Content-Type: multipart/mixed; boundary="===============8955886579614522192==" MIME-Version: 1.0 From: Karsten Wade To: docs at lists.fedoraproject.org Subject: Re: establishing a timezone for FDP Date: Fri, 21 Oct 2005 09:07:24 -0700 Message-ID: <1129910844.18168.701.camel@erato.phig.org> In-Reply-To: 1129906187.15431.122.camel@baythorne.infradead.org --===============8955886579614522192== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable 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/ --===============8955886579614522192== Content-Type: application/pgp-signature MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="signature.asc" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4xIChHTlUv TGludXgpCgppRDhEQlFCRFdSSTgyWklPQnEwT0RFRVJBdEdzQUo5c2ZzWTBvNzc4S2pzaWkybjhG dGhKUEtvNjRBQ2VJQkZMCmFYa0Z6dUh6SHQwNFE5cjUxdVRDYURjPQo9UVE2WQotLS0tLUVORCBQ R1AgU0lHTkFUVVJFLS0tLS0K --===============8955886579614522192==-- From sopwith at redhat.com Thu Jun 4 22:08:18 2015 Content-Type: multipart/mixed; boundary="===============7053773261554251850==" MIME-Version: 1.0 From: Elliot Lee To: docs at lists.fedoraproject.org Subject: Fedora web team Date: Fri, 21 Oct 2005 12:13:17 -0400 Message-ID: --===============7053773261554251850== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable 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 --===============7053773261554251850==-- From Tommy.Reynolds at MegaCoder.com Thu Jun 4 22:08:18 2015 Content-Type: multipart/mixed; boundary="===============1598791286170210207==" MIME-Version: 1.0 From: Tommy Reynolds To: docs at lists.fedoraproject.org Subject: Saxon, FOP, and xmlto Date: Fri, 21 Oct 2005 11:20:17 -0500 Message-ID: <20051021112017.c0ef4870.Tommy.Reynolds@MegaCoder.com> --===============1598791286170210207== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable 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 --===============1598791286170210207== Content-Type: application/pgp-signature MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="attachment.sig" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4xIChHTlUv TGludXgpCgppRDhEQlFGRFdSVkYvMHlkcWtRRGxRRVJBaEtWQUo0MjZja0prdUpqMzZ6YU5ub1Rz bjlDMUwwaENnQ2ZiT0taCityTDh2MDdxY1BXc1lyalNCWFE0SDFFPQo9SnVtawotLS0tLUVORCBQ R1AgU0lHTkFUVVJFLS0tLS0K --===============1598791286170210207==-- From kwade at redhat.com Thu Jun 4 22:08:18 2015 Content-Type: multipart/mixed; boundary="===============4432852992055099618==" MIME-Version: 1.0 From: Karsten Wade To: docs at lists.fedoraproject.org Subject: Re: Fedora web team Date: Fri, 21 Oct 2005 09:35:37 -0700 Message-ID: <1129912537.18168.707.camel@erato.phig.org> In-Reply-To: Pine.LNX.4.58.0510211213080.22869@devserv.devel.redhat.com --===============4432852992055099618== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable 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/ --===============4432852992055099618== Content-Type: application/pgp-signature MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="signature.asc" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4xIChHTlUv TGludXgpCgppRDhEQlFCRFdSaloyWklPQnEwT0RFRVJBcFEvQUowV2ZWaWw0T2IvdlVBK3U1RWdR RVFlejhHRHF3Q2dpbXFQCkVHUDcyeGdZc3NvTDBTVElIWHJham9BPQo9YTNXNgotLS0tLUVORCBQ R1AgU0lHTkFUVVJFLS0tLS0K --===============4432852992055099618==-- From nman64 at n-man.com Thu Jun 4 22:08:18 2015 Content-Type: multipart/mixed; boundary="===============2284855408597515587==" MIME-Version: 1.0 From: Patrick W. Barnes To: docs at lists.fedoraproject.org Subject: Re: establishing a timezone for FDP Date: Fri, 21 Oct 2005 11:49:17 -0500 Message-ID: <43591C0D.4000307@n-man.com> In-Reply-To: 1129910844.18168.701.camel@erato.phig.org --===============2284855408597515587== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable 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(a)n-man.com www.n-man.com -- = --===============2284855408597515587== Content-Type: application/pgp-signature MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="signature.asc" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4yIChHTlUv TGludXgpCgppRDhEQlFGRFdSd1JkQm9CN0NtVUI5Z1JBaXNqQUo5Mis5aWtxK1JONFBHOHdGek9r TG1VSHRkTVZRQ2VJejNQCnZFNmtuSXo1UzZiQjEwMmQrWlppeHZRPQo9S0xWUgotLS0tLUVORCBQ R1AgU0lHTkFUVVJFLS0tLS0K --===============2284855408597515587==-- From stickster at gmail.com Thu Jun 4 22:08:18 2015 Content-Type: multipart/mixed; boundary="===============0198227877359600531==" MIME-Version: 1.0 From: Paul W. Frields To: docs at lists.fedoraproject.org Subject: Re: establishing a timezone for FDP Date: Fri, 21 Oct 2005 13:02:41 -0400 Message-ID: <1129914162.2994.12.camel@localhost.localdomain> In-Reply-To: 43591C0D.4000307@n-man.com --===============0198227877359600531== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable 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/ --===============0198227877359600531== Content-Type: application/pgp-signature MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="signature.asc" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4xIChHTlUv TGludXgpCgppRDhEQlFCRFdSOHhyTnZKTjcwUk54Y1JBdWcrQUtEV0ZmT2crSEFNWjlheXd4bWs3 eXpUaXYzV2NBQ2d2SUI3ClMwUFRhQlNjSFZaUjcreUFHbldOeWVVPQo9L2Y3NgotLS0tLUVORCBQ R1AgU0lHTkFUVVJFLS0tLS0K --===============0198227877359600531==-- From hballal at gmail.com Thu Jun 4 22:08:18 2015 Content-Type: multipart/mixed; boundary="===============0563155427807092430==" MIME-Version: 1.0 From: Hrishikesh Ballal To: docs at lists.fedoraproject.org Subject: Self-Introduction: Hrishikesh Ballal Date: Fri, 21 Oct 2005 17:51:00 -0400 Message-ID: <1129931461.2570.2.camel@localhost.localdomain> --===============0563155427807092430== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable 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 =3D D2F7 2117 6C27 519A 3FA3 A2C5 5934 5083 DECE E55D uid Hrishikesh Ballal sub 1024g/CE27A608 2005-06-16 --===============0563155427807092430==-- From bbbush.yuan at gmail.com Thu Jun 4 22:08:18 2015 Content-Type: multipart/mixed; boundary="===============6802700265880336396==" MIME-Version: 1.0 From: Yuan Yijun To: docs at lists.fedoraproject.org Subject: Self-Introduction: Yuan Yijun Date: Sat, 22 Oct 2005 14:17:43 +0800 Message-ID: <76e72f800510212317q32f7577fj@mail.gmail.com> --===============6802700265880336396== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Name: Yuan Yijun (=E8=A2=81=E4=B9=99=E9=92=A7, 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 =3D 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 ^_^ --===============6802700265880336396==-- From nman64 at n-man.com Thu Jun 4 22:08:18 2015 Content-Type: multipart/mixed; boundary="===============0401860075426353463==" MIME-Version: 1.0 From: Patrick W. Barnes To: docs at lists.fedoraproject.org Subject: Re: Self-Introduction: Yuan Yijun Date: Sat, 22 Oct 2005 10:43:43 -0500 Message-ID: <435A5E2F.6030001@n-man.com> In-Reply-To: 76e72f800510212317q32f7577fj@mail.gmail.com --===============0401860075426353463== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Yuan Yijun wrote: > Name: Yuan Yijun (=E8=A2=81=E4=B9=99=E9=92=A7, 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 =3D DCCE E98A DBBC 71F6 57D8 C2BA CF7A 52BD 8334 9= 285 > uid Yuan Yijun (bbbush) > sub 2048g/CDB2236B 2005-10-22 [expires: 2007-01-01] > > > > > > -- > bbbush ^_^ > > = Welcome to the team, =E8=A2=81=E4=B9=99=E9=92=A7. 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(a)n-man.com www.n-man.com -- = --===============0401860075426353463== Content-Type: application/pgp-signature MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="signature.asc" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4yIChHTlUv TGludXgpCgppRDhEQlFGRFdsNDJkQm9CN0NtVUI5Z1JBbDg4QUo5TWExMElFeThpdTNkb095bVNa Y0hmSVF0cnZRQ2dqVVJRCnhlRWswc1habVhQNmdZK2FyeVNmZWc4PQo9bnlybAotLS0tLUVORCBQ R1AgU0lHTkFUVVJFLS0tLS0K --===============0401860075426353463==-- From bbbush.yuan at gmail.com Thu Jun 4 22:08:18 2015 Content-Type: multipart/mixed; boundary="===============7644033145617505466==" MIME-Version: 1.0 From: Yuan Yijun To: docs at lists.fedoraproject.org Subject: Re: Self-Introduction: Yuan Yijun Date: Sun, 23 Oct 2005 15:06:07 +0800 Message-ID: <76e72f800510230006h73bcf8cdw@mail.gmail.com> In-Reply-To: 435A5E2F.6030001@n-man.com --===============7644033145617505466== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable 2005/10/22, Patrick Barnes : > Welcome to the team, =E8=A2=81=E4=B9=99=E9=92=A7. Have you created a wik= i 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 ^_^ --===============7644033145617505466==-- From nman64 at n-man.com Thu Jun 4 22:08:18 2015 Content-Type: multipart/mixed; boundary="===============8454463516346280057==" MIME-Version: 1.0 From: Patrick W. Barnes To: docs at lists.fedoraproject.org Subject: Re: Self-Introduction: Yuan Yijun Date: Sun, 23 Oct 2005 02:26:49 -0500 Message-ID: <435B3B39.3020908@n-man.com> In-Reply-To: 76e72f800510230006h73bcf8cdw@mail.gmail.com --===============8454463516346280057== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Yuan Yijun wrote: > 2005/10/22, Patrick Barnes : > = >> Welcome to the team, =E8=A2=81=E4=B9=99=E9=92=A7. Have you created a wi= ki 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(a)n-man.com www.n-man.com -- = --===============8454463516346280057== Content-Type: application/pgp-signature MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="signature.asc" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4yIChHTlUv TGludXgpCgppRDhEQlFGRFd6czlkQm9CN0NtVUI5Z1JBbXpyQUo5R2RnOExSNXZVV1ZXYisvNWR0 VDFUOUhIOTJRQ2RFT05LClVJcEU3cG4vS3JCNzdmdDdhaStRUnVzPQo9cE92VQotLS0tLUVORCBQ R1AgU0lHTkFUVVJFLS0tLS0K --===============8454463516346280057==-- From bbbush.yuan at gmail.com Thu Jun 4 22:08:19 2015 Content-Type: multipart/mixed; boundary="===============3900819466643671476==" MIME-Version: 1.0 From: Yuan Yijun To: docs at lists.fedoraproject.org Subject: Re: Self-Introduction: Yuan Yijun Date: Sun, 23 Oct 2005 15:39:09 +0800 Message-ID: <76e72f800510230039x4ba04ffu@mail.gmail.com> In-Reply-To: 435B3B39.3020908@n-man.com --===============3900819466643671476== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable 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 ^_^ --===============3900819466643671476==-- From kwade at redhat.com Thu Jun 4 22:08:19 2015 Content-Type: multipart/mixed; boundary="===============2730739147459346902==" MIME-Version: 1.0 From: Karsten Wade To: docs at lists.fedoraproject.org Subject: Re: release-notes Makefile,1.1,1.2 Date: Mon, 24 Oct 2005 07:19:38 -0700 Message-ID: <1130163578.5528.103.camel@erato.phig.org> In-Reply-To: 200510241408.j9OE8vhT017956@cvs-int.fedora.redhat.com --===============2730739147459346902== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable 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 Mak= efile.common instead. However, my method here is obviously sub-par and thr= ows an error, so I'll be punting for help. The objective is to make certai= n that the figs/ directory gets copied over to the HTML directories in all = languages. Actually, the figs-/ needs to get copied to foo-/ HTML director= y. This requires some consideration and kung-fu. It should copy over the = language specific figures if they exist, otherwise use the English by defau= lt so as to not break the build. > = > = > Index: Makefile > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > 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 =3D en > -DOCS_SETUP_PATH=3D ../../docs-common > -XSLPDF =3D $(DOCS_SETUP_PATH)/xsl/main-pdf.xsl > -XSLHTML =3D $(DOCS_SETUP_PATH)/xsl/main-html-nochunks-relnotes.xsl > - > -XSLPDFCOMMONS =3D ${XSLPDF} > -XSLHTMLCOMMONS =3D ${XSLHTML} > - > -XMLCOMMONSPATH=3D${DOCS_SETUP_PATH}/common > -XMLCOMMONS=3D${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=3D} > - xmlto html -x ${XSLHTML} -o ${@:.html=3D} $< > - mkdir -p ${@:.html=3D}/stylesheet-images > - mkdir -p ${@:.html=3D}/figs > - cp $(DOCS_SETUP_PATH)/stylesheet-images/*.png ${@:.html=3D}/stylesheet-= images > - cp ./figs/*.png ${@:.html=3D}/figs > - cp $(DOCS_SETUP_PATH)/css/fedora.css ${@:.html=3D} > - mv ${@:.html=3D}/${@:.html=3D.proc} ${@:.html=3D}/$@ = > - ln -sf ${@:.html=3D}/$@ $@ > - > -%.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=3DRELEASE-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=3DC cvs2cl -f ChangeLog.txt > - > -ChangeLog.xml: > - LANG=3DC 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 =3D en > +DOCBASE =3D RELEASE-NOTES > +XMLEXTRAFILES-en=3Ddaemons.xml database-servers.xml desktop.xml developm= ent-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-no= tes.xml printing.xml project-overview.xml samba.xml security.xml server-too= ls.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=3D$(shell grep BOOKID $(DOCBASE)-en.xml | sed 's/ +DATE=3D${shell grep BOOKID $(DOCBASE)-en.xml | sed 's/.\+(//' | sed 's/)= .\+//' } > +NOW=3D$(shell date +"%a %b %e %Y") > +SPECIN=3D../docs-common/packaging/fedora-doc.spec.in.common > +OMFIN=3D../docs-common/packaging/fedora-doc.omf.in.common > +DESKTOPIN=3D../docs-common/packaging/fedora-doc.desktop.in.common > +DOCSPEC=3D$(PWD)/SPECS/$(DOCBASE).spec > +DOCOMF=3D$(PWD)/SOURCES/fedora-doc-$(DOCBASE)-C.omf > +DOCDESKTOP=3D$(PWD)/SOURCES/fedora-doc-$(DOCBASE).desktop > +DOCSRCTAR=3D$(PWD)/SOURCES/$(DOCBASE)-$(VERSION).src.tar.gz > +TITLE=3D$(shell ../docs-common/packaging/titlegrab.py $(DOCBASE)-en.xml = | sed 's/^ \+//') > +###################################################### > +# Some RPM flags... > +###################################################### > +RPMFLAGS=3D--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(a)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/ --===============2730739147459346902== Content-Type: application/pgp-signature MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="signature.asc" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4xIChHTlUv TGludXgpCgppRDhEQlFCRFhPMTYyWklPQnEwT0RFRVJBdEhjQUowWjE1WlY1U3lLeVNvc0Nsc2lU RTdObE9NZ0J3Q2ZaM2FaCjdLdEdmNVpxWVV1cDE5WGJNdWxKMjM0PQo9R0FINAotLS0tLUVORCBQ R1AgU0lHTkFUVVJFLS0tLS0K --===============2730739147459346902==-- From kwade at redhat.com Thu Jun 4 22:08:19 2015 Content-Type: multipart/mixed; boundary="===============4278775951392112480==" MIME-Version: 1.0 From: Karsten Wade To: docs at lists.fedoraproject.org Subject: Re: establishing a timezone for FDP Date: Mon, 24 Oct 2005 07:36:18 -0700 Message-ID: <1130164578.5528.118.camel@erato.phig.org> In-Reply-To: 1129914162.2994.12.camel@localhost.localdomain --===============4278775951392112480== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable 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=3D98.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/ --===============4278775951392112480== Content-Type: application/pgp-signature MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="signature.asc" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4xIChHTlUv TGludXgpCgppRDhEQlFCRFhQRmkyWklPQnEwT0RFRVJBdlZUQUo5cTJpOUFySzk1MjFGMThXbEV2 Rlpud3FBbyt3Q2ZRd01nCnN6WmVzbW5lcVk1TnBHRnlEM1dGdk1NPQo9b3ZaeAotLS0tLUVORCBQ R1AgU0lHTkFUVVJFLS0tLS0K --===============4278775951392112480==-- From kwade at redhat.com Thu Jun 4 22:08:19 2015 Content-Type: multipart/mixed; boundary="===============4972432017550398250==" MIME-Version: 1.0 From: Karsten Wade To: docs at lists.fedoraproject.org Subject: invitation to hack the relnotes tonight Date: Mon, 24 Oct 2005 07:39:58 -0700 Message-ID: <1130164798.5528.123.camel@erato.phig.org> --===============4972432017550398250== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable 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/ --===============4972432017550398250== Content-Type: application/pgp-signature MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="signature.asc" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4xIChHTlUv TGludXgpCgppRDhEQlFCRFhQSSsyWklPQnEwT0RFRVJBa0VlQUtDcmVIRUs0Q3RXV1RoRHRRbitn akpOeEtrMXJnQ2ZYaS8wCmZFNmRJNmJ5b1Zqa0Mya0MzcjlXSnRVPQo9cWF2agotLS0tLUVORCBQ R1AgU0lHTkFUVVJFLS0tLS0K --===============4972432017550398250==-- From stickster at gmail.com Thu Jun 4 22:08:19 2015 Content-Type: multipart/mixed; boundary="===============3299690864628868303==" MIME-Version: 1.0 From: Paul W. Frields To: docs at lists.fedoraproject.org Subject: Re: release-notes Makefile,1.1,1.2 Date: Mon, 24 Oct 2005 10:47:09 -0400 Message-ID: <1130165229.3022.2.camel@localhost.localdomain> In-Reply-To: 1130163578.5528.103.camel@erato.phig.org --===============3299690864628868303== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable 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/ --===============3299690864628868303== Content-Type: application/pgp-signature MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="signature.asc" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4xIChHTlUv TGludXgpCgppRDhEQlFCRFhQUHNyTnZKTjcwUk54Y1JBanovQUtEeXhrYTZ2SWpSay8zT0dsT2Zl YS96ckN1Nkh3Q2ZTMlJRClpnc2lTb1VFN3BXV0JkOVJURDZXR0swPQo9SkZ1bAotLS0tLUVORCBQ R1AgU0lHTkFUVVJFLS0tLS0K --===============3299690864628868303==-- From Tommy.Reynolds at MegaCoder.com Thu Jun 4 22:08:19 2015 Content-Type: multipart/mixed; boundary="===============5782748110265679211==" MIME-Version: 1.0 From: Tommy Reynolds To: docs at lists.fedoraproject.org Subject: Re: release-notes Makefile,1.1,1.2 Date: Mon, 24 Oct 2005 10:33:29 -0500 Message-ID: <20051024103329.2e4adf70.Tommy.Reynolds@MegaCoder.com> In-Reply-To: 1130163578.5528.103.camel@erato.phig.org --===============5782748110265679211== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable 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 --===============5782748110265679211== Content-Type: application/pgp-signature MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="attachment.sig" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4xIChHTlUv TGludXgpCgppRDhEQlFGRFhQN0ovMHlkcWtRRGxRRVJBbkk2QUo0ajVzeEp0eHdrM01lNFoxMnFo RHE5TGxmdUxRQ2ZRaTdMCm9zYVBSU2RUNlRHcmI2dDdqZUhoOGM0PQo9eENqZAotLS0tLUVORCBQ R1AgU0lHTkFUVVJFLS0tLS0K --===============5782748110265679211==-- From bbbush.yuan at gmail.com Thu Jun 4 22:08:19 2015 Content-Type: multipart/mixed; boundary="===============4321188051190523409==" MIME-Version: 1.0 From: Yuan Yijun To: docs at lists.fedoraproject.org Subject: About release-notes, what should translators commit to cvs? Date: Tue, 25 Oct 2005 09:23:20 +0800 Message-ID: <76e72f800510241823t6a591718r@mail.gmail.com> --===============4321188051190523409== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable 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 ^_^ --===============4321188051190523409==-- From kwade at redhat.com Thu Jun 4 22:08:19 2015 Content-Type: multipart/mixed; boundary="===============4493626238748157407==" MIME-Version: 1.0 From: Karsten Wade To: docs at lists.fedoraproject.org Subject: Re: About release-notes, what should translators commit to cvs? Date: Mon, 24 Oct 2005 19:48:02 -0700 Message-ID: <1130208482.12794.8.camel@erato.phig.org> In-Reply-To: 76e72f800510241823t6a591718r@mail.gmail.com --===============4493626238748157407== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable 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/ --===============4493626238748157407== Content-Type: application/pgp-signature MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="signature.asc" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4xIChHTlUv TGludXgpCgppRDhEQlFCRFhaemkyWklPQnEwT0RFRVJBcE5UQUtDWFNKZWRwYkp0dUlFeFpoZHBG OGJkaHpUUFhRQ2d1eTFNCkdrdzE1anJzYkV5N0FWT21MV3prazcwPQo9ZmI3ZQotLS0tLUVORCBQ R1AgU0lHTkFUVVJFLS0tLS0K --===============4493626238748157407==-- From kwade at redhat.com Thu Jun 4 22:08:19 2015 Content-Type: multipart/mixed; boundary="===============8479546446481205527==" MIME-Version: 1.0 From: Karsten Wade To: docs at lists.fedoraproject.org Subject: FC5 test1 relnotes for translation Date: Tue, 25 Oct 2005 02:16:07 -0700 Message-ID: <1130231767.12794.26.camel@erato.phig.org> --===============8479546446481205527== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable 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(a)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/ --===============8479546446481205527== Content-Type: application/pgp-signature MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="signature.asc" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4xIChHTlUv TGludXgpCgppRDhEQlFCRFhmZlcyWklPQnEwT0RFRVJBbUxYQUtDU3ByekdTNjU0N2g1ZzJmdW1a Wjk0ZmJEVmh3Q2VMcnVKCk1SRkNFVmJYYkNnZGVDaDl5QUVtRHU4PQo9OEpLWAotLS0tLUVORCBQ R1AgU0lHTkFUVVJFLS0tLS0K --===============8479546446481205527==-- From tsekine at sdri.co.jp Thu Jun 4 22:08:19 2015 Content-Type: multipart/mixed; boundary="===============2947012108650501271==" MIME-Version: 1.0 From: SEKINE Tatsuo To: docs at lists.fedoraproject.org Subject: Re: FC5 test1 relnotes for translation Date: Tue, 25 Oct 2005 19:36:03 +1000 Message-ID: <20051025.193603.111289002.tsekine@sdri.co.jp> In-Reply-To: 1130231767.12794.26.camel@erato.phig.org --===============2947012108650501271== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Hi, From: Karsten Wade Date: Tue, 25 Oct 2005 02:16:07 -0700 > echo $CVSROOT = > :ext:username(a)cvs.fedora.redhat.com:/cvs/docs > cvs co -r FC-5-TEST1-TRANS-FREEZE -d release-notes-FC5test1 release not= es It could be: cvs co -r FC-5-TEST1-TRANS-FREEZE -d release-notes-FC5test1 release-notes -- = SEKINE Tatsuo: tsekine(a)sdri.co.jp System Design & Research Inst. Co.,Ltd. --===============2947012108650501271==-- From nman64 at n-man.com Thu Jun 4 22:08:20 2015 Content-Type: multipart/mixed; boundary="===============3260866322455734448==" MIME-Version: 1.0 From: Patrick W. Barnes To: docs at lists.fedoraproject.org Subject: Re: FC5 test1 relnotes for translation Date: Tue, 25 Oct 2005 04:58:20 -0500 Message-ID: <435E01BC.7010409@n-man.com> In-Reply-To: 20051025.193603.111289002.tsekine@sdri.co.jp --===============3260866322455734448== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable SEKINE "tatz" Tatsuo wrote: > Hi, > > From: Karsten Wade > Date: Tue, 25 Oct 2005 02:16:07 -0700 > > = >> echo $CVSROOT = >> :ext:username(a)cvs.fedora.redhat.com:/cvs/docs >> cvs co -r FC-5-TEST1-TRANS-FREEZE -d release-notes-FC5test1 release no= tes >> = > > It could be: > cvs co -r FC-5-TEST1-TRANS-FREEZE -d release-notes-FC5test1 release-not= es > > = 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=3Dssh export CVSROOT=3D:ext:username(a)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(a)n-man.com www.n-man.com -- = --===============3260866322455734448== Content-Type: application/pgp-signature MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="signature.asc" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4yIChHTlUv TGludXgpCgppRDhEQlFGRFhnRy9kQm9CN0NtVUI5Z1JBakxYQUo5Sytja0EvOXFaSlBwRGFjaEdS ZFUwaWNqenRRQ2dtOU5uCnJNWEVFaVJ1YStEUi9EYmVpbC9SZVk4PQo9N1BYbQotLS0tLUVORCBQ R1AgU0lHTkFUVVJFLS0tLS0K --===============3260866322455734448==-- From dwmw2 at infradead.org Thu Jun 4 22:08:20 2015 Content-Type: multipart/mixed; boundary="===============8265917919313500935==" MIME-Version: 1.0 From: David Woodhouse To: docs at lists.fedoraproject.org Subject: Re: FC5 test1 relnotes for translation Date: Tue, 25 Oct 2005 11:06:57 +0100 Message-ID: <1130234817.6932.276.camel@baythorne.infradead.org> In-Reply-To: 435E01BC.7010409@n-man.com --===============8265917919313500935== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable 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 --===============8265917919313500935==-- From bbbush.yuan at gmail.com Thu Jun 4 22:08:20 2015 Content-Type: multipart/mixed; boundary="===============7926588568334602223==" MIME-Version: 1.0 From: Yuan Yijun To: docs at lists.fedoraproject.org Subject: RELEASE-NOTES-master-en.xml and README-en.xml Date: Tue, 25 Oct 2005 20:21:02 +0800 Message-ID: <76e72f800510250521g11e7b191r@mail.gmail.com> --===============7926588568334602223== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable 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 ^_^ --===============7926588568334602223==-- From Tommy.Reynolds at MegaCoder.com Thu Jun 4 22:08:20 2015 Content-Type: multipart/mixed; boundary="===============4763037793487144802==" MIME-Version: 1.0 From: Tommy Reynolds To: docs at lists.fedoraproject.org Subject: Re: FC5 test1 relnotes for translation Date: Tue, 25 Oct 2005 10:43:21 -0500 Message-ID: <20051025104321.23396eda.Tommy.Reynolds@MegaCoder.com> In-Reply-To: 1130231767.12794.26.camel@erato.phig.org --===============4763037793487144802== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Uttered Karsten Wade , spake thus: > Someone here can correct me, but I believe you do this: > echo $CVSROOT = > :ext:username(a)cvs.fedora.redhat.com:/cvs/docs > cvs co -r FC-5-TEST1-TRANS-FREEZE -d release-notes-FC5test1 release not= es You need not muck with $CVSROOT for a one-time checkout. Assuming that $CVS_RSH is set to: $ export CVS_RSH=3Dssh you can first do: $ cvs -d :ext:username(a)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": =3D=3DCUT=3D=3D=3DCUT=3D=3D=3DCUT=3D=3D=3DCUT=3D=3D=3DCUT=3D=3D=3DCUT=3D=3D= =3DCUT=3D=3D=3DCUT=3D=3D #!/bin/sh CVS_RSH=3Dssh export CVS_RSH exec cvs -d :ext:username(a)cvs.fedora.redhat.com:/cvs/docs $@ =3D=3DCUT=3D=3D=3DCUT=3D=3D=3DCUT=3D=3D=3DCUT=3D=3D=3DCUT=3D=3D=3DCUT=3D=3D= =3DCUT=3D=3D=3DCUT=3D=3D 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 --===============4763037793487144802== Content-Type: application/pgp-signature MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="attachment.sig" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4xIChHTlUv TGludXgpCgppRDhEQlFGRFhsS2QvMHlkcWtRRGxRRVJBaGF4QUtEVlkvbDVjdEs4MHJCYWtMZWdQ a2hXK2Q1d1hnQ2d6b3dPCnlYbElaaVlCNXJGc1dLNUp4bStzY2ZFPQo9SDQxRwotLS0tLUVORCBQ R1AgU0lHTkFUVVJFLS0tLS0K --===============4763037793487144802==-- From mumumu at mumumu.org Thu Jun 4 22:08:21 2015 Content-Type: multipart/mixed; boundary="===============5354520504995959046==" MIME-Version: 1.0 From: Yoshinari Takaoka To: docs at lists.fedoraproject.org Subject: FC5 test1 relnotes make problem(two xml file broken) Date: Wed, 26 Oct 2005 01:08:28 +0900 Message-ID: <200510260108.28890.mumumu@mumumu.org> --===============5354520504995959046== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable hi, all. i checked out fc5 test1 relnotes, and tried to make with the following step= s. ---- $ echo $CVSROOT :ext:username(a)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=3Dja.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?ann= otate=3D1.3&root=3Ddocs i fixed this and tried once more. but i got error again. ---- $ make LANG=3Dja.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: pars= er = error : Opening and ending tag mismatch: para line 1052 and emphasis ) ^ /home/mumumu/work/release-notes-FC5test1/package-movement-en.xml:1056: pars= er = error : Opening and ending tag mismatch: section line 1044 and para ^ /home/mumumu/work/release-notes-FC5test1/package-movement-en.xml:1065: pars= er = error : chunk is not well balanced
^ /home/mumumu/work/release-notes-FC5test1/package-movement-en.xml:1065: pars= er = 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=3D1.3&root=3Ddocs i fixed this and tried again. this time, "make" worked fine and i could get release-note-ja directory an= d = tar archive. Regards. -- = Yoshinari Takaoka(mumumu(a)IRC) reversethis -> {gro} {tod} {umumum} {ta} {umumum} --===============5354520504995959046==-- From Tommy.Reynolds at MegaCoder.com Thu Jun 4 22:08:21 2015 Content-Type: multipart/mixed; boundary="===============7276678097621867546==" MIME-Version: 1.0 From: Tommy Reynolds To: docs at lists.fedoraproject.org Subject: Re: XMLTO and SAXON Date: Tue, 25 Oct 2005 13:48:57 -0500 Message-ID: <20051025134857.95fbe673.Tommy.Reynolds@MegaCoder.com> In-Reply-To: 1130227071.4304.1.camel@cyberelk.elk --===============7276678097621867546== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable 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 --===============7276678097621867546== Content-Type: application/octet-stream MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="xmlto-saxon.patch" LS0tIHhtbHRvLTAuMC4xOC1vcmlnL3htbHRvLmluCTIwMDUtMTAtMjUgMTI6NTU6NTEuMDAwMDAw MDAwIC0wNTAwCisrKyB4bWx0by0wLjAuMTgveG1sdG8uaW4JMjAwNS0xMC0yNSAxMzo0MTo0Ni4w MDAwMDAwMDAgLTA1MDAKQEAgLTMxLDYgKzMxLDcgQEAgdXNhZ2UgKCkgewogICBjYXQgPDwgRU9G CiB1c2FnZTogQFBBQ0tBR0VAIFtPUFRJT05dLi4uIEZPUk1BVCBYTUwKIE9QVElPTnMgYXJlOgor ICAtWCB4c2x0ICAgICAgICAgWFNMVCBwcm9jZXNzb3IgdG8gdXNlICh4c2x0cHJvYyBvciBzYXhv bikKICAgLXYgICAgICAgICAgICAgIHZlcmJvc2Ugb3V0cHV0ICgtdnYgZm9yIHZlcnkgdmVyYm9z ZSkKICAgLXggc3R5bGVzaGVldCAgIHVzZSB0aGUgc3BlY2lmaWVkIHN0eWxlc2hlZXQgaW5zdGVh ZCBvZiBjaG9vc2luZyBvbmUKICAgLW0gZnJhZ21lbnQgICAgIHVzZSB0aGUgWFNMIGZyYWdtZW50 IHRvIGN1c3RvbWl6ZSB0aGUgc3R5bGVzaGVldApAQCAtNjAsNiArNjEsMTcgQEAgRU9GCiAgIGZp CiB9CiAKKyMgQSBjb3VwbGUgb2YgaGVscGVyIGZ1bmN0aW9ucyB0byBwcm92aWRlIGEgY29tbW9u IGludGVyZmFjZSB0byB0aGUgCisjIFhTTFQgcHJvY2Vzc29ycyB3ZSBrbm93LgorCit4c2x0Lnhz bHRwcm9jICgpCXsKKyAgICB4c2x0cHJvYyAtLXhpbmNsdWRlIC0tbm9uZXQgLW8gIiRYU0xUX1BS T0NFU1NFRCIgIiRTVFlMRVNIRUVUIiAiJElOUFVUX0ZJTEUiCit9CisKK3hzbHQuc2F4b24gKCkJ eworICAgIHNheG9uICAtbyAiJFhTTFRfUFJPQ0VTU0VEIiAiJElOUFVUX0ZJTEUiICIkU1RZTEVT SEVFVCIKK30KKwogIyBBbGxvdyBGT1JNQVRfRElSIGFuZCBYU0xfRElSIHRvIGJlIG92ZXItcmlk ZGVuLCBzbyB0aGF0IHdlIGNhbiBiZQogIyBydW4gZnJvbSB0aGUgYnVpbGQgZGlyZWN0b3J5Lgog cHJlZml4PUBwcmVmaXhACkBAIC02OCw2ICs4MCw5IEBAIHByZWZpeD1AcHJlZml4QAogIyBUaGlz IGNhbiBiZSBvdmVyLXJpZGRlbiwgYnV0IHJlYWxseSB3ZSBzaG91bGQgZGV0ZWN0IHRoZSBzb3Vy Y2UKICMgZG9jdW1lbnQgdHlwZSB3aXRob3V0IG5lZWRpbmcgYW55IGhlbHAuCiA6ICR7U09VUkNF X0ZPUk1BVD1kb2Nib29rfQorIyBTcGVjaWZ5IHRoZSBkZWZhdWx0IFhTTFQgcHJvY2Vzc29yCis6 ICR7WFNMVF9QUk9DRVNTT1I9eHNsdHByb2N9CitleHBvcnQgWFNMVF9QUk9DRVNTT1IKIAogIyBH ZXQgYWJzb2x1dGUgcGF0aG5hbWVzIGZvciBGT1JNQVRfRElSLCBYU0xfRElSLCBhbmQgT1VUUFVU X0RJUi4KIFdEPSIkKHB3ZCkiCkBAIC0xNDYsMTggKzE2MSwxMiBAQCBmaQogVkVSQk9TRT0wCiBl eHBvcnQgVkVSQk9TRQogCi0jIERpc2FibGUgbmV0d29yayBlbnRpdGllcwotWFNMVE9QVFM9IiRY U0xUT1BUUyAtLW5vbmV0IgotCi0jIEVuYWJsZSBYSW5jbHVkZQotWFNMVE9QVFM9IiRYU0xUT1BU UyAtLXhpbmNsdWRlIgotCiBTS0lQX1ZBTElEQVRJT049MAogCiAjIFByb2Nlc3MgYW55IG9wdGlv bnMKIEFSR1M9JCgke0dFVE9QVH0gXAogCS0tbG9uZ29wdGlvbnM9aGVscCx2ZXJzaW9uLGV4dGVu c2lvbnMsc2VhcmNocGF0aDosc2tpcC12YWxpZGF0aW9uIFwKLQktbiB4bWx0byAtLSB4Om06bzpw OnYgIiRAIikKKwktbiB4bWx0byAtLSBYOng6bTpvOnA6diAiJEAiKQogWyAkPyAhPSAwIF0gJiYg eyB1c2FnZTsgZXhpdCAxOyB9CiBldmFsIHNldCAtLSAiJEFSR1MiCiB3aGlsZSBbICIkIyIgLWd0 ICIwIiBdOyBkbwpAQCAtMTcwLDYgKzE3OSwxOCBAQCB3aGlsZSBbICIkIyIgLWd0ICIwIiBdOyBk bwogCXZlcnNpb24KIAlleGl0IDAKIAk7OworICAtWCkKKyAgCWNhc2UgIiQyIiBpbgorCXhzbHRw cm9jIHwgc2F4b24gKQorCQlYU0xUX1BST0NFU1NPUj0iJHsyfSIKKwkJOzsKKwkqICkKKwkJZWNo byAiVW5rbm93biBYU0xUIHByb2Nlc3NvciAoJDIpIG5vdCAneHNsdHByb2MnIG9yICdzYXhvbici CisJCWV4aXQgMQorCQk7OworCWVzYWMKKwlzaGlmdCAyCisgIAk7OwogICAteCkKIAljYXNlICIk MiIgaW4KIAkvKikgU1RZTEVTSEVFVD0iJDIiIDs7CkBAIC0yNzIsOSArMjkzLDkgQEAgdGhlbgog ICBleGl0IDEKIGZpCiAKK1sgIiRWRVJCT1NFIiAtZ2UgMSBdICYmIGVjaG8gPiYyICJYU0xUIHBy b2Nlc3NvcjogJHtYU0xUX1BST0NFU1NPUn0iCisKICMgQXNrIHRoZSBmb3JtYXQgc2NyaXB0IHdo YXQgc3R5bGVzaGVldCB0byB1c2UuCi1YU0xUX1BST0NFU1NPUj14c2x0cHJvYyAjIFdlIG9ubHkg a25vdyBhYm91dCB4c2x0cHJvYyByaWdodCBub3cuCi1leHBvcnQgWFNMVF9QUk9DRVNTT1IKIGV4 cG9ydCBYU0xfRElSCiBpZiBbIC16ICIkU1RZTEVTSEVFVCIgXQogdGhlbgpAQCAtMzU0LDEzICsz NzUsMTMgQEAgZWxzZQogICBmaQogCiAgIFsgIiRWRVJCT1NFIiAtZ2UgMSBdICYmIFwKLSAgIGVj aG8gLWUgPiYyICJ4c2x0cHJvYyR7WFNMVE9QVFN9ICR7WFNMVFNIT1dQQVRIfVxcXFxcbiAtbyAi JFhTTFRfUFJPQ0VTU0VEIiBcXFxcXG4gJFNUWUxFU0hFRVQgXFxcXFxuICRJTlBVVF9GSUxFIgor ICAgZWNobyAtZSA+JjIgInhzbHQuJHtYU0xUX1BST0NFU1NPUn0gJHtYU0xUT1BUU30gJHtYU0xU U0hPV1BBVEh9XFxcXFxuIC1vICIkWFNMVF9QUk9DRVNTRUQiIFxcXFxcbiAkU1RZTEVTSEVFVCBc XFxcXG4gJElOUFVUX0ZJTEUiCiAKICAgaWYgWyAteiAiJFhTTFRXSVRIUEFUSCIgXQogICB0aGVu Ci0gICAgeHNsdHByb2MgJFhTTFRPUFRTIC1vICIkWFNMVF9QUk9DRVNTRUQiICIkU1RZTEVTSEVF VCIgIiRJTlBVVF9GSUxFIgorICAgIHhzbHQuJHtYU0xUX1BST0NFU1NPUn0gICRYU0xUT1BUUyAt byAiJFhTTFRfUFJPQ0VTU0VEIiAiJFNUWUxFU0hFRVQiICIkSU5QVVRfRklMRSIKICAgZWxzZQot ICAgIHhzbHRwcm9jICRYU0xUT1BUUyAkWFNMVFdJVEhQQVRIICIkWFNMVFBBVEgiIC1vICIkWFNM VF9QUk9DRVNTRUQiIFwKKyAgICB4c2x0LiR7WFNMVF9QUk9DRVNTT1J9ICAkWFNMVE9QVFMgJFhT TFRXSVRIUEFUSCAiJFhTTFRQQVRIIiAtbyAiJFhTTFRfUFJPQ0VTU0VEIiBcCiAgICAgICAiJFNU WUxFU0hFRVQiICIkSU5QVVRfRklMRSIKICAgZmkKIApAQCAtMzY5LDcgKzM5MCw3IEBAIGVsc2UK ICAgICBYU0xUT1BUUz0iJHtYU0xUT1BUU30gLS1jYXRhbG9ncyIKICAgICBbICIkVkVSQk9TRSIg LWdlIDEgXSAmJiBcCiAgICAgICBlY2hvID4mMiAiTm8gWE1MIENhdGFsb2dzPyAgVHJ5aW5nIGFn YWluIHdpdGggLS1jYXRhbG9ncy4uIgotICAgIHhzbHRwcm9jICRYU0xUT1BUUyAtbyAiJFhTTFRf UFJPQ0VTU0VEIiAiJFNUWUxFU0hFRVQiICIkSU5QVVRfRklMRSIKKyAgICB4c2x0LiR7WFNMVF9Q Uk9DRVNTT1J9ICAkWFNMVE9QVFMgLW8gIiRYU0xUX1BST0NFU1NFRCIgIiRTVFlMRVNIRUVUIiAi JElOUFVUX0ZJTEUiCiAgIGZpCiAKICAgaWYgWyAkPyAtZ3QgMCBdCg== --===============7276678097621867546== Content-Type: application/octet-stream MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="xmlto-fop.patch" ZGlmZiAtdU5wIC1yIHhtbHRvLTAuMC4xOC1vcmlnL2Zvcm1hdC9kb2Nib29rL2F3dCB4bWx0by0w LjAuMTgvZm9ybWF0L2RvY2Jvb2svYXd0Ci0tLSB4bWx0by0wLjAuMTgtb3JpZy9mb3JtYXQvZG9j Ym9vay9hd3QJMTk2OS0xMi0zMSAxODowMDowMC4wMDAwMDAwMDAgLTA2MDAKKysrIHhtbHRvLTAu MC4xOC9mb3JtYXQvZG9jYm9vay9hd3QJMjAwNS0xMC0yNSAxMjo1NjozNi4wMDAwMDAwMDAgLTA1 MDAKQEAgLTAsMCArMSwxNyBAQAorY2FzZSAiJDEiIGluCitzdHlsZXNoZWV0KQorICBpZiBbICIk VkVSQk9TRSIgLWdlIDEgXQorICB0aGVuCisgICAgZWNobyA+JjIgIkNvbnZlcnQgdG8gWFNMLUZP IgorICBmaQorICBlY2hvICJodHRwOi8vZG9jYm9vay5zb3VyY2Vmb3JnZS5uZXQvcmVsZWFzZS94 c2wvY3VycmVudC9mby9kb2Nib29rLnhzbCIKKyAgOzsKK3Bvc3QtcHJvY2VzcykKKyAgRVhUPSQo YmFzZW5hbWUgJDApIAorICBpZiBbICIkVkVSQk9TRSIgLWdlIDEgXQorICB0aGVuCisgICAgZWNo byA+JjIgIkNvbnZlcnQgdG8gJHtFWFR9IgorICBmaQorICAjIEdldCB0aGUgRk8gZm9ybWF0IHNj cmlwdCB0byBkbyB0aGUgcmVzdAorICBzaCAiJChkaXJuYW1lICIkMCIpLy4uL2ZvLyR7RVhUfSIg IiQxIgorZXNhYwpkaWZmIC11TnAgLXIgeG1sdG8tMC4wLjE4LW9yaWcvZm9ybWF0L2RvY2Jvb2sv Zm8geG1sdG8tMC4wLjE4L2Zvcm1hdC9kb2Nib29rL2ZvCi0tLSB4bWx0by0wLjAuMTgtb3JpZy9m b3JtYXQvZG9jYm9vay9mbwkyMDA1LTEwLTI1IDEyOjU1OjUxLjAwMDAwMDAwMCAtMDUwMAorKysg eG1sdG8tMC4wLjE4L2Zvcm1hdC9kb2Nib29rL2ZvCTIwMDUtMTAtMjUgMTI6NTY6MzYuMDAwMDAw MDAwIC0wNTAwCkBAIC03LDYgKzcsNiBAQCBzdHlsZXNoZWV0KQogICBlY2hvICJodHRwOi8vZG9j Ym9vay5zb3VyY2Vmb3JnZS5uZXQvcmVsZWFzZS94c2wvY3VycmVudC9mby9kb2Nib29rLnhzbCIK ICAgOzsKIHBvc3QtcHJvY2VzcykKLSAgY3AgIiRYU0xUX1BST0NFU1NFRCIgIiRPVVRQVVRfRElS LyQoYmFzZW5hbWUgIiR7WFNMVF9QUk9DRVNTRUQlLip9IikuZm8iCisgIGNwICIkWFNMVF9QUk9D RVNTRUQiICIkT1VUUFVUX0RJUi8kKGJhc2VuYW1lICR7WFNMVF9QUk9DRVNTRUQlLip9KS5mbyIK ICAgOzsKIGVzYWMKZGlmZiAtdU5wIC1yIHhtbHRvLTAuMC4xOC1vcmlnL2Zvcm1hdC9kb2Nib29r L2h0bWwtbm9jaHVua3MgeG1sdG8tMC4wLjE4L2Zvcm1hdC9kb2Nib29rL2h0bWwtbm9jaHVua3MK LS0tIHhtbHRvLTAuMC4xOC1vcmlnL2Zvcm1hdC9kb2Nib29rL2h0bWwtbm9jaHVua3MJMjAwNS0x MC0yNSAxMjo1NTo1MS4wMDAwMDAwMDAgLTA1MDAKKysrIHhtbHRvLTAuMC4xOC9mb3JtYXQvZG9j Ym9vay9odG1sLW5vY2h1bmtzCTIwMDUtMTAtMjUgMTI6NTY6MzYuMDAwMDAwMDAwIC0wNTAwCkBA IC03LDYgKzcsNiBAQCBzdHlsZXNoZWV0KQogICBlY2hvICJodHRwOi8vZG9jYm9vay5zb3VyY2Vm b3JnZS5uZXQvcmVsZWFzZS94c2wvY3VycmVudC9odG1sL2RvY2Jvb2sueHNsIgogICA7OwogcG9z dC1wcm9jZXNzKQotICBjcCAiJFhTTFRfUFJPQ0VTU0VEIiAiJE9VVFBVVF9ESVIvJChiYXNlbmFt ZSAiJHtYU0xUX1BST0NFU1NFRCUuKn0iKS5odG1sIgorICBjcCAiJFhTTFRfUFJPQ0VTU0VEIiAi JE9VVFBVVF9ESVIvJChiYXNlbmFtZSAke1hTTFRfUFJPQ0VTU0VEJS4qfSkuaHRtbCIKICAgOzsK IGVzYWMKZGlmZiAtdU5wIC1yIHhtbHRvLTAuMC4xOC1vcmlnL2Zvcm1hdC9kb2Nib29rL21pZiB4 bWx0by0wLjAuMTgvZm9ybWF0L2RvY2Jvb2svbWlmCi0tLSB4bWx0by0wLjAuMTgtb3JpZy9mb3Jt YXQvZG9jYm9vay9taWYJMTk2OS0xMi0zMSAxODowMDowMC4wMDAwMDAwMDAgLTA2MDAKKysrIHht bHRvLTAuMC4xOC9mb3JtYXQvZG9jYm9vay9taWYJMjAwNS0xMC0yNSAxMjo1NjozNi4wMDAwMDAw MDAgLTA1MDAKQEAgLTAsMCArMSwxNyBAQAorY2FzZSAiJDEiIGluCitzdHlsZXNoZWV0KQorICBp ZiBbICIkVkVSQk9TRSIgLWdlIDEgXQorICB0aGVuCisgICAgZWNobyA+JjIgIkNvbnZlcnQgdG8g WFNMLUZPIgorICBmaQorICBlY2hvICJodHRwOi8vZG9jYm9vay5zb3VyY2Vmb3JnZS5uZXQvcmVs ZWFzZS94c2wvY3VycmVudC9mby9kb2Nib29rLnhzbCIKKyAgOzsKK3Bvc3QtcHJvY2VzcykKKyAg RVhUPSQoYmFzZW5hbWUgJDApIAorICBpZiBbICIkVkVSQk9TRSIgLWdlIDEgXQorICB0aGVuCisg ICAgZWNobyA+JjIgIkNvbnZlcnQgdG8gJHtFWFR9IgorICBmaQorICAjIEdldCB0aGUgRk8gZm9y bWF0IHNjcmlwdCB0byBkbyB0aGUgcmVzdAorICBzaCAiJChkaXJuYW1lICIkMCIpLy4uL2ZvLyR7 RVhUfSIgIiQxIgorZXNhYwpkaWZmIC11TnAgLXIgeG1sdG8tMC4wLjE4LW9yaWcvZm9ybWF0L2Rv Y2Jvb2svcGNsIHhtbHRvLTAuMC4xOC9mb3JtYXQvZG9jYm9vay9wY2wKLS0tIHhtbHRvLTAuMC4x OC1vcmlnL2Zvcm1hdC9kb2Nib29rL3BjbAkxOTY5LTEyLTMxIDE4OjAwOjAwLjAwMDAwMDAwMCAt MDYwMAorKysgeG1sdG8tMC4wLjE4L2Zvcm1hdC9kb2Nib29rL3BjbAkyMDA1LTEwLTI1IDEyOjU2 OjM2LjAwMDAwMDAwMCAtMDUwMApAQCAtMCwwICsxLDE3IEBACitjYXNlICIkMSIgaW4KK3N0eWxl c2hlZXQpCisgIGlmIFsgIiRWRVJCT1NFIiAtZ2UgMSBdCisgIHRoZW4KKyAgICBlY2hvID4mMiAi Q29udmVydCB0byBYU0wtRk8iCisgIGZpCisgIGVjaG8gImh0dHA6Ly9kb2Nib29rLnNvdXJjZWZv cmdlLm5ldC9yZWxlYXNlL3hzbC9jdXJyZW50L2ZvL2RvY2Jvb2sueHNsIgorICA7OworcG9zdC1w cm9jZXNzKQorICBFWFQ9JChiYXNlbmFtZSAkMCkgCisgIGlmIFsgIiRWRVJCT1NFIiAtZ2UgMSBd CisgIHRoZW4KKyAgICBlY2hvID4mMiAiQ29udmVydCB0byAke0VYVH0iCisgIGZpCisgICMgR2V0 IHRoZSBGTyBmb3JtYXQgc2NyaXB0IHRvIGRvIHRoZSByZXN0CisgIHNoICIkKGRpcm5hbWUgIiQw IikvLi4vZm8vJHtFWFR9IiAiJDEiCitlc2FjCmRpZmYgLXVOcCAtciB4bWx0by0wLjAuMTgtb3Jp Zy9mb3JtYXQvZG9jYm9vay9wZGYgeG1sdG8tMC4wLjE4L2Zvcm1hdC9kb2Nib29rL3BkZgotLS0g eG1sdG8tMC4wLjE4LW9yaWcvZm9ybWF0L2RvY2Jvb2svcGRmCTIwMDUtMTAtMjUgMTI6NTU6NTEu MDAwMDAwMDAwIC0wNTAwCisrKyB4bWx0by0wLjAuMTgvZm9ybWF0L2RvY2Jvb2svcGRmCTIwMDUt MTAtMjUgMTI6NTY6MzYuMDAwMDAwMDAwIC0wNTAwCkBAIC03LDcgKzcsMTEgQEAgc3R5bGVzaGVl dCkKICAgZWNobyAiaHR0cDovL2RvY2Jvb2suc291cmNlZm9yZ2UubmV0L3JlbGVhc2UveHNsL2N1 cnJlbnQvZm8vZG9jYm9vay54c2wiCiAgIDs7CiBwb3N0LXByb2Nlc3MpCisgIEVYVD0kKGJhc2Vu YW1lICQwKSAKKyAgaWYgWyAiJFZFUkJPU0UiIC1nZSAxIF0KKyAgdGhlbgorICAgIGVjaG8gPiYy ICJDb252ZXJ0IHRvICR7RVhUfSIKKyAgZmkKICAgIyBHZXQgdGhlIEZPIGZvcm1hdCBzY3JpcHQg dG8gZG8gdGhlIHJlc3QKLSAgc2ggIiQoZGlybmFtZSAiJDAiKS8uLi9mby8kKGJhc2VuYW1lICIk MCIpIiAiJDEiCi0gIDs7CisgIHNoICIkKGRpcm5hbWUgIiQwIikvLi4vZm8vJHtFWFR9IiAiJDEi CiBlc2FjCmRpZmYgLXVOcCAtciB4bWx0by0wLjAuMTgtb3JpZy9mb3JtYXQvZG9jYm9vay9wcyB4 bWx0by0wLjAuMTgvZm9ybWF0L2RvY2Jvb2svcHMKLS0tIHhtbHRvLTAuMC4xOC1vcmlnL2Zvcm1h dC9kb2Nib29rL3BzCTIwMDUtMTAtMjUgMTI6NTU6NTEuMDAwMDAwMDAwIC0wNTAwCisrKyB4bWx0 by0wLjAuMTgvZm9ybWF0L2RvY2Jvb2svcHMJMjAwNS0xMC0yNSAxMjo1NjozNi4wMDAwMDAwMDAg LTA1MDAKQEAgLTcsNyArNywxMSBAQCBzdHlsZXNoZWV0KQogICBlY2hvICJodHRwOi8vZG9jYm9v ay5zb3VyY2Vmb3JnZS5uZXQvcmVsZWFzZS94c2wvY3VycmVudC9mby9kb2Nib29rLnhzbCIKICAg OzsKIHBvc3QtcHJvY2VzcykKKyAgRVhUPSQoYmFzZW5hbWUgJDApIAorICBpZiBbICIkVkVSQk9T RSIgLWdlIDEgXQorICB0aGVuCisgICAgZWNobyA+JjIgIkNvbnZlcnQgdG8gJHtFWFR9IgorICBm aQogICAjIEdldCB0aGUgRk8gZm9ybWF0IHNjcmlwdCB0byBkbyB0aGUgcmVzdAotICBzaCAiJChk aXJuYW1lICIkMCIpLy4uL2ZvLyQoYmFzZW5hbWUgIiQwIikiICIkMSIKLSAgOzsKKyAgc2ggIiQo ZGlybmFtZSAiJDAiKS8uLi9mby8ke0VYVH0iICIkMSIKIGVzYWMKZGlmZiAtdU5wIC1yIHhtbHRv LTAuMC4xOC1vcmlnL2Zvcm1hdC9kb2Nib29rL3N2ZyB4bWx0by0wLjAuMTgvZm9ybWF0L2RvY2Jv b2svc3ZnCi0tLSB4bWx0by0wLjAuMTgtb3JpZy9mb3JtYXQvZG9jYm9vay9zdmcJMTk2OS0xMi0z MSAxODowMDowMC4wMDAwMDAwMDAgLTA2MDAKKysrIHhtbHRvLTAuMC4xOC9mb3JtYXQvZG9jYm9v ay9zdmcJMjAwNS0xMC0yNSAxMjo1NjozNi4wMDAwMDAwMDAgLTA1MDAKQEAgLTAsMCArMSwxNyBA QAorY2FzZSAiJDEiIGluCitzdHlsZXNoZWV0KQorICBpZiBbICIkVkVSQk9TRSIgLWdlIDEgXQor ICB0aGVuCisgICAgZWNobyA+JjIgIkNvbnZlcnQgdG8gWFNMLUZPIgorICBmaQorICBlY2hvICJo dHRwOi8vZG9jYm9vay5zb3VyY2Vmb3JnZS5uZXQvcmVsZWFzZS94c2wvY3VycmVudC9mby9kb2Ni b29rLnhzbCIKKyAgOzsKK3Bvc3QtcHJvY2VzcykKKyAgRVhUPSQoYmFzZW5hbWUgJDApIAorICBp ZiBbICIkVkVSQk9TRSIgLWdlIDEgXQorICB0aGVuCisgICAgZWNobyA+JjIgIkNvbnZlcnQgdG8g JHtFWFR9IgorICBmaQorICAjIEdldCB0aGUgRk8gZm9ybWF0IHNjcmlwdCB0byBkbyB0aGUgcmVz dAorICBzaCAiJChkaXJuYW1lICIkMCIpLy4uL2ZvLyR7RVhUfSIgIiQxIgorZXNhYwpkaWZmIC11 TnAgLXIgeG1sdG8tMC4wLjE4LW9yaWcvZm9ybWF0L2RvY2Jvb2svdHh0IHhtbHRvLTAuMC4xOC9m b3JtYXQvZG9jYm9vay90eHQKLS0tIHhtbHRvLTAuMC4xOC1vcmlnL2Zvcm1hdC9kb2Nib29rL3R4 dAkyMDA1LTEwLTI1IDEyOjU1OjUxLjAwMDAwMDAwMCAtMDUwMAorKysgeG1sdG8tMC4wLjE4L2Zv cm1hdC9kb2Nib29rL3R4dAkyMDA1LTEwLTI1IDEyOjU2OjM2LjAwMDAwMDAwMCAtMDUwMApAQCAt MSwzNCArMSwxNyBAQAotaWYgWyAteCAvdXNyL2Jpbi93M20gXQotdGhlbgotICBDT05WRVJUPS91 c3IvYmluL3czbQotICBBUkdTPSItVCB0ZXh0L2h0bWwgLWR1bXAiCi1lbGlmIFsgLXggL3Vzci9i aW4vbHlueCBdCi10aGVuCi0gIENPTlZFUlQ9L3Vzci9iaW4vbHlueAotICBBUkdTPSItZm9yY2Vf aHRtbCAtZHVtcCAtbm9saXN0IC13aWR0aD03MiIKLWVsaWYgWyAteCAvdXNyL2Jpbi9saW5rcyBd Ci10aGVuCi0gIENPTlZFUlQ9L3Vzci9iaW4vbGlua3MKLSAgQVJHUz0iLWR1bXAiCi1lbHNlCi0g IGVjaG8gPiYyICJObyB3YXkgdG8gY29udmVydCBIVE1MIHRvIHRleHQgZm91bmQuIgotICBleGl0 IDEKLWZpCi0KIGNhc2UgIiQxIiBpbgogc3R5bGVzaGVldCkKICAgaWYgWyAiJFZFUkJPU0UiIC1n ZSAxIF0KICAgdGhlbgotICAgIGVjaG8gPiYyICJDb252ZXJ0IHRvIEhUTUwgKG5vIGNodW5rcyki CisgICAgZWNobyA+JjIgIkNvbnZlcnQgdG8gWFNMLUZPIgogICBmaQotICBlY2hvICJodHRwOi8v ZG9jYm9vay5zb3VyY2Vmb3JnZS5uZXQvcmVsZWFzZS94c2wvY3VycmVudC9odG1sL2RvY2Jvb2su eHNsIgorICBlY2hvICJodHRwOi8vZG9jYm9vay5zb3VyY2Vmb3JnZS5uZXQvcmVsZWFzZS94c2wv Y3VycmVudC9mby9kb2Nib29rLnhzbCIKICAgOzsKIHBvc3QtcHJvY2VzcykKKyAgRVhUPSQoYmFz ZW5hbWUgJDApIAogICBpZiBbICIkVkVSQk9TRSIgLWdlIDEgXQogICB0aGVuCi0gICAgZWNobyA+ JjIgIkNvbnZlcnQgSFRNTCB0byBBU0NJSSIKKyAgICBlY2hvID4mMiAiQ29udmVydCB0byAke0VY VH0iCiAgIGZpCi0gICR7Q09OVkVSVH0gJHtBUkdTfSAke1BPU1RBUkdTfSAke1hTTFRfUFJPQ0VT U0VEfSA+IFwKLSAgICIkT1VUUFVUX0RJUi8kKGJhc2VuYW1lICIke1hTTFRfUFJPQ0VTU0VEJS4q fSIpLnR4dCIKLSAgOzsKKyAgIyBHZXQgdGhlIEZPIGZvcm1hdCBzY3JpcHQgdG8gZG8gdGhlIHJl c3QKKyAgc2ggIiQoZGlybmFtZSAiJDAiKS8uLi9mby8ke0VYVH0iICIkMSIKIGVzYWMKZGlmZiAt dU5wIC1yIHhtbHRvLTAuMC4xOC1vcmlnL2Zvcm1hdC9mby9hd3QgeG1sdG8tMC4wLjE4L2Zvcm1h dC9mby9hd3QKLS0tIHhtbHRvLTAuMC4xOC1vcmlnL2Zvcm1hdC9mby9hd3QJMTk2OS0xMi0zMSAx ODowMDowMC4wMDAwMDAwMDAgLTA2MDAKKysrIHhtbHRvLTAuMC4xOC9mb3JtYXQvZm8vYXd0CTIw MDUtMTAtMjUgMTI6NTY6MzYuMDAwMDAwMDAwIC0wNTAwCkBAIC0wLDAgKzEsMTEgQEAKK0VYVD0k KGJhc2VuYW1lICQwKSAKK2Nhc2UgIiQxIiBpbgorc3R5bGVzaGVldCkKKyAgOzsKK3Bvc3QtcHJv Y2VzcykKKyAgaWYgWyAiJFZFUkJPU0UiIC1nZSAxIF0KKyAgdGhlbgorICAgIGVjaG8gPiYyICJS ZW5kZXJpbmcgWFNMLUZPIHRvIHNjcmVlbiIKKyAgZmkKKyAgZm9wICR7UE9TVEFSR1N9IC1mbyAi JHtYU0xUX1BST0NFU1NFRH0iIC0iJHtFWFR9IgorZXNhYwpkaWZmIC11TnAgLXIgeG1sdG8tMC4w LjE4LW9yaWcvZm9ybWF0L2ZvL2R2aSB4bWx0by0wLjAuMTgvZm9ybWF0L2ZvL2R2aQotLS0geG1s dG8tMC4wLjE4LW9yaWcvZm9ybWF0L2ZvL2R2aQkyMDA1LTEwLTI1IDEyOjU1OjUxLjAwMDAwMDAw MCAtMDUwMAorKysgeG1sdG8tMC4wLjE4L2Zvcm1hdC9mby9kdmkJMjAwNS0xMC0yNSAxMjo1Njoz Ni4wMDAwMDAwMDAgLTA1MDAKQEAgLTI5LDYgKzI5LDYgQEAgcG9zdC1wcm9jZXNzKQogICAgICAg WyAiJFZFUkJPU0UiIC1nZSAzIF0gJiYgY2F0ICRPVVQKICAgICBmaQogICBmaQotICBjcCAtLSAq LmR2aSAiJE9VVFBVVF9ESVIvJChiYXNlbmFtZSAiJHtYU0xUX1BST0NFU1NFRCUuKn0iKS5kdmki CisgIGNwIC0tICouZHZpICIkT1VUUFVUX0RJUi8kKGJhc2VuYW1lICR7WFNMVF9QUk9DRVNTRUQl Lip9KS5kdmkiCiAgIDs7CiBlc2FjCmRpZmYgLXVOcCAtciB4bWx0by0wLjAuMTgtb3JpZy9mb3Jt YXQvZm8vbWlmIHhtbHRvLTAuMC4xOC9mb3JtYXQvZm8vbWlmCi0tLSB4bWx0by0wLjAuMTgtb3Jp Zy9mb3JtYXQvZm8vbWlmCTE5NjktMTItMzEgMTg6MDA6MDAuMDAwMDAwMDAwIC0wNjAwCisrKyB4 bWx0by0wLjAuMTgvZm9ybWF0L2ZvL21pZgkyMDA1LTEwLTI1IDEyOjU2OjM2LjAwMDAwMDAwMCAt MDUwMApAQCAtMCwwICsxLDExIEBACitFWFQ9JChiYXNlbmFtZSAkMCkgCitjYXNlICIkMSIgaW4K K3N0eWxlc2hlZXQpCisgIDs7Citwb3N0LXByb2Nlc3MpCisgIGlmIFsgIiRWRVJCT1NFIiAtZ2Ug MSBdCisgIHRoZW4KKyAgICBlY2hvID4mMiAiUG9zdC1wcm9jZXNzIFhTTC1GTyB0byBQREYiCisg IGZpCisgIGZvcCAke1BPU1RBUkdTfSAtZm8gIiR7WFNMVF9QUk9DRVNTRUR9IiAtIiR7RVhUfSIg IiRPVVRQVVRfRElSLyQoYmFzZW5hbWUgJHtYU0xUX1BST0NFU1NFRCUuKn0pLiR7RVhUfSIKK2Vz YWMKZGlmZiAtdU5wIC1yIHhtbHRvLTAuMC4xOC1vcmlnL2Zvcm1hdC9mby9wY2wgeG1sdG8tMC4w LjE4L2Zvcm1hdC9mby9wY2wKLS0tIHhtbHRvLTAuMC4xOC1vcmlnL2Zvcm1hdC9mby9wY2wJMTk2 OS0xMi0zMSAxODowMDowMC4wMDAwMDAwMDAgLTA2MDAKKysrIHhtbHRvLTAuMC4xOC9mb3JtYXQv Zm8vcGNsCTIwMDUtMTAtMjUgMTI6NTY6MzYuMDAwMDAwMDAwIC0wNTAwCkBAIC0wLDAgKzEsMTEg QEAKK0VYVD0kKGJhc2VuYW1lICQwKSAKK2Nhc2UgIiQxIiBpbgorc3R5bGVzaGVldCkKKyAgOzsK K3Bvc3QtcHJvY2VzcykKKyAgaWYgWyAiJFZFUkJPU0UiIC1nZSAxIF0KKyAgdGhlbgorICAgIGVj aG8gPiYyICJQb3N0LXByb2Nlc3MgWFNMLUZPIHRvIFBERiIKKyAgZmkKKyAgZm9wICR7UE9TVEFS R1N9IC1mbyAiJHtYU0xUX1BST0NFU1NFRH0iIC0iJHtFWFR9IiAiJE9VVFBVVF9ESVIvJChiYXNl bmFtZSAke1hTTFRfUFJPQ0VTU0VEJS4qfSkuJHtFWFR9IgorZXNhYwpkaWZmIC11TnAgLXIgeG1s dG8tMC4wLjE4LW9yaWcvZm9ybWF0L2ZvL3BkZiB4bWx0by0wLjAuMTgvZm9ybWF0L2ZvL3BkZgot LS0geG1sdG8tMC4wLjE4LW9yaWcvZm9ybWF0L2ZvL3BkZgkyMDA1LTEwLTI1IDEyOjU1OjUxLjAw MDAwMDAwMCAtMDUwMAorKysgeG1sdG8tMC4wLjE4L2Zvcm1hdC9mby9wZGYJMjAwNS0xMC0yNSAx Mjo1NjozNi4wMDAwMDAwMDAgLTA1MDAKQEAgLTEsMyArMSw0IEBACitFWFQ9JChiYXNlbmFtZSAk MCkgCiBjYXNlICIkMSIgaW4KIHN0eWxlc2hlZXQpCiAgIDs7CkBAIC02LDI5ICs3LDUgQEAgcG9z dC1wcm9jZXNzKQogICB0aGVuCiAgICAgZWNobyA+JjIgIlBvc3QtcHJvY2VzcyBYU0wtRk8gdG8g UERGIgogICBmaQotICAjIFdvcmsgYXJvdW5kIHN0dXBpZCB0ZXRleCBidWcgd2l0aCAnXycgaW4g ZmlsZW5hbWVzCi0gICMgQWxzbyB3b3JrIGFyb3VuZCBzdHVwaWQgdGV0ZXggbGltaXRhdGlvbiB3 aXRoIGxvbmcgbGluZXMgKGJ1ZyAjMTAxMDU1KQotICBzZWQgLWUgInMsLz4sXG4vPixnIiAiJFhT TFRfUFJPQ0VTU0VEIiA+dG1wLmZvCi0gIE9VVD1vdXRwdXQKLSAgVEVYSU5QVVRTPSIkKGRpcm5h bWUgIiRJTlBVVF9GSUxFIik6OiRTRUFSQ0hQQVRIIgotICBleHBvcnQgVEVYSU5QVVRTCi0gIHBk ZnhtbHRleCAke1BPU1RBUkdTfSB0bXAuZm8gPiRPVVQgPC9kZXYvbnVsbCB8fCB7IGNhdCAkT1VU OyBleGl0IDE7IH0KLSAgWyAiJFZFUkJPU0UiIC1nZSAyIF0gJiYgZWNobyA+JjIgIkZpcnN0IHBh c3MgY29tcGxldGUiCi0gICMgSWYgdGhlcmUgd2VyZSB1bmRlZmluZWQgcmVmZXJlbmNlcyB3ZSBu ZWVkIHRvIHJlLXJ1biBwZGZ4bWx0ZXguCi0gIGlmIGVncmVwICdeTGFUZVggV2FybmluZzogVGhl cmUgd2VyZSB1bmRlZmluZWQgcmVmZXJlbmNlcy4kJyAkT1VUIFwKLQkJCQkJCT4vZGV2L251bGwg Mj4mMSBcCi0gIHx8IGVncmVwICdeTGFUZVggV2FybmluZzogTGFiZWwucy4gbWF5IGhhdmUgY2hh bmdlZFwuJyAkT1VUIFwKLQkJCQkJCT4vZGV2L251bGwgMj4mMQotICB0aGVuCi0gICAgcGRmeG1s dGV4ICR7UE9TVEFSR1N9IHRtcC5mbyA+JE9VVCA8L2Rldi9udWxsCi0gICAgWyAiJFZFUkJPU0Ui IC1nZSAyIF0gJiYgZWNobyA+JjIgIlNlY29uZCBwYXNzIGNvbXBsZXRlIgotICAgIHBkZnhtbHRl eCAke1BPU1RBUkdTfSB0bXAuZm8gPiRPVVQgPC9kZXYvbnVsbAotICAgIGlmIFsgIiRWRVJCT1NF IiAtZ2UgMiBdCi0gICAgdGhlbgotICAgICAgZWNobyA+JjIgIlRoaXJkIHBhc3MgY29tcGxldGUi Ci0gICAgICBbICIkVkVSQk9TRSIgLWdlIDMgXSAmJiBjYXQgJE9VVAotICAgIGZpCi0gIGZpCi0g IGNwIC0tICoucGRmICIkT1VUUFVUX0RJUi8kKGJhc2VuYW1lICIke1hTTFRfUFJPQ0VTU0VEJS4q fSIpLnBkZiIKLSAgOzsKKyAgZm9wICR7UE9TVEFSR1N9IC1mbyAiJHtYU0xUX1BST0NFU1NFRH0i IC0iJHtFWFR9IiAiJE9VVFBVVF9ESVIvJChiYXNlbmFtZSAke1hTTFRfUFJPQ0VTU0VEJS4qfSku JHtFWFR9IgogZXNhYwpkaWZmIC11TnAgLXIgeG1sdG8tMC4wLjE4LW9yaWcvZm9ybWF0L2ZvL3Bz IHhtbHRvLTAuMC4xOC9mb3JtYXQvZm8vcHMKLS0tIHhtbHRvLTAuMC4xOC1vcmlnL2Zvcm1hdC9m by9wcwkyMDA1LTEwLTI1IDEyOjU1OjUxLjAwMDAwMDAwMCAtMDUwMAorKysgeG1sdG8tMC4wLjE4 L2Zvcm1hdC9mby9wcwkyMDA1LTEwLTI1IDEyOjU2OjM2LjAwMDAwMDAwMCAtMDUwMApAQCAtMSwz OCArMSwxMSBAQAorRVhUPSQoYmFzZW5hbWUgJDApIAogY2FzZSAiJDEiIGluCiBzdHlsZXNoZWV0 KQogICA7OwogcG9zdC1wcm9jZXNzKQogICBpZiBbICIkVkVSQk9TRSIgLWdlIDEgXQogICB0aGVu Ci0gICAgZWNobyA+JjIgIlBvc3QtcHJvY2VzcyBYU0wtRk8gdG8gRFZJIgorICAgIGVjaG8gPiYy ICJQb3N0LXByb2Nlc3MgWFNMLUZPIHRvIFBERiIKICAgZmkKLSAgIyBXb3JrIGFyb3VuZCBzdHVw aWQgdGV0ZXggYnVnIHdpdGggJ18nIGluIGZpbGVuYW1lcwotICAjIEFsc28gd29yayBhcm91bmQg c3R1cGlkIHRldGV4IGxpbWl0YXRpb24gd2l0aCBsb25nIGxpbmVzIChidWcgIzEwMTA1NSkKLSAg c2VkIC1lICJzLC8+LFxuLz4sZyIgIiRYU0xUX1BST0NFU1NFRCIgPnRtcC5mbwotICBPVVQ9b3V0 cHV0Ci0gIFRFWElOUFVUUz0iJChkaXJuYW1lICIkSU5QVVRfRklMRSIpOjokU0VBUkNIUEFUSCIK LSAgZXhwb3J0IFRFWElOUFVUUwotICB4bWx0ZXggJHtQT1NUQVJHU30gdG1wLmZvID4kT1VUIDwv ZGV2L251bGwgfHwgeyBjYXQgJE9VVDsgZXhpdCAxOyB9Ci0gIFsgIiRWRVJCT1NFIiAtZ2UgMiBd ICYmIGVjaG8gPiYyICJGaXJzdCBwYXNzIGNvbXBsZXRlIgotICAjIElmIHRoZXJlIHdlcmUgdW5k ZWZpbmVkIHJlZmVyZW5jZXMgd2UgbmVlZCB0byByZS1ydW4geG1sdGV4LgotICBpZiBlZ3JlcCAn XkxhVGVYIFdhcm5pbmc6IFRoZXJlIHdlcmUgdW5kZWZpbmVkIHJlZmVyZW5jZXMuJCcgJE9VVCBc Ci0JCQkJCQk+L2Rldi9udWxsIDI+JjEgXAotICB8fCBlZ3JlcCAnXkxhVGVYIFdhcm5pbmc6IExh YmVsLnMuIG1heSBoYXZlIGNoYW5nZWRcLicgJE9VVCBcCi0JCQkJCQk+L2Rldi9udWxsIDI+JjEK LSAgdGhlbgotICAgIHhtbHRleCAke1BPU1RBUkdTfSB0bXAuZm8gPiRPVVQgPC9kZXYvbnVsbAot ICAgIFsgIiRWRVJCT1NFIiAtZ2UgMiBdICYmIGVjaG8gPiYyICJTZWNvbmQgcGFzcyBjb21wbGV0 ZSIKLSAgICB4bWx0ZXggJHtQT1NUQVJHU30gdG1wLmZvID4kT1VUIDwvZGV2L251bGwKLSAgICBp ZiBbICIkVkVSQk9TRSIgLWdlIDIgXQotICAgIHRoZW4KLSAgICAgIGVjaG8gPiYyICJUaGlyZCBw YXNzIGNvbXBsZXRlIgotICAgICAgWyAiJFZFUkJPU0UiIC1nZSAzIF0gJiYgY2F0ICRPVVQKLSAg ICBmaQotICBmaQotICBpZiBbICIkVkVSQk9TRSIgLWdlIDEgXQotICB0aGVuCi0gICAgZWNobyA+ JjIgIlBvc3QtcHJvY2VzcyBEVkkgdG8gUFMiCi0gIGZpCi0gIGR2aXBzIC1SIC1xICR7UE9TVFBP U1RBUkdTfSAtbyAiJE9VVFBVVF9ESVIvJChiYXNlbmFtZSAiJHtYU0xUX1BST0NFU1NFRCUuKn0i KS5wcyIgKi5kdmkKLSAgOzsKKyAgZm9wICR7UE9TVEFSR1N9IC1mbyAiJHtYU0xUX1BST0NFU1NF RH0iIC0iJHtFWFR9IiAiJE9VVFBVVF9ESVIvJChiYXNlbmFtZSAke1hTTFRfUFJPQ0VTU0VEJS4q fSkuJHtFWFR9IgogZXNhYwpkaWZmIC11TnAgLXIgeG1sdG8tMC4wLjE4LW9yaWcvZm9ybWF0L2Zv L3N2ZyB4bWx0by0wLjAuMTgvZm9ybWF0L2ZvL3N2ZwotLS0geG1sdG8tMC4wLjE4LW9yaWcvZm9y bWF0L2ZvL3N2ZwkxOTY5LTEyLTMxIDE4OjAwOjAwLjAwMDAwMDAwMCAtMDYwMAorKysgeG1sdG8t MC4wLjE4L2Zvcm1hdC9mby9zdmcJMjAwNS0xMC0yNSAxMjo1NjozNi4wMDAwMDAwMDAgLTA1MDAK QEAgLTAsMCArMSwxMSBAQAorRVhUPSQoYmFzZW5hbWUgJDApIAorY2FzZSAiJDEiIGluCitzdHls ZXNoZWV0KQorICA7OworcG9zdC1wcm9jZXNzKQorICBpZiBbICIkVkVSQk9TRSIgLWdlIDEgXQor ICB0aGVuCisgICAgZWNobyA+JjIgIlBvc3QtcHJvY2VzcyBYU0wtRk8gdG8gUERGIgorICBmaQor ICBmb3AgJHtQT1NUQVJHU30gLWZvICIke1hTTFRfUFJPQ0VTU0VEfSIgLSIke0VYVH0iICIkT1VU UFVUX0RJUi8kKGJhc2VuYW1lICR7WFNMVF9QUk9DRVNTRUQlLip9KS4ke0VYVH0iCitlc2FjCmRp ZmYgLXVOcCAtciB4bWx0by0wLjAuMTgtb3JpZy9mb3JtYXQvZm8vdHh0IHhtbHRvLTAuMC4xOC9m b3JtYXQvZm8vdHh0Ci0tLSB4bWx0by0wLjAuMTgtb3JpZy9mb3JtYXQvZm8vdHh0CTE5NjktMTIt MzEgMTg6MDA6MDAuMDAwMDAwMDAwIC0wNjAwCisrKyB4bWx0by0wLjAuMTgvZm9ybWF0L2ZvL3R4 dAkyMDA1LTEwLTI1IDEyOjU2OjM2LjAwMDAwMDAwMCAtMDUwMApAQCAtMCwwICsxLDExIEBACitF WFQ9JChiYXNlbmFtZSAkMCkgCitjYXNlICIkMSIgaW4KK3N0eWxlc2hlZXQpCisgIDs7Citwb3N0 LXByb2Nlc3MpCisgIGlmIFsgIiRWRVJCT1NFIiAtZ2UgMSBdCisgIHRoZW4KKyAgICBlY2hvID4m MiAiUG9zdC1wcm9jZXNzIFhTTC1GTyB0byBQREYiCisgIGZpCisgIGZvcCAke1BPU1RBUkdTfSAt Zm8gIiR7WFNMVF9QUk9DRVNTRUR9IiAtIiR7RVhUfSIgIiRPVVRQVVRfRElSLyQoYmFzZW5hbWUg JHtYU0xUX1BST0NFU1NFRCUuKn0pLiR7RVhUfSIKK2VzYWMK --===============7276678097621867546== Content-Type: application/pgp-signature MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="attachment.sig" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4xIChHTlUv TGludXgpCgppRDhEQlFGRFhuNGQvMHlkcWtRRGxRRVJBcWdTQUo0a1U2bkJaNzZiMXJLMDFMYU8z ODFBbFE3Z0VRQ2NDVUZhCkUxdHFVaWExN082eDhtNktzOVBkUkY4PQo9bHRySAotLS0tLUVORCBQ R1AgU0lHTkFUVVJFLS0tLS0K --===============7276678097621867546==-- From kwade at redhat.com Thu Jun 4 22:08:21 2015 Content-Type: multipart/mixed; boundary="===============6709855057140982471==" MIME-Version: 1.0 From: Karsten Wade To: docs at lists.fedoraproject.org Subject: Re: FC5 test1 relnotes for translation Date: Tue, 25 Oct 2005 12:36:25 -0700 Message-ID: <1130268985.12794.118.camel@erato.phig.org> In-Reply-To: 1130234817.6932.276.camel@baythorne.infradead.org --===============6709855057140982471== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable 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/ --===============6709855057140982471== Content-Type: application/pgp-signature MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="signature.asc" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4xIChHTlUv TGludXgpCgppRDhEQlFCRFhvazUyWklPQnEwT0RFRVJBbERSQUpzSGNtNi9tR1JCSDNXVUg2dk5R V2Q3R3YrU3FnQ2ZaVEk2ClZqOWxOR09wTDAxWXlpYlZ1Nnl1YTFzPQo9eHplTQotLS0tLUVORCBQ R1AgU0lHTkFUVVJFLS0tLS0K --===============6709855057140982471==-- From kwade at redhat.com Thu Jun 4 22:08:21 2015 Content-Type: multipart/mixed; boundary="===============2348002623109592602==" MIME-Version: 1.0 From: Karsten Wade To: docs at lists.fedoraproject.org Subject: Re: FC5 test1 relnotes make problem(two xml file broken) Date: Tue, 25 Oct 2005 12:38:45 -0700 Message-ID: <1130269125.12794.120.camel@erato.phig.org> In-Reply-To: 200510260108.28890.mumumu@mumumu.org --===============2348002623109592602== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable 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 st= eps. 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(a)cvs.fedora.redhat.com:/cvs/docs > $ cvs co -r FC-5-TEST1-TRANS-FREEZE -d release-notes-FC5test1 release-not= es > $ 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=3Dja.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?a= nnotate=3D1.3&root=3Ddocs > = > i fixed this and tried once more. but i got error again. > = > ---- > = > $ make > LANG=3Dja.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: pa= rser = > error : Opening and ending tag mismatch: para line 1052 and emphasis > ) > ^ > /home/mumumu/work/release-notes-FC5test1/package-movement-en.xml:1056: pa= rser = > error : Opening and ending tag mismatch: section line 1044 and para > > ^ > /home/mumumu/work/release-notes-FC5test1/package-movement-en.xml:1065: pa= rser = > error : chunk is not well balanced > > ^ > /home/mumumu/work/release-notes-FC5test1/package-movement-en.xml:1065: pa= rser = > 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-e= n.xml = > line 1055. > = > http://cvs.fedora.redhat.com/viewcvs/release-notes/package-movement-en.xm= l?annotate=3D1.3&root=3Ddocs > = > 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(a)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/ --===============2348002623109592602== Content-Type: application/pgp-signature MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="signature.asc" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4xIChHTlUv TGludXgpCgppRDhEQlFCRFhvbkYyWklPQnEwT0RFRVJBbm9ZQUp3Tkw5cUlud21Nem5wWS9vZkln bmdpUGJTUlJ3Q2RHalFICjJkUXpIYVRMOWV0RktkcUpBb1BKVmd3PQo9T0tOWAotLS0tLUVORCBQ R1AgU0lHTkFUVVJFLS0tLS0K --===============2348002623109592602==-- From kwade at redhat.com Thu Jun 4 22:08:21 2015 Content-Type: multipart/mixed; boundary="===============7994986171310362487==" MIME-Version: 1.0 From: Karsten Wade To: docs at lists.fedoraproject.org Subject: Re: FC5 test1 relnotes make problem(two xml file broken) Date: Tue, 25 Oct 2005 12:42:37 -0700 Message-ID: <1130269357.12794.123.camel@erato.phig.org> In-Reply-To: 200510260108.28890.mumumu@mumumu.org --===============7994986171310362487== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable 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 st= eps. 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/ --===============7994986171310362487== Content-Type: application/pgp-signature MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="signature.asc" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4xIChHTlUv TGludXgpCgppRDhEQlFCRFhvcXQyWklPQnEwT0RFRVJBcFQ2QUo5K0ZuWVRXL1E3c2ZrNXlDRzRm cW55RzBmU2ZRQ2ZUbzFqCnVIb3U3QXo3V3pBcVhOY0dYK1NRc2RnPQo9TVF4bgotLS0tLUVORCBQ R1AgU0lHTkFUVVJFLS0tLS0K --===============7994986171310362487==-- From dwmw2 at infradead.org Thu Jun 4 22:08:21 2015 Content-Type: multipart/mixed; boundary="===============2063117207243147847==" MIME-Version: 1.0 From: David Woodhouse To: docs at lists.fedoraproject.org Subject: Re: FC5 test1 relnotes for translation Date: Tue, 25 Oct 2005 21:21:32 +0100 Message-ID: <1130271692.6932.378.camel@baythorne.infradead.org> In-Reply-To: 1130268985.12794.118.camel@erato.phig.org --===============2063117207243147847== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable 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 --===============2063117207243147847==-- From mumumu at mumumu.org Thu Jun 4 22:08:21 2015 Content-Type: multipart/mixed; boundary="===============1461175192727750818==" MIME-Version: 1.0 From: Yoshinari Takaoka To: docs at lists.fedoraproject.org Subject: Re: FC5 test1 relnotes make problem(two xml file broken) Date: Wed, 26 Oct 2005 07:05:54 +0900 Message-ID: <200510260705.54301.mumumu@mumumu.org> In-Reply-To: 1130269357.12794.123.camel@erato.phig.org --===============1461175192727750818== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable hi. Wednesday 26 October 2005 04:42 +0900=E3=80=81Karsten 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(a)IRC) reversethis -> {gro} {tod} {umumum} {ta} {umumum}v --===============1461175192727750818==-- From kwade at redhat.com Thu Jun 4 22:08:21 2015 Content-Type: multipart/mixed; boundary="===============3854258733288794101==" MIME-Version: 1.0 From: Karsten Wade To: docs at lists.fedoraproject.org Subject: minutes FDSCo 25 Oct. 2005 Date: Wed, 26 Oct 2005 02:13:02 -0700 Message-ID: <1130317982.12794.193.camel@erato.phig.org> --===============3854258733288794101== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Today we were not able to have a quorum, but no decisions came up that required one. :) Attendees: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Stuart Elliss Karsten Wade Tommy Reynolds Updated activities: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D http://fedoraproject.org/wiki/DocsProject/FedoraDocsSchedule Highlights: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D * 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/ --===============3854258733288794101== Content-Type: application/pgp-signature MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="signature.asc" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4xIChHTlUv TGludXgpCgppRDhEQlFCRFgwaWUyWklPQnEwT0RFRVJBZ25XQUtDTHZjMHpZcUszRzBTUTBlVEdl VXMxT0UvTU9nQ2d6MWttClo0UVREdXRDaFdOSjZHOVA5YXhDTjhZPQo9S1hqcgotLS0tLUVORCBQ R1AgU0lHTkFUVVJFLS0tLS0K --===============3854258733288794101==-- From jlaska at redhat.com Thu Jun 4 22:08:21 2015 Content-Type: multipart/mixed; boundary="===============4715278835219803930==" MIME-Version: 1.0 From: James Laska To: docs at lists.fedoraproject.org Subject: Local document customizations Date: Fri, 28 Oct 2005 09:38:52 -0400 Message-ID: <1130506732.20337.15.camel@flatline.devel.redhat.com> --===============4715278835219803930== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable 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 = -- = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D James Laska -- jlaska(a)redhat.com Quality Engineering -- Red Hat, Inc. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --===============4715278835219803930== Content-Type: text/x-patch MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="fdp-toc.patch" SW5kZXg6IG1haW4taHRtbC54c2wKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQpSQ1MgZmlsZTogL2N2cy9kb2NzL2RvY3Mt Y29tbW9uL3hzbC9tYWluLWh0bWwueHNsLHYKcmV0cmlldmluZyByZXZpc2lvbiAxLjgKZGlmZiAt dSAtdSAtcjEuOCBtYWluLWh0bWwueHNsCi0tLSBtYWluLWh0bWwueHNsCTIxIE9jdCAyMDA1IDIz OjMwOjQwIC0wMDAwCTEuOAorKysgbWFpbi1odG1sLnhzbAkyOCBPY3QgMjAwNSAxMzozMjowMyAt MDAwMApAQCAtMjYsNyArMjYsNyBAQAogPHhzbDpwYXJhbSBuYW1lPSJnZW5lcmF0ZS50b2MiPgog Ym9vayB0b2MKIGFydGljbGUgdG9jCi1jaGFwdGVyIG5vcAorY2hhcHRlciB0b2MKIHFhbmRhZGl2 IHRvYwogcWFuZGFzZXQgdG9jCiBzZWN0MSBub3AKQEAgLTE0NSw0ICsxNDUsMjUgQEAKIDx4c2w6 cGFyYW0gbmFtZT0ibmF2aWcuc2hvd3RpdGxlcyI+MTwveHNsOnBhcmFtPgogLS0+CiAKKzwhLS0g VE9DIC0tPgorPHhzbDp0ZW1wbGF0ZSBtYXRjaD0icHJlZmFjZXxjaGFwdGVyfGFwcGVuZGl4fGFy dGljbGUiIG1vZGU9InRvYyI+CisgICAgPHhzbDpwYXJhbSBuYW1lPSJ0b2MtY29udGV4dCIgc2Vs ZWN0PSIuIi8+CisgICAgPHhzbDpjaG9vc2U+CisgICAgICAgIDx4c2w6d2hlbiB0ZXN0PSJsb2Nh bC1uYW1lKCR0b2MtY29udGV4dCkgPSAnYm9vayciPgorICAgICAgICAgICAgPHhzbDpjYWxsLXRl bXBsYXRlIG5hbWU9InN1YnRvYyI+CisgICAgICAgICAgICAgICAgPHhzbDp3aXRoLXBhcmFtIG5h bWU9InRvYy1jb250ZXh0IiBzZWxlY3Q9IiR0b2MtY29udGV4dCIvPgorICAgICAgICAgICAgICAg IDx4c2w6d2l0aC1wYXJhbSBuYW1lPSJub2RlcyIgc2VsZWN0PSJmb28iLz4KKyAgICAgICAgICAg IDwveHNsOmNhbGwtdGVtcGxhdGU+CisgICAgICAgIDwveHNsOndoZW4+CisgICAgICAgIDx4c2w6 b3RoZXJ3aXNlPgorICAgICAgICAgICAgPHhzbDpjYWxsLXRlbXBsYXRlIG5hbWU9InN1YnRvYyI+ CisgICAgICAgICAgICAgICAgPHhzbDp3aXRoLXBhcmFtIG5hbWU9InRvYy1jb250ZXh0IiBzZWxl Y3Q9IiR0b2MtY29udGV4dCIvPgorICAgICAgICAgICAgICAgIDx4c2w6d2l0aC1wYXJhbSBuYW1l PSJub2RlcyIKKyAgICAgICAgICAgICAgICAgICAgICBzZWxlY3Q9InNlY3Rpb258c2VjdDF8Z2xv c3Nhcnl8YmlibGlvZ3JhcGh5fGluZGV4CisgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHxi cmlkZ2VoZWFkWyRicmlkZ2VoZWFkLmluLnRvYyAhPSAwXSIvPgorICAgICAgICAgICAgPC94c2w6 Y2FsbC10ZW1wbGF0ZT4KKyAgICAgICAgPC94c2w6b3RoZXJ3aXNlPgorICAgIDwveHNsOmNob29z ZT4KKzwveHNsOnRlbXBsYXRlPgorCiA8L3hzbDpzdHlsZXNoZWV0Pgo= --===============4715278835219803930==-- From Tommy.Reynolds at MegaCoder.com Thu Jun 4 22:08:21 2015 Content-Type: multipart/mixed; boundary="===============3375626128822437725==" MIME-Version: 1.0 From: Tommy Reynolds To: docs at lists.fedoraproject.org Subject: Re: Local document customizations Date: Fri, 28 Oct 2005 10:18:14 -0500 Message-ID: <20051028101814.3e4bfdc3.Tommy.Reynolds@MegaCoder.com> In-Reply-To: 1130506732.20337.15.camel@flatline.devel.redhat.com --===============3375626128822437725== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable 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 --===============3375626128822437725== Content-Type: application/pgp-signature MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="attachment.sig" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4xIChHTlUv TGludXgpCgppRDhEQlFGRFlrRTIvMHlkcWtRRGxRRVJBazZTQUtEV2lRM0F0eXM3RFlxZXpvbDgx NW5ZRHU1QXNBQ2ZVSjBGCmVBUGlXVWd5Z2RIa25qUjVYMDh1OGZNPQo9SHU3SwotLS0tLUVORCBQ R1AgU0lHTkFUVVJFLS0tLS0K --===============3375626128822437725==-- From jlaska at redhat.com Thu Jun 4 22:08:22 2015 Content-Type: multipart/mixed; boundary="===============3152331135199995998==" MIME-Version: 1.0 From: James Laska To: docs at lists.fedoraproject.org Subject: Re: Local document customizations Date: Fri, 28 Oct 2005 11:43:47 -0400 Message-ID: <1130514228.20337.22.camel@flatline.devel.redhat.com> In-Reply-To: 20051028101814.3e4bfdc3.Tommy.Reynolds@MegaCoder.com --===============3152331135199995998== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable 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 -- = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D James Laska -- jlaska(a)redhat.com Quality Engineering -- Red Hat, Inc. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --===============3152331135199995998==-- From Tommy.Reynolds at MegaCoder.com Thu Jun 4 22:08:22 2015 Content-Type: multipart/mixed; boundary="===============2291399215561542357==" MIME-Version: 1.0 From: Tommy Reynolds To: docs at lists.fedoraproject.org Subject: Re: Local document customizations Date: Fri, 28 Oct 2005 11:32:55 -0500 Message-ID: <20051028113255.e1033992.Tommy.Reynolds@MegaCoder.com> In-Reply-To: 1130514228.20337.22.camel@flatline.devel.redhat.com --===============2291399215561542357== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable 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 --===============2291399215561542357== Content-Type: application/pgp-signature MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="attachment.sig" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4xIChHTlUv TGludXgpCgppRDhEQlFGRFlsSzgvMHlkcWtRRGxRRVJBcm45QUtDR1c5NmQxamNsbStoYUUySEFa dUhJV0E5eVB3Q2dwK0tICjNiMGtjODIyTmNoUW5XTGsyM2FiRGpvPQo9MStHQwotLS0tLUVORCBQ R1AgU0lHTkFUVVJFLS0tLS0K --===============2291399215561542357==-- From tsekine at sdri.co.jp Thu Jun 4 22:08:22 2015 Content-Type: multipart/mixed; boundary="===============0833911591366994303==" MIME-Version: 1.0 From: SEKINE Tatsuo To: docs at lists.fedoraproject.org Subject: Re: FC5 test1 relnotes make problem(two xml file broken) Date: Sun, 30 Oct 2005 00:21:41 +1000 Message-ID: <20051030.002141.115070803.tsekine@sdri.co.jp> In-Reply-To: 1130269125.12794.120.camel@erato.phig.org --===============0833911591366994303== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable 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(a)sdri.co.jp System Design & Research Inst. Co.,Ltd. --===============0833911591366994303==-- From mumumu at mumumu.org Thu Jun 4 22:08:22 2015 Content-Type: multipart/mixed; boundary="===============8015363336660003335==" MIME-Version: 1.0 From: Yoshinari Takaoka To: docs at lists.fedoraproject.org Subject: Guides content frozen for trans delayed? Date: Sun, 30 Oct 2005 01:01:00 +0900 Message-ID: <200510300101.00623.mumumu@mumumu.org> --===============8015363336660003335== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable hi all. according to DocsProject/Schedule, fedora installation guide contents freez= e = for trans is Oct 28, but its CVS contents are unchanged. http://fedoraproject.org/wiki/DocsProject/Schedule schedule is delayed? Regards. -- = Yoshinari Takaoka(mumumu(a)IRC) reversethis -> {gro} {tod} {umumum} {ta} {umumum} --===============8015363336660003335==-- From stuart at elsn.org Thu Jun 4 22:08:22 2015 Content-Type: multipart/mixed; boundary="===============2850012968912150815==" MIME-Version: 1.0 From: Stuart Ellis To: docs at lists.fedoraproject.org Subject: Re: Guides content frozen for trans delayed? Date: Sat, 29 Oct 2005 18:12:54 +0100 Message-ID: <1130605974.2841.5.camel@localhost.localdomain> In-Reply-To: 200510300101.00623.mumumu@mumumu.org --===============2850012968912150815== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable On Sun, 2005-10-30 at 01:01 +0900, Yoshinari Takaoka wrote: > hi all. > = > according to DocsProject/Schedule, fedora installation guide contents fre= eze = > 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(a)elsn.org Fedora Documentation Project: http://fedora.redhat.com/projects/docs/ GPG key ID: 7098ABEA GPG key fingerprint: 68B0 E291 FB19 C845 E60E 9569 292E E365 7098 ABEA --===============2850012968912150815== Content-Type: application/pgp-signature MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="signature.asc" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4xIChHTlUv TGludXgpCgppRDhEQlFCRFk2MldLUzdqWlhDWXErb1JBZ0NnQUp3TlY0QXpwVXhnMzNES0xzYjhV TzJWazBzN3hnQ2ZadUxrCjIyU0pmUkowWGx2QXF6MjgvcEE4YzVFPQo9VVNSRgotLS0tLUVORCBQ R1AgU0lHTkFUVVJFLS0tLS0K --===============2850012968912150815==-- From kwade at redhat.com Thu Jun 4 22:08:22 2015 Content-Type: multipart/mixed; boundary="===============6973465412897468526==" MIME-Version: 1.0 From: Karsten Wade To: docs at lists.fedoraproject.org Subject: Re: FC5 test1 relnotes make problem(two xml file broken) Date: Sat, 29 Oct 2005 22:17:50 -0700 Message-ID: <1130649470.12794.570.camel@erato.phig.org> In-Reply-To: 20051030.002141.115070803.tsekine@sdri.co.jp --===============6973465412897468526== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable 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/ --===============6973465412897468526== Content-Type: application/pgp-signature MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="signature.asc" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4xIChHTlUv TGludXgpCgppRDhEQlFCRFpGZCsyWklPQnEwT0RFRVJBbExsQUo5c29IWWltY2FZN1E4OXRCVkNY QjAvR2QySktnQ2dqRDZwCmhYd1dvZzJYS2xRYkZpb2ZsZFZVTVl3PQo9TmxMaQotLS0tLUVORCBQ R1AgU0lHTkFUVVJFLS0tLS0K --===============6973465412897468526==-- From sundaram at redhat.com Thu Jun 4 22:08:22 2015 Content-Type: multipart/mixed; boundary="===============5519647612275605047==" MIME-Version: 1.0 From: Rahul Sundaram To: docs at lists.fedoraproject.org Subject: Fedora websites mailing list and Wiki ownership Date: Mon, 31 Oct 2005 00:24:17 +0530 Message-ID: <436516D9.5070703@redhat.com> --===============5519647612275605047== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable 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 --===============5519647612275605047==-- From ed at rpath.com Thu Jun 4 22:08:22 2015 Content-Type: multipart/mixed; boundary="===============9057100478437235041==" MIME-Version: 1.0 From: Edward C. Bailey To: docs at lists.fedoraproject.org Subject: Tech writing position available... Date: Sun, 30 Oct 2005 14:13:06 -0500 Message-ID: <7spspmhl8d.fsf@lambchop.rdu.rpath.com> --===============9057100478437235041== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable (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/=3Dedward.c.bailey rPath, Inc. http://www.rpath.com/ --===============9057100478437235041==-- From Tommy.Reynolds at MegaCoder.com Thu Jun 4 22:08:22 2015 Content-Type: multipart/mixed; boundary="===============7358934163988914281==" MIME-Version: 1.0 From: Tommy Reynolds To: docs at lists.fedoraproject.org Subject: Re: Tech writing position available... Date: Sun, 30 Oct 2005 13:24:28 -0600 Message-ID: <20051030132428.5b8cf63a.Tommy.Reynolds@MegaCoder.com> In-Reply-To: 7spspmhl8d.fsf@lambchop.rdu.rpath.com --===============7358934163988914281== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable 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 --===============7358934163988914281== Content-Type: application/pgp-signature MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="attachment.sig" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4xIChHTlUv TGludXgpCgppRDhEQlFGRFpSM3YvMHlkcWtRRGxRRVJBaG0rQUtDRDdLeWgvbUNYbFVpOGxJOUJ1 MzlZdDBOeDBRQ2d2NnFZCnN1c3ZyQndMek9Mc2tROHJnMGZwUURRPQo9VnR5UAotLS0tLUVORCBQ R1AgU0lHTkFUVVJFLS0tLS0K --===============7358934163988914281==-- From kwade at redhat.com Thu Jun 4 22:08:22 2015 Content-Type: multipart/mixed; boundary="===============1495366507408472203==" MIME-Version: 1.0 From: Karsten Wade To: docs at lists.fedoraproject.org Subject: Re: Tech writing position available... Date: Sun, 30 Oct 2005 14:00:42 -0800 Message-ID: <1130709642.12794.574.camel@erato.phig.org> In-Reply-To: 20051030132428.5b8cf63a.Tommy.Reynolds@MegaCoder.com --===============1495366507408472203== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable 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/ --===============1495366507408472203== Content-Type: application/pgp-signature MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="signature.asc" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4xIChHTlUv TGludXgpCgppRDhEQlFCRFpVS0syWklPQnEwT0RFRVJBc05pQUo5bFQwNUsyY1FISEpMTzZ5M1ph OGZNZE5SSFdnQ2ZYbTdUCmxkMHNMclRENEVXV0RCMjhPdjEwK1N3PQo9R1I5awotLS0tLUVORCBQ R1AgU0lHTkFUVVJFLS0tLS0K --===============1495366507408472203==-- From nman64 at n-man.com Thu Jun 4 22:08:22 2015 Content-Type: multipart/mixed; boundary="===============4442275510093984224==" MIME-Version: 1.0 From: Patrick W. Barnes To: docs at lists.fedoraproject.org Subject: Re: Fedora websites mailing list and Wiki ownership Date: Sun, 30 Oct 2005 18:12:50 -0600 Message-ID: <43656182.9080601@n-man.com> In-Reply-To: 436516D9.5070703@redhat.com --===============4442275510093984224== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable 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 =3D Document Title =3D 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(a)n-man.com www.n-man.com -- = --===============4442275510093984224== Content-Type: application/pgp-signature MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="signature.asc" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4yIChHTlUv TGludXgpCgppRDhEQlFGRFpXR0dkQm9CN0NtVUI5Z1JBZzZzQUo0cGxUZXNONHQ1dFdpN2w4ci85 Sm9uS0pMV2t3Q2VMOHJqCmN6WG9hMUNzZFRRM0dsdlFlNENkWTFFPQo9Nzh0TQotLS0tLUVORCBQ R1AgU0lHTkFUVVJFLS0tLS0K --===============4442275510093984224==-- From nman64 at n-man.com Thu Jun 4 22:08:22 2015 Content-Type: multipart/mixed; boundary="===============1284541532673015659==" MIME-Version: 1.0 From: Patrick W. Barnes To: docs at lists.fedoraproject.org Subject: Re: Tech writing position available... Date: Sun, 30 Oct 2005 18:17:08 -0600 Message-ID: <43656284.8080108@n-man.com> In-Reply-To: 1130709642.12794.574.camel@erato.phig.org --===============1284541532673015659== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable 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(a)n-man.com www.n-man.com -- = --===============1284541532673015659== Content-Type: application/pgp-signature MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="signature.asc" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4yIChHTlUv TGludXgpCgppRDhEQlFGRFpXS0xkQm9CN0NtVUI5Z1JBcFpQQUp3SkloeS9DNWhxWkdzWnM4YjlT dTNMNDEwbm5RQ2RFaWNwCnBRb0ZvcjBLd2IxakdGV0pCdjE4ZlVvPQo9NGRucgotLS0tLUVORCBQ R1AgU0lHTkFUVVJFLS0tLS0K --===============1284541532673015659==-- From Tommy.Reynolds at MegaCoder.com Thu Jun 4 22:08:23 2015 Content-Type: multipart/mixed; boundary="===============1226814644572607283==" MIME-Version: 1.0 From: Tommy Reynolds To: docs at lists.fedoraproject.org Subject: RFC: RPM Changelog thoughts Date: Mon, 31 Oct 2005 07:40:55 -0600 Message-ID: <20051031074055.9bf0fe90.Tommy.Reynolds@MegaCoder.com> --===============1226814644572607283== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable 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 --===============1226814644572607283== Content-Type: application/pgp-signature MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="attachment.sig" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4xIChHTlUv TGludXgpCgppRDhEQlFGRFpoN3IvMHlkcWtRRGxRRVJBaGcwQUo5U3lMeHBIYW1DL2FRdUVZVGpE UmJSNUpIcERnQ2RHelNvCkxyM25ZM3MxbVpPTGhUSnVvV3FxY0owPQo9WUdhZAotLS0tLUVORCBQ R1AgU0lHTkFUVVJFLS0tLS0K --===============1226814644572607283==-- From tsekine at sdri.co.jp Thu Jun 4 22:08:23 2015 Content-Type: multipart/mixed; boundary="===============5389058809037547479==" MIME-Version: 1.0 From: SEKINE Tatsuo To: docs at lists.fedoraproject.org Subject: The translation of legal notice Date: Tue, 01 Nov 2005 01:04:06 +1100 Message-ID: <20051101.010406.43309441.tsekine@sdri.co.jp> --===============5389058809037547479== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable 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(a)sdri.co.jp System Design & Research Inst. Co.,Ltd. --===============5389058809037547479==-- From Tommy.Reynolds at MegaCoder.com Thu Jun 4 22:08:23 2015 Content-Type: multipart/mixed; boundary="===============6463650681212946336==" MIME-Version: 1.0 From: Tommy Reynolds To: docs at lists.fedoraproject.org Subject: Re: The translation of legal notice Date: Mon, 31 Oct 2005 08:21:05 -0600 Message-ID: <20051031082105.9de74670.Tommy.Reynolds@MegaCoder.com> In-Reply-To: 20051101.010406.43309441.tsekine@sdri.co.jp --===============6463650681212946336== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable 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 --===============6463650681212946336== Content-Type: application/pgp-signature MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="attachment.sig" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4xIChHTlUv TGludXgpCgppRDhEQlFGRFppaFIvMHlkcWtRRGxRRVJBcEhHQUo5c0VCTHQyQnkzTTh4TGtaMEdY SC8xbFFEVlpnQ2VLay8xClYyZXMvTDhTNzJHdFpORDhCdjc3ckNrPQo9cFFRRQotLS0tLUVORCBQ R1AgU0lHTkFUVVJFLS0tLS0K --===============6463650681212946336==-- From kwade at redhat.com Thu Jun 4 22:08:23 2015 Content-Type: multipart/mixed; boundary="===============1246251721140429980==" MIME-Version: 1.0 From: Karsten Wade To: docs at lists.fedoraproject.org Subject: Re: The translation of legal notice Date: Mon, 31 Oct 2005 07:06:53 -0800 Message-ID: <1130771214.12794.594.camel@erato.phig.org> In-Reply-To: 20051101.010406.43309441.tsekine@sdri.co.jp --===============1246251721140429980== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable 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/ --===============1246251721140429980== Content-Type: application/pgp-signature MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="signature.asc" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4xIChHTlUv TGludXgpCgppRDhEQlFCRFpqTU4yWklPQnEwT0RFRVJBcGhXQUo0dlpZUzc5NHpPTHJMb1l2c3pR R2FBUlh6dG9RQ2ZjNjFvCjAxbkwvbGxsZGxza0YzbkQ2RHFmVXN3PQo9d3BCVAotLS0tLUVORCBQ R1AgU0lHTkFUVVJFLS0tLS0K --===============1246251721140429980==-- From Tommy.Reynolds at MegaCoder.com Thu Jun 4 22:08:23 2015 Content-Type: multipart/mixed; boundary="===============3461159721037908159==" MIME-Version: 1.0 From: Tommy Reynolds To: docs at lists.fedoraproject.org Subject: Re: The translation of legal notice Date: Mon, 31 Oct 2005 09:18:01 -0600 Message-ID: <20051031091801.d89fb908.Tommy.Reynolds@MegaCoder.com> In-Reply-To: 1130771214.12794.594.camel@erato.phig.org --===============3461159721037908159== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable 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. --===============3461159721037908159== Content-Type: application/pgp-signature MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="attachment.sig" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4xIChHTlUv TGludXgpCgppRDhEQlFGRFpqV3UvMHlkcWtRRGxRRVJBamFyQUtDcHVXS002SEwySkVvck5IVVJw Z2FiOUYwYVBnQ2RHcXBHCm0xQjgxcmJETE94Q2djcWVWUHFUcnQ0PQo9cUR1egotLS0tLUVORCBQ R1AgU0lHTkFUVVJFLS0tLS0K --===============3461159721037908159==-- From kwade at redhat.com Thu Jun 4 22:08:23 2015 Content-Type: multipart/mixed; boundary="===============2155376206134091866==" MIME-Version: 1.0 From: Karsten Wade To: docs at lists.fedoraproject.org Subject: Re: The translation of legal notice Date: Mon, 31 Oct 2005 07:28:51 -0800 Message-ID: <1130772531.12794.612.camel@erato.phig.org> In-Reply-To: 20051031091801.d89fb908.Tommy.Reynolds@MegaCoder.com --===============2155376206134091866== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable 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/l= egalnotice.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/ --===============2155376206134091866== Content-Type: application/pgp-signature MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="signature.asc" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4xIChHTlUv TGludXgpCgppRDhEQlFCRFpqZ3oyWklPQnEwT0RFRVJBc3FOQUtEZlQxLzFtNTMyd3JQYnNUbHBM dzdQTnA2Qi9nQ2ZTdHZpCkw4a1BoY3BnbUg1SDYxQmpZczBDcVNZPQo9ZjZYTAotLS0tLUVORCBQ R1AgU0lHTkFUVVJFLS0tLS0K --===============2155376206134091866==-- From kwade at redhat.com Thu Jun 4 22:08:23 2015 Content-Type: multipart/mixed; boundary="===============7424335391213257124==" MIME-Version: 1.0 From: Karsten Wade To: docs at lists.fedoraproject.org Subject: Re: Fedora websites mailing list and Wiki ownership Date: Mon, 31 Oct 2005 08:07:43 -0800 Message-ID: <1130774863.12794.623.camel@erato.phig.org> In-Reply-To: 43656182.9080601@n-man.com --===============7424335391213257124== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable 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/ --===============7424335391213257124== Content-Type: application/pgp-signature MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="signature.asc" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4xIChHTlUv TGludXgpCgppRDhEQlFCRFprRlAyWklPQnEwT0RFRVJBcFU5QUo5WVlUWVRYN3JweTRZSnBnMlBu cVVqZnRaRlpnQ2doUXFXClcyUlc2cmIwTnNma0FpQnNiVWpmeFpzPQo9NXp6VQotLS0tLUVORCBQ R1AgU0lHTkFUVVJFLS0tLS0K --===============7424335391213257124==-- From stickster at gmail.com Thu Jun 4 22:08:23 2015 Content-Type: multipart/mixed; boundary="===============0124981797094137438==" MIME-Version: 1.0 From: Paul W. Frields To: docs at lists.fedoraproject.org Subject: Re: RFC: RPM Changelog thoughts Date: Mon, 31 Oct 2005 12:23:54 -0500 Message-ID: <1130779434.5412.11.camel@localhost.localdomain> In-Reply-To: 20051031074055.9bf0fe90.Tommy.Reynolds@MegaCoder.com --===============0124981797094137438== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable 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/ --===============0124981797094137438== Content-Type: application/pgp-signature MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="signature.asc" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4xIChHTlUv TGludXgpCgppRDhEQlFCRFpsTXFyTnZKTjcwUk54Y1JBa3VEQUo5VFVodE80Z0VVVGYxQnpmcFh5 VUZBbjJoQ3pBQ2c2bVVICjlHYTZhK0pEZGJOZ0ZhN0l4dWlwaEUwPQo9TzFUSgotLS0tLUVORCBQ R1AgU0lHTkFUVVJFLS0tLS0K --===============0124981797094137438==-- From mumumu at mumumu.org Thu Jun 4 22:08:23 2015 Content-Type: multipart/mixed; boundary="===============8732531076155150388==" MIME-Version: 1.0 From: Yoshinari Takaoka <mumumu at mumumu.org> To: docs at lists.fedoraproject.org Subject: translated screen image Date: Tue, 01 Nov 2005 02:46:39 +0900 Message-ID: <200511010246.39638.mumumu@mumumu.org> --===============8732531076155150388== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable hi all. as you know, fedora installation guide has many figures, and they are engli= sh = screen. i want to relpace them with translated (in my case, japanese) scree= n. can i commit translated images (i.e *-ja_JP.png, *-ja_JP.eps) to the = install-guide/figs/ directory? -- = Yoshinari Takaoka(mumumu(a)IRC) reversethis -> {gro} {tod} {umumum} {ta} {umumum} --===============8732531076155150388==-- From Tommy.Reynolds at MegaCoder.com Thu Jun 4 22:08:24 2015 Content-Type: multipart/mixed; boundary="===============3965586870557853771==" MIME-Version: 1.0 From: Tommy Reynolds <Tommy.Reynolds at MegaCoder.com> To: docs at lists.fedoraproject.org Subject: Re: translated screen image Date: Mon, 31 Oct 2005 11:55:08 -0600 Message-ID: <20051031115508.34e4d2fd.Tommy.Reynolds@MegaCoder.com> In-Reply-To: 200511010246.39638.mumumu@mumumu.org --===============3965586870557853771== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Uttered Yoshinari Takaoka <mumumu(a)mumumu.org>, spake thus: > as you know, fedora installation guide has many figures, and they are eng= lish = > screen. i want to relpace them with translated (in my case, japanese) scr= een. > 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 --===============3965586870557853771== Content-Type: application/pgp-signature MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="attachment.sig" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4xIChHTlUv TGludXgpCgppRDhEQlFGRFpscUIvMHlkcWtRRGxRRVJBcS9qQUtDUmo5cnRRMjVnYkxZYkkwRkRn Mm5vVHNmbVFBQ2dtdWpEClZjd3M0N0t5RkVpZm15REl6YitiODdVPQo9SGM0SAotLS0tLUVORCBQ R1AgU0lHTkFUVVJFLS0tLS0K --===============3965586870557853771==-- From sundaram at redhat.com Thu Jun 4 22:08:24 2015 Content-Type: multipart/mixed; boundary="===============0252430810471895699==" MIME-Version: 1.0 From: Rahul Sundaram <sundaram at redhat.com> To: docs at lists.fedoraproject.org Subject: Re: translated screen image Date: Mon, 31 Oct 2005 23:32:14 +0530 Message-ID: <43665C26.6000508@redhat.com> In-Reply-To: 20051031115508.34e4d2fd.Tommy.Reynolds@MegaCoder.com --===============0252430810471895699== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Tommy Reynolds wrote: >Uttered Yoshinari Takaoka <mumumu(a)mumumu.org>, spake thus: > > = > >>as you know, fedora installation guide has many figures, and they are eng= lish = >>screen. i want to relpace them with translated (in my case, japanese) scr= een. >>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 --===============0252430810471895699==-- From Tommy.Reynolds at MegaCoder.com Thu Jun 4 22:08:24 2015 Content-Type: multipart/mixed; boundary="===============8351162590543167995==" MIME-Version: 1.0 From: Tommy Reynolds <Tommy.Reynolds at MegaCoder.com> To: docs at lists.fedoraproject.org Subject: Re: RFC: RPM Changelog thoughts Date: Mon, 31 Oct 2005 12:49:33 -0600 Message-ID: <20051031124933.a68c503e.Tommy.Reynolds@MegaCoder.com> In-Reply-To: 1130779434.5412.11.camel@localhost.localdomain --===============8351162590543167995== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Uttered "Paul W. Frields" <stickster(a)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: =3D=3D[release-notes/rpm-Changelog]=3D=3D * Mon Oct 31 2005 04:48 bbbush <fedora-docs-list(a)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(a)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(a)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(a)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: =3D=3D[release-notes/AUTHORS]=3D=3D ######################################################################## # We use this AUTHORS file to map CVS checkin names to real names and # email addresses. ######################################################################## # DEFAULT fedora-docs-list(a)redhat.com - jtr Tommy.Reynolds(a)MegaCoder.com Tommy Reynolds kwade Karsten.Wade(a)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 --===============8351162590543167995== Content-Type: application/octet-stream MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="rpm-changelog.obj" IyEvYmluL3NoCmN2czJjbCAtLXN0ZG91dCAtciAtdCAtYiAtLW5vLXdyYXAgIAkJCQkJfAphd2sJ JwpmdW5jdGlvbiB0cmltKCBzLAl2ICkJewoJdiA9IHMKCXN1YiggL15bIFx0XSovLCAiIiwgdiAp CglzdWIoIC9eWyBcdF0qJC8sICIiLCB2ICkKCXJldHVybiggdiApCn0KZnVuY3Rpb24gY2Fub25p Y2FsRGF0ZSggcywJY21kLCB2ICkJewoJY21kID0gc3ByaW50ZiggImRhdGUgLWQgJXMgXCIrJSVh ICUlYiAlJWQgJSVZXCIiLCBzICkKCWNtZCB8IGdldGxpbmUgcwoJY2xvc2UoIGNtZCApCglyZXR1 cm4oIHMgKQp9CmZ1bmN0aW9uIGlzRGF0ZUxpbmUoIHMgKQl7CglyZXR1cm4oIFwKCQlzIH4gL15b MC05XVswLTldWzAtOV1bMC05XVstXVswLTldWzAtOV1bLV1bMC05XVswLTldWyBcdF0qWzAtOV1b MC05XTpbMC05XVswLTldWyBcdF0qW14gXHRdKiQvIFwKCSkKfQpmdW5jdGlvbiBvdXRMaW5lKCkJ ewoJaWYoIGxpbmUgIT0gIiIgKQl7CgkJcHJpbnQgbGluZQoJfQoJbGluZSA9ICIiCglzZXAgPSAi LSAiCn0KQkVHSU4JewoJZGVmTG9naW4gPSAiREVGQVVMVCIKCWVtYWlsc1sgZGVmTG9naW4gXSA9 ICI8ZmVkb3JhLWRvY3MtbGlzdEByZWRoYXQuY29tPiIKCXJlYWxuYW1lc1sgZGVmTG9naW4gXSA9 ICJGSVhNRSIKCXdoaWxlKCBnZXRsaW5lIDwgIkFVVEhPUlMiID4gMCApCXsKCQlzdWIoIC8jLiok LywgJDAgKQoJCWlmKCBORiA+PSAzICkJewoJCQlsb2duYW1lID0gJDEKCQkJZW1haWwgPSAkMgoJ CQkkMSA9ICIiCgkJCSQyID0gIiIKCQkJZW1haWxzWyBsb2duYW1lIF0gPSAiPCIgZW1haWwgIj4i CgkJCXJlYWxuYW1lc1sgbG9nbmFtZSBdID0gdHJpbSggJDAgKQoJCX0KCX0KCW91dExpbmUoKQp9 CnsKCWRvCXsKCQlpZiggTkYgPT0gMyAmJiBpc0RhdGVMaW5lKCAkMCApICkJewoJCQlvdXRMaW5l KCkKCQkJZGF0ZSA9ICQxCgkJCXRvZCA9ICQyCgkJCWF1dGhvciA9ICQzCgkJCWlmKCBhdXRob3Ig aW4gZW1haWxzICkJewoJCQkJZW1haWwgPSBlbWFpbHNbIGF1dGhvciBdCgkJCQlyZWFsbmFtZSA9 IHJlYWxuYW1lc1sgYXV0aG9yIF0KCQkJfSBlbHNlCXsKCQkJCWVtYWlsID0gZW1haWxzWyBkZWZM b2dpbiBdCgkJCQlyZWFsbmFtZSA9IGF1dGhvcgoJCQl9CgkJCWlmKCBvdGhlcnMrKyApCXsKCQkJ CXByaW50ZiAiXG4iCgkJCX0KCQkJcHJpbnRmKCAiKiAlcyAlcyAlcyAlc1xuIiwgY2Fub25pY2Fs RGF0ZShkYXRlKSwgCgkJCQl0b2QsIHJlYWxuYW1lLCBlbWFpbCApCgkJCWdldGxpbmUJIyBFYXQg YmxhbmsgbGluZSBhZnRlciBkYXRlCgkJCWNvbnRpbnVlCgkJfQoJCW4gPSBzcGxpdCggJDAsIHRv a2VucywgL1sgXHRcbl0vICkKCQlmb3IoIGkgPSAxOyBpIDw9IG47ICsraSApCXsKCQkJdG9rZW4g PSB0b2tlbnNbaV0KCQkJaWYoIHRva2VuID09ICIiICkJewoJCQkJY29udGludWUKCQkJfQoJCQlp ZiggdG9rZW4gPT0gIioiICkJewoJCQkJY29udGludWUKCQkJfQoJCQluZXdMaW5lTGVuID0gbGVu Z3RoKHRva2VuKSArIGxlbmd0aChzZXApICsgXAoJCQkJbGVuZ3RoKCBsaW5lICkKCQkJaWYoIG5l d0xpbmVMZW4gPj0gNzIgKQl7CgkJCQlvdXRMaW5lKCkKCQkJfQoJCQlsaW5lID0gc3ByaW50Zigg IiVzJXMlcyIsIGxpbmUsIHNlcCwgdG9rZW4gKQoJCQlzZXAgPSAiICIKCQl9Cgl9IHdoaWxlKCBn ZXRsaW5lID4gMCApCn0KRU5ECXsKCW91dExpbmUoKQp9CicK --===============8351162590543167995== Content-Type: application/pgp-signature MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="attachment.sig" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4xIChHTlUv TGludXgpCgppRDhEQlFGRFptYzkvMHlkcWtRRGxRRVJBbk9VQUtDV3ZVbmRtK2VOVDJmYzAxcFRB dlJlTERVZklnQ2ZlZnZ2Ckg5QzAyK0pYTk5IUWphbjVkcjRRc2xnPQo9QzRvQQotLS0tLUVORCBQ R1AgU0lHTkFUVVJFLS0tLS0K --===============8351162590543167995==-- From stickster at gmail.com Thu Jun 4 22:08:24 2015 Content-Type: multipart/mixed; boundary="===============8712559915933211700==" MIME-Version: 1.0 From: Paul W. Frields <stickster at gmail.com> To: docs at lists.fedoraproject.org Subject: Re: RFC: RPM Changelog thoughts Date: Mon, 31 Oct 2005 14:04:30 -0500 Message-ID: <1130785470.3288.4.camel@localhost.localdomain> In-Reply-To: 20051031124933.a68c503e.Tommy.Reynolds@MegaCoder.com --===============8712559915933211700== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable On Mon, 2005-10-31 at 12:49 -0600, Tommy Reynolds wrote: > Uttered "Paul W. Frields" <stickster(a)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: > = > =3D=3D[release-notes/AUTHORS]=3D=3D > = > ######################################################################## > # We use this AUTHORS file to map CVS checkin names to real names and > # email addresses. > ######################################################################## > # DEFAULT fedora-docs-list(a)redhat.com - > jtr Tommy.Reynolds(a)MegaCoder.com Tommy Reynolds > kwade Karsten.Wade(a)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/ --===============8712559915933211700== Content-Type: application/pgp-signature MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="signature.asc" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4xIChHTlUv TGludXgpCgppRDhEQlFCRFptcStyTnZKTjcwUk54Y1JBckhKQUo0alNmWTljZlptbTlvOGUyTFQ5 SzhTMnB3MGF3Q2duRnN4CnlVZWxaV3BITTBSNVBITVMvbW5EbUJBPQo9Y3VYZQotLS0tLUVORCBQ R1AgU0lHTkFUVVJFLS0tLS0K --===============8712559915933211700==-- From sundaram at redhat.com Thu Jun 4 22:08:24 2015 Content-Type: multipart/mixed; boundary="===============6386791202844981362==" MIME-Version: 1.0 From: Rahul Sundaram <sundaram at redhat.com> To: docs at lists.fedoraproject.org Subject: Re: RFC: RPM Changelog thoughts Date: Tue, 01 Nov 2005 00:55:23 +0530 Message-ID: <43666FA3.9020203@redhat.com> In-Reply-To: 20051031124933.a68c503e.Tommy.Reynolds@MegaCoder.com --===============6386791202844981362== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable 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 --===============6386791202844981362==-- From andrewm at inventa.ru Thu Jun 4 22:08:24 2015 Content-Type: multipart/mixed; boundary="===============2699433958881921084==" MIME-Version: 1.0 From: Andrew Martynov <andrewm at inventa.ru> To: docs at lists.fedoraproject.org Subject: Self-Introduction: Andrew Martynov Date: Tue, 01 Nov 2005 00:14:00 +0300 Message-ID: <20051031211400.GA24305@mk61.inventa.ru> --===============2699433958881921084== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable 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 int= o 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(a)inventa.ru> Key fingerprint =3D 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(a)inventa.ru -- = Andrew Martynov Inventa phone +7(095)7758777 fax +7(095)9270981 http://www.rhd.ru andrewm(a)inventa.ru --===============2699433958881921084==-- From stuart at elsn.org Thu Jun 4 22:08:24 2015 Content-Type: multipart/mixed; boundary="===============8782146212627176866==" MIME-Version: 1.0 From: Stuart Ellis <stuart at elsn.org> To: docs at lists.fedoraproject.org Subject: Re: Fedora websites mailing list and Wiki ownership Date: Mon, 31 Oct 2005 21:53:50 +0000 Message-ID: <1130795630.2811.17.camel@localhost.localdomain> In-Reply-To: 1130774863.12794.623.camel@erato.phig.org --===============8782146212627176866== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable 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(a)elsn.org Fedora Documentation Project: http://fedora.redhat.com/projects/docs/ GPG key ID: 7098ABEA GPG key fingerprint: 68B0 E291 FB19 C845 E60E 9569 292E E365 7098 ABEA --===============8782146212627176866== Content-Type: application/pgp-signature MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="signature.asc" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4xIChHTlUv TGludXgpCgppRDhEQlFCRFpwSnVLUzdqWlhDWXErb1JBZ29hQUo5SEdFTEl3T01DM3g1QkU0U01K UkNQWDVqaWNnQ2ZYVnMzCkNCZWk1UklQb2VXakdPQW9NbmEwZGRBPQo9N3RYagotLS0tLUVORCBQ R1AgU0lHTkFUVVJFLS0tLS0K --===============8782146212627176866==--