yum doesn't like installonly_limit=1?
by Rajeesh K V
I changed the "installonly_limit" to "1" from the default value "3" in
/etc/yum.conf, and yum blows up.
# yum search boinc
Loaded plugins: presto, refresh-packagekit
Options Error: Error parsing '1': out of range integer value
PackageKit gave me a better traceback:
Traceback (most recent call last):
File "/usr/share/PackageKit/helpers/yum/yumBackend.py", line 2956, in __init__
self.repos.confirm_func = self._repo_gpg_confirm
File "/usr/lib/python2.6/site-packages/yum/__init__.py", line 717, in <lambda>
repos = property(fget=lambda self: self._getRepos(),
File "/usr/lib/python2.6/site-packages/yum/__init__.py", line 496,
in _getRepos
self.conf # touch the config class first
File "/usr/lib/python2.6/site-packages/yum/__init__.py", line 723, in <lambda>
conf = property(fget=lambda self: self._getConfig(),
File "/usr/lib/python2.6/site-packages/yum/__init__.py", line 276,
in _getConfig
self._conf = config.readMainConfig(startupconf)
File "/usr/lib/python2.6/site-packages/yum/config.py", line 827, in
readMainConfig
yumconf.populate(startupconf._parser, 'main')
File "/usr/lib/python2.6/site-packages/yum/config.py", line 505, in populate
setattr(self, name, value)
File "/usr/lib/python2.6/site-packages/yum/config.py", line 94, in __set__
raise ValueError('Error parsing $r: $s' $ (value, str(e)))
ValueError: Error parsing '1': out of range integer value
I changed the value to 0, 2, 3 etc, all of them resulting in a working
yum environment. Is it a known issue, or worth filing a bug?
Yum version is yum-3.2.25-1.fc12.noarch
--
Cheers,
Rajeesh
http://rajeeshknambiar.wordpress.com
14 years, 4 months
rawhide and tagging requests
by Peter Robinson
Hi All,
What's the status of the issues with the rawhide compose? Are they
going to be fixed and a push done before the upcoming extended outage?
What about outstanding tag build-override requests?
Cheers,
Peter
14 years, 4 months
Reminder: Tomorrow is the last F10 updates push
by Josh Boyer
Hi All,
Just a friendly reminder that Dec 11 00:00:00 UTC is the cutoff for
F10 updates submission. Ideally these would just be the final stable
updates, as pushes to updates-testing would basically be stuck there
forever.
Please take a few moments to review your pending requests, add any
final stable updates you'd like pushed, and clear out any update
requests that don't make much sense for a soon to be EOL'd distro.
josh
_______________________________________________
Fedora-devel-announce mailing list
Fedora-devel-announce(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-announce
14 years, 4 months
abrt issue
by Neal Becker
I just got a crash in kde plasma. Traceback is not useful, because of
missing debug pacakges.
I'm told I can reload after 'installing the needed packages', but
there is no clue what packages are needed.
A bit of a mystery. It seems sometimes abrt will go ahead and download
needed debuginfo packages, but other times (like today), it doesn't, and
doesn't offer any clue what packages are missing.
Either way, still not very user friendly.
14 years, 4 months
Outage Notification - date -d '2009-12-11 02:00:00 UTC'
by Mike McGrath
There will be an outage starting at date -d '2009-12-11 02:00:00 UTC',
which will last approximately 2 hours.
To convert UTC to your local time, take a look at
http://fedoraproject.org/wiki/Infrastructure/UTCHowto
or run:
date -d 'date -d '2009-12-11 02:00:00 UTC''
Affected Services:
Database
Fedora Hosted (Just auth against trac)
Translation Services
Websites
Unaffected Services:
Buildsystem
CVS / Source Control
DNS
Fedora Talk
Fedora People
Mail
Mirror System
Torrent
Ticket Link:
https://fedorahosted.org/fedora-infrastructure/ticket/1845
Reason for Outage:
Our temporary DB hosts are in PHX are ready to take on load. We're going
to shut down db1 and db2, do an rsync then bring them up. During this
time we'll also be configuring our new VPN.
Also, a reminder for those who don't read the link, we'll be having a
massive outage of many Fedora services this weekend while we are moving
our servers to a new location.
Contact Information:
Please join #fedora-admin in irc.freenode.net or respond to this email to
track the status of this outage.
_______________________________________________
Fedora-devel-announce mailing list
Fedora-devel-announce(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-announce
14 years, 4 months
Planning the accessibility stack rebase
by Matthias Clasen
As some of you may know, the accessibility framework is getting ported
from CORBA/ORBit to DBus [1]. The (ambitious) upstream plan is to have
this transition completed in time for GNOME 2.30, ie within the F-13
timeframe.
This is a big effort, and the accessibility guys need all the help they
can get. To help with testing and feedback, I plan to get the new
accessibility stack into rawhide in early January. I have done initial
packages for the at-spi2 components [2], but they are not quite ready
for prime time yet (they don't have the coexistence part entirely sorted
out).
Some details about the changes that coming:
The CORBA-based at-spi package is being replaced by three components:
at-spi2-core - protocol definitions and registry daemon
at-spi2-atk - the atk-bridge GTK+ module
pyatspi - Python bindings for at-spi
There is no replacement for the cspi 'C bindings' at the moment. The
current users of cspi are being ported to use D-Bus directly
(mousetweaks) or replaced (gok being replaced by Caribou [3]). I am not
sure about the porting status of dasher...
To make the transition phase less painful, there are some efforts to
allow the old and new stacks to coexist. The CORBA-based at-spi stuff
will install its atk-bridge module and Python bindings somewhere else,
and there will be a desktop file that sets the GTK_PATH environment
variable and a pyatspi.pth Python module that sets some Python path.
These path-tweaks will be triggered by a GConf key, allowing both stacks
to be installed at the same time and allowing users and testers to
switch back and forth between the stacks.
It would be great if people who are interested in accessibility on
Fedora could chime in and help with planning this to make the transition
as smooth as it can. I'm sure there will be some bumps along the way
anyway...
Matthias
PS Having written all this down, I realize that I should probably turn
this into a feature page...
[1] http://www.linuxfoundation.org/collaborate/workgroups/accessibility/atk/a...
[2] http://bugzilla.redhat.com/show_bug.cgi?id=544628
http://bugzilla.redhat.com/show_bug.cgi?id=544629
http://bugzilla.redhat.com/show_bug.cgi?id=544630
[3] http://live.gnome.org/Caribou
14 years, 4 months
Re: Docs Installation Guide - Submission and Download problem
by Paul W. Frields
On Fri, Dec 04, 2009 at 10:51:59AM +0200, Dimitris Glezos wrote:
> 2009/12/3 Ruediger Landmann <r.landmann(a)redhat.com>:
> > On 12/02/2009 05:47 PM, Dimitris Glezos wrote:
> >>
> >> Rudi, you could clear the cache and refresh it.
> >>
> >
> > Really? How do I do that? I'd thought that a button like that would be useful for the
> > maintainer of a project
>
> This button is available on the web interface on component pages for
> maintainers.
>
> > , not least of which because changes to a POT in the repo don't automatically
> > trigger a refresh (of course!) while submissions of updated POs do.
>
> This functionality has been available in Transifex for a while, it's
> just that Fedora is still running an old (and unmaintained) version.
Diego posted the summary of what needs to be done here:
https://fedorahosted.org/fedora-infrastructure/ticket/1455#comment:10
In short, we need a few people to step up and help with the process
Diego posted.
We already do have a L10n Admin group[1] that should be overseeing and
managing this process, to ensure a successful rollout for translators.
Their charter is to maintain the infrastructure for translators, and
this clearly falls into that area. I've heard from two of the people
in that group that they can't do all this work themselves, but haven't
heard from Ankit or Asgeir about it.
What I would suggest is that Diego should help with bullet #4 on that
list, as it probably requires the greatest degree of specific
technical knowledge, in this case a database upgrade. The rest of the
work on that ticket could likely be done entirely by the remainder of
the team, maybe with limited input from Diego. It would be helpful
for Asgeir or Ankit to help manage this set of tasks in collaboration
with Diego, who has appropriate package access. (I'm cc'ing Ignacio
directly as well, so he can add appropriate CVS access for any other
people who are willing to help maintain the EL-5 package used on our
Infrastructure.)
Without help, it's doubtful there will be a new Transifex rolled out,
and that means some of the problems people are experiencing will
continue, even though they're already fixed upstream. I'm cc'ing the
docs, devel, and infrastructure lists to see if any of the people in
areas well served by translators are willing to help see this project
through. It's time to pull together, guys, and see if we can help the
translators who give so much across the whole Fedora Project.
* * *
[1] https://fedoraproject.org/wiki/L10N/Tools#Website
--
Paul W. Frields http://paul.frields.org/
gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717
http://redhat.com/ - - - - http://pfrields.fedorapeople.org/
irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug
14 years, 4 months
kernel update highly recommended
by Kyle McMartin
Hi folks,
I'd highly recommend if you're running 2.6.31 or 2.6.32, that you update
to the latest kernel in the koji builds here:
http://koji.fedoraproject.org/koji/taskinfo?taskID=1864871
http://koji.fedoraproject.org/koji/taskinfo?taskID=1864876
They fix a rather severe security problem with ext4 caused by
insufficient permission checking by the ext4 ioctl code, allowing a
malicious local user to corrupt files. Note, the ioctl isn't currently
used by userspace, so if you build your own kernels, you can just nuke
the entire EXT4_IOC_MOVE_EXT ioctl case.
NOTE: This is only a problem if you're using EXT4, if you aren't, you're
safe.
I'll get these pushed out to stable asap, but I wanted to let folks know
just in case rawhide doesn't compose before the downtime.
regards, Kyle M.
14 years, 4 months