I’ve just installed Eran Sandler’s OpenID Delegation Plugin [1]. This means that I can now use my blog URL for OpenID authentication. I’ve also included the plugin in my Wordpress repository (which among other things has the latest version of Wordpress). One thing that I consider to be a bug in Eran’s plugin is the fact that it only adds the OpenID links to the main URL. This means that for example if I write a blog comment and want to refer to one of my own blog posts on the same topic (which is reasonably common - after more than two years of blogging and almost 700 posts I’ve probably written a post that is related to every topic I might want to comment on) then I can’t put the comment in the URL field. The problem here is that URLs in the body of a blog comment generally increase the spam-score (I use this term loosely to refer to a variety of anti-spam measures - I am not aware of anything like SpamAssassin being used on blog comments), and not having OpenID registration also does the same. So it seems that with the current functionality of Eran’s plugin I will potentially suffer in some way any time I want to enter a blog comment that refers to a particular post I wrote. deb http://www.coker.com.au etch wordpress My Wordpress Debian repository is currently available with the above APT repository. While it specifies etch it works with Lenny too (my blog currently runs on Lenny). I will eventually change it to use lenny in the name. For the OpenID server I am currently using the OpenID service provided by Yubico as part of the support for their Yubikey authentication token [2] (of which I will write more at a later date). I think that running their own OpenID server was a great idea, it doesn’t cost much to run such a service and it gives customers an immediate way of using their key. I expect that there are more than a few people who would be prepared to buy a Yubikey for the sole purpose of OpenID authentication and signing in to a blog server (which can also be via OpenID if you want to do it that way). I plan to use my Yubikey for logging in to my blog, but I still have to figure out the best way of doing it. One thing that has been discussed periodically over the years has been the topic of using smart-cards (or some similar devices) for accessing Debian servers and securing access to GPG keys used for Debian work by developers who are traveling. Based on recent events I would hazard a guess that such discussions are happening within the Fedora project and within Red Hat right now (if I worked for Red Hat I would be advocating such things). It seems that when such an idea is adopted a logical extension is to support services that users want such as OpenID at the same time, if nothing else it will make people more prone to use such devices. Disclaimer: Yubico gave me a free Yubikey for the purpose of review. Update: The OpenIDEnabled.com tool to test OpenID is useful when implementing such things [3].

• [1] http://eran.sandler.co.il/downloads/openid-delegate-wp-plugin/


• [2] http://www.yubico.com/


• [3] http://www.openidenabled.com/resources/openid-test/checkup

Share This

...and bug #500000 will probably be there. #499938 as of now.

As I wrote in blog item 29 there are many ways to break your debian/rules file. As I grew of seeing those and many more, I decided to write a lintian test for this. Getting that finished will still need several days, as the general Makefile syntax is quite intresting in detail, and lintian is written in perl thus so have to be tests. It's quite intresting that the different cases when variables are resolved and when not seem to quite firmly force an specific way to parse it. (And relearning perl when I so successfully unlearned all parts of that language in the past make it not much faster). Anyway, the reason I'm blogging is to give you already the results of one particular test a preliminary version gave when running over the lintian lab: It's checking for targets with -stamp in them that are phony, as that makes no sense. It will either cause configure or make run multiple times via build, wasting buildd cycles or even make the build more unstable, or just indicates needlessly complex Makefiles (having an install target that invokes an install-stamp target that does not actually produce a stamp file just makes the Makefile longer without doing anything at all but confusing readers). You can find the preliminary results for that test at http://people.debian.org/~brlink/debian-rules-phony-stamp-file.log. I looked at some randomly choosen results and did not find a false positive. As that list was produced by the last runable version which did not yet look at variables, I guess the list will only increase.

Early details:

• Coming out in October.
• UK in early November, Europe by first quarter 2009.
• Simlocked to T-Mobile.
• Source code! When the phone comes out. Hopefully someone will use it to unlock the thing.
• 179$ - not bad.
• MP3's from Amazon.
• Market app built in.
• Neat use of Google Maps street view.

I'm sold, I want one. It might not be quite as flashy as the iPhone, but I want something open.

I finally managed to process all my mails and it's not time to push Gammu towards stable release. If everything goes without problems, the just born 1.20.93 will be followed by 1.21.0. Version 1.20.93 fixes several crashes with parsing strange data from phones and changes a bit initialization of FBUS protocols. If you are using this connection type, please test this new code whether it behaves better or worse than older version. Full list of changes:

• Fix crash when decoding EMS pictures (bug #549).
• Motorola phones sometimes reply in UCS2 instead of HEX (bug #712).
• Use native functions sleep/usleep if available.
• Improve FBUS initialization sequence.
• Fixed reading for ringtones from Nokia 5510 (bug #529).
• Do not crash if ringtone name is too long (bug #529).
• Fix possible crash while reading of messages using AT.
• Increase timeout when writing SMS message (bug #596).
• Cleaned up issues with reading from Bluez (bug #670).

You can download from usual place: http://cihar.com/gammu/, Debian users will find packages in experimental soon.

Ok, my apologies, the Latin is incorrect, but the idea is this: I have run into an important limitation of Google's domain registration system. Buyer beware. Lately, I have been using Google Apps to register domains. At $10 a year for new domains, which come with all the nifty Google applications, email and so on, it's a really good deal. However, there appears to be a potentially crucial problem: you can't sell or transfer the domains, as far as I can tell. I would love to hear that I am wrong on this, but the person helping me through Google's support channel first told me to "enter the new credit card details in the Google Checkout account associated with the domain". Uh, sorry, but I want to transfer the whole thing, lock, stock and barrel. After another round of email, I got this:

To assign a different Google Account to the subscription you'll need to modify your billing information by following the steps listed below:

• Enable automatic renewals for your account.
• When you receive email notification of the impending charge, visit the link to the 'Ordering page.' - Authorize a new purchase for your domain registration renewal. This will replace the old subscription and charge your new billing information on the subscription expiration date. Automatic renewals will also be enabled going forward.

If you don't have automatic renewals enabled, your email notification won't include an 'Ordering page' link to change the Google Checkout account and purchase or renew Google Apps. You must first enable auto-renew to be sent this link.

I don't want to have to wait for the email notification, though! The domain won't be automatically renewed until sometime next spring. Hopefully this is either an oversight on my part or something Google will fix soonish, as buying a domain name that you can't sell or otherwise give to someone else is of very limited use for some things. No, I haven't gone into business as a domain name speculator/squatter, the domain in question is InnsbruckExpats.com, a site I registered for a friend a bit more than a year ago.

I don’t have the expertise to intelligently explain the entire global financial meltdown myself, but here are a few resources that merit wide dissemination, especially if you are a podcast-listener:

• The Planet Money Podcast. NPR’s Adam Davidson hosted one of the most memorable episodes of This American Life on the Giant Pool of Money (complete PDF transcript). He has springboarded that show into a frequent short podcast in these times of peril. He finds a near-perfect balance between accessibility and complexity for a non-specialist but educated audience. It’s also entertaining. Of all major media outfits, NPR is miles ahead on the podcast front.
• Paul Krugman’s blog. Admittedly on the partisan side (”Conscience of a Liberal”), Krugman’s analysis is deep both on politics and economics. Steve drew my attention to this excellent illustration of the flaws with the current approach to bailout:

Tomorrow, a long bus ride to the capital of the Czech Republic will set off the last trip together with my high school classmates before the final exams in spring. We are to leave half an hour past 6am local time; I m surprised to find that my alarm watch can be configured to get on my nerves at five o clock in the morning. Until Friday, instead of connectivity I will have medieval buildings and woozy-for-some-reason teenagers all around me, so please don t expect me to reply to mails before Saturday. I ve been really looking forward to these holidays for weeks (hint: the school year started a fortnight ago). So glad they re finally here! PS: I m going to miss the party, so allow me to pre-congratulate 500000-submitter and the prospective winner of the contest. Cheers!

Just stumbled over this meme at Adrian (the meme seems to be started by madduck involuntarily), and since I’m fascinated by how people choose hostnames since my early years at university, I can’t resist to add my two cents to this meme. To be exact, I have two schemes, one for servers out there somewhere (Hetzner, xencon, etc.) and they’re all wordplays on their domain name noone.org, e.g. symlink.to.noone.org (short name “sym” :-), gateway.to.noone.org (usually an alias for one of the machines below), virtually.noone.org (always a virtual machine, initially UML, soon a Xen DomU), etc. So nothing for a quiz here. My other scheme is for all my machines at home and my mobile machines. I’ll start this list with the not so obvious hostnames, so the earlier you guess the scheme, the better you are (or the better you know me ;-). One more hint in advance: “(*)” means this attribute or fact made me choose the name for the machine and therefore can be used as hint for the scheme. :-)

azam

My first PC at all, a 386 with 25 MHz and MS-DOS. (Got named retroactively(*). Hadn’t hostnames at that time.)

ak (pronounced as letters)

Got it from my brother after he didn’t need it anymore. It initially was identical to azam, but once was upgraded to a 486. Still have the 386 board, though.

azka

My first self-bought computer, a pure SCSI system with a AMD K5-PR133 and 32 MB RAM. Initially had SuSE 4.4 and Windows 95 on. Still my last machine which had a Windows installed! :-)

m35

Same case and same speed as azka. Used it for experimenting(*) with Sid years ago.

azu

Initially also an AMD K5-PR133, later replaced by a Pentium 90 and used as DSL router.

azl

An HP Vectra 386/25N book size mini desktop I saved from the scrapyard at Y_Plentyn before his (first) move to Munich. The cutest(*) 386 I ever saw.

ayce

A 386 with 387 co-processor(*) and solded 8 MB of RAM.

ayca

A 1992 Toshiba T6400C 486 laptop bought at VCFe 5.0.

bijou

My 1996 ThinkPad 760ED, which is still working and running Debian GNU/Linux 5.0 Lenny (I started with Debian 3.0 Woody on it and always dist-upgraded it! :-)

gsa (pronounced as letters)

My long-time desktop after azka. A Pentium II with 400 MHz and 578 MB of RAM at the end. Bought used at LinuxTag 2003, it worked until end of last year when it started to suddenly switch off more and more often and now refuses to boot at all. Hasn’t been replaced yet though. I mostly use my laptops at home since then.

gsx (pronounced as letters)

An AMD K6 with 500 MHz I got from maol and which was used as Symlink test server more than once. (It was the machine initially named symlink.to.noone.org because of that.)

hy

My 32 bit Sparc, a Hamilton Hamstation.

hz (pronounced as letters)

My 64 bit Sparc, an UltraSparc 5.

tub

An HP Apollo 9000 Series 400, model 400t from 1990.

tpv (pronounced as letters, too ;-)

My Zaurus SL-5500G.

tryane

A Unisys Acquanta CP mini desktop with a passively cooled(*) 200 MHz Pemtium MMX. Used as DSL router for while, but the power supply fan was too noisy.

lna (pronounced as letters)

A 233 MHz Alpha

loadrunner

An IBM ThinkPad A31 running Sid. I use it as beside terminal.

pony

A Compaq LTE5100 laptop with a Pentium 90 running Sid.

dagonet

A Sony Vaio laptop which ran Debian GNU/kFreeBSD until it broke.

Those who know me quite good should already have guessed the scheme, even if they can’t assign all the names. For all others, here’s one name which doesn’t exactly fit into the scheme, but still is related in someway, but you need to knowledge of the theme’s subject to know the relation:

colani

A big tower from the early 90s designed by Colani.

Ok, and now the more obvious hostnames:

rosalie

A very compact Toshiba T1000LE 8086 laptop running ELKS and FreeDOS.

amisuper

Also an old Symlink test server from maol. He named it “dual”. 2x(*) Pentium I with 166 MHz. Unfortunately doesn’t boot anymore.

visa

An IBM NetVista workstation running Debian GNU/kFreeBSD. My current IRC host.

nemo

My ASUS EeePC running Debian 5.0 Lenny.

pluriel

My current WLAN router running FreeWRT.

c1

My MicroClient JrSX, an embedded 486SX compatible machine with 300 Mhz for VESA mountings.

c2

My MicroClient Jr, an embedded Pentium MMX compatible machine with 200 Mhz for VESA mountings.

c-crosser

My Lenovo ThinkPad T61 running Debian 5.0 Lenny.

c-cactus and c-metisse

The KVM based virtual(*) machines on c-crosser running Sid and Debian GNU/kFreeBSD.

jumper

My NAS(*) at home, currently a TheCus N4100. Soon to be replaced by some Mini-ITX box.

Any one who hasn’t guessed the scheme yet? For those understanding German it’s explained at the end of my old hardware page. For all others I suggest either to look at the domain name in my e-mail address (no, it’s usually not noone.org). Still not clear? Well, feel free to ask me for all the gory details or mark the following white box to see the scheme as well as the explanations for nearly all hostnames hidden in there:

All the machines are named after Citroëns. Old machines after old Citroëns, current hardware after current Citroën models or prototypes. Those names starting with “A” are 2CV derivatives since the 2CV was Citroëns “A” model. “AZ” was the 2CV, AZU and AK were 2CV vans and everything starting with AY (e.g. AYA, AYA2, AYB – but those don’t sound that nice ;-) is Dyane based, but I currently only use Méhara names (AYCA is the normal Méhari, AYCE the 4x4 version). Interestingly not everything starting with AYC is a Méhari: AYCD was the Acadiane, the Dyane van. HY and HZ are variants of Citroëns “H van” (HX, HW and H1600 as well, but they don’t sound that nice), TUB was the pre-WWII “H van” prototype and later the nickname of the “H van” in France. TPV was the name of the pre-WWII 2CV prototype and an abbreviation for Toute Petite Voiture (French for “Very Small Car”), hence the Zaurus, my smallest Linux box, got that name. Rosalie was the nickname of a rear-wheel drive pre-WWII Citroën. M35 was a Wankel engine prototype of the Ami 8 and the Ami Super was the 4 cylinder version of the Ami 8. Bijou was a 2CV based coupé build by Citroën UK in the late 50s and early 60s. Visa and LNA were 2CV predecessors which were available with 2CV engines, but were stopped before the 2CV. GSA and GSX are GS late derivatives. C1, C2, (C3) Pluriel, C-Crosser, Jumper and Nemo are current Citroën models and C-Cactus and C-Métisse are recent Citroën prototypes and show cars. The 2CV Dagonet was an aerodynamically optimised 2CVs by Jean Dagonet in the 50s. The Tryane is an aerodynamic and fuel efficient, three wheeled car by Friend Wood based on the 2CV and with a body of wood. And Colani once dressed a 2CV so that it broke several efficiency world records. The Namco Pony was a 2CV based light utility truck (similar to the Méhari, but with steel body) built in Greece under license in many variants. And Loadrunner is the name of some CX six-wheeler conversions.

Some links about the naming items:

• Tryane II
• An original Loadrunner and a just recently built Loadrunner. I even saw the base of exactly that one in RL shortly before it was converted into a Loadrunner.
• Luigi Colani
• Dagonet
• Namco Pony
• C1, C2, C-Crosser, C-Cactus, C-Métisse, Pluriel, Nemo, Visa, LNA, GSA, Ami Super, Rosalie
• AZAM, AZL, AZKA, AZU, AK, AYCD, Bijou, TPV
• HY, HZ, TUB.

Hope you had fun. I had. ;-)

Now playing: Willi Astor — Gwand Anham Ära

I went to this event a few weeks ago. The immediate outcome is the call for expressions of interest in RISE-SW’s projects. The deadline is next Monday (29th September) at 12 noon, so get emailing if you’re interested in them. After that, shortlisted EoIs will get two weeks to write a full bid. I’ve asked for a non-Microsoft copy to be posted. Microsoft is a social problem, not a social enterprise. The consultation event was a pretty straightforward introduction and discussion in small groups, followed by feedback to the whole group, with lunch to finish. The host was Gareth Hart of Perfect Moment (yet another non-SE hired by RISE instead of SE providers?). First, the introduction covered the CapacityBuilders Social Enterprise Programme, the context of the programme and RISE’s suggested themes for support: accessibility of SE support, better opportunity for the Voluntary and Community Sectors to be more enterprising, improving SE quality standards and organisations, making SE infrastructure sustainable, and developing more peer-to-peer SE support and mentoring. In the discussion that followed, I think the standards and sustainability themes were largely kicked into touch as unachievable with the available budget, while we felt peer-to-peer support was better as part of the more general accessibility and opportunities themes. My personal pet points were that if the Social Enterprise Mark is funded, it should benefit small SEs rather than RISE, and that if another database or directory is funded, it should be Open in licence and maintenance, like ODP and unlike previous directories which have wasted government money. I’ll be interested to see how that’s reflected in the Call for Expressions when I get to reading it this week.

This is the highest bug number as of now. We did not turn #500000 last week-end and will probably do it tomorrow (23rd) or, more likely, on 24th. The winner of the contest is now very certainly Ren Mayorga who did bet Sept 23rd (the next best is October 1st: too far away). So, next suspense now: who and when? :-)

I did it! :) I defended my thesis and passed master finals from theoretical physics at Charles University in Prague couple hours ago.

After almost dropping out of my school exactly a year ago for not having enough credits to go to the next year, I gave myself an obligation to finish my school on time. I worked very hard the last year, I had to do 8 exams, some of them very hard, requiring more than a week of thorough learning and 9 seminars, requiring a lot of work too and also a master thesis, for which I had to had working finite element solvers and together with SymPy it took all my time and energy. I even had to cancel my trip to Austin and Caltech for the SciPy conference. But I finished my school after all, I am very happy about it.

Last year, two of my friends bet $100 between themselves that I will not finish on time. Jarda, who believed in me is now at Princeton doing his Ph.D. Matou , who didn't believe in me, will now pay $100 to Jarda. I think that life is fair.:)

Now I'll be visiting pubs quite often and then I'll fix some long standing issues in SymPy, hopefully finish my Debian task & skills (to finally become a Developer couple months after that) and finally do useful stuff for my research with a fresh head now.

When this post goes live I will have had OpenID running on my blog for 24 hours. My first attempt to do so was not successful. The theme I use does not support the option of displaying that the website URL is checked for OpenID (a feature of the Wordpress OpenID Plugin [1]. Someone who’s comments I desire complained that the unexpected prompt for an OpenID password when they entered a comment caused them to abort the submission process and I therefore lost their comment - so I immediately disabled the plugin. I think that person was being a little unreasonable, it seems to me that when you add OpenID to your web site you should be expecting it to be checked for such things! But in spite that I felt obliged to do what was necessary to avoid confusion. Yesterday I reenabled OpenID, my first effort was to hack my theme to have a separate entry field for the OpenID URL which appears to work (this is documented in the OpenID plugin). The next step was to enable the URL to be used for OpenID and hack the theme to make it note how it’s being used. This appears to work well and should avoid the objections. One factor that gave me an incentive to work on this is this post about Taking a Stand to Promote OpenID [2]. That’s the type of person who I would like to have commenting on my blog. I’m also working on my own OpenID authentication solution and I may consider taking the same stand.

• [1] http://wordpress.org/extend/plugins/openid


• [2] http://www.anotherblogger.com/2008/04/24/taking-a-stand-openid/

Share This

After a short discussion time, my proposals have been ACK'ed and we will have 63 languages supported, including English, in Debian Installer for Lenny. Etch had 58 supported languages. The final winners are (alphabetical order of ISO code): Amharic, Arabic, Belarusian, Bulgarian, Bengali, Bosnian, Catalan, Czech, Welsh, Danish, German, Dzongkha, Greek, English, Esperanto, Spanish, Basque, Finnish, French, Irish, Galician, Gujarati, Hebrew, Hindi, Croatian, Hungarian, Indonesian, Italian, Japanese, Georgian, Khmer, Korean, Kurdish, Lithuanian, Latvian, Macedonian, Malayalam, Marathi, Norwegian Bokm l, Nepali, Dutch, Norwegian Nynorsk, Punjabi, Polish, Portuguese, Brazilian Portuguese, Romanian, Russian, Northern Sami, Slovak, Slovenian, Albabian, Serbian, Swedish, Tamil, Thai, Tagalog, Turkish, Ukrainian, Vietnamese, Wolof, Simplified Chinese, Traditional Chinese Newcomers for Lenny are: Amharic, Welsh (back), Irish, Marathi, Northern Sami, Serbian We lost Estonian which was in Etch. Those that missed the deadline are of course all other languages of the world. We will put focus on languages where an effort started at some moment but could not be complete enough: Afrikaans, Estonian, Persian, Armenian, Icelandic, Kazakh, Kannada, Kashmiri, Lao, Malagasy, Malay, Sanskrit, Secwepemctsin, Telugu, Urdu, Xhosa Many thanks to all translators for this final effort. Thanks also to all people who urgently popped up last week to complete the translations for languages that were "orphaned". I hope this will bring us more translators...:-) I keep special thanks to Frans Pop here. He is, along with me, the author of the code that allows us to split D-I translations in "sublevels", allowing translators to focus on the most "important" messages. He also implemented prior warnings when users pick up a language where some less important screens aren't translated. This also allows us to more easily keep partly complete translations, or activate languages earlier. Without this, 11 languages should have been dropped.

For the impatient reader: New lintian in experimental, please test and give feedback. You will miss most changes though unless you read the rest of the post (Hint, Hint ;)) During the past week I've uploaded new lintian versions to experimental which we designated to be release candidates for 2.0.0. Code-wise the changes are not that much more intrusive than for many of our past releases, but they change the way lintian classifies tags in a fundamental way, thanks due to the hard work of Jord Polo in his Google Summer of Code project (mentored by Marc Brockschmidt). Lintian Tag Classification, old and new Previously lintian classified tags only in one dimension, in the categories "Info", "Warning", and "Error". While this worked reasonably well, the difference between the categories was not very well defined. The general idea was that everything violating a "must" in Debian Policy or endangering the building or usage of the package should be an "Error", i.e. something very similar to the definition of RC bugs (except that not all "must"s in Policy are deemed worthy of filing RC bugs). Some errors were downgraded to "Warning" or even "Info" though on the basis that their detection was too prone to false positives. Due to this it was a long existing desire to split the classification of tags into two dimensions, one for the impact/importance of the tag, and one for the certainty of its correct detection. This should make it easier for people to interpret and/or filter the output. At various points in the last few years people began to work on this but quickly gave up, usually overwhelmed by the sheer number of tags (728 in 2.0.0~rc2) to classify anew and to make sure that the old and new categorisation could exist side-by-side (because breaking backwards compatibility was not really feasible). Finally this year Jord Polo decided to tackle this task as a Google Summer of Code project, with great success. Tags are now classified in two dimensions "Severity" (with the possible values wishlist, minor, normal, important, serious, which are intentionally very close to the available severities in the Debian bug tracking system), and "Certainty" (possible values: wild-guess, possible, certain). A third classification by "Source" (i.e. Policy, Developers Reference, ...) is planned but not yet fully implemented. For backwards compatibility there is a mapping of these new classification to the old ones (which lead to a few reclassifications of tags). The default output of lintian is unchanged. The new output formats that support the classification are still experimental (see below). How to use it You can specify exactly which levels of Severity and Certainty you want to have displayed with the new --display-level (-L) option. Please see the manual page for the details, but to give you an idea, the default behaviour (i.e. "show warnings and errors" in the "old" vocabulary) is equivalent to specifying

-L ">=important" -L "+>=normal/possible" -L +minor/certain

And to get a report with only severe tags we're very certain of, you could use

-L ">=important/certain"

which will only display tags that have severity "important" or "serious" and a certainty of certain. There is also the (intentionally undocumented) option --exp-output which allows you to play with some experiments we're doing with the output format. --exp-output format=letterqualifier will give you an output very similar to the "classic" one, but with additional information about severity and certainty. --exp-output format=colons gives you a colon-separated format which includes all the possible information lintian currently has available during tag output and which should be easily machine-consumable. Note that these formats are experimental and might be changed at any point without notice. If you're interested in using alternative formats for lintian output, please join the mailing list and talk to us about it. Etc. Other changes include the usual share of bug fixes and of course: New tags

• description-contains-dh-make-perl-template
• doc-base-uses-applications-section (actually a split of doc-base-unknown-section in two tags)
• embedded-pear-module
• embedded-php-library
• improbable-bug-number-in-closes
• maintainer-also-in-uploaders
• maintainer-script-ignores-errors
• manpage-has-errors-from-pod2man
• ored-build-depends-on-obsolete-package (actually a split of build-depends-on-obsolete-package in two tags)
• package-superseded-by-perl
• versioned-dependency-satisfied-by-perl
• windows-devel-file-in-package

Credits This lintian release is brought to you by (sorted by number of changesets):

• Jord Polo
• Frank Lichtenheld
• Adam D. Barratt
• Raphael Geissert
• Russ Allbery
• Niko Tyni
• Marc 'HE' Brockschmidt

A Linux Users Group like most volunteer organisations will often have a small portion of the membership making most of the contributions. I believe that every LUG has many people who would like to contribute but don’t know how, here are some suggestions for what you can do. Firstly offer talks. Many people seem to believe that giving a talk for a LUG requires expert knowledge. While it is desired to get any experts in the area to share their knowledge, it is definitely not a requirement that you be an expert to give a talk. The only requirement is that you know more than the audience - and a small amount of research can achieve that goal. One popular talk that is often given is “what’s new in Linux”. This is not a talk that requires deep knowledge, it does require spending some time reading the news (which lots of people do for fun anyway). So if you spend an average of 30 minutes a day every week day reading about new developments in Linux and other new technology, you could spend another minute a day (20 minutes a month) making notes and the result would be a 10 to 15 minute talk that would be well received. A talk about what’s new is one way that a novice can give a presentation that will get the attention of all the experts (who know their own area well but often don’t have time to see the big picture). There are many aspects of Linux that are subtle, tricky, and widely misunderstood. Often mastering them is a matter that is more related to spending time testing than anything else. An example of this is the chmod command (and all the Unix permissions that are associated with it). I believe that the majority of Linux users don’t understand all the subtleties of Unix permissions (I have even seen an employee of a Linux vendor make an error in this regard while running a formal training session). A newbie who spent a few hours trying the various combinations of chmod etc and spoke about the results could give a talk that would teach something to almost everyone in the audience. I believe that there are many other potential talk topics of this nature. One thing that is often overlooked when considering how to contribute to LUGs is the possibility of sharing hardware. We all have all the software we need for free but hardware still costs money. If you have some hardware that hasn’t been used for a year then consider whether you will ever use it again, if it’s not likely to be used then offer it to your LUG (either via a mailing list or by just bringing it to a meeting). Also if you see some hardware that is about to be discarded and you think that someone in your LUG will like it then grab it! In a typical year I give away a couple of car-loads of second-hand hardware, most of it was about to be thrown out by a client so I grab it for my local LUG. Taking such hardware reduces disposal costs for my clients, prevents computer gear from poisoning landfill (you’re not supposed to put it in the garbage but most people do), and helps random people who need hardware. One common use for the hardware I give away is for children. Most people are hesitant to buy hardware specifically for children as it only takes one incident of playing with the switch labeled 240V/110V (or something of a similar nature) to destroy it. Free hardware allows children to get more access to computers at an early age. Finally one way to contribute is by joining the committee. Many people find it difficult to attend meetings, so attending a regular meeting and a committee meeting every month is difficult. So if you have no problems in attending meetings then please consider contributing in this way.

Share This

The last two days saw some updates to the queue daemon. (The queue daemon is that part of our archive software that processes the anonymous ftp uploads and, if they pass basic checks, moves them into the place our archive wants new uploads to be in.) The first big patch to it was written by FTP Assistant Thomas Viehmann, implementing the DELAYED (DEFERRED) Queue. Now, the second one was by me and not even half as much work. As people did like one feature of the unofficial DELAYED upload queue that Tollef did run in the past, namely the possibility to upload using ssh, we now officially provide such a way. While it won’t ever support uploads to the DEFERRED queue, I don’t think thats neccessary. DEFERRED is, as far as I know, used seldomly enough to not warrant the amount of work it would need to support it. As the ssh upload queue daemon is basically nothing more than a simple “ssh to ftp” wrapper (it just takes .changes and associated files and uploads them to the ftp place), people will get two mails for uploads done that way. One saying “Uploaded to ftp.upload.debian.org”, the next will be “Uploaded to localhost”. One equally important thing was changed together with the above two things: We have new names for the upload locations. People shouldn’t use direct hostnames anymore. Use the CNAMEs we provide, ssh.upload.debian.org or ftp.upload.debian.org. Comments: 0

Every now and again the topic of SELinux arises locally. I still believe it is:

• Theoretically interesting.
• Not ready for the prime time.
• Not something I ever consider using.

I kept quiet when the Should SELinux be standard topic was recently raised. But I personally believe the answer should be emphatically "No". Anyway, change of subject. The recent "What do you look like right now" meme. I looked like this a couple of days ago. Today I have no hair. In other news my mail scanning service has now reached a new record. Over the last 30 days it has rejected/archived ovr three million SPAM messages. Three million messages over a month averages out at about 100,000 messages a day. Sustained. Nice. Finally I really owe Runa a new letter. I will write it today. ObQuote: Bill & Ted's Excellent Adventure

(including English!) The string freeze of Debian Installer officially ended at 23:59 yesterday (Sept. 20th). Indeed, this was extended a bit to today, with agreement by Otavio Salvador who I thank for this. That allowed Zak to "save" Tagalog and also the Welsh and Latvian translators to polish their work. We now have to decide about some of these languages: those that failed to meet the release criteria but were formerly activated in D-I. There are four such languages: Amharic, Welsh, Estonian and Northern Sami. Please find below the mail I just sent to debian-i18n and debian-boot. I promised that this discussion would happen in public. It will (but it will be short as we can't delay the release of the installer for ages....and I think that my proposals are reasonable!)

First of all, the numbers as of Sunday Sept. 21st 09:32 UTC (date of
the last commit with an l10n update):
Languages meeting the release criteria: 59
------------------------------------------
Already activated and complete for level 1: 51
 Arabic, Belarusian, Bulgarian, Bosnian, Catalan, Czech, Danish,
 German, Dzongkha, Greek, Esperanto, Spanish, Basque, Finnish, French,
 Galician, Gujarati, Hebrew, Hindi, Croatian, Hungarian, Indonesian,
 Italian, Japanese, Georgian, Khmer, Korean, Lithuanian, Latvian,
 Macedonian, Malayalam, Marathi, Norwegian Bokm l, Nepali, Dutch,
 Norwegian Nynorsk, Punjabi, Polish, Portuguese, Brazilian Portuguese,
 Romanian, Russian, Slovak, Albabian, Swedish, Tamil, Thai, Turkish,
 Vietnamese, Simplified Chinese, Traditional Chinese
Already activated and complete for sublevels 1 and 2: 6
Bengali, Kurdish, Slovenian, Tagalog, Ukrainian, Wolof
Not yet activated languages complete for sublevels 1 and 2: 2
 (the mail in -i18n and -boot says 3 but this is an error by me)
Irish, Serbian
Languages failing to meet the release criteria: 15
--------------------------------------------------
Activated languages: 4
Amharic, Welsh, Estonian, Northern Sami
Not yet activated languages: 11
Afrikaans, Persian, Armenian, Icelandic, Kazakh, Kannada,
Malagasy, Malay, Telugu, Urdu, Xhosa
Discussion
----------
(careful people will notice that I moved Welsh down to "failed to meet
the release criteria" as this is what is technically correct)
Nothing to discuss for the 57 already activated languages that meet
the defined criteria. They'll be kept or first activated in the RC1
release of Debian Installer.
Similarly, nothing to discuss for the 11 languages that were not
activated and haven't made it. They will remain unactivated.
Two languages should be activated as they have met the release
criteria for the first time during the string freeze: Irish and Serbian.
This adds more load (and size changes) to D-I but I really don't see
any reason to not follow our own rules there.
The discussion comes for the 4 languages that fail to meet the release
criteria. Here are my proposals with some rationale:
Amharic: 
  I would really dislike deactivating Amharic because it's highly
  symbolic to have the language of Ethiopia activated. We have so few
  African languages. Also, the translation is nearly complete and the
  translator was well coping with updates until July. The missing
  stuff for Amharic in sublevels 1 and 2 are messages about loading
  drivers or firmware from removable media, the rescue mode stuff for
  the graphical installer and some messages that briefly appear during
  finish-install. A little bit more important is the message warning
  that the boot partition is not ext2 or ext3, added in August by
  tbm. I think this is not enough to drop out one year of efforts for
  the translator
  As a consequence, I propose to KEEP Amharic.
Welsh:
  Only five strings are missing in sublevels 1 and 2 because of the
  small experience of PO files by the person who completed the
  translation during last week. One will make the regular user login
  name screen to be in English and others will make the GRUB password
  screen to be in English as well, that's all.
  Additionnally, we can safely assume that all potential users of
  Welsh have good skills in English...and will therefore very easily
  cope with these screens.
  As a consequence, I propose to KEEP Welsh.
Estonian:
  The translation had NO update since Etch. The last update is dated
  back to Feb. 17th 2007. I haven't got any sign of life from the
  translator and no Estonian users have volunteered to maintain the
  translation.
  Missing strings are in many places, including several screens that
  appear in default installs. Even though one can assume that the
  skills of the average Linux user in Estonia is fairly good, I think
  this is not enough to throw users in a big mix of English and
  Estonian.
  As a consequence, I propose to DROP Estonian.
Northern Sami:
  The translation is very incomplete. With about any other language,
  that would be a reason to drop the translation.
  However, a few reasons make me suggest keeping it:
   - Northern Sami is mostly used in Norway and D-I will fall back
     to Norwegian Bokm l which is understood by all potentials users
     as it is teached in all Norwegian schools. 
   - Users will be warned, *in Sami*, about this situation
   - The choice of Sami will be kept in localechooser even if the
     translations are dropped. This is on request of Debian Edu
     developers to avoid them to develop a special boot floppy
     to offer the choice of Sami (a requirement for Norwegian
     schools). I personnally think this is a reward to Debian Edu and
     its ancestor Skolelinux for their initial involvement in the
     development of D-I
  As a consequence, I propose to KEEP Northern Sami.
I understand that these choices may be debatable and some may sound
slightly subjective. I however think this is the best way to be fair
with translators' efforts without compromising the quality of D-I.
Please note that the final word on this will be by D-I release
managers...but advices are very much welcomed.

I have been thinking about ways to speed multiple remote git on the same hosts. My starting point is mr, which does the job, but is a bit slow. I am thinking about giving up some generality for some speed. In particular it seems like it ought to be possible to optimize for the two following use cases:

• many repos are on the same host
• mostly nothing needs updating.

For my needs, mr is almost fast enough, but I can see it getting annoying as I add repos (I currently have 11, and mr update takes about 5 seconds; I am already running ssh multiplexing). I am also thinking about the needs of the Debian Perl Modules Team, which would have over 900 git repos if the current setup was converted to one git repo per module. My first attempt, using perl module Net::SSH::Expect to keep an ssh channel open can be scientifically classified as "utter fail", since Net::SSH::Expect takes about 1 second to round trip "/bin/true". Initial experiments using IPC::PerlSSH are more promising. The following script grabs the head commit in 11 repos in about 0.5 seconds. Of course, it still doesn't do anything useful, but I thought I would toss this out there in case there already exists a solution to this problem I don't know about.

 
#!/usr/bin/perl
use IPC::PerlSSH;
use Getopt::Std;
use File::Slurp;
my %config; 
eval( "\%config=(".read_file(shift(@ARGV)).")");
die "reading configuration failed: $@" if $@;
my $ips= IPC::PerlSSH->new(Host=>$config host );
$ips->eval("use Git");
$ips->store( "ls_remote", q my $repo=shift;
                       return Git::command_oneline('ls-remote',$repo,'HEAD');
                            );
foreach $repo (@ $config repos ) 
    print $ips->call("ls_remote",$repo);
 

P.S. If you google for "mr joey hess", you will find a Kiss tribute band called Mr. Speed, started by Joe Hess" P.P.S. Hello planet debian!