Unsurprisingly, I awoke to a disappointing response from the Debian bugs team. The email was sent privately so I wont post it here, but it boils down to “nah man, this is normal”. On a whim, I have therefore asked the Debian TC if they have a policy on quality and correctness review of patches inserted by Debian into upstream software:
On the recommendation of a friend on a business themed social network, I have just sent the following email to owners@bugs.debian.org about my experiences on the Debian bug tracker recently. It will be interesting to see if anything comes of it.
So… a really really long time ago I wrote a small set of PNG utilities called pngtools. They’re not particularly complicated or anything, but a few distros decided to package them, including Debian (and therefore Ubuntu), Gentoo, Mint, and so forth. I’ve talked previously here about resurrecting the old subversion commit history and attempting to modernize the code.
And then something weird happened. A couple of weeks ago a github issue was filed against pngtools. The entire bug report is a single sentence pointing to the Debian bug tracker where people are being… weird. I think perhaps I accidentally overlapped with two things — a slightly entitled user, and people who appear to “karma farm” by pushing bug reports from Debian upstream with the minimum possible level of detail. Certainly when I look at the github history for these users they do not have a good hit rate for reporting bugs which actually result in a fix upstream. I am unclear on why they would be doing this thing if their goal isn’t either to acquire a fix or to earn some sweet sweet made up internet points.
This is just a delightfully retconned note to say that PNGtools 1.2 was released on this date.
This is just a delightfully retconned note to say that PNGtools 1.2 was released on this date.
This is just a delightfully retconned note to say that PNGtools 1.1 was released on this date.
In the early 2000s I was in my mid 20s, working a dead end job as a Windows programmer, and had two very young kids who were not super good at sleeping. I had worked as what I would now call a systems programmer for the Australian patents and trade marks office for a few years in the late 1990s doing low level image manipulation code -- we had a for the time quite impressive database of scanned images of patents and trademarks, and sometimes we need to do things like turn them into PDFs or import a weird made up image format from the Japanese patents office. So when you combined those things -- previous experience in a field I found interesting, a job I did not currently find interesting, and a lot of spare time very early in the morning because the kids wouldn't sleep but my wife really did need a rest -- you end up with a Michael who spent a lot of time writing image manipulation code on his own time. Even back then I was pretty into Open Source, so I released what I think was probably the first Open Source PDF generation library,…
This is just a delightfully retconned note to say that PNGtools 1.0 was released on this date.
I was recently contacted about availability problems with the code for pngtools. Frankly, I'm mildly surprised anyone still uses this code, but I am happy for them to do so. I have resurrected the code, placed it on github, and included the note below on all relevant posts: A historical note from November 2020: this code is quite old, but still actively used. I have therefore converted the old subversion repository to git and it is hosted at https://github.com/mikalstill/pngtools. I will monitor there for issues and patches and try my best to remember what I was thinking 20 years ago...
Wow, this is a blast from the past. When I wrote the pngchunks command in 2003, I had never seen a 64 bit machine, and knew enough to check that an int was the right size, but not enough to just use the guaranteed-to-be-32-bit version from day 1. I'd pretty much forgotten about this code until I got pinged about this Debian bug. The bug reporter is entirely right, this was lame. PNGtools 0.4 should be 64 bit safe. The pngchunks command works on my 64 bit machines at least. A historical note from November 2020: this code is quite old, but still actively used. I have therefore converted the old subversion repository to git and it is hosted at https://github.com/mikalstill/pngtools. I will monitor there for issues and patches and try my best to remember what I was thinking 20 years ago...