bpgallery is my little bash script that uses the image magic tools to generate a simple static gallery, this release has some documentation fixes (tells you how to make themes!), fixes the annoying find warnings that were happening and fixes an escaping issue with URLs.

http://www.sommitrealweird.co.uk/development/bpgallery.html

Hmmm, MJ Ray asks about date and locales...

I think (though without grabbing the source I can't confirm) that the default date format of "date" is the legacy format that it's always been... if you want to get a shiny locale based date format from it use, +"%c". Here's the output from my laptop:

brettp@pitr:~$ locale
LANG=en_GB.UTF-8
LC_CTYPE="en_GB.UTF-8"
LC_NUMERIC="en_GB.UTF-8"
LC_TIME=en_GB.UTF-8
LC_COLLATE="en_GB.UTF-8"
LC_MONETARY="en_GB.UTF-8"
LC_MESSAGES="en_GB.UTF-8"
LC_PAPER="en_GB.UTF-8"
LC_NAME="en_GB.UTF-8"
LC_ADDRESS="en_GB.UTF-8"
LC_TELEPHONE="en_GB.UTF-8"
LC_MEASUREMENT="en_GB.UTF-8"
LC_IDENTIFICATION="en_GB.UTF-8"
LC_ALL=
brettp@pitr:~$ date
Wed Jan 18 08:34:52 GMT 2006
brettp@pitr:~$ date +"%c"
Wed 18 Jan 2006 08:34:55 GMT
brettp@pitr:~$

I wonder why date doesn't use "%c" by default... weird.

I've just finished uploading new django packages to my repository, the python-django packages are now 0.91, so if you're using 0.90 beware! There are backward incompatable changes, it's probably worth reading http://www.djangoproject.com/weblog/2006/jan/11/091/ and then follow the links for the 5 backwards incompatable changes and fix your apps to the new system.

I've also updated the python-django-magic-removal packages to the latest svn (or it was the latest svn when I built them ;).

Oh, and a symlink has been added to both packages to link in to the admin-media nicely (OK - so I got bored of editing the python each release to point to the /usr/share location, and this works nicely and simply, I hope. Thanks for the pointer James! :)

Oh, one other thing, there's a patch in the debian 0.91 version that means that the startproject part actually generates a settings.py with the "right" timezone and language. I haven't patched the magic removal branch with this (hey, if you're using that, I'm sure you can edit the settings.py and catch those yourself ;)

Play, have fun, report bugs at me! (or something)

We have a new django release, 0.91... I'll package it RSN... but here's some forewarning for those of you out there using the python-django packages... there's some backwards incompatible changes from 0.90 to 0.91, it's probably worth reading http://code.djangoproject.com/wiki/BackwardsIncompatibleChanges if you are using django.

The next real little boy^W^Wrelease will have the magic-removal branch merged in, so that'll be another set of backwards incompatible changes (if you want to stay ahead of the game though, as I said in my previous blog entry, there are some packages for that branch too ;)

Fun fun fun fun fun!

I've just packaged the django magic removal branch (well, kinda, it's more or less the same build system as the other django packages I made, so these aren't quite right, but they're good enough for the time being). They're in the same place as the other django debs, and compiled for sarge and sid... for those without the previous URL...

deb http://www.sommitrealweird.co.uk/debian stable django
deb-src http://www.sommitrealweird.co.uk/debian stable django

or

deb http://www.sommitrealweird.co.uk/debian unstable django
deb-src http://www.sommitrealweird.co.uk/debian unstable django

The package for the 0.90 release is called python-django, for the magic removal branch it's called (unsuprisingly) python-django-magic-removal. The magic-removal packages conflict with the other packages because they plonk their files in the same place, so if you're trying to 'upgrade' between the 2, you'll probably need to use some magic (or apt-get install python-django-magic-removal python-django-).

I'll try to update these reasonably often (like whenever I get a spare moment or 2 to build them).

That should cover it for now.

Why is it that people use PHP?! Why do people entrust data to this nasty language? Why run mediawiki, for example? MoinMoin is much nicer. PHP is a nasty language, it's non-thread-safe, it's got awful syntax, it's OO design is awful, and debugging it is a small nightmare.

I suggest to the world that python is a much nicer language.

People that claim things in blog posts because they think they are right, when even the SIMPLEST visit to the softwares website tells you otherwise... As an example to this... Sionide says that XMMS is a port of WinAmp, you can clearly see from the XMMS Website that this is not the case, the about page clearly states:

It was modeled after winamp from the Windows operating system. XMMS is not a port of Winamp but was written from scratch by Mikael and Peter Alm.

/me slaps Sionide about the face a bit. PLEASE DO AT LEAST A TINY BIT OF RESEARCH, DAMMIT.

sigh

Right - I've got some clean django packages ready, just waiting on my pbuilders to update then I'll upload them to my repository, it's the first official django release, and they state (quite clearly) on the site that there maybe backwards incompatible changes between now and 1.0, so I'm not sure wether I'll try to get this sponsored in to unstable or not at this point.

My debian repository for django is at:

deb http://www.sommitrealweird.co.uk/debian/ unstable django

or for sarge (yes, there should be some sarge packages soon!):

deb http://www.sommitrealweird.co.uk/debian/ stable django

At the moment these contain an older set of django packages built from an svn snapshot, I may make some new svn snapshots in the future, depending on time constraints and if anyone is interested in having them :)

Django has finally got a release! I'll be packaging it very shortly, once I sort out the few problems that I've got in the current packages that I've built. I might even finally get round to getting something useful working in it, I just haven't had time to rewrite my site yet to use django, I'm still using a (rather non-elegant) home grown set of scripts to apply my 'template' to my site, but I think that I can make it all a lot nicer using django, and much easier to update :)

Django is really quite nice, but it does need some tweaks to fit in to the FHS better, which I'll do against this nice shiny new tar ball release shortly.

I'm looking for a wiki -> html style, generic, parser... It's not that difficult to write one, but I wondered if you fine people out there might already know of one before I set about writing one... I could, in theory at least, use the parser from moinmoin, but that does seem very very tied in to moinmoin. It'd be nice to just use something like...

wikiparser = WikiParser(type="somewikistyle")
html = wikiparser.parse("somewikidocumentasastring").getHTML()

And have the WikiParser first generate an internal structure based on the markup (possibly, in effect, creating a dom tree), which is then returned at the .parse stage, then having different calls on that tree to, say, generate simple HTML, or LaTeX, or PDF etc.

Hope that makes sense to people that aren't me....

I've just packaged a newer version of python-django, if anyone is using these beware that the admin section has undergone a non backwards compatible change since the last package, details can be found from the django backwards incompatible changes page on the django wiki.

sources.list lines are:

deb http://www.sommitrealweird.co.uk/debian/ (sid|sarge) django
deb-src http://www.sommitrealweird.co.uk/debian/ (sid|sarge) django

and are available for i386 and amd64. The package still needs some work (various bits of config really shouldn't be where they are), but I expect to do that sometime before the release (we still haven't got an official django release).

I should be working my way through the xmms-scrobbler bugs at some point this weekend, I hope... the tag reading is still quite bad, and does still segfault on badly formatted tags which is what really needs fixing.

Anyways - back to it.

Joey Hess says in blog responses, window managers, tabs

It wasn't that long ago that window shading was a cutting edge new feature, so it might have made sense to implement it in an app back then, but it's in any self-respecting window manager now (except, arguably, ion ;-), so it's time to let go and let the window manager take care of it. I think the same will happen with tabs. says in

Ion3 does have window shading! Fire up a WFloatWS workspace and watch it in action!

Anyways - to respond to alllll the comments on web browsers that'd been hitting planet recently, here's my current position: all web browsers suck, some suck marginally less than others. Basically, I use firefox on the basis that it, currently, is sucking the least for me, is reasonably fast and reasonably light weight, and does come somewhere near implementing the standards. I have used kazahakase, infact, I did almost decide to use it as my default web browser, but then something put me off, maybe there was some odd key combo that I didn't like, or maybe it was something to do with the tabs... I just remember that there was something that I just didn't get on with. I get fairly bored with most apps fairly quickly, basically, if it can't be done on the command line, or automated in some way, what's the point? Unfortunately, that kinda doesn't work so well for web browsing, although, w3m still gets a fair amount of use on my machine, mainly because sometimes I just want the content, I don't need the stupid roll overs, the inane graphics, some web designers idea of what's a 'good ui'... often I just want a simple navigatable site, with clear and easy to follow sections, and easily accessable text, not this damn flash stuff, not this horrible java applet foo, pure, plain, simple, markup. Headings, subheadings, paragraphs, all marked up as they should be... I want the web to come back to being a place for information, dammit. Maybe I'm just a purist though.

Anyways - just my 2p worth.

Friday before last (23 Sept, 2005) I finally got assigned an AM :) I really need to get back my answers for the first part of P+P RSN, just haven't really had time, still settling in after the move, and we've not sorted the wireless network out yet... Should get it done today or tommorow though, and then it's just a case of sending it off and waiting for the next installment!

I've written an evil bash script that will (just about) resolve dependencies of an rpm based distributions files, and install them in to a chroot. It appears to work on my debian system quite well, with just the straight debian version of "rpm" from unstable, and some sed, grep and temporary files.

If you're interested in taking a look, then it's available at http://www.sommitrealweird.co.uk/development/rpmbased-dist-chroot.html .

I've added in some support for setting important and critical levels on a per maildir level in my statusd_maildir.lua script. Means that if you have some less important or more important maildirs you can make them go pretty colours quicker.

Seems to be working reliably for me... now if I could work out how to make the statusbar bigger (like, 2 lines high rather than one, and with the mailboxes all on the bottom line and the top line for date, time, load, cpufreq, etc etc) it'd be very handy... anyone got any hints? I glanced at the statusbar code but I haven't yet figured it out, and it doesn't appear to automatically wrap if it over fills, which is a PITA.

I've switched to using Ion3 as my window manager, it's a nice idea, and I'm getting kinda used to using it, doesn't half change perspective on using graphical applications though. Ion3 has a rather nice single line statusbar by default that will show the time, load and mailcount for your MAIL environment, assuming that you're using mbox mailboxes... Now, I don't use mbox for mail anymore, I offlineimap my mail in to ~/Maildir/INBOX ~/Maildir/project-list etc etc, so, first task... lets see if there's a Maildir mail monitor... looking around provided no useful results, so, I wrote one. First attempt at diving in to lua (though, this code has now been looked over by rjek so, it should at least work for more people than just me), the code is available from my ion3 script repository, it's the only script there at the moment, but I'm sure that other things will bother me sometime and I'll write some more.

All comments gratefully received :)

First, a big congratulations to all that were involved in the debian release process, you've done a fantastic job. It's a shame that the CD images weren't perfect first time round, but it's fantastic that it was picked up so quickly and publicised to avoid people going manic on creating CDs. Thank you all for your fine work, and remind me if I meet you guys to buy you a beer or two :)

Now on to other stuff... I know that xmms-scrobbler didn't make it in to Sarge, I haven't yet had time to fix the important bugs that are filed against it, if you're one of the bug submitters, and I haven't responded to you yet, I'm very sorry, it's been a manic couple of months at work, and it's not going to slow down for the next month or so. I need to go through a fair chunk of the code, especially the tag reading code, to stop it from segfaulting, and I think I've spotted where the issue is with the submissions of queued tracks, I'm not impressed, currently, by the queueing code, an assumption that I'd made on how it works appears to be untrue, so I'll try to look at that in the next couple of weeks if I get some breathing space and don't waste it in relaxing.

And the other thing... I'm starting to think about working on another onak backend, basically a caching backend so that you query a local server and if it doesn't know about a key, or hasn't got that key recently (in a configurable amount of time), it'll go and grab it again. I've also noticed that sometimes the keyservers out there aren't quite in sync with each other, so the other idea for the backend is to get the results from more than one upstream keyserver, merge them in the server, and if the key we end up with is different to the key got from a particular server, we send back up the key we've now got. Can anyone see anything wrong with this approach? If not, I'll start coding that some time this month (hopefully).

I think that's all for now, I'm currently fuelled by a bottle of cheap merlot, so this post may make no sense, but I'm fairly relaxed ;)

Cheers,

Brett.

It appears that the tg3 driver has been entirely removed from the debian stock 2.6.11 kernel images, this would be fine, except that that means the easiest way to get a working driver in debian, now, is to use the bcm5700 non-free driver. ARGH. Gimme back my tg3 driver, dammit.

In other news, decided to play with sshfs, seems quite cool, got the fuse module loaded and mounting remote filesystems over ssh seems to work quite nicely :)

May compile a custom 2.6.11 later to get back the nice shiny tg3 module, which is much nicer than the non-free driver I've currently got loaded. sigh.

Right, having made a fair few changes in the last couple of days, I'm quite happy that the new version of bpgallery addresses the bugs that I found in 0.9.3. It's available from http://www.sommitrealweird.co.uk/development/bpgallery.html which now includes a link to my gallerys that I've generated using it.

The next thing to work on is a better set of documentation for it, especially for the themes. Basically a theme is defined as a set of bash functions that print the various parts of the HTML file or stylesheet, and can include some variables. It's a very simple way of doing it, but it works quite well (or has done so far).

My small gallery script has just gone through another release, the new version supports rudimentary comments taken from the file comments.txt in the photos directory, themeing support is almost complete, next release will have the destructions for how to write those, I hope.

If you're interested, it's available from http://www.sommitrealweird.co.uk/development/bpgallery.html .