HP laptop keyboard won’t type on Linux

Here’s another story from my “WTF, computer?!” files (and also my “oh I’m dumb” files).

As I regularly do, I recently updated my Fedora machines. This includes the crappy HP 2000-2b30DX Notebook PC that I bought as a refurb in 2013. After dnf finished, I rebooted the laptop and put it away. Then while I was at a conference last week, my wife sent me a text telling me that she couldn’t type on it.

When I got home I took a look. Sure enough, they keyboard didn’t key. But it was weirder than that. I could type in the decryption password for the hard drive at the beginning of the boot process. And when I attached a wireless keyboard, I could type. Knowing the hardware worked, I dropped to runlevel 3. The built-in keyboard worked then.

I tried applying the latest updates, but that didn’t help. Some internet searching lead me to Freedesktop.org bug 103561. Running dnf downgrade libinput and rebooting gave me a working keyboard again. The bug is closed as NOTABUG, since the maintainers say it’s an issue in the kernel, which is fixed in the 4.13 kernel release. So I checked to see if Fedora 27, which was released last week, includes the 4.13 kernel. It does, and so does Fedora 26.

That’s when I realized I still had the kernel package excluded from dnf updates on that machine because of a previous issue where a kernel update caused the boot process to hang while/after loading the initrd. I removed the exclusion, updated the kernel, and re-updated libinput. After a reboot, the keyboard still worked. But if you’re using a kernel version from 4.9 to 4.12, libinput 1.9, and an HP device, your keyboard may not work. Update to kernel 4.13 or downgrade libinput (or replace your hardware. I would not recommend the HP 2000 Notebook. It is not good.)

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.