Disappearing WiFi with rt2800pci

I recently did a routine package update on my Fedora 24 laptop. I’ve had the laptop for three years and have been running various Fedorae the whole time, so I didn’t think much of it. So it came as some surprise to me when after rebooting I could no longer connect to my WiFi network. In fact, there was no indication that any wireless networks were even available.

Since the update included a new kernel, I thought that might be the issue. Rebooting into the old kernel seemed to fix it (more on that later!), so I filed a bug, excluded kernel packages from future updates, and moved on.

But a few days later, I rebooted and my WiFi was gone again. The kernel hadn’t updated, so what could it be? I spent a lot of time flailing around until I found a “solution”. A four-year-old forum post said don’t reboot. Booting from off or suspending and resuming the laptop will cause the wireless to work again.

And it turns out, that “fixed” it for me. A few other posts seemed to suggest power management issues in the rt2800pci driver. I guess that’s what’s going on here, though I can’t figure out why I’m suddenly seeing it after so long. Seems like a weird failure mode for failing hardware.

Here’s what dmesg and the systemd journal reported:

Aug 01 14:54:24 localhost.localdomain kernel: ieee80211 phy0: rt2800_wait_wpdma_ready: Error - WPDMA TX/RX busy [0x00000068]
Aug 01 14:54:24 localhost.localdomain kernel: ieee80211 phy0: rt2800pci_set_device_state: Error - Device failed to enter state 4 (-5)

Hopefully, this post saves someone else a little bit of time in trying to figure out what’s going on.

Changing how HTCondor is packaged in Fedora

The HTCondor grid scheduler and resource manager follows the old Linux kernel versioning scheme: for release x.y.z, if y is an even number it’s a “stable” series that get bugfixes, behavior changes and major features go on odd-numbered y. For a long time, the HTCondor packages in Fedora used the development series. However, this leads to a choice between introducing behavior changes when a new development HTCondor release comes out or pinning a Fedora release to a particular HTCondor release which means no bugfixes.

This ignores the Fedora Packaging Guidelines, too:

As a result, we should avoid major updates of packages within a stable release. Updates should aim to fix bugs, and not introduce features, particularly when those features would materially affect the user or developer experience. The update rate for any given release should drop off over time, approaching zero near release end-of-life; since updates are primarily bugfixes, fewer and fewer should be needed over time.

Although the HTCondor developers do an excellent job of preserving backward compatibility, behavior changes can happen between x.y.1 and x.y.2. HTCondor is not a major part of Fedora, but we should still attempt to be good citizens.

After discussing the matter with upstream and the other co-maintainers, I’ve submitted a self-contained change for Fedora 25 that will

  1. Upgrade the HTCondor version to 8.6
  2. Keep HTCondor in Fedora on the stable release series going forward

Most of the bug reports against the condor-* packages have been packaging issues and not HTCondor bugs, so upstream isn’t losing a massive testing resource here. I think this will be a net benefit to Fedora since it prevents unexpected behavior changes and makes it more likely that I’ll package upstream releases as soon as they come out.

Fedora 24 upgrade

Fedora 24 was released last week, so of course I had to upgrade my machines. As has become the norm, there weren’t any serious issues, but I hit a few annoyances this time around. The first was due to packages in the RPMFusion repos not being signed. This isn’t Fedora’s fault, as RPMFusion is a completely separate project. And it was temporary: by the time I upgraded my laptop on Sunday night, the packages had all been signed.

Several packages had to be dropped by using the –allowerasing argument to dnf. Mostly these were packages installed from RPMFusion, but there were a couple of Fedora packages as well.

The biggest annoyance was that post-upgrade, I had no graphical login. I had to explicitly start the desktop manager service with:

systemctl enable kdm
systemctl start kdm

kdm had previously been enabled on both machines, but the upgrade nuked that in both cases. It looks like I’m not the only person to hit this: https://bugzilla.redhat.com/show_bug.cgi?id=1337546

And now, my traditional meaningless torrent stats!

Here’s my seeding ratios for Fedora 23:

Flavor i686 x86_64
KDE 16.2 35.6
Security 10.3 21.1
Workstation 30.9 46.7
Server 17.5 25.0

The “ratio ratio” as I call it is a comparison of seeding ratios between the two main architectures:

Flavor x86_64:i686
KDE 2.20
Security 2.05
Workstation 1.51
Server 1.43

So what does all of this tell us? Nothing, of course. Just because someone downloads a torrent that doesn’t mean they use it. Still, if we pretend that it’s a proxy for usage, all of the seeding ratios are higher than on the last release day. That tells me that Fedora is becoming more popular (yay!). 64-bit architectures are continuing to be a larger portion of the pie, as well.

Now that I’m starting to build a record of these, I can start reporting trends with the Fedora 25 release.

I support Software Freedom Conservancy

If you’ve read this blog for any length of time, you know that free and open source software is important to me. It’s important to Software Freedom Conservancy as well. Conservancy is a 501(c)(3) organization dedicated to supporting software projects.

Conservancy provides a lot of services to member projects, including financial and administrivia. Conservancy also provides license enforcement services, including support of a high-profile suit against VMWare. Although Conservancy uses litigation as a last resort, it’s sometimes necessary. However, this has lead to some corporate sponsors pulling their funding.

In order to continue their efforts, Conservancy is moving to an individual-supporter model. I first became a Conservancy supporter last year, and when it’s shortly time to renew my support, I will contribute double. Free and open source software is important to my personal and professional lives, and the services Conservancy provide to projects is invaluable.

If you use computers at all, a Conservancy project is probably an important part of your daily life. Please join me in supporting the Software Freedom Conservancy with a tax-deductible* donation today.

*Consult your tax professional to see if donations are tax-deductible in your jurisdiction.

Upgrading to Fedora 23 and some meaningless torrent stats

Since Fedora 23 was released yesterday, I went ahead and upgraded my desktop over lunch. The process was mostly painless. I followed the instructions for using dnf in Fedora Magazine, but hit a small snag: a few of the packages blocked on requirements. So I removed an old kernel-devel package and gstreamer-plugins-ugly. But I still got this:

package kf5-kdesu-5.15.0-2.fc23.x86_64 requires kf5-filesystem >= 5.15.0, but none of the providers can be installed.

That’s not great, because you can’t remove that package without also removing KDE Plasma. Taking the –best off of the dnf invocation fixed it, without any weird upgrade issues (the –best option supposedly cancels the download if a package can’t be upgraded, but everything seems good after the fact).

Since I don’t have any great tales of technical prowess to share, I thought I’d comment on the torrents. Measuring usage of an open source operating system is a really tricky thing, so I thought I might see what the torrents tell us. Keep in mind that torrents are probably a terrible way of measuring popularity, too. I’m just going to assume that most people who torrent ISOs are only torrenting the ones they actually use (instead of me, where I torrent several just to be a good citizen).

Here’s my seeding ratios for Fedora 22:

Flavor i686 x86_64
KDE 16.1 32.9
Security 8.02 13.6
Workstation 24.8 31.2
Server 10.3 15

The “ratio ratio” as I call it is a comparison of seeding ratios between the two main architectures:

Flavor x86_64:i686
KDE 2.04
Security 1.70
Workstation 1.26
Server 1.46

So what does all of this tell us? Apart from “absolutely nothing!”, it says that KDE users install on x86_64 way more than on i686. Workstation is still really popular on 32-bit machines and overall. The first 32 hours of seeding for Fedora 23 show similar patterns. Yay?

HTCondor 8.3.8 in Fedora repos

It’s only been a month-plus since HTCondor 8.3.8 was released, but I finally have the Fedora packages updated. Along the way, I fixed a couple of outstanding bugs in the Fedora package. The builds are in the updates-testing repo, so test away!

As of right now, upstream plans to release HTCondor 8.5.0 early next week, so I got caught up just in time.

Odd touchpad behavior in Fedora 22

A few days ago, the touchpad on my HP 2000 Notebook PC began acting up. It would jitter around a lot and insert phantom mouse clicks. My desktop ended up with approximately Avogadro’s number of Notes widgets. At first, I thought the touchpad was going bad. I resigned myself to a life of using a USB mouse, at least until I could buy a replacement.

As it turns out, though, it appears to be a software problem. On a whim, I opened up the KDE System Settings. When I selected “Touchpad” from the “Input Devices” menu, I saw a warning message that the saved settings did not match the current settings. Clicking “Apply” fixed…the glitch. Hopefully this helps if someone else comes across the issue. I didn’t file a bug because I don’t know what changed or how to reproduce it.

#info as a measure of meeting productivity?

It all started with a tweet:

That started a discussion between Matt and Karsten Wade about how to measure whether or not a meeting was productive. Matt suggested a count of “#action”, “#agreed”, and “#info” MeetBot commands.

about how to measure whether or not a meeting was productive. Matt suggested a count of “#action”, “#agreed”, and “#info” MeetBot commands. At this point, I had to jump in. “#info”, I felt, did not really belong in a measure of whether a not a meeting was productive.

My take is that #info should be used primarily as a reminder of things that have already been brought up on the appropriate mailing list. It serves as context for what’s going on in the discussion and should not be used to bring up new ideas.

Fedora teams particularly, and many open source teams generally, are too geographically distributed for IRC meetings to be where new items come up. Ideally, even #agreed should be mostly a formal recognition of the consensus on the mailing list. When contributors span the globe, it is nearly impossible to find a time when everyone can meet, making asynchronous communication essential.

This lines up with my philosophy about meetings in general. It’s better to share information ahead of time so people can evaluate it before the meeting. This saves time, since less explanation is required during the meeting, and it gives people the opportunity to more rationally consider their position on the topic.

Matt also suggested that #info is a way to call out things that were brought up as new in a meeting. To the extent that it’s better than not calling out new things, I agree. However, as Karsten suggested, perhaps #idea is a better.

Each team will have, to some extent, its own culture and its own rules for coming to decisions. The important thing is to make sure that contributors who can’t regularly attend IRC meetings still have the opportunity to participate in the decision-making process.

The Fundamental Theorem of Developing FLOSS

Recently Fedora developer and all-around good gal Máirín Duffy has been working on what she calls “The Fundamental Theorem of Developing FLOSS“. Inspired by what she called “opinionated non-doers”, this is an attempt to catalogue the sorts of behaviors a FLOSS developer should expect. Most of the entries revolve around change, particularly the addition or removal of features.

This isn’t some “those damn lusers” screed. Instead, Máirín offers a fairly objective summary of the experience of her and others. It’s a rather useful, if cynical, checklist of the kinds of feedback a developer might expect when introducing a change. Knowing what will happen in advance allows a project to better communicate the reasoning and impacts for a change (though the Axiom of Assuming the Worst would suggest this is a futile effort).

If I were to claim any beef with the theorem as it currently exists, it would be the Axiom of Ignoring the Source. It’s not that it’s wrong, necessarily, but that it’s incomplete. There are certainly those who are capable of reading the source, making changes, and submitting those change and yet decide not to. Sometimes it’s laziness, sometimes there are other reasons.

But there are a lot of people, and I would generally count myself among them, who lack the ability to understand the source or to make the changes I want. I think we, as various open source communities, often assume the hypothetical user is as knowledgeable as the developer and forget about the non-developer users. “Whining in an online forum” is often as much as someone can do (though it’s certainly not a productive way of expressing discontent). I’d also argue that access to source is not “the entire point” of FLOSS, but instead a means to an end. That’s more of a semantic quibble than any actual disagreement.

I suspect there’s a Fundamental Theorem of Using FLOSS to be written that is the user perspective of some of the same issues.

File a bug!

The ability for users to submit patches is often touted by advocates of open source software. “Patches welcome!” is a common refrain on mailing lists. Even if someone lacks the ability to diagnose and fix an issue, they can file a bug in the project’s system. Indeed, there’s an unwritten social expectation that users file a bug.

Sadly, these are often just empty words. “Patches welcome” can be a seemingly-polite way of saying “your problem is not important to me. Go solve it yourself and I’ll accept your solution.” And telling a user to go file a bug can be equally dismissive, especially if the bug-filing process is unpleasant.

I certainly don’t mean to imply that all or even most open source developers use these phrases as a polite cover for their disinterest. There are jerks, of course, but I suspect most developers genuinely want bug reports and patches. Last week, a very busy developer replied to a mailing list post with a terse “file a bug.” Now, I happen to know this particular developer and I know he’s keenly interested in fixing bugs. On this day, he was swamped and didn’t have time to get to the issue right away. Suspecting from the original email that the user who reported the bug wasn’t deeply technical, I took the liberty of reproducing the issue and filing a bug with the details.

Would the person who originally reported the issue have filed the bug done so if I hadn’t? We’ll never know, but I do know that he didn’t by the time I did. After creating a Red Hat Bugzilla account, selecting the right options, and filling out the bug report, he’d have to hope the developer meant it and that he bug would get fixed. As anyone who has been around a while can attest, just because a bug is filed, that doesn’t guarantee it will be fixed in the next few years.

One particular bug that I filed sticks in my memory. It was undeniably a bug, I attached a patch to fix it, and yet the bug remained untouched through several Fedora releases. Granted, it was a relatively minor issue, but if I weren’t involved with the project, I’d have been pretty put off by this. Of course, no one owes me a fix, but as Chris Siebenmann noted, if there’s a social obligation to file a bug, there’s also a social obligation to deal with the bug.

This morning,I asked on Twitter if anyone had what they’d call a “positive” bug reporting experience (as opposed to simply a not-negative experience). I was pleasantly surprised when several people chimed in to say they had. Small projects were generally the ones that drew the good responses (Jordan Sissel was mentioned by multiple people).

So what makes for a positive experience? Rapid acknowledgement and resolution were mentioned several times. Those who replied mentioned courteous and helpful interactions (e.g. asking constructive questions, filing an appropriate bug when the original bug was mis-filed). @phrawzty summed it up well: “Most importantly, however: good intentions were assumed. I never felt treated like a dangerous outsider.”

This is an area wide open for study (and I may end up doing just that), but in the meantime projects should consider how they present themselves. Large projects with more resources should make an active effort to devote some time to bug handling as a community outreach effort (I suspect large projects have worse bug experiences, in part due to the fact that nobody owns the process). When you say “patches welcome” or “file a bug”, consider what you’re really saying and if people will take it the way you mean it.

(Thanks to those who provided feedback: @cpj1, Matt SimmonsMatthew General, Patrick Cable@phrawzty, Rick Waldron@SysAdm DreddThomas Ballinger, @Twirrim, and anyone else I failed to mention.)