Daniel Baumann: dosfstools 3.0.0
dosfstools is a collection of three utilities for making and checking FAT/MS-DOS filesystems:
- dosfsck (aka fsck.msdos and fsck.vfat)
- dosfslabel
- mkdosfs (aka mkfs.dos and mkfs.vfat)
dosfstools is a collection of three utilities for making and checking FAT/MS-DOS filesystems:
This week, I sufferred and still suffer from a very painful left shoulder, which handicaps me for most activities.
That happened when I falled during one of my regular runs, after hitting a stone on the floor. I probably falled right on my left shoulder and, since then, it is more and more painful.
This is indeed an encore of something that happened already in July
when I had a very bad fall while running in the woods, because of a
stupid low-level fence meant to keep boars outside the forest.
I unfortunately suspect a broken shoulder or so.
No run for this week-end, then. Sad, as I was indeed on my way back to long distance runs (22km last week) in an attempt to break the 30km barrier until the end of the year.
I'm even handicapped for typing on my keyboard which, as my wife says, should be the final argument to bring me to a doctor and have rido exams....(I hate seeing doctors!).
When the Debian installer starts, it will normally ask you what language
you want to install in and gives you a really long list of languages to
choose from. Unfortunately, that's not how it works when you install on a
headless NAS device. The reason for this is that installations on NAS
devices are done via SSH and the installer normally brings the network up
after asking the user for their language. So we'd simply skip the language
question and go with English.
When Timo Jyrinki recently mentioned that he couldn't install in Finnish,
Frans Pop pointed out that localechooser has changed a lot since etch and
that it should now be possible to have the language question after setting
up the network. This turned out to be correct and I managed to choose a
different language but the installer still showed everything in English.
Frans reminded me that the installer drops all translations that are not
necessary but unfortunately this happens too early in our case. He pointed
me to a variable that determines whether translations will be dropped. So
in lenny translations will not be dropped on NAS devices that have enough
RAM and users will be asked when they connect to the installer via SSH what
language they'd like to install in.
Linux will never be able to displace MacOS/Windows since the latter are much more pretty/user-friendly. You will lose.Such people assume that hackers write free software because they "hate Microsoft" or "hate capitalism" or have some other pet hates. However, it should be obvious that such a large creative effort cannot be sustained if it is based on such negative emotions.1 There are a number of positive reasons why one works on free software. The software that I like to work on is software2 that I use or want to use. This has some consequences which are worth underlining:
Reia uses an indentation-sensitive syntax. This allows Reia to look similar to Erlang without relying on "ant turd" tokens (i.e. , ; and .) to structure relationships between forms.That made me laugh, and is in all seriousness, something that I do find to be a bit annoying in Erlang, especially when refactoring code. You can't just move a line of code from one place to another; you move it, then change the line endings in both places. My preference would be to do something more Ruby style rather than Python style for the following reason: the indentation thing makes it harder to use straight-up Python for templating purposes, whereas Ruby can be used as-is. Templates are something that I wouldn't particularly want to do in Erlang, either, so doing them with this language might be a very nice alternative. Anyway, it looks to be in its infancy. Unfortunately, it seems to require a more recent version of Erlang than what ships with Ubuntu Hardy. Maybe Intrepid will have something recent enough to run it. It's a little known fact that I originally wrote Hecl in Erlang, although, sadly, I can't find the code any more.
Russell writes about the iphone. I think he's missing a few things.
First root canal today. There were some interesting parts. I'll spare you.
If I seemed a bit annoyed with awesome 3 configuration in the last post,
this has put it well in perspective.
One nice thing about awesome 3 is that it has good system tray support
built in. So I've at least temporarily mainstreamed my laptop, so it's
using the gnome power manager, and network manager, instead of hibernate
and sleepd and my own scripts.
I was invited to participate at Festival Internacional de Software Libre (FISOL), in Tapchula, Chiapas. The other invited speakers were Sandino Flores (tigrux), Alexandro Colorado (jza), Eric Herrera (crac), John Hall (maddog) and Fernando Romo (pop), all well-known due to very different contributions to the Free Software movement in Mexico and abroad. Several other people also presented tutorials, but I was not involved in that part, and mentioning one while not the rest would be unfair.
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. :-)
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:
Now playing: Willi Astor — Gwand Anham Ära
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/certainAnd 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
This is a wonderful day. The various non-free bits of X donated by SGI have, thanks to the efforts of those at the FSF, been relicensed under the MIT/X11 license. Congratulations to the FSF for pushing this very difficult task through. I've been told numerous times whenever I tried to take a stab at the issue that it was "tilting at windmills," but the FSF persevered and made the impossible happen. This should be evidence for the naysayers that the FSF is out there doing the really hard, and all too often thankless, work that helps keep our software Free.
Hectic days...
The last l10n teams are waking up and alarming messages seem to be sent in various places after my various blog posts, messages to lists, private messages, etc. (I think that the only place where I haven't yelled out for D-I translations is the street I live in).
As of now, 7 languages are still in danger to be de-activated:
Amharic, Estonian, Latvian, Macedonian, Northern Sami, Albanian,
Tagalog
Among these, Latvian and Macedonian should make it: Arangel Angov for Macedonian and Aigars Mahinovs for Latvian will probably complete the required minimum.
For others, I'm afraid that Estonian, Albanian and maybe Tagalog will
be deactivated. I have to think about it. I will be very sad for all of them if I have to do it. But I haven't got news from these translators for ages and I haven't been able to find any possible backup translator.
For Albanian and Tagalog, that's not a surprise. For Estonian, I call this very disappointing.
Northern Sami is a special case: this is the language of the Sami people in Norway, teached there in schools and important for DebianEdu...which originated in Norway and has been the pilar of D-I development a few years ago. As finding Sami translators is very difficult, I will probably keep the language (also, because it has a solid backup with Norwegian).
Amharic is also special for me. The l10n effort is very specific: the translator works on ships all around the world, from his words, and can only communicate with me when he reaches a harbour. He has also been very committed to reach completeness (which he did) and the translation was only fuzzied by last minute changes in August. I'll probably fight to keep that language in D-I..:-)
Still, there's one day left. So if your language is not 100% on D-I statistics for level 1, then try to do something.
And, guess what? After the deadline is reached, I'll still have work to do: get as many levels 2-5 translations completed. All of these belong to regular Debian packages so they're not dependent on D-I release schedules!
If you are working with Eclipse on a Java project, make sure to try a regular
(ant) build from time to time. The eclipse compiler sometimes differs quite a
lot in what it accepts (especially when it comes to generics it seems to be a
bit more clever) or considers a warning.No, I did not just disable a warning. Eclipse did report some
"serialVersionUID" warnings, but it missed lots of them, too. I have the vague
impression that the Eclipse java compiler didn't recognize that a class
implementing the "Externalizable" interface also should have a serial version
UID.And unfortunately I didn't find a way to reach the serial UID generation
quickfix without having an eclipse warning... Well, after all there is not
much wrong with starting the serial version at 1L.
Why is it that always the seemingly most simple things turn out to be the most annoying? This time I “just” wanted to get rid of one of my last MySQL databases and move it over to PostgreSQL. The Bacula catalog that saves which file I backed up when and to which storage medium. I tried with MySQL’s “mysqldump” and it’s PostgreSQL compatibility option - but apparently MySQL developers know nothing about PostgreSQL. Then I tried with “sqlfairy” - and found myself booting my system hard after it ate 2 GB of swap and died while converting 500 MB of data.
So finally I asked in #bacula and was told to try CSV (comma-seperated values) as an intermediate format. Yuck… that satan-spawned format that reminds me of my dark past? Okay. First dump the catalog from MySQL:
for table in BaseFiles CDImages Client Counters Device File Filename FileSet Job JobMedia Location LocationLog Log Media MediaType Path Pool Status Storage UnsavedFiles Version ; do mysqldump -u root -pmypassword -T. bacula $table; done
(Okay, okay, this is not comma- but tab-seperated. But that’s even better for running the COPY-FROM command later.)
This creates an ‘.sql’ (the schema) and a ‘.txt’ (the rows/records) file for each table in the current directory. Just don’t try to apply the schema to PostgreSQL. Instead better create a new schema. Bacula ships with a script for that purpose.
Unless you have the PostgreSQL database for Bacula ready you should run something like…
/usr/share/bacula-director/make_postgresql_tables -h localhost -U bacula
…and…
/usr/share/bacula-director/grant_postgresql_privileges -h localhost -U bacula
Now on to read the tab-delimited data into PostgreSQL. The importing via the COPY command must be done with administrator privileges! And it’s important to explicitly state which columns correspond to which table columns (see the respective ‘.sql’ files) or otherwise you’ll get chaos. Of course this only has to be done for .txt files larger than 0 bytes. Oh, and the filename has to be absolute. Example:
s/0000-00-00 00:00:00/1970-01-01 00:00:00/g. Clear the table (DELETE FROM job) and import again.
And finally it’s important to get the sequence numbers right as described in the Bacula manual.
Morale: spend two extra-minutes to start with PostgreSQL right away instead of bothering about conversions later. And never assume converting from one database to another would work - just because both have “SQL” in their names.
Next.