New to Fedora: wordgrinder

Do you ever wish you had a word processor that just processed words? Font selection? Pah! Styling? Just a tiny bit, please. Or maybe you read Scott Nesbitt’s article on Opensource.com and thought “I’d like to try this!” If this sounds like you, then it may interest you to know that WordGrinder is now available on Fedora 25, 26, and Rawhide.

View of WordGrinder in a terminal

WordGrinder

I should clarify that it’s only available on some architectures (x86_64, i686, aarch64, and armv7hl). WordGrinder depends on luaJIT which is only available on those platforms.

This is my first new Fedora package, and I have to say I’m kind of proud of myself. I tried to volunteer someone else for it, but he didn’t know how to build RPMs so I ended up volunteering myself. In the process, I had to patch the upstream release to build on Fedora, and then patch my patch to get it to build on Rawhide. In true Fedora fashion, I submitted my patch upstream and it was accepted. So not only did I make a new package available, but I also made an improvement to a project written in a language that I don’t know.

Yay open source!

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.