2010-06-03: NVIDIA, bug handling, and patience
Recently, the long-time maintainer of the NVIDIA packages for Debian
stepped down, after having not had much time to work on the packages for
some time. I don't really like maintaining non-free packages, but I have
some NVIDIA hardware and nouveau isn't quite far enough along yet for me
to feel comfortable just switching, so I decided to help, despite having
very little spare time. Thankfully, Andreas Beckmann stepped up and has
been submitting patches like crazy, so I've not had to do a lot of the
work.
This is a very difficult package to maintain, since it's completely
non-free. Nearly all the code is a binary object, which we cannot change
in any way, so it's frustrating because we can't do anything about
basically any bugs. Upstream distributes their code in a weird, annoying
package format. It's also very complicated, full of random upstream
libraries for providing various interfaces to the GPU to do computing, and
it conflicts with and replaces various X bits like the GL library. And on
top of that, it comes in four different variants, all of which need to be
separately packaged, plus a bunch of supporting packages and libraries
(some non-free and some free). Oh, and it builds a kernel module. And we
historically provided pre-built kernel modules and meta-packages. And the
packaging infrastructure hadn't been overhauled in quite some time, so it
wasn't using current packaging techniques.
Did I mention the RC bugs and the nearly 200 open bugs on just the main
non-legacy package (now much lower thanks to Andreas's hard work).
We're slowly making progress. nvidia-graphics-drivers migrated to testing
for the first time since around the lenny release and now supports DKMS,
and Andreas has massively modernized the packaging. We also have just
about finished the transition to using the free libvdpao library rather
than the one included with the NVIDIA packages.
But given that background, you might understand why one might find blog
posts like
this
one (about a bug that was first reported for KDE just one week ago!)
just a little demotivating. (The problem had been previously observed
with GDM, but it appeared to be fixed somehow in GDM 3.)
I'm sure there are better ways that I could have communicated the bug
status, and I probably stressed a bit more than I need to the point that
the module is completely opaque and non-free and there isn't much that we
can do to change its behavior. But reading negative comments about one's
work on Planet Debian is really kind of frustrating, particularly when
that work is on something that it's hard to get Debian to care about and
that's kind of thankless to start with.
I'm not trolling for praise here; I have a thick skin. But this does seem
like a good opportunity for a reminder that this is a volunteer project,
some packages are kind of annoying to maintain, and things take time. If
you don't agree with a maintainer's determination of whether or not
something is RC (I still don't think this bug is RC), one can certainly
have that conversation. But unless the maintainer marks the bug wontfix,
please don't jump to the conclusion that no one cares about trying to find
a resolution. And one week is a rather short time period to arrive at
that conclusion, even if the maintainer is fairly negative about the bug.
Sometimes that just means that you caught them on a bad day.
For the record, I'm currently pondering asking the people with this bug to
try adding nvidia to /etc/modules and see if forcing the module
load earlier works around this problem. I think what's happening is that
the module is doing some sort of prolonged initialization, and it just
needs more lead time before it's expected to respond to the X server.
2010-06-09: C TAP Harness 1.3
The primary change in this release is extensive new documentation. There
is now an overview document on how to write TAP tests with special
attention to Perl, C (using the included libtap library), and shell (using
the included shell library). There is also now API documentation for all
of the functions in the C TAP library.
Also new in this release is an okv() function in the C TAP library, which
is the same as ok() but takes the arguments for the test description
format as a va_list. This allows writers of additional test functions to
take the test description as a printf-style format and still reuse the
reporting and statistics infrastructure provided by ok().
You can get the latest version from the
C TAP Harness distribution page.
2010-06-09: pam-krb5 4.3
This release incorporates optional support for Flexible Authentication
Secure Tunneling (FAST), which is a mechanism for protecting the exchange
with the KDC using an existing ticket cache. This support was contributed
by Sam Hartman. If the fast_ccache option is set and there is a valid
Kerberos ticket in the cache it points to, and if both the local Kerberos
libraries and the KDC support FAST, that ticket will be used to protect
the authentication exchange. Currently, this requires MIT Kerberos 1.7 or
later.
Also in this release are more minor bug fixes for the alt_auth_map
configuration parsing and building on Solaris with the native compiler.
You can get the latest release from the pam-krb5 distribution page.
2010-06-24: Long time no write
Well, I see this is the first journal entry I've made in quite a while.
This has, by and large, been for good reasons for a change, although there
was a bit of exhaustion and stress in the middle of that.
I was at the AFS and Kerberos
Best Practices Workshop for the first week of this month, which was a
fantastic workshop and a good opportunity to get a ton of AFS work done.
But it was also intense and very social (involving having to drive in a
strange town, too), and so I came back rather exhausted. The next couple
of weeks didn't exactly help: I was in a lot of meetings, on an interview
panel, and dealing with a routine audit response at work.
That's one factor. Another is that I've gotten back into playing
video games rather than reading or doing other things that lead me
to write here. This got considerably worse when I discovered the
TrueAchievements site, which is
basically Ohloh for Xbox 360 players.
It's full of interesting statistics and well-done use of social networking
and is making me eager to go back and play a lot more of many games I'd
just started. That's devoured my last couple of weekends.
There's also the World Cup, which I've been watching to the tune of two or
three games a day. I can do other things while I watch (like I am right
now), but it's a distraction.
But probably the strongest factor is that I've been extremely successful
with time management over the past few weeks. As soon as I get back to
posting book reviews, I'll get the review of Do It Tomorrow up, but
the summary is that the closed list approach really works for me. I've
been making lists almost daily and am now completing them reliably, and
I'm getting much more done each day than I had been before and feeling
more in control of the structure of the day. But the interesting side
effect is that I'm also more fully utilizing my available energy, which
means that when I get home at night, I'm tired. Not a bad sort of tired,
but an accomplished sort of tired that pushes me towards watching TV or
playing games and not towards getting on-line and writing things.
I am planning on getting back to reading and writing reviews over the next
week and particularly the holiday weekend. And of course not reading
hasn't kept me from buying more books. The latest round:
Jacqueline Carey — Naamah's Curse (sff)
Stieg Larsson — The Girl with the Dragon Tattoo
(thriller)
Ursula K. Le Guin — Lavinia (sff)
Walter Jon Williams — This Is Not a Game (sff)
Robert Charles Wilson — Julian Comstock (sff)
Hopefully I'll get a chance to catch up on book reviews and read a couple
more books over the next few days, although the top priority will be to
get a new Lintian and Debian Policy release out.
All posts