Notice of awayness
by Yaakov Nemoy
Hi lists,
I'm probably not important enough that it warrants a full message, but
this is to inform you that I will be out of touch from May 26th 2008
through May 31st 2008. I will have limited access to internet and
email, and will be busy interacting with people in meatspace anyways.
If there are any major problems with Smolt, or anything else that
requires my attention, the best person to reach is probably Mike
McGrath.
-Yaakov
16 years, 1 month
Re: X Keyboard layout problem
by Warren Togami
I think xorg.conf should be optional.
The default no xorg.conf should be able to handle simpler options
overlayed on top of the autoconfiguration. Keyboard layout and
resolution should be overridable. Extra fonts should be detected
automatically (you need xorg.conf options for this? huh?) Dual screen
might be a legitimate case where you need your own xorg.conf.
Warren Togami
wtogami(a)redhat.com
Bond, Darryl wrote:
> I think we need to be able to generate a special xorg.conf.
> What if we need a lower/higher resolution than the one the auto configurator determines.
>
> My site (with 300 LTSP clients) has lots of special needs in the xorg.conf, ie resolution, extra fonts, dual screen etc.
>
> Xrandr may be the way to handle resolution after the X server starts.
>
> Darryl
>
>
> -----Original Message-----
> From: k12linux-devel-list-bounces(a)redhat.com [mailto:k12linux-devel-list-bounces@redhat.com] On Behalf Of Warren Togami
> Sent: Sunday, 25 May 2008 1:29 PM
> To: k12linux-devel-list(a)redhat.com; Development discussions related to Fedora Core
> Subject: X Keyboard layout problem
>
>
> https://bugzilla.redhat.com/show_bug.cgi?id=448196
> This is a critical problem for anybody using a non-US keyboard layout with LTSP.
>
> LTSP on Debian uses ltsp-trunk/client/configure-x.sh to generate an xorg.conf and mangle it to use an explicit keyboard layout before running the actual X.
>
> Fedora LTSP uses X autoconfiguration without an xorg.conf. This seems to be working extremely well, except for cases like this where we need a specific configuration option that differs from the X autoconfiguration.
>
> Any ideas of what we can do?
>
> Warren Togami
> wtogami(a)redhat.com
>
> _______________________________________________
> K12Linux-devel-list mailing list
> K12Linux-devel-list(a)redhat.com https://www.redhat.com/mailman/listinfo/k12linux-devel-list
>
> The contents of this electronic message and any attachments are intended only for the addressee and may contain legally privileged, personal, sensitive or confidential information. If you are not the intended addressee, and have received this email, any transmission, distribution, downloading, printing or photocopying of the contents of this message or attachments is strictly prohibited. Any legal privilege or confidentiality attached to this message and attachments is not waived, lost or destroyed by reason of delivery to any person other than intended addressee. If you have received this message and are not the intended addressee you should notify the sender by return email and destroy all copies of the message and any attachments. Unless expressly attributed, the views expressed in this email do not necessarily represent the views of the company.
>
> _______________________________________________
> K12Linux-devel-list mailing list
> K12Linux-devel-list(a)redhat.com
> https://www.redhat.com/mailman/listinfo/k12linux-devel-list
16 years, 1 month
X Keyboard layout problem
by Warren Togami
https://bugzilla.redhat.com/show_bug.cgi?id=448196
This is a critical problem for anybody using a non-US keyboard layout
with LTSP.
LTSP on Debian uses ltsp-trunk/client/configure-x.sh to generate an
xorg.conf and mangle it to use an explicit keyboard layout before
running the actual X.
Fedora LTSP uses X autoconfiguration without an xorg.conf. This seems
to be working extremely well, except for cases like this where we need a
specific configuration option that differs from the X autoconfiguration.
Any ideas of what we can do?
Warren Togami
wtogami(a)redhat.com
16 years, 1 month
Packager Sponsors Responsibility Policy
by Brian Pepple
Hi all,
I'm looking for some feedback on what we've got so far for the Packager
Sponsors Responsibility Policy.
http://fedoraproject.org/wiki/Extras/Schedule/SponsorResponsibilityPolicy
---
== Who are Packager Sponsors? ===
Packager Sponsors are maintainers that have a good record of maintaining
packages, doing reviews and assisting others with the processes and
procedures of Fedora. Sponsors act as mentors for new contributors to
help point them to areas they would like to contribute, assist them with
processes and procedures and assist them when they need general
guidance. Sponsors also are responsible for fixing mistakes made by
their sponsored maintainers if they are unable to do so. Every Fedora
package maintainer should have a sponsor.
== Make sure the maintainers you sponsor follow guidelines ==
Sponsors should try and keep up with the doings of their sponsored
maintainers. Bugzilla has the ability to let you know via email all
activity for a given address. Initial sponsored maintainers should have
more scrutiny than long established maintainers with a known record of
good efforts.
== Help answer maintainers questions ==
Sponsors should be available to their sponsored maintainers to answer
questions. It's up to the sponsor if they wish to be available via IRC,
email, bugzilla, mailing list posts, phone or the like. In the event a
sponsor is unable to answer a question, they should escalate it to the
appropriate list, FESCO, FAB or the like and get an answer passed back.
== Fix issues caused by sponsored maintainers ==
If one of your sponsored maintainers is unable to fix an issue in their
package(s), it's up to the sponsor to step in and make the needed fixes.
This might include pushing a security update when the maintainer is
unavailable, applying a patch, removing a improperly build package, or
other time or security sensitive issue. Note that the maintainer should
be shown the fix and how to manage the issue moving forward.
== Revoking Sponsorship ==
A sponsor may elect to revoke their sponsorship of a maintainer in rare
and extreme situations. These situations might include: A maintainer
that no longer wishes to contribute to Fedora, a maintainer that refuses
to follow guidelines, or irreconcilable differences between the
maintainer and the Sponsor. In this event it is the responsibility of
the Sponsor to orphan the maintainers packages, and do any other needed
cleanups.
== Sponsorship Duration ==
Sponsorship of a maintainer begins when the Sponsor approves them in the
Fedora Account System. Sponsorship of a maintainer ends when that
sponsorship is revoked, or when that maintainer themselves becomes a
Sponsor.
== Who Sponsors the Sponsors? ==
Once a maintainer has been granted sponsorship status (via a vote of
FESCO), that Sponsor will be held accountable by FESCO, and not their
previous Sponsor.
---
If there is anything you feel is missing, or could be explained better,
please reply to this thread (along with any suggested wording).
Thanks,
/B
--
Brian Pepple <bpepple(a)fedoraproject.org>
http://fedoraproject.org/wiki/BrianPepple
gpg --keyserver pgp.mit.edu --recv-keys 810CC15E
BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E
16 years, 1 month
wikiold frozen, work on wikinew begins, early-import happening right now
by Karsten Wade
http://fedoraproject.org/wiki ==> /wikiold on 27 May == 'wikiold' == MoinMoin
http://fedoraproject.org/wikinew ==> /wiki on 27 May == 'wikinew' == MediaWiki
The content from MoinMoin (wikiold) is being early-imported to MediaWiki
(wikinew). That is happening right now and should be ready in N hours.
N == when it's ready. I'll send another announcement at that time.
This content is going to be imported *again* on 27 May, to capture any
changes made to wikiold. The details of that are being worked on, but
the goal is to have content fidelity. Your help is needed in
maintaining fidelity.
Here is what you should do:
1. Don't edit either wiki until you hear the early-import is done
2. If your content can wait until 27 May (Tuesday) for the public to
view it at fp.org/wiki, then do the work in wikinew and it goes live
with the final-import on Tuesday. This is a chance to fix pages in
wikinew that are not going to stay steady.
** DO NOT edit the page in both wikiold and wikinew. **
** Pick one and stick with it through the migration. **
3. If your content cannot wait until Tuesday and *must* be visible to
the public at fp.org/wiki between now and Tuesday, do the work in
wikiold. On Tuesday, it is final-imported into wikinew. You then want
to check the content post-import as you would any other pages.
Questions? #fedora-docs on irc.freenode.net is where the Wiki Gardeners
hang out. Time to start pruning and trimming and re-planting.
- Karsten, Wiki Gardener
--
Karsten Wade, Sr. Developer Community Mgr.
Dev Fu : http://developer.redhatmagazine.com
Fedora : http://quaid.fedorapeople.org
gpg key : AD0E0C41
_______________________________________________
Fedora-devel-announce mailing list
Fedora-devel-announce(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-announce
16 years, 1 month
Packaging Firefox extensions (Finnish spell checking)
by Ville-Pekka Vainio
Hi all,
I've been packaging Finnish spell checking support for Fedora (see
http://voikko.sourceforge.net/) and now I've packaged a Firefox extension
which uses the Voikko library to do spell checking in Finnish. My initial
testing package can be found here:
http://vpv.fedorapeople.org/packages/mozvoikko/
What do you think about packaging Firefox extensions, are they allowed and
would someone be interested in reviewing this package if I submitted it?
Beagle-firefox is probably the only Firefox extension packaged currently in
Fedora and I made my package so that it matches the locations etc. used in
that package.
Of course the extensions can be installed from Mozilla's web site as well, but
especially with this extension there would be a couple of benefits if it was
shipped as an RPM: It can be built against the libvoikko and libmalaga
libraries available in Fedora and it uses the Finnish data files available in
Fedora (malaga-suomi-voikko).
The extension version which probably will be shipped from Mozilla's web site
needs to have the libraries and the data files compiled in it, because it
can't assume much from the target system. Thus it will probably be much
larger (the uncompressed data files seem to be around 8 megabytes) whereas
the extension built to call the stuff already in the system takes around 70
kilobytes (uncompressed). Also, if the extension is installed via Firefox
from Mozilla's site, it will only be installed for the single user, so if the
system has for example 5 users and all of them install the extension for
themselves, the difference will be even bigger.
--
Ville-Pekka Vainio
16 years, 1 month
The problems upgraded to fedora 9
by zjsun
To be frankly, Fedora 9 is great distribution, but there is nothing
perfect in the world with no exception of Fedora :)
sipx project can be compiled successfully on Fedora 8, my another
program is compiled successfully on fedora 8 also
But after I upgraded my pc to fedora 9, all the things changed.
My program failed to compile on fedora 9 with the complaints of some
functions like memset, strcpy not found.
Sipx projects has the same problem, which can find strncpy, strcmp,
and so on. The worst is that it always report the following errors
[all-recursive] errors or [check-recursive] errors
I was confused by these strange errors.
Does fedora 9 change its include path and contents.of tools chains?
Can anyone give me some hints?
Thanks very much for your kindly help
zongjun
16 years, 1 month
