Unofficial NVidia bugzilla?

September 2, 2012

The idea for this really comes from the Unofficial ATI bugzilla at http://ati.cchtml.com which appears to be successful. For NVidia issues the official way has been to email linux-bugs@nvidia.com or the unofficial method of posting on http://nvnews.net and hoping for a reply. Unfortunately I don’t find forums terribly useful for bug reports and the search functionality is less than ideal for issues.

I’ve been thinking of spinning up a Bugzilla instance for an Unofficial NVidia Bugzilla and inviting all distros to use it as well as the NVidia Linux engineers. But obviously I’d need some user/developer interest in this.

Would you use it?

I’ve been receiving a lot of questions lately from people wanting to use libvirt with virsh and not wanting to use a GUI (e.g. virt-manager). They’ll get gung-ho and install libvirt and start up virsh and be confronted with an error almost right away. Obviously from a user perspective, this is a bad experience so I think a little background is in order.

libvirt runs in two modes called system and session. These terms are identical to D-Bus so if you are familiar with that just think in those terms. If not, system is the instance that runs as a system daemon. It has an init script at /etc/init.d/libvirtd and will run as root. The session instance runs as a normal user. It is not started at boot time but dynamically by someone using virsh. The default when running virsh as root is to connect to the system instance. The default when running virsh as a normal user is to connect to the session instance. This is why people say their virtual machines have disappeared or they can't connect typically. There are four ways to connect to the system instance as a normal user:

  • virsh -c qemu:///system
  • virsh and at the prompt connect qemu:///system
  • export LIBVIRT_DEFAULT_URI=qemu:///system and running virsh
  • edit /etc/libvirt/libvirt.conf and set uri_default=qemu:///system

Now if you haven't built libvirt with PolicyKit support, by default only root will be able to communicate with the system instance. You will have to edit /etc/libvirt/libvirtd.conf and change unix_sock_rw_perms to something more open like 0770 or 0777 (the former will require changing unix_sock_group to a group your user is part of). Then restart libvirtd to get the new permissions.

The last issue to befall people relates to libvirt's recent switch to using XDG_RUNTIME_DIR and XDG_CONFIG_HOME from the XDG Base Directory Spec. The defaults for these are $HOME/.cache/ and $HOME/.config/ respectively. The issue that gets people is that your X session manager creates these directories for you if they don't exist but libvirt does not. So for people logging into a user that never uses X, they won't have these directories. As a result when exiting virsh you will get an error that it couldn't save your command history. Additionally you will not be able to start a session instance without these directories present. The simplest fix is to just do mkdir $HOME/{.cache,.config} and all should be well. Note: This last issue is now resolved for the forth coming 0.10.0 release.

Users of qemu-kvm may have noticed that as of 0.15.1 it has a new dependency on sys-apps/seabios from the Coreboot project. Previously we used the pre-built versions that shipped with qemu-kvm, however this version is typically out of date and has recently caused problems for some users. Ubuntu and Fedora have switched to not using the pre-built versions and building their own versions of all the binary blobs recently as well so for Gentoo we’ll do the same. The issue however is that some of these can only be built with a x86 toolchain so we will have to come up with a solution for ppc. Any suggestions are welcome.

NVIDIA has just pushed out their first beta of the 290.x series drivers and this should be seen as good news for Gentoo users. Several bugs that I’ve pushed upstream from Bugzilla reports about the 280.x and 285.x series have been fixed. This should be the first series that Gentoo will support with xorg-server 1.11 and Linux 3.0. Additionally NVIDIA has built in a workaround for users using a noexec mounted /tmp when executing 32 bit OpenGL apps on a 64 bit kernel. Users should be aware that the workaround brings in performance implications but at least your app won’t crash. Many other little issues were resolved as well so I am inclined to bump the version in the against our typical policy of not supporting beta releases. Be aware however that if I see an abnormal amount of bugs with the beta release it will be quickly masked.

So with Mac OS X 10.6.x, Apple has required that each mailbundle be explicitly marked as compatible with Mail.app. This means that most of the time your mailbundle’s don’t work cause of a silly version check. To get around this issue, I’ve made a little script that fixes your mailbundles. It’s important to run it right after you upgrade to 10.6.4 but before you start Mail.app for the first time.

Download Here

#!/bin/sh

echo "Fetching UUID for Message.framework"
MESSAGE=`defaults read /System/Library/Frameworks/Message.framework/Resources/Info PluginCompatibilityUUID`
if [ $? -ne 0 ]; then
echo "Failed to get UUID for Message.framework"
exit 1
fi

echo "Fetching UUID for Mail.app"
MAIL=`defaults read /Applications/Mail.app/Contents/Info PluginCompatibilityUUID`
if [ $? -ne 0 ]; then
echo "Failed to get UUID for Mail.app"
exit 1
fi

for bundle in `find ~/Library/Mail/Bundles/ -type d -depth 1 -name '*.mailbundle'`; do
echo "Setting Message.framework UUID for `basename $bundle`"
defaults write "$bundle/Contents/Info" SupportedPluginCompatibilityUUIDs -array-add "$MESSAGE"
if [ $? -ne 0 ]; then
echo "Failed..."
exit 1
fi

echo "Setting Mail.app UUID for `basename $bundle`"
defaults write "$bundle/Contents/Info" SupportedPluginCompatibilityUUIDs -array-add "$MAIL"
if [ $? -ne 0 ]; then
echo "Failed..."
exit 1
fi
done

echo
echo "Success!"
echo "Try to use Mail.app now"
exit 0

kvm changes in Gentoo

November 22, 2009

Since I got saddled with maintaining kvm without really having the desire (I use it but not all that often) and not really having the time to maintain it, I asked for someone to take over maintainership. Unfortunately I didn’t get any replies so the package has remained fairly unmaintained and dead-ish. Well I’ve decided today to take some time and clean it up a little bit and get it up to speed a little. However, this means that there are some changes coming.

We will use qemu-kvm releases and will no longer rename everything to make it play nicer together. External kernel modules won’t be supported and you’ll be expected to build the right settings into the kernel. If you want to use the external kernel modules, that’s up to you. qemu and qemu-kvm will be blockers since they will overlay greatly.

Really the optimal thing would be for a group of people to take over kvm and qemu and maintain them together.

NVIDIA legacy drivers update

November 13, 2009

As I previously noted, the 96.x.y and 173.x.y series had not seen any updates yet for xorg-server 1.7 compatibility, however today that has changed. They both saw updates late last night from NVIDIA and now those drivers are available in the Gentoo tree so feel free to give them a try.

MythTV 0.22 is out

November 8, 2009

As many may have already known, MythTV 0.22 is officially out. Slashdot is late to the party to report the news, however Gentoo does have ~arch ebuilds available in the tree for MythTV and all officially supported plugins. In the future I may add an ebuild as well for mythstream since it is a fairly popular plugin.

Some known issues include compilation problems on x86 as a result of PIC support, the issue is being looked into actively. For this upgrade, you must manually upgrade your database however the process is pretty painless.

If you run into any other issues, please file a bug and I’ll do my best to get to it.

As always happens when we see a new xorg-server release people start to wonder why the Gentoo ebuilds for nvidia-drivers have blockers for the new release. To help clarify this I’ll post an ASCII table showing the current support.

driver series   maximum ABI
-------------   -----------
71.86.*         2.x
96.43.*         5.x
173.14.*        5.x
190.*           6.x

xorg server     video ABI
-----------     ---------
1.7.*           6.x
1.6.*           5.x
1.5.*           2.x

As you can see from the above, the 71.86.x series has gone into very limited maintenance mode. I would be surprised to see very many updates, if any at all to it in the future. However, for users of the 96.43.x and 173.14.x series, NVIDIA has confirmed to me that there will be an update to the latest xorg-server ABI change. This update though does not have any definite dates so I can't provide any. I recommend users of that series stay with xorg-server-1.6.x releases for the time being so they can have a smooth X experience.

Improved VDPAU abstraction

October 28, 2009

Recently, Aaron Plattner from NVIDIA announce libvdpau 0.2, which a wrapper for driver specific VDPAU implementations. You may have noticed that nvidia-drivers shipped a libvdpau.so library for a while now for apps to link against while placing their actual implementation in libvdpau_nvidia.so. Newer ebuilds of nvidia-drivers will no longer install libvdpau.so, nor any of the headers and install will rely on this being installed. Other applications, like MythTV will instead depend on x11-libs/libvdpau.

In addition to this change, there’s a new package called vdpauinfo in the tree. Some people might know it from the NVNews forums as vdpinfo. However, Aaron got the author’s permission to add it to freedesktop.org and rename it to vdpauinfo to match the library.

Follow

Get every new post delivered to your Inbox.