Older blog entries for joey (starting at number 538)

a special announcement from RMS

A little grep has told me that RMS is going to announce something special on olduse.net in two weeks time, on 27 September 1983. Best not to speculate about the details, but this announcement will be something people are still talking about thirty years later. So it's an event you and your news reader won't want to miss.

I have set up an IRC channel #olduse.net on FreeNode, and we'll see who first spots the post!

Syndicated 2013-09-13 23:21:41 from see shy jo

a rope ladder to the dgit treehouse

Ian has said something along the lines of dgit being a private club; if you're not in the club the strange git-centric views of its members don't affect you. With that said, dgit is now a quite usable and nice tool and we would like more people in the club.

To that end, here's one way to get into our little world where the Debian source repository is really a collection of git repositories. I recently made a new package and added it to Debian, and here is every command I typed to do it (other than vim, lintian, and dpkg -i). As you read through, notice that every command has to do with git in one way or another.

git clone https://github.com/blake2-ppc/git-remote-gcrypt

This software makes git be able to push to encrypted git remotes. Very neat stuff.

git archive --format=tar origin/master -o | gzip > ../git-remote-gcrypt_0.20130908.orig.tar.gz

Like most software on github, this one has no upstream tarball; its git repository is its native source format. Needing to manually generate this tarball appendix is the only unpleasant part of the process.

git add debian
git commit -m debianization

Had to write 48 lines of control file and stuff to make the package build.

dgit build -tc

This just runs dpkg-buildpackage. But you need to commit all files before running it.

dgit push --new

The --new is needed because this is a new package. This created the git repository for the package on alioth and pushed my changes and the upstream history to it, as well as uploadng the package to incoming.

Syndicated 2013-09-09 00:33:24 from see shy jo

best DebConf ever

For me, DebConf13 in Switzerland was a perfect DebConf, and generally an great developer meeting and conference. I've attended several past DebConfs in Canada, Norway, Brazil, Finland, Mexico, Scotland, Spain, NYC, Bosnia, and Nicaragua. I have special memories of each. DebConf13 was ideal in every way.

Let's start with the camping. Only a minority of us did it, and my campsite was located in a small field behind a bar that was often noisy late into the night, when I was trying to rest and preserve my European jetlag remedy of inverted sleeping schedule. Still, I love sleeping cocooned in a tent, and going through the routines of camping and spending time alone there was a good counterpoint to DebConf. I generally find myself retreating for a day or two in the middle of a week-long conference, burnt out with social interactions. That didn't happen this time. I need to find way to camp at future DebConfs.

(Also special shout out to wonderful people who lent me a warmer sleeping bag, and bought me a pillow while on a trip to town! Upgraded my first backpacking in Europe experience's comfort level a lot!)

The next perfect thing for me were the talks I gave at DebConf. I always enjoy presenting at DebConf, and barely remember when I'd get nervous doing it. But I really felt comfortable giving these talks in a way I've not before. I'm pleased with how the Debian Cosmology talk turned out; I'd worried it would be a downer talk, or too light, or not well received, and none of those problems surfaced.

I was especially happy with my dh_busfactor session, which I prepared for all of 10 minutes and was structured entirely to benefit me by talking over my thoughts and getting feedback, and in which I probably drove the camerapeople crazy running my own mic into the audience. Despite all that, I think it succeeded being interesting for the participants as well as for me. Hope to follow up on it soon..

But beyond the two talks I submitted, there were a series of ad-hoc scheduled talks. It seemed that every day I spent at least an hour discussing something I'm deeply involved in. This started with the Ikiwiki bof, and then there was an epic series of (unrecorded) BoFs about git stuff, which basically turned into an unofficial git track at DebConf. Much, much discussion of git-annex and other things I'm involved in.

BTW, I really like that DebConf, as well as being a formal conference on top, is really an un-conference underneath, with new BoFs and things popping up on the schedule all week long. You can even have completely unscheduled meetings that somehow get just the right mix of people to make something awesome happen.

But it wasn't all about talks. Indeed, I only attended 2 or 3 sessions a day. The DebConf13 venue was controversial, but I found it excellent for getting things done. Rather than one or two massive rooms that get too noisy to think in, this venue had many little nooks and crannies suited for different types of work. There were so many I only discovered some while walking down the hill as I was leaving the venue! Anchoring it all was the excellent view, and I particularly enjoyed the "scenic hacklab".

I was particularly impressed with the flexability of the venue's management. Someone asked if we could have cheese for breakfast, and every breakfast thereafter had not one but often three excellent cheeses. One day we'd be complaining that there were not enough vegetables in the food, and the next we'd be eating an excellent vegetarian Swiss lunch. They even apparently relaxed stringent Swiss rules on not allowing tents in sightlines visible from people further up the hill. They were clearly happy to welcome our crazy gathering to Le Camp. They let a DD borrow and use a chain saw and build a bonfire!

The venue also encouraged getting out and exploring the surrounding countryside. Too often I end up spending the whole DebConf without seeing much of the area around. This time I at least got down the hill to see the castle in Vaumarcus a few times, and enjoyed many evening walks amoung the grape fields. The conference dinner (on a boat!) tied into this well too. And the daytrip to CERN was a great addition. We got to poke around the control center for a massive particle accellerator! My only regret is we didn't get a chance to actually go inside the LHC tunnels.

Back to DebConf, another thing I really liked about this one was that its location allowed several upstream authors of software in Debian (other than the usual suspects who are both upstreams and Debian Developers) to attend. I don't know if Lennart Poettering changed any minds about systemd with his talk, but I was happy for the opportunity to buy him a beer. I didn't get to Monty's talk, but it was excellent to see him attend as well.

Finally, I got to meet old friends I'd not seen in years, and new ones I've not met in real life before. We're still not sure where this whole DebConf thing is going -- will it be all about the cheese and wine party and greybeards in 20 years time? But one thing we know is we enjoy our little slice of the year where kilts and coding are equally unremarkable, where problems that seem intractable online somehow solve themselves in person, where we come away with ideas for an entire year and memories for a lifetime.

Syndicated 2013-08-30 21:53:10 from see shy jo

southern fried science fiction with plum sauce

Had an afternoon of steak and science fiction. Elysium is only so-so, but look what we found in a bookstore that was half religious materials and half SF, local books, and carefully hidden romance novels:

Star Wars, Star Trek and the 21st Century Christians

Best part was at the end, when I finally found one of the local asian markets Tomoko tells us about when she casually pulls out the good stuff at family gatherings. I will be back for whole ducks, fresh fish, squid, 50 lb bags of rice, tamarind paste, fresh ginger that has not sat on the shelf for 2 months because only I buy it, etc. Only an hour from home in the woods! Between the garlic sprouts, bean sprouts, enoki mushrooms, etc that I got for $10 today and this week's CSA surprise of 18 inch snake beans and smoked pork knuckles, I have the epic stir fry potential..

Spock and R2D2

Syndicated 2013-08-25 22:25:16 from see shy jo

idea: git push requests

This is an idea that Keith Packard told me. It's a brilliant way to reduce GitHub's growing lockin, but I don't know how to implement it. And I almost forgot about it, until I had another annoying "how do I send you a patch with this amazing git technology?" experience and woke up with my memory refreshed.

The idea is to allow anyone to git push to any anonymous git:// repository. But the objects pushed are not stored in a public part of the repository (which could be abused). Instead the receiving repository emails them off to the repository owner, in a git-am-able format.

So this is like a github pull request except it can be made on any git repository, and you don't have to go look up the obfuscated contact email address and jump through git-format-patch hoops to make it. You just commit changes to your local repository, and git push to wherever you cloned from in the first place. If the push succeeds, you know your patch is on its way for review.

Keith may have also wanted to store the objects in the repository in some way that a simple git command run there could apply them without the git-am bother on the receiving end. I forget. I think git-am would be good enough -- and including the actual diffs in the email would actually make this far superior to github pull request emails, which are maximally annoying by not doing so.

Hmm, I said I didn't know how to implement this, but I do know one way. Make the git-daemon run an arbitrary script when receiving a push request. A daemon.pushscript config setting could enable this.

The script could be something like this:

set -e
tmprepo="$(mktemp -d)"
# this shared clone is *really* fast even for huge repositories, and uses
# only a few 100 kb of disk space!
git clone --shared --bare "$GIT_DIR" "$tmprepo"
git-receive-pack "$tmprepo"
# XXX add email sending code here.
rm -rf "$tmprepo"

Of course, this functionality could be built into the git-daemon too. I suspect a script hook and an example script in contrib/ might be an easier patch to get accepted into git though.

That may be as far as I take this idea, at least for now..

Syndicated 2013-08-25 13:07:32 from see shy jo

experimental multiuser git-annex repository

On the last day of DebConf 13, RichiH and Ganneff and I set up a git-annex repository that all Debian developers have automatic commit access to, and everyone can clone and browse. See the announcement email.

This is an interesting repository for me for several reasons. Selfishly, I have always wanted an easy way to download lots of DebConf photos for offline viewing, and never seem to get around to downloading everything from gallery.debconf.org when I have bandwidth. I've also wanted an example repository that shows how git-annex can be used by a large group for collaboration. Finally, the way this repository is set up with an incoming queue is fairly unique.

With 430 files in the repository, totaling over 3.5 gigabytes (which doesn't include all the talk videos that are #included into it), and at least 18 people having cloned the repository so far, the debconf-share repository is well on its way to being a sort of large git-annex repository.

Just running git annex whereis is interesting; many of the files already have 8 copies. Some talk videos are more popular than others and you can see when they're downloaded too. But enough snooping.. ;)

So far people have uploaded mostly photos and talk slides. Other places exist to store those things in the DebConf infrastructure, but it's nice to have them all available in one tree. I particularly like today's addition of chrysn's files which include the raw photos and hugin files used to produce panoramas, and then pull those together into a postcard which has all its sources available.

In my corner of the debconf-share repository, I'm collecting together files regarding the possibly-historic dpkg-source-git-re-re-redesign process that would have otherwise been scattered around various places and probably not all published. This includes an hour long recording of the main design session (recorded with permissions) made by my laptop's mic, which, surprisingly, turned out to be pretty listenable. I will probably have more to say about this process later, once Ian announces dgit.

So, we're still seeing how usage develops. I hope that having this available during the next DebConf, and other Debian meetings, rather than only at the end, will further facilitate file sharing and storage. Especially if a fast clone is available right on the DebConf LAN. ;)

The technical details of how the repository is put together are:

  • There's a repository on git.debian.org, which piggy-backs on the collab-maint group, so most Debian people have commit access to it.
  • git-annex is used to upload files to that repository, as an incoming queue.
  • A git-annex-shell annex-content hook is run whenever someone uploads a file to there. It moves all annexed content over to annex.debconf.org for publication. This involves some ugly but safe stuff to do with publically readable restricted use ssh private keys. It was the hardest piece to get working, and is only necessary because we don't want to bloat git.debian.org with this stuff and it's not practical to give everyone logins to annex.debconf.org.
  • As an additional guard against accidental bloat, the git.debian.org repository will refuse to accept uploads when there is less than 5 gb free disk.
  • annex.debconf.org was set up following the git-annex public repository on a web site howto.

I've found at least 4 bugs in git-annex as a result of this repository, which is a rather unusual use case. And fixed 2 of them so far..

Syndicated 2013-08-21 20:20:18 from see shy jo

Debian at 20

RichiH used flint and steel to light the bonfire. We carefully fed it up from those sparks to a blaze. Put on the biggest logs we could find to make it last. Now I'm sitting on the hill above it watching folks gathered around. A poem is being read, in Hindi, then translated for us to English. Others have shared songs and poems in a dozen languages, both classics and their own. Out below the darkness of the lake. This is Debian at 20.

At the start of this DebConf, I gave a talk on "Debian Cosmology. In that (and a later "dh_busfactor" talk) I shared my hopes and my fears. I was conflicted about giving the this talk, worked on it for weeks, felt it might not work, or be depressing. I've had nothing but good comments about it.

20 years is ages in internet time and technical projects ossify over time. The last session I was in this afternoon was a presentation of a new tool, which I hope & feel has the potential to fundamentally change an important and suboptimal part of Debian. Then I walked outside to a rainbow over crystal clear Swiss alps on the horizon. How encouraging, and what a nice story that will be around some future campfire.

Syndicated 2013-08-16 22:16:42 from see shy jo

please build a haskell to perl compiler

The Fay compiler is a simple way to build fairly comprehensible javascript code from Haskell source.

It occurs to me that it should be rather easy to modify Fay to emit perl code rather than javascript. This would allow contributing things like plugins to various perl programs, without writing perl.

Of course, the same idea could probably be used to compile Haskell to other languages like python, but perl seems particularly well suited as a second Fay target, since javascript and it have quite similar syntax and similar support for features like closures which Fay relies on.

I do not have time to work on this idea myself. It would be a good project for a beginning Haskell programmer. You probably don't even need to fully understand monads to do it! Essentially, look at Fay output examples, translate them from javascript to perl, and then much of the code changes in Fay would probably be in simple string generation code.

I will forward any bitcoins sent to the address 149eBtWS6i8cwQdPQJJ8hAGpDuEqNidyTj to whoever makes this. If it doesn't happen in 1 year, any donations will be forwarded to the EFF instead.

Syndicated 2013-08-12 12:40:54 from see shy jo

529 older entries...

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!