On stabling hardware-dependent packages

I thought I wrote about this before but it looks like I didn’t. And since this was something I was asked about a few months ago as well, any time is good to fix the issue by writing what I think about this.

We could say that almost every package in the tree relies on someone having at least some pieces of hardware: a computer. At the same time, some packages require more particular hardware than others: drivers, firmware, and similar packages. The problem with these packages is that, unless you own the hardware, you have no way to know that they work at all. Sure you can be certain that they do not work, if they fail to build, but the opposite can’t be confirmed without the hardware.

This is troublesome to say the least, as sometimes a given hardware driver’s ebuild is written, by either a developer or an user (that goes on to proxy it), when they have the hardware … but it goes untouched once said hardware is gone for good. This happened to me before, for instance I no longer have a Motorola phone to test those handlers; nor I have an HP printer any longer, so there goes my help to the hplip package…

At the same time it is true I have quite a few hardware-dependent packages in the tree still: ekeyd, iwl6000-ucode, and so on so forth. One of the packages I still try to help out with even though I had to discard the related hardware (for now at least) is freeipmi, which exemplifies all too well the problems with hardware-dependent packages.

FreeIPMI, like the name leaves to imply, is an implementation of utilities and daemons to manage IPMI hardware, which is used on middle-range-to-high-end server motherboard for remote management. I had one on Yamato until recently, when either the mainboard or the PSU started to act up and I had to take it out. I had tried to making the best out of the ebuild since I had access to an IPMI board, and that consisted mostly on bumping it, fixing the build and, recently, updating its init scripts so that they actually work (in the case of the watchdog service I ended up patching it up upstream, which meant having something that actually works as intended!).

Last year, after about two years from the release of the version that was marked stable, I decided to ask for a new stable with a version of the package that surely worked better … which is not the same to say that it worked perfectly. Indeed, now I know that said version simply did not work in some configurations, at all, because the bmc-watchdog init script, as I said, did not work and required upstream changes.

What happens when I ask for a new stable this year, to cover for that issue? Well, this time around the arch teams finally decided to test the stuff they mark stable, but that also meant nobody was available to test IPMI-related packages on x86. Even our own infra team was unable to test it anywhere else beside amd64, with the end result that after months of back-and-forth, I was able to get the old package de-keyworded, which means that there is no longer a “stable” freeipmi package; you’ve got to use ~arch.

Don’t get me wrong: I’m not happy about the conclusion, but it’s better than pretending that an ancient version works.

So when Vincent – who proxy maintains the acr38u IFD driver for pcsc-lite – asks me about marking his ebuild stable, I plan on writing this very post.. and then leave it there for over five months… I apologize, Vincent, and I don’t think I have enough words to express my trouble with a delay of such proportions.

And when I get Paweł’s automated stable request for another pcsc-lite driver, my answer is an obvious one: does anybody have the hardware to test the package? I’m afraid the answer was obviously no… unless Alon still has said reader. End result is the same though: time to de-keyword the package so that we can drop the ancient ebuild, which is definitely not adhering to modern standards (well okay, -r2 isn’t much better, but I digress).

Of course the question here would be “how do you mark stable any pcsc-lite related software at all this way?” … and I don’t really have a real clear answer to that. I guess we’re lucky that the ccid driver covers so many hardware devices that it makes it much more likely that somebody has a compatible reader and some card to test it with… the card part is easy, as I suppose most people living in the so-called Western world have an ATM or credit card… and those have a chip that can be at least detected, if not accessed, by PC/SC.

There is actually a script written in Python that allows you to access at least some of the details on EMV based cards.. the dependencies should all be in Portage, but I didn’t have time to play with the code for long enough to make sure it works and it is safe to use.

There is another obvious question of course: “why don’t you stable your own stuff?” — while this could be sensible, there is a trick: my “desktop” systems – Yamato, Titan (this box) and Saladin (the laptop) – are all running ~arch for as long as I can remember… or at least part of it; I gave up on glibc-2.14 so it is masked on all of my systems, on count of breaking Ruby and I’m still pissed by the fact it was unmasked even if that was known.

Any comment to help picking up a direction about this kind of trouble?

6 thoughts on “On stabling hardware-dependent packages

  1. Diego,In some cases, where the hardware is needed to test some packages, why not ask the Foundation to buy it? That is one of the areas the Foundation can be of service to developers. You just need to ask! Next time you’re on IRC, ping me and I will walk you through the process. The Foundation may not fund every request, and its certainly not rolling in extra cash, but for reasonably priced items that have a distinct benefit to users the Foundation can handle the purchase. Thanks for your efforts!

    Like

  2. If the foundation can afford hardware, why not arrange to give Diego better hardware for the tinderbox efforts?That would have more of a benefit than anything else. It might be better to arrange with the OSUOSL to provide it, specifically because they provide hosted hardware for free to open source developers and the tinderbox is clearly something in the scope of what they support. That would allow foundation money to be spent on hardware needed to test packages.

    Like

  3. This is kind of a longshot from someone not too knowledgable in the process:If the piece of hardware has a set list of functions or commands that is either documented or test-able.. then you might be able to set up an emulation layer for hardware which allows for using the same functions and commands and return the same pre-recorded result.For all software that would build normally you could then test for compatibilty (expected output) equal to the older release.Well, it’s one thing to consider I guess, even if it’s not a perfect answer in itself it migt be a direction you haven’t looked yet..

    Like

  4. It is by far not something I’d like to rely upon. While hardware emulators make sense in some contexts, I honestly don’t see them on very reliable, not for the use of stabling software…

    Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

w

Connecting to %s