I spend a surprising amount of my time as part of keyring-maint telling people their requests are badly formed and asking them to fix them up so I can actually process them. The one that's hardest to fault anyone on is that we require requests to be inline PGP signed (i.e. the same sort of output as you get with "gpg --clearsign"). That's because RT does various pieces of unpacking of MIME messages that mean that a PGP/MIME signatures that have passed through it are no longer verifiable. Daniel has pointed out that inline PGP is a bad idea and got as far as filing a request that RT handle PGP/MIME correctly (you need a login for that but there's a generic read-only one that's easy to figure out), but until that happens the requirement stands when dealing with Debian's RT instance. So today I finally added the following lines to my .muttrc rather than having to remember to switch Mutt to inline signing for this one special case:send-hook . "unset pgp_autoinline; unset pgp_autosign" send-hook rt.debian.org "set pgp_autosign; set pgp_autoinline"
i.e. by default turn off auto inlined PGP signatures, but when emailing anything at rt.debian.org turn them on.
(Most of the other things I tell people to fix are covered by the replacing keys page; I advise anyone requesting a key replacement to read that page. There's even a helpful example request template at the bottom.)
 RT sticks a header on the plain text portion of the mail, rather than adding a new plain text part for the header if there are multiple parts (this is something Mailman handles better). It will also re-encode received mail into UTF-8 which I can understand, but Mutt will by default try to find an 8 bit encoding that can handle the mail, because that's more efficient, which tends to mean it picks latin1.
Update: Apparently Mutt in Jessie and beyond doesn't have the pgp_autosign option; you want crypt_autosign instead (and maybe crypt_autopgp but that defaults to yes so unless you've configured your setup to do S/MIME by default you should be fine). Thanks to Luca Capello for pointing this out.
Assuming this post shows up then I'll have successfully migrated from Chronicle to a temporary replacement.
Chronicle is awesome, and despite a lack of activity recently it is not dead. (No activity because it continued to do everything I needed for my blog.)
Unfortunately though there is a problem with chronicle, it suffers from a bit of a performance problem which has gradually become more and more vexing as the nubmer of entries I have has grown.
When chronicle runs it :
In the general case you rebuild a blog because you've made a entry, or received a new comment. There is some code which tries to use memcached for caching, but in general chronicle just isn't fast and it is certainly memory-bound if you have a couple of thousand entries.
Currently my test data-set contains 2000 entries and to rebuild that from a clean start takes around 4 minutes, which is pretty horrific.
So what is the alternative? What if you could parse each post once, add it to an SQLite database, and then use that for writing your output pages? Instead of the complex data-structure in-RAM and the need to parse a zillion files you'd have a standard/simple SQL structure you could use to build a tag-cloud, an archive, & etc. If you store the contents of the parsed-blog, along with the mtime of the source file you can update it if the entry is changed in the future, as I sometimes make typos which I only spot once Ive run make steve on my blog sources.
Not surprisingly the newer code is significantly faster if you have 2000+ posts. If you've imported the posts into SQLite the most recent entries are updated in 3 seconds. If you're starting cold, parsing each entry, inserting it into SQLite, and then generating the blog from scratch the build time is still less than 10 seconds.
The downside is that I've removed features, obviously nothing that I use myself. Most notably the calendar view is gone, as is the ability to use date-based URLs. Less seriously there is only a single theme, which is what is used upon this site.
In conclusion I've written something last night which is a stepping stone between the current chronicle and chronicle2 which will appear in due course.
PS. This entry was written in markdown, just because I wanted to be sure it worked.
I made damson jam, it's something I've not made for years. It's the first year we've had fruit from our damson tree. Sadly we were on holiday when the fruit was at it's prime so we lost some to birds and age. In the end we had about 1.5 kg of fruit that was okay, to which we added a further 1.5 kg of cooking apples we collected from a box in the village.
I gave everything a wash and picked out the past redemption fruit, and put the cleaned damsons and roughly chopped apples in the jam pan and added 400 ml of water. I then heated the mixture and gave it a good mashing until it was all broken up and soft. Previously I've tried making jelly but the yield is dreadful, so instead I forced the mush through a collander to hold back the stones, pips and coarse material.
Next I cleaned everything up and started on the jamimg process. I added 1.5 kg of sugar, 300 ml of water and the juice of a lemon into the jam pan and heated to boiling. I then poured in my 1.5 kg of apple and damson puree, and brought quickly to the boil. I let it have a full rolling boil for about three minutes (damsons and apples have a lot of pectin and if you boil for too long you just get rubber). I then potted it up and left it to cool.
From this batch I got 9.75 jars of jam, which isn't too bad at all. It's not as clear jelly, but it tastes plenty good and it's a lot easier to make than proper whole fruit jam. When I put it in the jars it was very runny and didn't lool jam at all, this morning when I inspected it had set well, I'll find out tonight if it's over cooked!
Personally I believe that any application packaged for Debian should neither phone home, attempt to download plugins over HTTP at run-time, or update itself.
On that basis I've filed #761828.
As a project we have guidelines for what constitutes a "serious" bug, which generally boil down to a package containing a security issue, causing data-loss, or being unusuable.
I'd like to propose that these kind of tracking "things" are equally bad. If consensus could be reached that would be a good thing for the freedom of our users.
(Ooops I slipped into "us", "our user", I'm just an outsider looking in. Mostly.)