From kwade at redhat.com Tue Nov 1 04:34:16 2005 From: kwade at redhat.com (Karsten Wade) Date: Mon, 31 Oct 2005 20:34:16 -0800 Subject: Fedora websites mailing list and Wiki ownership In-Reply-To: <1130795630.2811.17.camel@localhost.localdomain> References: <436516D9.5070703@redhat.com> <43656182.9080601@n-man.com> <1130774863.12794.623.camel@erato.phig.org> <1130795630.2811.17.camel@localhost.localdomain> Message-ID: <1130819656.12794.642.camel@erato.phig.org> On Mon, 2005-10-31 at 21:53 +0000, Stuart Ellis wrote: > 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. This sounds like a reasonable compromise of control, applying more where it is needed, less where it gets in the way. > FWIW, I really like Patrick's idea of having of a mailing list for > official and third-party Website maintainers to get together. I have request fedora-websites-list and will announce it here when it is ready. A post to fedora-announce also seems in order. - Karsten -- Karsten Wade, RHCE * Sr. Tech Writer * http://people.redhat.com/kwade/ gpg fingerprint: 2680 DBFD D968 3141 0115 5F1B D992 0E06 AD0E 0C41 Red Hat SELinux Guide http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/selinux-guide/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From tsekine at sdri.co.jp Tue Nov 1 05:18:04 2005 From: tsekine at sdri.co.jp (SEKINE tatz Tatsuo) Date: Tue, 01 Nov 2005 16:18:04 +1100 (EST) Subject: Proposal: Makefile improvement for the release notes Message-ID: <20051101.161804.59916755.tsekine@sdri.co.jp> Hi, all Now the Makefile has the following entry for the list of XML files: XMLEXTRAFILES-en=daemons-en.xml database-servers-en.xml desktop-en.xml development-tools-en.xml feedback-en.xml file-servers-en.xml file-systems-en.xml hardware-reqs-en.xml install-notes-en.xml intro-en.xml java-package-en.xml kernel-en.xml misc-server-en.xml multimedia-en.xml networking-en.xml overview-en.xml package-movement-en.xml package-notes-en.xml printing-en.xml project-overview-en.xml samba-en.xml security-en.xml server-tools-en.xml splash-en.xml web-servers-en.xml xorg-en.xml IMHO, it could be generalized for the languages like below: ---- 8X ---- 8X ---- 8X ---- 8X ---- 8X ---- 8X ---- 8X ---- define XMLEXTRAFILES_template XMLEXTRAFILES-$(1)=daemons-$(1).xml desktop-$(1).xml development-tools-$(1).xml feedback-$(1).xml file-servers-$(1).xml hardware-reqs-$(1).xml install-notes-$(1).xml intro-$(1).xml java-package-$(1).xml kernel-$(1).xml misc-server-$(1).xml multimedia-$(1).xml networking-$(1).xml overview-$(1).xml package-movement-$(1).xml package-notes-$(1).xml printing-$(1).xml project-overview-$(1).xml samba-$(1).xml security-$(1).xml server-tools-$(1).xml splash-$(1).xml web-servers-$(1).xml xorg-$(1).xml $(foreach LANG,${LANGUAGES},$(eval $(call XMLEXTRAFILES_template,${LANG}))) ---- X8 ---- X8 ---- X8 ---- X8 ---- X8 ---- X8 ---- X8 ---- # I removed unused files(i.e. database-servers-*.xml, # file-systems-*.xml) from it. Regards, -- SEKINE Tatsuo: tsekine at sdri.co.jp System Design & Research Inst. Co.,Ltd. http://www.amazon.co.jp/exec/obidos/ASIN/4797329750 From stickster at gmail.com Tue Nov 1 12:25:51 2005 From: stickster at gmail.com (Paul W. Frields) Date: Tue, 01 Nov 2005 07:25:51 -0500 Subject: RFC: RPM Changelog thoughts In-Reply-To: <43666FA3.9020203@redhat.com> References: <20051031074055.9bf0fe90.Tommy.Reynolds@MegaCoder.com> <1130779434.5412.11.camel@localhost.localdomain> <20051031124933.a68c503e.Tommy.Reynolds@MegaCoder.com> <43666FA3.9020203@redhat.com> Message-ID: <1130847951.2973.3.camel@localhost.localdomain> On Tue, 2005-11-01 at 00:55 +0530, Rahul Sundaram wrote: > 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? This is really a process change and not a bug, but as James has already made this suggestion on list, it's probably a good idea to discuss it here. Specifically, does doing this create any extra burdens on authors or editors, or should the ChangeLog file (to feed the RPM %changelog) simply include packaging-specific information? I would prefer the latter to avoid needless duplication of work. In other words, although the CVS log and/or revision history might have entries with info like this: - style changes - push to version x.y.z, move to final editorial ...the ChangeLog file would instead only include packaging specific entries or things which have nothing to do with the CVS content (much like code packages): - Update to x.y.z - Fix OMF file Comments? -- Paul W. Frields, RHCE http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 Fedora Documentation Project: http://fedora.redhat.com/projects/docs/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From Tommy.Reynolds at MegaCoder.com Tue Nov 1 16:47:16 2005 From: Tommy.Reynolds at MegaCoder.com (Tommy Reynolds) Date: Tue, 1 Nov 2005 10:47:16 -0600 Subject: Proposal: Makefile improvement for the release notes In-Reply-To: <20051101.161804.59916755.tsekine@sdri.co.jp> References: <20051101.161804.59916755.tsekine@sdri.co.jp> Message-ID: <20051101104716.161345ea.Tommy.Reynolds@MegaCoder.com> Uttered SEKINE "tatz" Tatsuo , spake thus: > Now the Makefile has the following entry for the list of XML files: > > XMLEXTRAFILES-en=daemons-en.xml database-servers-en.xml ... > > IMHO, it could be generalized for the languages like below: > > ---- 8X ---- 8X ---- 8X ---- 8X ---- 8X ---- 8X ---- 8X ---- > define XMLEXTRAFILES_template > XMLEXTRAFILES-$(1)=daemons-$(1).xml desktop-$(1).xml ... > > $(foreach LANG,${LANGUAGES},$(eval $(call XMLEXTRAFILES_template,${LANG}))) > ---- X8 ---- X8 ---- X8 ---- X8 ---- X8 ---- X8 ---- X8 ---- > # I removed unused files(i.e. database-servers-*.xml, > # file-systems-*.xml) from it. Yes, this technique will work. Since it is specific to this document, the change should be made in the local "Makefile", as you correctly show. This is a clever solution. Cheers -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From kwade at redhat.com Wed Nov 2 07:47:19 2005 From: kwade at redhat.com (Karsten Wade) Date: Tue, 01 Nov 2005 23:47:19 -0800 Subject: minutes 1 Nov 2005 FDSCo meeting Message-ID: <1130917639.26414.143.camel@erato.phig.org> Attending: ---------- Mark Johnson (mrj) Paul Frields (stickster) Stuart Elliss (elliss) Gavin Henry (G2) Tommy Reyonlds (MegaCoder) Karsten Wade (quaid) Regrets: -------- Tammy Fox (temporary leave-of-absence) Schedule of Tasks: ------------------ http://fedoraproject.org/wiki/DocsProject/FedoraDocsSchedule Highlights: ----------- * Reaffirmation of FDSCo membership requirements/details. Members are active when they can be involved in Fedora enough to make intelligent decisions as a committee member. When they cannot perform that duty, they are obligated to move themselves to inactive status. The committee should never have to tell someone to leave, except in extreme situations. * The formation of the Fedora Foundation is going to be a good opportunity for FDSCo to review it's organization. This is a good time to morph the shape, form more sub-committees, etc. * Reorganizing the beats in this way: FileSystems -> Kernel/FileSystems DatabaseServers -> NetworkServers/DatabaseServers Networking -> Kernel/Networking ServerTools -> SystemConfigTools EmergingTechnologies (new) NetworkServers (new) -- covers mail, ftp, etc. * Bob Jensen is now the Xorg beat writer. Sweet! * Slip of Fedora schedule does not affect writing, editing, or translating. We are getting a few weeks ahead of our work and have tested our tools and processes. No work is lost. However, some of us may have been under pressure to produce within the deadline. Sorry if you lost any sleep, like I did! ## 30 ## -- Karsten Wade, RHCE * Sr. Tech Writer * http://people.redhat.com/kwade/ gpg fingerprint: 2680 DBFD D968 3141 0115 5F1B D992 0E06 AD0E 0C41 Red Hat SELinux Guide http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/selinux-guide/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From luya at jpopmail.com Wed Nov 2 09:51:17 2005 From: luya at jpopmail.com (Luya Tshimbalanga) Date: Wed, 02 Nov 2005 01:51:17 -0800 Subject: Self-introduction: Luya Tshimbalanga Message-ID: <20051102095117.7429F23D02@ws5-3.us4.outblaze.com> Luya Tshimbalanga Vancouver, British Columbia, Canada Freelance writer and web designer Goal in Fedora Project * I currently write information about the installer (Anaconda) and add features that are included. * Due to my french background, I sometime made a grammatical mistake so I hope writing a styling english text will improve my skil Historical qualification * Fedora News contributor, http://www.fedoranews.org * Author of Fedora Test Guide, a tutorial about installing Fedora Rawhide, in Fedora Project * Author of The VOC Soul Gospel Choir article published on http://workinfonet.bc.ca/youth/mindgallery/earcandy/default.cfm?mode=2&ID=341&PAGESTATUS=A * Skilled on XHTML,CSS * W3school certified web developer * Designed draft logo concept for Fedora Project * Fluent in French -- _______________________________________________ Get your free email from http://mymail.jp.popstarmail.org From ghenry at suretecsystems.com Wed Nov 2 10:29:31 2005 From: ghenry at suretecsystems.com (Gavin Henry) Date: Wed, 2 Nov 2005 10:29:31 -0000 (GMT) Subject: Self-introduction: Luya Tshimbalanga In-Reply-To: <20051102095117.7429F23D02@ws5-3.us4.outblaze.com> References: <20051102095117.7429F23D02@ws5-3.us4.outblaze.com> Message-ID: <43948.195.38.86.72.1130927371.squirrel@webmail.suretecsystems.com> > Luya Tshimbalanga Welcome, and added: http://fedoraproject.org/wiki/DocsProject/Contributors -- Kind Regards, Gavin Henry. Managing Director. T +44 (0) 1224 279484 M +44 (0) 7930 323266 F +44 (0) 1224 742001 E ghenry at suretecsystems.com Open Source. Open Solutions(tm). http://www.suretecsystems.com/ From andrewm at inventa.ru Wed Nov 2 13:34:14 2005 From: andrewm at inventa.ru (Andrew Martynov) Date: Wed, 2 Nov 2005 16:34:14 +0300 Subject: Self-Introduction: Andrew Martynov In-Reply-To: <20051031211400.GA24305@mk61.inventa.ru> References: <20051031211400.GA24305@mk61.inventa.ru> Message-ID: <20051102133414.GA2570@mk61.inventa.ru> Full Name: Andrew Martynov City & Country: Moscow, Russian Federation (GMT+0300) Profession: Trainer, Support Engineer Company: Inventa Your goals in the Fedora Project: - translation of Docs of Fedora Project into Russian language Historical qualifications: - maintainer of FC translation project into Russian - paticipant of translation RHEL manuals at www.rhd.ru/docs/ Computer skills: - linux user since 1999 - RHCE/RHCX certifications GPG KeyID and fingerprint: pub 1024D/30E45693 2005-03-18 Andrew Martynov Key fingerprint = 0AF4 0070 E8A7 8C14 F9E0 97D9 320E 10AB 30E4 5693 sub 2048g/37A9C84D 2005-03-18 [expires: 2010-03-17] Other Details: fedoraproject.org wiki username: AndrewMartynov contact e-mail: andrewm at inventa.ru -- Andrew Martynov Inventa phone +7(095)7758777 fax +7(095)9270981 http://www.rhd.ru andrewm at inventa.ru From kwade at redhat.com Wed Nov 2 18:45:43 2005 From: kwade at redhat.com (Karsten Wade) Date: Wed, 02 Nov 2005 10:45:43 -0800 Subject: Self-introduction: Luya Tshimbalanga In-Reply-To: <20051102095117.7429F23D02@ws5-3.us4.outblaze.com> References: <20051102095117.7429F23D02@ws5-3.us4.outblaze.com> Message-ID: <1130957143.26414.162.camel@erato.phig.org> On Wed, 2005-11-02 at 01:51 -0800, Luya Tshimbalanga wrote: > Luya Tshimbalanga Hey Luya, welcome officially. Here is my favorite picture from LWCE San Francisco 2005, featuring Luya in the foreground, Spot, Jack, and Jesse walking away. http://phig.members.sonic.net/imgs/LWCE-SF-2005-Luya_and_boyz_GGBridge-500x667.jpg > * Due to my french background, I sometime made a grammatical mistake so > I hope writing a styling english text will improve my skil Are you interested in also writing in French and having it translated into other languages? I've been very, very curious about this idea for a while. I wonder how it would work out? I think it would be educational for all of us. - Karsten -- Karsten Wade, RHCE * Sr. Tech Writer * http://people.redhat.com/kwade/ gpg fingerprint: 2680 DBFD D968 3141 0115 5F1B D992 0E06 AD0E 0C41 Red Hat SELinux Guide http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/selinux-guide/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From luya at jpopmail.com Wed Nov 2 19:14:06 2005 From: luya at jpopmail.com (Luya Tshimbalanga) Date: Wed, 02 Nov 2005 11:14:06 -0800 Subject: Self-introduction: Luya Tshimbalanga Message-ID: <20051102191406.F077923D02@ws5-3.us4.outblaze.com> Ah that picture, I will add on my profile. Priceless =) >Are you interested in also writing in French and having it translated >into other languages? >I've been very, very curious about this idea for a while. I wonder how >it would work out? I think it would be educational for all of us. Sure. That will further show Fedora Core is an international community project. Luya -- _______________________________________________ Get your free email from http://mymail.jp.popstarmail.org From dpniner at dpniner.net Wed Nov 2 19:26:58 2005 From: dpniner at dpniner.net (David-Paul Niner) Date: Wed, 02 Nov 2005 14:26:58 -0500 Subject: Self-Introduction: David-Paul Niner Message-ID: <43691302.4070509@dpniner.net> Greetings! My name is David-Paul Niner. I am a 35 year-old "just returning to college" male presently residing in Orange Park, Florida (that's a suburb of Jacksonville in the very northeast corner of the state), in the United States. Although I am only presently attending part-time classes (I recently resigned from the local government arena, but enjoyed dragging them into the world of open source nonetheless), I will begin full-time studies in the Computer Science program at the University of North Florida in the Spring of 2006. I enjoy writing immensely. The idea of becoming part of something as important as the Fedora Project excites me; I feel I have much to contribute. My several years experience as a network/systems administrator and my independent studies of CS have allowed me to develop a certain level of comfort when communicating with others on a technical level. However, I also enjoy acting as a translator for those less inclined to learn the more arcane aspects of computer operations and the language itself. Have you ever met someone who was absolutely obsessive about writing and/or grammar perfection? If so, it was probably me. I'm the sort of person who reads everything over two, three, and occasionally four times before committing to it. It's both a blessing and a curse, but it's something I enjoy. I take great pride in attending to detail. I have no formal technical writing training (save for the usual grammar and literature classes taught in college), although I feel confident that I can "hit the ground running" in that area. The simplistic genius of the Gnome environment impresses me; It is that style of interface design--the enormous amount of function balanced against a nearly clutter-free layout--that I find attractive. Having the ability to fine-tune one's desktop environment is, in my opinion, not nearly as important to the average user as some believe; I believe that ease-of-use and intuitiveness will always be more appreciated. If this is a vision shared by you then perhaps I could benefit your team by doing some interface design work. As an aside, I enjoy creative writing as a form of stress relief, and have given serious thought to attempting to publish a work of fiction in the near-to-mid future. I have great respect for both the Fedora Project and for the individual members who compose the whole. Redhat/Fedora is the only flavor of Linux I've seriously come to study, and I've been using one form or another now for nearly eight years (and have used Fedora on the desktop since its conception). I'm now ready to give back in some way if anyone is interested! Below please find my gpg information for review: -------------------------- pub 1024D/215E3188 2005-11-02 Key fingerprint = AA92 20F2 DE95 49AA 860D 814B 6DB3 37A5 215E 3188 uid David-Paul Niner (I'm the real DP!) sub 2048g/48A8C44F 2005-11-02 ---------------------------- Your time and attention are appreciated, David-Paul Niner -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From pnasrat at redhat.com Wed Nov 2 20:35:49 2005 From: pnasrat at redhat.com (Paul Nasrat) Date: Wed, 02 Nov 2005 14:35:49 -0600 Subject: Draft RPM Guide available online Message-ID: <1130963750.2928.27.camel@enki.eridu> I'm very pleased to announce that the Red Hat RPM Guide has been made available under the Open Publication Licence, Version 1.0. http://fedora.redhat.com/docs/drafts/rpm-guide-en/ This is much more recent than Maximum RPM and gives a good starting point to work towards living documentation for RPM. Although some sections - notably Chapter 7 requires a complete rewrite. However I wanted to get it out in it's current form (basically as published plus errata). I'd like to thank Eric Foster-Johnson, all those involved in the original formation of the Guide (particularly Jeff Johnson) and Tammy Fox and those at the publishers for helping to make this happen. Also thanks to the Fedora Docs team in particular Stuart Ellis and Karsten Wade for their conversion and push efforts Participation through normal Fedora Documentation process: http://fedora.redhat.com/projects/docs/ I'll be attempting to form a team to help edit/update content. If you want to help please follow up to fedora-docs-list. Paul From dpniner at dpniner.net Wed Nov 2 20:49:48 2005 From: dpniner at dpniner.net (David-Paul Niner) Date: Wed, 02 Nov 2005 15:49:48 -0500 Subject: Offer to assist with editing RPM Guide Message-ID: <4369266C.9070205@dpniner.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I've only glossed over the topic areas, but what I see looks awesome! It's nice to have a current rpm reference available. If I can be of any assistance, I would be more than willing to help edit. Thank you, David-Paul Niner, RHCE -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFDaSZpbbM3pSFeMYgRAhIuAJ9E7aj/kfUdYdpzxVNWpjVjkJBrawCfeEj+ MMn103XKnvvgrMG6m6MhVF0= =SSy5 -----END PGP SIGNATURE----- -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From ghenry at suretecsystems.com Wed Nov 2 21:41:49 2005 From: ghenry at suretecsystems.com (Gavin Henry) Date: Wed, 2 Nov 2005 21:41:49 -0000 (GMT) Subject: Self-Introduction: David-Paul Niner In-Reply-To: <43691302.4070509@dpniner.net> References: <43691302.4070509@dpniner.net> Message-ID: <56101.192.168.100.90.1130967709.squirrel@webmail.suretecsystems.com> > Greetings! My name is David-Paul Niner. Welcome!! Added: http://fedoraproject.org/wiki/DocsProject/Contributors > I am a 35 year-old "just returning to college" male presently residing > in Orange Park, Florida (that's a suburb of Jacksonville in the very > northeast corner of the state), in the United States. > > Although I am only presently attending part-time classes (I recently > resigned from the local government arena, but enjoyed dragging them into > the world of open source nonetheless), I will begin full-time studies in > the Computer Science program at the University of North Florida in the > Spring of 2006. > > I enjoy writing immensely. The idea of becoming part of something as > important as the Fedora Project excites me; I feel I have much to > contribute. > > My several years experience as a network/systems administrator and my > independent studies of CS have allowed me to develop a certain level of > comfort when communicating with others on a technical level. However, I > also enjoy acting as a translator for those less inclined to learn the > more arcane aspects of computer operations and the language itself. > > Have you ever met someone who was absolutely obsessive about writing > and/or grammar perfection? If so, it was probably me. I'm the sort of > person who reads everything over two, three, and occasionally four times > before committing to it. It's both a blessing and a curse, but it's > something I enjoy. I take great pride in attending to detail. > > I have no formal technical writing training (save for the usual grammar > and literature classes taught in college), although I feel confident > that I can "hit the ground running" in that area. > > The simplistic genius of the Gnome environment impresses me; It is that > style of interface design--the enormous amount of function balanced > against a nearly clutter-free layout--that I find attractive. Having > the ability to fine-tune one's desktop environment is, in my opinion, > not nearly as important to the average user as some believe; I believe > that ease-of-use and intuitiveness will always be more appreciated. > If this is a vision shared by you then perhaps I could benefit your team > by doing some interface design work. > > As an aside, I enjoy creative writing as a form of stress relief, and > have given serious thought to attempting to publish a work of fiction in > the near-to-mid future. > > I have great respect for both the Fedora Project and for the individual > members who compose the whole. Redhat/Fedora is the only flavor of > Linux I've seriously come to study, and I've been using one form or > another now for nearly eight years (and have used Fedora on the desktop > since its conception). I'm now ready to give back in some way if > anyone is interested! > > Below please find my gpg information for review: > > -------------------------- > > pub 1024D/215E3188 2005-11-02 > Key fingerprint = AA92 20F2 DE95 49AA 860D 814B 6DB3 37A5 215E 3188 > uid David-Paul Niner (I'm the real DP!) > > sub 2048g/48A8C44F 2005-11-02 > > ---------------------------- > > Your time and attention are appreciated, > David-Paul Niner > > > > > > -- > This message has been scanned for viruses and > dangerous content by MailScanner, and is > believed to be clean. > > -- > fedora-docs-list mailing list > fedora-docs-list at redhat.com > To unsubscribe: > https://www.redhat.com/mailman/listinfo/fedora-docs-list > From ghenry at suretecsystems.com Wed Nov 2 21:42:21 2005 From: ghenry at suretecsystems.com (Gavin Henry) Date: Wed, 2 Nov 2005 21:42:21 -0000 (GMT) Subject: Self-Introduction: Andrew Martynov In-Reply-To: <20051102133414.GA2570@mk61.inventa.ru> References: <20051031211400.GA24305@mk61.inventa.ru> <20051102133414.GA2570@mk61.inventa.ru> Message-ID: <56112.192.168.100.90.1130967741.squirrel@webmail.suretecsystems.com> > Full Name: Andrew Martynov > City & Country: Moscow, Russian Federation (GMT+0300) > Profession: Trainer, Support Engineer > Company: Inventa Welcome!! Added: http://fedoraproject.org/wiki/DocsProject/Contributors P.S. Don't post twice ;-) > > Your goals in the Fedora Project: > - translation of Docs of Fedora Project into Russian language > > Historical qualifications: > - maintainer of FC translation project into Russian > - paticipant of translation RHEL manuals at www.rhd.ru/docs/ > > Computer skills: > - linux user since 1999 > - RHCE/RHCX certifications > > GPG KeyID and fingerprint: > pub 1024D/30E45693 2005-03-18 Andrew Martynov > Key fingerprint = 0AF4 0070 E8A7 8C14 F9E0 97D9 320E 10AB 30E4 5693 > sub 2048g/37A9C84D 2005-03-18 [expires: 2010-03-17] > > Other Details: > fedoraproject.org wiki username: AndrewMartynov > contact e-mail: andrewm at inventa.ru > -- > Andrew Martynov > Inventa > > phone +7(095)7758777 > fax +7(095)9270981 > http://www.rhd.ru > andrewm at inventa.ru > > -- > fedora-docs-list mailing list > fedora-docs-list at redhat.com > To unsubscribe: > https://www.redhat.com/mailman/listinfo/fedora-docs-list > From kwade at redhat.com Wed Nov 2 21:48:20 2005 From: kwade at redhat.com (Karsten Wade) Date: Wed, 02 Nov 2005 13:48:20 -0800 Subject: Self-Introduction: David-Paul Niner In-Reply-To: <43691302.4070509@dpniner.net> References: <43691302.4070509@dpniner.net> Message-ID: <1130968100.26414.182.camel@erato.phig.org> On Wed, 2005-11-02 at 14:26 -0500, David-Paul Niner wrote: > I'm now ready to give back in some way if > anyone is interested! We're interested, welcome. Nice example of the narrative self-intro, btw. Good enough to prove you can write. ;-) - Karsten -- Karsten Wade, RHCE * Sr. Tech Writer * http://people.redhat.com/kwade/ gpg fingerprint: 2680 DBFD D968 3141 0115 5F1B D992 0E06 AD0E 0C41 Red Hat SELinux Guide http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/selinux-guide/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From pnasrat at redhat.com Wed Nov 2 23:24:50 2005 From: pnasrat at redhat.com (Paul Nasrat) Date: Wed, 02 Nov 2005 18:24:50 -0500 Subject: Offer to assist with editing RPM Guide In-Reply-To: <4369266C.9070205@dpniner.net> References: <4369266C.9070205@dpniner.net> Message-ID: <1130973891.2928.45.camel@enki.eridu> On Wed, 2005-11-02 at 15:49 -0500, David-Paul Niner wrote: > I've only glossed over the topic areas, but what I see looks > awesome! It's nice to have a current rpm reference available. > > If I can be of any assistance, I would be more than willing to help edit. Thanks, I'll collate various peoples details and work to figure how best to organise things along with Stuart. Paul From dpniner at dpniner.net Thu Nov 3 00:05:45 2005 From: dpniner at dpniner.net (David-Paul Niner) Date: Wed, 02 Nov 2005 19:05:45 -0500 Subject: Offer to assist with editing RPM Guide In-Reply-To: <1130973891.2928.45.camel@enki.eridu> References: <4369266C.9070205@dpniner.net> <1130973891.2928.45.camel@enki.eridu> Message-ID: <43695459.7000105@dpniner.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Excellent! Thanks, DP Paul Nasrat wrote: > On Wed, 2005-11-02 at 15:49 -0500, David-Paul Niner wrote: > > >>I've only glossed over the topic areas, but what I see looks >>awesome! It's nice to have a current rpm reference available. >> >>If I can be of any assistance, I would be more than willing to help edit. > > > Thanks, I'll collate various peoples details and work to figure how best > to organise things along with Stuart. > > Paul > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFDaVRWbbM3pSFeMYgRApUEAJ0cD+M6/EX410w3/k15xvguz7qFHACfU25N AXswMhgcUDl1AV0ADp4Ycyg= =HoX8 -----END PGP SIGNATURE----- -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From dpniner at dpniner.net Thu Nov 3 00:06:22 2005 From: dpniner at dpniner.net (David-Paul Niner) Date: Wed, 02 Nov 2005 19:06:22 -0500 Subject: Self-Introduction: David-Paul Niner In-Reply-To: <1130968100.26414.182.camel@erato.phig.org> References: <43691302.4070509@dpniner.net> <1130968100.26414.182.camel@erato.phig.org> Message-ID: <4369547E.5090703@dpniner.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Thank you! David-Paul Niner, RHCE Karsten Wade wrote: > On Wed, 2005-11-02 at 14:26 -0500, David-Paul Niner wrote: > >> I'm now ready to give back in some way if >>anyone is interested! > > > We're interested, welcome. > > Nice example of the narrative self-intro, btw. Good enough to prove you > can write. ;-) > > - Karsten > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFDaVR9bbM3pSFeMYgRAo/LAKCENvDFQMuCQ+LffW3A7G/gh1mLQQCginSy hBggiqy8/VOJG6pwFQFy/oE= =s36P -----END PGP SIGNATURE----- -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From mumumu at mumumu.org Thu Nov 3 14:48:36 2005 From: mumumu at mumumu.org (Yoshinari Takaoka) Date: Thu, 3 Nov 2005 23:48:36 +0900 Subject: figure title centering Message-ID: <200511032348.36383.mumumu@mumumu.org> hi, all. i found that a figure title of the installation guide is not centering, this is the same as original one. for example, http://fedora.redhat.com/docs/fedora-install-guide-en/fc4/ch-other-install-methods.html#sn-installer-tcpip IMHO, its title should be also centering because figure is centering. this is because text alignment of a figure title is undefined in fedora.css. but its a docs-common file and its change affects to all document. can i modify fedora.css as follows, or is there an another solution? RCS file: /cvs/docs/docs-common/css/fedora.css,v retrieving revision 1.7 diff -r1.7 fedora.css 16a17,20 > p.title { > text-align: center; > } > Regards. -- Yoshinari Takaoka(mumumu at IRC) reversethis -> {gro} {tod} {umumum} {ta} {umumum} From Tommy.Reynolds at MegaCoder.com Thu Nov 3 15:25:02 2005 From: Tommy.Reynolds at MegaCoder.com (Tommy Reynolds) Date: Thu, 3 Nov 2005 09:25:02 -0600 Subject: figure title centering In-Reply-To: <200511032348.36383.mumumu@mumumu.org> References: <200511032348.36383.mumumu@mumumu.org> Message-ID: <20051103092502.d47856cd.Tommy.Reynolds@MegaCoder.com> Uttered Yoshinari Takaoka , spake thus: > i found that a figure title of the installation guide is not centering, this > is the same as original one. for example, > http://fedora.redhat.com/docs/fedora-install-guide-en/fc4/ch-other-install-methods.html#sn-installer-tcpip > IMHO, its title should be also centering because figure is centering. > this is because text alignment of a figure title is undefined in fedora.css. > but its a docs-common file and its change affects to all document. > can i modify fedora.css as follows, or is there an another solution? As I Understand It: The stylesheet for your example is not "fedora.css", but another owned by the project, so changing "docs-common" will not accomplish what you want. The files in "docs-common/" are not intended to be the final rendering solution -- just good enough that we can see that the XML is reasonable. Different stylesheets are used for production document releases. Maybe we need a FAQ point about this. Cheers -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mumumu at mumumu.org Thu Nov 3 16:13:24 2005 From: mumumu at mumumu.org (Yoshinari Takaoka) Date: Fri, 4 Nov 2005 01:13:24 +0900 Subject: figure title centering In-Reply-To: <20051103092502.d47856cd.Tommy.Reynolds@MegaCoder.com> References: <200511032348.36383.mumumu@mumumu.org> <20051103092502.d47856cd.Tommy.Reynolds@MegaCoder.com> Message-ID: <200511040113.24718.mumumu@mumumu.org> hi. On Friday 04 November 2005 00:25, Tommy Reynolds wrote: > The files in "docs-common/" are not intended to be the final > rendering solution -- just good enough that we can see that the XML > is reasonable. Different stylesheets are used for production > document releases. ok, i see. i had wrong idea about docs-common module. i thought that "make execution" result is the same as the production release document. > Maybe we need a FAQ point about this. i agree. thank you for modifing fedora.css file. -- Yoshinari Takaoka(mumumu at IRC) reversethis -> {gro} {tod} {umumum} {ta} {umumum} From stickster at gmail.com Thu Nov 3 18:08:05 2005 From: stickster at gmail.com (Paul W. Frields) Date: Thu, 03 Nov 2005 13:08:05 -0500 Subject: figure title centering In-Reply-To: <200511040113.24718.mumumu@mumumu.org> References: <200511032348.36383.mumumu@mumumu.org> <20051103092502.d47856cd.Tommy.Reynolds@MegaCoder.com> <200511040113.24718.mumumu@mumumu.org> Message-ID: <1131041285.3192.13.camel@localhost.localdomain> On Fri, 2005-11-04 at 01:13 +0900, Yoshinari Takaoka wrote: > hi. > > On Friday 04 November 2005 00:25, Tommy Reynolds wrote: > > The files in "docs-common/" are not intended to be the final > > rendering solution -- just good enough that we can see that the XML > > is reasonable. Different stylesheets are used for production > > document releases. > > ok, i see. i had wrong idea about docs-common module. > i thought that "make execution" result is the same as the production > release document. > > > Maybe we need a FAQ point about this. > > i agree. > > thank you for modifing fedora.css file. You could file this as a bug in Bugzilla against product "Fedora Infrastructure," component "web" if you want to see it changed. Good idea! -- Paul W. Frields, RHCE http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 Fedora Documentation Project: http://fedora.redhat.com/projects/docs/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From dpniner at dpniner.net Fri Nov 4 04:45:15 2005 From: dpniner at dpniner.net (David-Paul Niner) Date: Thu, 03 Nov 2005 23:45:15 -0500 Subject: Self-Introduction: David-Paul Niner In-Reply-To: <1130968100.26414.182.camel@erato.phig.org> References: <43691302.4070509@dpniner.net> <1130968100.26414.182.camel@erato.phig.org> Message-ID: <436AE75B.6010609@dpniner.net> Karsten Wade wrote: > On Wed, 2005-11-02 at 14:26 -0500, David-Paul Niner wrote: > >> I'm now ready to give back in some way if >>anyone is interested! > > > We're interested, welcome. > > Nice example of the narrative self-intro, btw. Good enough to prove you > can write. ;-) > > - Karsten > I've been trying for a while to return my signed Contributor License Agreement, but each time I attempt to send it off I receive a scripted reject message back. The message states something to the effect of "Signature Invalid" and contains a link to a page about creating a new gpg key. For grins, I revoked my existing key and created a new one (no big loss here as I don't know if I've ever used it). I then updated my profile to include my new public key and re-requested a blank CLA form. I then re-signed, re-attached, and re-sent, and...the reject messages keep coming. My primary mail client is Thunderbird 1.07 w/ the Enigmail 0.93.0 extension installed for GPG support, although I've tried straight web mail (Squirrelmail) as well, and my outgoing postfix box is not doing any sort of scanning so the message should be going out uncorrupted. I've tried signing the message itself as well as signing the entire thing (message+attachment). If anyone has ever run into the situation before I would greatly appreciate knowing how they managed to get their returned CLA accepted. Specifically, I'd be very interested in knowing which email client they were using... Thanks much. -- David-Paul Niner, RHCE Orange Park, Florida, United States GPG Key ID: 0x106B54E3 From dpniner at dpniner.net Fri Nov 4 04:59:01 2005 From: dpniner at dpniner.net (David-Paul Niner) Date: Thu, 03 Nov 2005 23:59:01 -0500 Subject: Self-Introduction: David-Paul Niner In-Reply-To: <436AE75B.6010609@dpniner.net> References: <43691302.4070509@dpniner.net> <1130968100.26414.182.camel@erato.phig.org> <436AE75B.6010609@dpniner.net> Message-ID: <436AEA95.2060407@dpniner.net> David-Paul Niner wrote: > Karsten Wade wrote: > >>On Wed, 2005-11-02 at 14:26 -0500, David-Paul Niner wrote: >> >> >>> I'm now ready to give back in some way if >>>anyone is interested! >> >> >>We're interested, welcome. >> >>Nice example of the narrative self-intro, btw. Good enough to prove you >>can write. ;-) >> >>- Karsten >> > > > I've been trying for a while to return my signed Contributor License > Agreement, but each time I attempt to send it off I receive a scripted > reject message back. The message states something to the effect of > "Signature Invalid" and contains a link to a page about creating a new > gpg key. > > For grins, I revoked my existing key and created a new one (no big loss > here as I don't know if I've ever used it). I then updated my profile > to include my new public key and re-requested a blank CLA form. I then > re-signed, re-attached, and re-sent, and...the reject messages keep coming. > > My primary mail client is Thunderbird 1.07 w/ the Enigmail 0.93.0 > extension installed for GPG support, although I've tried straight web > mail (Squirrelmail) as well, and my outgoing postfix box is not doing > any sort of scanning so the message should be going out uncorrupted. > I've tried signing the message itself as well as signing the entire > thing (message+attachment). > > If anyone has ever run into the situation before I would greatly > appreciate knowing how they managed to get their returned CLA accepted. > Specifically, I'd be very interested in knowing which email client > they were using... > > Thanks much. > Well, when I read my own reply I saw the MailScanner signature at the bottom and figured out what was going on: Turns out I inadvertently set my internal DNS to reflect a higher mx record that my scanning server, so it was being handed off...anyway, we'll see if that doesn't solve the issue. Sorry, folks! Later, DP -- David-Paul Niner, RHCE Orange Park, Florida, United States GPG Key ID: 0x106B54E3 From dpniner at dpniner.net Fri Nov 4 05:03:06 2005 From: dpniner at dpniner.net (David-Paul Niner) Date: Fri, 04 Nov 2005 00:03:06 -0500 Subject: Self-Introduction: David-Paul Niner In-Reply-To: <436AEA95.2060407@dpniner.net> References: <43691302.4070509@dpniner.net> <1130968100.26414.182.camel@erato.phig.org> <436AE75B.6010609@dpniner.net> <436AEA95.2060407@dpniner.net> Message-ID: <436AEB8A.1020105@dpniner.net> David-Paul Niner wrote: > David-Paul Niner wrote: > >>Karsten Wade wrote: >> >> >>>On Wed, 2005-11-02 at 14:26 -0500, David-Paul Niner wrote: >>> >>> >>> >>>>I'm now ready to give back in some way if >>>>anyone is interested! >>> >>> >>>We're interested, welcome. >>> >>>Nice example of the narrative self-intro, btw. Good enough to prove you >>>can write. ;-) >>> >>>- Karsten >>> >> >> >>I've been trying for a while to return my signed Contributor License >>Agreement, but each time I attempt to send it off I receive a scripted >>reject message back. The message states something to the effect of >>"Signature Invalid" and contains a link to a page about creating a new >>gpg key. >> >>For grins, I revoked my existing key and created a new one (no big loss >>here as I don't know if I've ever used it). I then updated my profile >>to include my new public key and re-requested a blank CLA form. I then >>re-signed, re-attached, and re-sent, and...the reject messages keep coming. >> >>My primary mail client is Thunderbird 1.07 w/ the Enigmail 0.93.0 >>extension installed for GPG support, although I've tried straight web >>mail (Squirrelmail) as well, and my outgoing postfix box is not doing >>any sort of scanning so the message should be going out uncorrupted. >>I've tried signing the message itself as well as signing the entire >>thing (message+attachment). >> >>If anyone has ever run into the situation before I would greatly >>appreciate knowing how they managed to get their returned CLA accepted. >> Specifically, I'd be very interested in knowing which email client >>they were using... >> >>Thanks much. >> > > > Well, when I read my own reply I saw the MailScanner signature at the > bottom and figured out what was going on: Turns out I inadvertently set > my internal DNS to reflect a higher mx record that my scanning server, > so it was being handed off...anyway, we'll see if that doesn't solve the > issue. > > Sorry, folks! > > Later, > DP > Well, still no love -- just did a re-send and it bounced right back. Any suggestions at this point would be greatly appreciated. Thanks again, -- David-Paul Niner, RHCE Orange Park, Florida, United States GPG Key ID: 0x106B54E3 From kwade at redhat.com Fri Nov 4 07:42:34 2005 From: kwade at redhat.com (Karsten Wade) Date: Thu, 03 Nov 2005 23:42:34 -0800 Subject: Self-Introduction: David-Paul Niner In-Reply-To: <436AEB8A.1020105@dpniner.net> References: <43691302.4070509@dpniner.net> <1130968100.26414.182.camel@erato.phig.org> <436AE75B.6010609@dpniner.net> <436AEA95.2060407@dpniner.net> <436AEB8A.1020105@dpniner.net> Message-ID: <1131090154.5130.129.camel@erato.phig.org> On Fri, 2005-11-04 at 00:03 -0500, David-Paul Niner wrote: > > Well, still no love -- just did a re-send and it bounced right back. > Any suggestions at this point would be greatly appreciated. One common problem we've seen is having the email address you are registering with and/or sending from not having a GPG uid. I already discarded the earlier parts of this thread, so I don't have an example GPG key of yours to check, but here is mine for example: pub 1024D/AD0E0C41 2003-11-26 Key fingerprint = 2680 DBFD D968 3141 0115 5F1B D992 0E06 AD0E 0C41 uid Karsten G. Wade (quaid|phig) uid Karsten Wade sub 1024g/C07806E8 2003-11-26 The second uid for kwade at redhat.com was necessary before I could use this GPG key for the CLA process. Otherwise, it got kicked back as invalid. Still, though, I'd figure the account you were sending from may not matter, since it's not a signed email being looked for but rather a signed CLA attached to an email. Hmmm ... This page has our collected knowledge so far: http://fedoraproject.org/wiki/DocsProject/UsingGpg I'll be in #fedora-docs on irc.freenode.net early on Friday, if you come by you can also email me a copy of the signed CLA and I can see if I have any problems decrypting it with your public key. G'luck - Karsten -- Karsten Wade, RHCE * Sr. Tech Writer * http://people.redhat.com/kwade/ gpg fingerprint: 2680 DBFD D968 3141 0115 5F1B D992 0E06 AD0E 0C41 Red Hat SELinux Guide http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/selinux-guide/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From dpniner at dpniner.net Fri Nov 4 07:52:54 2005 From: dpniner at dpniner.net (David-Paul Niner) Date: Fri, 04 Nov 2005 02:52:54 -0500 Subject: Self-Introduction: David-Paul Niner In-Reply-To: <1131090154.5130.129.camel@erato.phig.org> References: <43691302.4070509@dpniner.net> <1130968100.26414.182.camel@erato.phig.org> <436AE75B.6010609@dpniner.net> <436AEA95.2060407@dpniner.net> <436AEB8A.1020105@dpniner.net> <1131090154.5130.129.camel@erato.phig.org> Message-ID: <436B1356.4060904@dpniner.net> Karsten Wade wrote: > On Fri, 2005-11-04 at 00:03 -0500, David-Paul Niner wrote: > > >>Well, still no love -- just did a re-send and it bounced right back. >>Any suggestions at this point would be greatly appreciated. > > > One common problem we've seen is having the email address you are > registering with and/or sending from not having a GPG uid. I already > discarded the earlier parts of this thread, so I don't have an example > GPG key of yours to check, but here is mine for example: > > pub 1024D/AD0E0C41 2003-11-26 > Key fingerprint = 2680 DBFD D968 3141 0115 5F1B D992 0E06 AD0E > 0C41 > uid Karsten G. Wade (quaid|phig) > > uid Karsten Wade > sub 1024g/C07806E8 2003-11-26 > > The second uid for kwade at redhat.com was necessary before I could use > this GPG key for the CLA process. Otherwise, it got kicked back as > invalid. > > Still, though, I'd figure the account you were sending from may not > matter, since it's not a signed email being looked for but rather a > signed CLA attached to an email. Hmmm ... > > This page has our collected knowledge so far: > > http://fedoraproject.org/wiki/DocsProject/UsingGpg > > I'll be in #fedora-docs on irc.freenode.net early on Friday, if you come > by you can also email me a copy of the signed CLA and I can see if I > have any problems decrypting it with your public key. > > G'luck - Karsten > Here's my fingerprint, FWIW: --- pub 1024D/106B54E3 2005-11-03 Key fingerprint = 42D5 1ED2 56F9 385D 981A AEFF 663E 1E3B 106B 54E3 uid David-Paul Niner (created 2005-11-03) sub 2048g/05342A6A 2005-11-03 --- I could add any number of email aliases to see if that helps; I own and manage that domain. For more grins I just re-emailed the same signed file from Evolution. It will be interesting to see if moving to another email clients solves the issue. I've seen some clients do odd things to messages. If I can't get it resolved in the next five minutes (I'm fairly tired) then I'll drop by tomorrow. I'll scour over the docs you referenced first. Later, DP -- David-Paul Niner, RHCE Orange Park, Florida, United States GPG Key ID: 0x106B54E3 From dpniner at dpniner.net Fri Nov 4 08:03:30 2005 From: dpniner at dpniner.net (David-Paul Niner) Date: Fri, 04 Nov 2005 03:03:30 -0500 Subject: Self-Introduction: David-Paul Niner In-Reply-To: <1131090154.5130.129.camel@erato.phig.org> References: <43691302.4070509@dpniner.net> <1130968100.26414.182.camel@erato.phig.org> <436AE75B.6010609@dpniner.net> <436AEA95.2060407@dpniner.net> <436AEB8A.1020105@dpniner.net> <1131090154.5130.129.camel@erato.phig.org> Message-ID: <436B15D2.4080304@dpniner.net> Karsten Wade wrote: > On Fri, 2005-11-04 at 00:03 -0500, David-Paul Niner wrote: > > >>Well, still no love -- just did a re-send and it bounced right back. >>Any suggestions at this point would be greatly appreciated. > > > One common problem we've seen is having the email address you are > registering with and/or sending from not having a GPG uid. I already > discarded the earlier parts of this thread, so I don't have an example > GPG key of yours to check, but here is mine for example: > > pub 1024D/AD0E0C41 2003-11-26 > Key fingerprint = 2680 DBFD D968 3141 0115 5F1B D992 0E06 AD0E > 0C41 > uid Karsten G. Wade (quaid|phig) > > uid Karsten Wade > sub 1024g/C07806E8 2003-11-26 > > The second uid for kwade at redhat.com was necessary before I could use > this GPG key for the CLA process. Otherwise, it got kicked back as > invalid. > > Still, though, I'd figure the account you were sending from may not > matter, since it's not a signed email being looked for but rather a > signed CLA attached to an email. Hmmm ... > > This page has our collected knowledge so far: > > http://fedoraproject.org/wiki/DocsProject/UsingGpg > > I'll be in #fedora-docs on irc.freenode.net early on Friday, if you come > by you can also email me a copy of the signed CLA and I can see if I > have any problems decrypting it with your public key. > > G'luck - Karsten > When I try to do the manual search for my key on pgp.mit.edu using the instructions here: http://fedoraproject.org/wiki/DocsProject/UsingGpg/WithEvolution The server responds immediately, and I can pick the correct key (it's #1), but it times out while trying to fetch it. Quite odd, indeed. Goodnight and thank you, DP -- David-Paul Niner, RHCE Orange Park, Florida, United States GPG Key ID: 0x106B54E3 From kwade at redhat.com Sat Nov 5 10:05:24 2005 From: kwade at redhat.com (Karsten Wade) Date: Sat, 05 Nov 2005 02:05:24 -0800 Subject: Self-Introduction: David-Paul Niner In-Reply-To: <436B15D2.4080304@dpniner.net> References: <43691302.4070509@dpniner.net> <1130968100.26414.182.camel@erato.phig.org> <436AE75B.6010609@dpniner.net> <436AEA95.2060407@dpniner.net> <436AEB8A.1020105@dpniner.net> <1131090154.5130.129.camel@erato.phig.org> <436B15D2.4080304@dpniner.net> Message-ID: <1131185124.4233.72.camel@erato.phig.org> On Fri, 2005-11-04 at 03:03 -0500, David-Paul Niner wrote: > The server responds immediately, and I can pick the correct key (it's > #1), but it times out while trying to fetch it. No timeout now. Perhaps there was back-end sync'ing that you stumbled over. Perhaps the CLA will work this time? - Karsten -- Karsten Wade, RHCE * Sr. Tech Writer * http://people.redhat.com/kwade/ gpg fingerprint: 2680 DBFD D968 3141 0115 5F1B D992 0E06 AD0E 0C41 Red Hat SELinux Guide http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/selinux-guide/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From dpniner at dpniner.net Sat Nov 5 15:15:06 2005 From: dpniner at dpniner.net (David-Paul Niner) Date: Sat, 05 Nov 2005 10:15:06 -0500 Subject: Self-Introduction: David-Paul Niner In-Reply-To: <1131185124.4233.72.camel@erato.phig.org> References: <43691302.4070509@dpniner.net> <1130968100.26414.182.camel@erato.phig.org> <436AE75B.6010609@dpniner.net> <436AEA95.2060407@dpniner.net> <436AEB8A.1020105@dpniner.net> <1131090154.5130.129.camel@erato.phig.org> <436B15D2.4080304@dpniner.net> <1131185124.4233.72.camel@erato.phig.org> Message-ID: <436CCC7A.60506@dpniner.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Karsten Wade wrote: > On Fri, 2005-11-04 at 03:03 -0500, David-Paul Niner wrote: > >>The server responds immediately, and I can pick the correct key (it's >>#1), but it times out while trying to fetch it. > > > No timeout now. Perhaps there was back-end sync'ing that you stumbled > over. Perhaps the CLA will work this time? > > - Karsten > Yes, the delay is gone from the command line. A friend of mine was able to read a test message I signed and sent to them with no issues. There's an option to print out the form and mail it in; perhaps I'll look into that. I hope this doesn't mean that Redhat/Fedora is going to have problems with everything I send them. Curious, DP - -- David-Paul Niner, RHCE Orange Park, Florida, United States GPG Key ID: 0x106B54E3 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFDbMx4Zj4eOxBrVOMRAlVqAJ9Co/GgLI7rgQgI9hFKJVTfIXu7mACdEFsg 8LYzT8vg2jnvqNcBdAGLa/8= =3rlD -----END PGP SIGNATURE----- From dpniner at dpniner.net Sat Nov 5 15:18:17 2005 From: dpniner at dpniner.net (David-Paul Niner) Date: Sat, 05 Nov 2005 10:18:17 -0500 Subject: Self-Introduction: David-Paul Niner In-Reply-To: <436CCC7A.60506@dpniner.net> References: <43691302.4070509@dpniner.net> <1130968100.26414.182.camel@erato.phig.org> <436AE75B.6010609@dpniner.net> <436AEA95.2060407@dpniner.net> <436AEB8A.1020105@dpniner.net> <1131090154.5130.129.camel@erato.phig.org> <436B15D2.4080304@dpniner.net> <1131185124.4233.72.camel@erato.phig.org> <436CCC7A.60506@dpniner.net> Message-ID: <436CCD39.3070808@dpniner.net> David-Paul Niner wrote: > Karsten Wade wrote: > >>>On Fri, 2005-11-04 at 03:03 -0500, David-Paul Niner wrote: >>> >>> >>>>The server responds immediately, and I can pick the correct key (it's >>>>#1), but it times out while trying to fetch it. >>> >>> >>>No timeout now. Perhaps there was back-end sync'ing that you stumbled >>>over. Perhaps the CLA will work this time? >>> >>>- Karsten >>> > > > Yes, the delay is gone from the command line. A friend of mine was able > to read a test message I signed and sent to them with no issues. > > There's an option to print out the form and mail it in; perhaps I'll > look into that. > > I hope this doesn't mean that Redhat/Fedora is going to have problems > with everything I send them. > > Curious, > DP > > -- > David-Paul Niner, RHCE > Orange Park, Florida, United States > GPG Key ID: 0x106B54E3 Forgot to mention that I did try it again this morning, and it bounced back. FYI, DP -- David-Paul Niner, RHCE Orange Park, Florida, United States GPG Key ID: 0x106B54E3 From Tommy.Reynolds at MegaCoder.com Mon Nov 7 03:19:46 2005 From: Tommy.Reynolds at MegaCoder.com (Tommy Reynolds) Date: Sun, 6 Nov 2005 21:19:46 -0600 Subject: Question about RPM packaging. Message-ID: <20051106211946.91953b07.Tommy.Reynolds@MegaCoder.com> Fellow Doc'ers, As I continue to think about RPM packaging for the FDP world, another question arose. I noticed in several other *.desktop files that the package name is specified like this: Name[en] = Example Tutorial Name[de] = Beispiel Tutorial* and so on. My idea here is to use another "Makefile" macro for this, so that individual translators can add the title when they add the translated files. Something like: DOCNAME-en=Example Tutorial DOCNAME-de=Beispiel Tutorial* and on and on. Can someone who is more fluent in a non-Romance language do a quick test to see if make(1) can handle the unicode characters properly? A two-line "Makefile" would be sufficient: all: echo '________________________' where all the underbars should be replaced by some unicode characters. Then, a quick: $ make should show the original characters. Please let me know your results. Thanks! * N.B.: I got this translation from bablefish. Apologies if it is something tacky. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From tsekine at sdri.co.jp Mon Nov 7 05:30:36 2005 From: tsekine at sdri.co.jp (SEKINE tatz Tatsuo) Date: Mon, 07 Nov 2005 16:30:36 +1100 (EST) Subject: Question about RPM packaging. In-Reply-To: <20051106211946.91953b07.Tommy.Reynolds@MegaCoder.com> References: <20051106211946.91953b07.Tommy.Reynolds@MegaCoder.com> Message-ID: <20051107.163036.126343342.tsekine@sdri.co.jp> Hi, From: Tommy Reynolds Date: Sun, 6 Nov 2005 21:19:46 -0600 > As I continue to think about RPM packaging for the FDP world, another > question arose. I noticed in several other *.desktop files that the > package name is specified like this: > > Name[en] = Example Tutorial > Name[de] = Beispiel Tutorial* > > and so on. My idea here is to use another "Makefile" macro for this, > so that individual translators can add the title when they add the > translated files. Something like: > > DOCNAME-en=Example Tutorial > DOCNAME-de=Beispiel Tutorial* As long as I saw some other *.desktop files, "Comment" and "GenericName" fields are also able to be I18N-ed. From: Tommy Reynolds Date: Sun, 6 Nov 2005 21:19:46 -0600 > Can someone who is more fluent in a non-Romance > language do a quick test to see if make(1) can handle the unicode > characters properly? A two-line "Makefile" would be sufficient: > > all: > echo '________________________' > > where all the underbars should be replaced by some unicode > characters. Then, a quick: > > $ make > > should show the original characters. It worked fine for Japanese/UTF-8 characters, regardless of the LANG/LC_ALL values for the make command execution. For example, $ LANG=C make can display Japanese/UTF-8 characters. -- SEKINE Tatsuo: tsekine at sdri.co.jp System Design & Research Inst. Co.,Ltd. From Tommy.Reynolds at MegaCoder.com Mon Nov 7 15:00:32 2005 From: Tommy.Reynolds at MegaCoder.com (Tommy Reynolds) Date: Mon, 7 Nov 2005 09:00:32 -0600 Subject: Question about RPM packaging. In-Reply-To: <20051107.163036.126343342.tsekine@sdri.co.jp> References: <20051106211946.91953b07.Tommy.Reynolds@MegaCoder.com> <20051107.163036.126343342.tsekine@sdri.co.jp> Message-ID: <20051107090032.c756985e.Tommy.Reynolds@MegaCoder.com> Uttered SEKINE "tatz" Tatsuo , spake thus: > > Name[en] = Example Tutorial > > Name[de] = Beispiel Tutorial > As long as I saw some other *.desktop files, "Comment" and > "GenericName" fields are also able to be I18N-ed. Thanks for the hint. I did not notice those before. > > all: > > echo '________________________' > > $ make > It worked fine for Japanese/UTF-8 characters, regardless of > the LANG/LC_ALL values for the make command execution. Excellent news. Thanks, again. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From andrewm at inventa.ru Wed Nov 9 06:46:57 2005 From: andrewm at inventa.ru (Andrew Martynov) Date: Wed, 9 Nov 2005 09:46:57 +0300 Subject: CVS access for translation Message-ID: <20051109064657.GA32129@mk61.inventa.ru> Hello, FDSCo team! How can I get access to CVS to post translated release notes to Russian? I did following steps: - create Wiki account "AndrewMartynov" - made Self Introduction - sign CLA - create Fedora account "andrmart" - download via anonymous CVS release-notes files - prepare translated XML files Currently I could not get access to CVS via "CVS_ROOT=:ext:andrmart at ....". I suppose my account was not activated yet. What should I do next? Regards, Andrew Martynov Inventa phone +7(095)7758777 fax +7(095)9270981 http://www.rhd.ru andrewm at inventa.ru From kwade at redhat.com Wed Nov 9 13:19:14 2005 From: kwade at redhat.com (Karsten Wade) Date: Wed, 09 Nov 2005 05:19:14 -0800 Subject: CVS access for translation In-Reply-To: <20051109064657.GA32129@mk61.inventa.ru> References: <20051109064657.GA32129@mk61.inventa.ru> Message-ID: <1131542354.20949.33.camel@erato.phig.org> On Wed, 2005-11-09 at 09:46 +0300, Andrew Martynov wrote: > Hello, FDSCo team! > > How can I get access to CVS to post translated > release notes to Russian? > > I did following steps: Did you do this: https://admin.fedora.redhat.com/accounts/userbox.cgi?_edit=1 And add yourself to the cvsdocs group? Doing that generates a request that we can approve to give you CVS access. - Karsten > - create Wiki account "AndrewMartynov" > - made Self Introduction > - sign CLA > - create Fedora account "andrmart" > - download via anonymous CVS release-notes files > - prepare translated XML files > > Currently I could not get access to CVS via "CVS_ROOT=:ext:andrmart at ....". > I suppose my account was not activated yet. > > What should I do next? > > Regards, > Andrew Martynov > Inventa > > phone +7(095)7758777 > fax +7(095)9270981 > http://www.rhd.ru > andrewm at inventa.ru > -- Karsten Wade, RHCE * Sr. Tech Writer * http://people.redhat.com/kwade/ gpg fingerprint: 2680 DBFD D968 3141 0115 5F1B D992 0E06 AD0E 0C41 Red Hat SELinux Guide http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/selinux-guide/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From kwade at redhat.com Fri Nov 11 15:38:53 2005 From: kwade at redhat.com (Karsten Wade) Date: Fri, 11 Nov 2005 07:38:53 -0800 Subject: CVS access for translation In-Reply-To: <1131542354.20949.33.camel@erato.phig.org> References: <20051109064657.GA32129@mk61.inventa.ru> <1131542354.20949.33.camel@erato.phig.org> Message-ID: <1131723533.20949.89.camel@erato.phig.org> Just an FYI closer to this, I didn't get email (or filtered them) that requested the CVS grouping for Andrew and a few others. I'll look into that, and all have been approved. cheers - Karsten On Wed, 2005-11-09 at 05:19 -0800, Karsten Wade wrote: > On Wed, 2005-11-09 at 09:46 +0300, Andrew Martynov wrote: > > Hello, FDSCo team! > > > > How can I get access to CVS to post translated > > release notes to Russian? > > > > I did following steps: > Did you do this: > > https://admin.fedora.redhat.com/accounts/userbox.cgi?_edit=1 > > And add yourself to the cvsdocs group? > > Doing that generates a request that we can approve to give you CVS > access. > > - Karsten > > > - create Wiki account "AndrewMartynov" > > - made Self Introduction > > - sign CLA > > - create Fedora account "andrmart" > > - download via anonymous CVS release-notes files > > - prepare translated XML files > > > > Currently I could not get access to CVS via "CVS_ROOT=:ext:andrmart at ....". > > I suppose my account was not activated yet. > > > > What should I do next? > > > > Regards, > > Andrew Martynov > > Inventa > > > > phone +7(095)7758777 > > fax +7(095)9270981 > > http://www.rhd.ru > > andrewm at inventa.ru > > > -- > fedora-docs-list mailing list > fedora-docs-list at redhat.com > To unsubscribe: > https://www.redhat.com/mailman/listinfo/fedora-docs-list -- Karsten Wade, RHCE * Sr. Tech Writer * http://people.redhat.com/kwade/ gpg fingerprint: 2680 DBFD D968 3141 0115 5F1B D992 0E06 AD0E 0C41 Red Hat SELinux Guide http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/selinux-guide/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From fajarpri at cbn.net.id Tue Nov 15 06:33:13 2005 From: fajarpri at cbn.net.id (Fajar Priyanto) Date: Tue, 15 Nov 2005 13:33:13 +0700 Subject: Done translating: FC4 Training Material In-Reply-To: <200511091354.33256.fajarpri@cbn.net.id> References: <200511091137.37747.fajarpri@cbn.net.id> <437185BE.9000409@gmail.com> <200511091354.33256.fajarpri@cbn.net.id> Message-ID: <200511151333.13674.fajarpri@cbn.net.id> On Wednesday 09 November 2005 01:54 pm, Fajar Priyanto wrote: > > An English-language resource on Fedora Core would be most helpful to me, > > as I try to introduce Linux in the broader community of computer users. > > I'll translate it ASAP, along with some revisions already in my mind. The > hardest thing is to have enough strength to do it. Because I am a commuter > that have to take a 70km journey everyday to the office by car. Actually it > isn't so bad if the toll road is not so congested everyday. Ups, looks > like I've been ranting. Ok see you, Hi all, I have finished translating it into English. It can be downloaded from: http://linux2.arinet.org/index.php?option=com_remository&Itemid=31&func=selectfolder&filecatid=2 The filename is 'arinet-tr102-fasttrack-fc4v4E.pdf' Your suggestion and critics are very welcome. Thank you, -- Fajar Priyanto | Reg'd Linux User #327841 | Linux tutorial http://linux2.arinet.org 23:38:41 up 2:03, 2.6.11-1.1369_FC4 GNU/Linux Let's use OpenOffice. http://www.openoffice.org From stuart at elsn.org Wed Nov 16 19:14:24 2005 From: stuart at elsn.org (Stuart Ellis) Date: Wed, 16 Nov 2005 19:14:24 +0000 Subject: Done translating: FC4 Training Material In-Reply-To: <200511151333.13674.fajarpri@cbn.net.id> References: <200511091137.37747.fajarpri@cbn.net.id> <437185BE.9000409@gmail.com> <200511091354.33256.fajarpri@cbn.net.id> <200511151333.13674.fajarpri@cbn.net.id> Message-ID: <1132168464.2827.2.camel@localhost.localdomain> On Tue, 2005-11-15 at 13:33 +0700, Fajar Priyanto wrote: > On Wednesday 09 November 2005 01:54 pm, Fajar Priyanto wrote: > > > An English-language resource on Fedora Core would be most helpful to me, > > > as I try to introduce Linux in the broader community of computer users. > > > > I'll translate it ASAP, along with some revisions already in my mind. The > > hardest thing is to have enough strength to do it. Because I am a commuter > > that have to take a 70km journey everyday to the office by car. Actually it > > isn't so bad if the toll road is not so congested everyday. Ups, looks > > like I've been ranting. Ok see you, > > Hi all, > I have finished translating it into English. > It can be downloaded from: > http://linux2.arinet.org/index.php?option=com_remository&Itemid=31&func=selectfolder&filecatid=2 > The filename is 'arinet-tr102-fasttrack-fc4v4E.pdf' Hi, I've tried this link and get a "registration required" page. Is there another way to pick up the file ? -- Stuart Ellis stuart at elsn.org Fedora Documentation Project: http://fedora.redhat.com/projects/docs/ GPG key ID: 7098ABEA GPG key fingerprint: 68B0 E291 FB19 C845 E60E 9569 292E E365 7098 ABEA -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From fajarpri at cbn.net.id Thu Nov 17 02:58:36 2005 From: fajarpri at cbn.net.id (Fajar Priyanto) Date: Thu, 17 Nov 2005 09:58:36 +0700 Subject: Done translating: FC4 Training Material In-Reply-To: <1132168464.2827.2.camel@localhost.localdomain> References: <200511091137.37747.fajarpri@cbn.net.id> <200511151333.13674.fajarpri@cbn.net.id> <1132168464.2827.2.camel@localhost.localdomain> Message-ID: <200511170958.36721.fajarpri@cbn.net.id> On Thursday 17 November 2005 02:14 am, Stuart Ellis wrote: > Hi, > > I've tried this link and get a "registration required" page. Is there > another way to pick up the file ? Hello Stuart, Sure, I can send it to your email. It's about 5MB, is it OK? Sorry about the registration, it's required to prevent file leeching and other abuses. We can't be too careful right? Nice to meet you, -- Fajar Priyanto | Reg'd Linux User #327841 | Linux tutorial http://linux2.arinet.org 09:58:25 up 1:40, 2.6.11-1.1369_FC4 GNU/Linux Let's use OpenOffice. http://www.openoffice.org From Serge.Sterck at fmsb.be Thu Nov 17 09:15:43 2005 From: Serge.Sterck at fmsb.be (Serge.Sterck at fmsb.be) Date: Thu, 17 Nov 2005 10:15:43 +0100 Subject: RPM Guide in odt format Message-ID: An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: rpm.odt Type: application/octet-stream Size: 14179 bytes Desc: not available URL: From sopwith at redhat.com Thu Nov 17 22:52:44 2005 From: sopwith at redhat.com (Elliot Lee) Date: Thu, 17 Nov 2005 17:52:44 -0500 (EST) Subject: Rawhide of Docs Message-ID: If you'd like to see the latest and greatest docs that that the Fedora Documentation team has been working on, you can now visit http://webtest.fedora.redhat.com/docs/ Join the fun! -- Elliot From nman64 at n-man.com Thu Nov 17 23:07:13 2005 From: nman64 at n-man.com (Patrick Barnes) Date: Thu, 17 Nov 2005 17:07:13 -0600 Subject: make on older systems (RHEL3) Message-ID: <437D0D21.1060206@n-man.com> I've made some revisions to docs-common/Makefile.common in an attempt to resolve build failures on RHEL3. I'd like this to undergo more testing (particularly on older systems) before committing it. In particular, I would like Tommy to take a quick look at this to make sure it doesn't break anything. It is a syntax change that, to the best of my knowledge, shouldn't change behavior, but I'm not overly experienced with Makefiles. The altered file is attached. -- Patrick "The N-Man" Barnes nman64 at n-man.com www.n-man.com -- -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: Makefile.common URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From nman64 at n-man.com Thu Nov 17 23:16:09 2005 From: nman64 at n-man.com (Patrick Barnes) Date: Thu, 17 Nov 2005 17:16:09 -0600 Subject: Rawhide of Docs In-Reply-To: References: Message-ID: <437D0F39.6060205@n-man.com> Elliot Lee wrote: > If you'd like to see the latest and greatest docs that that the Fedora > Documentation team has been working on, you can now visit > http://webtest.fedora.redhat.com/docs/ > > Join the fun! > -- Elliot > > Remember: This is _Rawhide_ and should be treated accordingly. Don't go about linking to it or requiring it at this time. It will change, it will evolve, it may eat all the cheese in your house. :-) -- Patrick "The N-Man" Barnes nman64 at n-man.com www.n-man.com -- -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From Tommy.Reynolds at MegaCoder.com Fri Nov 18 03:02:47 2005 From: Tommy.Reynolds at MegaCoder.com (Tommy Reynolds) Date: Thu, 17 Nov 2005 21:02:47 -0600 Subject: Rawhide of Docs In-Reply-To: References: Message-ID: <20051117210247.736636a8.Tommy.Reynolds@MegaCoder.com> Uttered Elliot Lee , spake thus: > If you'd like to see the latest and greatest docs that that the Fedora > Documentation team has been working on, you can now visit > http://webtest.fedora.redhat.com/docs/ What a rush! I *like* it! Cheers -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Tommy.Reynolds at MegaCoder.com Fri Nov 18 04:45:21 2005 From: Tommy.Reynolds at MegaCoder.com (Tommy Reynolds) Date: Thu, 17 Nov 2005 22:45:21 -0600 Subject: make on older systems (RHEL3) In-Reply-To: <437D0D21.1060206@n-man.com> References: <437D0D21.1060206@n-man.com> Message-ID: <20051117224521.142fdbf3.Tommy.Reynolds@MegaCoder.com> Uttered Patrick Barnes , spake thus: > I've made some revisions to docs-common/Makefile.common in an attempt to > resolve build failures on RHEL3. I'd like this to undergo more testing > (particularly on older systems) before committing it. In particular, I > would like Tommy to take a quick look at this to make sure it doesn't > break anything. It is a syntax change that, to the best of my > knowledge, shouldn't change behavior, but I'm not overly experienced > with Makefiles. > > The altered file is attached. Sorry, but it's not even close ;-( Let me explain what's going on in a bit of detail, so everybody will be on the same page. Someday I'll fold it into the docs... (yeah, right) The magic is all driven from a ${LANGUAGES} macro that holds a simple list of all the languages we must support in the make(1) setup. Here is the target and some rules for one language: $(DOCBASE)-en/index.html:: ${DOCBASE}-en.xml ${EXTRAXMLFILES-en} LANG=en.UTF-8 ${XMLTO} html -x $(XSLHTML) -o $(DOCBASE)-en \ $(DOCBASE)-en.xml mkdir -p $(DOCBASE)-en/stylesheet-images/ cp ${FDPDIR}/docs-common/stylesheet-images/*.png \ $(DOCBASE)-en/stylesheet-images cp ${FDPDIR}/docs-common/css/fedora.css $(DOCBASE)-en/ [ ! -d figs ] || ( \ mkdir -p ${DOCBASE}-en/figs; \ find figs -type f -iname '*.*' -print | \ egrep -vi '*.eps' | \ egrep '(.*-$(1)..*)|([^-]*[.][^-]*)' | \ while read x; do cp -f $$$${x} ${DOCBASE}-$(1)/figs; done \ ) && exit 0 Now, here is another target and its rules for a translation: $(DOCBASE)-it/index.html:: ${DOCBASE}-it.xml ${EXTRAXMLFILES-it} LANG=en.UTF-8 ${XMLTO} html -x $(XSLHTML) -o $(DOCBASE)-it \ $(DOCBASE)-it.xml mkdir -p $(DOCBASE)-it/stylesheet-images/ cp ${FDPDIR}/docs-common/stylesheet-images/*.png \ $(DOCBASE)-it/stylesheet-images cp ${FDPDIR}/docs-common/css/fedora.css $(DOCBASE)-it/ [ ! -d figs ] || ( \ mkdir -p ${DOCBASE}-it/figs; \ find figs -type f -iname '*.*' -print | \ egrep -vi '*.eps' | \ egrep '(.*-$(1)..*)|([^-]*[.][^-]*)' | \ while read x; do cp -f $$$${x} ${DOCBASE}-$(1)/figs; done \ ) && exit 0 So, using traditional make(1) constructs, we would have an "unrolled loop" that looks like this: ${DOCBASE-en/index.html:: ${DOCBASE}-en.xml ${EXTRAXMLFILES-en} LANG=en.UTF-8 ${XMLTO} html -x $(XSLHTML) -o $(DOCBASE)-it \ $(DOCBASE)-it.xml ... ${DOCBASE-de/index.html:: ${DOCBASE}-de.xml ${EXTRAXMLFILES-de} LANG=en.UTF-8 ${XMLTO} html -x $(XSLHTML) -o $(DOCBASE)-it \ $(DOCBASE)-it.xml ... ${DOCBASE-it/index.html:: ${DOCBASE}-it.xml ${EXTRAXMLFILES-it} LANG=en.UTF-8 ${XMLTO} html -x $(XSLHTML) -o $(DOCBASE)-it \ $(DOCBASE)-it.xml ... See the emerging pattern? GNU make(1) implements a "template", which is a bit like a CPP macro preprocessor for the Makefile: define HTML_template ${DOCBASE}-$(1)/index.html:: ${DOCBASE}-$(1).xml $$(XMLEXTRAFILES-$(1)) LANG=$(1).UTF-8 ${XMLTO} html -x $(XSLHTML) -o $(DOCBASE)-$(1) $(DOCBASE)-$(1).xml mkdir -p $(DOCBASE)-$(1)/stylesheet-images/ cp ${FDPDIR}/docs-common/stylesheet-images/*.png $(DOCBASE)-$(1)/stylesheet-images cp ${FDPDIR}/docs-common/css/fedora.css $$(DOCBASE)-$(1)/ [ ! -d figs ] || ( \ mkdir -p ${DOCBASE}-$(1)/figs; \ find figs -type f -iname '*.*' -print | \ egrep -vi '*.eps' | \ egrep '(.*-$(1)..*)|([^-]*[.][^-]*)' | \ while read x; do cp -f $$$${x} ${DOCBASE}-$(1)/figs; done \ ) && exit 0 endef Here, the "HTML_template" will take one parameter, the locale code that marks the language of interest. We get these from the ${LANGUAGES} macro, so we somehow need to obtain a Makefile line like: html:: ${DOCBASE}-en/index.html ${DOCBASE}-de/index.html ... \ ${DOCBASE}-it/index.html without needing to do any editing when a new language gets added. One way to do this would have been to use various patsubst verbs for an in-line expansion, something like: html:: ${LANGUAGES:^%=${DOCBASE}-%:%$=%/index.html} (OK, that's not a valid line, but it gets the point across. The real code was even uglier.) Assume "LANGUAGES=en de it"; the construct you used: html:: ${DOCBASE}-${LANGUAGES}/index.html expands to html:: example_tutorial-en de it/index.html which is not what we want. Meanwhile, back at the patsubst example: well and good, as far as it goes. Unfortunately, this works only for in-line expansion and is useless to "unroll the loop" to generate all the code and rules we need for every language we need to support. When the Makefile.common does: $(foreach LANG,${LANGUAGES},$(eval $(call HTML_template,${LANG}))) it is exactly the same as having cut & pasted the lines within the template body while replacing each instance of "$(1)" with one language locale from the ${LANGUAGES} list. You can watch all this happen by going into the "release-notes" document and typing this: $ make -n -p | less In particular, look for the stanzas introduced by lines with "LANG=.UTF-8". All of these were generated as the template was expanded in the $(foreach ...) lines. Maybe this technique was just too cute to be maintainable. I don't know when template support was introduced, but it's in FC4 and later. If this is a real problem, we have other technologies such as shell scripts, awk scripts, perl scripts, m4 macros, and on. HTH -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From nman64 at n-man.com Fri Nov 18 07:42:05 2005 From: nman64 at n-man.com (Patrick Barnes) Date: Fri, 18 Nov 2005 01:42:05 -0600 Subject: make on older systems (RHEL3) In-Reply-To: <20051117224521.142fdbf3.Tommy.Reynolds@MegaCoder.com> References: <437D0D21.1060206@n-man.com> <20051117224521.142fdbf3.Tommy.Reynolds@MegaCoder.com> Message-ID: <437D85CD.5080406@n-man.com> Tommy Reynolds wrote: > Uttered Patrick Barnes , spake thus: > > >> I've made some revisions to docs-common/Makefile.common in an attempt to >> resolve build failures on RHEL3. I'd like this to undergo more testing >> (particularly on older systems) before committing it. In particular, I >> would like Tommy to take a quick look at this to make sure it doesn't >> break anything. It is a syntax change that, to the best of my >> knowledge, shouldn't change behavior, but I'm not overly experienced >> with Makefiles. >> >> The altered file is attached. >> > > Sorry, but it's not even close ;-( > > Let me explain what's going on in a bit of detail, so everybody will > be on the same page. Someday I'll fold it into the docs... (yeah, > right) > > The magic is all driven from a ${LANGUAGES} macro that holds a simple > list of all the languages we must support in the make(1) setup. > > Here is the target and some rules for one language: > > $(DOCBASE)-en/index.html:: ${DOCBASE}-en.xml ${EXTRAXMLFILES-en} > LANG=en.UTF-8 ${XMLTO} html -x $(XSLHTML) -o $(DOCBASE)-en \ > $(DOCBASE)-en.xml > mkdir -p $(DOCBASE)-en/stylesheet-images/ > cp ${FDPDIR}/docs-common/stylesheet-images/*.png \ > $(DOCBASE)-en/stylesheet-images > cp ${FDPDIR}/docs-common/css/fedora.css $(DOCBASE)-en/ > [ ! -d figs ] || ( \ > mkdir -p ${DOCBASE}-en/figs; \ > find figs -type f -iname '*.*' -print | \ > egrep -vi '*.eps' | \ > egrep '(.*-$(1)..*)|([^-]*[.][^-]*)' | \ > while read x; do cp -f $$$${x} ${DOCBASE}-$(1)/figs; done \ > ) && exit 0 > > Now, here is another target and its rules for a translation: > > $(DOCBASE)-it/index.html:: ${DOCBASE}-it.xml ${EXTRAXMLFILES-it} > LANG=en.UTF-8 ${XMLTO} html -x $(XSLHTML) -o $(DOCBASE)-it \ > $(DOCBASE)-it.xml > mkdir -p $(DOCBASE)-it/stylesheet-images/ > cp ${FDPDIR}/docs-common/stylesheet-images/*.png \ > $(DOCBASE)-it/stylesheet-images > cp ${FDPDIR}/docs-common/css/fedora.css $(DOCBASE)-it/ > [ ! -d figs ] || ( \ > mkdir -p ${DOCBASE}-it/figs; \ > find figs -type f -iname '*.*' -print | \ > egrep -vi '*.eps' | \ > egrep '(.*-$(1)..*)|([^-]*[.][^-]*)' | \ > while read x; do cp -f $$$${x} ${DOCBASE}-$(1)/figs; done \ > ) && exit 0 > > So, using traditional make(1) constructs, we would have an "unrolled > loop" that looks like this: > > ${DOCBASE-en/index.html:: ${DOCBASE}-en.xml ${EXTRAXMLFILES-en} > LANG=en.UTF-8 ${XMLTO} html -x $(XSLHTML) -o $(DOCBASE)-it \ > $(DOCBASE)-it.xml > ... > ${DOCBASE-de/index.html:: ${DOCBASE}-de.xml ${EXTRAXMLFILES-de} > LANG=en.UTF-8 ${XMLTO} html -x $(XSLHTML) -o $(DOCBASE)-it \ > $(DOCBASE)-it.xml > ... > ${DOCBASE-it/index.html:: ${DOCBASE}-it.xml ${EXTRAXMLFILES-it} > LANG=en.UTF-8 ${XMLTO} html -x $(XSLHTML) -o $(DOCBASE)-it \ > $(DOCBASE)-it.xml > ... > > See the emerging pattern? GNU make(1) implements a "template", which > is a bit like a CPP macro preprocessor for the Makefile: > > define HTML_template > ${DOCBASE}-$(1)/index.html:: ${DOCBASE}-$(1).xml $$(XMLEXTRAFILES-$(1)) > LANG=$(1).UTF-8 ${XMLTO} html -x $(XSLHTML) -o $(DOCBASE)-$(1) $(DOCBASE)-$(1).xml > mkdir -p $(DOCBASE)-$(1)/stylesheet-images/ > cp ${FDPDIR}/docs-common/stylesheet-images/*.png $(DOCBASE)-$(1)/stylesheet-images > cp ${FDPDIR}/docs-common/css/fedora.css $$(DOCBASE)-$(1)/ > [ ! -d figs ] || ( \ > mkdir -p ${DOCBASE}-$(1)/figs; \ > find figs -type f -iname '*.*' -print | \ > egrep -vi '*.eps' | \ > egrep '(.*-$(1)..*)|([^-]*[.][^-]*)' | \ > while read x; do cp -f $$$${x} ${DOCBASE}-$(1)/figs; done \ > ) && exit 0 > endef > > Here, the "HTML_template" will take one parameter, the locale code > that marks the language of interest. We get these from the > ${LANGUAGES} macro, so we somehow need to obtain a Makefile line > like: > > html:: ${DOCBASE}-en/index.html ${DOCBASE}-de/index.html ... \ > ${DOCBASE}-it/index.html > > without needing to do any editing when a new language gets added. > > One way to do this would have been to use various patsubst verbs for > an in-line expansion, something like: > > html:: ${LANGUAGES:^%=${DOCBASE}-%:%$=%/index.html} > > (OK, that's not a valid line, but it gets the point across. The real > code was even uglier.) Assume "LANGUAGES=en de it"; the construct you used: > > html:: ${DOCBASE}-${LANGUAGES}/index.html > > expands to > > html:: example_tutorial-en de it/index.html > > which is not what we want. > > Meanwhile, back at the patsubst example: well and good, as far as it > goes. Unfortunately, this works only for in-line expansion and is > useless to "unroll the loop" to generate all the code and rules we > need for every language we need to support. When the Makefile.common > does: > > $(foreach LANG,${LANGUAGES},$(eval $(call HTML_template,${LANG}))) > > it is exactly the same as having cut & pasted the lines within the > template body while replacing each instance of "$(1)" with one > language locale from the ${LANGUAGES} list. > > You can watch all this happen by going into the "release-notes" > document and typing this: > > $ make -n -p | less > > In particular, look for the stanzas introduced by lines with > "LANG=.UTF-8". All of these were generated as the template was > expanded in the $(foreach ...) lines. > > Maybe this technique was just too cute to be maintainable. I don't > know when template support was introduced, but it's in FC4 and later. > > If this is a real problem, we have other technologies such as shell > scripts, awk scripts, perl scripts, m4 macros, and on. > > HTH > D'oh. I should have caught my error on that one. I don't think it is high-priority right now, and I hope it doesn't become such. Elliot was trying to use an RHEL3 system, but just used an RHEL4 system when it didn't work. -- Patrick "The N-Man" Barnes nman64 at n-man.com www.n-man.com -- -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From stickster at gmail.com Fri Nov 18 20:34:35 2005 From: stickster at gmail.com (Paul W. Frields) Date: Fri, 18 Nov 2005 15:34:35 -0500 Subject: Proposal for document entities Message-ID: <1132346075.5672.23.camel@localhost.localdomain> Currently, our documents have entities like this (please pardon the MUA mangling): %FEDORA-ENTITIES-EN; I would like to see this instead as a standard: Any input? -- Paul W. Frields, RHCE http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 Fedora Documentation Project: http://fedora.redhat.com/projects/docs/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From nman64 at n-man.com Fri Nov 18 22:21:46 2005 From: nman64 at n-man.com (Patrick Barnes) Date: Fri, 18 Nov 2005 16:21:46 -0600 Subject: Proposal for document entities In-Reply-To: <1132346075.5672.23.camel@localhost.localdomain> References: <1132346075.5672.23.camel@localhost.localdomain> Message-ID: <437E53FA.9060100@n-man.com> Paul W. Frields wrote: > Currently, our documents have entities like this (please pardon the MUA > mangling): > > "../docs-common/common/fedora-entities-en.ent"> > %FEDORA-ENTITIES-EN; > > > > I would like to see this instead as a standard: > > > > > > > > > Any input? > > +1 It is usually considered best practice to track a package's name, version and revision date separately. No sense in making an exception for docs. :-) -- Patrick "The N-Man" Barnes nman64 at n-man.com www.n-man.com -- -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From Tommy.Reynolds at MegaCoder.com Sat Nov 19 05:57:11 2005 From: Tommy.Reynolds at MegaCoder.com (Tommy Reynolds) Date: Fri, 18 Nov 2005 23:57:11 -0600 Subject: Advise on Fedora RPM's Message-ID: <20051118235711.50ea5f96.Tommy.Reynolds@MegaCoder.com> Hello Paul, kwade, list, et. al. I've been struggling with FDP RPM's for a couple of weeks and they are not coming together. I think the reason I'm going round and round is that I don't have a clear idea of what flavors of RPM's we need and what files should be in each. Nor where they should go when installed. I apologize in advance for these ramblings below, but maybe seeing them in print will help clarify things. If this doesn't make sense to you, feel free to skip the rest of this email. >From what I can glean from kwade's postings, we should have: 1) A development RPM that's just a copy of everything that's in the CVS tree for a document. I guess this would be the foo.src.rpm package. Installing this RPM would instantiate the files in /usr/src/redhat or ~/rpm, I guess. 2) A gnome help package with just the XML files, figures, callouts, and the like. I guess this would be a foo.noarch.rpm, similar to the RPM's your Makefile changes produce. Installing this RPM would populate the /usr/share/fedora/doc tree and drop some desktop files in place, too. Generating this RPM would actually explode into separate foo.en.noarch.rpm or foo.zn_CH.noarch.rpm packages depending on the ${LANGUAGES} make(1) macro. Or should all translations stay in a single package with per-locale subdirs? 3) An RPM containing the formatted HTML/PDF content, suitable for browsing and printing. What could this be called? foo.i386.rpm? I don't know of a good (standard) place for these files to go at install time. I've thought about methods to generate the various RPM components, such as the .spec files. I found a neat program that lets a shell script extract arbitrary content from an XML document: http://xmlstar.sourceforge.net/ and have gotten it working on FC4. Built an RPM for it so we can add it to Fedora Extras if we decide to keep it. Anyway, using this program I can write a shell script that will parse the title, author info and revision data from the XML document itself or from a separate package description file. Built a DTD for that description file, too. I ran an experiment where I used the CVS ChangeLog to derive the RPM %changelog content, but then realized that the RPM changelog needed to reflect the RPM-specific changes, not the day-to-day editing for the document itself. OK, I added the RPM change information (not the ChangeLog, but manual change data) to the XML package description file and then parsed that. However, it then struck me that if we have to keep the RPM package description info in a separate file and maintain it manually, then why not just fill out the .spec file directly and have done with it. Anyone have a clear enough understanding of what the RPM packaging should be that they can explain it to a total dunce like me? Perhaps you could take one of the more complete documents, such as the release notes, and show me the directory hierarchy produced by installing each of the RPM types I mentioned above. (Or whatever the correct complement of RPM's should be.) If you've gotten this far, I'm impressed ;-) Thanks! Cheers -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From nman64 at n-man.com Sat Nov 19 06:46:36 2005 From: nman64 at n-man.com (Patrick Barnes) Date: Sat, 19 Nov 2005 00:46:36 -0600 Subject: Advise on Fedora RPM's In-Reply-To: <20051118235711.50ea5f96.Tommy.Reynolds@MegaCoder.com> References: <20051118235711.50ea5f96.Tommy.Reynolds@MegaCoder.com> Message-ID: <437ECA4C.8000106@n-man.com> Tommy Reynolds wrote: > Hello Paul, kwade, list, et. al. > > I've been struggling with FDP RPM's for a couple of weeks and they > are not coming together. I think the reason I'm going round and > round is that I don't have a clear idea of what flavors of RPM's we > need and what files should be in each. Nor where they should go when > installed. > > I apologize in advance for these ramblings below, but maybe seeing > them in print will help clarify things. If this doesn't make sense > to you, feel free to skip the rest of this email. > > >From what I can glean from kwade's postings, we should have: > > 1) A development RPM that's just a copy of everything that's in the > CVS tree for a document. I guess this would be the foo.src.rpm > package. Installing this RPM would instantiate the files in > /usr/src/redhat or ~/rpm, I guess. > +1 on the package type. Location would be /usr/src/redhat. The full name might be something like 'fedora-doc-install-guide-devel.src.rpm'. > 2) A gnome help package with just the XML files, figures, callouts, > and the like. I guess this would be a foo.noarch.rpm, similar to > the RPM's your Makefile changes produce. Installing this RPM > would populate the /usr/share/fedora/doc tree and drop some > desktop files in place, too. > +1 on this package type. Installation of figures, in order to be shared among formats, might go into a path like '/usr/share/doc/fedora/install-guide/figs' (with a further path [/en] for language-specific items) while the XML files would go to '/usr/share/doc/fedora/install-guide/xml'. The full package name might be something like 'fedora-doc-install-guide.noarch.rpm'. This lacks any format extensions as this would be the standard package to install to access the docs. > Generating this RPM would actually explode into separate > foo.en.noarch.rpm or foo.zn_CH.noarch.rpm packages depending on > the ${LANGUAGES} make(1) macro. Or should all translations stay > in a single package with per-locale subdirs? > I think we should definitely have these broken down into different packages by locale. Upon installation, the XML documents should go into eg. /usr/share/doc/fedora/install-guide/xml/en. > 3) An RPM containing the formatted HTML/PDF content, suitable for > browsing and printing. What could this be called? foo.i386.rpm? > I don't know of a good (standard) place for these files to go at > install time. > These are still architecture-independent, aren't they? Perhaps eg. 'fedora-doc-install-guide-html-en.noarch.rpm'. I know these names might seem long, but they aren't unprecedented and are necessary to distinguish these packages. These would install to paths like /usr/share/doc/fedora/install-guide/html/en. > I've thought about methods to generate the various RPM components, > such as the .spec files. I found a neat program that lets a shell > script extract arbitrary content from an XML document: > > http://xmlstar.sourceforge.net/ > > and have gotten it working on FC4. Built an RPM for it so we can add > it to Fedora Extras if we decide to keep it. Anyway, using this > program I can write a shell script that will parse the title, author > info and revision data from the XML document itself or from a > separate package description file. Built a DTD for that description > file, too. > > I ran an experiment where I used the CVS ChangeLog to derive the RPM > %changelog content, but then realized that the RPM changelog needed > to reflect the RPM-specific changes, not the day-to-day editing for > the document itself. OK, I added the RPM change information (not the > ChangeLog, but manual change data) to the XML package description > file and then parsed that. > > However, it then struck me that if we have to keep the RPM > package description info in a separate file and maintain it manually, > then why not just fill out the .spec file directly and have done with > it. > I think that would largely be a matter of tastes. I'll pass on advising on this one. > Anyone have a clear enough understanding of what the RPM packaging > should be that they can explain it to a total dunce like me? Perhaps > you could take one of the more complete documents, such as the > release notes, and show me the directory hierarchy produced by > installing each of the RPM types I mentioned above. (Or whatever the > correct complement of RPM's should be.) > > If you've gotten this far, I'm impressed ;-) Thanks! > > Cheers > There's my $0.02. -- Patrick "The N-Man" Barnes nman64 at n-man.com www.n-man.com -- -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From stuart at elsn.org Sat Nov 19 11:10:44 2005 From: stuart at elsn.org (Stuart Ellis) Date: Sat, 19 Nov 2005 11:10:44 +0000 Subject: Proposal for document entities In-Reply-To: <1132346075.5672.23.camel@localhost.localdomain> References: <1132346075.5672.23.camel@localhost.localdomain> Message-ID: <1132398644.2870.4.camel@localhost.localdomain> On Fri, 2005-11-18 at 15:34 -0500, Paul W. Frields wrote: > Currently, our documents have entities like this (please pardon the MUA > mangling): > > "../docs-common/common/fedora-entities-en.ent"> > %FEDORA-ENTITIES-EN; > > > > I would like to see this instead as a standard: > > > > > > Another +1. I'd prefer "DOC*", over "BOOK*" for these, just because documents may all not be Guides, and most of the end-products are on-line, rather than specifically for printing. -- Stuart Ellis stuart at elsn.org Fedora Documentation Project: http://fedora.redhat.com/projects/docs/ GPG key ID: 7098ABEA GPG key fingerprint: 68B0 E291 FB19 C845 E60E 9569 292E E365 7098 ABEA -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From ivazquez at ivazquez.net Sat Nov 19 12:35:09 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Sat, 19 Nov 2005 07:35:09 -0500 Subject: Advise on Fedora RPM's In-Reply-To: <20051118235711.50ea5f96.Tommy.Reynolds@MegaCoder.com> References: <20051118235711.50ea5f96.Tommy.Reynolds@MegaCoder.com> Message-ID: <1132403709.1574.13.camel@ignacio.lan> On Fri, 2005-11-18 at 23:57 -0600, Tommy Reynolds wrote: > 1) A development RPM that's just a copy of everything that's in the > CVS tree for a document. I guess this would be the foo.src.rpm > package. Installing this RPM would instantiate the files in > /usr/src/redhat or ~/rpm, I guess. An export of the CVS tree, yes. > 2) A gnome help package with just the XML files, figures, callouts, > and the like. I guess this would be a foo.noarch.rpm, similar to > the RPM's your Makefile changes produce. Installing this RPM > would populate the /usr/share/fedora/doc tree and drop some > desktop files in place, too. Sounds good. > Generating this RPM would actually explode into separate > foo.en.noarch.rpm or foo.zn_CH.noarch.rpm packages depending on > the ${LANGUAGES} make(1) macro. Or should all translations stay > in a single package with per-locale subdirs? The latter. It doesn't matter if the SRPM ends up being hundreds of megabytes as one shouldn't need it other than in exceptional circumstances. > 3) An RPM containing the formatted HTML/PDF content, suitable for > browsing and printing. What could this be called? foo.i386.rpm? > I don't know of a good (standard) place for these files to go at > install time. HTML and PDF are arch-independent so they would be noarch. And they should go in the standard doc location, i.e., /usr/share/doc. > I've thought about methods to generate the various RPM components, > such as the .spec files. I found a neat program that lets a shell > script extract arbitrary content from an XML document: > > http://xmlstar.sourceforge.net/ > > and have gotten it working on FC4. Built an RPM for it so we can add > it to Fedora Extras if we decide to keep it. https://www.redhat.com/archives/fedora-extras-list/2005-July/msg00591.html The thread explains why it's not in yet. Summary: ambiguous command name. > Anyone have a clear enough understanding of what the RPM packaging > should be that they can explain it to a total dunce like me? Perhaps > you could take one of the more complete documents, such as the > release notes, and show me the directory hierarchy produced by > installing each of the RPM types I mentioned above. (Or whatever the > correct complement of RPM's should be.) If you can walk me through handling the stuff in CVS, possibly in #fedora-docs, then I can take a look at it. -- Ignacio Vazquez-Abrams http://fedora.ivazquez.net/ gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From stickster at gmail.com Sat Nov 19 15:29:17 2005 From: stickster at gmail.com (Paul W. Frields) Date: Sat, 19 Nov 2005 10:29:17 -0500 Subject: Proposal for document entities In-Reply-To: <1132398644.2870.4.camel@localhost.localdomain> References: <1132346075.5672.23.camel@localhost.localdomain> <1132398644.2870.4.camel@localhost.localdomain> Message-ID: <1132414157.3578.0.camel@localhost.localdomain> On Sat, 2005-11-19 at 11:10 +0000, Stuart Ellis wrote: > On Fri, 2005-11-18 at 15:34 -0500, Paul W. Frields wrote: > > I would like to see this instead as a standard: > > > > > > > > > > > > > > Another +1. > > I'd prefer "DOC*", over "BOOK*" for these, just because documents may > all not be Guides, and most of the end-products are on-line, rather than > specifically for printing. Excellent point. -- Paul W. Frields, RHCE http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 Fedora Documentation Project: http://fedora.redhat.com/projects/docs/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From kwade at redhat.com Sat Nov 19 17:38:19 2005 From: kwade at redhat.com (Karsten Wade) Date: Sat, 19 Nov 2005 09:38:19 -0800 Subject: wow, release notes Message-ID: <1132421900.3572.245.camel@erato.phig.org> This morning I came in to run the final build of the test1 release notes. It is beautiful. Five languages in one CVS with one Makefile to rule them all. And this was done the hard way! Imagine when we integrate the documentation XML into the same workbench system that is used for translating the strings in Fedora applications. Thanks to all involved for your help. I'll send a proper announcement and appreciation to the test list following the release of test1. You'll notice that the content is the same across the original English and the translated release notes (Italian, Japanese, Russian, and Simplified Chinese). To do this, we had to freeze the content and give it time to be translated. An updated release notes with content that is currently in the Wiki *will be* available when test1 is released. Once I have tagged this content in CVS, it will freeze again for a while. If anyone wants to update their translation, you can do so during that freeze. I will see that the updated version is posted to http://fedora.redhat.com/docs/release-notes/ as soon as possible. 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 Content Services Fedora Documentation Project http://www.redhat.com/docs http://fedoraproject.org/wiki/DocsProject -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From nman64 at n-man.com Sat Nov 19 18:42:05 2005 From: nman64 at n-man.com (Patrick Barnes) Date: Sat, 19 Nov 2005 12:42:05 -0600 Subject: Advise on Fedora RPM's In-Reply-To: <1132403709.1574.13.camel@ignacio.lan> References: <20051118235711.50ea5f96.Tommy.Reynolds@MegaCoder.com> <1132403709.1574.13.camel@ignacio.lan> Message-ID: <437F71FD.9020101@n-man.com> Ignacio Vazquez-Abrams wrote: > On Fri, 2005-11-18 at 23:57 -0600, Tommy Reynolds wrote: > > >> Generating this RPM would actually explode into separate >> foo.en.noarch.rpm or foo.zn_CH.noarch.rpm packages depending on >> the ${LANGUAGES} make(1) macro. Or should all translations stay >> in a single package with per-locale subdirs? >> > > The latter. It doesn't matter if the SRPM ends up being hundreds of > megabytes as one shouldn't need it other than in exceptional > circumstances. > > The SRPM can contain all languages and be as large as it needs to be, but the RPMs built from it should be broken down into the different locales. -- Patrick "The N-Man" Barnes nman64 at n-man.com www.n-man.com -- -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From kwade at redhat.com Sat Nov 19 20:36:44 2005 From: kwade at redhat.com (Karsten Wade) Date: Sat, 19 Nov 2005 12:36:44 -0800 Subject: [Fwd: Fedora general improvements input survey invitation] Message-ID: <1132432604.3572.283.camel@erato.phig.org> For those who might not have seen this ... Please participate. Surveys like this can be very valuable. -------- Forwarded Message -------- > From: Tim Burke > Reply-To: Development discussions related to Fedora Core devel-list at redhat.com> > To: fedora-devel-list at redhat.com, fedora-test-list at redhat.com, fedora- > extras-list at redhat.com, fedora-maintainers at redhat.com > Subject: Fedora general improvements input survey invitation > Date: Thu, 17 Nov 2005 21:23:25 -0500 > The Fedora Core team invites you to participate in a survey to help > identify the major ways in which Fedora can be improved for the benefit > of the community. The survey consists of 10 questions involving Fedora > Core and Fedora Extras. We are greatly interested in your views and > hope you can share your thoughts with us. The survey is available at: > > http://www.keysurvey.com/survey/85928/1078/ > > The survey is enabled now and will remain open for input until > Wednesday, November 30. > > Thanks in advance for helping us to make Fedora better for all > involved. Upon conclusion of the survey, a summary of the results will > be shared. > > -- Karsten Wade, RHCE * Sr. Tech Writer * http://people.redhat.com/kwade/ gpg fingerprint: 2680 DBFD D968 3141 0115 5F1B D992 0E06 AD0E 0C41 Content Services Fedora Documentation Project http://www.redhat.com/docs http://fedoraproject.org/wiki/DocsProject -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From ivazquez at ivazquez.net Sun Nov 20 00:40:01 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Sat, 19 Nov 2005 19:40:01 -0500 Subject: Advise on Fedora RPM's In-Reply-To: <437F71FD.9020101@n-man.com> References: <20051118235711.50ea5f96.Tommy.Reynolds@MegaCoder.com> <1132403709.1574.13.camel@ignacio.lan> <437F71FD.9020101@n-man.com> Message-ID: <1132447201.1574.14.camel@ignacio.lan> On Sat, 2005-11-19 at 12:42 -0600, Patrick Barnes wrote: > Ignacio Vazquez-Abrams wrote: > > On Fri, 2005-11-18 at 23:57 -0600, Tommy Reynolds wrote: > > > > > >> Generating this RPM would actually explode into separate > >> foo.en.noarch.rpm or foo.zn_CH.noarch.rpm packages depending on > >> the ${LANGUAGES} make(1) macro. Or should all translations stay > >> in a single package with per-locale subdirs? > >> > > > > The latter. It doesn't matter if the SRPM ends up being hundreds of > > megabytes as one shouldn't need it other than in exceptional > > circumstances. > > > > > > The SRPM can contain all languages and be as large as it needs to be, > but the RPMs built from it should be broken down into the different locales. Right, I misread the question, sorry. -- Ignacio Vazquez-Abrams http://fedora.ivazquez.net/ gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From stickster at gmail.com Sun Nov 20 00:57:29 2005 From: stickster at gmail.com (Paul W. Frields) Date: Sat, 19 Nov 2005 19:57:29 -0500 Subject: Advise on Fedora RPM's In-Reply-To: <20051118235711.50ea5f96.Tommy.Reynolds@MegaCoder.com> References: <20051118235711.50ea5f96.Tommy.Reynolds@MegaCoder.com> Message-ID: <1132448250.9579.14.camel@localhost.localdomain> On Fri, 2005-11-18 at 23:57 -0600, Tommy Reynolds wrote: > Hello Paul, kwade, list, et. al. > > I've been struggling with FDP RPM's for a couple of weeks and they > are not coming together. I think the reason I'm going round and > round is that I don't have a clear idea of what flavors of RPM's we > need and what files should be in each. Nor where they should go when > installed. > > I apologize in advance for these ramblings below, but maybe seeing > them in print will help clarify things. If this doesn't make sense > to you, feel free to skip the rest of this email. > > >From what I can glean from kwade's postings, we should have: > > 1) A development RPM that's just a copy of everything that's in the > CVS tree for a document. I guess this would be the foo.src.rpm > package. Installing this RPM would instantiate the files in > /usr/src/redhat or ~/rpm, I guess. You're correct; that's how SRPMs work in fact. In my testing scheme the SRPM consists of a tarball of the XML source, the .spec file created from the common .spec.in, the .desktop file created from the common .desktop.in, and the .omf file created from the common .omf.in. > 2) A gnome help package with just the XML files, figures, callouts, > and the like. I guess this would be a foo.noarch.rpm, similar to > the RPM's your Makefile changes produce. Installing this RPM > would populate the /usr/share/fedora/doc tree and drop some > desktop files in place, too. Correct, along with the OMF for scrollkeeper, but see below. I think this file should also contain HTML suitable for (and featuring prominently in) khelpcenter, as the XML and OMF are for yelp. > Generating this RPM would actually explode into separate > foo.en.noarch.rpm or foo.zn_CH.noarch.rpm packages depending on > the ${LANGUAGES} make(1) macro. Or should all translations stay > in a single package with per-locale subdirs? This is an interesting question about namespace... I think it might make sense for the RPMs to be named "fedora-doc-en-foo-tutorial" since that would allow people to do "yum install fedora-doc-en\*", which is much more likely to be helpful than "yum install fedora-doc-\*" which would give them every doc in every language. > 3) An RPM containing the formatted HTML/PDF content, suitable for > browsing and printing. What could this be called? foo.i386.rpm? > I don't know of a good (standard) place for these files to go at > install time. In my opinion these should all be in the .noarch.rpm. Definitely not .i386 at any rate since they are not arch-specific. > I've thought about methods to generate the various RPM components, > such as the .spec files. I found a neat program that lets a shell > script extract arbitrary content from an XML document: > > http://xmlstar.sourceforge.net/ > > and have gotten it working on FC4. Built an RPM for it so we can add > it to Fedora Extras if we decide to keep it. Anyway, using this > program I can write a shell script that will parse the title, author > info and revision data from the XML document itself or from a > separate package description file. Built a DTD for that description > file, too. I was trying to do this with a Python script, but I don't know enough about Python, or XML programming therein, to do more than the simplest things. One reason for my proposals on better entities was to make simple grep/sed stuff work nicely in the Makefile. > I ran an experiment where I used the CVS ChangeLog to derive the RPM > %changelog content, but then realized that the RPM changelog needed > to reflect the RPM-specific changes, not the day-to-day editing for > the document itself. OK, I added the RPM change information (not the > ChangeLog, but manual change data) to the XML package description > file and then parsed that. > > However, it then struck me that if we have to keep the RPM > package description info in a separate file and maintain it manually, > then why not just fill out the .spec file directly and have done with > it. Now you're starting to feel my pain. ;-) I think the cleanest way to handle this would be a ChangeLog file in the doc's directory which would simply be grafted onto the .spec during munging. I think keeping the majority of the .spec work in a single common file, and "make"-ing it into the proper form at RPM generation time, is still the Right Thing To Do. It means that changes in Fedora packaging standards, yelp, khelpcenter, etc., etc. can be communicated to each doc more easily in the future. > Anyone have a clear enough understanding of what the RPM packaging > should be that they can explain it to a total dunce like me? Perhaps > you could take one of the more complete documents, such as the > release notes, and show me the directory hierarchy produced by > installing each of the RPM types I mentioned above. (Or whatever the > correct complement of RPM's should be.) Maybe I should be committing more of my work to CVS to expose the bruises thus far... :-D > If you've gotten this far, I'm impressed ;-) Thanks! -- Paul W. Frields, RHCE http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 Fedora Documentation Project: http://fedora.redhat.com/projects/docs/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From stickster at gmail.com Sun Nov 20 16:09:06 2005 From: stickster at gmail.com (Paul W. Frields) Date: Sun, 20 Nov 2005 11:09:06 -0500 Subject: Advise on Fedora RPM's In-Reply-To: <1132448250.9579.14.camel@localhost.localdomain> References: <20051118235711.50ea5f96.Tommy.Reynolds@MegaCoder.com> <1132448250.9579.14.camel@localhost.localdomain> Message-ID: <1132502946.21435.3.camel@localhost.localdomain> OK, I spent a few hours this morning banging my head against the problem (again), trying to mentally clarify additional issues. There may be significant opinion mixed with fact here, be wary... Maybe this is just more food for thought? 1. We should have separate .noarch.rpm ("binary" RPM) packages for each language. Although the scrollkeeper/yelp and khelpcenter parts are mostly XML and HTML files that simply don't take up much space, the screenshots for things like the Installation Guide and other upcoming works are going to drastically increase the size of these packages. No reason to burden all users with i18n they can't use. The easiest way to do this is with subpackages in the .spec.in.common, but that puts the namespacing as "fedora-doc-docname-en-0.14" instead of "fedora-doc-en-docname-0.14". Does it put a significant burden on the user if "installing all docs for my LANG" means "yum install fedora-doc-\*-LANG" instead of "yum install fedora-doc-LANG-\*"? Should we figure out how to do this with yum groups instead, having a "Documentation/English," "Documentation/Italian," etc.? Is such a thing possible while *NOT* putting a burden on Core development to support this confusion? 2. To a significant extent, SRPMs will have duplicative content with the RPMs; this is unavoidable and not really a problem /per se/. There shouldn't be any HTML in the SRPMs, just the DocBook-XML originals, screenshots, etc. 3. I've done the RPM building process about three different ways thus far, none of them great, and each of them confusing in a unique way. I am going to try to flowchart something out to make the process a little clearer to myself before I try again. I keep getting hung up on when to set up i18n templates and when not. What makes this challenging is that in order to make the process work, the OMFs, the specfile, and the various tarballs must be coordinated in a pretty interesting little ballet. Back to the grindstone... -- Paul W. Frields, RHCE http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 Fedora Documentation Project: http://fedora.redhat.com/projects/docs/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From Tommy.Reynolds at MegaCoder.com Sun Nov 20 17:21:07 2005 From: Tommy.Reynolds at MegaCoder.com (Tommy Reynolds) Date: Sun, 20 Nov 2005 11:21:07 -0600 Subject: Advise on Fedora RPM's In-Reply-To: <437ECA4C.8000106@n-man.com> References: <20051118235711.50ea5f96.Tommy.Reynolds@MegaCoder.com> <437ECA4C.8000106@n-man.com> Message-ID: <20051120112107.cc7b9ba5.Tommy.Reynolds@MegaCoder.com> Uttered Patrick Barnes , spake thus: > +1 on the package type. Location would be /usr/src/redhat. The full > name might be something like 'fedora-doc-install-guide-devel.src.rpm'. Dude! Thanks for the magic word "-devel"! I don't know why I didn't think of that from the first. That was the missing piece, at least for now ;-) I'm thinking of these RPM's: -.src.rpm Raw CVS dump, w/o CVS subdirs -devel-.noarch.rpm Everything in CVS w/corrected paths --.noarch.rpm XML, XSL, images and desktop files The .src RPM is for archiving purposes, I guess. The -devel RPM is for folk wishing to use the FDP infrastructure but not using the CVS facilities. I'm not sure where the -devel files should go, but maybe a "pkg-config" crutch would fix this. The RPM would hold the XML infrastructure to allow desktop tools like yelp to work. Hmm... I'll think about this a bit more. Thanks! -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From stickster at gmail.com Sun Nov 20 18:02:39 2005 From: stickster at gmail.com (Paul W. Frields) Date: Sun, 20 Nov 2005 13:02:39 -0500 Subject: Advise on Fedora RPM's In-Reply-To: <20051120112107.cc7b9ba5.Tommy.Reynolds@MegaCoder.com> References: <20051118235711.50ea5f96.Tommy.Reynolds@MegaCoder.com> <437ECA4C.8000106@n-man.com> <20051120112107.cc7b9ba5.Tommy.Reynolds@MegaCoder.com> Message-ID: <1132509759.23150.18.camel@localhost.localdomain> On Sun, 2005-11-20 at 11:21 -0600, Tommy Reynolds wrote: > Uttered Patrick Barnes , spake thus: > > > +1 on the package type. Location would be /usr/src/redhat. The full > > name might be something like 'fedora-doc-install-guide-devel.src.rpm'. > > Dude! Thanks for the magic word "-devel"! I don't know why I didn't > think of that from the first. That was the missing piece, at least > for now ;-) > > I'm thinking of these RPM's: > > -.src.rpm Raw CVS dump, w/o CVS subdirs > -devel-.noarch.rpm Everything in CVS w/corrected paths > --.noarch.rpm XML, XSL, images and desktop files > > The .src RPM is for archiving purposes, I guess. Umm... Methinks this is kind of missing the point of the .src.rpm. That is the source for building; no -devel package containing more of the same is needed, certainly not on a per-doc basis (see below). The original DocBook XML source is in the .src.rpm, probably duplicated again in the normal .noarch.rpm because yelp uses DocBook XML directly. Why triplicate this? The only thing that should be needed for building is "fedora-doc-common-.noarch.rpm" (or just call it "fedora-doc-devel-.noarch.rpm"), which would contain user scripts and helpers equivalent to what's in CVS (probably just relocating, as mentioned above). Doesn't matter whether its "-common" or "-devel," as long as it fulfills certain criteria: - Puts common entities, images, stylesheets and so forth in a place where they are available not just for the user building docs, but also where they can be accessed for use in yelp, khelpcenter, etc. - Includes scripts that allow documents to be built from XML source already written to /usr/share/fedora/doc/ (or wherever is referenced in /usr/share/omf// as part of fedora-doc--.noarch.rpm - Proper Requires: on any stuff we're currently using (e.g. xmlformat) that needs to also be in Extras or Core If we need to change scripts, Makefiles, and such to make them universally adaptable not just in CVS but in their packaged form, let's do that. Better that than having to maintain two sets of scripts and build environments. Is there a good reason *not* to do so (you know, other than "gee, that sounds hard")? > The -devel RPM is for folk wishing to use the FDP infrastructure but > not using the CVS facilities. I'm not sure where the -devel files > should go, but maybe a "pkg-config" crutch would fix this. There's really no reason they couldn't live in /usr/share/fedora/ somwhere, which is the right place for them given the namespacing the rest of the Fedora Project is using. > The RPM would hold the XML infrastructure to allow desktop > tools like yelp to work. Right, which is why a separate -devel per doc is probably not that useful. With a proper extra doc on "How to Build Docs," itself included in yelp/khelpcenter as part of the fedora-doc-[common|devel] package, people should be able to "fedoradoc-make" a doc, or something like that, to build things we've included, or their own docs. Perhaps such a helper would also include relevant checks for project standards. > Hmm... I'll think about this a bit more. > > Thanks! I realized that having a RPM implies we should have separate .desktop files for each package. Just a note for the archive for later... -- Paul W. Frields, RHCE http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 Fedora Documentation Project: http://fedora.redhat.com/projects/docs/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From Tommy.Reynolds at MegaCoder.com Sun Nov 20 20:14:06 2005 From: Tommy.Reynolds at MegaCoder.com (Tommy Reynolds) Date: Sun, 20 Nov 2005 14:14:06 -0600 Subject: Advise on Fedora RPM's In-Reply-To: <1132509759.23150.18.camel@localhost.localdomain> References: <20051118235711.50ea5f96.Tommy.Reynolds@MegaCoder.com> <437ECA4C.8000106@n-man.com> <20051120112107.cc7b9ba5.Tommy.Reynolds@MegaCoder.com> <1132509759.23150.18.camel@localhost.localdomain> Message-ID: <20051120141406.359f9584.Tommy.Reynolds@MegaCoder.com> Uttered "Paul W. Frields" , spake thus: > On Sun, 2005-11-20 at 11:21 -0600, Tommy Reynolds wrote: > > Uttered Patrick Barnes , spake thus: > > > +1 on the package type. Location would be /usr/src/redhat. The full > > > name might be something like 'fedora-doc-install-guide-devel.src.rpm'. > > I'm thinking of these RPM's: > > -.src.rpm Raw CVS dump, w/o CVS subdirs > > -devel-.noarch.rpm Everything in CVS w/corrected paths > > --.noarch.rpm XML, XSL, images and desktop files > > The .src RPM is for archiving purposes, I guess. > Umm... Methinks this is kind of missing the point of the .src.rpm. > Why triplicate this? Ouch. OK, I see the light. > The only thing that should be needed for building is > "fedora-doc-common-.noarch.rpm" which would contain user > scripts and helpers equivalent to what's in CVS (probably just > relocating, as mentioned above). Recently I put the line "sinclude Make.paths" into "Makefile.common" to deal with the relocations for RPM installation. The idea is that the docs-common package is a prerequisite to everything else. As all other packages get installed, a "%post" line does something like this: %post echo $(dirname $(rpm -ql docs-common | grep Makefile.common)) \ >/path/to/example-tutorial/Make.paths and then: %pre rm -f /path/to/example-tutorial/Make.paths to close the loop. I'll probably need to use a pkg-config crutch because we'll still need to correct the paths embedded in the XML, XSL and Makefiles. > Is there a good reason *not* to do so (you know, other than "gee, > that sounds hard")? Not as long as you are doing the hard part ;-) > > The -devel RPM is for folk wishing to use the FDP infrastructure but > > not using the CVS facilities. I'm not sure where the -devel files > > should go, but maybe a "pkg-config" crutch would fix this. > There's really no reason they couldn't live in /usr/share/fedora/ > somwhere, which is the right place for them given the namespacing the > rest of the Fedora Project is using. Fine with me. > > The RPM would hold the XML infrastructure to allow desktop > > tools like yelp to work. > Right, which is why a separate -devel per doc is probably not that > useful. With a proper extra doc on "How to Build Docs," itself included > in yelp/khelpcenter as part of the fedora-doc-[common|devel] package, > people should be able to "fedoradoc-make" a doc, or something like that, > to build things we've included, or their own docs. Perhaps such a > helper would also include relevant checks for project standards. Yeah, that would work. The docs-common package could drop stuff in a "/usr/share/fedora/build" directory or the like. > I realized that having a RPM implies we should have separate > .desktop files for each package. Just a note for the archive for > later... Er, no. The .desktop files allow constructs like "Name[de]=Handheld PDA" and "Name[es]=PDA de mano" and avoid all this cruft. This argues for either a real .desktop file that translators maintain or the XML-style build info file I mentioned earlier. ==[/home/reynolds/src/f/fedora-docs/docs-common/rpm-info.dtd]== ==[/home/reynolds/src/f/fedora-docs/docs-common/rpm-info.xml]== Example Tutorial This is quite a feat. Beispeil Tutorial Ist idiotien
Just noodling with the files...
 ==[END]== What 'cha think? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From stickster at gmail.com Sun Nov 20 21:09:58 2005 From: stickster at gmail.com (Paul W. Frields) Date: Sun, 20 Nov 2005 16:09:58 -0500 Subject: Advise on Fedora RPM's In-Reply-To: <20051120141406.359f9584.Tommy.Reynolds@MegaCoder.com> References: <20051118235711.50ea5f96.Tommy.Reynolds@MegaCoder.com> <437ECA4C.8000106@n-man.com> <20051120112107.cc7b9ba5.Tommy.Reynolds@MegaCoder.com> <1132509759.23150.18.camel@localhost.localdomain> <20051120141406.359f9584.Tommy.Reynolds@MegaCoder.com> Message-ID: <1132520998.23150.34.camel@localhost.localdomain> On Sun, 2005-11-20 at 14:14 -0600, Tommy Reynolds wrote: > Uttered "Paul W. Frields" , spake thus: > > The only thing that should be needed for building is > > "fedora-doc-common-.noarch.rpm" which would contain user > > scripts and helpers equivalent to what's in CVS (probably just > > relocating, as mentioned above). > > Recently I put the line "sinclude Make.paths" into "Makefile.common" > to deal with the relocations for RPM installation. The idea is that > the docs-common package is a prerequisite to everything else. As all > other packages get installed, a "%post" line does something like this: > > %post > echo $(dirname $(rpm -ql docs-common | grep Makefile.common)) \ > >/path/to/example-tutorial/Make.paths > > and then: > > %pre > rm -f /path/to/example-tutorial/Make.paths > > to close the loop. I'll probably need to use a pkg-config crutch > because we'll still need to correct the paths embedded in the XML, > XSL and Makefiles. Just in the FC/FE spirit of "don't use %pre/%post unless you have to," could the Make.paths file simply be built at RPM building time? I was under the impression that playing around with RPM queries during an RPM installation/erase process is not a desirable thing. I think I understand why we want the file, I'm just guessing we can probably build the file during "make rpm" and simply list it in the %files per normal. > > Is there a good reason *not* to do so (you know, other than "gee, > > that sounds hard")? > > Not as long as you are doing the hard part ;-) And *that* is why I don't live in a commune. (OK, that's not the only reason why.) Q.v. etymology for community, no? ;-D > > > The -devel RPM is for folk wishing to use the FDP infrastructure but > > > not using the CVS facilities. I'm not sure where the -devel files > > > should go, but maybe a "pkg-config" crutch would fix this. > > There's really no reason they couldn't live in /usr/share/fedora/ > > somwhere, which is the right place for them given the namespacing the > > rest of the Fedora Project is using. > > Fine with me. Ah, sweet consensus! > > > The RPM would hold the XML infrastructure to allow desktop > > > tools like yelp to work. > > Right, which is why a separate -devel per doc is probably not that > > useful. With a proper extra doc on "How to Build Docs," itself included > > in yelp/khelpcenter as part of the fedora-doc-[common|devel] package, > > people should be able to "fedoradoc-make" a doc, or something like that, > > to build things we've included, or their own docs. Perhaps such a > > helper would also include relevant checks for project standards. > > Yeah, that would work. The docs-common package could drop stuff in a > "/usr/share/fedora/build" directory or the like. Disco! > > I realized that having a RPM implies we should have separate > > .desktop files for each package. Just a note for the archive for > > later... > > Er, no. The .desktop files allow constructs like "Name[de]=Handheld > PDA" and "Name[es]=PDA de mano" and avoid all this cruft. This > argues for either a real .desktop file that translators maintain or > the XML-style build info file I mentioned earlier. > > ==[/home/reynolds/src/f/fedora-docs/docs-common/rpm-info.dtd]== > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ==[/home/reynolds/src/f/fedora-docs/docs-common/rpm-info.xml]== > > > > > > > > > > Example Tutorial > This is quite a feat. > > > Beispeil Tutorial > Ist idiotien > > > > > > >
Just noodling with the files...
> > > > > ==[END]== > > What 'cha think? That's totally bitchin AFAIC. But the point I was trying to make is that if there is a separate .noarch.rpm for each , each one needs its own .desktop file. The alternatives AIUI are: - a foo-.desktop file in a single foo-.noarch.rpm RPM will have all the translations for the name of the shortcut, but will lead to a single language version of the document, which confuses the user, who expects to see the doc for his language come up when he clicks on the menu item - an identical foo.desktop file for every foo-.noarch.rpm, meaning you get yucky RPM conflicts So to me, the best solution is a foo-.desktop file that contains only -specific name, etc. They could still come out of the (totally bitchin) XML but would act as expected. The shortcuts would read in the native language, so I could install the foo-de.noarch.rpm and click on the "Foo (Deutsch)" menu item to read the German version, supposedly to check the translation for errors if I'm bilingual. Am I making any sense? All this is independent of the bitchin-ness of your XML stuff, which will be useful no matter which way the .desktop thing goes. -- Paul W. Frields, RHCE http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 Fedora Documentation Project: http://fedora.redhat.com/projects/docs/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From Tommy.Reynolds at MegaCoder.com Sun Nov 20 17:53:39 2005 From: Tommy.Reynolds at MegaCoder.com (Tommy Reynolds) Date: Sun, 20 Nov 2005 11:53:39 -0600 Subject: Advise on Fedora RPM's In-Reply-To: <1132502946.21435.3.camel@localhost.localdomain> References: <20051118235711.50ea5f96.Tommy.Reynolds@MegaCoder.com> <1132448250.9579.14.camel@localhost.localdomain> <1132502946.21435.3.camel@localhost.localdomain> Message-ID: <20051120115339.dabb9c9d.Tommy.Reynolds@MegaCoder.com> Uttered "Paul W. Frields" , spake thus: > 1. We should have separate .noarch.rpm ("binary" RPM) packages for each > language. Yup, I agree. See my reply to the nman's post mentioning that wonderful phrase "-devel". > The easiest way to do this is with subpackages in the .spec.in.common, > but that puts the namespacing as "fedora-doc-docname-en-0.14" instead of > "fedora-doc-en-docname-0.14". Well, the "fedora-doc-docname-en" form is what seemed most obvious to me from the beginning. > Does it put a significant burden on the user if "installing all > docs for my LANG" means "yum install fedora-doc-\*-LANG" instead of > "yum install fedora-doc-LANG-\*"? Should we figure out how to do > this with yum groups instead, having a "Documentation/English," > "Documentation/Italian," etc.? Is such a thing possible while > *NOT* putting a burden on Core development to support this > confusion? If folk need type the silly wildcard, then it should not make much difference where it goes. I can't find precedent for this approach, though. Can you point to a package set using the "foo--*" template? About the "Documentation/" groups, I don't know. I'm intrigued though, so I'll look at the anaconda stuff to see what needs to be done. > 2. To a significant extent, SRPMs will have duplicative content with > the RPMs; this is unavoidable and not really a problem /per se/. There > shouldn't be any HTML in the SRPMs, just the DocBook-XML originals, > screenshots, etc. Agree. > 3. I've done the RPM building process about three different ways thus > far, none of them great, and each of them confusing in a unique way. Yeah. Think twice, code once ;-) Perhaps a question will help focus the discussion: Who builds / maintains the RPM overhead files, such as the OMF and SPEC files? Granted there are significant portions of each we could treat as boilerplate, some content (such as translations of the package name) must come from the translators themselves. So, my question is really "originate or derive?" If we originate, it should not be a burden for the first doc author to copy a prototype "foo.spec" from "docs-common/packaging" and edit for the package name, description and to maintain the %changelog. Translators can then just add (or maybe just uncomment) a couple of lines for each translation. With this approach, RPM packaging is much simpler. On the other hand, if we derive, then authors and translators will still need to supply the localized doc names and descriptions. We should be able to derive most of the stuff from the XML-format OMF file, given a suitable XML tool like the "xmlstar*" program I found. Have the author team edit the OMF file and then pick stuff out of that. (Question: is there a DTD for the OMF file?) I don't consider having the author team maintain one overhead file for RPM generation much of a burden. Let's agree on what we want to do before everyone roars off and invents the wheel. Of course, we'll need a bit of trial and error before we decide what it is that we want to do... Cheers! * [footnote] Someone pointed out that the Fedora Extras folk have been discussing the xmlstar tool but so far have avoided in because of the "ambiguous package name". Even its author uses at least three different names for it on the web pages. With the power of an RPM patch file, we can include the tool using any name we like. With proper attribution in the SPEC file, we can name it anything we like. No huhu. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From stickster at gmail.com Sun Nov 20 22:21:34 2005 From: stickster at gmail.com (Paul W. Frields) Date: Sun, 20 Nov 2005 17:21:34 -0500 Subject: Advise on Fedora RPM's In-Reply-To: <20051120115339.dabb9c9d.Tommy.Reynolds@MegaCoder.com> References: <20051118235711.50ea5f96.Tommy.Reynolds@MegaCoder.com> <1132448250.9579.14.camel@localhost.localdomain> <1132502946.21435.3.camel@localhost.localdomain> <20051120115339.dabb9c9d.Tommy.Reynolds@MegaCoder.com> Message-ID: <1132525294.23150.53.camel@localhost.localdomain> On Sun, 2005-11-20 at 11:53 -0600, Tommy Reynolds wrote: > Uttered "Paul W. Frields" , spake thus: > > The easiest way to do this is with subpackages in the .spec.in.common, > > but that puts the namespacing as "fedora-doc-docname-en-0.14" instead of > > "fedora-doc-en-docname-0.14". > > Well, the "fedora-doc-docname-en" form is what seemed most obvious to > me from the beginning. 'S cool, I can go either way with this. > > Does it put a significant burden on the user if "installing all > > docs for my LANG" means "yum install fedora-doc-\*-LANG" instead of > > "yum install fedora-doc-LANG-\*"? Should we figure out how to do > > this with yum groups instead, having a "Documentation/English," > > "Documentation/Italian," etc.? Is such a thing possible while > > *NOT* putting a burden on Core development to support this > > confusion? > > If folk need type the silly wildcard, then it should not make much > difference where it goes. > > I can't find precedent for this approach, though. Can you point to > a package set using the "foo--*" template? Ahh, yes. See e.g. koffice-langpack-* in Extras I think. I haven't looked at the SRPM yet. > About the "Documentation/" groups, I don't know. I'm intrigued > though, so I'll look at the anaconda stuff to see what needs to be > done. I thought this was underway in Anaconda, but doesn't even that revolve around comps? > > 2. To a significant extent, SRPMs will have duplicative content with > > the RPMs; this is unavoidable and not really a problem /per se/. There > > shouldn't be any HTML in the SRPMs, just the DocBook-XML originals, > > screenshots, etc. > > Agree. > > > 3. I've done the RPM building process about three different ways thus > > far, none of them great, and each of them confusing in a unique way. > > Yeah. Think twice, code once ;-) Actually that proportion was about right. :-D > Perhaps a question will help focus the discussion: Who builds / > maintains the RPM overhead files, such as the OMF and SPEC files? I think we should handle this in docs-common to the greatest possible extent. > Granted there are significant portions of each we could treat as > boilerplate, some content (such as translations of the package name) > must come from the translators themselves. > > So, my question is really "originate or derive?" > > If we originate, it should not be a burden for the first doc author > to copy a prototype "foo.spec" from "docs-common/packaging" and edit > for the package name, description and to maintain the %changelog. > Translators can then just add (or maybe just uncomment) a couple of > lines for each translation. With this approach, RPM packaging is > much simpler. > > On the other hand, if we derive, then authors and translators will > still need to supply the localized doc names and descriptions. We > should be able to derive most of the stuff from the XML-format OMF > file, given a suitable XML tool like the "xmlstar*" program I found. > Have the author team edit the OMF file and then pick stuff out of > that. (Question: is there a DTD for the OMF file?) > > I don't consider having the author team maintain one overhead file for > RPM generation much of a burden. Agreed there. I think it would be cool if we simply required one extra file, an XML one based on the DTD you provided. All authors and translators could update that, and everything needed to press the spec, OMF, .desktop, etc. would come out of that file at build time. > Let's agree on what we want to do before everyone roars off and > invents the wheel. Of course, we'll need a bit of trial and error > before we decide what it is that we want to do... > > Cheers! Agreed. > * [footnote] > Someone pointed out that the Fedora Extras folk have been discussing > the xmlstar tool but so far have avoided in because of the "ambiguous > package name". Even its author uses at least three different names > for it on the web pages. With the power of an RPM patch file, we can > include the tool using any name we like. With proper attribution in > the SPEC file, we can name it anything we like. No huhu. It looks like from the discussion you referenced that the original packager has dropped out of the running. Shall I email him and see if he minds me picking up the package instead? I don't mind patching it and getting it into FE if it will help us move down this road by the time of FC5t2 or t3. -- Paul W. Frields, RHCE http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 Fedora Documentation Project: http://fedora.redhat.com/projects/docs/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From Tommy.Reynolds at MegaCoder.com Mon Nov 21 00:21:57 2005 From: Tommy.Reynolds at MegaCoder.com (Tommy Reynolds) Date: Sun, 20 Nov 2005 18:21:57 -0600 Subject: Advise on Fedora RPM's In-Reply-To: <1132525294.23150.53.camel@localhost.localdomain> References: <20051118235711.50ea5f96.Tommy.Reynolds@MegaCoder.com> <1132448250.9579.14.camel@localhost.localdomain> <1132502946.21435.3.camel@localhost.localdomain> <20051120115339.dabb9c9d.Tommy.Reynolds@MegaCoder.com> <1132525294.23150.53.camel@localhost.localdomain> Message-ID: <20051120182157.2b284fec.Tommy.Reynolds@MegaCoder.com> Uttered "Paul W. Frields" , spake thus: > > I can't find precedent for this approach, though. Can you point to > > a package set using the "foo--*" template? > Ahh, yes. See e.g. koffice-langpack-* in Extras I think. I haven't > looked at the SRPM yet. NOT COUNTING KDE!! I'm kidding. Maybe that should be "I'm kdeing" ;-) > > About the "Documentation/" groups, I don't know. I'm intrigued > > though, so I'll look at the anaconda stuff to see what needs to be > > done. > I thought this was underway in Anaconda, but doesn't even that revolve > around comps? Dunno. I'm looking. > > I don't consider having the author team maintain one overhead file for > > RPM generation much of a burden. > Agreed there. I think it would be cool if we simply required one extra > file, an XML one based on the DTD you provided. All authors and > translators could update that, and everything needed to press the spec, > OMF, .desktop, etc. would come out of that file at build time. If you can send me the prototype OMF, et.al., I may find time to produce some XSL stylesheets to do the necessary transformation from the funky XML info file into an OMF or a SPEC and be able to eschew any additions to Fedora Extras. Cheers -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From stickster at gmail.com Mon Nov 21 00:51:03 2005 From: stickster at gmail.com (Paul W. Frields) Date: Sun, 20 Nov 2005 19:51:03 -0500 Subject: Advise on Fedora RPM's In-Reply-To: <20051120182157.2b284fec.Tommy.Reynolds@MegaCoder.com> References: <20051118235711.50ea5f96.Tommy.Reynolds@MegaCoder.com> <1132448250.9579.14.camel@localhost.localdomain> <1132502946.21435.3.camel@localhost.localdomain> <20051120115339.dabb9c9d.Tommy.Reynolds@MegaCoder.com> <1132525294.23150.53.camel@localhost.localdomain> <20051120182157.2b284fec.Tommy.Reynolds@MegaCoder.com> Message-ID: <1132534263.23150.92.camel@localhost.localdomain> On Sun, 2005-11-20 at 18:21 -0600, Tommy Reynolds wrote: > Uttered "Paul W. Frields" , spake thus: > > > > I can't find precedent for this approach, though. Can you point to > > > a package set using the "foo--*" template? > > Ahh, yes. See e.g. koffice-langpack-* in Extras I think. I haven't > > looked at the SRPM yet. > > NOT COUNTING KDE!! I'm kidding. Maybe that should be "I'm kdeing" ;-) > > > > About the "Documentation/" groups, I don't know. I'm intrigued > > > though, so I'll look at the anaconda stuff to see what needs to be > > > done. > > I thought this was underway in Anaconda, but doesn't even that revolve > > around comps? > > Dunno. I'm looking. > > > > I don't consider having the author team maintain one overhead file for > > > RPM generation much of a burden. > > Agreed there. I think it would be cool if we simply required one extra > > file, an XML one based on the DTD you provided. All authors and > > translators could update that, and everything needed to press the spec, > > OMF, .desktop, etc. would come out of that file at build time. > > If you can send me the prototype OMF, et.al., I may find time to > produce some XSL stylesheets to do the necessary transformation from > the funky XML info file into an OMF or a SPEC and be able to eschew > any additions to Fedora Extras. You'll find the prototype OMF in docs-common/packaging, It is ugly in that it only really works for "en" $LANG. What you'll find is that OMFs are separately constructed for each locale and placed in /usr/share/omf/, e.g. /usr/share/omf/gcalctool/gcalctool-it.omf -- the "C" locale is used for en. (That goes for at least en.UTF-8, maybe other sub-locales -- or whatever you call them, I'm out of my depth there.) The OMF standard is discussed in /usr/share/scrollkeeper/doc/writing_scrollkeeper_omf_files/C/writing_scrollkeeper_omf_files.xml if you want to take a look at the real authoritative stuff -- or in GNOME, just launch Desktop -> Help -> Writing Scrollkeeper OMF Files. (Just a side note: One thing we *definitely* want is for all official FDP docs to be in the General|Linux|Distributions|Other category, since that will put them on the front "Help" page where people find them quickly. You'll see that in the example in docs-common/packaging/.) If you run "make rpm" in the docs-common/ module, you'll get my first cut at what a fedora-doc-common RPM would look like. Notice it includes things like a .menu file for the /etc/xdg/ tree so that later docs will show up on the Applications -> Documentation menu as well as yelp, khelpcenter, or anywhere else we decide. The .desktop files are set up to allow such a thing. Let me know if there's anything there that looks wacko. -- Paul W. Frields, RHCE http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 Fedora Documentation Project: http://fedora.redhat.com/projects/docs/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From ivazquez at ivazquez.net Mon Nov 21 02:53:49 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Sun, 20 Nov 2005 21:53:49 -0500 Subject: xmlstarlet (was: Re: Advise on Fedora RPM's) In-Reply-To: <1132525294.23150.53.camel@localhost.localdomain> References: <20051118235711.50ea5f96.Tommy.Reynolds@MegaCoder.com> <1132448250.9579.14.camel@localhost.localdomain> <1132502946.21435.3.camel@localhost.localdomain> <20051120115339.dabb9c9d.Tommy.Reynolds@MegaCoder.com> <1132525294.23150.53.camel@localhost.localdomain> Message-ID: <1132541629.1574.21.camel@ignacio.lan> On Sun, 2005-11-20 at 17:21 -0500, Paul W. Frields wrote: > > * [footnote] > > Someone pointed out that the Fedora Extras folk have been discussing > > the xmlstar tool but so far have avoided in because of the "ambiguous > > package name". Even its author uses at least three different names > > for it on the web pages. With the power of an RPM patch file, we can > > include the tool using any name we like. With proper attribution in > > the SPEC file, we can name it anything we like. No huhu. > > It looks like from the discussion you referenced that the original > packager has dropped out of the running. Shall I email him and see if > he minds me picking up the package instead? I don't mind patching it > and getting it into FE if it will help us move down this road by the > time of FC5t2 or t3. I wouldn't say I've "dropped out"; I haven't heard from upstream and have been too busy to deal with it. If you want it then by all means take it. Also, it wasn't the package name but the binary name. "xml" was designated to be too generic. I did have a patch for it IIRC; let me look around. -- Ignacio Vazquez-Abrams http://fedora.ivazquez.net/ gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From kwade at redhat.com Mon Nov 21 05:38:34 2005 From: kwade at redhat.com (Karsten Wade) Date: Sun, 20 Nov 2005 21:38:34 -0800 Subject: Proposal for document entities In-Reply-To: <1132414157.3578.0.camel@localhost.localdomain> References: <1132346075.5672.23.camel@localhost.localdomain> <1132398644.2870.4.camel@localhost.localdomain> <1132414157.3578.0.camel@localhost.localdomain> Message-ID: <1132551515.935.20.camel@erato.phig.org> On Sat, 2005-11-19 at 10:29 -0500, Paul W. Frields wrote: > On Sat, 2005-11-19 at 11:10 +0000, Stuart Ellis wrote: > > On Fri, 2005-11-18 at 15:34 -0500, Paul W. Frields wrote: > > > I would like to see this instead as a standard: > > > > > > > > > > > > > > > > > > > > > > Another +1. > > > > I'd prefer "DOC*", over "BOOK*" for these, just because documents may > > all not be Guides, and most of the end-products are on-line, rather than > > specifically for printing. > > Excellent point. +1 -- Karsten Wade, RHCE * Sr. Tech Writer * http://people.redhat.com/kwade/ gpg fingerprint: 2680 DBFD D968 3141 0115 5F1B D992 0E06 AD0E 0C41 Content Services Fedora Documentation Project http://www.redhat.com/docs http://fedoraproject.org/wiki/DocsProject -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From kwade at redhat.com Mon Nov 21 06:53:47 2005 From: kwade at redhat.com (Karsten Wade) Date: Sun, 20 Nov 2005 22:53:47 -0800 Subject: docs-common/common legalnotice-relnotes-zh_CN.xml,NONE,1.1 In-Reply-To: <76e72f800511201918y39100ack@mail.gmail.com> References: <200511210305.jAL355Gv007647@cvs-int.fedora.redhat.com> <76e72f800511201918y39100ack@mail.gmail.com> Message-ID: <1132556027.935.27.camel@erato.phig.org> On Mon, 2005-11-21 at 11:18 +0800, Yuan Yijun wrote: > Should I update the master file (RELEASE-NOTES-zh_CN.xml) or I could > do that until next freeze? How does it need updating? - Karsten -- Karsten Wade, RHCE * Sr. Tech Writer * http://people.redhat.com/kwade/ gpg fingerprint: 2680 DBFD D968 3141 0115 5F1B D992 0E06 AD0E 0C41 Content Services Fedora Documentation Project http://www.redhat.com/docs http://fedoraproject.org/wiki/DocsProject -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From bbbush.yuan at gmail.com Mon Nov 21 07:21:09 2005 From: bbbush.yuan at gmail.com (Yuan Yijun) Date: Mon, 21 Nov 2005 15:21:09 +0800 Subject: docs-common/common legalnotice-relnotes-zh_CN.xml,NONE,1.1 In-Reply-To: <1132556027.935.27.camel@erato.phig.org> References: <200511210305.jAL355Gv007647@cvs-int.fedora.redhat.com> <76e72f800511201918y39100ack@mail.gmail.com> <1132556027.935.27.camel@erato.phig.org> Message-ID: <76e72f800511202321i5a08569ci@mail.gmail.com> 2005/11/21, Karsten Wade : > On Mon, 2005-11-21 at 11:18 +0800, Yuan Yijun wrote: > > Should I update the master file (RELEASE-NOTES-zh_CN.xml) or I could > > do that until next freeze? > > How does it need updating? > :) just find "legalnotice-relnotes-en.xml" is not hardcoded in that control file. -- bbbush ^_^ From stickster at gmail.com Mon Nov 21 13:15:51 2005 From: stickster at gmail.com (Paul W. Frields) Date: Mon, 21 Nov 2005 08:15:51 -0500 Subject: xmlstarlet (was: Re: Advise on Fedora RPM's) In-Reply-To: <1132541629.1574.21.camel@ignacio.lan> References: <20051118235711.50ea5f96.Tommy.Reynolds@MegaCoder.com> <1132448250.9579.14.camel@localhost.localdomain> <1132502946.21435.3.camel@localhost.localdomain> <20051120115339.dabb9c9d.Tommy.Reynolds@MegaCoder.com> <1132525294.23150.53.camel@localhost.localdomain> <1132541629.1574.21.camel@ignacio.lan> Message-ID: <1132578951.690.9.camel@localhost.localdomain> On Sun, 2005-11-20 at 21:53 -0500, Ignacio Vazquez-Abrams wrote: > On Sun, 2005-11-20 at 17:21 -0500, Paul W. Frields wrote: > > > * [footnote] > > > Someone pointed out that the Fedora Extras folk have been discussing > > > the xmlstar tool but so far have avoided in because of the "ambiguous > > > package name". Even its author uses at least three different names > > > for it on the web pages. With the power of an RPM patch file, we can > > > include the tool using any name we like. With proper attribution in > > > the SPEC file, we can name it anything we like. No huhu. > > > > It looks like from the discussion you referenced that the original > > packager has dropped out of the running. Shall I email him and see if > > he minds me picking up the package instead? I don't mind patching it > > and getting it into FE if it will help us move down this road by the > > time of FC5t2 or t3. > > I wouldn't say I've "dropped out"; I haven't heard from upstream and > have been too busy to deal with it. If you want it then by all means > take it. Pardon my poor choice of words -- was in a hasty rush to make the kids some dinner. :-) I meant "withdrawn the package for now." We are really interested in this package, so if you don't have time to do it we (by which I mean "I," at least as far as this package goes) would be happy to help, and you have our thanks for bringing it up to this point. > Also, it wasn't the package name but the binary name. "xml" was > designated to be too generic. I did have a patch for it IIRC; let me > look around. If you thought you'd have to time *review* the package for Extras that would probably be a huge help! Thanks Ignacio! -- Paul W. Frields, RHCE http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 Fedora Documentation Project: http://fedora.redhat.com/projects/docs/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From stickster at gmail.com Mon Nov 21 13:18:39 2005 From: stickster at gmail.com (Paul W. Frields) Date: Mon, 21 Nov 2005 08:18:39 -0500 Subject: Proposal for document entities In-Reply-To: <1132551515.935.20.camel@erato.phig.org> References: <1132346075.5672.23.camel@localhost.localdomain> <1132398644.2870.4.camel@localhost.localdomain> <1132414157.3578.0.camel@localhost.localdomain> <1132551515.935.20.camel@erato.phig.org> Message-ID: <1132579119.690.12.camel@localhost.localdomain> On Sun, 2005-11-20 at 21:38 -0800, Karsten Wade wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > Another +1. > > > > > > I'd prefer "DOC*", over "BOOK*" for these, just because documents may > > > all not be Guides, and most of the end-products are on-line, rather than > > > specifically for printing. > > > > Excellent point. > > +1 OK, this will break some docs when we put this change in, since docs-common/common/{legalnotice,bugreporting}-*.xml are tied to BOOKID. I don't mind changing all these to use DOCID, and I'll even do a mass replacement of BOOKID in existing docs, as long as no one objects. Speak now, Docs Mobb! -- Paul W. Frields, RHCE http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 Fedora Documentation Project: http://fedora.redhat.com/projects/docs/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From Tommy.Reynolds at MegaCoder.com Mon Nov 21 15:29:59 2005 From: Tommy.Reynolds at MegaCoder.com (Tommy Reynolds) Date: Mon, 21 Nov 2005 09:29:59 -0600 Subject: xmlstarlet (was: Re: Advise on Fedora RPM's) In-Reply-To: <1132578951.690.9.camel@localhost.localdomain> References: <20051118235711.50ea5f96.Tommy.Reynolds@MegaCoder.com> <1132448250.9579.14.camel@localhost.localdomain> <1132502946.21435.3.camel@localhost.localdomain> <20051120115339.dabb9c9d.Tommy.Reynolds@MegaCoder.com> <1132525294.23150.53.camel@localhost.localdomain> <1132541629.1574.21.camel@ignacio.lan> <1132578951.690.9.camel@localhost.localdomain> Message-ID: <20051121092959.645c9090.Tommy.Reynolds@MegaCoder.com> Uttered "Paul W. Frields" , spake thus: > On Sun, 2005-11-20 at 21:53 -0500, Ignacio Vazquez-Abrams wrote: > > On Sun, 2005-11-20 at 17:21 -0500, Paul W. Frields wrote: > > > > Someone pointed out that the Fedora Extras folk have been discussing > > > > the xmlstar tool but so far have avoided in because of the "ambiguous > > > > package name". > > > It looks like from the discussion you referenced that the original > > > packager has dropped out of the running. Shall I email him and see if > > > he minds me picking up the package instead? I don't mind patching it > > > and getting it into FE if it will help us move down this road by the > > > time of FC5t2 or t3. > > I wouldn't say I've "dropped out"; I haven't heard from upstream and > > have been too busy to deal with it. If you want it then by all means > > take it. > We are really interested in this package, so if you don't have time > to do it we (by which I mean "I," at least as far as this package > goes) would be happy to help, and you have our thanks for bringing > it up to this point. > > Also, it wasn't the package name but the binary name. "xml" was > > designated to be too generic. I did have a patch for it IIRC; let me > > look around. > If you thought you'd have to time *review* the package for Extras that > would probably be a huge help! Thanks Ignacio! As I mentioned in my original post, I have the package patched and an RPM built if you'd like to review it. Cheers -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From stickster at gmail.com Mon Nov 21 15:53:23 2005 From: stickster at gmail.com (Paul W. Frields) Date: Mon, 21 Nov 2005 10:53:23 -0500 Subject: xmlstarlet (was: Re: Advise on Fedora RPM's) In-Reply-To: <20051121092959.645c9090.Tommy.Reynolds@MegaCoder.com> References: <20051118235711.50ea5f96.Tommy.Reynolds@MegaCoder.com> <1132448250.9579.14.camel@localhost.localdomain> <1132502946.21435.3.camel@localhost.localdomain> <20051120115339.dabb9c9d.Tommy.Reynolds@MegaCoder.com> <1132525294.23150.53.camel@localhost.localdomain> <1132541629.1574.21.camel@ignacio.lan> <1132578951.690.9.camel@localhost.localdomain> <20051121092959.645c9090.Tommy.Reynolds@MegaCoder.com> Message-ID: <1132588403.2864.0.camel@localhost.localdomain> On Mon, 2005-11-21 at 09:29 -0600, Tommy Reynolds wrote: > Uttered "Paul W. Frields" , spake thus: > > On Sun, 2005-11-20 at 21:53 -0500, Ignacio Vazquez-Abrams wrote: > > > Also, it wasn't the package name but the binary name. "xml" was > > > designated to be too generic. I did have a patch for it IIRC; let me > > > look around. > > If you thought you'd have to time *review* the package for Extras that > > would probably be a huge help! Thanks Ignacio! > > As I mentioned in my original post, I have the package patched and an > RPM built if you'd like to review it. Superb, bring it on! -- Paul W. Frields, RHCE http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 Fedora Documentation Project: http://fedora.redhat.com/projects/docs/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From Tommy.Reynolds at MegaCoder.com Mon Nov 21 18:41:52 2005 From: Tommy.Reynolds at MegaCoder.com (Tommy Reynolds) Date: Mon, 21 Nov 2005 12:41:52 -0600 Subject: xmlstarlet (was: Re: Advise on Fedora RPM's) In-Reply-To: <1132588403.2864.0.camel@localhost.localdomain> References: <20051118235711.50ea5f96.Tommy.Reynolds@MegaCoder.com> <1132448250.9579.14.camel@localhost.localdomain> <1132502946.21435.3.camel@localhost.localdomain> <20051120115339.dabb9c9d.Tommy.Reynolds@MegaCoder.com> <1132525294.23150.53.camel@localhost.localdomain> <1132541629.1574.21.camel@ignacio.lan> <1132578951.690.9.camel@localhost.localdomain> <20051121092959.645c9090.Tommy.Reynolds@MegaCoder.com> <1132588403.2864.0.camel@localhost.localdomain> Message-ID: <20051121124152.329e14c6.Tommy.Reynolds@MegaCoder.com> Uttered "Paul W. Frields" , spake thus: > > As I mentioned in my original post, I have the package patched and an > > RPM built if you'd like to review it. > Superb, bring it on! OK. I've put it here: http://www.megacoder.com/pub/xmlstarlet/ ftp://ftp.megacoder.com/pub/xmlstarlet/ It renames the "xml" application to "xmlstarlet" to match the package name, the documentation, the web page... Just for fun, here is an XSLT stylesheet that shows we can derive the stuff, as well as the OMF and SPEC file stuff. Run it like this: $ xsltproc rpm-info.xsl rpm-info.xml using the files I posted yesterday. Have fun with it! ==[/home/reynolds/src/f/fedora-docs/docs-common/rpm-info.xsl]== Processing titles Processing translation () Processing title Processing desc %changelog Processing revision Processing date Processing author Processing details ===[EOF]=== Cheers -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From kwade at redhat.com Tue Nov 22 12:01:59 2005 From: kwade at redhat.com (Karsten Wade) Date: Tue, 22 Nov 2005 04:01:59 -0800 Subject: CMS use cases Message-ID: <1132660919.935.129.camel@erato.phig.org> Seth asked for some use cases that show what a content management system (CMS) can do. I wanted to run them by this group, see what your ideas are. What would the CMS do? Manage content for Fedora sites. fedoraproject.org, primarily. There are multiple roles: * Editor - logs into a workbench with entire work queue visible: - Can approve content or push it back for further writing/edits - If configured, cannot edit the document, can only push forward or backward - Push to publish - Directly to Web, or enables an autobuild of some kind, or pushes to a higher level publisher * Writer - Write content from scratch or amalgamate - Can use built-in CMS editing functionality, attach a document of some kind, or check into CVS and point at that as content submission. - May modify a work when it is pushed back from an editor. - Modification of published work generates a new workflow, requiring the same level of approval as previously - If configured, may retire or set expiration date for own content. - When ready, can push own content to editor * Lead Writer - As above for Writer, can also be injected into the workflow for a pre-approval/denial step prior to pushing to Editor. - Can act upon any content from project they lead as if the sole writer, that is, can modify into the workflow, set expiration, etc. * Publisher/Editor-in-chief - Final approver for sensitive content (legal, special marketing) - May have ability to directly edit content, depending on usage model. * Content Manager - Looks for content to retire or revitalize - Can immediately retire or set expiration date - Can dig up old content and push it for a rewrite - Lands in appropriate writer queue That's what I've got off the top of my head. Thanks - Karsten -- Karsten Wade, RHCE * Sr. Tech Writer * http://people.redhat.com/kwade/ gpg fingerprint: 2680 DBFD D968 3141 0115 5F1B D992 0E06 AD0E 0C41 Content Services Fedora Documentation Project http://www.redhat.com/docs http://fedoraproject.org/wiki/DocsProject -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From Tommy.Reynolds at MegaCoder.com Tue Nov 22 12:28:08 2005 From: Tommy.Reynolds at MegaCoder.com (Tommy Reynolds) Date: Tue, 22 Nov 2005 06:28:08 -0600 Subject: CMS use cases In-Reply-To: <1132660919.935.129.camel@erato.phig.org> References: <1132660919.935.129.camel@erato.phig.org> Message-ID: <20051122062808.2221d5e9.Tommy.Reynolds@MegaCoder.com> Uttered Karsten Wade , spake thus: > That's what I've got off the top of my head. I'll be you feel much lighter now. All this sounds terribly formalized; is there really a need for so many task divisions? I have no experience with such a CMS, so I'm not qualified to have an opinion, but where is the current setup inadequate? I'm not objecting, just asking for a sales pitch ;-) Cheers -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From stickster at gmail.com Tue Nov 22 12:47:52 2005 From: stickster at gmail.com (Paul W. Frields) Date: Tue, 22 Nov 2005 07:47:52 -0500 Subject: xmlstarlet (was: Re: Advise on Fedora RPM's) In-Reply-To: <20051121124152.329e14c6.Tommy.Reynolds@MegaCoder.com> References: <20051118235711.50ea5f96.Tommy.Reynolds@MegaCoder.com> <1132448250.9579.14.camel@localhost.localdomain> <1132502946.21435.3.camel@localhost.localdomain> <20051120115339.dabb9c9d.Tommy.Reynolds@MegaCoder.com> <1132525294.23150.53.camel@localhost.localdomain> <1132541629.1574.21.camel@ignacio.lan> <1132578951.690.9.camel@localhost.localdomain> <20051121092959.645c9090.Tommy.Reynolds@MegaCoder.com> <1132588403.2864.0.camel@localhost.localdomain> <20051121124152.329e14c6.Tommy.Reynolds@MegaCoder.com> Message-ID: <1132663672.3047.1.camel@localhost.localdomain> On Mon, 2005-11-21 at 12:41 -0600, Tommy Reynolds wrote: > Uttered "Paul W. Frields" , spake thus: > > > > As I mentioned in my original post, I have the package patched and an > > > RPM built if you'd like to review it. > > Superb, bring it on! > > OK. I've put it here: > > http://www.megacoder.com/pub/xmlstarlet/ > ftp://ftp.megacoder.com/pub/xmlstarlet/ Do you have the .src.rpm available? -- Paul W. Frields, RHCE http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 Fedora Documentation Project: http://fedora.redhat.com/projects/docs/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From Tommy.Reynolds at MegaCoder.com Tue Nov 22 13:40:18 2005 From: Tommy.Reynolds at MegaCoder.com (Tommy Reynolds) Date: Tue, 22 Nov 2005 07:40:18 -0600 Subject: xmlstarlet (was: Re: Advise on Fedora RPM's) In-Reply-To: <1132663672.3047.1.camel@localhost.localdomain> References: <20051118235711.50ea5f96.Tommy.Reynolds@MegaCoder.com> <1132448250.9579.14.camel@localhost.localdomain> <1132502946.21435.3.camel@localhost.localdomain> <20051120115339.dabb9c9d.Tommy.Reynolds@MegaCoder.com> <1132525294.23150.53.camel@localhost.localdomain> <1132541629.1574.21.camel@ignacio.lan> <1132578951.690.9.camel@localhost.localdomain> <20051121092959.645c9090.Tommy.Reynolds@MegaCoder.com> <1132588403.2864.0.camel@localhost.localdomain> <20051121124152.329e14c6.Tommy.Reynolds@MegaCoder.com> <1132663672.3047.1.camel@localhost.localdomain> Message-ID: <20051122074018.1571dc0f.Tommy.Reynolds@MegaCoder.com> Uttered "Paul W. Frields" , spake thus: > > http://www.megacoder.com/pub/xmlstarlet/ > > ftp://ftp.megacoder.com/pub/xmlstarlet/ > > Do you have the .src.rpm available? Yup; it's there now. Sorry, too big of a hurry. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From stickster at gmail.com Tue Nov 22 18:29:06 2005 From: stickster at gmail.com (Paul W. Frields) Date: Tue, 22 Nov 2005 13:29:06 -0500 Subject: xmlstarlet (was: Re: Advise on Fedora RPM's) In-Reply-To: <20051122074018.1571dc0f.Tommy.Reynolds@MegaCoder.com> References: <20051118235711.50ea5f96.Tommy.Reynolds@MegaCoder.com> <1132448250.9579.14.camel@localhost.localdomain> <1132502946.21435.3.camel@localhost.localdomain> <20051120115339.dabb9c9d.Tommy.Reynolds@MegaCoder.com> <1132525294.23150.53.camel@localhost.localdomain> <1132541629.1574.21.camel@ignacio.lan> <1132578951.690.9.camel@localhost.localdomain> <20051121092959.645c9090.Tommy.Reynolds@MegaCoder.com> <1132588403.2864.0.camel@localhost.localdomain> <20051121124152.329e14c6.Tommy.Reynolds@MegaCoder.com> <1132663672.3047.1.camel@localhost.localdomain> <20051122074018.1571dc0f.Tommy.Reynolds@MegaCoder.com> Message-ID: <1132684146.3047.13.camel@localhost.localdomain> On Tue, 2005-11-22 at 07:40 -0600, Tommy Reynolds wrote: > Uttered "Paul W. Frields" , spake thus: > > > > http://www.megacoder.com/pub/xmlstarlet/ > > > ftp://ftp.megacoder.com/pub/xmlstarlet/ > > > > Do you have the .src.rpm available? > > Yup; it's there now. Thanks Tommy, and Ignacio too for that matter. This is now in the FE queue. If one of you is a FE reviewer, it would be great if you could take it upon yourselves to verify that all the concerns have been handled. I have no doubt Tommy's done that, and I think the .spec buffed to a high "FE" gloss, so it should be a quick process. See the BZ entry: https://bugzilla.redhat.com/173924 -- Paul W. Frields, RHCE http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 Fedora Documentation Project: http://fedora.redhat.com/projects/docs/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From Tommy.Reynolds at MegaCoder.com Tue Nov 22 19:38:41 2005 From: Tommy.Reynolds at MegaCoder.com (Tommy Reynolds) Date: Tue, 22 Nov 2005 13:38:41 -0600 Subject: xmlstarlet (was: Re: Advise on Fedora RPM's) In-Reply-To: <1132684146.3047.13.camel@localhost.localdomain> References: <20051118235711.50ea5f96.Tommy.Reynolds@MegaCoder.com> <1132448250.9579.14.camel@localhost.localdomain> <1132502946.21435.3.camel@localhost.localdomain> <20051120115339.dabb9c9d.Tommy.Reynolds@MegaCoder.com> <1132525294.23150.53.camel@localhost.localdomain> <1132541629.1574.21.camel@ignacio.lan> <1132578951.690.9.camel@localhost.localdomain> <20051121092959.645c9090.Tommy.Reynolds@MegaCoder.com> <1132588403.2864.0.camel@localhost.localdomain> <20051121124152.329e14c6.Tommy.Reynolds@MegaCoder.com> <1132663672.3047.1.camel@localhost.localdomain> <20051122074018.1571dc0f.Tommy.Reynolds@MegaCoder.com> <1132684146.3047.13.camel@localhost.localdomain> Message-ID: <20051122133841.893f6a78.Tommy.Reynolds@MegaCoder.com> Uttered "Paul W. Frields" , spake thus: > > > > ftp://ftp.megacoder.com/pub/xmlstarlet/ > > > Do you have the .src.rpm available? > > Yup; it's there now. > Thanks Tommy, and Ignacio too for that matter. This is now in the FE > queue. If one of you is a FE reviewer, it would be great if you could > take it upon yourselves to verify that all the concerns have been > handled. I have no doubt Tommy's done that, and I think the .spec > buffed to a high "FE" gloss, so it should be a quick process. See the > BZ entry: > https://bugzilla.redhat.com/173924 Oops! The RPM contains the *patched* sources, instead of the pristine sources and a patch. Give me a couple of minutes, and I'll fix it. Cheers -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From stickster at gmail.com Tue Nov 22 20:32:58 2005 From: stickster at gmail.com (Paul W. Frields) Date: Tue, 22 Nov 2005 15:32:58 -0500 Subject: xmlstarlet (was: Re: Advise on Fedora RPM's) In-Reply-To: <20051122133841.893f6a78.Tommy.Reynolds@MegaCoder.com> References: <20051118235711.50ea5f96.Tommy.Reynolds@MegaCoder.com> <1132448250.9579.14.camel@localhost.localdomain> <1132502946.21435.3.camel@localhost.localdomain> <20051120115339.dabb9c9d.Tommy.Reynolds@MegaCoder.com> <1132525294.23150.53.camel@localhost.localdomain> <1132541629.1574.21.camel@ignacio.lan> <1132578951.690.9.camel@localhost.localdomain> <20051121092959.645c9090.Tommy.Reynolds@MegaCoder.com> <1132588403.2864.0.camel@localhost.localdomain> <20051121124152.329e14c6.Tommy.Reynolds@MegaCoder.com> <1132663672.3047.1.camel@localhost.localdomain> <20051122074018.1571dc0f.Tommy.Reynolds@MegaCoder.com> <1132684146.3047.13.camel@localhost.localdomain> <20051122133841.893f6a78.Tommy.Reynolds@MegaCoder.com> Message-ID: <1132691578.3056.31.camel@localhost.localdomain> On Tue, 2005-11-22 at 13:38 -0600, Tommy Reynolds wrote: > Uttered "Paul W. Frields" , spake thus: > > > > > > ftp://ftp.megacoder.com/pub/xmlstarlet/ > > > > Do you have the .src.rpm available? > > > Yup; it's there now. > > Thanks Tommy, and Ignacio too for that matter. This is now in the FE > > queue. If one of you is a FE reviewer, it would be great if you could > > take it upon yourselves to verify that all the concerns have been > > handled. I have no doubt Tommy's done that, and I think the .spec > > buffed to a high "FE" gloss, so it should be a quick process. See the > > BZ entry: > > https://bugzilla.redhat.com/173924 > > Oops! The RPM contains the *patched* sources, instead of the > pristine sources and a patch. > > Give me a couple of minutes, and I'll fix it. Can I just back out the patch on your site above? I can do it if you're busy, no prob. -- Paul W. Frields, RHCE http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 Fedora Documentation Project: http://fedora.redhat.com/projects/docs/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From kwade at redhat.com Tue Nov 22 20:50:49 2005 From: kwade at redhat.com (Karsten Wade) Date: Tue, 22 Nov 2005 12:50:49 -0800 Subject: CMS use cases In-Reply-To: <20051122062808.2221d5e9.Tommy.Reynolds@MegaCoder.com> References: <1132660919.935.129.camel@erato.phig.org> <20051122062808.2221d5e9.Tommy.Reynolds@MegaCoder.com> Message-ID: <1132692649.935.178.camel@erato.phig.org> On Tue, 2005-11-22 at 06:28 -0600, Tommy Reynolds wrote: > Uttered Karsten Wade , spake thus: > > > That's what I've got off the top of my head. > > I'll be you feel much lighter now. Much. > All this sounds terribly formalized; is there really a need for so > many task divisions? I have no experience with such a CMS, so I'm > not qualified to have an opinion, but where is the current setup > inadequate? I'm not objecting, just asking for a sales pitch ;-) See, this was why I asked this question here. :) Simple, the folks on fedora-websites-list have been discussing using a CMS to manage the formal Fedora websites. One advantage is that it is like a Wiki, user friendly to readers, authors, and content maintainers. I just found myself trying to explain what a CMS brings that, say, a Wiki with ACLs cannot do. To be honest, I'm not settled on my thoughts about what to do. A CMS has value. We could also install the lightest framework (Moin Moin + Python based framework, like Django) and build what we need as we go. That, however, requires resources that might be elsewhere. So, yeah, etc., just trying to scope the idea a bit. :) thanks - Karsten -- Karsten Wade, RHCE * Sr. Tech Writer * http://people.redhat.com/kwade/ gpg fingerprint: 2680 DBFD D968 3141 0115 5F1B D992 0E06 AD0E 0C41 Content Services Fedora Documentation Project http://www.redhat.com/docs http://fedoraproject.org/wiki/DocsProject -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From stuart at elsn.org Tue Nov 22 23:03:52 2005 From: stuart at elsn.org (Stuart Ellis) Date: Tue, 22 Nov 2005 23:03:52 +0000 Subject: Minutes of FDSCo meeting 22 Nov 2005 Message-ID: <1132700632.2888.40.camel@localhost.localdomain> Attending: --------- quaid elliss G2 megacoder mrj stickster Regrets: -------- Tammy Fox (tcf) - leave of absence Schedule of Tasks: ------------------ http://www.fedoraproject.org/wiki/DocsProject/FedoraDocsSchedule Highlights: ----------- * Release Notes: Great job done by Release Note beat writers and translators. Release Notes for FC5t1 have finalised and will be available in five languages. * DocsRawhide: Maintained documents in CVS are now built into Webpages, updated every hour. To avoid potential confusion about the status of the documents, public access to the site will be restricted until alternate stylesheets are in place to visibly distinguish the Rawhide drafts from completed documents. * Packaging: Work is ongoing to enhance the Fedora document build infrastructure to create RPMs for shipping documentation. Technical issues are being discussed on the main mailing list (fedora-docs-list) as they arise. Anyone with a interest in this area is welcome to join in and add their input. -- Stuart Ellis stuart at elsn.org Fedora Documentation Project: http://fedora.redhat.com/projects/docs/ GPG key ID: 7098ABEA GPG key fingerprint: 68B0 E291 FB19 C845 E60E 9569 292E E365 7098 ABEA -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From stuart at elsn.org Tue Nov 22 23:28:12 2005 From: stuart at elsn.org (Stuart Ellis) Date: Tue, 22 Nov 2005 23:28:12 +0000 Subject: CMS use cases In-Reply-To: <1132692649.935.178.camel@erato.phig.org> References: <1132660919.935.129.camel@erato.phig.org> <20051122062808.2221d5e9.Tommy.Reynolds@MegaCoder.com> <1132692649.935.178.camel@erato.phig.org> Message-ID: <1132702092.2888.60.camel@localhost.localdomain> On Tue, 2005-11-22 at 12:50 -0800, Karsten Wade wrote: > Simple, the folks on fedora-websites-list have been discussing using a > CMS to manage the formal Fedora websites. One advantage is that it is > like a Wiki, user friendly to readers, authors, and content maintainers. > > I just found myself trying to explain what a CMS brings that, say, a > Wiki with ACLs cannot do. To be honest, I'm not settled on my thoughts > about what to do. A CMS has value. We could also install the lightest > framework (Moin Moin + Python based framework, like Django) and build > what we need as we go. I think that the issue that I have with Wiki is more to do with the expectations than the technology itself. Pages on a Wiki site are never finalised, and get edited incrementally by whoever has something to contribute. For prominent pages I think that there ought to be a way of separating in-progress work from a done/approved/unleash on the public version - perhaps more a feature of CMS. At a technical level I don't really distinguish between Wikis with access control and CMS with on-line editing - different CMS/Wiki/portal products do seem to encourage different working styles, though. -- Stuart Ellis stuart at elsn.org Fedora Documentation Project: http://fedora.redhat.com/projects/docs/ GPG key ID: 7098ABEA GPG key fingerprint: 68B0 E291 FB19 C845 E60E 9569 292E E365 7098 ABEA -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From gdk at redhat.com Tue Nov 22 23:35:34 2005 From: gdk at redhat.com (Greg DeKoenigsberg) Date: Tue, 22 Nov 2005 18:35:34 -0500 (EST) Subject: CMS use cases In-Reply-To: <1132702092.2888.60.camel@localhost.localdomain> References: <1132660919.935.129.camel@erato.phig.org> <20051122062808.2221d5e9.Tommy.Reynolds@MegaCoder.com> <1132692649.935.178.camel@erato.phig.org> <1132702092.2888.60.camel@localhost.localdomain> Message-ID: Wikis often have poor navigation. The current moinmoin wiki definitely has poor navigation. A good CMS should have some sense of hierarchy available, imho. --g _____________________ ____________________________________________ Greg DeKoenigsberg ] [ the future masters of technology will have Community Relations ] [ to be lighthearted and intelligent. the Red Hat ] [ machine easily masters the grim and the ] [ dumb. --mcluhan On Tue, 22 Nov 2005, Stuart Ellis wrote: > On Tue, 2005-11-22 at 12:50 -0800, Karsten Wade wrote: > > > Simple, the folks on fedora-websites-list have been discussing using a > > CMS to manage the formal Fedora websites. One advantage is that it is > > like a Wiki, user friendly to readers, authors, and content maintainers. > > > > I just found myself trying to explain what a CMS brings that, say, a > > Wiki with ACLs cannot do. To be honest, I'm not settled on my thoughts > > about what to do. A CMS has value. We could also install the lightest > > framework (Moin Moin + Python based framework, like Django) and build > > what we need as we go. > > I think that the issue that I have with Wiki is more to do with the > expectations than the technology itself. > > Pages on a Wiki site are never finalised, and get edited incrementally > by whoever has something to contribute. For prominent pages I think that > there ought to be a way of separating in-progress work from a > done/approved/unleash on the public version - perhaps more a feature of > CMS. > > At a technical level I don't really distinguish between Wikis with > access control and CMS with on-line editing - different CMS/Wiki/portal > products do seem to encourage different working styles, though. > > -- > > Stuart Ellis > > stuart at elsn.org > > Fedora Documentation Project: http://fedora.redhat.com/projects/docs/ > > GPG key ID: 7098ABEA > GPG key fingerprint: 68B0 E291 FB19 C845 E60E 9569 292E E365 7098 ABEA > From Tommy.Reynolds at MegaCoder.com Tue Nov 22 23:42:49 2005 From: Tommy.Reynolds at MegaCoder.com (Tommy Reynolds) Date: Tue, 22 Nov 2005 17:42:49 -0600 Subject: xmlstarlet (was: Re: Advise on Fedora RPM's) In-Reply-To: <1132691578.3056.31.camel@localhost.localdomain> References: <20051118235711.50ea5f96.Tommy.Reynolds@MegaCoder.com> <1132448250.9579.14.camel@localhost.localdomain> <1132502946.21435.3.camel@localhost.localdomain> <20051120115339.dabb9c9d.Tommy.Reynolds@MegaCoder.com> <1132525294.23150.53.camel@localhost.localdomain> <1132541629.1574.21.camel@ignacio.lan> <1132578951.690.9.camel@localhost.localdomain> <20051121092959.645c9090.Tommy.Reynolds@MegaCoder.com> <1132588403.2864.0.camel@localhost.localdomain> <20051121124152.329e14c6.Tommy.Reynolds@MegaCoder.com> <1132663672.3047.1.camel@localhost.localdomain> <20051122074018.1571dc0f.Tommy.Reynolds@MegaCoder.com> <1132684146.3047.13.camel@localhost.localdomain> <20051122133841.893f6a78.Tommy.Reynolds@MegaCoder.com> <1132691578.3056.31.camel@localhost.localdomain> Message-ID: <20051122174249.29361d8e.Tommy.Reynolds@MegaCoder.com> Uttered "Paul W. Frields" , spake thus: > > > > > > ftp://ftp.megacoder.com/pub/xmlstarlet/ > > > > > Do you have the .src.rpm available? > > > > Yup; it's there now. > > Oops! The RPM contains the *patched* sources, instead of the > > pristine sources and a patch. > > Give me a couple of minutes, and I'll fix it. > Can I just back out the patch on your site above? I can do it if you're > busy, no prob. I've posted the corrected RPM's at the address mentioned above. This turned out to be a bit more tricky than usual. I needed to modify the Makefile.am file because I needed to "./autogen.sh" instead of "configure". Oh, well that's one. Have lotsa fun... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From stuart at elsn.org Tue Nov 22 23:56:08 2005 From: stuart at elsn.org (Stuart Ellis) Date: Tue, 22 Nov 2005 23:56:08 +0000 Subject: CMS use cases In-Reply-To: References: <1132660919.935.129.camel@erato.phig.org> <20051122062808.2221d5e9.Tommy.Reynolds@MegaCoder.com> <1132692649.935.178.camel@erato.phig.org> <1132702092.2888.60.camel@localhost.localdomain> Message-ID: <1132703768.2888.72.camel@localhost.localdomain> On Tue, 2005-11-22 at 18:35 -0500, Greg DeKoenigsberg wrote: > Wikis often have poor navigation. The current moinmoin wiki definitely > has poor navigation. A good CMS should have some sense of hierarchy > available, imho. I agree. That what kind of what I was driving at... MoinMoin is designed to be unstructured to match the Wiki way of working (throw down stuff as you need it). We can beat the current set of pages into a particular shape, and use the technical functions to do CMS stuff, but it will always encourage a loose structure, and contributors will always treat it as a Wiki rather than a standard heirarchical site. -- Stuart Ellis stuart at elsn.org Fedora Documentation Project: http://fedora.redhat.com/projects/docs/ GPG key ID: 7098ABEA GPG key fingerprint: 68B0 E291 FB19 C845 E60E 9569 292E E365 7098 ABEA -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From stickster at gmail.com Wed Nov 23 00:36:21 2005 From: stickster at gmail.com (Paul W. Frields) Date: Tue, 22 Nov 2005 19:36:21 -0500 Subject: xmlstarlet (was: Re: Advise on Fedora RPM's) In-Reply-To: <20051122174249.29361d8e.Tommy.Reynolds@MegaCoder.com> References: <20051118235711.50ea5f96.Tommy.Reynolds@MegaCoder.com> <1132448250.9579.14.camel@localhost.localdomain> <1132502946.21435.3.camel@localhost.localdomain> <20051120115339.dabb9c9d.Tommy.Reynolds@MegaCoder.com> <1132525294.23150.53.camel@localhost.localdomain> <1132541629.1574.21.camel@ignacio.lan> <1132578951.690.9.camel@localhost.localdomain> <20051121092959.645c9090.Tommy.Reynolds@MegaCoder.com> <1132588403.2864.0.camel@localhost.localdomain> <20051121124152.329e14c6.Tommy.Reynolds@MegaCoder.com> <1132663672.3047.1.camel@localhost.localdomain> <20051122074018.1571dc0f.Tommy.Reynolds@MegaCoder.com> <1132684146.3047.13.camel@localhost.localdomain> <20051122133841.893f6a78.Tommy.Reynolds@MegaCoder.com> <1132691578.3056.31.camel@localhost.localdomain> <20051122174249.29361d8e.Tommy.Reynolds@MegaCoder.com> Message-ID: <1132706181.17303.6.camel@localhost.localdomain> On Tue, 2005-11-22 at 17:42 -0600, Tommy Reynolds wrote: > Uttered "Paul W. Frields" , spake thus: > > > > > > > > ftp://ftp.megacoder.com/pub/xmlstarlet/ > > > > > > Do you have the .src.rpm available? > > > > > Yup; it's there now. > > > Oops! The RPM contains the *patched* sources, instead of the > > > pristine sources and a patch. > > > Give me a couple of minutes, and I'll fix it. > > Can I just back out the patch on your site above? I can do it if you're > > busy, no prob. > > I've posted the corrected RPM's at the address mentioned above. > > This turned out to be a bit more tricky than usual. I needed to modify > the Makefile.am file because I needed to "./autogen.sh" instead of > "configure". Oh, well that's one. > > Have lotsa fun... Oh I did. BTW, where did you get that tarball? It's not posted at the URL referenced in your spec file. Is it a CVS d/l? Anyway, since they haven't issued it as stable I slipped back to the 1.0.1 release. I also had to do a little sleuthing to get everything in the docs and the program to agree to call itself "xmlstarlet". The results are ref'd in the Bugzilla entry: https://bugzilla.redhat.com/173924 -- Paul W. Frields, RHCE http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 Fedora Documentation Project: http://fedora.redhat.com/projects/docs/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From brads at redhat.com Wed Nov 23 20:21:38 2005 From: brads at redhat.com (Brad Smith) Date: Wed, 23 Nov 2005 15:21:38 -0500 Subject: Best tagging practice: multi-key sequences? Message-ID: <4384CF52.7090408@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello all, I've come upon another scenario where I'm unsure what the best tagging practice would be. In general, if a user is instructed to perform a key combo we use the keycombo and keycap tags: Press Ctrl Alt Del to initiate a reboot. or, in the case of a key sequence, something like: Press Esc, . to recall the last argument of the last command in bash When the user is being asked to type in text, we use userinput: Enter the text I like penguins! into text document. The issue is that we're now marking up documentation that deals with using vi and things are becoming a bit more ambiguous. What about an instruction like: To save and quit, press :wq while in command mode Technically, since :wq is a set of keypresses, rather than arbitrary text that the user is entering, it seems that it should be marked up as :, w, q ...but that is awfully klunky. We've instead been opting for :wq even though that is arguably incorrect. The FDP docs guide doesn't really address situations like this (multi-key sequences) directly, so is there an informal standard we should know about before settling on one or the other? - --Brad -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFDhM8uDvp49DvQ8kcRAh+GAJ9R0hFXizWMNfZj2+5xbQR7duyoYQCfd58G XNqh9lHZpPUen67vtwEddow= =im/R -----END PGP SIGNATURE----- From Tommy.Reynolds at MegaCoder.com Wed Nov 23 20:35:44 2005 From: Tommy.Reynolds at MegaCoder.com (Tommy Reynolds) Date: Wed, 23 Nov 2005 14:35:44 -0600 Subject: Best tagging practice: multi-key sequences? In-Reply-To: <4384CF52.7090408@redhat.com> References: <4384CF52.7090408@redhat.com> Message-ID: <20051123143544.d464c77b.Tommy.Reynolds@MegaCoder.com> Uttered Brad Smith , spake thus: > The FDP docs guide doesn't really address situations like this > (multi-key sequences) directly, so is there an informal standard we > should know about before settling on one or the other? My rule of thumb is that printable characters are shown as simply a string. Sequences with non-printing characters are exploded as you demonstrate. No need to obfusticate the obvious. If you can read it, it's a string; if not it's separate characters. Now, if you are thinking about chords, such as Ctl-Alt-Del, then you've just seen my rendering ;-) Cheers -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From brads at redhat.com Wed Nov 23 20:57:29 2005 From: brads at redhat.com (Brad Smith) Date: Wed, 23 Nov 2005 15:57:29 -0500 Subject: Best tagging practice: multi-key sequences? In-Reply-To: <20051123143544.d464c77b.Tommy.Reynolds@MegaCoder.com> References: <4384CF52.7090408@redhat.com> <20051123143544.d464c77b.Tommy.Reynolds@MegaCoder.com> Message-ID: <4384D7B9.5040405@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Tommy Reynolds wrote: > Uttered Brad Smith , spake thus: > > >>The FDP docs guide doesn't really address situations like this >>(multi-key sequences) directly, so is there an informal standard we >>should know about before settling on one or the other? > > > My rule of thumb is that printable characters are shown as simply a string. You mean without any markup at all? I'm not sure about that. After all, everything else (commands, user input, key combos) are tagged in such a way that they will be visually differentiated from the rest of the text. I think it would look inconsistent if only these instructions were treated as regular text so, for our purposes, I think we definitely need to tag it with something, I'm just unsure what. Thank you for the input, - --Brad -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFDhNe5Dvp49DvQ8kcRAvJCAJ4lIo9AxuJr6HcKt6p51jxtL53OfACfUQL4 8xsUOqyJx1sCw3tM3jm4wk8= =d92L -----END PGP SIGNATURE----- From Tommy.Reynolds at MegaCoder.com Wed Nov 23 21:10:38 2005 From: Tommy.Reynolds at MegaCoder.com (Tommy Reynolds) Date: Wed, 23 Nov 2005 15:10:38 -0600 Subject: Best tagging practice: multi-key sequences? In-Reply-To: <4384D7B9.5040405@redhat.com> References: <4384CF52.7090408@redhat.com> <20051123143544.d464c77b.Tommy.Reynolds@MegaCoder.com> <4384D7B9.5040405@redhat.com> Message-ID: <20051123151038.71e0cd21.Tommy.Reynolds@MegaCoder.com> Uttered Brad Smith , spake thus: > I think it would look inconsistent if only these instructions were > treated as regular text so, for our purposes, I think we > definitely need to tag it with something, I'm just unsure what. Well, :wq, of course. and are not "key strokes", they are silkscreen labels and ROM values. Just my $0.02e+48 on it. Cheers -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From brads at redhat.com Wed Nov 23 21:12:11 2005 From: brads at redhat.com (Brad Smith) Date: Wed, 23 Nov 2005 16:12:11 -0500 Subject: Best tagging practice: multi-key sequences? In-Reply-To: <20051123151038.71e0cd21.Tommy.Reynolds@MegaCoder.com> References: <4384CF52.7090408@redhat.com> <20051123143544.d464c77b.Tommy.Reynolds@MegaCoder.com> <4384D7B9.5040405@redhat.com> <20051123151038.71e0cd21.Tommy.Reynolds@MegaCoder.com> Message-ID: <4384DB2B.9090708@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Tommy Reynolds wrote: > Uttered Brad Smith , spake thus: > > >>I think it would look inconsistent if only these instructions were >>treated as regular text so, for our purposes, I think we >>definitely need to tag it with something, I'm just unsure what. > > > Well, :wq, of course. and > are not "key strokes", they are silkscreen labels and ROM values. > > Just my $0.02e+48 on it. > > Cheers > Ok, so a good way of codifying this would be: For typed-in characters, use . Nonprintable characters should be wrapped in eg: Enter: Heading 1 Tab Heading 2 Enter into a text document to begin a simple table. Sounds good. I'll add this to our style guide. Thanks again for helping clarify this, - --Brad -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFDhNsqDvp49DvQ8kcRAp4NAJ9UoZizDOOFm2gXFKM8IMWj29eosQCfZXx9 F2dfxMr3+DtGdF3RrUWHDhI= =wJKo -----END PGP SIGNATURE----- From stickster at gmail.com Wed Nov 23 23:11:23 2005 From: stickster at gmail.com (Paul W. Frields) Date: Wed, 23 Nov 2005 18:11:23 -0500 Subject: Best tagging practice: multi-key sequences? In-Reply-To: <4384DB2B.9090708@redhat.com> References: <4384CF52.7090408@redhat.com> <20051123143544.d464c77b.Tommy.Reynolds@MegaCoder.com> <4384D7B9.5040405@redhat.com> <20051123151038.71e0cd21.Tommy.Reynolds@MegaCoder.com> <4384DB2B.9090708@redhat.com> Message-ID: <1132787483.2990.6.camel@localhost.localdomain> On Wed, 2005-11-23 at 16:12 -0500, Brad Smith wrote: > Tommy Reynolds wrote: > > Uttered Brad Smith , spake thus: > >>I think it would look inconsistent if only these instructions were > >>treated as regular text so, for our purposes, I think we > >>definitely need to tag it with something, I'm just unsure what. > > > > Well, :wq, of course. and > > are not "key strokes", they are silkscreen labels and ROM values. > > Ok, so a good way of codifying this would be: > > For typed-in characters, use . Nonprintable characters should > be wrapped in eg: > > Enter: Heading 1 Tab Heading 2 > Enter into a text document to begin a > simple table. I'm not sure if I got Tommy's meaning right, but I think what he was getting at didn't have to do with the difference between printable and nonprintable characters, but rather the difference between something the user types and sees echoed on the screen (like ":wq" in the vi example), as opposed to Ctrl+Alt+Del. The former would be a , while the latter would be a . At least that's how I took it. And if that's not what he meant, well, the above is what I think makes sense semantically and procedurally. In Emacs, for example (hush, Tommy) ;-) -- you might turn on a mode by using a combination of these physical actions, like M-x rpm-specfile-mode, which would be: Meta x rpm-specfile-mode -- Paul W. Frields, RHCE http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 Fedora Documentation Project: http://fedora.redhat.com/projects/docs/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From Tommy.Reynolds at MegaCoder.com Thu Nov 24 01:30:59 2005 From: Tommy.Reynolds at MegaCoder.com (Tommy Reynolds) Date: Wed, 23 Nov 2005 19:30:59 -0600 Subject: Best tagging practice: multi-key sequences? In-Reply-To: <1132787483.2990.6.camel@localhost.localdomain> References: <4384CF52.7090408@redhat.com> <20051123143544.d464c77b.Tommy.Reynolds@MegaCoder.com> <4384D7B9.5040405@redhat.com> <20051123151038.71e0cd21.Tommy.Reynolds@MegaCoder.com> <4384DB2B.9090708@redhat.com> <1132787483.2990.6.camel@localhost.localdomain> Message-ID: <20051123193059.e6eacf73.Tommy.Reynolds@MegaCoder.com> Uttered "Paul W. Frields" , spake thus: > I'm not sure if I got Tommy's meaning right, but I think what he was > getting at didn't have to do with the difference between printable and > nonprintable characters, but rather the difference between something the > user types and sees echoed on the screen (like ":wq" in the vi example), > as opposed to Ctrl+Alt+Del. Er, Paul, if you can see the echo: it's printable! More formally, I would reserve keycaps, et. al., to mark-up "function keys": F1 and friends, as well as Ctl+Alt+Del, including the you-would-never-type-this-character-in-typing-class category that emacs loves so well. Attend me. It matters not that VI treats ":wq" specially in some instances. What is important is that it's a readable sequence. All VI commands follow the general form of either "" like "4cw" or a logical process like "wq". Massively 'ing them destroys the semantics. On the other hand, the emacs key binding of "Ctl-C Ctl-F foo \n" is not readable and should be 'ed because there are two logical "function" keys introducing the sequence. If only emacs had the kind of keyboard it needed, there would be a special function key whose labels was "Funky Emacs Function". See the difference? A key or keys treated as a virtual function key should be 'ed; anything else is just . Reserve the family to convey the notion of a function key. And it just so happens that most logical function key combos are non-printing... That any better? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From stickster at gmail.com Thu Nov 24 13:34:05 2005 From: stickster at gmail.com (Paul W. Frields) Date: Thu, 24 Nov 2005 08:34:05 -0500 Subject: Best tagging practice: multi-key sequences? In-Reply-To: <20051123193059.e6eacf73.Tommy.Reynolds@MegaCoder.com> References: <4384CF52.7090408@redhat.com> <20051123143544.d464c77b.Tommy.Reynolds@MegaCoder.com> <4384D7B9.5040405@redhat.com> <20051123151038.71e0cd21.Tommy.Reynolds@MegaCoder.com> <4384DB2B.9090708@redhat.com> <1132787483.2990.6.camel@localhost.localdomain> <20051123193059.e6eacf73.Tommy.Reynolds@MegaCoder.com> Message-ID: <1132839245.6253.2.camel@localhost.localdomain> On Wed, 2005-11-23 at 19:30 -0600, Tommy Reynolds wrote: > Uttered "Paul W. Frields" , spake thus: > > > I'm not sure if I got Tommy's meaning right, but I think what he was > > getting at didn't have to do with the difference between printable and > > nonprintable characters, but rather the difference between something the > > user types and sees echoed on the screen (like ":wq" in the vi example), > > as opposed to Ctrl+Alt+Del. > > Er, Paul, if you can see the echo: it's printable! Ah, but in Emacs the special function keys *are* echoed to the screen. Which, now that I think about it, makes the explanation below a better fit with how I think the markup should go. > More formally, I would reserve keycaps, et. al., to mark-up "function > keys": F1 and friends, as well as Ctl+Alt+Del, including the > you-would-never-type-this-character-in-typing-class category that > emacs loves so well. > > Attend me. It matters not that VI treats ":wq" specially in some > instances. What is important is that it's a readable sequence. All > VI commands follow the general form of either "" > like "4cw" or a logical process like "wq". Massively 'ing them > destroys the semantics. On the other hand, the emacs key binding of > "Ctl-C Ctl-F foo \n" is not readable and should be 'ed > because there are two logical "function" keys introducing the > sequence. If only emacs had the kind of keyboard it needed, there > would be a special function key whose labels was "Funky Emacs > Function". I'll nobly resist rising to your baiting remarks, sir! ;-D > See the difference? A key or keys treated as a virtual function key > should be 'ed; anything else is just . Reserve > the family to convey the notion of a function key. > > And it just so happens that most logical function key combos are > non-printing... > > That any better? I think you better said the thing that I meant, so yes! -- Paul W. Frields, RHCE http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 Fedora Documentation Project: http://fedora.redhat.com/projects/docs/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From stickster at gmail.com Thu Nov 24 13:36:43 2005 From: stickster at gmail.com (Paul W. Frields) Date: Thu, 24 Nov 2005 08:36:43 -0500 Subject: OT: By the way... Message-ID: <1132839404.6253.6.camel@localhost.localdomain> Happy Thanksgiving to those who celebrate it! And let me heartily recommend brining your turkey before you cook it... you'll thank me after dinner! http://www.foodnetwork.com/food/recipes/recipe/0,1977,FOOD_9936_8389,00.html -- Paul W. Frields, RHCE http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 Fedora Documentation Project: http://fedora.redhat.com/projects/docs/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From Tommy.Reynolds at MegaCoder.com Thu Nov 24 14:58:36 2005 From: Tommy.Reynolds at MegaCoder.com (Tommy Reynolds) Date: Thu, 24 Nov 2005 08:58:36 -0600 Subject: OT: By the way... In-Reply-To: <1132839404.6253.6.camel@localhost.localdomain> References: <1132839404.6253.6.camel@localhost.localdomain> Message-ID: <20051124085836.47858824.Tommy.Reynolds@MegaCoder.com> Uttered "Paul W. Frields" , spake thus: > http://www.foodnetwork.com/food/recipes/recipe/0,1977,FOOD_9936_8389,00.html Ah, Food TV! If ever Paula Deen and I are single at the same time... Cheers -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Tommy.Reynolds at MegaCoder.com Fri Nov 25 21:14:40 2005 From: Tommy.Reynolds at MegaCoder.com (Tommy Reynolds) Date: Fri, 25 Nov 2005 15:14:40 -0600 Subject: [RFC] Packaging technology update Message-ID: <20051125151440.03bc8873.Tommy.Reynolds@MegaCoder.com> Hello, All! As part of getting the RPM's built for the Fedora documents, there are a number of files necessarily that all must be consistent. For example, there is a revision history within the DocBook document itself and a similar one for the RPM package. There is an author / editor / translator list for the DocBook information and a similar list for the RPM. The list goes on, but you get the idea. Since I'm lazy and don't want to do the same task twice, I've developed some XSLT stylesheets that will generate: 1) the or information in the DocBook itself; 2) the OMF file needed for the yelp integration; 3) the ".desktop" file needed for the GNOME menu system; 4) the ".spec" file needed for the RPM packaging. All that is needed is for the authors, translators, and editors to enter the information once in an "rpm-info.xml" file. Then, the document build system Makefile.common will be able to automatically generate the derivative files as needed. So that you can get an idea of how this will work, I've also added a sample "rpm-info.xml" file to the Example Tutorial. To see this work, type the following command from the "example-tutorial/" directory: $ xsltproc --stringparam doctype articleinfo \ ../docs-common/packaging/bookinfo.xsl rpm-info.txt When we get this worked out, we will redirect this generated XML into a file and the base document will include it rather than having the stuff hardcoded within it. As new translations are added to the document, the translator just adds the new locale to the Makefile ${LANGUAGES} macro and updates "rpm-info.xml" with the translated document name and description. Everything else adapts itself to the new information and out comes a localized RPM package. This is just the plan, we're not quite there yet, but we're very close. The rest of this is probably of interest only to KWADE and STICKSTER, but feel free to read along. In the "docs-common/packaging" directory are some new files: rpm-info.dtd -- DTD for the "rpm-info.xml" files bookinfo.xsl -- XSLT stylesheet to extract the stuff desktop.xsl -- XSLT stylesheet to build the "{docbase}.desktop" file omf.xsl -- XSLT stylesheet to generate the OMF file spec.xsl -- XSLT stylesheet to generate an RPM ".spec" file Of these XSLT stylesheets, "spec.xsl" is the most tentative. I'm not clear about how to structure the multi-language RPM generation yet, so I've put in some stubs to suggest how this technology could generate a customized SPEC file on the fly. Suggestions, praise and criticsm are all welcome! Cheers -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From stickster at gmail.com Sat Nov 26 01:07:24 2005 From: stickster at gmail.com (Paul W. Frields) Date: Fri, 25 Nov 2005 20:07:24 -0500 Subject: [RFC] Packaging technology update In-Reply-To: <20051125151440.03bc8873.Tommy.Reynolds@MegaCoder.com> References: <20051125151440.03bc8873.Tommy.Reynolds@MegaCoder.com> Message-ID: <1132967244.18594.2.camel@localhost.localdomain> On Fri, 2005-11-25 at 15:14 -0600, Tommy Reynolds wrote: > As part of getting the RPM's built for the Fedora documents, there > are a number of files necessarily that all must be consistent. For > example, there is a revision history within the DocBook document > itself and a similar one for the RPM package. There is an author / > editor / translator list for the DocBook information and a similar > list for the RPM. The list goes on, but you get the idea. > > Since I'm lazy and don't want to do the same task twice, I've > developed some XSLT stylesheets that will generate: [... a bunch of really cool stuff snipped ...] Very cool! Still looking over all of this, but I think one of the best things about this (besides all the general coolness) is that it keeps everything in the authoritative DocBook XML. This is a big step in the right direction. -- Paul W. Frields, RHCE http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 Fedora Documentation Project: http://fedora.redhat.com/projects/docs/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From stickster at gmail.com Sat Nov 26 17:56:21 2005 From: stickster at gmail.com (Paul W. Frields) Date: Sat, 26 Nov 2005 12:56:21 -0500 Subject: [RFC] Packaging technology update In-Reply-To: <20051125151440.03bc8873.Tommy.Reynolds@MegaCoder.com> References: <20051125151440.03bc8873.Tommy.Reynolds@MegaCoder.com> Message-ID: <1133027781.19749.13.camel@localhost.localdomain> More thoughts on the packaging work Tommy did... - Version numbers must be sane for revisionhistory entries. In the install-guide there was a 1.0rc1 followed by 1.0, which is decidedly *not* sane. (Ever the lemming, I then followed suit with 1.01rc1, which I have since eliminated in favor of 1.0.1 and followed by 1.0.2.) In the future, no alphabetics should be used. Runup to a X.0 should be $(X-1).9.9 or something similar. Remember that in RPM packaging terms, IIRC, 0.99 > 0.12 > 0.9.9, so we should probably eliminate any weirdness with double-digit numbering. Using x.y.z where both y and z are less than 10 is probably the right way to do things. If you need something even more minor, just make it x.y.z.n instead. - I made just a couple cosmetic changes to spec.xsl to be consistent with FE guidelines. - I wonder if it would be wise to have a change to the DTD which offers a 'release' in addition to 'version' for a 'revision', such that: would be allowed. The latest release number would be the thing that appears in the %release tag. The 'release' element that falls directly inside 'rpm-info' would be eliminated. There is always a chance that things have to be repackaged because an OMF or .desktop file is updated -- or even the spec template -- but not the doc content, which calls for a release bump, not a version bump. Is such a thing possible, Tommy? Just some quick ideas... I'm not really conversant with a lot of XSLT stuff so I may piddle around with this, but not expecting great things as a result. ;-) -- Paul W. Frields, RHCE http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 Fedora Documentation Project: http://fedora.redhat.com/projects/docs/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From Tommy.Reynolds at MegaCoder.com Sat Nov 26 19:18:49 2005 From: Tommy.Reynolds at MegaCoder.com (Tommy Reynolds) Date: Sat, 26 Nov 2005 13:18:49 -0600 Subject: [RFC] Packaging technology update In-Reply-To: <1133027781.19749.13.camel@localhost.localdomain> References: <20051125151440.03bc8873.Tommy.Reynolds@MegaCoder.com> <1133027781.19749.13.camel@localhost.localdomain> Message-ID: <20051126131849.c5c482d0.Tommy.Reynolds@MegaCoder.com> Uttered "Paul W. Frields" , spake thus: > - I wonder if it would be wise to have a change to the DTD which offers > a 'release' in addition to 'version' for a 'revision', such that: > > > > would be allowed. The latest release number would be the thing that > appears in the %release tag. The 'release' element that falls directly > inside 'rpm-info' would be eliminated. There is always a chance that > things have to be repackaged because an OMF or .desktop file is updated > -- or even the spec template -- but not the doc content, which calls for > a release bump, not a version bump. Is such a thing possible, Tommy? My thought was that the /rpm-info/release value would represent the RPM packaging release cycle. The components of the would generate both the RPM %changelog and the DocBook revision log. Hm.. would a "role='rpm'" attribute on the / element suffice? I could then just skip that entry when building the DocBook history. > Just some quick ideas... I'm not really conversant with a lot of XSLT > stuff so I may piddle around with this, but not expecting great things > as a result. ;-) Neither am I, but if you can help get the prototype SPEC, OMF, et. al., files right I think I can mangle the XSLT stuff enough to get by. Cheers -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From stickster at gmail.com Sat Nov 26 21:03:06 2005 From: stickster at gmail.com (Paul W. Frields) Date: Sat, 26 Nov 2005 16:03:06 -0500 Subject: [RFC] Packaging technology update In-Reply-To: <20051126131849.c5c482d0.Tommy.Reynolds@MegaCoder.com> References: <20051125151440.03bc8873.Tommy.Reynolds@MegaCoder.com> <1133027781.19749.13.camel@localhost.localdomain> <20051126131849.c5c482d0.Tommy.Reynolds@MegaCoder.com> Message-ID: <1133038986.3733.13.camel@localhost.localdomain> On Sat, 2005-11-26 at 13:18 -0600, Tommy Reynolds wrote: > Uttered "Paul W. Frields" , spake thus: > > > - I wonder if it would be wise to have a change to the DTD which offers > > a 'release' in addition to 'version' for a 'revision', such that: > > > > > > > > would be allowed. The latest release number would be the thing that > > appears in the %release tag. The 'release' element that falls directly > > inside 'rpm-info' would be eliminated. There is always a chance that > > things have to be repackaged because an OMF or .desktop file is updated > > -- or even the spec template -- but not the doc content, which calls for > > a release bump, not a version bump. Is such a thing possible, Tommy? > > My thought was that the /rpm-info/release value would represent the > RPM packaging release cycle. Ah, I see, that makes sense... IOW we would hope that if we do this right that might never change, right? Sorry, forget that snippet above, then. > The components of the > would generate both the RPM %changelog and the DocBook > revision log. > Hm.. would a "role='rpm'" attribute on the / > element suffice? I could then just skip that entry when building the > DocBook history. Well, I think having that sort of structure makes sense, in that some changes will be packaging only, and some changes will be document only. It probably makes sense for the document revision history to be in the RPM %changelog but not the other way around. What if we were to use some of the XSL "if" statements to perform some of that magic, and have a hierarchy like this: 2005-11-20 PWF
Some guff here
 Sat Nov 26 2005 Paul W. Frields stickster at gmail > > Just some quick ideas... I'm not really conversant with a lot of XSLT > > stuff so I may piddle around with this, but not expecting great things > > as a result. ;-) > > Neither am I, but if you can help get the prototype SPEC, OMF, et. > al., files right I think I can mangle the XSLT stuff enough to get > by. I am doing some DTD and XSLish reading... your new additions here have helped make this a lot easier for me to learn a bit, so thanks for that. I might play around with what's there, but will try not to break anything. ;-) -- Paul W. Frields, RHCE http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 Fedora Documentation Project: http://fedora.redhat.com/projects/docs/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From Tommy.Reynolds at MegaCoder.com Sat Nov 26 21:47:07 2005 From: Tommy.Reynolds at MegaCoder.com (Tommy Reynolds) Date: Sat, 26 Nov 2005 15:47:07 -0600 Subject: [RFC] Packaging technology update In-Reply-To: <1133038986.3733.13.camel@localhost.localdomain> References: <20051125151440.03bc8873.Tommy.Reynolds@MegaCoder.com> <1133027781.19749.13.camel@localhost.localdomain> <20051126131849.c5c482d0.Tommy.Reynolds@MegaCoder.com> <1133038986.3733.13.camel@localhost.localdomain> Message-ID: <20051126154707.f82f288b.Tommy.Reynolds@MegaCoder.com> Uttered "Paul W. Frields" , spake thus: > Well, I think having that sort of structure makes sense, in that some > changes will be packaging only, and some changes will be document only. You were right; I was wrong. I fixed this your way. There is now a "role='doc|rpm'" attribute to the changelog info. I ignore the "role='rpm'" entries when populating the DocBook revhistory. So there ;-) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From stickster at gmail.com Sat Nov 26 22:04:11 2005 From: stickster at gmail.com (Paul W. Frields) Date: Sat, 26 Nov 2005 17:04:11 -0500 Subject: [RFC] Packaging technology update In-Reply-To: <1133038986.3733.13.camel@localhost.localdomain> References: <20051125151440.03bc8873.Tommy.Reynolds@MegaCoder.com> <1133027781.19749.13.camel@localhost.localdomain> <20051126131849.c5c482d0.Tommy.Reynolds@MegaCoder.com> <1133038986.3733.13.camel@localhost.localdomain> Message-ID: <1133042652.3733.25.camel@localhost.localdomain> On Sat, 2005-11-26 at 16:03 -0500, Paul W. Frields wrote: > > The components of the > > would generate both the RPM %changelog and the DocBook > > revision log. > > > Hm.. would a "role='rpm'" attribute on the / > > element suffice? I could then just skip that entry when building the > > DocBook history. > > Well, I think having that sort of structure makes sense, in that some > changes will be packaging only, and some changes will be document only. > It probably makes sense for the document revision history to be in the > RPM %changelog but not the other way around. What if we were to use > some of the XSL "if" statements to perform some of that magic, and have > a hierarchy like this: > > > > 2005-11-20 > PWF >
Some guff here
> > > Sat Nov 26 2005 > > Paul W. Frields > stickster at gmail > > > Maybe the following might prove easier: 2005-11-20 PWF
Some guff here
 Sat Nov 26 2005 Paul W. Frields stickster at gmail
Fixed OMF
Did something else important
 Amazing what a little DTD reading will teach ya... I'm startin' to understand some of this here XML guff. Unfortunately while I was composing this you had already improved the DTD! I'm wondering whether it makes sense to have these two elements be different since they want for different data. On the one hand, you could just ask for a big author element with attributes for all of them, as is the case now. On the other hand, a RPM %changelog often has more than one explanatory line for details. I will try my hand at this one if you agree, since I don't want to try your patience, and since I want to see if I understand the concept well enough to DIY. (DIM?) I suppose, thanks to your display of XML skillz, we can even validate this info during the build process to make sure nothing breaks! Sweet. -- Paul W. Frields, RHCE http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 Fedora Documentation Project: http://fedora.redhat.com/projects/docs/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From stickster at gmail.com Sat Nov 26 22:06:21 2005 From: stickster at gmail.com (Paul W. Frields) Date: Sat, 26 Nov 2005 17:06:21 -0500 Subject: [RFC] Packaging technology update In-Reply-To: <1133042652.3733.25.camel@localhost.localdomain> References: <20051125151440.03bc8873.Tommy.Reynolds@MegaCoder.com> <1133027781.19749.13.camel@localhost.localdomain> <20051126131849.c5c482d0.Tommy.Reynolds@MegaCoder.com> <1133038986.3733.13.camel@localhost.localdomain> <1133042652.3733.25.camel@localhost.localdomain> Message-ID: <1133042782.3733.28.camel@localhost.localdomain> On Sat, 2005-11-26 at 17:04 -0500, Paul W. Frields wrote: > Maybe the following might prove easier: > > [...snip...] Maybe valid XML would be easier. :-D Should read: 2005-11-20 PWF
Some guff here
 Sat Nov 26 2005 Paul W. Frields stickster at gmail
Fixed OMF
Did something else important
 -- Paul W. Frields, RHCE http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 Fedora Documentation Project: http://fedora.redhat.com/projects/docs/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From kwade at redhat.com Sun Nov 27 05:50:08 2005 From: kwade at redhat.com (Karsten Wade) Date: Sat, 26 Nov 2005 21:50:08 -0800 Subject: OT: By the way... In-Reply-To: <1132839404.6253.6.camel@localhost.localdomain> References: <1132839404.6253.6.camel@localhost.localdomain> Message-ID: <1133070608.935.240.camel@erato.phig.org> On Thu, 2005-11-24 at 08:36 -0500, Paul W. Frields wrote: > Happy Thanksgiving to those who celebrate it! And let me heartily > recommend brining your turkey before you cook it... you'll thank me > after dinner! > > http://www.foodnetwork.com/food/recipes/recipe/0,1977,FOOD_9936_8389,00.html No problems with the gravy/pan drippings being too salty? Other than that, I enjoyed the brine method, tried it a few years back. cheers - Karsten, who resorted to the tried-n-true herb butter stuffing for the breast and legs -- Karsten Wade, RHCE * Sr. Tech Writer * http://people.redhat.com/kwade/ gpg fingerprint: 2680 DBFD D968 3141 0115 5F1B D992 0E06 AD0E 0C41 Content Services Fedora Documentation Project http://www.redhat.com/docs http://fedoraproject.org/wiki/DocsProject -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From Tommy.Reynolds at MegaCoder.com Sun Nov 27 15:40:34 2005 From: Tommy.Reynolds at MegaCoder.com (Tommy Reynolds) Date: Sun, 27 Nov 2005 09:40:34 -0600 Subject: [RFC] Packaging technology update In-Reply-To: <1133042652.3733.25.camel@localhost.localdomain> References: <20051125151440.03bc8873.Tommy.Reynolds@MegaCoder.com> <1133027781.19749.13.camel@localhost.localdomain> <20051126131849.c5c482d0.Tommy.Reynolds@MegaCoder.com> <1133038986.3733.13.camel@localhost.localdomain> <1133042652.3733.25.camel@localhost.localdomain> Message-ID: <20051127094034.000210d7.Tommy.Reynolds@MegaCoder.com> Uttered "Paul W. Frields" , spake thus: > On the other hand, a RPM %changelog often has more than one > explanatory line for details. I will try my hand at this one if > you agree, since I don't want to try your patience, and since I > want to see if I understand the concept well enough to DIY. (DIM?) Go ahead and welcome. I just didn't have time to investigate line wrapping the %changelog entries, but I'd be happy for your to take a swing. > I suppose, thanks to your display of XML skillz, we can even validate > this info during the build process to make sure nothing breaks! Sweet. BTW, order matters in the %changelog entries. I always take the version and release numbers from the very first element. That's why there is that mandatory, only-one-alternative "ordered=" attribute; it's really documentation. Cheers -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From stickster at gmail.com Sun Nov 27 15:50:16 2005 From: stickster at gmail.com (Paul W. Frields) Date: Sun, 27 Nov 2005 10:50:16 -0500 Subject: [RFC] Packaging technology update In-Reply-To: <20051127094034.000210d7.Tommy.Reynolds@MegaCoder.com> References: <20051125151440.03bc8873.Tommy.Reynolds@MegaCoder.com> <1133027781.19749.13.camel@localhost.localdomain> <20051126131849.c5c482d0.Tommy.Reynolds@MegaCoder.com> <1133038986.3733.13.camel@localhost.localdomain> <1133042652.3733.25.camel@localhost.localdomain> <20051127094034.000210d7.Tommy.Reynolds@MegaCoder.com> Message-ID: <1133106616.7543.22.camel@localhost.localdomain> On Sun, 2005-11-27 at 09:40 -0600, Tommy Reynolds wrote: > Uttered "Paul W. Frields" , spake thus: > > > On the other hand, a RPM %changelog often has more than one > > explanatory line for details. I will try my hand at this one if > > you agree, since I don't want to try your patience, and since I > > want to see if I understand the concept well enough to DIY. (DIM?) > > Go ahead and welcome. I just didn't have time to investigate line > wrapping the %changelog entries, but I'd be happy for your to take a > swing. > > > I suppose, thanks to your display of XML skillz, we can even validate > > this info during the build process to make sure nothing breaks! Sweet. > > BTW, order matters in the %changelog entries. I always take the > version and release numbers from the very first element. > That's why there is that mandatory, only-one-alternative "ordered=" > attribute; it's really documentation. Cool, that means I grokked it right. Although that means revision histories will be written differently than they are now, that's not a problem. DocBook doesn't mandate an order for them, so any way we want to do them is acceptable. -- Paul W. Frields, RHCE http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 Fedora Documentation Project: http://fedora.redhat.com/projects/docs/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From Tommy.Reynolds at MegaCoder.com Sun Nov 27 15:56:55 2005 From: Tommy.Reynolds at MegaCoder.com (Tommy Reynolds) Date: Sun, 27 Nov 2005 09:56:55 -0600 Subject: [RFC] Packaging technology update In-Reply-To: <1133106616.7543.22.camel@localhost.localdomain> References: <20051125151440.03bc8873.Tommy.Reynolds@MegaCoder.com> <1133027781.19749.13.camel@localhost.localdomain> <20051126131849.c5c482d0.Tommy.Reynolds@MegaCoder.com> <1133038986.3733.13.camel@localhost.localdomain> <1133042652.3733.25.camel@localhost.localdomain> <20051127094034.000210d7.Tommy.Reynolds@MegaCoder.com> <1133106616.7543.22.camel@localhost.localdomain> Message-ID: <20051127095655.3f2848f4.Tommy.Reynolds@MegaCoder.com> Uttered "Paul W. Frields" , spake thus: > Although that means revision histories will be written differently > than they are now, that's not a problem. DocBook doesn't mandate > an order for them, so any way we want to do them is acceptable. Well, we can output the changelog in any order we choose. Instead of an construct, something along the lines of "blah/blah/revision[count()-position()]" could reverse the order. I figured that nicety could wait. Cheers -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From stickster at gmail.com Sun Nov 27 17:42:54 2005 From: stickster at gmail.com (Paul W. Frields) Date: Sun, 27 Nov 2005 12:42:54 -0500 Subject: [RFC] Packaging technology update In-Reply-To: <20051127095655.3f2848f4.Tommy.Reynolds@MegaCoder.com> References: <20051125151440.03bc8873.Tommy.Reynolds@MegaCoder.com> <1133027781.19749.13.camel@localhost.localdomain> <20051126131849.c5c482d0.Tommy.Reynolds@MegaCoder.com> <1133038986.3733.13.camel@localhost.localdomain> <1133042652.3733.25.camel@localhost.localdomain> <20051127094034.000210d7.Tommy.Reynolds@MegaCoder.com> <1133106616.7543.22.camel@localhost.localdomain> <20051127095655.3f2848f4.Tommy.Reynolds@MegaCoder.com> Message-ID: <1133113374.7543.36.camel@localhost.localdomain> On Sun, 2005-11-27 at 09:56 -0600, Tommy Reynolds wrote: > Uttered "Paul W. Frields" , spake thus: > > > Although that means revision histories will be written differently > > than they are now, that's not a problem. DocBook doesn't mandate > > an order for them, so any way we want to do them is acceptable. > > Well, we can output the changelog in any order we choose. Instead of > an construct, something along the lines of > "blah/blah/revision[count()-position()]" could reverse the order. > > I figured that nicety could wait. Yeah, I'm starting to realize the more reading I do that XSLT is pretty danged powerful. And yes, I am in fact late to the party, as usual. ;-D -- Paul W. Frields, RHCE http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 Fedora Documentation Project: http://fedora.redhat.com/projects/docs/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From Tommy.Reynolds at MegaCoder.com Sun Nov 27 21:17:44 2005 From: Tommy.Reynolds at MegaCoder.com (Tommy Reynolds) Date: Sun, 27 Nov 2005 15:17:44 -0600 Subject: [RFC] Packaging technology update In-Reply-To: <1133042782.3733.28.camel@localhost.localdomain> References: <20051125151440.03bc8873.Tommy.Reynolds@MegaCoder.com> <1133027781.19749.13.camel@localhost.localdomain> <20051126131849.c5c482d0.Tommy.Reynolds@MegaCoder.com> <1133038986.3733.13.camel@localhost.localdomain> <1133042652.3733.25.camel@localhost.localdomain> <1133042782.3733.28.camel@localhost.localdomain> Message-ID: <20051127151744.1f526b8b.Tommy.Reynolds@MegaCoder.com> Uttered "Paul W. Frields" , spake thus: > Maybe valid XML would be easier. :-D Should read: > > > 2005-11-20 > PWF >
Some guff here
> > > Sat Nov 26 2005 > > Paul W. Frields > stickster at gmail >
Fixed OMF
>
Did something else important
> > > I don't really like this / stuff. The "role=doc" or "role=rpm" more succinctly captures the reason for a particular change having been made. I hope this is not a NIH issue, but having frobbed around with the XSLT stylesheets a bit, I think I like my approach better. How about we keep the CVS versions of the DTD and XSLT stylesheets in sync? Cheers -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From stickster at gmail.com Sun Nov 27 23:28:18 2005 From: stickster at gmail.com (Paul W. Frields) Date: Sun, 27 Nov 2005 18:28:18 -0500 Subject: [RFC] Packaging technology update In-Reply-To: <20051127151744.1f526b8b.Tommy.Reynolds@MegaCoder.com> References: <20051125151440.03bc8873.Tommy.Reynolds@MegaCoder.com> <1133027781.19749.13.camel@localhost.localdomain> <20051126131849.c5c482d0.Tommy.Reynolds@MegaCoder.com> <1133038986.3733.13.camel@localhost.localdomain> <1133042652.3733.25.camel@localhost.localdomain> <1133042782.3733.28.camel@localhost.localdomain> <20051127151744.1f526b8b.Tommy.Reynolds@MegaCoder.com> Message-ID: <1133134098.3664.13.camel@localhost.localdomain> On Sun, 2005-11-27 at 15:17 -0600, Tommy Reynolds wrote: > Uttered "Paul W. Frields" , spake thus: > > > Maybe valid XML would be easier. :-D Should read: > > > > > > 2005-11-20 > > PWF > >
Some guff here
> > > > > > Sat Nov 26 2005 > > > > Paul W. Frields > > stickster at gmail > >
Fixed OMF
> >
Did something else important
> > > > > > > > I don't really like this / stuff. The > "role=doc" or "role=rpm" more succinctly captures the reason for a > particular change having been made. I hope this is not a NIH issue, > but having frobbed around with the XSLT stylesheets a bit, I think I > like my approach better. I'm not opposed to it, just wanted to float some ideas. I'm OK with the role attribute too... It would be nice, though, to *not* have to enter all the extraneous name info in contexts where it won't be used. For example, doc revisions only need the person's initials to generate a revision entry, where RPM revisions need the person's full name and email. (BTW, generating the full name from the firstname and surname doesn't work for some people, like me for instance.) > How about we keep the CVS versions of the DTD and XSLT stylesheets in sync? Sure, as I noted in previous posts, I was just experimenting to see if I understood DTDs well enough to make changes to this one and write a new rpm-info.xml against it. Experiment successful, now I can roll back to the previous version, no problem, and move on from there. I do want to actually move the content out of attributes and into elements where it seems more in keeping with standard XML usage, but I'll update the XSLT as needed to do that. What do you think about simply making the various pieces of optional so that they can be used as necessary? Or is there a way to make subelements dependent on the parent element's attribute? I am still reading up on that... In the meantime I've reverted the aforementioned files. -- Paul W. Frields, RHCE http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 Fedora Documentation Project: http://fedora.redhat.com/projects/docs/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From Tommy.Reynolds at MegaCoder.com Mon Nov 28 01:38:27 2005 From: Tommy.Reynolds at MegaCoder.com (Tommy Reynolds) Date: Sun, 27 Nov 2005 19:38:27 -0600 Subject: [RFC] Packaging technology update In-Reply-To: <1133134098.3664.13.camel@localhost.localdomain> References: <20051125151440.03bc8873.Tommy.Reynolds@MegaCoder.com> <1133027781.19749.13.camel@localhost.localdomain> <20051126131849.c5c482d0.Tommy.Reynolds@MegaCoder.com> <1133038986.3733.13.camel@localhost.localdomain> <1133042652.3733.25.camel@localhost.localdomain> <1133042782.3733.28.camel@localhost.localdomain> <20051127151744.1f526b8b.Tommy.Reynolds@MegaCoder.com> <1133134098.3664.13.camel@localhost.localdomain> Message-ID: <20051127193827.834a829d.Tommy.Reynolds@MegaCoder.com> Uttered "Paul W. Frields" , spake thus: > It would be nice, though, to *not* have to enter all the extraneous > name info in contexts where it won't be used. For example, doc > revisions only need the person's initials to generate a revision > entry, where RPM revisions need the person's full name and email. > (BTW, generating the full name from the firstname and surname > doesn't work for some people, like me for instance.) I know. That's why I have all those names, name parts, initials, combinations and permutations like "wholename" in there. From that, I generate the DocBook's and entries. Think of the rpm-info file as sort of a database where we can squirrel away (potentially) useful data and then produce wonderous results without resorting to custom surgery. > I do want to actually move the content out of attributes and into > elements where it seems more in keeping with standard XML usage, > but I'll update the XSLT as needed to do that. Be very cautious here. I used attributes because they can make searching and selection easier. There has long been a war between the attribute folks and the sub-element folks, but then an emacs user should be familiar with that sort of thing ;-) > What do you think about simply making the various pieces of > optional so that they can be used as necessary? If these items are optional, then we must know _now_ how we are going to use this info _later_. However, I *do* wish XML had some sort of static structure declaration. Until we get the building process up and working, we really have nothing to streamline. I'll listen to discussion like this later. To me, the key point of this exercise has been that we can plop all the packaging information into a single meta file and fairly easily derive whatever we need from it; I hate changing the same info all over creation. Thanks for helping! Cheers -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From stickster at gmail.com Mon Nov 28 02:48:18 2005 From: stickster at gmail.com (Paul W. Frields) Date: Sun, 27 Nov 2005 21:48:18 -0500 Subject: [RFC] Packaging technology updateUttered "Paul W. Frields" , spake thus: In-Reply-To: <20051127193827.834a829d.Tommy.Reynolds@MegaCoder.com> References: <20051125151440.03bc8873.Tommy.Reynolds@MegaCoder.com> <1133027781.19749.13.camel@localhost.localdomain> <20051126131849.c5c482d0.Tommy.Reynolds@MegaCoder.com> <1133038986.3733.13.camel@localhost.localdomain> <1133042652.3733.25.camel@localhost.localdomain> <1133042782.3733.28.camel@localhost.localdomain> <20051127151744.1f526b8b.Tommy.Reynolds@MegaCoder.com> <1133134098.3664.13.camel@localhost.localdomain> <20051127193827.834a829d.Tommy.Reynolds@MegaCoder.com> Message-ID: <1133146099.3664.20.camel@localhost.localdomain> On Sun, 2005-11-27 at 19:38 -0600, Tommy Reynolds wrote: > Uttered "Paul W. Frields" , spake thus: > > > It would be nice, though, to *not* have to enter all the extraneous > > name info in contexts where it won't be used. For example, doc > > revisions only need the person's initials to generate a revision > > entry, where RPM revisions need the person's full name and email. > > (BTW, generating the full name from the firstname and surname > > doesn't work for some people, like me for instance.) > > I know. That's why I have all those names, name parts, initials, > combinations and permutations like "wholename" in there. From that, > I generate the DocBook's and entries. > > Think of the rpm-info file as sort of a database where we can > squirrel away (potentially) useful data and then produce wonderous > results without resorting to custom surgery. Right, I understood this. > > I do want to actually move the content out of attributes and into > > elements where it seems more in keeping with standard XML usage, > > but I'll update the XSLT as needed to do that. > > Be very cautious here. I used attributes because they can make > searching and selection easier. There has long been a war between > the attribute folks and the sub-element folks, but then an emacs user > should be familiar with that sort of thing ;-) I did google my way to some advice on this, the simplest explanation being "if there's no required order to the content, use attributes." That makes sense to me. -- Paul W. Frields, RHCE http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 Fedora Documentation Project: http://fedora.redhat.com/projects/docs/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From mospina at redhat.com Tue Nov 29 02:00:16 2005 From: mospina at redhat.com (Manuel Eduardo Ospina Sarmiento) Date: Tue, 29 Nov 2005 12:00:16 +1000 Subject: Document translation Message-ID: <1133229616.4664.47.camel@dhcp-118.brisbane.redhat.com> Hi, I have some question regarding the translation of documents: 1. To access the CVS server, do translators need a new ssh-key (and account) or they can use the same one used to translate packages. 2. Are we still using cvs.fedora.redhat.com:/cvs/docs ? 3. Can individual translators modified the Makefile or they should report the list? Cheers, Manuel From nman64 at n-man.com Tue Nov 29 02:35:52 2005 From: nman64 at n-man.com (Patrick Barnes) Date: Mon, 28 Nov 2005 20:35:52 -0600 Subject: Document translation In-Reply-To: <1133229616.4664.47.camel@dhcp-118.brisbane.redhat.com> References: <1133229616.4664.47.camel@dhcp-118.brisbane.redhat.com> Message-ID: <438BBE88.5060501@n-man.com> Manuel Eduardo Ospina Sarmiento wrote: > Hi, > > I have some question regarding the translation of documents: > 1. To access the CVS server, do translators need a new ssh-key (and > account) or they can use the same one used to translate packages. > You can use the same SSH key for all things. > 2. Are we still using cvs.fedora.redhat.com:/cvs/docs ? > Yes. > 3. Can individual translators modified the Makefile or they should > report the list? > Usually best to check with the list first. If an agreement has been reached, you can make changes yourself. > Cheers, > Manuel > > > > -- Patrick "The N-Man" Barnes nman64 at n-man.com www.n-man.com -- -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From shaunm at gnome.org Tue Nov 29 19:31:53 2005 From: shaunm at gnome.org (Shaun McCance) Date: Tue, 29 Nov 2005 13:31:53 -0600 Subject: Docs packaging and Yelp Message-ID: <1133292713.25828.26.camel@shaunmlx> I'm on fedora-docs-list, but I'm afraid I can't usually manage to stay current with it. So my apologies for coming back to this discussion late in the game. I am one of the maintainers of Yelp, Gnome's help browser. It's my understanding that Matthias Clasen has patched Yelp to display some of the Fedora documentation on the front page. There was a lot of talk in threads on this list about how to manage things with upstream. Currently, we have a situation where at least Ubuntu and Fedora are both patching Yelp in different ways to accomplish the same thing, which rather sucks. Ubuntu did contact me about this, but we were unable to work something out in the time-frame they needed, so they ended up doing their own hack. One reason we had problems is that I wasn't sure how best to make this work for all downstream distributors. Just as a point of reference, in the future, when there's some question as to how to coordinate things with upstream, you might consider actually contacting the upstream developers. I know how Ubuntu changed Yelp. And my understanding is that Fedora is just putting General|Linux|Distributions|Other on the front page. I assume this was done by changing scrollkeeper.xml slightly. Could somebody send me the patch? With a clear idea of how both Ubuntu and Fedora have done this, we should be able to produce a better upstream method in 2.14 or 2.16. // Shaun From mclasen at redhat.com Tue Nov 29 19:37:25 2005 From: mclasen at redhat.com (Matthias Clasen) Date: Tue, 29 Nov 2005 14:37:25 -0500 Subject: Docs packaging and Yelp In-Reply-To: <1133292713.25828.26.camel@shaunmlx> References: <1133292713.25828.26.camel@shaunmlx> Message-ID: <1133293045.19836.2.camel@golem.boston.redhat.com> On Tue, 2005-11-29 at 13:31 -0600, Shaun McCance wrote: > I'm on fedora-docs-list, but I'm afraid I can't usually manage > to stay current with it. So my apologies for coming back to > this discussion late in the game. I am one of the maintainers > of Yelp, Gnome's help browser. > > It's my understanding that Matthias Clasen has patched Yelp > to display some of the Fedora documentation on the front page. > There was a lot of talk in threads on this list about how to > manage things with upstream. > > Currently, we have a situation where at least Ubuntu and Fedora > are both patching Yelp in different ways to accomplish the same > thing, which rather sucks. Ubuntu did contact me about this, > but we were unable to work something out in the time-frame they > needed, so they ended up doing their own hack. One reason we > had problems is that I wasn't sure how best to make this work > for all downstream distributors. > > Just as a point of reference, in the future, when there's some > question as to how to coordinate things with upstream, you might > consider actually contacting the upstream developers. > > I know how Ubuntu changed Yelp. And my understanding is that > Fedora is just putting General|Linux|Distributions|Other on the > front page. I assume this was done by changing scrollkeeper.xml > slightly. Could somebody send me the patch? With a clear idea > of how both Ubuntu and Fedora have done this, we should be able > to produce a better upstream method in 2.14 or 2.16. > > // Shaun Shaun, I looked at the Ubuntu patch for inspiration when working on this, and I believe we are doing essentially the same as they do. I'll attach our patch FYI. Matthias -------------- next part -------------- A non-text attachment was scrubbed... Name: yelp-2.12.1-fedora-docs.patch Type: text/x-patch Size: 859 bytes Desc: not available URL: From Tommy.Reynolds at MegaCoder.com Tue Nov 29 22:05:20 2005 From: Tommy.Reynolds at MegaCoder.com (Tommy Reynolds) Date: Tue, 29 Nov 2005 16:05:20 -0600 Subject: Draft document rendering Message-ID: <20051129160520.399fdcd6.Tommy.Reynolds@MegaCoder.com> Hi, folks! We have repeatedly had confusion about the HTML (and PDF?) formatting produced by our current "css/fedora.css" stylesheet. It is important to realize that any local rendering has *no official status". In particular, the Fedora project (or anyone else for that matter) can and will choose their own stylesheet settings. To that end, I've changed the default CSS stylesheet from "fedora.css" to "fedora-draft.css". This new stylesheet uses the background image "docs-common/images/watermark.png" to place the text "DRAFT / NOT FOR REFERENCE" diagonally across each HTML page. Each of you will need to update your "docs-common/" directory to pick up the new files. There is a new directory "docs-common/images". You may need to: $ cd docs-common $ cvs update -d to pick up the new directory. There is also a new shell script "docs-common/bin/use-prod-css" that will change the CSS file used by the rendered HTML document. At the moment there is no way to automatically generate the "production-looking" release. More on that later. Cheers -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From stuart at elsn.org Tue Nov 29 22:36:44 2005 From: stuart at elsn.org (Stuart Ellis) Date: Tue, 29 Nov 2005 22:36:44 +0000 Subject: Minutes of FDSCo Meeting 29 Nov 2005 Message-ID: <1133303804.3511.27.camel@localhost.localdomain> Attending: --------- Karsten Wade (quaid) Tommy Reynolds (megacoder) Paul Frields (stickster) Gavin Henry (G2) Stuart Ellis (elliss) Regrets: -------- Tammy Fox (tcf) - leave of absence Schedule of Tasks: ------------------ http://www.fedoraproject.org/wiki/DocsProject/FedoraDocsSchedule Highlights: ----------- * Tommy: Documents built from CVS will now automatically be marked with a "draft" watermark. For details, see the e-mail to fedora-docs-list: https://www.redhat.com/archives/fedora-docs-list/2005-November/msg00123.html A new make option will be added to build documents for public distribution. * Paul: xmlstarlet has now been added to Fedora Extras for both Fedora Core 3 and Fedora Core 4, to assist packaging work. This tool enables you to perform arbitrary queries against an XML file. To install it: su -c 'yum install xmlstarlet' * Karsten: The SELinux FAQ needs a new maintainer to revise and update it for Fedora Core 5. An e-mail has been sent to fedora-selinux-list: https://www.redhat.com/archives/fedora-selinux-list/2005-November/msg00171.html The current version of the FAQ is here: http://fedora.redhat.com/docs/selinux-faq-fc3/ Full IRC Log: ------------- https://www.redhat.com/archives/fedora-dsco-list/2005-November/msg00021.html -- Stuart Ellis stuart at elsn.org Fedora Documentation Project: http://fedora.redhat.com/projects/docs/ GPG key ID: 7098ABEA GPG key fingerprint: 68B0 E291 FB19 C845 E60E 9569 292E E365 7098 ABEA -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From shaunm at gnome.org Tue Nov 29 23:42:32 2005 From: shaunm at gnome.org (Shaun McCance) Date: Tue, 29 Nov 2005 17:42:32 -0600 Subject: Docs packaging and Yelp In-Reply-To: <1133293045.19836.2.camel@golem.boston.redhat.com> References: <1133292713.25828.26.camel@shaunmlx> <1133293045.19836.2.camel@golem.boston.redhat.com> Message-ID: <1133307752.25828.49.camel@shaunmlx> On Tue, 2005-11-29 at 14:37 -0500, Matthias Clasen wrote: > On Tue, 2005-11-29 at 13:31 -0600, Shaun McCance wrote: > > I know how Ubuntu changed Yelp. And my understanding is that > > Fedora is just putting General|Linux|Distributions|Other on the > > front page. I assume this was done by changing scrollkeeper.xml > > slightly. Could somebody send me the patch? With a clear idea > > of how both Ubuntu and Fedora have done this, we should be able > > to produce a better upstream method in 2.14 or 2.16. > > > > // Shaun > > Shaun, I looked at the Ubuntu patch for inspiration when working on > this, and I believe we are doing essentially the same as they do. > > I'll attach our patch FYI. CCing gnome-doc-devel-list at gnome.org Ah hah. IIRC, that's exactly what Ubuntu does. The reason I didn't just make G|L|D|Other always top-level is that it seems wrong for those distros that are in ScrollKeeper's (very out-of-date) list. I suppose I could put all of the G|L|D|* categories at the top and just assume most normal people don't have the distro docs for more than one distro installed. But then that screws the BSDs, Solaris, etc. So currently we have the Other page, which catches all the SK categories under General|* and System|*. What if I put all of System|* in System, put General|Licenses in Licenses, and put everything else under General|* on the front page? A quick grep on my system (FC4 + some rawhide, no fancy distro docs packages installed) shows the only General|* category used is General|Licenses, and that's only used by the GPL, LGPL, and FDL license texts installed by Gnome. The ScrollKeeper categories aren't optimal, and we're not going to get a really nice solution until we can replace the help system (and share the new system with KDE, if all goes right). For the time being, though, we can at least manage to share the same dirty hacks. // Shaun From stickster at gmail.com Wed Nov 30 01:04:20 2005 From: stickster at gmail.com (Paul W. Frields) Date: Tue, 29 Nov 2005 20:04:20 -0500 Subject: {RFC] XSLT for draft watermarking? Message-ID: <1133312660.3089.9.camel@localhost.localdomain> Both and
in DocBook support a CDATA attribute called "status". (I.e., or something like that.) Does this mean we could have XSLT do the work of deciding which stylesheet to use, without having to have a new "make" target? When the work is approved, the author or editor can add this attribute to the top of their doc, and the next build fixes the make. If you want to dream really big like Karsten, then think of that status attribute being manipulated by a XML/XSLT capable shell script that is part of a Larger Automated Process. For example, when the doc is published, it gets branched and the branch gets the status="published" tag, whereas HEAD keeps the default draft. Is this possible? -- Paul W. Frields, RHCE http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 Fedora Documentation Project: http://fedora.redhat.com/projects/docs/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From jlaska at redhat.com Wed Nov 30 12:51:20 2005 From: jlaska at redhat.com (James Laska) Date: Wed, 30 Nov 2005 07:51:20 -0500 Subject: {RFC] XSLT for draft watermarking? In-Reply-To: <1133312660.3089.9.camel@localhost.localdomain> References: <1133312660.3089.9.camel@localhost.localdomain> Message-ID: <1133355080.14939.8.camel@flatline.devel.redhat.com> On Tue, 2005-11-29 at 20:04 -0500, Paul W. Frields wrote: > Both and
in DocBook support a CDATA attribute called > "status". (I.e., or something like that.) > Does this mean we could have XSLT do the work of deciding which > stylesheet to use, without having to have a new "make" target? When the > work is approved, the author or editor can add this attribute to the top > of their doc, and the next build fixes the make. If you want to dream > really big like Karsten, then think of that status attribute being > manipulated by a XML/XSLT capable shell script that is part of a Larger > Automated Process. For example, when the doc is published, it gets > branched and the branch gets the status="published" tag, whereas HEAD > keeps the default draft. > > Is this possible? That's a good idea. Another thought might be to pass in any details by way of environment variables when the doc is made. I do this for some "production-style" xsl ... $ XSLHTML=some.xsl make Perhaps something like ... $ CSS=../common/css/production.css make ... just thinking outloud. This approach would allow for local CSS customization and follows a similar path provided by overloading XSLHTML, XSLHTMLNOCHUNK, XSLPDF, FDPDIR. Thanks, James > > -- > fedora-docs-list mailing list > fedora-docs-list at redhat.com > To unsubscribe: > https://www.redhat.com/mailman/listinfo/fedora-docs-list From stickster at gmail.com Wed Nov 30 13:19:29 2005 From: stickster at gmail.com (Paul W. Frields) Date: Wed, 30 Nov 2005 08:19:29 -0500 Subject: {RFC] XSLT for draft watermarking? In-Reply-To: <1133355080.14939.8.camel@flatline.devel.redhat.com> References: <1133312660.3089.9.camel@localhost.localdomain> <1133355080.14939.8.camel@flatline.devel.redhat.com> Message-ID: <1133356769.3446.24.camel@localhost.localdomain> On Wed, 2005-11-30 at 07:51 -0500, James Laska wrote: > On Tue, 2005-11-29 at 20:04 -0500, Paul W. Frields wrote: > > Both and
in DocBook support a CDATA attribute called > > "status". (I.e., or something like that.) > > Does this mean we could have XSLT do the work of deciding which > > stylesheet to use, without having to have a new "make" target? When the > > work is approved, the author or editor can add this attribute to the top > > of their doc, and the next build fixes the make. If you want to dream > > really big like Karsten, then think of that status attribute being > > manipulated by a XML/XSLT capable shell script that is part of a Larger > > Automated Process. For example, when the doc is published, it gets > > branched and the branch gets the status="published" tag, whereas HEAD > > keeps the default draft. > > > > Is this possible? > > That's a good idea. Another thought might be to pass in any details by > way of environment variables when the doc is made. I do this for some > "production-style" xsl ... > > $ XSLHTML=some.xsl make > > Perhaps something like ... > > $ CSS=../common/css/production.css make > > ... just thinking outloud. This approach would allow for local CSS > customization and follows a similar path provided by overloading > XSLHTML, XSLHTMLNOCHUNK, XSLPDF, FDPDIR. That's a good point too -- Tommy has already made allowances for this in his Makefile.common, so this is do-able as well. I suppose we could do this based on tagging in CVS as well. There's probably several other ways we haven't thought of either. I like any way that doesn't make us have to change a big chunk of the current Makefile.common, or put too many additional "don't forget to..." burdens on the authors/editors/publishers. One way or another somebody's got to mark *something*, it's just a matter of what's the most flexible way to do it. If I remember correctly, there's an order to how XSL stuff is inherited, right? Like, "whoever's first wins," although it could be the opposite, I'm not sure. That would give a pretty easy solution to using your XSLHTML= method above, I'm thinking, since you could just write the new XSL to include the original stuff and process the "production" instructions in the right order. Am I on the right track with this? Sorry I don't know the formal terms correctly at this point -- if I did it would make my comments more readable, I'm sure. ;-) -- Paul W. Frields, RHCE http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 Fedora Documentation Project: http://fedora.redhat.com/projects/docs/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From Tommy.Reynolds at MegaCoder.com Wed Nov 30 17:41:05 2005 From: Tommy.Reynolds at MegaCoder.com (Tommy Reynolds) Date: Wed, 30 Nov 2005 11:41:05 -0600 Subject: {RFC] XSLT for draft watermarking? In-Reply-To: <1133312660.3089.9.camel@localhost.localdomain> References: <1133312660.3089.9.camel@localhost.localdomain> Message-ID: <20051130114105.3003620b.Tommy.Reynolds@MegaCoder.com> Uttered "Paul W. Frields" , spake thus: > Both and
in DocBook support a CDATA attribute called > "status". (I.e., or something like that.) > Does this mean we could have XSLT do the work of deciding which > stylesheet to use, without having to have a new "make" target? Maybe I know this, but I can't remember it at the moment. I need a little more thinking on this. My question is: When is an FDP document "published"? It seems to me that being considered as a published document is solely determinable from the context in which the document appears. I'm not considering "publication" as it relates to copyright, just making the distinction between DRAFT and PRODUCTION versions of a doc. For example, you write a manuscript and send it to a publisher. They love the first draft and fire up the presses. Now, the copy you sent them is clearly DRAFT and their bound version is clearly PRODUCTION, even though the words in each are exactly the same: it's the context or pedigree that matters. Documents built locally from CVS can never be "production" because they are not official copies. To emphasis this, we now have a watermark indicating its draft status. Documents obtained from DocsRawHide can never be "production" and need to be watermarked as draft. Official, production-quality documents are located (where?) and produced by (whom?). Only those copies need have the draft watermarking revoked. Docs included in the distribution are "production". Where else do the official docs reside? Who places them there? How do they know when to do this? I don't think the document itself should know whether it is released or not. It is too easy to leave the blessing in the document as modifications are in progress. An external mechanism makes sense to me. We really need only one CSS stylesheet in the docs CVS: the fedora-draft.css file, and we have that. Any official-looking document renderings should come from whom ever is constructing the official-looking release, but anything in our CVS is strictly for draft documents. Does this mean that document authors can't generate official document renderings? Yes, if by that you mean "Fedora Documentation Project" official copies. Anyone wanting to produce their own published renderings are free to take the "fedora-draft.css" stylesheet and edit as desired. I would agree to change the XSLT and Makefile.common stuff to reference "fedora.css" and to make "fedora.css" a symlink to the "fedora-draft.css" file. That would make switching the CSS stylesheet easier because a change would not corrupt the local CVS image. Comments? Suggestions? Donations? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jlaska at redhat.com Wed Nov 30 18:44:57 2005 From: jlaska at redhat.com (James Laska) Date: Wed, 30 Nov 2005 13:44:57 -0500 Subject: {RFC] XSLT for draft watermarking? In-Reply-To: <20051130114105.3003620b.Tommy.Reynolds@MegaCoder.com> References: <1133312660.3089.9.camel@localhost.localdomain> <20051130114105.3003620b.Tommy.Reynolds@MegaCoder.com> Message-ID: <1133376298.18529.15.camel@flatline.devel.redhat.com> On Wed, 2005-11-30 at 11:41 -0600, Tommy Reynolds wrote: > Does this mean that document authors can't generate official document > renderings? Yes, if by that you mean "Fedora Documentation Project" > official copies. Anyone wanting to produce their own published > renderings are free to take the "fedora-draft.css" stylesheet and > edit as desired. > > I would agree to change the XSLT and Makefile.common stuff to > reference "fedora.css" and to make "fedora.css" a symlink to the > "fedora-draft.css" file. That would make switching the CSS > stylesheet easier because a change would not corrupt the local CVS > image. All sounds great to me! As someone using the fedora/docs-common toolchain for internal process documentation, I would very much like the ability to overload with a custom *production* css. As you suggest, I think it makes sense to not have that information live in the document. I like the XSLHTML and XSLHTMLNOCHUNK environment variable approach because it allows us to keep in sync with fdp docs-common and use our own xsl tweaks when it comes to *production*. I made a few Makefile.common changes that allow for passing in a CSS env var that points to a css file. That file is then copied over as fedora.css. I would have liked to use ${DOCBASE}.css but I can't figure out how to use variables in the html-common.xsl. I have attached those changes just to show where I was headed. Thoughts/concerns? Thanks, James Laska -- ========================================== James Laska -- jlaska at redhat.com Quality Engineering -- Red Hat, Inc. ========================================== -------------- next part -------------- A non-text attachment was scrubbed... Name: fdp-local-css.patch Type: text/x-patch Size: 2828 bytes Desc: not available URL: From stuart at elsn.org Wed Nov 30 20:07:26 2005 From: stuart at elsn.org (Stuart Ellis) Date: Wed, 30 Nov 2005 20:07:26 +0000 Subject: {RFC] XSLT for draft watermarking? In-Reply-To: <20051130114105.3003620b.Tommy.Reynolds@MegaCoder.com> References: <1133312660.3089.9.camel@localhost.localdomain> <20051130114105.3003620b.Tommy.Reynolds@MegaCoder.com> Message-ID: <1133381246.2802.24.camel@localhost.localdomain> On Wed, 2005-11-30 at 11:41 -0600, Tommy Reynolds wrote: > Documents built locally from CVS can never be "production" because > they are not official copies. To emphasis this, we now have a > watermark indicating its draft status. > > Documents obtained from DocsRawHide can never be "production" and > need to be watermarked as draft. > We really need only one CSS stylesheet in the docs CVS: the > fedora-draft.css file, and we have that. > > Any official-looking document renderings should come from whom ever > is constructing the official-looking release, but anything in our CVS > is strictly for draft documents. I agree. This is in line with the general trademark policy, too (people can freely copy, modify, and then rebrand, but not pass off modified copies as an "official Fedora" product). -- Stuart Ellis stuart at elsn.org Fedora Documentation Project: http://fedora.redhat.com/projects/docs/ GPG key ID: 7098ABEA GPG key fingerprint: 68B0 E291 FB19 C845 E60E 9569 292E E365 7098 ABEA -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: