############################## nwf Contributes to Open 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 https://github.com/archlinuxarm/PKGBUILDs/issues/1082 for details. The IRC conversation of the next day is too good to not include, but see below in :ref:`nwf-contributes-to-open-source_appendix_alarm-sshfs`. As a result of this, I moved to running Debian, and, in general, I suggest against using Arch Linux Arm if possible. Binutils ######## https://sourceware.org/bugzilla/show_bug.cgi?id=15178 fixes a linker glitch on FreeBSD/sparc64. Darcs ##### http://bugs.darcs.net/issue904 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 http://bugs.darcs.net/msg5218); eventually, my patch was accepted, verbatim, in Febuary, 2013. http://bugs.darcs.net/issue992 submitted a mockup patch in August, 2008 (http://bugs.darcs.net/msg5545); 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. http://bugs.darcs.net/issue978 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 ############# http://leaf.dragonflybsd.org/mailarchive/users/2005-05/msg00047.html brought to their libc the understanding of a new relocation type gcc had recently started emitting. Firefox ####### Don't expect logical things from profiles, kids: * https://bugzilla.mozilla.org/show_bug.cgi?id=99828#c63 submitted February, 2013. Patch rejected, issue still not resolved for political reasons; see https://bugzilla.mozilla.org/show_bug.cgi?id=99828#c73 . * https://bugzilla.mozilla.org/show_bug.cgi?id=486172 related to the above, REOPENed May, 2013. Still REOPENed as of this writing. FreeBSD ####### Generally very pleasant group of people to interact with. Of several bug reports, a few are worth commenting on. Kernel ====== https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=139527 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. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=140523 another (!) ``setcontext`` bug on sparc64. Apparently TLS happened while no-one was watching. Fixed promptly by the maintainer. Ports ===== https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=140073 is a pretty typical patch for me; those guys fixed something that's still broken over here. It's thematic. Git ### http://marc.info/?l=git&m=126112719810059 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 ################ https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51615 reported Dec, 2011. Exhibits a bug in the condition variables of ``gij`` runtime libraries. Stayed open until the project was abandoned (!). Glibc ##### https://sourceware.org/bugzilla/show_bug.cgi?id=6577 ; 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) Haskell Ecosystem ################# I have made largely trivial contributions to ``trifecta``, ``wl-pprint-extras`` (which should probably now be deprecated in favor of ``prettyprinter``), and a few other packages. Linux Kernel ############ kafs ==== A few small patches to kafs and rxrpc got accepted in May, 2014: * https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=656f88ddf1ec3abf2cd20b8b4028c44e8e95f56d * https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=150a6b478982475c60fa25b7060ab990ece5483d * https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=6cf12869f5c1a837f18af5f8b2308fa243772735 * https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=fde0133b9cfa4e01b275e942ffc32fd78e27d27c ext4 ==== A tragically long-running thread starting in April 2014 (http://lists.openwall.net/linux-ext4/2014/04/10/4) may have helped contribute to http://patchwork.ozlabs.org/patch/375106/ (July 2014), if I may be so bold. misc ==== * https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=a26af1e08a3a1e0f88e6f2685ac2313d713a59c9 fixes a small glitch with `tun` devices (Feb, 2008). NodeMCU ####### I am one of several volunteer maintainers of the NodeMCU Lua-on-Espressif platform. OpenAFS ####### I have a small pile of patches in the tree and pending. Many are very minor or janitorial. http://gerrit.openafs.org/#change,10966 is perhaps the most relevant to a contribution log, and it is not yet officially in tree. However, these patches enabled me to obtain employment as a contractor for AuriStor, Inc. OpenSC ###### I have corrected some truly glaring flaws in what should be secure and carefully audited software. https://github.com/OpenSC/OpenSC/pull/1141 and https://github.com/OpenSC/OpenSC/pull/1143 . OpenVPN ####### A long-time fan of the product, I filed a minor bug https://community.openvpn.net/openvpn/ticket/649 and they acknowledged with no drama. OpenWRT ####### I maintain a small fork of OpenWRT, mostly for integrating and tweaking patches. https://github.com/nwf/openwrt I am listed as maintainer for a few inconsequential packages in their tree. Plan 9 (Ports) ############## * https://github.com/9fans/plan9port/commit/df1ee4e1af9340a8207535c5009ec289bf1ecda1 fixes a 64-bit-unsafe bug in libthread threadstart (June, 2008) * https://github.com/9fans/plan9port/commit/fd0a0b2a6216ae9b1773da719c3c0e53ff2e87c8 fixes a minor glitch in Venti/copy (February, 2009) * ``venti/copy`` truncation bug https://codereview.appspot.com/162860045 fixes a major data loss opportunity in venti/copy. (Developers unresponsive for months as the project is basically dead AFAICT; finally fixed November, 2014.) Shorewall ######### * A minor patch which makes IPTABLES raw rules work: http://sourceforge.net/p/shorewall/code/ci/468167f9e52f57dbc91d0e642d03396fc1e1441e/ (March, 2015). RISC V / SiFive ############### I have low opinions of the RISC V community; it seems a damn shame. * https://github.com/riscv/riscv-qemu/pull/159 * https://github.com/sifive/clic-spec/issues/10 Tor ### Mostly bug reports. The Tor team is very responsive in general and has well-meaning, competent people. * https://trac.torproject.org/projects/tor/ticket/651 assertion failure; wasn't able to debug but upstream did just fine. * https://gitweb.torproject.org/tor.git/commit/?id=d48f6425e5c7822a0852d94450fdaa8625e95003 * https://gitweb.torproject.org/tor.git/commit/?id=d964beac16d00252242609d9e5fb5459b4d76983 * https://gitweb.torproject.org/tor.git/commit/?id=299014b2c784c0bb72188f4db55d099b69a4e7f4 * https://trac.torproject.org/projects/tor/ticket/9498 relatively low-priority issue got very little traction; remains open. Wine #### 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 http://source.winehq.org/git/wine.git/commit/d30dfd24d6ab2f52bb4f29aee59e75238c648fc4 http://source.winehq.org/git/wine.git/commit/bd3771c2ee0b2352eddb632505a112afa6360313 March 1999, allowed isolating registry backing stores. http://source.winehq.org/git/wine.git/commit/7bf36ad35dda45d5e6b192fe2b83605134bb0129 October 1999, expanded above. -------- Appendix -------- Don'T Be That Guy ################# I have encountered a few... exemplars of people not to emulate. I'm sure these are not the worst cases you'll find. When reporting things that might be bugs, allow room in your first contact that you might have missed something. Don't be this guy: https://github.com/nodemcu/nodemcu-firmware/issues/2683 .. _nwf-contributes-to-open-source_appendix_alarm-sshfs: Arch Linux ARM sshfs ==================== Here, preserved for all to see, is how the package maintainer responded to a miscompilation. I will admit to briefly losing my temper, but don't be this guy, either. :: 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 https://github.com/archlinuxarm/PKGBUILDs/issues/1082 20:11:53 phrik | Title: sshfs segfault ? Issue #1082 ? archlinuxarm/PKGBUILDs ? GitHub (at github.com) 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 https://projects.archlinux.org/svntogit/community.git/plain/trunk/PKGBUILD?h=packages/sshfs 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: https://wiki.archlinux.org/index.php/Arch_Build_System 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.