Search Results: "ed"

12 December 2011

Dominique Dumont: What name for Config::Model s new command line ? cfg or something else ?

Hello As Damyan mentioned last summer in Debconf, the current command interface to Config::Model Perl module is rather cumbersome as it involves quite a lot of typing. First, config-edit command name is too long. Even with the help bash completion, this does not compare well with git or hg command. Then all operation require options. For instance, the -application option is required to specify what you will be working on. A required option is a good example of an oxymoron. Which may be funny but which is not user friendly So, here s the synopsis of the new command I m working on:
# edit dpkg config with GUI (Tk or curses, or readline)
cfg edit dpkg 
# just check the validity of the file, show warnings
# and suggested fixes
# does not modify the file
cfg check dpkg
# check the file, remove deprecated parameters,
# migrate data to new parameters and save
cfg migrate dpkg 
# like migrate, but also apply all suggested fixes
cfg fix dpkg 
# like migrate and modify configuration
# with command line argument
cfg modify dpkg source format="quilt (3.0)"
# access dpkg parameters through a fuse file
# system. data are saved when fs is unmounted
cfg fusefs dpkg fuse-dir
# dump configuration data in config-model format
cfg dump dpkg   
# list all available applications
cfg list 
# more general synopsis
cfg [ global_options ] command application [ options ] arguments
This synopsis use dpkg as an example, but it could be used for any of the available models (e.g. ssh, lcdproc, multistrap ). The main question I have for you is: Is cfg name good ? I mean it s short, descriptive enough. But it s also quite ugly. Does anyone have a better idea ? And what do you think of the synopsis shown above ? Are the sub-command name descriptive enough ? All the best

NeuroDebian: Chroot workaround for fslview (HOWTO)

Chroot workaround for fslview (HOWTO)
Preamble Sometimes research software lags behind developments in libraries it relies upon, because necessary changes to the code might require considerable effort, and thus time. That leads to difficulties building those tools using up-to-date library versions due API incompatibility. That is what happened with fslview from the FSL suite. Today, at the end of 2011, it still relies on Qt3 and VTK GUI support for it.

Note Last version of Qt3, 3.3.8, was released in February 2007, with official support by Trolltech terminated later that year.

Qt4 was first released in 2005, and current stable series 4.7 released appeared in September 2010.

Because of its age and discontinued upstream support, Qt3 was orphaned in Debian, and tools relying on it were encouraged to migrate to use Qt4. As a result, although Qt3 itself is still present in Debian (and thus Ubuntu), VTK GUI support for Qt3 (package libvtk5.4-qt3) which fslview uses, was removed from Debian due to Qt3 deprecation. It should be made clear that it was not removed to annoy people, but rather because it became unfeasible to maintain its robust building and functioning. So nowadays fslview is present only in those previous releases of Debian and Ubuntu which carry the libvtk5.4-qt3 library. Those are Debian squeeze (stable), Ubuntu nutty and maverick. If you upgraded your system from one of those releases, chances are that you still have fslview (and required libraries) installed although not they are not available from the APT repository anymore. Therefore fresh systems installations will not have them at all.
Workaround While everyone is waiting for a new release of fslview compatible with Qt4 there are possible workarounds to keep research going on bleeding edge Debian-based operating systems. The first, obvious choice for a FOSS enthusiast, is to build fslview from source by first building VTK Qt3 bindings, possibly after building Qt3 itself. While it might be educationally valuable and exciting, we are afraid in the end it might be more frustrating than useful. Therefore we would like to suggest another, much more straightforward and hopefully painless approach lightweight virtualization, or chroot jailing, which exists in Unix-land since 1970s. With this exercise in 4 simple steps we will install a complete (minimalistic) installation of Debian stable into a separate directory without harming the original system installation. We will provide a convenience wrapper to run fslview as if it was installed on the main system. So your system will stay intact while you would enhance it with additional software in a stable Debian environment. Moreover if security or critical fixes to any components of that installation become available, this chroot environment, being a complete Debian installation, could be as easily upgraded as your main system, thus guaranteeing robust performance. Although we demonstrate this setup with fslview in mind, such approach is generally useful for various use cases. For example, we have used it in the opposite situation on stable Debian systems we needed to run some software available only from Debian unstable or testing, and backporting of all required dependencies was either cumbersome or just impossible without sacrificing stability of the system.
Prerequisites For this exercise you would need
  • 3 20 minutes depending on the bandwidth to the Debian mirror and efficiency in cut/paste operations
  • root access to the system while performing this setup, although end-users of fslview would not need root access after everything is set up
  • 2 additional tools debootstrap to install Debian in a directory and a convenience utility schroot to enable such an environment
Procedure
  • Install the tools:

    sudo apt-get install debootstrap schroot
  • Choose a location with enough space (600 MB should be enough) and install a complete Debian squeeze installation with fslview:

    sudo debootstrap --include=fslview squeeze /srv/chroots/squeeze http://ftp.us.debian.org/debian

    Note

    You might like to adjust the URL to a Debian mirror closer to you

  • Create schroot configuration file /etc/schroot/chroot.d/squeeze with the following content:

    [squeeze]
    description=Debian squeeze (6.x stable)
    type=directory
    directory=/srv/chroots/squeeze
    users=YOURLOGIN
    aliases=debian,default
    Replace YOURLOGIN with a comma separated list of users who should be allowed to access this chroot environment (see man schroot.conf for more options, e.g. how to specify whole groups with groups=..., etc.)
  • At this point you should already be able to invoke any command within the chroot environment, so just create a little shell script /usr/local/bin/fslview, make it executable and be all set:

    echo -e '#!/bin/sh\nschroot -p -c squeeze /usr/bin/fslview "$@"' > /usr/local/bin/fslview
    chmod a+x /usr/local/bin/fslview

    Note

    You might need to become root for the above.

Optional steps Although at this point you can run fslview from the chroot-ed environment, we would suggest a few additional steps. For some of them (marked with chroot-root) you would need to become root in a chroot environment via following steps:
  • enter chroot using schroot -c squeeze -p
  • become root (via su command, root password should be the same as on the main system)
So here are recommended optional additions:
  • chroot-root: Enable NeuroDebian repository. Choose squeeze release and mirror of preference (remove sudo from provided cmdline).

  • chroot-root: Enable security and functionality updates:

    sed -e 's,squeeze,squeeze-updates,g' /etc/apt/sources.list > /etc/apt/sources.list.d/updates.list
    echo 'deb http://security.debian.org/ stable/updates main' > /etc/apt/sources.list.d/security.list
    apt-get update
    apt-get upgrade
  • Make fsl atlases accessible within the chroot environment. There are two ways and you must choose only one of them, otherwise you might damage your main system installation.

    • chroot-root: Install atlases packages in the chroot-ed environment:

      apt-get install fsl-atlases
      Although this is the best/correct way it would require additional 200MB of space, possibly duplicating what you already have installed in the main system. Also it requires enabling of NeuroDebian repository in chroot environment.
    • Alternatively you can bind-mount those directories with atlases installed on the main system within chroot. For that edit (as root on the main system) /etc/schroot/default/fstab and add following entries:

      /usr/share/fsl/data/atlases /usr/share/fsl/data/atlases none rw,bind 0 0
      /usr/share/data             /usr/share/data             none rw,bind 0 0
      You need to be aware of the potential consequences of this second approach: Any package that installs files under /usr/share/data will modify files in the same directory outside the chroot as well. If you don t want to risk that don t use this method and simply install the necessary data packages inside the chroot environment too, as describe before.

      Note

      Similarly you can bind-mount any other directory you would like to make visible in chroot. Just be careful to not overlap with system directories in chroot which already carry something.

Also you might like to read man schroot on how to enable persistent sessions so that chroot initiation could be done ones during boot instead of per each fslview invocation If you have any comments (typos, improvements, etc) feel welcome to leave a comment below, or just email us@NeuroDebian .

Simon Josefsson: Small syslog server

My home network has several devices that do not have large persistent storage to keep log files. For example, my wireless routers based on OpenWRT doesn t log to the limited local storage it has, and a Flukso energy metering device log power readings to a ramdisk. These devices log a fair amount of information that I ideally would like to keep for later analysis. I have never before seen a need to setup a syslogd server, thinking that storing logs locally and keeping regular backups of the machine is good enough. However, it appears like this situation calls for a syslogd server. I found an old NSLU2 in my drawer and installed Debian Squeeze on it following Martin Michlmayr s instructions. I m using a 4GB USB memory stick for storage, which should hold plenty of log data. I keep backups of the machine in case the USB memory stick wears out. After customizing the installation to my preferences (disable ssh passwords, disable portmap/rpc.statd/exim4, installing etckeeper, emacs23-nox, etc) I am ready to configure Rsyslog. I found what looked like the perfect configuration example, Storing messages from a remote system into a specific file , but it requires me to hard code a bit too much information in the configuration file for my taste. Instead, I found the DynFile concept. With a file /etc/rsyslogd.d/logger.conf as below I can point any new device to my log server and it will automatically create a new file for it. And since the dates are embedded into the filename, I get log rotation suitable for rsync-style backups for free.
$ModLoad imudp
$UDPServerRun 514 $ModLoad imtcp
$InputTCPServerRun 514 $template DynFile, /var/log/network-%HOSTNAME%-%$year%-%$month%-%$day%.log
:fromhost-ip, !isequal, 127.0.0.1 ?DynFile
:fromhost-ip, !isequal, 127.0.0.1 ~

flattr this!

Christian Perrier: Defoma removal

Thanks to the longstading work by Paul Wise in nearly 3 years...and with some help from my side (and from other members of the font packaging team), we're getting closer of a longstanding goal : removing Defoma from the archive. Defoma is indeed obsoleted by fontconfig, which doesn't need these "hints" file, turning the packaging of fonts into a very simple process. On last Saturday, Paul sent the removal request for defoma. The request mentions blocking bugs that are, for most of them, requests for font packages to drop the dependency on defoma. As we already sent patches for these bugs, I started NMU'ing the remaining packages this week-end. Most of them were apparently nearly abandoned packages, so I had no shame doing that so quickly. Indeed, I no longer fear NMU'ing packages even for non critical issues and I even sometimes no longer fear adding a few other fixes when the packages are very obviously poorly maintained (things like source v3, debhelper compatibility bump, build- indep arch targets support, etc.). After this NMU wave, we should be left, in one week, with only five packages blocking the removal of defoma. I might even NMU some of them, though some are TeX-related packages providing T1 fonts additionnally to TrueType ones...something I'l less familiar with. Whatever happens, I now nearly sure that wheezy will not have defoma. Yay! Hats off to Paul.

Cyril Brulebois: Fixing synaptics on powerpc

(It s a new day, it s a new bug ) A regression appeared in the synaptics input driver, between the 1.4.1 and the 1.5.0 release, as reported in Debian #649002 by many users. Basically, no more touchpad on PowerPC (hi, iBook G4 users!). :-( What follows is how I tracked it down. The upstream bug report is fdo#43728. Anyone could have done so, there s no black magic involved. A little hint maybe: git bisect is really easy on X drivers, since one can build and test without the Debian packaging bits. 1st step: Getting started You need sources and build dependencies, nothing fancy. Since packages might be named a bit differently, there s a reference to the relevant upstream repositories in debian/watch for X packages.
# You need git here:
debcheckout xserver-xorg-input-synaptics synaptics.git
cd synaptics.git
# Let s get the upstream tags and branches:
cat debian/watch
git remote add upstream git://anongit.freedesktop.org/xorg/driver/xf86-input-synaptics
git fetch --all
# Let s install build dependencies:
sudo apt-get build-dep xserver-xorg-input-synaptics
2nd step: Reproducing It was said 1.5.0 was the first known buggy version, so let s make sure:
# Get the appropriate tag:
git checkout xf86-input-synaptics-1.5.0
# Prepare the build system:
autoreconf -vfi
# X finds its modules under /usr, not /usr/local:
./configure --prefix=/usr
# Build and install:
make && sudo make install
Now time to restart the display manager, and confirm that the pointer is not moving bug reproduced. Now let s check the 1.4.1 release isn t affected:
# Clean everything:
git clean -xdf
git checkout xf86-input-synaptics-1.4.1
autoreconf -vfi
./configure --prefix=/usr
make && sudo make install
And after a display manager restart, the pointer is moving again, good! For reference, the log has very different lines about appletouch, so it can be used to programmatically learn about the status (good or bad). 3rd step: Narrowing it down So, we have a known good version and a known bad version. Time for a binary search to find the guilty commit which introduced that regression!
git bisect start
git bisect good xf86-input-synaptics-1.4.1
git bisect bad  xf86-input-synaptics-1.5.0
You don t even need to know that 1.4.x and 1.5.x live in different branches, git figures that out for you:
Bisecting: a merge base must be tested
[de0dfb76444ad4160468d00515876c91a9fa20bf] synaptics 1.4.0
It s just a matter of running autoreconf && ./configure && make && sudo make install && sudo /etc/init.d/xdm restart every step of the way, so it s pretty easy. No wonder, 1.4.0 was working OK, so it can be recorded as such through git bisect good, and the binary search goes between that commit and 1.5.0. After a few iterations of git bisect good and git bisect bad, we get to the commit reported on the upstream bug. As an extra bonus, mentioning the upstream bug number/URL in the Debian bug means it can be marked as forwarded there and we ll receive automatic notifications when its status changes, thanks to bts-link. Now, if you want to provide a patch for this bug, you may want to try and revert this commit. 4th step: Providing a patch Let s go back to the affected release and try to revert the guilty commit:
git checkout xf86-input-synaptics-1.5.0
git revert 13543b156d78bc4d01a19844a5ee8f283269621b
Unfortunately, some later commits modified the affected areas so we re running into conflicts:
error: could not revert 13543b1... eventcomm: replace synaptics-custom TEST_BIT with server's BitIsOn.
hint: after resolving the conflicts, mark the corrected paths
hint: with 'git add <paths>' or 'git rm <paths>'
hint: and commit the result with 'git commit'
Let s try to understand what the offending commit did: it replaced a set of macros with a single one, taken from the server. Both the old TEST_BIT() and the new BitIsOn() take 2 arguments, but the order is reversed. Reverting it should only be a matter of introducing the TEST_BIT() macro again (along with the two other ones it needs), and using it. The problem is replacing all BitIsOn(foo,bar) with TEST_BIT(bar,foo): foo and bar might not be trivial, they could be complex C expressions, and a replacement in your favourite editor might not get all occurrences right. Thankfully, there s a nice tool to handle such things, called coccinelle. I won t go into details, just show how it can help here. Basically you just need to craft a tiny patch, called a semantic patch, which describes what I wrote in the previous paragraph. You only need to declare two expressions, say a and b, and declare that all BitIsOn(a,b) must be replaced with TEST_BIT(b,a). Here s the syntax:
@@
expression a,b;
@@
-BitIsOn(a,b)
+TEST_BIT(b,a)
Save it under testbit.cocci and apply it through spatch (from the coccinelle package), asking it to perform in-place replacement (we re in a git checkout copy, remember):
# Apply:
spatch -sp_file testbit.cocci -in_place .
# Profit:
git diff
Then you can run git commit -s, write a nice commit message, send it upstream, and enjoy the rest of the night. Coming soon to a mirror near you: fixing commit. As mentioned on the upstream bug report, I got the Debian reference wrong in the commit message, I really meant #649002.

11 December 2011

Phil Hands: One Month

... since we got married -- a great month :-) wedding photo and one month until Gunde's expected to give birth to our first daughter. So exciting times ahead.

Stefano Zacchiroli: bits from the DPL for November 2011

Mako's IronBlogger is a great idea. I often find myself postponing blog posts for a very long time, simply out of laziness. IronBlogger provides a nice community incentive to counter (my) laziness and blogging more often. As a related challenge, we have to face the fact that different subsets of our communities use different media to stay informed: mailing lists, blog (aggregators), social media, IRC, etc. Disparities in how they stay informed are a pity and can be countered using multiple medias at a time. Although I haven't blogged very often as of lately, I managed to keep the Debian (Developer) community informed of what happens in "DPL land" on a monthly basis, by the means of bits from the DPL mails sent to d-d-a. While the target of bits mails perfectly fits d-d-a, there is no reason to exclude a broader public from them. After all, who knows, maybe we'll find the next DPL victim^W candidate among Planet readers! Bonus point: blogging this also helped me realize that my mails are not as markdown-clean as I thought they were. I still have no IronBlogger squad, though. (And sharing beers with folks in the Boston area is not terribly handy for me ). Anyone interested in setting up a BloggeurDeFer in the Paris area? (SCNR)
Dear Project Members,
another month has passed, it's time to bother you again about what has happened in DPL land in November (this time, with even less delay than the last one, ah!). Call for Help: press/publicity team I'd like to highlight the call for help by the press / publicity teams. They are "hiring" and have sent out a call for new members a couple of weeks ago. The work they do is amazing and is very important for Debian, as important as maintaining packages or fixing RC bugs during a freeze. It is only by letting the world know what Debian is and what we do, that we can keep the Project thriving. And letting the world know is exactly what the publicity and press teams do. If you're into writing, blogging, or simply have a crush for social media, please read the call and "apply"! Interviews November has apparently been the "let's interview the DPL" month. I've spent quite some time giving interviews to interested journalists about various topics. For both my embarrassment and transparency on what I've said on behalf of Debian, here are the relevant links: Assets Legal advice (work in progress) Relationships with others Miscellanea Thanks for reading thus far,
and happy hacking.
PS as usual, the boring day-to-day activity log is available at master:/srv/leader/news/bits-from-the-DPL.*

Gregor Herrmann: RC bugs 2011/49

a quiet RCBW week, here's the usual status report:

Amaya Rodrigo: Biggest of them all


Biggest of them all
Originally uploaded by Amayita.
And what the heck bumped into that? :)

Via Flickr:
Tomares, Seville

Christian Perrier: New update about Debian Installer localization

Czech back to 100% in level 1 and 2, thus joining the hall of fame of full completeness. Dutch completes level 2 and also reaches the hall of fame. I take this as a specific wish for Frans Pop memory. Korean and Marathi complete level 1. Full stats are here Status for D-I level 1 (core D-I files): Status for D-I level 2 (packages that have localized material that may appear during default installs, such as iso-codes, tasksel, etc.): Status for D-I level 3 (packages that have localized material that may appear during non-default installs, such as win32-loader) So, full 100% completeness (hall of fame) for: Czech, Dutch, German, Persian, French, Portuguese, Russian, Slovak

Cyril Brulebois: Fixing libdrm for intel

If you re having issues with video playback in unstable on Intel hardware, this post is for you. Some buffer freeing code was added in libdrm 2.4.28 to try and fix exhaustion of per-process limits. Some safeguards (assert()) were put in place to see whether some other components needed fixing (like unbalanced map()/unmap()). It s hard to miss those, since the server crashes when something s wrong. Good news: for affected users, downgrading to libdrm 2.4.27 (currently available in testing) should restore a functional setup. So far, patches have floated around for libva[1], xserver-xorg-video-intel[1,2] and libdrm[1,2,3] itself. Since libdrm has already been exposed to a wide audience for a while, a new upstream release is planned in a few days, disabling those assert()s. Other packages will then have some extra time to get new releases with the appropriate patches.

10 December 2011

Patrick Schoenfeld: Migrating from blogspot to Movable Type

A while ago I decided to migrate my existing blogspot blog to an own domain and webspace again. My reasoning was mostly, that blogspot lacked some features, which I'd like to have in my blog.
Additionally, my requirements have changed a bit since I originally moved to blogspot and, last but not least, Blogspot was a compromise anyway.

So I started re-evaluating a possible software platform for my blog. In my numerous previous attempts to start blogging (there were several blogs of me in the internet since at least 2006), before I moved to Blogspot, I used Wordpress. But there were quiet some reasons against it, one of the biggest concerns being its security history. Also, while I worked a lot with PHP in the past years, I have developed a serious antipathy against software written in PHP, which I couldn't just ignore.

In the end, the decision fell on Movable Type, because its written in Perl, which is the language I prefer for most of my projects, because its features were matching my wishes (mostly) and because I heard some good opinions about it. Also it is used by my employer for our company blog.

So the next question was: How to migrate?

I decided to use Movable Type 5, although, at present, it seems not to be the communities choice. At least the list of plugins supporting MT5 is really short. Foremost there was no plugin to import blogger posts, which, after all, was the most important thing about the migration.
Luckily there is such a plugin for Movable Type and so I basically did the following:

  1. Install Movable Type 4
  2. Install the Blogger Import Plugin
  3. Import posts (it supports either the export file of blogger or directly importing posts via the Google API)
  4. Upgrade to Movable Type 5
  5. Check the result
Check the results, or: The missing parts

Obviously such an import is not perfect. Some posts contain images or in-site links. The importer is not able to detect that and honestly it would have a hard time to track that anyway.
So as soon as content is migrated, its time to look for the missing parts.

The process to find missing parts is basically very easy and common among the various missing parts:
Just search for your blogspot URL via the Search & Replace option in the Movable Type administration.

Now how to fix that? For links its quiet easy (although I forgot about them in the first run), as long as the permalinks have kept the same scheme.
In my case that is the case, since I decided to use the Preferred Archive option "Entry" in the blog settings for the new blog and the default (if there is an option, because I don't know)
in Blogspot. The importer does import the Basename of the document, so fixing links is just a matter of replacing the domain part of the URL.

For images its some more work. One has to get the images somehow and upload them in Movable Type. Eventually it then boils down to search and replace, but I decided to do that manually, since I only have a very low number of images in my posts so far.

After that I did everything else, which is not specific to the migration, like picking a template, modifying it to my wishes, considering the additions of plugin etc.
And here we are. There were some issues during the migration, which I haven't handled here. I will blog about them another time.

Tim Retout: SFTP default umask

So I was about to configure an FTP server to let a friend upload content for a website... and then I came to my senses and remembered sftp exists. It's supported by the same graphical clients, and avoids me having to figure out SSL certificates and so on. Next problem: we want to both edit the site. Okay, so I create a group, make it the default group for both users... and now I need to set the umask to 002 so that all group members can edit all files. There's no option in the client... Skimming Debian bug #496843 (closed Apr 2010, thanks Colin Watson!) we can set this in sshd_config these days - no need to mess about with wrapper scripts. Very easy:
Subsystem sftp /usr/lib/openssh/sftp-server -u 002
Now all content created through the sftp client is group-writable, and owned by the default group of each user! See 'man (8) sftp-server'.

Patrick Schoenfeld: On Debian discussions

In my article "Last time I've used network-manager" I made a claim for which I've been criticized by some people, including Stefano, our current (and just re-elected) DPL. I said that a certain pattern, which showed up in a certain thread, were a prototype for discussions in the Debian surroundings.

Actually I have to commit, that this was a very generalizing statement, making my own point against the discussion point back directly at myself.
Because as Stefano said correctly there has been some progress in the Debian discussion cult.
Indeed, there are examples of threads, were discussions followed another scheme.
But to my own advocacy I have to say that such changes are like little plants (in the botanical sense). They take their time to grow and as long as they are so very new, they are very vulnerable to all small interruptions. Regardless of how tiny those interruptions may seem.

I've been following Debian discussions for 6 or 7 years. That scheme I was describing was that which had the most visibility of all Debian discussions. Almost every discussion which were important for a broader audience followed that scheme. It has a reason that Debian is famous for flamewars.
In a way its quiet similar to the network-manager perception, some people have. Negative impressions manifest themselves. Especially if they have years of time.
Positive impressions does not have a chance to manifest themselves as long as the progress is not visible enough to survive small interruptions.

I hope that I didn't cause to much damage with my comment, which got cited (context-less) on other sites. Hopefully the Debian discussion cult will improve further to a point where there is no difference between the examples of very good, constructive discussions we already have in some parts of the project and the project-wide decision-making-discussions which affect a broad audience and often led to flamewars.

Patrick Schoenfeld: PHP and big numbers

One would expect, that one of the most used script languages of the world would be ableto do proper comparisons of numbers, even big numbers, right?Well, PHP is not such a language, at least not on 32bit systems.Given a script like this:
<?
$t1 = "1244431010010381771";
$t2 = "1244431010010381772";
if ($t1 == $t2)
print "equal\n";
?>

A current PHP version will output:

schoenfeld@homer ~ % php5 test.php
equal

It will do the right thing on 64bit systems (not claiming that the numbers are equal).Interesting enough: An equal-type-equality check (see my article from a few years ago) will not tell that the two numbers are equal.

Patrick Schoenfeld: The caravan is moving on..

I once moved to blogspot with my blog, because I was to lazy to handle all the hard stuff about blogging (finding, setting up and maintaing a blog software) myself. It was a compromise, back then, because blogspot was missing features I'd like to have from a blog software.
Recently the compromise was slowly going to not satisfy me enough anymore and so I planned and executed a migration plan to an own domain and powered by Movable Type.

Because I was always blogging about more technical and Open Source-community related things as well as private stuff, politics and anything else, which I was interested about, and because these subject areas are not really related to each other, I decided to split the blog into two.

So in the future you will find this blog split into two places:

I've tried to migrate everything to this sites, which has been on blogspot, including comments. So if you happen to find your comments there: Do not wonder.

The blogspot blog will stay around, eventually forever, eventually only for a certain time, to let search engine visitors still find stuff. But this is the last entry I'll publish here.

So update your bookmarks and stay tuned :)

9 December 2011

Andrew Pollock: [life/americania] Six years in the US

Late last month our six year anniversary of moving to the US quietly came and went. This also makes it six years with Google. I think if you had have told me at the start of 2005, that I'd be ending the year off by starting a six year (and counting) stint in Silicon Valley, I wouldn't have believed you. Six years is comfortably the longest I've spent in any one place since I moved out of home (the four years living at the Central Park Apartments was the longest I've spent in any one home, also). Six years is also far and away the longest time I've stayed with one employer. I wonder what life will be like in another six years' time?

Julian Andres Klode: Combining ikiwiki and Twitter s bootstrap

Just because Julien did it, I moved my website to almost the same design now. Still using ikiwiki, of course. I m still missing a few things, such as marking the currently active page in the menu, but I hope to get that done as well soon. Go to http://jak-linux.org/ to see it.
Filed under: General

C.J. Adams-Collier: xend xml parsing failure solution

I got this error when starting xend after a filesystem crash: [2011-12-09 11:05:04 5590] ERROR (SrvDaemon:349) Exception starting xend (not well-formed (invalid token): line 3, column 0) It sounded like an XML parsing error, but the stack trace in the log didn t say which file it had loaded. It turns out that it was trying to load something from /var/lib/xend/state/. Purging the /var/lib/xend/state directory fixed the problem, and hopefully had no side-effects. Thanks to this blog for the solution. I should probably file a bug, shouldn t I? [edit] done: http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1797

Christian Perrier: 10 years being Debian Developer - part 5: being a newbie DD...and working on l10n

I left you 2.5 months ago with the last question asked by my applicaiton manager, Martin Michlmayr : "Please tell me about about yourself and what you intend to do for Debian". Interesting question to revisit now, indeed. Here is what I answered: About myself first. I'm a 40 year old project manager and system administrator working in French National Aerospace Research Center. My best definition of my skills in computing is "Know more or less about a Lot of Things and be a Specialist of Nothing"...:-). I'm definitely not a programmer, nor a real system administrator, nor a RDBMS administrator, nor a personal workstation designer, though I do all of these daily. I think I'm perfect for finding the good person for having a defined job done. Besides this, I'm a genealogist for several years now. This is what finally decided me to apply for becoming a package maintainer : there are some quite good free genealogy software for Unix, though for various reasons they are not used very widely, even Unix geeks (my main software for genealogy still runs on Another Operatin System and is evertythig but free).I think that I can bring something here to the Free Software World, by helping some of these good programs in getting into the best Linux distribution I know.... For me, this is a mean for giving back to the free software movement what I gives to me since I discovered Linux 6-7 years ago. My very first intention as soon as I get my way into the Debian Developers Heaven is adopting the Geneweb package currently maintained by Brent Flugham. I'm in close contact with the author (who happens to be french, which helps) as well as a daily user of it. The current package which is in the distribution is already my work for a great part. I gave it to Brent, the current maintainer and we both agreed that it would be better for me to apply to becoming anofficial maintainer. I also contributed to the package for lifelines, another genealogy software. The last version of the package is also 80% my work, acknowledged by Javier, the official maintainer. Concerning that package, I do not have "plans" for adopting it (we didn't discussed of this with Javier, and I'm not sure I could bring him that much things). I came to Linux thanks to a great friend of mine, Ren Cougnenc. Ren opened my eyes to the free software world when I still thought that it was only a variant of free beers. I got really involved into Linux when I forced me to remove any other Operating System from my computer at work and tried to do my daily job with Linux. I have now succeeded at ONERA in getting free software to be accepted as a credible alternative for important projects. At this time, especially for server and network-related projects. I absolutely cannot tell why and how I came to be a Debian user. I simply don't remember. But I know why I am still a Debian user : this is a distribution which is controlled by only one organisation--->its users. And I want to be part of it. Finally, I did not mention above the somewhat "political" nature of my personal involvment into free software. Except for the physical appearence, I think I mimic RMS on several points (though he probably speaks better french than I try to speak english....which does not help for expressing complex ideas like the ones above!). As anyone can see, I was already very verbose when writing, sorry for this. Funnily Martin summed this up in one paragraph when he posted his AM report about my application. From what I see, also, my English didn't improve that much since then. It seems this is a desperatecause, I'm afraid. Anyway, all this was apparently OK for Martin and, on July 21st 2001, he wrote and posted his AM report and, on July 30th 2001, I got a mail by James Troup: An account has been created for you on developer-accessible machines with username 'bubulle'. bubulle@debian.org was born. Now I can more easily destro^W contribute to my favourite Linux distro. Indeed, I don't remember that much about the 2001-2003 years. I was probably not that active in Debian. Mostly, I was maintaining geneweb, for which I polished the package to have it reach a quite decent state, with elaborated debconf configuration. Indeed, at that time, I was still also deeply involved in genealogy research and still contributing to several mutual help groups for this. This is about the time where I did setup my web site (including pages to keep the link with our US family, which we visited in 2002). I think that the major turn in my Debian activities happened around september 2002 when Denis Barbier contacted me to add support in geneweb for a new feature he introduced in Debian : po-debconf. At that time, I knew nearly nothing about localization and internationalization. Denis was definitely one of the "leaders" in this effort in Debian. During these years, he did a tremendous job setting up tools and infrastructure to make the translation work easier. One of his achievements was "po-debconf", this set of tools and scripts that allows translation debconf "templates", the questions asked to users when configuring packages. All this lead me to discover an entire new world : the world of translating software. As often when I discover something I like, I jumped into it very deeply. Indeed, in early January 2003, I did my very first contributions to debian-l10n-french and began working on systematic translation of debconf templates. Guess what was the goal : 100%, of course! Have ALL packages that have debconf templates...translated to French. We reached that goal.....on June 2nd 2008 in unstable (indeed "virtually" : all packages were either 100% translated...or had a bug report with a complete translation) and on December 21st 2010 for testing. Squeeze was indeed the first Debian release with full 100% for French. Something to learn with localization work: it's never finished and you have to be patient. So, back in 2003, we were starting this effort. Indeed, debian-l10n-french was, at that time, an incredibly busy list and the translation rate was very high: I still remember spending my summer holidays translating 2-3 packages debconf templates every day for two weeks. Meanwhile, my packaging activities were low: only geneweb and lifelines, that was all. Something suddenly changed this and it has been the other "big turn" in my Debian life. After summer 2003, I suddenly started coming on some strange packages that were needing translation: they were popping up daily in lists with funny names like "languagechooser", "countrychooser", "choose-mirror", etc. I knew nothing about them and started "translating" their strings too, and sending bug reports after a decent review on debian-l10n-french. Then, Denis Barbier mailed me and explained me that these things were belonging to a new shiny project named Debian Installer and meant to replace the good old boot-floppies. Denis explained me that it would maybe be more efficient to work directly in the "D-I" team and "commit" my work instead of sending bug reports. Commit? What's that? You mean this wizard tool that only Real Power Developers use, named "CVS"? But this is an incredibly complicated tool, Denis. Do you really want me, the nerd DD, to play with it? Oh, and in this D-I development, I see people who are close to be semi-gods. Names I read in mailing lists and always impress me with their Knowledge and Cleverness: Martin Michlmayr (my AM, doh), Tollef Fog Heen, Petter Reinholdtsen and so many others and, doh, this impressive person named "Joey Hess" who seems to be so clever and knowledgeable, and able to write things I have no clue about. Joey Hess, really? But this guy has been in Debian forever. Me, really? Work with the Elite of Debian? Doh, doh, doh. Anyway, in about two months time, I switched from the clueless guy status to the status of "the guy who nags people about l10n in D-I", along with another fellow named Denny "seppy" Stampfer". And then we started helping Joey to release well localized D-I alphas and betas at the end of 2003 (the release rate at the time was incredible: Sarge installer beta1 in November 2003, beta2 in January 2004). I really remember spending my 2003 Christmas holidays hunting for....100% completion of languages we were supporting, and helping new translators to work on D-I translation. Yes, 8 years ago, I was already doing all this..:-)...painting the world in red. All this leads up to the year 2004. Certainly the most important year in my Debian life because it has been....the year of my first DebConf. But you'll learn about this....in another post (hopefully not in 2.5 months).

Next.

Previous.