i managed to take a screenshot while updating my F8 to F9 rawhide. i
chose "upgrade existing installation". everything was smooth. but there
was this progress bar movement that really surprised me. it said it had
to update 915 packages. at 496 packages, isn't it more than 50% complete
? the progress bar however is at far less than 50%. is that expected
behaviour ? why ??
i am attaching a pic i took from my mobile :) . people pls pardon me for
the tilted image i had to take. i couldn't get it properly done with my
mobile. sos sorry for that.
I've got a few packages I'm the sole maintainer on, but I simply don't use the package anymore or have much interest in continuing to maintain. Anyone interested in taking the following over?
In all fairness, Matthias Saou used to own rrdtool before I took it over, so I'd like to offer that back to him first...
Speaking of thias, he's a co-maintainer on a few of the remaining packages that came from the beryl bits, which I'd like to also step away from. Thias, if you want primary maintainership, they're yours. Others interested, speak up:
And finally, one more package that also has a co-maintainer (jef spaleta) who I'd like to have first crack at becoming primary maintainer, but that I should really have nothing to do with anymore:
I took on numpy with the intention of trying to finally kill python-numeric, but I just don't have the time -- too busy with kernel-related fun. :) Still a worthwhile project someone with the time really ought take on though -- perhaps with the help of whomever is still maintaining the long-since obsoleted python-numeric package.
Just want to mention that smolts.org static pages (at least
http://smolts.org/static/stats/stats.html) is broken. If you reload the
page a few times, you'll see the date jumping around (Apr 23, Apr 9, Apr
17)... Seems it's loadbalanced and not all servers have the same content
and even the latest content you can get (Apr 23) is not up2date. :-(
PS: Keep me posted CC:...
I'm trying to get a F9 guest running using the new virtio block device but
seem to run into trouble with LVM. I rebuilt the initrd in the guest adding
the options "--with=virtio_pci --with=virtio_blk" and after booting the
kernel correctly detects vd1 and vd2 but then fails to find any volume
groups. Using "media=disk" instead of "if=virtio" brings the guest up fine.
Is there a special option needed to make the kernel/initrd find the volume
group on these virtual block devices?
Are these drivers stable enough to maybe put them into the initrd by
default? I would be nice to be able to boot a F9 guest with the
paravirtualized drivers out of the box without having to build a custom
Double pronged email this...
1. Can anyone recommend an AGP card which will allow me to run 3D graphics
without using non-GPL drivers? I want to move away from nVidia for the time
being. Nothing against their cards, just that to use 3D, I need to use their
2. Monodevelop (rawhide) currently has a problem - no editor. For that to
work, it has to have gtksourceview2-sharp installed. Currently, this is only
available from the Novell ftp site. Not really a problem, nor is the licence.
However, the package will still need to be approved. Given that monodevelop is
pretty useless without the editor, is there a fast track way to get
gtksourceview2-sharp into rawhide?
I'd like to do a bit of informal polling here and see if there is
enough interest in forming a Xfce SIG.
Right now, I maintain the Xfce packages and help with plugins,
Christoph Wickert maintains all the plugins and helps with the main
packages, and Rahul Sundaram maintains the Xfce spin.
Are there enough other people out there interested in Xfce to make
forming a SIG worthwhile?
I have been really busy of late and would love some help with a few of
the Xfce enhancement bugs at least:
433573 - RFE: add mixer and trash applett to the default panel config
(needs clean patch)
433838 - RFE: Fedora icon in desktop menu
(has a patch, but somehow is not working fully right).
Ideas, patches, suggestions are always welcome, but if there are enough
folks out there that want to contribute we can form up a SIG.
Feel free to email me directly or followup to this post to show your
Bill Nottingham wrote:
> Warren Togami (wtogami(a)redhat.com) said:
>> * In the case of this scim change: You do a Korean language install.
>> Even on a non-LiveCD install you end up missing i386 (and font) packages
>> necessary for full Korean desktop support. There is no obvious way for
>> the user to know why it broke. It is suddenly impossible to have a full
>> Korean language desktop install by using the yum group. THIS IS A BIG
>> PROBLEM OUTSIDE OF LIVECD.
> ... 'and font'? The scim change changes fonts? O RLY?
> This is *exactly* what I said. You're saying we should do something
> special for an input method (for GTK only) that we don't do for
> QT input methods, NSS modules, PAM modules, etc.
Then I guess we are really not that much worse off. It is impossible
for yum groupinstall to "fix" these problems in Fedora 9.
This points to a more general problem: We were not happy with having a
huge pile of unnecessary i386 packages so our solution was to completely
eliminate them from the default install. We went TOO FAR
overcompensating for the previous broken multilib behavior.
Dependencies or a comps multilib whitelist could be a nice
middle-ground. Some users want to be i386-free. Other users want a
tiny set of expected packages to be multilib to avoid confusion. The
current yum option is either all or none.
Perhaps we need a third option like "smart" which uses a multilib
whitelist that can be updated via repodata. Anaconda and other GUI
interfaces can allow the user to choose between "smart" and "100% i386
free". This way "yum groupinstall korean-support" can install
everything the user expects.
This avoids the lose of:
- expecting the user to manually install a complicated set of
arch-specific packages because they can't use yum groupinstall
- expecting the user to change the yum multilib priority option and
subject themselves to a huge pile of unnecessary crap that they will
No time to do this before F9.
I've been running my system for the past week without an xorg.conf file
and it seems to work well
I'm pretty sure that from comments made either on this list or
fedora-test that we are moving in a direction where the norm will be
that no xorg.conf file is needed and therefor won't be created.
I'm having discussions with someone about this at the moment and would
appreciate some clarification on where things are head so that this can
be addressed at their end.
 The nvidia service from livna tries to
run /usr/sbin/nvidia-config-display which seems to require a xorg.conf
file in place. It appears that either (a) livna will need to work
around the absence of this file by creating one (how?), and eventually
(b) that nvidia will need to rewrite their software to recognize that
the file need not exist.
"It's a fine line between denial and faith.
It's much better on my side"
Since Fedora 9-Preview completely unuseable for me I decided to step
back to F-8. Thus far I know abount the only solution - backing up
/etc/ and /home directories and reinstalling F-8 but maybe there are
some ways to downgrade to previous relese and updates.
Another one note - since FC-4 of FC-2 I never updated to next release
w/o errors and things tends to be more worse than earlier. Looks like
it's doe to lack of testing combined with lack of comminications
within community (if such a community exists at all). Take a look at
the fedora popularity trend compared with other distros popularities.
Current mood is "frustrating".
With best regards!