Fan control with nouveau

I recently switched over to the nouveau driver for my Nvidia graphics card. I had been using the proprietary blob simply because it would slow the GPU fan when idle. However, with recent kernels, nouveau now has this ability too. You just have to enable it via sysfs.

For example, on my system, I locate the proper sysfs file:

% find /sys -name pwm1_enable
/sys/devices/pci0000:00/0000:00:02.0/0000:01:00.0/hwmon/hwmon2/pwm1_enable
/sys/devices/platform/it87.552/pwm1_enable
% readlink /sys/devices/pci0000:00/0000:00:02.0/0000:01:00.0/driver
../../../../bus/pci/drivers/nouveau

Then I can set the fan mode to auto (2):

# echo 2 > /sys/devices/pci0000:00/0000:00:02.0/0000:01:00.0/hwmon/hwmon2/pwm1_enable

A better approach is to utilize a udev rule to do the job.

% cat /etc/udev/rules.d/50-nouveau-hwmon.rules
ACTION=="add", SUBSYSTEM=="hwmon", DRIVERS=="nouveau", ATTR{pwm1_enable}="2"

Slot-operator deps for V8

The recently approved EAPI 5 adds a feature called "slot-operator dependencies" to the package manager specification. Once these dependencies are implemented in the portage tree, the package manager will be able to automatically trigger package rebuilds when library ABI changes occur. Long-term, this will greatly reduce the need for revdep-rebuild.

If you are a Chromium user on Gentoo and you don't use portage-2.2, you have probably noticed that we are using the "preserve_old_lib" kludge so that your web browser doesn't break every time you upgrade the V8 Javascript library. This leaves old versions of V8 installed on your system until you manually clean them up. With slot-operator deps, we can eliminate this kludge since portage will have enough information to know it needs to rebuild chromium automatically. It's pretty neat.

I have forked the dev-lang/v8 and www-client/chromium ebuilds into my overlay to test this new feature; we can't really apply it in the main portage tree until a new enough version of portage has been stabilized. I will be maintaining the latest chromium dev channel release, plus a couple of versions of v8 in my overlay.

If you would like to try it out, you can install my overlay with layman -a floppym. Once you've upgraded to the versions in my overlay, upgrading/downgrading dev-lang/v8 should automatically trigger a chromium rebuild.

If you run into any issues, please file a bug.

Call out for grub:2 testing

I recently started working on the sys-boot/grub package for Gentoo. The upstream project is preparing to release version 2.00, which is currently in beta.

If you are feeling adventurous, please give the new version of GRUB a try and report any bugs you find on bugs.gentoo.org. Keep a livecd handy; it is very possible to break your system.

There is a minimal guide on the Gentoo wiki, and a more in-depth page that could use some editor's love an care.

Additional documentation is available through Google or by running "info grub2" from your terminal.

cvs-status: Display a CVS checkout in svn status format

I'm quite easily distracted, so I often leave uncommitted changes hanging around in my CVS checkout. I needed a way to easily detect when I have done this so I can pick up where I left off or revert the changes.

However, CVS does not seem to have a nice compact command for displaying the status of files in a checkout like SVN or git do. cvs status is way too verbose, and the network latency makes it slow.

Portage has a nice little module called "cvstree" that it uses to parse the CVS/Entries files directly and generates a convenient data structure in memory.

So, I wrote a little wrapper that produces output in the style of the svn status command:

cvs-status

#!/usr/bin/env python

from __future__ import print_function
from portage import cvstree

myentries = cvstree.getentries(mydir=".", recursive=1)

mynew     = cvstree.findnew(entries=myentries, recursive=1)
mychanged = cvstree.findchanged(entries=myentries, recursive=1)
mymissing = cvstree.findmissing(entries=myentries, recursive=1)
myunadded = cvstree.findunadded(entries=myentries, recursive=1)
myremoved = cvstree.findremoved(entries=myentries, recursive=1)

for x in mynew:
        print('A      ', x)

for x in mychanged:
        print('M      ', x)

for x in mymissing:
        print('!      ', x)

for x in myunadded:
        print('?      ', x)

for x in myremoved:
        print('D      ', x)

This produces output like this:

floppym@naomi gentoo-x86 % cvs-status
!       net-p2p/freenet/files/freenet.old
?       .ebuild.x
?       metadata/herds.xml
?       profiles/use.local.desc

That first entry is actually a small bug in the cvstree module: it does not handle the case where an ignored file is actually under version control.

Maybe some of my fellow devs will find this useful.

Google Chrome: Plan B

A few of you have asked me how to track a specific Google Chrome release channel in Gentoo. My original plan was to leverage keywords by stabilizing the stable channel, leaving the beta channel in ~arch, and hard masking the dev channel.

We stabilized Google Chrome 14 in portage over the weekend. Afterwards (today), Markos (hwoarang) raised concern over the fact that Google immediately removes the deb files from their server after a version bump. This is troublesome since we cannot mirror the files because of Chrome's EULA.

This issue had been brought to my attention before, but it did not really sink in until it was pointed out that this breaks the stable portage tree. Google did another stable channel release today, so I have removed the stable keywords just two days after they were added.

The new plan is this: Each Chrome release channel gets its own slot, and each slot blocks all other slots. All slots will be keyworded ~arch, but the dev channel will remain hard masked. To choose your release channel, unmask/emerge google-chrome with the appropriate slot.

For example, to install the stable channel, add www-client/google-chrome:stable to package.keywords and emerge google-chrome:stable. For the beta channel, use google-chrome:beta, and google-chrome:unstable for the dev channel.

You may need to uninstall your current version of google-chrome first if portage complains about blockers. Sorry about that.

Overlay updates: chromium-pdf and thin-manifests

I have slowly been working on cleaning out packages from my overlay, either by dropping them or moving them to the gentoo-x86 tree.

I have gotten a few complaints for dropping the chromium-pdf package which installs the google-chrome pdf viewer for www-client/chromium. I have added that back, and will be bumping the versions within the next day or so. If you also have google-chrome installed, an alternative is to symlink /opt/google/chrome/libpdf.so to /usr/lib/chromium-browser/libpdf.so.

Another change is the conversion to using thin manifests, a feature introduced in portage-2.1.10.16, with some bug fixes in 2.1.10.18 (and the equivalent 2.2_alpha releases). Thin manifests only contain entries for distfiles, and rely on the VCS to validate the integrity of ebuilds. Thanks to Brian and Zac for putting in the work on this feature.

This means you will need a fairly recent version of portage to use my overlay, or you will get errors about missing manifest entries. I have no particular reason for making this change, other than I find the feature to be pretty neat.

google-chrome is in the tree

I got my commit access to gentoo-x86 last week, and the first thing I did was commit a package that nobody cares about: dev-python/PyRSS2Gen. Okay, so I was a little nervous. :) It does happen to be a dependency of a package I will be adding later.

You may be familiar with the work I have done in maintaining the google-chrome package in Kaleb's (belak) overlay. This is one of many google-chrome ebuilds that have been floating around the various overlays, but I like to think it has been kept most up to date, especially in the last 6 months or so. As a dev, I can move it to the official portage tree.

After a short licensing discussion on the dev mailing list, I added the EULA for Google Chrome to the tree. It is a fascinating read, full of terms and conditions that I'm sure somebody actually cares about. Unfortunately, the terms do not allow for free distribution of the software, so we will not be able to mirror it on distfiles.gentoo.org.

Last night, I committed ebuilds for all three Chrome release channels. The plan is to mirror the procedure followed by www-client/chromium: stable channel releases become  stable (arch) targets, beta channel releases go in ~arch, and the dev channel is hard-masked. I will wait the normal 30 days before doing the first STABLEREQ, but after that it should happen much more quickly since stable channel releases are (usually) security updates.

For those that are unaware, Google Chrome is an officially branded and pre-compiled version of www-client/chromium. If you have the horsepower or patience, I recommend using the source-based chromium package over google-chrome, for all of the usual reasons.

Chrome does have a couple proprietary components that are not included in chromium: one is an officially licensed PDF reader plugin, and the other is a bundled version of Adobe Flash (x86 only). I may end up dropping the bundled flash plugin; Gentoo provides up-to-date versions of Flash already, so there is no advantage to using the bundled copy.

Please report any bugs you find. I might not always be able to fix them (this is a binary package after all), but I will do my best.