VMWare util and driver packages

Dear Fedoraweb,

Is anyone around who's interested in maintaining open-vm-tools packages (kernel modules and userland utils for VMWare products) in Livna (and RPM Fusion, once I or ixs get around of setting up FAS and the look-aside cache for CVS)? The package are prepared already and mostly reviewed (see 1664 and 1665), but the packager switched all his systems from Fedora to Gentoo (good luck with that Brandon!) and abandoned the packages after a final update (thx for hat Brandon!). He mentioned in bugzilla that the packages work for him; and it seems they work fine for duke as well, as they have a slightly enhanced version of those packages in their repo. I'll of course help with the final review steps and the Livna import.

Quicktext for GNOME panel?

Before I switched to Linux (years ago) I used text-templates a lot -- that made for example answering e-mails a lot easier and quicker. I still do it using Quicktext in Thunderbird sometimes these days. But Quicktext is bound to Thunderbird and sometimes it'd like to have its functionality available other apps (Editor, OpenOffice, ...) as well.

Dear Lazyweb, do you know a Gnome application (integrated into the panel ideally) that makes a similar functionality available desktop-wide (in cooperation with the clipboard if needed)? I asked Google -- all I found that half-way matched my use cases was blah, which seems to be one of those ten thousands of inactive sourceforge apps that were abandoned by their developers.

Parallel universes ^w discussions

Mailing lists are funny sometimes -- like today on fedora-devel. There is one discussion where some people support the idea to get rid of mosts ACLs in CVS (often found in old Core packages) so all (new and old contributers) can commit (nearly) everywhere.

At the same time there is a debate about restricting CVS more due to security concerns (disclaimer: I'm the one that brought the old topic up again), as a malicious attacker can modify random packages in CVS once he got sponsored for cvsextras (with is neither easy nor very hard). The latter discussion resulted in a IMHO nice post from John Dennis. To quote just a part:

Linux has been mostly immune to malware. For anyone writing malware one of the challenges
is propagating the infected code.

So lets not give bad folks the perfect vehicle for distributing their malware through an
official update channel which automatically gets pushed to tens of thousands of machines
with the implication of being clean software. Such an event would be devastating to the entire
open source community.

The funny thing about it: both the views I mentioned above are IMHO right somehow. We IMHO need to get hurdles (like to restricting ACLs, but also those in our heads that say "that package is owned by someone else, I won't touch it") out of the way to have a more wiki-like working style for maintaining packages in Fedora. But at the same time we need fences to prevent that new contributers immediately get access in areas where they don't need access, to prevent malicious people to do bad things easily.

Problems updating kernels and kmods (2)

Remember my Post about problems when updating kernels on systems with kmods? A updated yum package which should fix the problem is on the way to updates-testing -- thx to skvidal for fixing the problem. Hopefully the new yum makes it to the stable repo before the next kernel update.

Flexibility

Cnet cites Max: Red Hat wants Fedora to be a foundation for those who want to build their own Linux products on a Fedora foundation.

dwmw2 wrote: I'd love to see more functionality -- more _possibilities_ -- merged under the 'Fedora' umbrella.

There are more such statements from other people; the general idea is floating around for some time now in Fedora-land. I'm wondering if we should issue something like Max statement above as official goal for the next few Fedora-years, to have a target we can work towards.

But can Fedora really be a proper foundation for other distributions? What if somebody wants to create a complete OpenVZ or Linux-VServer distribution (just as example) with Fedora as a base *within* the Fedora-project to ensure updates and patches for all non-OpenVZ and non-Linux-Vserver stuff floating back and forth easily between this special spin (wich patches Fedora would not take) and the official Fedora? E.g. something similar to what OLPC in parts did?

Something like that afaics would be needed if we really want to be a proper foundation for other distros, as the "once Fedora-size fits all" is a good goal we should aim for with Fedora, but on the way to that sometimes special treatment and a semi-fork might be needed. Not to mention the old Who will ship the sources to fulfil the GPL-requirements problem that's still unsolved.

IOW: if we really want to be a proper foundation for other distributions there is much work to do afaics.

[Update 20071129-2110UTC]I just reused the word "foundation" (meant as in "base for a product/distribution" here) from the Cnet source. Do not confuse it with the "Fedora Foundation", a idea which was abandoned long ago.[/Update]

Problems updating kernels and kmods

I announced in on fedora-list@redhat.com and freeworld@livna.org already, but seems a lot of people ran into the problem and missed my post, so I put a slightly enhanced version of my post here as well:

F8 users with kmods will run into problems when updating to the
latest kernel from Fedora due to a problem in yum from F8 (at least
it looks like a bug in yum to me atm). See
https://bugzilla.redhat.com/show_bug.cgi?id=330711
for details. The problem looks like this:

# yum update
Setting up Update Process
Resolving Dependencies
--> Running transaction check
---> Package kernel.i686 0:2.6.23.1-49.fc8 set to be updated
---> Package kmod-nvidia-96xx.i686 0:96.43.01-17.lvn8 set to be updated
--> Processing Dependency: kmod-nvidia-96xx-2.6.23.1-49.fc8 for package: kmod-nvidia-96xx
--> Processing Dependency: kernel-i686 = 2.6.23.1-42.fc8 for package: kmod-nvidia-96xx-2.6.23.1-42.fc8
--> Running transaction check
---> Package kmod-nvidia-96xx-2.6.23.1-49.fc8.i686 0:96.43.01-17.lvn8 set to be updated
--> Processing Dependency: kernel-i686 = 2.6.23.1-42.fc8 for package: kmod-nvidia-96xx-2.6.23.1-42.fc8
--> Finished Dependency Resolution

If you run into this problem you can uninstall the kernel-modules for
the current kernel with this command :

rpm -e --nodeps $(rpm -qa 'kmod-*2.6.23*')

as workaround and then run yum update; you should get the new kernel and
the new kmods for it when running "yum update" afterwards.

Sorry for the trouble. Note that we have seem other problem in F7 due to this problem in the past already as well. According to a comment in above bug report it looks like other kernel module packaging standards might be affected as well.

While at it: looks like there is another bug in yum that affects kmods. In some situations the i586 kmod gets chosen to install, which tracks in the i586 kernel, which then leads to an error, as that has file conflicts with the i686 kernel. This is tracked in https://bugzilla.redhat.com/show_bug.cgi?id=346371
You can work around the problem by specifying which arch to install by running "yum install kmod-foo.i686".

Testing new features in rawhide

Much talk about pulseaudio everywhere, so I wondered what it's all about and wanted to take a closer look (I likely should have done it weeks ago, but I was busy with other stuff...).

It wasn't really easy to find all the bits I need (I know, there were posts on fedora-devel-list or fedora-test-list weeks ago that explained what's needed, but well, that was months ago and they are not easy to find as well). Especially locating the volume control app made some trouble -- you see screenshots of it everywhere but that doesn't help much if you don't know the binary's name or the name of the package which contains it. Especially if you are so stupid as I was and just look in the packges with pulseaudio-prefix (hint for those that run into the same trap: the binary is called pavucontrol and it's package is called the same).

Those that install F8 freshly (once it's released) have more luck -- they will get the important bits by default. But rawhide testers (I updated this machine from F7 to rawhide months ago) didn't get it -- with IMHO kind of sucks, as a feature that will become by default isn't tested by default by regular rawhide users...

BTW: those that update from F7 to F8 with yum later won't get pulseaudio by default either...