polka dot blog

As you may be aware, Lubuntu is transitioning from GTK to Qt graphics libraries, which means a transition from LXDE to LXQt. Same people, more or less, just different libs. Of course, every component is different. We finally have packages in Debian and Ubuntu Xenial. There's even instructions on how to install them!

We needed to subscribe our Lubuntu Packages Team to all of these bug mails. Sure, we could have went to 18 different source package pages and just clicked our way to it, but that kind of takes a darn while.

Luckily there's a solution: launchpadlib. Just a pip install away (or use package python-launchpadlib), it gives you all sorts of control over and access to Launchpad data. It's almost better than using the web interface! Well, assuming you're fine with Python.

In our case here, it's possible to simply name a team and/or person and give it a list of packages and have it subscribe them all. Takes a few seconds after you have the code, which you can find here. The meat of the code is one line:

lp.distributions['ubuntu'].getSourcePackage(name=filearray[i]).addBugSubscription(subscriber=lp.people[teamtowrite])

which is basically like saying for a particular source package in the Ubuntu project, add a bug subscription for the particular team or person. Heck, it almost reads like normal English.

This might be useful for normal people, too. Say you wanted to subscribe to all the bugs for a particular set of packages you're helping to develop. It'd be great for that.

More than anything, it shows the power of the Launchpad API and the hard work that Colin and the rest of the Launchpad team put into it!

With that, I'd like to especially thank cjwatson, dobey, and wgrant, whom were all helpful in figuring this out on IRC, as well as tsimonq2, who was responsible for the majority of the code.

Politics is an interesting word. We take it to mean exercising and acquiring power, exerting control, or simply using force. None of us like this notion at all. We like to think of ourselves and independent entities, capable of our own decision making abilities, without any need for outside influence, whether harmful or otherwise. And yet, we have politics, whether it be in our countries, our cities, our workplaces, our hobbyist organizations, or even our homes. Even when considering the battle cry of the early anarcho-punks of the 70s and 80s, "peace & anarchy," there is still a sentiment of using community power to ensure peace. I think, like it or not, politics is something we as humans need to empower us to coexist together. It's the check and balance we need to our own primal selfishness. It's what allows us to exist in community. And that's the really interesting part of the word. Its root lies in the Greek polis, which refers to either a city or a body of citizens. It refers to a community. It's focused on the concerns of the people.

In the world of open source, community often refers to users and volunteers that help development the software (including the people that provide support, documentation, artwork, etc.). The politics that occurs within this community is the leadership that facilitates peace amongst different personalities and expectations and makes the tough decisions about how precious resources are allocated. Usually there is a set of guidelines that allow the leaders (who, again, are often volunteers, thrown into the fire of whatever's happening that development cycle) to judge what decision to make. It's not easy, especially when you have volunteers (have I mentioned this enough yet?) who may have no really formal training or on-the-job experience in management or leadership. It's amazing we can do as much as we can.

This is especially true in that defining poltics as dealing with the concerns of the people does not necessarily say how those concerns are met. This is why we have egalitarianism in one system and dictatorship in another. This is as true in the world of state government as it is in the world of open source community governance. In fact, I have my concerns about our fearless Linux Leader Linus after reading about the concerns behind Matthew Garrett forking the kernel. I do enjoy his bitter diatribes against things I don't enjoy (e.g. "XML is crap") but in reading many of his quotes, I'm really appalled at how terrible he is.

And yet I find myself nearly every day working to encourage users to become contributors, contributors to contribute more, and long-time vets to keep at it. Work is hard. Volunteering is hard. Being in a community is hard. Volunteering to work in a community is downright painful at times. People need encouragement. That may mean a little handholding sometimes, or a simple expression of praise or graciousness. It's not just enough to ensure quality. It's not enough to create a vision and ensure the projects sticks with it. Our open source projects need open source communities and open source leadership. And they all need to work together. The primary responsibility for that cohension is in the hands of the leaders. If they can't lead in a way that empowers the communities to propel the project, then they should move on.

I have a great interest in leadership. Not management. I don't like managing people. I believe that people well suited to a particular project, with the right amount of support and guidance, will manage themselves. Leadership fulfills that conditional. For this reason, I helped create LinuxPadawan, a free Linux mentorship program. But I don't want to just deal with technical issues. I'd like to help with the truly difficult decisions and conversations.

With this in mind, I have joined the Ubuntu Membership Board (which I believe fulfills a similar role as LinuxPadawan, i.e. trying to encourage contributions) and the Ubuntu LoCo Council¹, to help encourage Ubuntu activity on a localized scale. I'm also the Team Leader for the Ubuntu Oregon Team. And though it's more technical, I serve as one of the Release Managers for Lubuntu as well as the Head of QA. I love all of these tasks and have no intention of leaving any one of them, but I'm still hungry to help more.

I recognize that not everyone is a leader. Not everyone wants to try to be. Many don't even want the responsibility. Heck, many folks aren't very social. I have no problem communicating with people, in thinking about things in an objective, balanced manner, and I jump for the opportunity to help in this manner. To be the grease that keeps the community gears turning.

As such, I have accepted a nomination to the Ubuntu Community Council. Armed with the values of the Ubuntu Code of Conduct, their job is to handle both the most high level of concerns (intellectual property rights) as well as dealing with resolving conflict. Ensuring that the community has the tools and resources it needs to function well is what they do. And I couldn't be more excited to join them.

In any case, votes are required from Ubuntu Members² to decide which nominees will go on to hold a seat on the council. That being said, I encourage you to consider me for the task³. You can read more about me, especially as it relates to Ubuntu, on my wiki page (including testimonals from others I've worked with, which you're welcome to add to!). Feel free to use any of those methods and/or the comments on this blog to ask any questions you might have.

¹For those unfamiliar with governance in Ubuntu, the Community Council delegates to boards such as the Membership Board and LoCo Council, so I'm not taking over the whole governance structure. From what I understand, this has been a fairly common model for folks, perhaps a sign of how needed leaders are.

²If you're not an Ubuntu Member, come chat with me about becoming one. It's easy and is not without its benefits!

³As a member, you will get an automatic email with a personal link to make the vote. The results will appear here here (corrected at 15:02pm in response to this). I'd also recommend viewing the official announcement.

Recently, the arrival of desktop Linux (and, no, I refuse to say GNU/Linux as much I refuse to say GNU/X/OpenBox/LXDE instead of Lubuntu) was announced. I think this came as no surprise to those of us that already use it on desktop. Sure, people may complain about this and that, but, honestly, Linux gives you choices. You can find your perfect desktop on Linux quite easily in this day and age of package managers. Filled with pre-compiled binaries, changing even components of a desktop environment is fairly seemless and just a few clicks away. Gone are the days of having to roll your own kernel from scratch (though, in typical fashion, you have the choice to do so). Heck, you rarely have a need to touch the command line (though it's often quicker). With Chromebooks and about half of the mobile devices out there running Linux under the hood, user-focused Linux is certainly here.

However, if we revisit that blasted GNU acronym, we should be reminded that GNU's Not Unix, or rather that Linux's Not Unix (ooh, we could fix the naming controversy by calling it LNU… but then someone would wawnt to call it G/LNU and that would be hard to pronounce). See, Linux owes its design and heritage (though not its code) to Unix. In fact, Unix is still plugging along, with some notable examples being the ever-secure OpenBSD, the distro that runs on pretty much everything, NetBSD (yes, that does include Amiga and VAX!), the almighty FreeBSD which is widely used by web servers, OS X, and plenty of embedded devices, and the version from whence Linux was born: MINIX.

So one might wonder how desktop Unix is doing. OS X certainly has made it but the FreeBSD core, Darwin, is quite different. Not to mention that it's a walled garden. It's not easy to change your window manager and using the command line is a frustrating experience, especially if you don't want to use the GUI. I guess that's not a very "user-focused" concern, but I think it reflects just how much OS X deviates from anything we think of as Unix-like. Ignoring that, it might be good to look at FreeBSD, as it is, if I may conjecture, the most widely used Unix out there.

Well, to give one a sense of things, I had to recently do an update on a co-worker's development machine, which was running FreeBSD and had an X setup. According to the FreeBSD documentation, assuming one doesn't need the "easy button" when it comes to installing, there's no need for PC-BSD. In this case, everything was installed, so no big deal, right? For that matter, all that needed to be done was to do some security updates. Those friendly folks at FreeBSD offer a script in periodic daily that emails root with updates on packages that need to be patched for security updates. Admittedly, the thing hadn't been updated in a while, but having been doing regular maintenence on other FreeBSD servers, I figured it would be fairly straightforward.

All of these machines use ports, which is basically a package management system that uses source code and compiles with each fresh install. There's also packages, but we use ports. Adds a little extra flexibility and is no more difficult, really. The package management system takes care of everything, including dependencies, as any good package manager would. The portmaster tool makes this task quite simple, needing little more than the package name to be installed.

Unfortunately, I faced several gotchas. One, in fact, came when having to update pkg, which is usually used for binary package management. It was super weird because I couldn't install it with portmaster, even if I specified it's full location (which usually fixes any ambiguity). I looked at /usr/ports/UPDATING, which is the canonical place to look for gotchas, but didn't find anything. On a whim, I chose to include the package version to upgrade from, and that worked. Never had that happen before at all, and never found any reference of others having it.

The next one was fairly easily solved, assuming you know where to look. gettext gave me an error on its install. I found the solution in /usr/ports/UPDATING: the port had been split, so I needed to remove the port and then reinstall it. Simple fix, but greping through a text file is not something one typically should be expected to do to install a freaking package. Also, the error didn't suggest where to look for the problem. You had to put two and two together.

So then I ran into some issue with GTK. First, I was having issues with gtk-update-icon-cache. I found something related, albeit old, in /usr/ports/UPDATING, so I decided to give it a go. I understood what I was doing and that doing it wasn't going to hurt anything if it didn't fix my problem. It referenced using pkg_delete -f gtk-2.\*. Now there's several problems here, the most obvious being the fact that there are three different package management tools: pkg, pkgng, and portmaster. Sometimes you might use a pkgng command even though you otherwise use portmaster. Problem is that that's not all described in these terse notes. Secondly, GTK2 is in a port called gtk2, so the search string was wrong, too. So pkg delete -f gtk2-2.\* did the trick.

So then there was complaints about cairo not being installed with X11 support. I confirmed it was installed. I checked the Makefile and there was a line that suggested that X11 was a default, but after digging some more, I discovered that it merely was a default option. Indeed, pkg info showed me "X11: off." I decided to run make config and there I could see it was not checked. So I checked it, did a make deinstall and a make reinstall and it was recompiled with X11 support.

However, I was still having issues with gtk. it failed to compile because of some test that required working with a PNG. It complained to not recognize the format, even though file had no problem recognizing it. Google produced no truly applicable results, but there was some mention among MacPorts/Homebrew folks about glib2 and gdk-pixbuf2. Checking the config of the latter, I discovered it was lacking PNG support, so I checked it, reinstalled the two, and finally, I got everything done.

One might be inclined to believe that since this is all on the command line, such problems are to be expected. I would, in fact, suggest the otherwise. As a general rule, graphical tools are front ends to command line interfaces. Ubuntu's Synaptic Package Manager is a great example of this. It's just apt under the hood. If the backend did not have a predicable, reliable interface, where one did not have to interpret, research, and intuit in order to figure out problems, then the frontend would suffer the same problems. That being said, the potential graphical interface to the FreeBSD package management system(s) are bound to be equally flawed.

That being said, desktop Unix is not here yet. Frankly, I'm not convinced it ever will be. Unix is a tool that was originally targeted at institutional use and to this day is employed largely by system administrators and hardware hackers. It tends to be fairly conservative (I like to call it "stable to a fault", which is to say you don't get the latest and greatest googaws). It's oriented towards the command line and towards users that are familiar enough with compiling to be able to deal with issues. Granted, it's a lot easier than grabbing a tarball and figuring out all your dependencies. But desktop Linux it's not.

To be clear, this it not meant to be a bash on Unix (actually, bash is not a standard part of the install!). BSD is excellent where stability and security are required at the expense of anything else. Having the ability to sort of create your own system from scratch the easy way sure is nice. A few make configs and you can have your system locked down to only do what you want. That includes your kernel, too. I'm sure this is part of the reason why OS X uses it (well that, and its precursor, NeXTSTEP, was derived from BSD).

I'm just pointing out that just because it's been out for much longer than Ubuntu, BSD and Unix in general, has not been able to really capture the attention of desktop users while still retaining the flexibility inherient in a standard system. In that sense, it's actually pretty amazing what Linux has been able to accomplish. Call me biased, but I give special credit to Ubuntu as it has moved beyond the neckbeards and actually drawn the attention of your average Joe, not just through its wonderful user interface, but through business partnerships and outreach. That is the herald of a great desktop operating system.

Unicode 8 has arrived at last. Yes, folks, you may now use the unicorn as much as you want. Well, kinda. Unicode 7 took forever to be widely implemented, even on the mobile devices we most expect emoji from. Despite the fact that Google and Apple are part of the Unicode consortium, they've got bigger fish to fry like plummeting stock and a failed gadget release.

On the other hand, third party developers behind SwiftKey only care about making their keyboard as useful as possible. As a long time Swype user, I'm impressed. I never paid attention before because their main selling point seemed to be themes. It also cost money.

They provide fairly accurate predictability, similar to that of Swype (which far exceeds even the Google Keyboard). There are some other nice customization options that Swype doesn't have and it seems to have everything Swype has, minus the gestures.

But it has really accessible emoji support. Given their new relationship with the Unicode Consortium, I imagine they'll be the first to give us good support for 8 and next summer's 9, which will give us a face palm at long last. That should prove useful to the thumb aching fools using standard soft keyboards and lame old emotions. ;-) 👎

It's also great to see they are an open source-friendly company. SwiftKey may not be freely licensed, but they have an organization on GitHub with repos that at least show some activity this year. Everyone's got to start somewhere. At least they're not freedom haters. In fact, their latest Greenhouse project, Clarity, which is essentially a testing ground for upcoming features, uses the Eclipse-licensed Lispy-goodness, Clojure!

As for Ubuntu, it's hard to say when we'll see Unicode 8 support. I would consider it a priority for Ubuntu developers, at least for the other additions to Unicode 8 that seem like they would be to Ubuntu's larger internationalization effort. There's even some new glyphs for Ubuntu's home continent of Africa. My guess is we'll see it soon. However, I think it's clear that Ubuntu phones will be lagging around those of us who still use Android (or iOS, but who does that?).

Well, you can't say I didn't try. If you look at this question on AskUbuntu, you can certainly say I tried. I tried hard. I tried to exhaust every tool at my disposal to make my new Logitech T630 Ultrathin Bluetooth Touch mouse behave properly in Ubuntu. Unfortunately, it doesn't behave properly and respond to all the things it should, including suggestions from X input hacker Peter Hutterer (who I greatly thank for so generously taking random private messages from me on IRC). I think officially I'm ready to give up.

The verdict: one of three things needs to happen for this to be solved:

1. hack the device firmware
2. reverse engineer the non-Linux device drivers
3. fix how the kernel deals with the mouse

Unfortunately I think part of the problem lies in the fact that the mouse is partially a keyboard. When the gestures happen, keyboard events are the result. It seems to me that this is ripe for the same multitouch treatment the Apple Magic Mouse got.

Oh well.

That's not to say I didn't learn a lot about the whole input process works. That's always helpful for the troubleshooting. Here's a brief run down:

• First, there's a lot of utilities that have "keyboard" in the name. That doesn't mean they don't work for mice. Yeah, I know: weird.
• It all starts at the kernel. You can see the currently registered input devices with lsinput. Like with all kernel-level commands, you'll need to sudo.
• Input events are recorded in /dev/input/eventN where N is some integer. These events can be probed with evemu-record from the evemu-tools package.
• The kernel registers scancodes. The keymap (accessible from input-kbd from the input-utils package) registers the keycodes (and keynames, like KEY_LEFTCTRL) that should be output in response to the scan codes.
• Next layer up is the X server. As a general rule, your input device (no matter what kind it is) will be run by evdev (on other Linux systems without HAL, you'll use the mouse and kbd drivers), a generic input driver. Of course, you may have some device that has its own driver, but that's the exception rather than the rule.
• Since the options of such a driver can only be modified when the server starts, we have xinput which allows us to tweak options on the fly. Don't need sudo, either.

…or at least that's how it should work.