I'm on vacation

Currently I am on vacation and I will come back after the 9th of January.

(posted from my Nokia E71 on free wireless)

Aren't we all descendants of barbarians?

Only the winners get to write the history, so we almost never get to hear the other side of the story.

I was thinking how many times people who were right were reduced to silence by death by some opposing force?

We, as the descendants of the winners, still hold that barbaric seed of the oppressors, so we are probably inclined to repeat such atrocities.

Taking all of these into account, is this one of the main reasons why we still engage war upon each other, although we, as a race, in the present, could live together without any problems?

The world produces now enough goods and food to cater for the entire race, still, we are putting a price tag on everything and using money, the tool that enslaves us all.

Isn't it time to open our eyes and stop believing the lies we're fed with every day?

If you own/have access to a Nokia E71 made for Romania, please contact me

I am trying to contact an owner of a Nokia E71 who is able to input Romanian diacritics on this type of phone. This person shouldn't worry, there is nothing destructive/dangerous involving his/her phone, should he/she contact me.

(Skip up to the "second approach" paragraph, if you don't care for the technical details or my story.)


Some time ago, during my latest blog silence period, I bought a white Nokia E71 phone from a Cosmote dealer.

I am really satisfied with it, except for two or three small issues[0], but the most annoying is that my phone was not made for the Romanian market, so I can't type Romanian diacritics[1].


Why does this matter? Because since I bought this phone I managed to do some translation work on the E71, on the daily commute to work. Still, the lack of diacritics forces me to go through another hop to add diacritics to my .po files when I get home.


So I was thinking on ways to fix this issue. After some google-ing I came up with the following possible fixes:

• change the product code with a code for the Romanian version and upgrade to the next firmware version, when that arrives
• hack the phone and use ROMPatcher to patch the Romanian layout into the phone

Since my phone was made for Singapore and I want to change to a Romanian product code, I have to wait for an update to be visible for Romania. Although the firmware update arrived for Singapore products, for phones made for Romania the firmware update is unavailable, so I am stuck on the first front.



Enter the second approach and my request for help.

I have looked into the files of my phone and I think I have found the files which define the keyboard layouts available on my phone. I haven't made out the details of the files, but, as a first step, I thought that I should try to replace one of those layout files I don't need with a Romanian layout file.

The problem is that I don't have a copy of such a file, but on a phone that works this file should be present and should be easily accessible. For short, I would need a copy of the firmware that is running on the phone, so I can try to replace on my phone the relevant files.



If you own a Nokia E71 and you're able to input Romanian diacritics on it, please contact me via a comment on my blog, or an email at eddy.petrisor+e71@gmail.com. Thanks in advance!


[0] the phone is really close to perfection on my scoreboard
[1] the correct "s comma" and "t comma" are not visible in any font present in the phone, but as long as they are correctly encoded I am fine with that. Surely with a proper font and an external editor I can fix that problem.

Coordinating localization via git

Note: this is quite long and might not be interesting for people not involved with /in either of: debian i18n, debian l10n, git, shell scripting.


For some time now I have been the de-facto coordinator of the Romanian localization team. During this time I was faced multiple times with problems related to motivation of the team members, setting goals for a release, coordination of the changes inside the team, integration of new translators in the team, loosing team members, my lack of time on some occasions and other problems.

I thought a lot about how to improve on those points and I was never satisfied with the answers I got. What I think was the worst problem in the team was the inability to set clear goals, especially during lenny's development cycle.

During sarge's and etch's development cycles we were in an infancy state and setting as the goal to have a fully translated installation process was really enough to keep people motivated. For sarge we missed by a small margin, but the translations were of poor quality, while for etch we worked more on improving the translations.


But during lenny it was bad, really bad. My free time had been shrinking for a while, starting with etch's release, and we were unable to set clear goal, since for etch we managed to have the installation process fully translated and a few other translations. There was no way for us to reach 100% translations during lenny's development cycle, so setting that as a goal was really unrealistic. Percents by themselves don't mean anything for people, and as long as there's no substance to those numbers, there's no motivation to reach for one arbitrary percent.

I tried to set as a goal translating the packages installed by default in a new installation, but that hit the eternal question How do we know easily which are those packages?. This remained sometimes unanswered or got an unsatisfying answer. Also, there was a goal to have correct diacritics for Romanian in lenny, to have aspell-ro that uses the correct diacritics.

I even got to a point that I, myself, lost my motivation and set myself a personal goal of overrunning the level the translations that the language just above Romanian had in the po-debconf l10n statistics (ranking between languages). This was nice way for me to keep myself motivated, but I had my reserves in making this motivation public out of fear of being misinterpreted, because, by a strange coincidence, that next language was Hungarian, and in Romania's history there was some friction between Hungaria and Romania, while there are still some tensions with the Hungarian minority in Romania, in areas where they represent the local majority.

I managed to reach my personal goal, but this wasn't addressing the big picture.



So, sometime around the start of this year I started thinking about ways to coordinate the Romanian localization team in order to have:

• a clear goal at any given time
• a way to always be able to change that goal as we go
• a way to sync with eventual calls for translations, or the current sid translations
  
• stats immediately available
• automated checks for spelling, correct diacritics usage and other checks that might be useful (e.g. translation completeness)
• an easy way to assign somebody else as a language coordinator (I would appreciate some help or I might even consider stepping down)
• easy integration of new translators (by providing immediate answer to the question "What can I do to help with the translations?")
  

For short, a tool that would allow the team to work more efficiently while having the possibility to set clear goals in order to keep people motivated.



So after some pondering, I thought that creating a repository with the translations and the helper tools that would do the funky sync, checks, stats would be the best way to do that. So I started hacking on that somewhere around July-August and I published the result, but without much publicity, since it is still incomplete.

Some of the technical details are still in a haze, but I have a general idea and I got some basic functionality.


Today I decided that I should announce this semi-officially though my blog, maybe I get some input, ideas, or even contributions (I really should write a TODO).




I give you the Debian L10n Romanian coordination repository.

This is a git repository that has some tools to facilitate translation coordination and the translations that are current in the distro for the team.


Can be cloned with:

git clone git://git.debian.org/git/users/eddyp-guest/debian-ro-repo.git

or, if you're behind a restrictive firewall:

git clone http://git.debian.org/git/users/eddyp-guest/debian-ro-repo.git



Currently the work flow for updating a translation is as follows:

1. source _bin/polibs (. _bin/polibs)
2. cd foo
3. po_refresh
4. complete the translation
5. po_rearrange "ro.po"
6. git add "ro.po" && git commit -m "updated translation for foo"
7. send the translation ("git format-patch origin" and send the patches by mail, or, alternatively, just "git push")
   

Features:

• provides a po_refresh function that can import material directly from http://i18n.debian.net/material, but can also allow manual imports (template.pot from a call from translation)
• for a new translation: source _bin/polibs (. _bin/polibs), make a directory with the name of the source package, cd into it, and run po_refresh
  
• po_rearrange - beautify and unify the layout of PO files (facilitating compact and sane diff-ing for PO files)
• po_merge uses compendium, if present
  

Planned features:

• sync translations/templates from package VCS-es (Vcs-* headers and debcheckout should be the means to the end)
• po_rearrange should be called as a pre-commit hook; should either reject the commit if the po file was not rearranged, or automatically rearranged before the commit
• generate stats
• add commands for "what's outdated", "what needs review", "submit translation", and maybe "reserve translation for offline use"
• conflict merges should be done via po_merge (.gitattributes is key here)
• support other file types (?) - does this make any sense?
• periodic and automated sync with sid for all translations
  

Problems:

• security - running tests automatically from files within the repo doesn't seem too wise, but looks like the only way to get automated testing on any translator machine; maybe keeping the code in a submodule might address this issue?
• entry level translators still have a hard time - UI sucks now; there should be a wrapper command that should use the library functions and should provide a useful help
  
• is git too difficult ? - git backend usage maybe should be cloaked?
• still in development/alpha stage - I still haven't figured some of the issues
• central repo or really distributed - should there be a central git repo where the coordinator(s) do the pushes? it seems the central repo with a small pushers team for new translators (which can't commit directly) might actually facilitate interactions between experienced and new translators to instruct/bring up to speed the rookies

I was hoping that the release notes for lenny would facilitate from this infrastructure, but unfortunately I was lately in a really inactive period wrt Debian.



Questions, suggestions, ideas are welcome.

signing packages heads-up

When trying to sign some Debian packages fails, you might think that temporally changing LANG to find similar errors on the web is a good idea.

But when you see that the expired key is not the default one and you made sure that the GPG agent environment info is correct, while signing still fails, you might start to consider that bad rendering of the "s comma below" character in your name might be worth taking into account.


gpg: skipped "Eddy Petrișor ": secret key not available


Also, remembering that LC_MESSAGES=C is the right way to have English messages, while preserving all the rest of the localization info, is also useful.

Nokia has your data

As a beta tester for the new email application from Nokia, you will have to give your mail account password:



and agree that they will get your data, too [1].




Really unimpressive, Nokia.


[1] I haven't checked the "Nokia privacy policy", but is enough for me to say no, thanks, and start to wonder if they do anything behind my back with the phones they sell.

Nokia and WPA2 PSK

Dear Nokia,

I really like your phones and I have been using them for about 10 years, but please understand that WPA2-PSK keys can be up to 64 hexdigits long, not 63.

Please fix this issue on the Nokia E51 phone and any other phones on which this might be the same.

Also, please, don't suggest that I should persuade all the admins that use 64 digits long keys to change them and change every client that already uses such a key, just to allow a phone to use the APs they admin.

P.S.: Could somebody confirm/inform that the same issue affects the Nokia E71?

---

Update: The bug was confirmed for E51, E65, E66, E71 devices. I sent a report to the support for Nokia about this.

one week ago

This happened:


This is why lately I haven't been available.

crazy idea: user supported snapshot.debian.net

I just had this crazy idea about solving snapshot.debian.net's space issue which just might work if done right.

We all know that snapshot.debian.net has ran out of space in early May this year and we all lost a valuable service. Since there are probably many users, developers and maintainers which find this service useful, it might make sense to think that the users themselves could solve the problem.

How? Think about implementing a really distributed storage/file system (not necesarly a real file system) that can rely on cluster nodes that can enter or exit at any time and the nodes are contributed by users, very much alike the GoogleFS file system (or maybe clients in a torrent swarm).


First problems that I can already see:

• there must be some indexing service that should run 24x7 to manage the information about the blocks which are desired.
• some data should always be kept on a trusted machine - the gpg signatures, the Packages files indexing information and meta data
  
• there might be a security risk involved since data would be stored on untrusted machines, but a sha1/md5 check in colaboration with the gpg signature should be enough (which isn't always doable - see large packages like openoffice.org or game data packages); if there are reasons why this might not be secure, maybe we need to rethink a little about the dpkg-sig package and see if we can get all the packages in the archive to be individually signed when entering the archive, or something of that sort
• the meta-data of the FS cluster might be really big, but my gut feeling tells me that it won't be as big as the current snapshot.d.n storage
• when a file is requested, the file needs to be cached on a central server so it can be assembled and its checksum be verified before being delivered to the client requesting it
• people might donate really little space compared to their usage
• some nodes of the network are special and this could lead to the failure of the entire infrastructure in case the special nodes fail; some of these nodes might turn out to need really big muscles
  
• some data might be unavailable at times depending on the clients connected to the network at different points in time
• in an attempt to create more copies of a block in more nodes in the network, a DoS might be triggered if many clients request the same info from a (set of) node(s) containing the rare info - still torrent's way of workig seems to cope quite well with that model
• none of this is implemented and probably I won't do it myself, although it could be a really nice project, even it is doomed to fail from day 1
  

Other ideas:

• maybe it would make more sense for the FS to actually be an ever-growing torrentt which people can connect to via some special client which would allow pushing to the clients in order to store information
• the number of copies of a file (or chunk of a file) in the distributed storage should be higher for more recent packages and lower for older ones (still one copy might be necessary to be stored on safe nodes - aka controled and trusted by debian so the information doesn't get lost - back to our current storage problem)
• probably the entire thing could be built somehow by piggy-backing the current apt-transport-debtorrent implementation or debtorrent, or apt's cache - the idea is that although not all files might be available, some people might still have relatiely recent packages files in their apt cache
• such a system, if done right, might prove to be usable as a live backup system between different nodes in the cluser, so it could be used in other situations by individuals, without the need of a central server - think trackerless trorrents
  

What do other people think?

vga=what in lilo.conf for 1280x800 1440x1024

With the more frequent wide screen laptops using 1280x800 or something else like 1440x1280, most people would want the console in vesa mode to use the entire screen, not only 1024x768.

I was in that situation and wanted to know the "secret code" that was needed for that console mode since these modes for 1280x800 seem to be vendor specific and not a VESA standard. They are not present in the official documentation but can be found with a simple command:

hwinfo --framebuffer | grep 1280x800

and pick one of those that makes sense for you. Add that to lilo.conf, run lilo (run etckeeper commit, if you use etckeeper) and reboot. Enjoy.

migrating from svn to git for wormux's maintainance

I have been thinking for quite some time about migrating the maintenance of the wormux package to git, but in a really smart way so that:

• we preserve history currently stored in svn
• a new integration branch should exist - we used the incomplete package model with svn-buildpackage, but now it makes more sense to have the complete history, including the upstream code at the time
  
• all previous orig tarballs should exist in the git repo in pristine-tar format
• upstream's svn repo should be included entirely so that we can cherry-pick any patches we might want or need

Since both the package repo and the upstream repo are in SVN, you can't simply use git-svn for both in a single repo, so I started thinking of some scheme to be able to join both repos and the (uncommitted) orig tarballs (which are backed up on DGT's webspace).


Tonight I have experimented a little with my git-svn clones which I made previously and eventually thought that:

• the main repo should track the upstream repo via git-svn
• I should properly tag the debian package versions in the svn.d.o repo, so svn tags no longer look like branches in git
  
• ideally all the branches in the package repo should be reproduced in some corresponding branch in the final repo
• the integration branch (that should contain the real debian complete packages) should be created with a non-existant merge strategy which I call overlay (basically, for two branches A and B, the strategy resumes to: all files as in A are present, any files unique to B are present)
• using pristine-tar forces me to keep the 'upstream' branch reserved so I need to avoid using that

It seems the last point could be obtained in some way via this small set of commands (I am sure it needs some modification to make the integration work in another branch C):

git merge --no-commit -s ours B
git checkout B -- .
git checkout A -- .
git commit


Note: Looking back, I think I can do a better job next time and I will se if I can use the resulting repo to create a new repo and drop the svn package maintainance for wormux. If this works, I might be able to create a script to allow migration of svn-bp maintained packages to git, at least for the Debian Games Team.


Since you can't fix a problem if you don't take things one at a time, I started by cloning the initial git-svn generated repos.

So after waiting some time (both git-svn fetch commands took long enough), I had to git-svn repos:

• repo A - the package repo
• repo B - the upstream svn clone repo

I tried to clone both A and B, to avoid distroying the original A and B clones and noticed that the svn branches were not visible from the cloned repo since the origins didn't had any other local branches than master - the svn trunk for each of them. So I added tracking branches in A for the experimental and sarge versions of the package. I also added some tags in A so that the svn tags don't get lost in between.

In the end I got my A' repo that had:

0 eddy@heidi ~/usr/src/wormux/tt/debian-bare $ git br -a
debian-experimental
debian-sarge
debian-sid
* master
origin/debian-experimental
origin/debian-sarge
origin/master

Yes, and having master in A' is not a good idea, but since I made A' a bare repo I had to suffer. Well, one more thing to better in iteration 2.


Excellent, now I can go in B and add the new remote repo which is A' which I should have called pkgsvn, but I ended up call it 'origin'. Since git-svn doesn't treat the svn repo as a true remote, this was possible.



Due to some confusion I also added 'ups-' as a prefix to the svn remote trunk and tags, but I am still unsure if this was necessary - I'll have to see more clearly into the pristine-tar restrictions area.

After all of this I got this branch configuration:
0 eddy@heidi ~/usr/src/wormux/tt/git-full $ git branch
* master
0 eddy@heidi ~/usr/src/wormux/tt/git-full $ git branch -r
0.8-final
0.8beta4
origin/debian-experimental
origin/debian-sarge
origin/debian-sid
origin/master
ups-tags/wormux-0.7
ups-tags/wormux-0.7.2
ups-tags/wormux-0.7.3
ups-tags/wormux-0.7.4
ups-tags/wormux-0.7.9
ups-tags/wormux-0.7.9rc1
ups-tags/wormux-0.7beta3
ups-tags/wormux-0.8
ups-tags/wormux-0.8alpha1
ups-tags/wormux-0.8beta1
ups-tags/wormux-0.8beta2
ups-tags/wormux-0.8beta3
ups-tags/wormux-0.8beta4
ups-trunk
wormux-0.7
wormux-0.7.9
wormux-0.8beta1
wormux-0.8beta2

So more tracking branches were necessary; I fired 'gitk --all' and got a nice picture, after adding tracking branches for branches originating from A':


This is not yet complete and now I am feeling sleepy, so I'll continue once I experiment more.

git-core backport still useless

The versioned depends on tk8.5 has been removed in 1:1.5.6.3-1~bpo40+4, but still, this isn't enough:

$ gitk
/usr/bin/gitk: line 3: /usr/bin/wish8.5: No such file or directory
/usr/bin/gitk: line 3: exec: /usr/bin/wish8.5: cannot execute: No such file or directory

The irony is that you can simply workaround with:

# ln -sf /usr/bin/wish8.4 /usr/bin/wish8.5


But the proper fix would be to apply this patch:


diff --git a/debian/rules b/debian/rules
index 7a1e771..7bd25cd 100755
--- a/debian/rules
+++ b/debian/rules
@@ -7,7 +7,7 @@ CFLAGS =-g -Wall
STRIP =strip
TEST =test
OPTS =NO_OPENSSL=1 prefix=/usr mandir=/usr/share/man INSTALLDIRS=vendor \
- WITH_P4IMPORT=1 PYTHON_PATH=/usr/bin/python TCLTK_PATH=/usr/bin/wish8.5 \
+ WITH_P4IMPORT=1 PYTHON_PATH=/usr/bin/python TCLTK_PATH=/usr/bin/wish \
THREADED_DELTA_SEARCH=1

ifneq (,$(findstring nostrip,$(DEB_BUILD_OPTIONS)))
--
1.5.6.3

git-core etch backport is useless

Update:

It seems that the lenny version (1:1.5.6.3-1) plus some small changes to allow building and running on etch does not have this problem.

The changes include:

* backported to etch
- compile against tcl8.4, instead of tcl8.5
- gtik and git-gui depend on tk8.4, instead of tk8.5
- drop the versioned dep on asciidoc and docbook-xsl

---

It s really nice that git-core is backported to etch, but is kind of hard to convince people to use it when gitk needs tk8.5, which is unavailable in etch.

This was the reason why previosely I made a local backport (1:1.5.6-1~bpo40+1~local) thinking the missing/extra[*] dep was a temporary glitch. According to bug 456423, this should be safe.


Does backports.org have a buildd network? IIRC, it uses the experimental buildd network, but that doesn't explain the desynchronisation of the packages in etch-backports.


Oddly enough, the build now fails on my etch machine during the tests in t9400-git-cvsserver-server.sh (looks like it is not related to the tk8.5 change):

* FAIL 23: cvs update (create new file)
echo testfile1 >testfile1 &&
git add testfile1 &&
git commit -q -m "Add testfile1" &&
git push gitcvs.git >/dev/null &&
cd cvswork &&
GIT_CONFIG="$git_config" cvs -Q update &&
test "$(echo $(grep testfile1 CVS/Entries|cut -d/ -f2,3,5))" = "testfile1/1.1/" &&
diff -q testfile1 ../testfile1

* expecting success: echo line 2 >>testfile1 &&
git add testfile1 &&
git commit -q -m "Append to testfile1" &&
git push gitcvs.git >/dev/null &&
cd cvswork &&
GIT_CONFIG="$git_config" cvs -Q update &&
test "$(echo $(grep testfile1 CVS/Entries|cut -d/ -f2,3,5))" = "testfile1/1.2/" &&
diff -q testfile1 ../testfile1
Counting objects: 5, done.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 282 bytes, done.
Total 3 (delta 1), reused 0 (delta 0)
Unpacking objects: 100% (3/3), done.
To gitcvs.git
0879984..e6bd37b master -> master
cvs update: Updating .
cvs update: New directory `master'
* FAIL 24: cvs update (update existing file)
echo line 2 >>testfile1 &&
git add testfile1 &&
git commit -q -m "Append to testfile1" &&
git push gitcvs.git >/dev/null &&
cd cvswork &&
GIT_CONFIG="$git_config" cvs -Q update &&
test "$(echo $(grep testfile1 CVS/Entries|cut -d/ -f2,3,5))" = "testfile1/1.2/" &&
diff -q testfile1 ../testfile1

* checking known breakage:
mkdir test &&
echo >test/empty &&
git add test &&
git commit -q -m "Single Subdirectory" &&
git push gitcvs.git >/dev/null &&
cd cvswork &&
GIT_CONFIG="$git_config" cvs -Q update &&
test ! -d test

Counting objects: 4, done.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 388 bytes, done.
Total 3 (delta 0), reused 0 (delta 0)
Unpacking objects: 100% (3/3), done.
To gitcvs.git
e6bd37b..4a13ee9 master -> master
cvs update: Updating .
cvs update: New directory `master'
* FIXED 25: cvs update w/o -d doesn't create subdir (TODO)

* expecting success: (for dir in A A/B A/B/C A/D E; do
mkdir $dir &&
echo "test file in $dir" >"$dir/file_in_$(echo $dir|sed -e "s#/# #g")" &&
git add $dir;
done) &&
git commit -q -m "deep sub directory structure" &&
git push gitcvs.git >/dev/null &&
cd cvswork &&
GIT_CONFIG="$git_config" cvs -Q update -d &&
(for dir in A A/B A/B/C A/D E; do
filename="file_in_$(echo $dir|sed -e "s#/# #g")" &&
if test "$(echo $(grep -v ^D $dir/CVS/Entries|cut -d/ -f2,3,5))" = "$filename/1.1/" &&
diff -q "$dir/$filename" "../$dir/$filename"; then
:
else
echo >failure
fi
done) &&
test ! -f failure
Counting objects: 13, done.
Compressing objects: 100% (4/4), done.
Writing objects: 100% (12/12), 754 bytes, done.
Total 12 (delta 1), reused 0 (delta 0)
Unpacking objects: 100% (12/12), done.
To gitcvs.git
4a13ee9..f573218 master -> master
cvs update: Updating .
cvs update: New directory `master'
grep: A/CVS/Entries: No such file or directory
grep: A/B/CVS/Entries: No such file or directory
grep: A/B/C/CVS/Entries: No such file or directory
grep: A/D/CVS/Entries: No such file or directory
grep: E/CVS/Entries: No such file or directory
* FAIL 26: cvs update (subdirectories)
(for dir in A A/B A/B/C A/D E; do
mkdir $dir &&
echo "test file in $dir" >"$dir/file_in_$(echo $dir|sed -e "s#/# #g")" &&
git add $dir;
done) &&
git commit -q -m "deep sub directory structure" &&
git push gitcvs.git >/dev/null &&
cd cvswork &&
GIT_CONFIG="$git_config" cvs -Q update -d &&
(for dir in A A/B A/B/C A/D E; do
filename="file_in_$(echo $dir|sed -e "s#/# #g")" &&
if test "$(echo $(grep -v ^D $dir/CVS/Entries|cut -d/ -f2,3,5))" = "$filename/1.1/" &&
diff -q "$dir/$filename" "../$dir/$filename"; then
:
else
echo >failure
fi
done) &&
test ! -f failure

* expecting success: git rm testfile1 &&
git commit -q -m "Remove testfile1" &&
git push gitcvs.git >/dev/null &&
cd cvswork &&
GIT_CONFIG="$git_config" cvs -Q update &&
test -z "$(grep testfile1 CVS/Entries)" &&
test ! -f testfile1
rm 'testfile1'
Counting objects: 3, done.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (2/2), 233 bytes, done.
Total 2 (delta 1), reused 0 (delta 0)
Unpacking objects: 100% (2/2), done.
To gitcvs.git
f573218..2ed3834 master -> master
cvs update: Updating .
cvs update: New directory `master'
* ok 27: cvs update (delete file)

* expecting success: echo readded testfile >testfile1 &&
git add testfile1 &&
git commit -q -m "Re-Add testfile1" &&
git push gitcvs.git >/dev/null &&
cd cvswork &&
GIT_CONFIG="$git_config" cvs -Q update &&
test "$(echo $(grep testfile1 CVS/Entries|cut -d/ -f2,3,5))" = "testfile1/1.4/" &&
diff -q testfile1 ../testfile1
Counting objects: 4, done.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 300 bytes, done.
Total 3 (delta 1), reused 0 (delta 0)
Unpacking objects: 100% (3/3), done.
To gitcvs.git
2ed3834..3f3e927 master -> master
cvs update: Updating .
cvs update: New directory `master'
* FAIL 28: cvs update (re-add deleted file)
echo readded testfile >testfile1 &&
git add testfile1 &&
git commit -q -m "Re-Add testfile1" &&
git push gitcvs.git >/dev/null &&
cd cvswork &&
GIT_CONFIG="$git_config" cvs -Q update &&
test "$(echo $(grep testfile1 CVS/Entries|cut -d/ -f2,3,5))" = "testfile1/1.4/" &&
diff -q testfile1 ../testfile1

* expecting success: echo Line 0 >expected &&
for i in 1 2 3 4 5 6 7
do
echo Line $i >>merge
echo Line $i >>expected
done &&
echo Line 8 >>expected &&
git add merge &&
git commit -q -m "Merge test (pre-merge)" &&
git push gitcvs.git >/dev/null &&
cd cvswork &&
GIT_CONFIG="$git_config" cvs -Q update &&
test "$(echo $(grep merge CVS/Entries|cut -d/ -f2,3,5))" = "merge/1.1/" &&
diff -q merge ../merge &&
( echo Line 0; cat merge ) >merge.tmp &&
mv merge.tmp merge &&
cd "$WORKDIR" &&
echo Line 8 >>merge &&
git add merge &&
git commit -q -m "Merge test (merge)" &&
git push gitcvs.git >/dev/null &&
cd cvswork &&
sleep 1 && touch merge &&
GIT_CONFIG="$git_config" cvs -Q update &&
diff -q merge ../expected
Counting objects: 4, done.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 302 bytes, done.
Total 3 (delta 1), reused 0 (delta 0)
Unpacking objects: 100% (3/3), done.
To gitcvs.git
3f3e927..28c1b4a master -> master
cvs update: Updating .
cvs update: New directory `master'
* FAIL 29: cvs update (merge)
echo Line 0 >expected &&
for i in 1 2 3 4 5 6 7
do
echo Line $i >>merge
echo Line $i >>expected
done &&
echo Line 8 >>expected &&
git add merge &&
git commit -q -m "Merge test (pre-merge)" &&
git push gitcvs.git >/dev/null &&
cd cvswork &&
GIT_CONFIG="$git_config" cvs -Q update &&
test "$(echo $(grep merge CVS/Entries|cut -d/ -f2,3,5))" = "merge/1.1/" &&
diff -q merge ../merge &&
( echo Line 0; cat merge ) >merge.tmp &&
mv merge.tmp merge &&
cd "$WORKDIR" &&
echo Line 8 >>merge &&
git add merge &&
git commit -q -m "Merge test (merge)" &&
git push gitcvs.git >/dev/null &&
cd cvswork &&
sleep 1 && touch merge &&
GIT_CONFIG="$git_config" cvs -Q update &&
diff -q merge ../expected

* expecting success: ( echo LINE 0; cat merge ) >merge.tmp &&
mv merge.tmp merge &&
git add merge &&
git commit -q -m "Merge test (conflict)" &&
git push gitcvs.git >/dev/null &&
cd cvswork &&
GIT_CONFIG="$git_config" cvs -Q update &&
diff -q merge ../expected.C
Counting objects: 5, done.
Compressing objects: 100% (3/3), done.
Writing objects: 100% (3/3), 303 bytes, done.
Total 3 (delta 1), reused 0 (delta 0)
Unpacking objects: 100% (3/3), done.
To gitcvs.git
28c1b4a..1f0f9c8 master -> master
cvs update: Updating .
cvs update: New directory `master'
diff: merge: No such file or directory
* FAIL 30: cvs update (conflict merge)
( echo LINE 0; cat merge ) >merge.tmp &&
mv merge.tmp merge &&
git add merge &&
git commit -q -m "Merge test (conflict)" &&
git push gitcvs.git >/dev/null &&
cd cvswork &&
GIT_CONFIG="$git_config" cvs -Q update &&
diff -q merge ../expected.C

* expecting success: cd cvswork &&
GIT_CONFIG="$git_config" cvs -Q update -C &&
diff -q merge ../merge
cvs update: Updating .
cvs update: New directory `master'
diff: merge: No such file or directory
* FAIL 31: cvs update (-C)
cd cvswork &&
GIT_CONFIG="$git_config" cvs -Q update -C &&
diff -q merge ../merge

* expecting success: echo Line 9 >>merge &&
cp merge cvswork/merge &&
git add merge &&
git commit -q -m "Merge test (no-op)" &&
git push gitcvs.git >/dev/null &&
cd cvswork &&
sleep 1 && touch merge &&
GIT_CONFIG="$git_config" cvs -Q update &&
diff -q merge ../merge
Counting objects: 5, done.
Compressing objects: 100% (3/3), done.
Writing objects: 100% (3/3), 303 bytes, done.
Total 3 (delta 1), reused 0 (delta 0)
Unpacking objects: 100% (3/3), done.
To gitcvs.git
1f0f9c8..e6c5fc1 master -> master
cvs update: Updating .
cvs update: New directory `master'
* ok 32: cvs update (merge no-op)

* expecting success:
touch really-empty &&
echo Line 1 > no-lf &&
echo -n Line 2 >> no-lf &&
git add really-empty no-lf &&
git commit -q -m "Update -p test" &&
git push gitcvs.git >/dev/null &&
cd cvswork &&
GIT_CONFIG="$git_config" cvs update &&
rm -f failures &&
for i in merge no-lf empty really-empty; do
GIT_CONFIG="$git_config" cvs update -p "$i" >$i.out
diff $i.out ../$i >>failures 2>&1
done &&
test -z "$(cat failures)"

Counting objects: 4, done.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 305 bytes, done.
Total 3 (delta 1), reused 0 (delta 0)
Unpacking objects: 100% (3/3), done.
To gitcvs.git
e6c5fc1..4d0f85b master -> master
cvs update: Updating .
cvs update: New directory `master'
cvs update: Updating .
cvs update: New directory `master'
cvs update: Updating .
cvs update: New directory `master'
cvs update: Updating .
cvs update: New directory `master'
cvs update: Updating .
cvs update: New directory `master'
* FAIL 33: cvs update (-p)

touch really-empty &&
echo Line 1 > no-lf &&
echo -n Line 2 >> no-lf &&
git add really-empty no-lf &&
git commit -q -m "Update -p test" &&
git push gitcvs.git >/dev/null &&
cd cvswork &&
GIT_CONFIG="$git_config" cvs update &&
rm -f failures &&
for i in merge no-lf empty really-empty; do
GIT_CONFIG="$git_config" cvs update -p "$i" >$i.out
diff $i.out ../$i >>failures 2>&1
done &&
test -z "$(cat failures)"


* expecting success:
mkdir status.dir &&
echo Line > status.dir/status.file &&
echo Line > status.file &&
git add status.dir status.file &&
git commit -q -m "Status test" &&
git push gitcvs.git >/dev/null &&
cd cvswork &&
GIT_CONFIG="$git_config" cvs update &&
GIT_CONFIG="$git_config" cvs status | grep "^File: status.file" >../out &&
test $(wc -l <../out) = 2 Counting objects: 5, done. Compressing objects: 100% (2/2), done. Writing objects: 100% (4/4), 366 bytes, done. Total 4 (delta 1), reused 0 (delta 0) Unpacking objects: 100% (4/4), done. To gitcvs.git 4d0f85b..a146cf3 master -> master
cvs update: Updating .
cvs update: New directory `master'
Invalid module '' at /home/eddy/usr/src/tools/git-backports/1.5.6.3-1~bpo40+3~local/git-core-1.5.6.3/t/../git-cvsserver line 2895, line 18.
cvs [status aborted]: end of file from server (consult above messages if any)
* FAIL 34: cvs status

mkdir status.dir &&
echo Line > status.dir/status.file &&
echo Line > status.file &&
git add status.dir status.file &&
git commit -q -m "Status test" &&
git push gitcvs.git >/dev/null &&
cd cvswork &&
GIT_CONFIG="$git_config" cvs update &&
GIT_CONFIG="$git_config" cvs status | grep "^File: status.file" >../out &&
test $(wc -l <../out) = 2 * expecting success: cd cvswork && GIT_CONFIG="$git_config" cvs status -l | grep "^File: status.file" >../out &&
test $(wc -l <../out) = 1 Invalid module '' at /home/eddy/usr/src/tools/git-backports/1.5.6.3-1~bpo40+3~local/git-core-1.5.6.3/t/../git-cvsserver line 2895, line 19.
cvs [status aborted]: end of file from server (consult above messages if any)
* FAIL 35: cvs status (nonrecursive)

cd cvswork &&
GIT_CONFIG="$git_config" cvs status -l | grep "^File: status.file" >../out &&
test $(wc -l <../out) = 1 * expecting success: cd cvswork && GIT_CONFIG="$git_config" cvs status | grep ^File: >../out &&
! grep / <../out Invalid module '' at /home/eddy/usr/src/tools/git-backports/1.5.6.3-1~bpo40+3~local/git-core-1.5.6.3/t/../git-cvsserver line 2895, line 18.
cvs [status aborted]: end of file from server (consult above messages if any)
* FAIL 36: cvs status (no subdirs in header)

cd cvswork &&
GIT_CONFIG="$git_config" cvs status | grep ^File: >../out &&
! grep / <../out * fixed 1 known breakage(s) * failed 11 among 36 test(s) make[2]: *** [t9400-git-cvsserver-server.sh] Error 1 make[2]: Leaving directory `/home/eddy/usr/src/tools/git-backports/1.5.6.3-1~bpo40+3~local/git-core-1.5.6.3/t' make[1]: *** [test] Error 2 make[1]: Leaving directory `/home/eddy/usr/src/tools/git-backports/1.5.6.3-1~bpo40+3~local/git-core-1.5.6.3' make: *** [build-arch-stamp] Error 2


[*] depends on how you look at it

Recommending the MSI MegaBook PR200WX-058EU laptop to Linux users

I recently bought a new MSI laptop and I am really pleased with my choice so far.

Since with the previous laptop I managed to kill two of my desired features, long battery life and pretty portable, I decided is time to look really well and see what the market has to offer.

I settled on a MSI PR200WX-058EU which has the following:

• built on a Centrino platform
• Intel(R) Core(TM)2 Duo CPU T8300 @ 2.40GHz
  
• Intel Corporation PRO/Wireless 4965 AG or AGN
• Intel mobile chipset
• 3GB of memory (yes, I would have enjoyed 4, but it seems the 32 bit barrier still decides hardware configurations)
• 320GB HDD
• DVD+/-RW
• Mobile GM965/GL960 Integrated Graphics Controller
• 12" wide screen (1280x800)
• 1 Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet
• 8 cell battery by default (long battery life)
  
• 1 USB 2.0 Camera - uses luvc driver
• bluetooth
• 1 card reader
• 3 USB port, 1 HDMI, 1 D-sub 15 connector, 1 PCI Express port, modem port
• fingerprint reader
• an advertised weight of 1.8kg (I weighted it at 2.1kg with the 8 cell battery)
  

In other words a small and mobile powerhouse for which I payed 3800 RON (approx. 1100€). I'd say not too bad at all.

Thanks to Gonéri Le Bouder and some searches on the internet I concluded that
the brand is not bad at all, and now that I have it I really am sure.

Of course, I installed Debian Lenny on it (I also sent an installation report), and, in spite of the initial problems, I managed to make the laptop work pretty nice, but I am especially excited about the webcam, which works with the linux-uvc driver.


There were some issues, but I managed to fix some them while I have been ignoring some other. The LaptopTestingTeam page for MSI PR200 on the ubuntu wiki was very helpful.
What have I been ignoring?

• it seems that from time to time the battery charge status isincorrect, or acpi report that the AC is plugged in
• headphones don't automatically turn off the speakers
• fingerprint reader is not used yet, but I intent to experiment at some point with it (authentication via the fingerprint would be cool)
  
• the keyboard seems a little bit too hard (but I hope it will loose up with time)
• modem isn't probably working, but I don't think I'll ever try
• there are some issues in gnome-power-manager which cause strange behaviour and grief wrt screen brighness
• sleep doesn't work,but hibernation does
  

What would you do if I'd tell you that the battery lasts 4 hours or even more while the wlan is on and working (browsing and stuff like installing new packages, configs) with the brightness set to minimum?


I am really excited about this and I can say that I think I have found my next generation laptop, so if you're thinking of a cheap mobile powerhouse on which Linux must run, this laptop might be for you.

I find the following to be selling points (for a Linux buyer or others):

• comes with FreeDOS, so no extra money for an OS you don't use
  
• wifi works
• webcam works with luvc
• no big problems during install (the most severe are already fixed)
• long battery life, even when using wifi (4+ hours in browsing+some package installation mode, according to my tests)
• light enough to carry around easily (2.1kg, 2.4kg with charger)
• nice design - some people asked me if I bought a MacBook
• 4 state kill switch for all possible combinations for wifi/bluetooth
• hibernate works with 2.6.24 or newer (sleep doesn't, but I will try a few things later)
  
• there's no mechanical latch for the lid, there is a magnet, so there's no plastic to be broken, the laptop is more robust
• the 8 cell battery is thicker than the regular one, allowing better ventilation
• it seems it doesn't get too hot to put on my lap (still, I am a little afraid of blocking its ventilation due to the fabric of my clothes, so I'll probably try to carry around a hard paperboard or something like that)
• the big resolution 1280x800 (for this screen size) seems to partly compensate for the reduced physical size of the screen (12")
• bright screen

So, thanks again to Gonéri, Debian Installer team, LVM2 maintainers, Ubuntu Laptop Testing team, linux uvc developers, Lilo developers and maintainers, all the nice people who made and still make Debian possible.

fast translation bug report via icedove

Here's a quick way to report po-debconf transalations:



Courtesy of Quicktext

---

Update: the image above is an animated gif and some viewers might not be able to render such images correctly. Apparently even on the blog the animation isn't visible unless you click on the image itself.

obscene VNC

I guess obscenity wasn't thought of in xvnc4viewer. Feel free to submit a BR.

OH MY GOD!

This can't be true! How can someone trust such a key?

Does anybody have a reasonable explanation for such an abomination?



Update: It seems it is unclear to some people what is the problem with this key. There are multiple identities (apparently different people) for the same key. So, in layman's terms, multiple different people are using exactly the same key to certify their identity.

I really don't understand how this could work in real life. Maybe is a case of misunderstanding what gpg is about?

when printouts don't help to revoke a GPG key

It's official, I am revoking my gpg key because after my laptop returned from service[1] I realized is a bad idea to change the passphrase just before a long break away from a routine that would help the brain to cement the new passphrase. In other words, I forgot the passphrase.

So, let's get the revocation certificate printout and revoke that gpg and generate a new one. All is good and fine until you realize that „I” (capital i) and „l” (low case „L”) look very much the same on paper. Oops!

So, what do you do? How many „I/l”-s are there in the certificate? Let's find out...


0 eddy@bounty ~/tmp/revoke $ cat template
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: A revocation certificate should follow

iEkEIBECAAkFAkbYOQUCHQIACgkQY8Chqv3NRNquGgCgxdMDrhycNcoJsaeeg7hk
8vVJZzsAnRicsfjcZnUtmLIsys6KK48FbJ4h
=I5o9
-----END PGP PUBLIC KEY BLOCK-----

Well, I'm not going to count, I'll remove the header and footer and see from there...

0 eddy@bounty ~/tmp/revoke $ cat template.in | tr -d '[a-zA-HJ-Z0-9=]'
II
I
I

Ok, so we have 16 possible combinations, not that many.

0 eddy@bounty ~/tmp/revoke $ for i in l I ; do for j in l I ; do for k in l I ; do for l in l I ; do cat template.in | sed -e "s#I#$i#" -e "s#I#$j#" -e "s#I#$k#" -e "s#I#$l#" > $i$j$k$l.mid ; done ; done ; done ; done
0 eddy@bounty ~/tmp/revoke $ md5sum *.mid
eab3a5e312bc0314ac2b3d4536bda2f6 IIII.mid
63a9dd10e381b8ff5c758ab3467a5c45 IIIl.mid
63a9dd10e381b8ff5c758ab3467a5c45 IIlI.mid
919d8494c9990c68f50bc9df61f269bc IIll.mid
63a9dd10e381b8ff5c758ab3467a5c45 IlII.mid
919d8494c9990c68f50bc9df61f269bc IlIl.mid
919d8494c9990c68f50bc9df61f269bc IllI.mid
919d8494c9990c68f50bc9df61f269bc Illl.mid
63a9dd10e381b8ff5c758ab3467a5c45 lIII.mid
919d8494c9990c68f50bc9df61f269bc lIIl.mid
919d8494c9990c68f50bc9df61f269bc lIlI.mid
919d8494c9990c68f50bc9df61f269bc lIll.mid
919d8494c9990c68f50bc9df61f269bc llII.mid
919d8494c9990c68f50bc9df61f269bc llIl.mid
919d8494c9990c68f50bc9df61f269bc lllI.mid
919d8494c9990c68f50bc9df61f269bc llll.mid

Oops, that's not ok... I guess I've been replacing some of the characters more than once.

Take 2:
0 eddy@bounty ~/tmp/revoke $ for i in l I ; do for j in l I ; do for k in l I ; do for l in l I ; do cat template.in | tr 'Il' '-'| sed -e "s#-#$i#" -e "s#-#$j#" -e "s#-#$k#" -e "s#-#$l#" > $i$j$k$l.mid ; done ; done ; done ; done
0 eddy@bounty ~/tmp/revoke $ md5sum *.mid
eab3a5e312bc0314ac2b3d4536bda2f6 IIII.mid
eab3a5e312bc0314ac2b3d4536bda2f6 IIIl.mid
eab3a5e312bc0314ac2b3d4536bda2f6 IIlI.mid
eab3a5e312bc0314ac2b3d4536bda2f6 IIll.mid
7150fa775c83c276223a30d373671333 IlII.mid
7150fa775c83c276223a30d373671333 IlIl.mid
7150fa775c83c276223a30d373671333 IllI.mid
7150fa775c83c276223a30d373671333 Illl.mid
63a9dd10e381b8ff5c758ab3467a5c45 lIII.mid
63a9dd10e381b8ff5c758ab3467a5c45 lIIl.mid
63a9dd10e381b8ff5c758ab3467a5c45 lIlI.mid
63a9dd10e381b8ff5c758ab3467a5c45 lIll.mid
919d8494c9990c68f50bc9df61f269bc llII.mid
919d8494c9990c68f50bc9df61f269bc llIl.mid
919d8494c9990c68f50bc9df61f269bc lllI.mid
919d8494c9990c68f50bc9df61f269bc llll.mid

Oops, that's not good either. Doh, sed works on lines.

Take 3:

Make a one line out of the template and try again:

0 eddy@bounty ~/tmp/revoke $ cat template.in
iEkEIBECAAkFAkbYOQUCHQIACgkQY8Chqv3NRNquGgCgxdMDrhycNcoJsaeeg7hk8vVJZzsAnRicsfjcZnUtmLIsys6KK48FbJ4h=I5o9

0 eddy@bounty ~/tmp/revoke $ for i in l I ; do for j in l I ; do for k in l I ; do for l in l I ; do cat template.in | tr 'I' '-' | tr 'l' '-' | sed -e "s#-#$i#" -e "s#-#$j#" -e "s#-#$k#" -e "s#-#$l#" > $i$j$k$l.mid ; done ; done ; done ; done
0 eddy@bounty ~/tmp/revoke $ md5sum *.mid
66ab0a0bed219db8499debabb9a41c0b IIII.mid
e02c1751c4491ce5db1ebe9e64d8eadc IIIl.mid
c96a33f821d3fba84f655aa986084320 IIlI.mid
998c5c4219a5afdd77f82c9fc9818f6f IIll.mid
e08fe6c5380765d12c4f5e4090a7d9c6 IlII.mid
24241b58c231900b02ebb0410183983e IlIl.mid
72040a77e7cca9a91abf2bb0d51c00dd IllI.mid
a02e8645f3593f5c3549b49adef04bc2 Illl.mid
99a1a47c853ed760ef1f58cba7b75916 lIII.mid
c48bf75f30be46ec576a46a1d5664a93 lIIl.mid
717e9dfdc0d3fba973ba66ccb57d69dc lIlI.mid
3e9a2c937fd269d85c09b449b4da17de lIll.mid
4d283333d1d62086328dbc72425a645d llII.mid
542a7c00e99aad5137975581e57a92c9 llIl.mid
ef0e0a2daad7a933b620331a86455c23 lllI.mid
bdf852887308830475a506f8daad9624 llll.mid

That's better. Now let's put those lines back in place:

0 eddy@bounty ~/tmp/revoke $ for I in *.mid ; do cat $I | sed -e 's#\(eeg7hk\)#\1-#' -e 's#\(K48FbJ4h\)#\1-#' | tr '-' '\n' > $I.good ; done


And revoke that key...

0 eddy@bounty ~/tmp/revoke $ for I in *.mid.good ; do echo "$I:" && (cat header $I footer) > template && gpg --import -a template ; done
IIII.mid.good:
gpg: CRC error; 73689A - 239A3D
gpg: read_block: read error: invalid keyring
gpg: import from `template' failed: invalid keyring
gpg: Total number processed: 0
IIIl.mid.good:
gpg: CRC error; 73689A - 979A3D
gpg: read_block: read error: invalid keyring
gpg: import from `template' failed: invalid keyring
gpg: Total number processed: 0
IIlI.mid.good:
gpg: key FDCD44DA: "Eddy Petrișor " revocation certificate imported
gpg: Total number processed: 1
gpg: new key revocations: 1
gpg: public key 67D8E867 is 987014 seconds newer than the signature
gpg: public key 67D8E867 is 987014 seconds newer than the signature
gpg: public key 67D8E867 is 987029 seconds newer than the signature
gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model
gpg: depth: 0 valid: 2 signed: 139 trust: 0-, 0q, 0n, 0m, 0f, 2u
gpg: depth: 1 valid: 139 signed: 667 trust: 138-, 0q, 0n, 1m, 0f, 0u
gpg: next trustdb check due at 2008-10-09
IIll.mid.good:
gpg: CRC error; 239A3D - 979A3D
gpg: read_block: read error: invalid keyring
gpg: import from `template' failed: invalid keyring
gpg: Total number processed: 0


Cool!


[1] I know is almost a half a year, but I've been busy and hoping

Motorcycles DO EXIST on the road!

Some of you might have noticed that in the recent weeks I wasn't active at all online. This was because I was on a vacation in Italy. On the way back I was eager to write about my experiences, but after entering Romania, I found out that may parents had been involved in a motorcycle accident due to a careless driver.

The accident took place on the second day of the Orthodox Easter (on the 28th of April)[1] while my parents were coming back from my sister's, just 20 km away from my home town, Caracal, in a village called Zănoaga. There, a Daewoo Cielo was parked on the left side of the road[2], facing the direction towards Caracal. The driver decided that it was a good idea to turn his vehicle and, according to his declaration, instead of looking himself if there was anything comming, he asked a passenger if there were any cars comming.

Since a motorcycle is not a car, I guess the passenger thought it was OK to answer "no".

So the driver simply started his maneuver and managed to occupy the entire right lane, according to the accident schematics (I saw the official police schematics of the accident site with my own eyes). There were only 30 cm from the front most point of the car to the ditch on the right side of road, while the rear wheels were on the mark indicating the axis of the road. That left only 2 meters free on the opposite lane out of the 6.60 meters wide road, so there was no way for my father (driving the motorcycle) to avoid the collision, in spite of the fact he was travelling at about 40-50 km/h[3], within the legal speed limit (50 km/h).

My father barely had enough time to avoid the central pillar and aim for the rear right door of the car, obviously, a safer place to hit. Still, this wasn't enough to keep my mother on the motorcycle, a safer place for her than anywhere on the road.

My mother was projected over my father and over the car, and, luckily, landed on the side of the road, between the asphalt and the ditch, on an area covered with grass. She landed straight onto her head (the helmet protected her really well), and the shock of the landing propagated along the spine, resulting in the fracture of the L1 vertebra. She also got a fissure in the right clavicula, but that should already be OK now.

My father managed to remain on the motorcycle, but the impact was violent enough that he managed to bend the gas tank and has two huge bruises on the inside of his thighs (one for each leg). He also accuses pains in his shoulders and the lower end of the spine (unfortunately he "managed" not to do the medical investigations after the accident), but I hope all of these will pass soon and will have no ill effects. Also, out of sheer luck, at that time, my father was wearing a full-face helmet, contrary to his habit of earing an open-face helmet; due to this, his face was protected and suffered no harm, while the chin of the helmet broke after the impact with the motorcycle windshield. Also some deep scratches starting from the half of the helmet windshield up to the top of the helmet were the signs of a (probably second) violent impact with the motorcycle windshield.



So, the next time you are on the wheel, please look out for motorcycles, too. Motorcycles do exist on the road!

Also, I advice anyone driving a motorcycle to wear good protection equipment like a full-face helmet, jacket, pants, boots, gloves, etc. These helped a lot my parents, and will help you too, if, God forbid, you are involved in an accident.


My mother is in a cast that covers her from hips to shoulders to help with the fracture recovery and also wears a collar (just for safety reasons since she is suffering of spondyloses).
My father is able to walk (with some pain) and seems not to have any injures (I will take him for a close investigation some time soon in spite of his stubbornness).



[1] worrying for us (me and my future spouse), my parents didn't told us and waited for us to return to Romania
[2] in Romania the vehicles travel on the right side of the road, so the driver also drove on opposite lane, a fact which, according to the law, is punished with the suspension of the driving license
[3] he speed was confirmed by the measurements done by the police

Finally I made time for it and I have it!

Heh, now I can ride!

News from other worlds

I was recently forced to face once more the limitations and quirks of rpm. This is more painful, when looking at a more capable system like .deb.

When building a .deb package, the debian/rules file is pretty much the heart of all things happening, with debian/control and debian/changelog as the lungs and the liver(? maybe) .

Having different files for the maintainer scripts makes possible things like automatic (but repetitive) generation/modifications of those scripts. This can be useful in some situations when the postinst should do stuff depending on the current contents of the released upstream source (sorry, I know I am being vague, but I can't detail too much). The source package is then generated and the resulting package can be rebuilt 1000 times and the resulting postinst will not be different for a given release. But this is always done in the same way, no matter the upstream version.

Fatality one - the spec is fixed, saint, but still can be altered... still, not in due time

So the basic idea is to have postinst.in as a source for postinst, which is created during the configure stage and later removed on clean. This is possible and works on deb.

Try the same on rpm and you will fail. This is because, although the spec file supports file inclusions, the altered files are merged into the spec right at the beginning of the build process, and you end up with no or an outdated postinst. A later rebuild of the same package would do the trick, but that is wrong for more than one reason.

Fatality two - why fatality one was met

All of this is made in order to overcome yet another rpm limitation: rpm can't assist too much on upgrades; you can't simply upgrade packages properly from one version to another, because rpm doesn't have the notion of letting the scripts know which version is installed over which; it only tells that it is an upgrade or not.

This has lead some people believe rpm isn't able to upgrade at all. Glad to tell them they're wrong (still rpm sucks and is brain dead).

Fatality three - why rpm based system fail to have upgrade support today

Want another RPM limitation? RPM has this brain dead idea that on upgrade the "proper" order and way to call the maintainer script(lets) is:

• new-preinst 2
• new-postinst 2
• old-prerm 1
• old-postrm 1

The numbers 1 and 2 are literally what is passed to the scripts and mean "the number of the installed versions of the same package that will exist after the current operation finishes". No versions of any kind, no other parameters, no rollback, no nothing, just 1 or 2.

And by letting the scripts of the old version run AFTER the scripts of the new one means that you have to explicitly prepare the packages for a later upgrade support (and the best idea is to do NOTHING in the old prerm and postrm scripts on upgrades, since nobody is clairvoyant to see what would be the right course of action for upgrade in future releases).

More bad ideas from the rpm land (glad not to be there)

In somewhat related news, the fedora people are discussing now around the rejection of being able to have package names contain non-ascii characters, characters like kanji, kanas, cyrillic characters or any other characters. Even if I am pro-l10n, this wreaks of bad idea scent from a mile afar.

They aren't probably aware that even unicode is broken (if you see the same glyphs in the comparison table, that is proof unicode is broken) but that is their decision and I am glad I am not in that lost land.

mistranslations - how to deal with it

Aigars, you could use what I already made for the compedia creation. The code is available on i18n.debian.net in my home dir (I thought I exposed it on alioth, too, but I just checked and is not).

The results for latvian are also present.

email harvesting prevention - simple and efficient

On this page I've seen this nice way of preventing email addresses harvesting (I have noscripts installed):



When javascript is enabled/permited, it looks like this:


The code is really simple and could be easily automatically applied to pages (the code obfuscates even more, but that is irrelevant - see the original source for the code):

<script language='JavaScript' type='text/javascript'>
<!--
var prefix = 'ma' + 'il' + 'to';
var path = 'hr' + 'ef' + '=';
var addy35780 = 'g.martinez' + '@';
addy35780 = addy35780 + 'pcbsd' + '.' + 'es';
document.write( '<a ' + path + '\'' + prefix + ':' + addy35780 + '\'>' );
document.write( addy35780 );
document.write( '<\/a>' );
//-->\n </script><script language='JavaScript' type='text/javascript'>
<!--
document.write( '<span style=\'display: none;\'>' );
//-->
</script>This e-mail address is being protected from spam bots, you need JavaScript enabled to view it
<script language='JavaScript' type='text/javascript'>
<!--
document.write( '</' );
document.write( 'span>' );
//-->
</script>

BTW, the PC-BSD site looks really nice, unlike Debian's.

Debian Games Team - have source, but do not import :-/

JoeyH wrote a while back some thoughts on why he hates the DGT SVN repo (mainly our policy to import just the incomplete source of packages - usually just the debian/ directory).

He updated that blog entry and latter said:

Update: I realized after posting this that while the space gains on alioth might be illusory, there is certianly a space gain for people checking the whole repo out. What's really needed is a way to keep all the upstream sources in svn, but check them out only when wanted, and check out all the debian directories for cross-game work.

I was thinking, how about having a different area of the repo where the full source is present and which pulls the debian directory as an external from the current location?

I know it has the huge disadvantage that anything outside of the debian/ directory, but part of the diff, is, for sure, lost. (Still, there is also another team policy to not track anything outside debian directly, except through patches[1], except for really exceptional cases, but even then, there is a need for a strong justification).


Would that work? (I know git-svn doesn't support externals properly, yet, so there's not much gain).


[1] I know Joey, you hate those, too

pbuilder - /etc/pbuilderrc no longer a conffile (333294)

I have just finished a completely functional patch for pbuilder's bug #333294. I started this during debconf7, to be more precise, just after Junichi's talk about pbuilder. This patch makes pbuilder smarter smarter about the information it places in the MIRRORSITE variable of the /etc/pbuilderrc.

And now that file is no longer a conffile[1], and it asks some questions via debconf. And since debconf is translatable, there is a Romanian translation, too.

I have published my changes in my pbuilder git repo on alioth.

Anyone interested in the changes can pull from that repo:

git://git.debian.org/git/users/eddyp-guest/pbuilder.git
or
http://git.debian.org/git/users/eddyp-guest/pbuilder.git


[1] this was the main reason the patch wasn't good enough, since modifying a conffile is RC.

TDebs - arch is not important, is it?

Updates:

1. the arch issue raised by Frans was not the object of my post. Also, not all points are invalid/reiterated, just the ones iterated here. Thanks Frans.
2. add a note that there is an image that proves that .mo endianness is irelevant - usefull for readers that might miss that

---

While looking at Neil Williams' talk(hi-res/lo-res) from FOSDEM about cross building and tdebs I was STUNNED about the many (not all, thanks Frans) points that were reiterated during that talk when there were already answered.

Well, I guess you have to repeat yourself a lot to get your ideas through to the other side. So, let's do that.

All (except the first) of the following have been already answered one way or another on the TDebs wiki page.

Q: .mo files are arch independent or not? Neil asks again on his blog.
A: It doesn't matter, does it?

0 eddy@bounty ~ $ file /usr/share/locale/ro/LC_MESSAGES/wormux.mo
/usr/share/locale/ro/LC_MESSAGES/wormux.mo: GNU message catalog (big endian), revision 0, 228 messages
0 eddy@bounty ~ $ uname -a
Linux bounty 2.6.24.2-bounty #1 SMP Wed Feb 13 02:34:09 EET 2008 x86_64 GNU/Linux

(there is a picture here which proves my point, if you can't see it, click here).



Q: The packages file will explode
A: No, that's addressed.

Q: How do you select languages?
A: Simply use what we have and expand on that.

Q: Do tdebs support anything else than gettext?
A: Yes.

Building in a sarge chroot might not always work

Adeodato correctly points out that building under a Sarge chroot, and expecting the package to work on Sid, might not always[1][2] work mainly because of ABI changes and similar changes. Thus, I am forced to clarify this a little.


Generally, the binaries in the packages we produce do not dynamically link to anything other than libc6, libstdc++5 (yes, 5, not 6) or some internal libraries, so we don't have to worry about ABI changes, at least, not yet.


So, a disclaimer is in order: unless you know what you're doing, you probably are better off building packages for each of the supported Debian distros.

Thanks Adeodato for the heads-up.

[1] unless your package is a special case
[2] or, better said, in most cases

---

udate: fixed the link to dato's post

sarge + cowbuilder = love

Update:
A disclaimer/warning is needed: UNLESS you KNOW what you're doing, you probably are better off building packages for each of the supported Debian distros.

---

I know it sounds cheesy, but I couldn't find a better name.


At my workplace we are packaging software to work for as many distros as possible at one time. As a consequence the .deb packages we produce should work fine on all Debian distros: oldstable, stable, testing, sid.

To make sure we achieve that, we are building them in an oldstable chroot. OTOH, using pbuilder is very demanding on I/O, especially when entering the chroot and when exiting it. That slows down a lot the build system and is time to change that.


One reliable alternative is to use cowbuilder (part of cowdancer package). What is interesting is that cowbuilder relies on the existance of /usr/bin/cow-shell inside the chroot, so the cowdancer package needs to be installed both in the chroot and the host machine.

But cowdancer was not a part of sarge, so, if you try to create a new sarge cow directory with cowbuilder, it will fail at the end saying it didn't found the cowdancer package. Also trying to login via cowbuilder --login will complain it didn't found /usr/bin/cow-shell.


The fix for this is simple, once you figured it out and saw that cowdancer is available in sarge as a backport:

cowbuilder --create --distribution sarge --basepath /var/cache/pbuilder/sarge.cow --othermirror 'deb http://www.backports.org/debian sarge-backports main'

You may prefer to be sure that the only thing from backports is cowdancer and use a more hands-on approach[1]. Also, this will eliminate the need to correct later the apt sources to exclude backports[2].

Write the same command as before, but omit everything starting with --othermirror. Then install by hand the package in the chroot.

twix:/home/eddy# cowbuilder --create --distribution sarge --basepath /var/cache/pbuilder/sarge.cow
twix:/home/eddy# chroot /var/cache/pbuilder/sarge.cow
twix:/# wget http://ftp.de.debian.org/backports.org/pool/main/c/cowdancer/cowdancer_0.23~bpo.1_i386.deb
twix:/# dpkg -i cowdancer_0.23~bpo.1_i386.deb
twix:/# rm cowdancer_0.23~bpo.1_i386.deb
twix:/# exit
twix:/home/eddy# cowbuilder --update

Since after the bootstrap all .deb packages will be in the apt cache in the chroot, you might want to save some disk space:

twix:/home/eddy# cowbuilder --login --save-after-login
twix:/# aptitude clean
twix:/# exit

That's it!


If anything is broken somehow, missing or whatnot, cowbuilder --login --save-after-login is your friend.

[1] the initial bootstrap does not pull from backport anything else but cowdancer
[2] since you want to compile for plain sarge, not sarge+backports ;-)

Postfix - (almost) a satellite system

When installing postfix and configuring it to act as a "Satellite system", all mails, including messages to root, will go to the remote mail delivery system. Also, there might be a local user account that absolutely doesn't exist on the remote MTA and should stay on the local machine, but, by default, this doesn't happen.

This is not good.

What is needed in such a case is virtual_alias_maps and a /etc/postfix/virtual file such as:

root    root@localhost
root@fqdn.domain.name    root@localhost
eddy    eddy@localhost
eddy@fqdn.domain.name    eddy@localhost

Don't forget to run postmap /etc/postfix/virtual, after restarting the system.


This tip is particularly useful on laptops.

[VCS/SCM] same language, different lingo

When people say "lightweight branches":

• In git lingo, most likely they will think about the fact that you don't need a different directory to switch to a different branch.
• In subversion lingo, they will probably mean that the cost of making a branch in the repository does not impose an expensive operation
• In bzr lingo, it seems they mean a repository with short history (aka shallow copy, for most other people)
• it seems that mercurial refers to git's meaning as "named branches" (not sure about this); not sure if mercurial documentation refers to anything else as "lightweight branches"

Export means:

• for subversion: to create a working copy without any meta information
• for mercurial/hg: "The act of exporting a changeset generates an augmented patch file that describes the change."
• for git, it seems to be a useless 'cp -r' operation

There are several other differences in the VCS/SCM lingo paralel uses, if you want to look closely, but these are enough for now...

No wonder we have communication problems and people don't grasp the power of a new tool when it changes the meaning of previously used terms.

wireless prohibition

After setting up wireless via WPA2-PSK with AES and realizing I really need the new firmware, I ended up using the latest wireless-2.6 kernel from branch 'everything'.

Now I am again browsing wireless-ly and I am wondering if the digital divide isn't already here:



Is there any reason why this discrimination is done? do they fear that they won't be able to sell the series?

forking privately in Debian

Joachim, the key is probably to implement patch support in srcinst and actually implement something nice which I think has nice applications.

It might be nice to combine srcinst with debian-xcontrol to obtain also customizable dependencies (e.g. no arts support).

I guess you'll be the best person to take over srcinst since:

1. John Goerzen doesn't want to/can't continue maintaining it
2. is written in Haskell and you know Haskell
3. source is available for grabs from http://darcs.complete.org/srcinst/

The basic idea is to have another command[1] wrap aptitude/apt-get/srcinst and make sure it does the proper job, depending on the local configuration.


[1] let's say, the debtoo command - srcinst should remain the tool for clear 'from source installs'

wpa2-psk with aes on a broadcom wlan0 (2.6.24)

Update: I managed to find out why the wpa_action stuff was needed. Please ignore the lines written like this; they are there just for reference.

One more update: it seems that the firmware needs to be in sync. I ended up using the wireless-2.6 kernel from the everything branch.

---

I just managed to get my wlan from my laptop to work with WPA2-PSK with AES with the free Broadcom driver (now named b43, formerly bcm43xx).

0b:00.0 Network controller: Broadcom Corporation BCM94311MCG wlan mini-PCI (rev 01)

0b:00.0 0280: 14e4:4311 (rev 01)

In order to do this I needed linux 2.6.24-1 from unstable and the b43 driver.

bounty:/home/eddy# lsmod | grep b43
b43                   119976  0
rfkill                 12816  3 rfkill_input,b43
mac80211              132236  1 b43
led_class              10120  1 b43
input_polldev           9872  1 b43
ssb                    39428  2 b43,b44
pcmcia                 45720  2 b43,ssb
pcmcia_core            46500  2 b43,pcmcia
firmware_class         15232  2 b43,pcmcia

The final trick was to convince wpasupplicat to reload the config with:

bounty:/home/eddy# wpa_action wlan0 reload
wpa_action: reloading wpa_supplicant configuration file via HUP signal

This is the wpasupplicant.conf file that I used:

bounty:/home/eddy# cat /etc/wpa_supplicant/wpasupplicant.conf | grep -v '^\s*#' | sed 's/psk=.*/psk=aaabbb___ENCRIPTED_SEE_wpa_password___cccddd/'
ctrl_interface=/var/run/wpa_supplicant
ap_scan=1
network={
ssid="toblerone"
scan_ssid=1
proto=RSN
key_mgmt=WPA-PSK
pairwise=CCMP
group=CCMP
psk=aaabbb___ENCRIPTED_SEE_wpa_password___cccddd
}

and this is the relevant interfaces area:

auto wlan0
allow-hotplug wlan0
iface wlan0 inet dhcp
wpa-driver wext
wpa-conf /etc/wpa_supplicant/wpasupplicant.conf
wpa-ap-scan 2

This is what it looks like when is working:

bounty:/home/eddy# iwconfig wlan0
wlan0     IEEE 802.11g  ESSID:"toblerone"
Mode:Managed  Frequency:2.412 GHz  Access Point: 00:1B:FC:45:33:70
Bit Rate=48 Mb/s   Tx-Power=27 dBm
Retry min limit:7   RTS thr:off   Fragment thr=2346 B
Encryption key:1337-0000-C121-d73D-0207-RE41-0000-3210 [2]
Link Quality=98/100  Signal level=-36 dBm  Noise level=-68 dBm
Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
Tx excessive retries:0  Invalid misc:0   Missed beacon:0

And here's the result of a scan (relevant section):

  Cell 02 - Address: 00:1B:FC:45:33:70
ESSID:"toblerone"
Mode:Master
Channel:1
Frequency:2.412 GHz (Channel 1)
Quality=93/100  Signal level=-42 dBm  Noise level=-68 dBm
Encryption key:on
IE: IEEE 802.11i/WPA2 Version 1
   Group Cipher : CCMP
   Pairwise Ciphers (1) : CCMP
   Authentication Suites (1) : PSK
Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 11 Mb/s; 18 Mb/s
         24 Mb/s; 36 Mb/s; 54 Mb/s; 6 Mb/s; 9 Mb/s
         12 Mb/s; 48 Mb/s
Extra:tsf=0000000072ff542d

and here is proof it works:

bounty:/home/eddy# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.77.0    0.0.0.0         255.255.255.0   U     0      0        0 wlan0
0.0.0.0         192.168.77.254  0.0.0.0         UG    0      0        0 wlan0

bounty:/home/eddy# ping debian.org
PING debian.org (192.25.206.10) 56(84) bytes of data.
64 bytes from gluck.debian.org (192.25.206.10): icmp_seq=1 ttl=36 time=201 ms
64 bytes from gluck.debian.org (192.25.206.10): icmp_seq=2 ttl=36 time=199 ms
64 bytes from gluck.debian.org (192.25.206.10): icmp_seq=3 ttl=36 time=200 ms

--- debian.org ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 1999ms
rtt min/avg/max/mdev = 199.691/200.519/201.046/0.786 ms

Woooohooo! :-)

Thanks to all people involved in b43 development and all the ones made this possible (Debian developers).

Posted from bed, via wlan.

---

Update: You need the firmware blob, which can be extracted from a Windows driver with bcm43xx-fwcutter (now called b43-fwcutter); I already had it from my previous attempts to configure wlan with bcm43xx. I am not sure if I should use the new tool. You really need the firmware and driver to be in sync.

Update: it seems the b43 driver page (the entire linuxwireless.org site) went down sometime yesterday evening, since yesterday afternoon I was browsing through the site without any issues. (Note: I live in Europe, for reference)