Much to my dismay, I figured out that my blog has been disabled on the Ubuntu planet since May. If you are curious about what I have been up to, please go to the handy links -> and read up! This post is a continuation of last weeks https://www.scarlettgatelymoore.dev/kde-a-day-in-the-life-of-the-kde-snapcrafter/ IMPORTANT: I am still looking for a super awesome team lead for a super amazing project involving KDE and Snaps. Time is running out and well the KDE world will be a better a better place if this project goes through! I would like to clarify, this is a paid position! A current KDE developer would be ideal as it is a small team so your time will be split managing and coding alike. If you or anyone you know might be interested please contact me ASAP! Snaps: I am wrapping up the 23.04.3 KDE applications release! Head on over to https://snapcraft.io/search?q=KDE and enjoy! We are now up to 180 snaps! PIM snaps will be slowly rolling in as they go through manual reviews for D-Bus. Snapcraft: minor fix in qmake plugin found by ruff. Launchpad: I almost have approval for per application repository snapcraft files, but I have to prove it will work to our benefit and not cause loads of polling etc. So I have been testing various methods of achieving such a task, and so far I have come up with launchpads ability to watch and download release tarballs into a project. I will then need to script getting the tarball and pushing it to a bzr branch from which I can create a proper snap recipe. Unfortunately, my proper snap recipe fails! Hopefully a very helpful cjwatson will chime in, or if anyone wants to take a gander please chime in here: https://bugs.launchpad.net/launchpad/+bug/2031307 As reality sets in that my project may not happen if I don t find anyone, I need help surviving until I find work or funding to continue my snap work ( still much to do! ) If you or anyone else you know enjoys our snaps please consider a donation, anything helps! Please share! Thank you for your consideration!

We had some requests to get GHC (the Glasgow Haskell Compiler) up and running on two new Ubuntu architectures: arm64, added in 13.10, and ppc64el, added in 14.04. This has been something of a saga, and has involved rather more late-night hacking than is probably good for me. Book the First: Recalled to a life of strange build systems You might not know it from the sheer bulk of uploads I do sometimes, but I actually don't speak a word of Haskell and it's not very high up my list of things to learn. But I am a pretty experienced build engineer, and I enjoy porting things to new architectures: I'm firmly of the belief that breadth of architecture support is a good way to shake out certain categories of issues in code, that it's worth doing aggressively across an entire distribution, and that, even if you don't think you need something now, new requirements have a habit of coming along when you least expect them and you might as well be prepared in advance. Furthermore, it annoys me when we have excessive noise in our build failure and proposed-migration output and I often put bits and pieces of spare time into gardening miscellaneous problems there, and at one point there was a lot of Haskell stuff on the list and it got a bit annoying to have to keep sending patches rather than just fixing things myself, and ... well, I ended up as probably the only non-Haskell-programmer on the Debian Haskell team and found myself fixing problems there in my free time. Life is a bit weird sometimes. Bootstrapping packages on a new architecture is a bit of a black art that only a fairly small number of relatively bitter and twisted people know very much about. Doing it in Ubuntu is specifically painful because we've always forbidden direct binary uploads: all binaries have to come from a build daemon. Compilers in particular often tend to be written in the language they compile, and it's not uncommon for them to build-depend on themselves: that is, you need a previous version of the compiler to build the compiler, stretching back to the dawn of time where somebody put things together with a big magnet or something. So how do you get started on a new architecture? Well, what we do in this case is we construct a binary somehow (usually involving cross-compilation) and insert it as a build-dependency for a proper build in Launchpad. The ability to do this is restricted to a small group of Canonical employees, partly because it's very easy to make mistakes and partly because things like the classic "Reflections on Trusting Trust" are in the backs of our minds somewhere. We have an iron rule for our own sanity that the injected build-dependencies must themselves have been built from the unmodified source package in Ubuntu, although there can be source modifications further back in the chain. Fortunately, we don't need to do this very often, but it does mean that as somebody who can do it I feel an obligation to try and unblock other people where I can. As far as constructing those build-dependencies goes, sometimes we look for binaries built by other distributions (particularly Debian), and that's pretty straightforward. In this case, though, these two architectures are pretty new and the Debian ports are only just getting going, and as far as I can tell none of the other distributions with active arm64 or ppc64el ports (or trivial name variants) has got as far as porting GHC yet. Well, OK. This was somewhere around the Christmas holidays and I had some time. Muggins here cracks his knuckles and decides to have a go at bootstrapping it from scratch. It can't be that hard, right? Not to mention that it was a blocker for over 600 entries on that build failure list I mentioned, which is definitely enough to make me sit up and take notice; we'd even had the odd customer request for it. Several attempts later and I was starting to doubt my sanity, not least for trying in the first place. We ship GHC 7.6, and upgrading to 7.8 is not a project I'd like to tackle until the much more experienced Haskell folks in Debian have switched to it in unstable. The porting documentation for 7.6 has bitrotted more or less beyond usability, and the corresponding documentation for 7.8 really isn't backportable to 7.6. I tried building 7.8 for ppc64el anyway, picking that on the basis that we had quicker hardware for it and didn't seem likely to be particularly more arduous than arm64 (ho ho), and I even got to the point of having a cross-built stage2 compiler (stage1, in the cross-building case, is a GHC binary that runs on your starting architecture and generates code for your target architecture) that I could copy over to a ppc64el box and try to use as the base for a fully-native build, but it segfaulted incomprehensibly just after spawning any child process. Compilers tend to do rather a lot, especially when they're built to use GCC to generate object code, so this was a pretty serious problem, and it resisted analysis. I poked at it for a while but didn't get anywhere, and I had other things to do so declared it a write-off and gave up. Book the Second: The golden thread of progress In March, another mailing list conversation prodded me into finding a blog entry by Karel Gardas on building GHC for arm64. This was enough to be worth another look, and indeed it turned out that (with some help from Karel in private mail) I was able to cross-build a compiler that actually worked and could be used to run a fully-native build that also worked. Of course this was 7.8, since as I mentioned cross-building 7.6 is unrealistically difficult unless you're considerably more of an expert on GHC's labyrinthine build system than I am. OK, no problem, right? Getting a GHC at all is the hard bit, and 7.8 must be at least as capable as 7.6, so it should be able to build 7.6 easily enough ... Not so much. What I'd missed here was that compiler engineers generally only care very much about building the compiler with older versions of itself, and if the language in question has any kind of deprecation cycle then the compiler itself is likely to be behind on various things compared to more typical code since it has to be buildable with older versions. This means that the removal of some deprecated interfaces from 7.8 posed a problem, as did some changes in certain primops that had gained an associated compatibility layer in 7.8 but nobody had gone back to put the corresponding compatibility layer into 7.6. GHC supports running Haskell code through the C preprocessor, and there's a __GLASGOW_HASKELL__ definition with the compiler's version number, so this was just a slog tracking down changes in git and adding #ifdef-guarded code that coped with the newer compiler (remembering that stage1 will be built with 7.8 and stage2 with stage1, i.e. 7.6, from the same source tree). More inscrutably, GHC has its own packaging system called Cabal which is also used by the compiler build process to determine which subpackages to build and how to link them against each other, and some crucial subpackages weren't being built: it looked like it was stuck on picking versions from "stage0" (i.e. the initial compiler used as an input to the whole process) when it should have been building its own. Eventually I figured out that this was because GHC's use of its packaging system hadn't anticipated this case, and was selecting the higher version of the ghc package itself from stage0 rather than the version it was about to build for itself, and thus never actually tried to build most of the compiler. Editing ghc_stage1_DEPS in ghc/stage1/package-data.mk after its initial generation sorted this out. One late night building round and round in circles for a while until I had something stable, and a Debian source upload to add basic support for the architecture name (and other changes which were a bit over the top in retrospect: I didn't need to touch the embedded copy of libffi, as we build with the system one), and I was able to feed this all into Launchpad and watch the builders munch away very satisfyingly at the Haskell library stack for a while. This was all interesting, and finally all that work was actually paying off in terms of getting to watch a slew of several hundred build failures vanish from arm64 (the final count was something like 640, I think). The fly in the ointment was that ppc64el was still blocked, as the problem there wasn't building 7.6, it was getting a working 7.8. But now I really did have other much more urgent things to do, so I figured I just wouldn't get to this by release time and stuck it on the figurative shelf. Book the Third: The track of a bug Then, last Friday, I cleared out my urgent pile and thought I'd have another quick look. (I get a bit obsessive about things like this that smell of "interesting intellectual puzzle".) slyfox on the #ghc IRC channel gave me some general debugging advice and, particularly usefully, a reduced example program that I could use to debug just the process-spawning problem without having to wade through noise from running the rest of the compiler. I reproduced the same problem there, and then found that the program crashed earlier (in stg_ap_0_fast, part of the run-time system) if I compiled it with +RTS -Da -RTS. I nailed it down to a small enough region of assembly that I could see all of the assembly, the source code, and an intermediate representation or two from the compiler, and then started meditating on what makes ppc64el special. You see, the vast majority of porting bugs come down to what I might call gross properties of the architecture. You have things like whether it's 32-bit or 64-bit, big-endian or little-endian, whether char is signed or unsigned, that sort of thing. There's a big table on the Debian wiki that handily summarises most of the important ones. Sometimes you have to deal with distribution-specific things like whether GL or GLES is used; often, especially for new variants of existing architectures, you have to cope with foolish configure scripts that think they can guess certain things from the architecture name and get it wrong (assuming that powerpc* means big-endian, for instance). We often have to update config.guess and config.sub, and on ppc64el we have the additional hassle of updating libtool macros too. But I've done a lot of this stuff and I'd accounted for everything I could think of. ppc64el is actually a lot like amd64 in terms of many of these porting-relevant properties, and not even that far off arm64 which I'd just successfully ported GHC to, so I couldn't be dealing with anything particularly obvious. There was some hand-written assembly which certainly could have been problematic, but I'd carefully checked that this wasn't being used by the "unregisterised" (no specialised machine dependencies, so relatively easy to port but not well-optimised) build I was using. A problem around spawning processes suggested a problem with SIGCHLD handling, but I ruled that out by slowing down the first child process that it spawned and using strace to confirm that SIGSEGV was the first signal received. What on earth was the problem? From some painstaking gdb work, one thing I eventually noticed was that stg_ap_0_fast's local stack appeared to be being corrupted by a function call, specifically a call to the colourfully-named debugBelch. Now, when IBM's toolchain engineers were putting together ppc64el based on ppc64, they took the opportunity to fix a number of problems with their ABI: there's an OpenJDK bug with a handy list of references. One of the things I noticed there was that there were some stack allocation optimisations in the new ABI, which affected functions that don't call any vararg functions and don't call any functions that take enough parameters that some of them have to be passed on the stack rather than in registers. debugBelch takes varargs: hmm. Now, the calling code isn't quite in C as such, but in a related dialect called "Cmm", a variant of C-- (yes, minus), that GHC uses to help bridge the gap between the functional world and its code generation, and which is compiled down to C by GHC. When importing C functions into Cmm, GHC generates prototypes for them, but it doesn't do enough parsing to work out the true prototype; instead, they all just get something like extern StgFunPtr f(void);. In most architectures you can get away with this, because the arguments get passed in the usual calling convention anyway and it all works out, but on ppc64el this means that the caller doesn't generate enough stack space and then the callee tries to save its varargs onto the stack in an area that in fact belongs to the caller, and suddenly everything goes south. Things were starting to make sense. Now, debugBelch is only used in optional debugging code; but runInteractiveProcess (the function associated with the initial round of failures) takes no fewer than twelve arguments, plenty to force some of them onto the stack. I poked around the GCC patch for this ABI change a bit and determined that it only optimised away the stack allocation if it had a full prototype for all the callees, so I guessed that changing those prototypes to extern StgFunPtr f(); might work: it's still technically wrong, not least because omitting the parameter list is an obsolescent feature in C11, but it's at least just omitting information about the parameter list rather than actively lying about it. I tweaked that and ran the cross-build from scratch again. Lo and behold, suddenly I had a working compiler, and I could go through the same build-7.6-using-7.8 procedure as with arm64, much more quickly this time now that I knew what I was doing. One upstream bug, one Debian upload, and several bootstrapping builds later, and GHC was up and running on another architecture in Launchpad. Success! Epilogue There's still more to do. I gather there may be a Google Summer of Code project in Linaro to write proper native code generation for GHC on arm64: this would make things a good deal faster, but also enable GHCi (the interpreter) and Template Haskell, and thus clear quite a few more build failures. Since there's already native code generation for ppc64 in GHC, getting it going for ppc64el would probably only be a couple of days' work at this point. But these are niceties by comparison, and I'm more than happy with what I got working for 14.04. The upshot of all of this is that I may be the first non-Haskell-programmer to ever port GHC to two entirely new architectures. I'm not sure if I gain much from that personally aside from a lot of lost sleep and being considered extremely strange. It has, however, been by far the most challenging set of packages I've ported, and a fascinating trip through some odd corners of build systems and undefined behaviour that I don't normally need to touch.

New Laptop: Thinkpad x120e My travels the last few days have not been to anywhere new. I spent a few days at Tumco, then spent today in Algodones and am staying the night at Quechen Casino. Since I never described my new computer due to network problems, I figured now would be a good time to do so. I purchased a discontinued Lenovo Thinkpad x120e laptop. It has 2gb ram, a 320gb hard drive, dual-core AMD processor, and no optical drive. The first thing I did was wipe windows off of it and install Debian Squeeze (stable), then attempt to upgrade to Debian Wheezy (testing). (Squeeze lacked the drivers for some hardware.) Wheezy lacked the drivers for the display, so during the boot sequence it would switch to an unreadable screen. I eventually found that Sid (unstable) had the driver for the display in non-free. (To install it I needed to boot with the Squeeze kernel.) The most significant thing I have not yet debugged is hibernate mode. One thing I really like about this system is the 4-6 hour battery life. This is enough that I can charge during the day when my solar is in absorption mode (meaning the panels are producing more power than the house battery can safely take) and use it at night and in the morning when there is no spare solar power without depleting the house battery. The 12v charger that I had purchased for my old Thinkpad (which died, prompting the replacement) works fine on my new one. I purchased a USB powered DVD writer to give me optical capability when I need it. This uses two of the three USB ports. The network problem I had this summer was the Millenicom 3g USB stick glitched and needed to be reset with their proprietary software that is only available for Windows and Mac. Lacking access to a Windows system that I could install software on, this meant that I was without my network connection. I used the Sandy Library (fast, free wifi) 30 miles from my worksite and occasionally wifi at a closer coffee shop or cafe which were both unreliable.

It s general election time again in New Zealand this year, with the added twist of an additional referendum on whether to keep MMP as our electoral system. If you re not interested in New Zealand politics, then you should definitely skip the rest of this post. I ve never understood why some people consider their voting choices a matter of national security, so when via Andrew McMillan, I saw a good rationale for why you should share your opinion I found my excuse to write this post. Party Vote
I ll be voting for National. I m philosophically much closer to National than Labour, particularly on economic and personal responsibility issues, but even if I wasn t the thought of having Phil Goff as Prime Minister would be enough to put me off voting Labour. His early career seems strong, but lately it s been one misstep and half-truth after another, the remainder of the Labour caucus and their likely support partners don t offer much reassurance either. If I was left-leaning and the mess that Labour is in wasn t enough to push me over to National this year then I d vote Greens and hope they saw the light and decided to partner with National. Electorate Vote
I live in Dublin, but you stay registered in the last electorate where you resided, which for me is Tamaki. I have no idea who the candidates there are, so I ll just be voting for the National candidate for the reasons above. MMP Referendum
I have no real objections to MMP and I think it s done a good job of increasing representation in our parliament. I like that parties can bring in some star players without them having to spend time in an electorate. I don t like the tendency towards unstable coalitions that our past MMP results have sometimes provided. Of the alternatives, STV is the only one that I think should be seriously considered, FPP and it s close cousin SM don t give the proportionality of MMP and PV just seems like a simplified version of STV with limited other benefit. If you re going to do preferential voting, you might as well do it properly and use STV. So, I ll vote for a change to STV, not because I m convinced that MMP is wrong, but because I think it doesn t hurt for the country to spend a bit more time and energy confirming that we have the right electoral system. If the referendum succeeds and we get another referendum between MMP and something other than STV in 2014, I ll vote to keep MMP. If we have a vote between MMP and STV in 2014 I m not yet sure how I d vote. STV is arguably an excellent system, but I worry that it s too complex for most voters to understand. PS. Just found this handy list of 10 positive reasons to vote for National, if you re still undecided and need a further nudge. Kiwiblog: 10 positive reasons to vote National

In Ubuntu, the use of ptrace is restricted. The default allowed relationship between the debugger and the debuggee is that parents are allowed to ptrace their descendants. This means that running gdb /some/program and strace /some/program Just Works. Using gdb s attach and strace s -p options need CAP_SYS_PTRACE, care of sudo. The next most common use-case was that of crash handlers needing to do a live ptrace of a crashing program (in the rare case of Apport being insufficient). For example, KDE applications have a segfault handler that calls out to kdeinit and requests that the crash handling process be started on it, and then sits in a loop waiting to be attached to. While kdeinit is the parent of both the crashing program (debuggee) and the crash handling program (debugger), the debugger cannot attach to the debugee since they are siblings, not parent/descendant. To solve this, a prctl() call was added so that the debugee could declare who s descendants were going to attach to it. KDE patched their segfault handler to make the prctl() and everything Just Works again. Breakpad, the crash handler for Firefox and Chromium, was updated to do effectively the same thing, though they had to add code to pass the process id back to the debuggee since they didn t have it handy like KDE. Another use-case was Wine, where for emulation to work correctly, they needed to allow all Wine processes to ptrace each other to correctly emulate Windows. For this, they just declared that all descendants of the wine-server could debug a given Wine process, there-by confining their ptrace festival to just Wine programs. One of the remaining use-cases is that of a debugging IDE that doesn t directly use ptrace itself. For example, qtcreator will launch a program and then later attach to it by launching gdb and using the attach command. This looks a lot like the crash handler use-case, except that the debuggee doesn t have any idea that it is running under an IDE. A simple solution for this is to have the IDE run its programs with the LD_PRELOAD environment variable aimed at a short library that just calls prctl() with the parent process id, and suddenly the IDE and its descendants (i.e. gdb) can debug the program all day long. I ve got an example of this preloadable library written. If it turns out this is generally useful for IDEs, I could package it up like fakeroot and faketime.

There is not much I miss from the world of gluten (though it does make it hard to eat on the fly) but I do miss good beer, especially Belgium beer. Thankfully, the last five years has seen a mini-explosion of decent to great gluten free products, including beer and here is a handy list of gluten free beers.

Serendipity is my blogging software of choice lately, but in the past I was a happy user of LiveJournal. Fortunately, now my friends at LJ can keep up to date with my current blog, because of a great event plugin which mirrors posts here on LiveJournal (configurable of course). On LJ people use markup like [lj user="jamuraa"] in order to make a handy link to the page of the livejournal user in question. I was missing that feature, so I coded up a small plugin for s9y which converts that into jamuraa. This is version 0.1, which only does the user tag. It also works in comments if you enable it. In the future, I hope to add code to detect the user type correctly (on LiveJournal there are other icons for different user types). I also probably should not hotlink to the .gifs on the livejournal servers.

To install, just unzip into the plugins/ directory of your s9y installation.

Download the LJ Markup Plugin 0.1 for Serendipity

Since interviewing the creator of Ruby on Rails, David Heinemeier Hansson, I've been thinking a little more about what he calls "opinionated software." That handy little phrase seems to sum up what attracts me to a lot of technology, at all levels. What I like Free software--it's not really economics that drew me to free software, but the principles and aims. When you release or use free software, you're exercising your right to free speech and adding your voice to an argument. Desktop environments--GNOME 2.0: The move from GNOME 1.0 to version 2.0 was highly opinionated (Mac users, think OS 9 to OS X). Complexity of user interface was thrown out in favour of sensible defaults. Web standards--CSS, RDF, XHTML: not only is there a right way to do things, but it turns out to be better too! I don't automatically fall in love with everything that emerges from the W3C, but some things are so obviously the right way it's impossible not to love them--warts and all. Muine music player--this player throws out the paraphernalia of iTunes clones and gets you close to the music. Queue, play. What I want to do. Epiphany web browser--a simple text bar does for bookmark lookup, search and URLs. The bookmarks work like del.icio.us tags. Despite the lure of Firefox extensions, simplicity and efficiency keeps me with Epiphany. Make friends and enemies The thing about opinions is that people are inclined to disagree with them. Opinions won't please everybody and, being opinionated, you will never carry everybody with you. But opinions give you something with which to scythe through indifference. In both my writing and software development work taking a particular stance enables me to create interest, and gives direction to my projects. I tend to get bored easily, and if I'm bored, then my readers and users will never make it. Being opinionated in software development is easier when there's a strong leader, or it's a one-person project. It's more of a dilemma if you're running a free software project with multiple contributors. Such projects need such contributions, but run a risk of losing focus and style. I think that there we need to be brave again. If being opinionated means losing potential users, it also means losing potential contributors. Opinions help in dealing with users, too. It's obvious that the mere act of listening to users isn't good enough. They often won't say what they mean, or their requests mask a deeper issue. How often have you given your boss exactly what he asked for, to find it wasn't what he wanted? A combination of reading-between-the-lines and having opinions helps cut a way through the noise of user feedback. Stirring the pot Here are a few wishes for some free software projects that I want to see succeed further, but which really need to get opinionated to be effective. These projects aren't failing, but they're not reaching the potential I know is there. Each of them are infrastructural in some way, and that's probably where the temptation to avoid being opinionated is strongest. But here's the genius: the rewards of being opinionated here are high. Ruby on Rails is the existence proof.

• Beagle, live search technology for GNOME. Needs to decide where its primary use will be, and get on and hit the 1.0 point for that use only. Choose one or two neat applications for integration, and be so utterly cool that every other app author flocks to integrate too.
• Synchronization. First MultiSync, then OpenSync, have rumbled on for ages, without ever being truly effective for any particular device. My take: choose a few "must-have" target devices--say, iPods and Nokia phones--and make them work completely. Nearly-but-not-quite pleases nobody.
• Mono. Mono's great, but where's the story? There's loads of potential in the people and the ideas behind the project, but playing catchup with Microsoft isn't very inspiring. Early projects like Muine helped Mono's cachet here, but we need more. My personal favourite option would have been a completely free alternative to ASP.NET for web applications. (I've seen a project called MonoRail, but don't know if it's the one...)

What's better? A handful of users with the "right" idea about how fundamentally important you are to everything, or loads of users who only see a portion of the capabilities of a project? Copy the experts It may seem like cheating to copy Apple's lead, but a lot of what they've done in OS X is to take a stand on what's useful and not. On many occasions this has inconvenienced people, but it's not eroded that special lure that Apple products hold. There's not harm in asking "What have Apple done?" with some of our projects. Another poster-child for being opinionated is Ubuntu Linux. Technically, it's only marginally better than other Linux distributions. Strategically, it's miles ahead. Its founder, Mark Shuttleworth, had very solid opinions about where Ubuntu should go, and pursued them. Over time, these have pervaded the product itself, but at the start it was the message and the style that made the difference. Opinions not expressed are rarely effective.