Show Source

I am a bit of a nomadic developer and as such I have had my fingers in a lot of source out there. For some reason I decided to start collecting memories in text here. Honestly, none of this is very impressive work; it’s just sweeping up around the edges a bit at best. It’s meant to be mostly an index for myself and show, if anything, breadth, not depth.

Case Log

Sorted by project and by date of filing or submission. Year of acceptance (which is sometimes hilariously in the future) will be noted when different.

Arch Linux Arm

Feb, 2015: attempted to file a bug report on sshfs package. See for details. The IRC conversation of the next day is too good to not include, but see below in Arch Linux ARM sshfs. As a result of this, I moved to running Debian, and, in general, I suggest against using Arch Linux Arm if possible.

Binutils fixes a linker glitch on FreeBSD/sparc64.

Darcs submitted (in July 2008) a patch to cause darcs to fall back to its already existant “sloppy” lock-file locking scheme, rather than an atomic-creation-based one. The whole thread is worth reading, but suffice to say that I was curtly dismissed and continuted to be ignored even after an exhaustive walk of the software stack involved (see; eventually, my patch was accepted, verbatim, in Febuary, 2013. submitted a mockup patch in August, 2008 (; was soundly dismissed two weeks later by project lead author in favor of similar idea which never came to fruition. Issue remains open and unsolved within the community. tried to extend darcs patch algebra, August 2008. Gave up on darcs entirely shortly after the above patch, though. Issue remains open and unresolved.

DragonFly BSD brought to their libc the understanding of a new relocation type gcc had recently started emitting.


Don’t expect logical things from profiles, kids:


Generally very pleasant group of people to interact with. Of several bug reports, a few are worth commenting on.

Kernel another portability bug brought about by some “clever” macros for manipulating bytes. Patched, but unfixed upstream (entirely my fault; I stopped caring and didn’t report back for years); but I don’t think anyone tries running the hardware in question on sparc64 other than me. another (!) setcontext bug on sparc64. Apparently TLS happened while no-one was watching. Fixed promptly by the maintainer.

Ports is a pretty typical patch for me; those guys fixed something that’s still broken over here. It’s thematic.

Git switches a single type declaration to use a C99 type rather than a C89 type, thereby fixing bugs encountered on FreeBSD/sparc64.

GCC Java Support reported Dec, 2011. Exhibits a bug in the condition variables of gij runtime libraries. Still open, occasionally even gets traffic (as of this writing, in January, 2015!).

Glibc ; diagnosed a problem (ultimately stemming from the use of plan9port on Linux sparc64) and mis-assigned as a glibc bug. Glibc team wonderful, fixes and patches kernel on my behalf. (May, 2008)


I have a small pile of patches in the tree and pending. Many are very minor or janitorial.,10966 is perhaps the most relevant to a contribution log, and it is not yet officially in tree.


A long-time fan of the product, I filed a minor bug and they acknowledged with no drama.


I maintain a small fork of OpenWRT, mostly for integrating and tweaking patches.

Plan 9 (Ports)



Mostly bug reports. The Tor team is very responsive in general and has well-meaning, competent people.


Maybe my first official contribution to open source.

Adding the -config option to wine, in September, 1998. Maybe too old for the actual commit object, but see the changelog in March 1999, allowed isolating registry backing stores. October 1999, expanded above.


Arch Linux ARM sshfs

Here, preserved for all to see, is how the package maintainer responded. I will admit to briefly losing my temper.

20:07:58         nwf | Does kmihelich hang out here?
20:10:16      +mdrjr | nwf: yes ..
20:11:17         nwf | mdrjr: Are you he under a different handle? :)
20:11:23      +mdrjr | nope
20:11:32      +mdrjr | just ask your question :)
20:11:51         nwf | Well, I was hoping for clarification on
20:11:53       phrik | Title: sshfs segfault ? Issue #1082 ?  archlinuxarm/PKGBUILDs ? GitHub (at
20:13:18      +mdrjr | since there's no pkgbuild on ALARM repo
20:13:26      +mdrjr | it belive its something fixed on upstream Arch
20:14:32         nwf | Well, upstream seems to not have a 2.5-1.1 PKGBUILD, assuming is upstream?
20:14:45         nwf | (Sorry, I'm still kinda new to Arch and not sure where all the bits are)
20:15:00 @WarheadsSE | nwf: it comes right from abs
20:15:11         nwf | What is abs, sorry?
20:15:16 @WarheadsSE | yes, Arch "proper" is our "upstream"
20:15:22 @WarheadsSE | !give nwf wiki abs
20:15:23       phrik | nwf:
20:15:27         nwf | Thankee
20:17:04         nwf | Well, so I *think* that means that my confusion stands: the PKGBUILD I linked to is 2.5-1, not 2.5-1.1.
20:17:50      +mdrjr | I believe that .1 is just a rebuild version of 2.5-1
20:18:10 @WarheadsSE | Either you, or kmihelich built that test version
20:18:39         nwf | OK, so that's a different form of confusion, then: when *I* rebuilt 2.5-1 locally with debug symbols, it crashed just like the packaged 2.5-1 did, so I don't know what
                     | kmihelich's terse assertion about an alignment issue means.
20:19:14 @WarheadsSE | memory alignment
20:19:54         nwf | No, I mean... I know what memory alignment is (I'm a kernel developer in my spare time).  I don't know what he thinks he fixed when he rebuilt the program.
20:20:47     @leming | what i fucking *think* i fixed?
20:20:51 @WarheadsSE | not seeing the changes he made to the pkgbuild, he might have set a harder enforcements of the cflags
20:20:56     @leming | i know what i fixed, because i fucking fixed it
20:22:09     @leming | it got rebuilt using the toolchain that's been out for month now that doesn't allow building code that causes unaligned access
20:22:27     @leming | which was the actual problem with the program, diagnosed by a very simple *kernel* tool
20:22:31         nwf | Apologies, leming.  I would like to know what changes you made so that I can apply them locally in hopes of fixing the *nigh on identical* crash happening elsewhere in
                     | the program, as shown in the last comment on the bug.
20:22:31     @leming | which a kernel developer would know about
20:23:18     @leming | no changes were made, it was just rebuilt, like i fucking said
20:23:24     @leming | how hard is this to understand?
20:23:36         nwf | ... so why when I rebuilt it did it not fix the problem?
20:23:51     @leming | probably because you don't have an updated system, or know what you're doing, or both
20:24:11         nwf | Uh, I'm fully up to date so far as I know and I'd appreciate if you didn't talk down to me like that?
20:25:30     @leming | the issue is fixed and closed, move on
20:25:53         nwf | It still fucking crashes, running 2.5-1.1, on my machine.
20:25:59         nwf | Should I open a new issue for the new crash?
20:46:34         nwf | leming: Assuming it was you who just pushed fuse 2.9.3-2.1
20:46:44         nwf | Things seem to be working better now.
20:46:53     @leming | yes, that wasn't pushed through before
20:48:04         nwf | Is that also just a rebuild of 2.9.3-2 using the new tool chain?
20:49:16     @leming | what do you think?
20:51:19         nwf | I'm insufficiently versed in Arch specific details to know for sure, but I am going to guess so, yes.
20:51:25         nwf | Thank you for giving it another look.