Hi,
There is a way to create PGP/SSH keys and sign
fedora-icla-${username}.txt using only user-friendly graphic programs
(Seahorse + Gedit), but it is not included in Fedora wiki howtos. I
don't trust me enough to write in English so I would like to know who
can work with me to update those documents.
Thanks,
--
Davidson Paulo
http://fedoraproject.org/wiki/DavidsonPaulo
This is a request for participation:
The KDE-SIG [1] is atm lacking active contributors. And we really need some
help in doing our job to provide a good KDE version in Fedora - especially
with the upcoming KDE 4.0 and the inclusion in Fedora 9.
If you don't know how you could help us here is a list (which is also in the
wiki):
* Packagers: There are so many interesting packages that are not yet packaged
for Fedora. Package it to improve the user experience.
* Reviewers: Only a few persons are doing the kde-related reviews. Help us
reviewing so that more packages could be included.
* Testers: If you love KDE use the development version or the updates-testing
repository and report bugs, bugs, bugs, request enhancements or features. We
need your feedback to improve KDE.
* Bugs: Become a BugZapper and help us with kde-related bugs.
* Documentation writers: The documentation (esp. the DesktopUserGuide) is
GNOME-centered. Help us to provide an equivalent for KDE.
* Release Notes: The few people that are working on the new KDE-Spin are quite
busy with development issues. If you want to help us in writing the release
notes for the next version of Fedora we would give you all the info you need.
* Wiki: Maintain http://fedoraproject.org/wiki/KDE and keep it updated with
end user information.
* Artists: To provide a matching theme for nodoka-metacity-theme and provide
an unified desktop experience.
But this is not a complete list. If you're interested in making KDE in Fedora
better, you're more than welcome.
The list of participants in the wiki is atm not a list of active contributors.
When setting up the wiki the only demand was an interest in KDE to be listed
on this page. This list would be changed in the future to be culled down to
the list of active (or reactivated) participants. This has become necessarely
because there are only (less or more) 3 active contributors atm (plus Than
Ngo). But the list indicates that there are enough people helping with KDE.
If you are interested in joining the KDE-SIG please add your name to this
list, answer to this mail, join us in #fedora-kde at freenode or attend the
weekly KDE-SIG-Meetings (every tuesday 17:00 UTC). I will also add a topic to
the agenda of the meeting next week to introduce new contributors. [2]
The attendance at the SIG-Meetings is of course not required. But this way we
would know of each other. And they are also the main place of discussing the
next steps in the development (besides fedora-devel-list).
If you have any further questions please answer to this mail or write me
directly. And be sure: If your are willing to help you're welcome (regardless
of your skills). :)
Sebastian
[1] http://fedoraproject.org/wiki/SIGs/KDE
[2] http://fedoraproject.org/wiki/SIGs/KDE/Meetings/2007-11-06
Hi all,
There's an XML markup problem in release-notes F-8 branch Colophon.xml at line
212. The <para> element is not closed as it should be:
<listitem>
<para><ulink
url="http://fedoraproject.org/wiki/MarekMahut">Marek
Mahut</ulink> (translator - Slovak)
<-- </para> should probably go here!
</listitem>
This causes a weird msgid in the po files, see http://f3dora.org/paste/412 and
the same if of course visible in the final document, see
http://cs.helsinki.fi/u/vpivaini/fedora/RELEASE-NOTES-fi/sn-Colophon.html#s…
I didn't try to fix it myself, since I'm not quite sure what should be done
besides committing the fix to cvs. Maybe make po pot? Anything else?
--
Ville-Pekka Vainio
On Mon, 2007-11-05 at 20:07 -0500, jason taylor wrote:
> Hi, After that tutorial Sunday and playing around with it a bit, I was
> wondering what the next step is? Should I apply for read-write CVS
> access? Is there anything in particular you would recommend working on
> at this point? Thanks in advance.
I'm moving this to the list for followup. Open processes means we can
conduct all this work there.
You can get this access by applying for "cvsdocs" group in the Fedora
Account System (admin.fp.o?). We'll grant it, no problem. As for
things to work on -- how about the Respin Guide? There's no content
there, nor anything but a "blank" module location, but that would allow
you to apply the knowledge in the Documentation Guide so you understand
the module workings. Also, neither the DUG nor the AG is ready for any
kind of porting yet, so best to keep those in wiki-land for now.
--
Paul W. Frields, RHCE http://paul.frields.org/
gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717
Fedora Project: http://pfrields.fedorapeople.org/irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug
I just made a final update of the POT for the release-notes module. No
more changes will be made before I pick up the completed PO files on
Wednesday, November 7, at approximately 2359 UTC. At that time I will
roll everything into a zero-day fedora-release-notes RPM package update
for F-8.
We can use this thread to discuss a target date for updating the package
again for teams that want to work on updating their translation of the
Release Notes materials. A target date of December 8 seems like a good
place to start. If anyone has suggestions, the floor is yours! :-)
Also, by the way, as mentioned in a previous thread, we will no longer
be imposing any minimum limitation on translation completion for a
locale to be included in the RPM. If you have a PO file entered, its
translation output will be included in the distribution. If there are
bugs for incomplete translation, we'll simply get them assigned to the
proper teams.
Thanks to everyone who worked so hard on getting these ready -- it looks
like we'll have at least 11 languages ready on release date! You guys
never fail to astound me with how much work you can accomplish in such a
relatively short time. Congratulations to all the teams for their
efforts!
--
Paul W. Frields, RHCE http://paul.frields.org/
gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717
Fedora Project: http://pfrields.fedorapeople.org/irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug
<stickster> <meeting>
<stickster> Roll call... hi-ya folks!
<EvilBob> BobJensen
* jmbuser had his mandatory disconnect
<jmbuser> JohnBabich
<stickster> We expect no less!
<EvilBob> I may have to leave early, family errands...
<EvilBob> So there are 3 of us?
<stickster> Looks like.
<stickster> OK, our agenda is a bit crooked, so let's just take care
of any leftover release business for now, since I'm sure that's what's
on everyone's minds
<stickster> All right, current status of relnotes -- tonight I do a
final POT sync, and notify f-trans-list
<stickster> I was just syncing some of the content before the meeting,
fortunately not many changes.
* stickster acknowledges that jmtaylor wanted to receive training on
this stuff, will handle after meeting
<nim-nim> BTW there is some documentation work listed on
http://fedoraproject.org/wiki/SIGs/Fonts/Todo
* nim-nim hides
<stickster> According to the "postat" target, we have at least 11
languages complete or nearly complete for release notes this time
around, several other partially done
<stickster> 6 locales done for IG too
<stickster> We are no longer setting _any_ bar for locales. If they
make a PO file, we'll include them in the release notes package.
<stickster> If people in that locale use Fedora and read the relnotes,
they'll notice problems and either fix them or they won't.
<stickster> Did anyone have any major objections to this? I asked on
list and really didn't receive anything other than "+1" votes
<vpv> as a translator, I'd say +1 as well
<EvilBob> I disagree with it, however I would let the majority go with it
<stickster> Yeah, I think all the translators were in favor
<stickster> (all those that had something to say at least)
<EvilBob> Naturally they are in favor
<stickster> Well, we should recognize their work, and an incomplete
translation is actually a motivator for some teams
<EvilBob> "Hey I can translate 2 paragraphs and get karma credit"
<stickster> As we go along some of these concepts get a little clearer
to me. I used to be against completed work, now I'm doing a better job
of recognizing the FOSS "release early, release often" philosophy
<stickster> s/against completed/against half-completed/
<stickster> jmbuser: Did you want to talk about the DUG status?
<jmbuser> stickster: KDE-SIG put out a shout for some KDE docs - I
seconded the motion
<jmbuser> stickster: There's been some nice encouraging words to help
out with the DUG, but no volunteers
<stickster> Have you reached out to any of the people who popped up on
f-docs-l recently with offers?
<jmbuser> stickster: I tried...
* jmbuser is not a motivational speaker
<stickster> You can lead the horse to water, but...
<stickster> Wow, and that's just wiki work.
<stickster> Well, if someone's not willing to help there, chances are
it's not worth chasing them down any longer.
<stickster> I will try and put in some work on the DUG after the
release happens this time.
<stickster> But as we've already noted, individuals don't scale well.
<jmbuser> I swear I'll work on the DUG - I really will
* jmbuser is serious, not kidding
<stickster> haha
<stickster> I know you'll be putting some time in, no worries
<jmbuser> There's been some good work on other guides, I've noticed
<stickster> Yeah, a lot of material going into admin guide
<stickster> couf_afk++
<stickster> OK, I really don't have much else, guys.
<stickster> I've been really busy with non-Fedora stuff this week, but
have been keeping up with the relnotes and IG stuff.
<stickster> jmtaylor: If you want, we can retire to #fedora-docs and
do some cross-training
<stickster> AOB?
<jmtaylor> stickster: sounds good
<jmbuser> +1
<stickster> OK, 5...
<stickster> 4...
<stickster> 3...
<stickster> 2...
<stickster> 1...
<stickster> </meeting>
* stickster has changed the topic to: Documentation -- Meeting Closed
John Babich
Volunteer, Fedora Documentation Project
Here's something interesting we might want to reference from the User or
Administrator Guides (or both!).
Not sure about licensing for that site. For now let's play it safe --
learn some commands and best practices from those docs to make ours
better, and link to it for "more details."
- Karsten
-------- Forwarded Message --------
From: wiki-noreply(a)rpm.org
To: wiki-noreply(a)rpm.org
Subject: [rpm.org Wiki] Update of "Docs/RpmRecovery" by PanuMatilainen
Date: Thu, 01 Nov 2007 11:25:01 -0000
Dear Wiki user,
You have subscribed to a wiki page or wiki category on "rpm.org Wiki" for change notification.
The following page has been changed by PanuMatilainen:
http://wiki.rpm.org/Docs/RpmRecovery
The comment on the change is:
Recovery document based on http://people.redhat.com/berrange/notes/rpmrecovery.h
New page:
This document provides an overview of how to deal with RPM database corruption.
== Removing stale locks ==
If an RPM command hangs, segfaults, or otherwise behaves abnormally during use then the first task is to check for stale lock files. This can be accomplished with -CA option to the rpmdb_stat command:
{{{
# cd /var/lib/rpm
# /usr/lib/rpm/rpmdb_stat -CA
}}}
Look at the output under the sections headed 'Locks grouped by lockers' and 'Locks grouped by object'. If no RPM command is executing, then there should be no entries. The RPM DB format allows many processes to be concurrently reading *AND* writing to the DB, so there is no safe way for an RPM command to identify & remove a stale lock. Stale locks are typically a result of a process being killed in an abnormal manner (power loss, kernel crash, 'kill' from an impatient admin). The locks are maintained in a handful of files named with two initial underscores.
Since there is generally no 100% reliable way to determine if an arbitrary application has a lock on the RPM db, the best time at which to clear the stale locks is while in single user mode. Thus to clean up stale lock files, the best course of action is to simply reboot the machine. If for some reason, it is not feasible to reboot the machine, then it is feasible to simply delete the files manually. Before doing this, one must ensure no application has any of the RPM database files open. This can be checked with the lsof command. For example, as root, ensure the following command shows no lines of output:
{{{
#lsof | grep /var/lib/rpm
}}}
If this shows no output then it is safe to delete the lock files
{{{
# rm -f /var/lib/rpm/__db*
}}}
== DB corruption recovery process ==
If after cleaning up stale lock files, problems are still experianced, then it is likely some level of database corruption is present. The file that usually requires rebuilding is master package metadata file /var/lib/rpm/Packages, and following that the indexes will also need to be re-generated. Before doing any potentially destructive action *ALWAYS* take a backup of the RPM DB.
{{{
# cd /var/lib
# tar zcvf /var/preserve/rpmdb-`date +"%d%m%Y"`.tar.gz rpm
}}}
Now verify the integrity of the Packages file:
{{{
# cd /var/lib/rpm
# rm -f __db* # to avoid stale locks
# /usr/lib/rpm/rpmdb_verify Packages
}}}
If this reports any errors then a dump and load of the DB is required. After dumping, verify the integrity of the newly loaded Packages file:
{{{
# mv Packages Packages.orig
# /usr/lib/rpm/rpmdb_dump Packages.orig | /usr/lib/rpm/rpmdb_load Packages
# /usr/lib/rpm/rpmdb_verify Packages
}}}
If the Packages file now passes the verify step, then as an additional sanity check query all headers in the DB by doing, and watch for any messages sent to standard error (it helps to discard standard out when looking for this):
{{{
# rpm -qa 1> /dev/null
}}}
If this query passes without generating any messages to standard error, then it is time to rebuild the indexes by invoking:
{{{
# rpm -v --rebuilddb
}}}
At this point you should have a functioning RPM database again. If any of the recovery steps failed, then a bug should be [:Communicate:reported]. . When creating the report, provide the tar.gz backup of the RPM DB as an attachment, along with any daily package list log files named /var/log/rpm*.
----
CategoryDocs
--
Karsten Wade, Developer Community Mgr.
Dev Fu : http://developer.redhatmagazine.com
Fedora : http://quaid.fedorapeople.org
gpg key : AD0E0C41