I've been discussing Publican problems since December of 2008. Many have been discussing it longer. At tonight's (today's) Docs Project meeting we will discuss Publican and how to go forward. Right now I can see five options for moving forward:
1. Use Publican for a guide but munge through to an RPM that Fedora will consume; use jjmcd's script or a new .spec file 2. Fork Publican and remove the variable that puts the version # in the name 3. Get the Packaging Committee to amend the rules 4. Use Publican for HTML + PDF and fedora-doc-utils for RPM 5. Use f-doc-utils exclusively
Be thinking about this for tonight's meeting.
Thanks, Eric
----- Original Message ----- From: "Eric Christensen" eric@christensenplace.us To: fedora-docs-list@redhat.com Sent: Wednesday, March 25, 2009 5:34 PM Subject: Publican Issues
meeting we will discuss Publican and how to go forward. Right now I can see five options for moving forward:
- Use Publican for a guide but munge through to an RPM that Fedora will
consume; use jjmcd's script or a new .spec file 2. Fork Publican and remove the variable that puts the version # in the name 3. Get the Packaging Committee to amend the rules 4. Use Publican for HTML + PDF and fedora-doc-utils for RPM 5. Use f-doc-utils exclusively
Let me provide some pre-meeting input here.
Last week I got thinking that I needed to learn more about how we implement multiple languages. It wasn't clear to me that Publican creates these various languanges in the same way f-doc-utils does, and I wanted to be confident that I could come up with an equivalent RPM. I was very confident about a single-language RPM, but I just don't understand how the language gets selected.
So I tried to add a couple of languages to the F11 release notes and I kept getting errors. I also tried making a small Publican doc and adding languages, same errors. I fought this for a while without success, but last night rudi grabbed my sources and discovered that the error was a known bug (I had just assumed I was doing something wrong) to be fixed in 0.44. He had a workaround, and I was able to get Publican to generate RPMs for my test languages.
Well, that is the first problem. Publican generates an RPM per language. Probably not insurmountable to munge these together, especially if we are rebuilding the RPM. But I ran into some strangeness. It looks as if during the rpmbuild Publican treats the non-English languages differently. I still have more to explore to completely understand this, but it does make me less confident that we can beat it into submission quickly.
That being said, I still, for obvious selfish reasons, lean toward Publican-oriented solutions as opposed to f-docs-utils solutions. Even if we have to use a forked Publican, I think we are better positioned for F12 when we might have our needs rolled back in.
--McD
John J. McDonough wrote:
----- Original Message ----- From: "Eric Christensen" eric@christensenplace.us To: fedora-docs-list@redhat.com Sent: Wednesday, March 25, 2009 5:34 PM Subject: Publican Issues
meeting we will discuss Publican and how to go forward. Right now I can see five options for moving forward:
- Use Publican for a guide but munge through to an RPM that Fedora will
consume; use jjmcd's script or a new .spec file 2. Fork Publican and remove the variable that puts the version # in the name
No need to do this, I'll move a copy internal and you can have the fedora hosted repo if you want.
- Get the Packaging Committee to amend the rules
Good luck getting the blind to see.
- Use Publican for HTML + PDF and fedora-doc-utils for RPM
- Use f-doc-utils exclusively
Let me provide some pre-meeting input here.
Last week I got thinking that I needed to learn more about how we implement multiple languages. It wasn't clear to me that Publican creates these various languanges in the same way f-doc-utils does, and I wanted to be confident that I could come up with an equivalent RPM. I was very confident about a single-language RPM, but I just don't understand how the language gets selected.
So I tried to add a couple of languages to the F11 release notes and I kept getting errors. I also tried making a small Publican doc and adding languages, same errors. I fought this for a while without success, but last night rudi grabbed my sources and discovered that the error was a known bug (I had just assumed I was doing something wrong) to be fixed in 0.44. He had a workaround, and I was able to get Publican to generate RPMs for my test languages.
0.44 is in the testing repo waiting for enough karma to be pushed live. I asked for it to be pushed live.
Well, that is the first problem. Publican generates an RPM per language. Probably not insurmountable to munge these together, especially if we are rebuilding the RPM. But I ran into some strangeness. It looks as if during the rpmbuild Publican treats the non-English languages differently. I still have more to explore to completely understand this, but it does make me less confident that we can beat it into submission quickly.
In the SVN repo look at old_srpm2 and old_spec2 in publican-redhat/make/Makefile.Redhat. This is how we used to publish docs for RHEL5. The related xsl files are in publican-redhat/xsl/
It very quickly became an unmaintainable approach for books of any size.
People get really pissed when they have to d/l 200MB to get a typo fixed when they only read 1 language. This will be exacerbated for fedora where many more languages are supported.
This is only kept around because we have to support the shipped books, it really is a sub optimal distribution method and limits you ability to have nifty yum groups and such.
i.e. 'yum installgroup latin-docs' for all you Latin docs needs.
Marginally useful for Release Notes for obvious reasons, however, being able to ship the English to beta testers before the translations is likely reduce the impact of errata on translations should they occur.
Cheers, Jeff.
Rahul Sundaram wrote:
Jeff Fearn wrote:
- Get the Packaging Committee to amend the rules
Good luck getting the blind to see.
We as a community need to show more respect for each other. Even if you disagree with something, this is not the way to go about resolving it.
Rahul
Being a roadblock is not resolving it either. There is working with developers and there is actively working against them. Respect is earnt, not given to the wanting.
Just my .02AUD
Christopher Curran wrote:
Being a roadblock is not resolving it either. There is working with developers and there is actively working against them. Respect is earnt, not given to the wanting.
How have you tried to solve the issue so far? Who have you approached? All is I see is rude remarks and sarcasm. Nothing constructive. That's a failure even before you get started.
Rahul
Rahul Sundaram wrote:
Christopher Curran wrote:
Being a roadblock is not resolving it either. There is working with developers and there is actively working against them. Respect is earnt, not given to the wanting.
How have you tried to solve the issue so far? Who have you approached? All is I see is rude remarks and sarcasm. Nothing constructive. That's a failure even before you get started.
Rahul
I'm a lurker. I sit and watch most of the time. My development and documentation work probably sits off your radar. It's where I prefer to stay because the more I have to deal with the fedora established bureaucracy the less I want to have anything to do with fedora. I am doing constructive work for fedora, I just have nothing to do with packaging most of the time. Those two things are related.
Chris
Christopher Curran wrote:
I'm a lurker. I sit and watch most of the time. My development and documentation work probably sits off your radar. It's where I prefer to stay because the more I have to deal with the fedora established bureaucracy the less I want to have anything to do with fedora. I am doing constructive work for fedora, I just have nothing to do with packaging most of the time. Those two things are related.
Nobody is forcing you to work on Fedora but if you or anybody else here want to solve any problems, you got to be a lot more specific about your issues and work on resolving them constructively. Where have you raised your issues?
Rahul
Christopher Curran wrote:
Rahul Sundaram wrote:
Jeff Fearn wrote:
- Get the Packaging Committee to amend the rules
Good luck getting the blind to see.
We as a community need to show more respect for each other. Even if you disagree with something, this is not the way to go about resolving it.
Rahul
Being a roadblock is not resolving it either. There is working with developers and there is actively working against them. Respect is earnt, not given to the wanting.
Considering that I don't even know what the problem is and no one who's swinging the hate bat has yet to clarify that on this list or the packaging list (where everyone in the FPC will see it rather than just the one randomly subscribed to this list.) It's hard to see how I can act as a very effective roadblock.
One note, though: while the FPC tries to implement goals in a way that's as easy as possible for the developers involved, the goals themselves are primarily about getting high quality packages to end-users, not making developers lives easier. If you have a suggestion for implementing a goal in a way that is easier for packagers, by all means make it. If you just want to complain about how doing things the right way takes time then you're going to find your complaints get no respect. Respect, after all, is earned.
-Toshio
Toshio Kuratomi wrote:
Christopher Curran wrote:
Rahul Sundaram wrote:
Jeff Fearn wrote:
- Get the Packaging Committee to amend the rules
Good luck getting the blind to see.
We as a community need to show more respect for each other. Even if you disagree with something, this is not the way to go about resolving it.
Rahul
Being a roadblock is not resolving it either. There is working with developers and there is actively working against them. Respect is earnt, not given to the wanting.
Considering that I don't even know what the problem is and no one who's swinging the hate bat has yet to clarify that on this list or the packaging list (where everyone in the FPC will see it rather than just the one randomly subscribed to this list.) It's hard to see how I can act as a very effective roadblock.
One note, though: while the FPC tries to implement goals in a way that's as easy as possible for the developers involved, the goals themselves are primarily about getting high quality packages to end-users, not making developers lives easier. If you have a suggestion for implementing a goal in a way that is easier for packagers, by all means make it. If you just want to complain about how doing things the right way takes time then you're going to find your complaints get no respect. Respect, after all, is earned.
-Toshio
I think that Jeff and Chris are referring to this: https://bugzilla.redhat.com/show_bug.cgi?id=476471
and possibly this as well: https://bugzilla.redhat.com/show_bug.cgi?id=482972
Josh
Joshua Wulf wrote: Thanks Joshua,
I think that Jeff and Chris are referring to this: https://bugzilla.redhat.com/show_bug.cgi?id=476471
IIUC, this boils down to: 1) Publican creates a different documentation package for each Fedora Release as it considers them to be separate documents. ie: Fedora-10-Security-Guide, Fedora-11-Security-Guide.
2) This means a new package review for each documentation package each release.
If you're willing to go through a new review each release, there's no problem.
If you want a single review to cover you for all releases, we need a new Guideline. I think if it's a potential goal to be able to install the Fedora-10-Security-Guide on Fedora-11, then I'd be against such a Guideline as separate packages really are what you want. If it's specifically a non-goal to do that, then it's a possibility although changing the name to not have the version in it strikes me as the better option there. Following onto that, I'm not sure why you wouldn't want to use publican to create an initial spec file and then modify it to meet the specifics of the situation. This is the workflow for CPAN2RPM, rpmdev-newspetemplate, and other tools.
Another option is to look at a streamlined set of review items for publican-created doc packages... We've never explicitly done this but in practice, people know they don't have to check, for instance, shared library guidelines when writing and reviewing a pure python module.
and possibly this as well: https://bugzilla.redhat.com/show_bug.cgi?id=482972
What's the problem here? That the .desktop is created inline in the spec file instead of as a separate file? If that's all it is, I can propose to the FPC to amend that. I can't recall a reason that it had to be included in the SRPM as a file specifically.
Note that neither of these issues had reached the FPC's radar (they still haven't, really, as I'm only one member and this isn't the packaging mailing list) so blaming the FPC as the roadblock is a bit misplaced.
-Toshio
Thanks for your response and suggestions Toshio.
I think it's more venting frustration than actually blaming the FPC for being a roadblock.
*Anything* that we can do to resolve these issues, keeping in mind the limited resources we are working with and the need to work together and forge stronger relationships going forward, will be great.
Josh
Toshio Kuratomi wrote:
Joshua Wulf wrote: Thanks Joshua,
I think that Jeff and Chris are referring to this: https://bugzilla.redhat.com/show_bug.cgi?id=476471
IIUC, this boils down to:
- Publican creates a different documentation package for each Fedora
Release as it considers them to be separate documents. ie: Fedora-10-Security-Guide, Fedora-11-Security-Guide.
- This means a new package review for each documentation package each
release.
If you're willing to go through a new review each release, there's no problem.
If you want a single review to cover you for all releases, we need a new Guideline. I think if it's a potential goal to be able to install the Fedora-10-Security-Guide on Fedora-11, then I'd be against such a Guideline as separate packages really are what you want. If it's specifically a non-goal to do that, then it's a possibility although changing the name to not have the version in it strikes me as the better option there. Following onto that, I'm not sure why you wouldn't want to use publican to create an initial spec file and then modify it to meet the specifics of the situation. This is the workflow for CPAN2RPM, rpmdev-newspetemplate, and other tools.
Another option is to look at a streamlined set of review items for publican-created doc packages... We've never explicitly done this but in practice, people know they don't have to check, for instance, shared library guidelines when writing and reviewing a pure python module.
and possibly this as well: https://bugzilla.redhat.com/show_bug.cgi?id=482972
What's the problem here? That the .desktop is created inline in the spec file instead of as a separate file? If that's all it is, I can propose to the FPC to amend that. I can't recall a reason that it had to be included in the SRPM as a file specifically.
Note that neither of these issues had reached the FPC's radar (they still haven't, really, as I'm only one member and this isn't the packaging mailing list) so blaming the FPC as the roadblock is a bit misplaced.
-Toshio
On Thu, 2009-03-26 at 00:12 -0700, Toshio Kuratomi wrote:
Joshua Wulf wrote: Thanks Joshua,
I think that Jeff and Chris are referring to this: https://bugzilla.redhat.com/show_bug.cgi?id=476471
IIUC, this boils down to:
- Publican creates a different documentation package for each Fedora
Release as it considers them to be separate documents. ie: Fedora-10-Security-Guide, Fedora-11-Security-Guide.
- This means a new package review for each documentation package each
release.
If you're willing to go through a new review each release, there's no problem.
And that's okay for certain documents (i.e. Release Notes, User Guide,...) that are tied directly to a specific release of Fedora. The Security Guide, however, is not. I'd much prefer the Security Guide being just that, the Fedora Security Guide and not have to go through review for each release.
So while it might be nice to include a release number in the package for some documents it is not appropriate for all. Publican does not provide that ability to not use the release number and if it did, and there were writers who wanted to use the release numbering, I would have already petitioned the FPC on behalf of the Docs Project to make the change. So, no, the problem isn't with the FPC's decisions or current rules.
Eric
Joshua Wulf wrote:
I think that Jeff and Chris are referring to this: https://bugzilla.redhat.com/show_bug.cgi?id=476471
Comment #58 by Jens Petersen:
I am not veto'ing parallel install per se, but maybe it is worth considerng what is so special about docs packages that warrants/necessitates parallel install since we don't really do this for any other packages except libraries/tools needed occasionally for back-compatibility.
The idea here is that people who are using Fedora in a production capacity, rather than just as a beta test of RHEL, are able to install multiple documentation sets.
The use case would be like this:
I'm a system administrator with a number of different servers on my network running different versions of Fedora. Some are internal servers and running the ancient Fedora 10. There is one running Fedora 15 that I'm intending to upgrade later. The ones on the firewall I run at latest-1, and are currently on Fedora 19. I'm running Fedora 20 on my personal workstation, and I have a virtual machine running Fedora Rawhide.
On my Fedora 20 workstation I have the documentation for all of these different versions installed (F10, F15, F19, F20, Rawhide), so that I can refer to the relevant docs in my graphical user environment as I administer them remotely via ssh.
That's the idea. It doesn't make much sense if you envision Fedora as a RHEL beta test that you scrap each time a new version comes out, but if it's a viable OS that can be deployed and used in a production capacity like that described above, parallel documentation installation will be useful.
What are your thoughts on this?
Josh
On Thu, Mar 26, 2009 at 05:19:33PM +1000, Joshua Wulf wrote:
[snip reasonable use case]
That's the idea. It doesn't make much sense if you envision Fedora as a RHEL beta test that you scrap each time a new version comes out, but if it's a viable OS that can be deployed and used in a production capacity like that described above, parallel documentation installation will be useful.
I find it to be a reasonable use case. Personally, I would move the version number after the word "Fedora", to make it clear it is about the version of the OS not the version of the document. Otherwise, the reason for the implementation makes sense.
In fact, I doubt anyone will argue against the use case. The issue is that the use case did not surface until the last few weeks, although obviously it has been part of the Publican design scheme for some time. It is rather late in the Fedora 11 lifecycle to make all of this work, but that doesn't mean it's impossible. Just much more "hurry up" work than should have been done.
Preferably, IMO, Publican makes it an option to include the version number in the package or document name, for reasons well stated elsewhere.
- Karsten
Eric Christensen wrote:
I've been discussing Publican problems since December of 2008. Many have been discussing it longer. At tonight's (today's) Docs Project meeting we will discuss Publican and how to go forward. Right now I can see five options for moving forward:
- Use Publican for a guide but munge through to an RPM that Fedora will
consume; use jjmcd's script or a new .spec file 2. Fork Publican and remove the variable that puts the version # in the name 3. Get the Packaging Committee to amend the rules 4. Use Publican for HTML + PDF and fedora-doc-utils for RPM 5. Use f-doc-utils exclusively
Be thinking about this for tonight's meeting.
Thanks, Eric
6. Remove the release notes from anaconda. <<To me this is the most logical solution as most users do not want to waste more time installing than they already must. 7. Branch stack the packaging committee out with people who adhere to more liberal packaging guidelines.
Chris
On Thu, Mar 26, 2009 at 09:22:09AM +1000, Christopher Curran wrote:
- Remove the release notes from anaconda. <<To me this is the most
logical solution as most users do not want to waste more time installing than they already must.
The release notes have been removed from Anaconda for several releases of Fedora. Unless you mean something else?
- Branch stack the packaging committee out with people who adhere to
more liberal packaging guidelines.
Must ... not ... feed ... the ... trolls ...
- Karsten
Karsten Wade wrote:
On Thu, Mar 26, 2009 at 09:22:09AM +1000, Christopher Curran wrote:
- Remove the release notes from anaconda. <<To me this is the most
logical solution as most users do not want to waste more time installing than they already must.
The release notes have been removed from Anaconda for several releases of Fedora. Unless you mean something else?
They are removed now? That's awesome. I haven't noticed as all I've been doing is automated installs.
Name: Wolf DreamWalker (not a pseudonym)
Location: Toronto, Ontario, Canada
Profession: Software Trainer
Company: Currently enrolled in the Technical Communications program at Seneca@York, Toronto
Background
Comfortable with Windows desktop and server products - certified systems engineer Have several years experience developing and presenting learning materials to university students and workers within technical areas of various companies.Have tested fan created missions for games such as Thief and even delved in creating some of the readables. Great believer in KIS (keep it simple) and have found that screen shots, etc. are excellent learning tools for those of us who are not computer naturals
Knowledge of Linux / Fedora Absolute Newbie ... less than a week old. I'm somewhat intimidated by the new concepts and perceptions encompassing Fedora but I'm excited to be able to dig into a few area of expertise. I've jumped in with a dual-boot install. I thought that all I had to do was to install Fedora on freed-up space on a single hard drive already occupied by Microsoft Vista. However, I soon discovered that the two systems handle "primary" drives somewhat differently and that the only way I could get a viable working copy of Fedora on my computer was to install it on what Vista designated as part of the "extended" drive (this variant doesn't appear to be addressed in the installation guide).
Goals - Where I could help
Since I'm so new to Linux and Fedora I am less likely to miss or overlook steps that a Fedora expert takes for granted. I'm also more likely to query what appears to be outdated documentation (e.g. the software's recommendation to follow what is actually a mandatory procedure to create a user name and password during installation). At the same time, I recognize I have somewhat of a learning curve to overcome so probably the best place to use me is in testing and editing of current material.
Availability
I'm between semesters and have plenty of free time between now and May 9 to devote myself to this project (at least 40 hrs a week). When I return to school my time will be limited to only a few hours a week.
Wolf
GPG KEYID and fingerprint
Name: Wolf DreamWalker Email: wolfdreamwalker@hotmail.com ID: 3117A6BC / DSA / 1024 Created: 2009-03-26 Fingerprint:1462 3928 AF44 6770 F616 925D 6EA6 B659 3117 A6BC
Subkeys:6EA6B6593117A6BC (DSA),A0D3380DAD91D537 (EIGamal)
_________________________________________________________________ Share photos with friends on Windows Live Messenger http://go.microsoft.com/?linkid=9650734
Whoops ... forgot to change the subject title
From: wolfdreamwalker@hotmail.com To: fedora-docs-list@redhat.com Date: Fri, 27 Mar 2009 09:57:56 -0400 Subject: RE: Publican Issues
Name: Wolf DreamWalker (not a pseudonym)
Location: Toronto, Ontario, Canada
Profession: Software Trainer
Company: Currently enrolled in the Technical Communications program at Seneca@York, Toronto
Background
Comfortable with Windows desktop and server products - certified systems engineer Have several years experience developing and presenting learning materials to university students and workers within technical areas of various companies.Have tested fan created missions for games such as Thief and even delved in creating some of the readables. Great believer in KIS (keep it simple) and have found that screen shots, etc. are excellent learning tools for those of us who are not computer naturals
Knowledge of Linux / Fedora Absolute Newbie ... less than a week old. I'm somewhat intimidated by the new concepts and perceptions encompassing Fedora but I'm excited to be able to dig into a few area of expertise. I've jumped in with a dual-boot install. I thought that all I had to do was to install Fedora on freed-up space on a single hard drive already occupied by Microsoft Vista. However, I soon discovered that the two systems handle "primary" drives somewhat differently and that the only way I could get a viable working copy of Fedora on my computer was to install it on what Vista designated as part of the "extended" drive (this variant doesn't appear to be addressed in the installation guide).
Goals - Where I could help
Since I'm so new to Linux and Fedora I am less likely to miss or overlook steps that a Fedora expert takes for granted. I'm also more likely to query what appears to be outdated documentation (e.g. the software's recommendation to follow what is actually a mandatory procedure to create a user name and password during installation). At the same time, I recognize I have somewhat of a learning curve to overcome so probably the best place to use me is in testing and editing of current material.
Availability
I'm between semesters and have plenty of free time between now and May 9 to devote myself to this project (at least 40 hrs a week). When I return to school my time will be limited to only a few hours a week.
Wolf
GPG KEYID and fingerprint
Name: Wolf DreamWalker Email: wolfdreamwalker@hotmail.com ID: 3117A6BC / DSA / 1024 Created: 2009-03-26 Fingerprint:1462 3928 AF44 6770 F616 925D 6EA6 B659 3117 A6BC
Subkeys:6EA6B6593117A6BC (DSA),A0D3380DAD91D537 (EIGamal)
Tell the whole story with photos, right from your Messenger window. Learn how! _________________________________________________________________ Chat with the whole group, and bring everyone together. http://go.microsoft.com/?linkid=9650735
Welcome!
With the Fedora 11 Beta scheduled for release "soon" (there is a schedule here somewhere.....) The Installation Guide and the User's Guide will need to be verified.
From your introduction, that sounds like something that might interest
you. I am sure those team leaders will have more information. Meanwhile check out: https://fedoraproject.org/wiki/Docs_Project_content_tasks_for_new_contributo...
Internally, the Docs Project is still in need of much cleanup for our own process pages and documentation but you can now find most of them in the Docs Project Category on the wiki: https://fedoraproject.org/wiki/Category:Docs_Project We know that they have some inconsistancies so please so not be shy about asking questions.
Again, welcome.
-Susan
2009/3/27 Wolf DreamWalker wolfdreamwalker@hotmail.com:
Whoops ... forgot to change the subject title
From: wolfdreamwalker@hotmail.com To: fedora-docs-list@redhat.com Date: Fri, 27 Mar 2009 09:57:56 -0400 Subject: RE: Publican Issues
Name: Wolf DreamWalker (not a pseudonym) Location: Toronto, Ontario, Canada Profession: Software Trainer Company: Currently enrolled in the Technical Communications program at Seneca@York, Toronto
Background
Comfortable with Windows desktop and server products - certified systems engineer Have several years experience developing and presenting learning materials to university students and workers within technical areas of various companies. Have tested fan created missions for games such as Thief and even delved in creating some of the readables. Great believer in KIS (keep it simple) and have found that screen shots, etc. are excellent learning tools for those of us who are not computer naturals
Knowledge of Linux / Fedora
Absolute Newbie ... less than a week old. I'm somewhat intimidated by the new concepts and perceptions encompassing Fedora but I'm excited to be able to dig into a few area of expertise. I've jumped in with a dual-boot install. I thought that all I had to do was to install Fedora on freed-up space on a single hard drive already occupied by Microsoft Vista. However, I soon discovered that the two systems handle "primary" drives somewhat differently and that the only way I could get a viable working copy of Fedora on my computer was to install it on what Vista designated as part of the "extended" drive (this variant doesn't appear to be addressed in the installation guide).
Goals - Where I could help Since I'm so new to Linux and Fedora I am less likely to miss or overlook steps that a Fedora expert takes for granted. I'm also more likely to query what appears to be outdated documentation (e.g. the software's recommendation to follow what is actually a mandatory procedure to create a user name and password during installation). At the same time, I recognize I have somewhat of a learning curve to overcome so probably the best place to use me is in testing and editing of current material.
Availability I'm between semesters and have plenty of free time between now and May 9 to devote myself to this project (at least 40 hrs a week). When I return to school my time will be limited to only a few hours a week.
Wolf
GPG KEYID and fingerprint
Name: Wolf DreamWalker
Email: wolfdreamwalker@hotmail.com
ID: 3117A6BC / DSA / 1024
Created: 2009-03-26
Fingerprint:1462 3928 AF44 6770 F616 925D 6EA6 B659 3117 A6BC
Subkeys:6EA6B6593117A6BC (DSA),A0D3380DAD91D537 (EIGamal)
Tell the whole story with photos, right from your Messenger window. Learn how! ________________________________ Windows Live Messenger makes it easier to stay in touch - learn how! -- fedora-docs-list mailing list fedora-docs-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-docs-list
-
Chris Curran -
Eric Christensen -
Jeff Fearn -
John J. McDonough -
Joshua Wulf -
Karsten Wade -
Rahul Sundaram -
Susan Lauber -
Toshio Kuratomi -
Wolf DreamWalker