Search Results: "xam"

9 March 2009

Ingo Juergensmann: IPv6 connectivity

I got an IPv6 tunnel/subnet during the weekend and set it up. So, for everyone who's visiting my blog or Buildd.Net can do this via IPv6 now. At least when I've not broke it again in the meantime. ;)

Sadly it's not a native IPv6 connectivity because the hosting company want charging me an extra amount of 29.- for that. Given the fact that the IPv4 Exhaustion Counter says that the IPv4 might be running out in 763 days, I don't think that this kind of extra charging will speed up the transition to IPv6.



Anyway, when you encounter problems in accessing my sites via IPv6, please drop me a note! For example I still need to setup rDNS and email... but http should work now - except for my SSL sites... but maybe that's a different story...

8 March 2009

Lucas Nussbaum: Make, tmpfs, and [amc]time granularity

As you might have guessed (or not), I ve been playing with the idea of improving my Debian rebuild setup by building on tmpfs: disk I/O take a signifiant amount of time, that could easily be reduced by building (mostly) in memory. Most packages build fine on tmpfs: only 8 packages fail only on tmpfs. Apparently, most of the failures are caused by old versions of autoconf: this version used /tmp to store temporary files ; for example, when generating Makefile, it would create it on /tmp, then move it to the current directory. The problem arises when /tmp is an ext3 filesystem, while the current directory is on tmpfs: when moving the file back to the current directory, the mtime of the file is truncated. This can lead make to think that a given target needs to be rebuilt. A nice example of that is the smuxi package, that just loops when building. Demo: 
# cat Makefile
f2: f1
        echo "Need to rebuild f2!"
First case: f1 and f2 are stored in the current directory. Make agrees that
f2 was created after f1: 
# rm f1 f2 ; touch f1 ; touch f2 ; make
make:  f2' is up to date.
Second case: f2 is created on /tmp, then moved to the current directory. Make thinks that f2 was created before f1 (and is right, according to stat). 
# rm f1 f2 ; touch f1 ; touch /tmp/f2 ; mv /tmp/f2 f2 ; make
echo "Need to rebuild f2!"
Need to rebuild f2!
# stat f1 f2
  File:  f1'
[..]
Modify: 2009-03-08 18:21:08.900237000 +0100
  File:  f2 
[..]
Modify: 2009-03-08 18:21:08.000000000 +0100

Russell Coker: The FAIL Meme

One of the recent poor trends in mailing list discussions is to reply to a message with a comment such as FAIL or EPIC FAIL . The FAIL meme has been around for a while and actually does some in some situations, slate has a good article about it [1]. The first example cited in that article is that when Ben Bernanke and Henry Paulson testified before the Senate banking committee last month about Paulson s proposed bailout bill, a demonstrator in the audience held up an 8.5-by-11 piece of paper with one word scrawled on it in block letters: FAIL. . This is an effective form of political demonstration, short words generally work well on placards (if only because the letters can be larger and therefore read from a greater distance) and anyone can understand the meaning of FAIL in that context. There are some blogs dedicated to publicising supposed failures, failblog.org and ShipmentOfFail.com are two examples. I cite these as supposed failures because some of the pictures that they contain are obviously staged. It s basically an Internet equivalent of the Funniest Home Videos shows that I never watched because they were not particularly funny. So using the word FAIL on it s own can be an effective form of political protest and can be used for mildly amusing web sites. But where it falls down is when it s applied to a discussion that involves people who are from different cultures or have different levels of background knowledge - which covers most mailing list discussions. Something that might be obviously wrong to some people is often not obvious at all to others. For example being forced to reboot a computer for any reason other than a kernel upgrade seems obviously wrong to me (and to most people who use Linux or other Unix systems) but Windows users seem happy to reboot machines after applying patches or upgrades. So writing a message with FAIL as the only word in a discussion with Windows users would not be productive. It could however be reasonable to forward a link to a page on a Microsoft web site to Linux people for their amusement with FAIL as the only comment - anyone who would find the link in question amusing would require no more explanation. Sometimes when in a debate someone will write a message that only says FAIL , this is a very unconvincing argument that will not convince the opposition or any onlookers. Generally it seems that using FAIL in a discussion with other like-minded people when talking about someone outside your group for the purpose of amusement can be effective. But any other use is going to be a FAIL . As a more general rule single-word messages seem to have little value apart from certain limited situations. I have identified the following seven scenarios where a single word message is useful. Can anyone think of any others?

  1. Code review - someone posts code (or design for code) and people who like it will write ACK or something similar.

  2. Arranging a meeting - the question who wants to meet for lunch tomorrow has me as a valid answer.

  3. Voting - yes and no are valid answers for a poll, but a mailing list or forum probably isn t the best place for it.

  4. Citing an example to refute a claim - often a single word won t be a great response but may be adequate to prove a point.

  5. Answering a request for a recommendation - if asked to recommend a laptop I might say Thinkpad or if asked to recommend a server I might say HP . Both those answers are poor (I recommend EeePC for netbooks and Dell for small/cheap servers), so while such an answer would be useful it would be below my usual quality standards for email (I prefer to write at least two paragraphs explaining why I recommend something).

  6. Informing people that something has been done by replying to a request with the word Done .

  7. Agreeing to a contract or proposal with OK or Yes .

Update: I added another two reasonable uses of single word messages,

7 March 2009

Lucas Nussbaum: Wysiwyg tool to create simple websites?

Hi, I m looking for a tool to create simple websites (5-10 pages), only static content (no PHP). Think of the typical small business or sports club website: text + pictures about what they did/do, nothing really complex. Requirements:
  • usable by a non-programmer who doesn t want to know about gory technical details (HTML, CSS, etc)
  • doesn t make it too hard to create a website with a few pages (i.e it should do a bit more than just allowing to create one page)
  • built-in support for (S)FTP uploading of the website, usable by a non-programmer after someone computer-litterate will have set it up. (that s not an absolute requirement, but would still be nice to have. also, what are the nice graphical tools to do that, currently?) I m asking for two different persons with different needs. So please don t limit your replies to free software (although it would be nice): cheap proprietary applications might be adequate as well. Regarding platform, Linux, Mac OS X or Windows would all be suitable. I don t think that a CMS is the right tool here: the focus should be put on the content (which won t be often modified anyway) and its presentation, not on the ease of modification. For example, I d like to be able to position pictures in a precise way. However, I might be interested in a CMS that is:
  • easy to setup (for a reasonably computer-literate person)
  • extremely easy to learn (a couple hours at most, for a non-programmer)
  • easy to transform into something that looks good In your comments, it would be great if you could include examples of what you did with those tools (yes, links are welcomed!) Thank you.

    • 6 March 2009

    Robert McQueen: This is a local mail for local people, we ll have no trouble here!

    all programs that interact with e-mail are broken in one way or another. Please be careful. - Lars Wirzenius
    I seem to have a cunning knack of finding problems with configuring server software, particularly involving e-mail, where a) I can t find answers in Google, b) most people I go and ask for help say they d usually ask me such things, and c) if I go onto IRC or mailing lists I end up helping other people and not getting any help with my problem. It s quite likely this is just because I m something of a perfectionist, so the ridiculous crappy hacks people come up with and seem content to entrust their mail to are unacceptable to me for one reason or another. Anyway, in my ongoing quest for the perfect mail system, I ve painted myself into a corner again. (I m currently running with postfix, postgrey, clamav-milter, dspam, dovecot using LDA, managesieve and the cmusieve & antispam plugins. If I can get the current incarnation working, I ve had enough requests to write up a full HOWTO, and seen enough around with pretty questionable content, that I ll probably do it before too long.) I ve got postfix s local transport configured to hand mail to dspam over LMTP, using mailbox_transport = lmtp:unix:/dspam/dspam.sock. dspam is configured to listen here, add X-DSPAM-Result and signature headers, and then deliver the mail with dovecot s deliver LDA (which I ve set to 4750 root:dspam). From dspam.conf: ServerParameters "--deliver=innocent,spam -d %u"
    ServerDomainSocketPath "/var/spool/postfix/dspam/dspam.sock"
    ...
    Preference "spamAction=tag"
    Preference "signatureLocation=headers"
    ...
    TrustedDeliveryAgent "/usr/lib/dovecot/deliver"     My dovecot configuration is pretty standard, using PAM for both passdb and userdb, and provides the auth-master socket that deliver needs. The problem I have is that postfix s local transport is qualifying the local username with the FQDN of the machine before delivering it to dspam with LMTP (the local mail transfer protocol), even for locally-originated mail which was only addressed with a bare username! dspam doesn t mangle it or care if the user is local or not, and then cheerfully invokes deliver -d robot101@omega.example.co.uk, which returns EX_NOUSER (addressee unknown) because my username is just robot101. From mail robot101: Mar 6 02:25:40 omega postfix/pickup[13607]: DAA4942F41F: uid=1000 from=<robot101>
    Mar 6 02:25:40 omega postfix/cleanup[13637]: DAA4942F41F: message-id=<20090306022540.DAA4942F41F@omega.example.co.uk>
    Mar 6 02:25:40 omega postfix/qmgr[12552]: DAA4942F41F: from=<robot101@omega.example.co.uk>, size=339, nrcpt=1 (queue active)
    Mar 6 02:25:40 omega dovecot: auth(default): passwd(robot101@omega.example.co.uk): unknown user
    Mar 6 02:25:40 omega dspam[13527]: Delivery agent returned exit code 67: /usr/lib/dovecot/deliver -d robot101@omega.example.co.uk
    Mar 6 02:25:40 omega postfix/lmtp[13640]: DAA4942F41F: to=<robot101@omega.example.co.uk>, orig_to=<robot101>, relay=omega.example.co.uk[/dspam/dspam.sock], delay=0.08, delays=0.05/0.01/0.01/0.03, dsn=4.3.0, status=deferred (host omega.example.co.uk[/dspam/dspam.sock] said: 421 4.3.0 <robot101@omega.example.co.uk> Delivered (in reply to end of DATA command))     So, no e-mail for me. Dearest lazyweb, which of the three components is behaving wrongly, and how can I fix it? (And no, I m not just going to switch to GMail. I store my data on hard drives, which are sometimes in servers, not in the cloud . Until about a month ago, most people I knew spoke about clouds which were made of particles of water in the sky, rather than as a data storage media. What if it rains? ;)

    Robert McQueen: This is a local mail for local people, we ll have no trouble here!

    all programs that interact with e-mail are broken in one way or another. Please be careful. - Lars Wirzenius
    I seem to have a cunning knack of finding problems with configuring server software, particularly involving e-mail, where a) I can t find answers in Google, b) most people I go and ask for help say they d usually ask me such things, and c) if I go onto IRC or mailing lists I end up helping other people and not getting any help with my problem. It s quite likely this is just because I m something of a perfectionist, so the ridiculous crappy hacks people come up with and seem content to entrust their mail to are unacceptable to me for one reason or another. Anyway, in my ongoing quest for the perfect mail system, I ve painted myself into a corner again. (I m currently running with postfix, postgrey, clamav-milter, dspam, dovecot using LDA, managesieve and the cmusieve & antispam plugins. If I can get the current incarnation working, I ve had enough requests to write up a full HOWTO, and seen enough around with pretty questionable content, that I ll probably do it before too long.) I ve got postfix s local transport configured to hand mail to dspam over LMTP, using mailbox_transport = lmtp:unix:/dspam/dspam.sock. dspam is configured to listen here, add X-DSPAM-Result and signature headers, and then deliver the mail with dovecot s deliver LDA (which I ve set to 4750 root:dspam). From dspam.conf: ServerParameters "--deliver=innocent,spam -d %u"
    ServerDomainSocketPath "/var/spool/postfix/dspam/dspam.sock"
    ...
    Preference "spamAction=tag"
    Preference "signatureLocation=headers"
    ...
    TrustedDeliveryAgent "/usr/lib/dovecot/deliver"     My dovecot configuration is pretty standard, using PAM for both passdb and userdb, and provides the auth-master socket that deliver needs. The problem I have is that postfix s local transport is qualifying the local username with the FQDN of the machine before delivering it to dspam with LMTP (the local mail transfer protocol), even for locally-originated mail which was only addressed with a bare username! dspam doesn t mangle it or care if the user is local or not, and then cheerfully invokes deliver -d robot101@omega.example.co.uk, which returns EX_NOUSER (addressee unknown) because my username is just robot101. From mail robot101: Mar 6 02:25:40 omega postfix/pickup[13607]: DAA4942F41F: uid=1000 from=<robot101>
    Mar 6 02:25:40 omega postfix/cleanup[13637]: DAA4942F41F: message-id=<20090306022540.DAA4942F41F@omega.example.co.uk>
    Mar 6 02:25:40 omega postfix/qmgr[12552]: DAA4942F41F: from=<robot101@omega.example.co.uk>, size=339, nrcpt=1 (queue active)
    Mar 6 02:25:40 omega dovecot: auth(default): passwd(robot101@omega.example.co.uk): unknown user
    Mar 6 02:25:40 omega dspam[13527]: Delivery agent returned exit code 67: /usr/lib/dovecot/deliver -d robot101@omega.example.co.uk
    Mar 6 02:25:40 omega postfix/lmtp[13640]: DAA4942F41F: to=<robot101@omega.example.co.uk>, orig_to=<robot101>, relay=omega.example.co.uk[/dspam/dspam.sock], delay=0.08, delays=0.05/0.01/0.01/0.03, dsn=4.3.0, status=deferred (host omega.example.co.uk[/dspam/dspam.sock] said: 421 4.3.0 <robot101@omega.example.co.uk> Delivered (in reply to end of DATA command))     So, no e-mail for me. Dearest lazyweb, which of the three components is behaving wrongly, and how can I fix it? (And no, I m not just going to switch to GMail. I store my data on hard drives, which are sometimes in servers, not in the cloud . Until about a month ago, most people I knew spoke about clouds which were made of particles of water in the sky, rather than as a data storage media. What if it rains? ;) Update: The problem is fixed! Even though arguably the problem is dspam s for not knowing which users are local or not, it s fixable in dovecot 1.1.x using the auth_username_format = %n option. Thanks so much to Angel Marin for helping me out. Update 2: There s also a patch for dspam floating around which adds a StripRcptDomain option, which makes the LMTP server truncate the e-mail address at the @, so essentially assumes everyone to be a local user. The problem with both of these fixes is that they re both blunt instruments which will break virtual users on the same host. I think the real fix would be something more like a LocalDomains option in dspam, to choose which domains should be considered local and truncated from the e-mail addresses for delivery purposes.

    5 March 2009

    Ingo Juergensmann: Gallery and missing exif information

    Dear Lazyweb,
    some time ago I upgraded my Gallery2 installation to 2.3-1 and since then I'm missing the exif information in the block below the foto. Although the exif plugin is activated and the exif plugin is properly configured (default). The Theme is configured to show "EXIF/IPTC photo info" to show the exif block on photo pages, but as you can see on this example there's no exif data showing up.

    The exif console tool is showing the correct information for those images, so I can't figure why gallery2 fails here. Any tips how to get exif information back into my gallery2, dear lazyweb?

    4 March 2009

    Uwe Hermann: Building an ARM cross-toolchain with binutils, gcc, newlib, and gdb from source

    I've been planning to write about building custom ARM toolchains for a while (I used stuff from gnuarm.com in the past, but I switched to the lastest and greatest upstream versions at some point). Among other things, recent upstream versions now have ARM Cortex support. First you will need a few base utilities and libs: 
      $ apt-get install flex bison libgmp3-dev libmpfr-dev autoconf texinfo build-essential
    Then you can use my tiny build-arm-toolchain script, which will download, build, and install the whole toolchain: 
      $ cat build-arm-toolchain
  #!/bin/sh
  # Written by Uwe Hermann <uwe@hermann-uwe.de>, released as public domain.
  TARGET=arm-elf                         # Or: TARGET=arm-none-eabi
  PREFIX=/tmp/arm-cortex-toolchain       # Install location of your final toolchain
  PARALLEL="-j 2"                        # Or: PARALLEL=""
  BINUTILS=binutils-2.19.1
  GCC=gcc-4.3.3
  NEWLIB=newlib-1.17.0
  GDB=gdb-6.8
  export PATH="$PATH:$PREFIX/bin"
  mkdir build
  wget -c http://ftp.gnu.org/gnu/binutils/$BINUTILS.tar.bz2
  tar xfvj $BINUTILS.tar.bz2
  cd build
  ../$BINUTILS/configure --target=$TARGET --prefix=$PREFIX --enable-interwork --enable-multilib \
    --with-gnu-as --with-gnu-ld --disable-nls
  make $PARALLEL
  make install
  cd ..
  rm -rf build/* $BINUTILS $BINUTILS.tar.bz2
  wget -c ftp://ftp.gnu.org/gnu/gcc/$GCC/$GCC.tar.bz2
  tar xfvj $GCC.tar.bz2
  cd build
  ../$GCC/configure --target=$TARGET --prefix=$PREFIX --enable-interwork --enable-multilib \
    --enable-languages="c" --with-newlib --without-headers --disable-shared --with-gnu-as --with-gnu-ld
  make $PARALLEL all-gcc
  make install-gcc
  cd ..
  rm -rf build/* $GCC.tar.bz2
  wget -c ftp://sources.redhat.com/pub/newlib/$NEWLIB.tar.gz
  tar xfvz $NEWLIB.tar.gz
  cd build
  ../$NEWLIB/configure --target=$TARGET --prefix=$PREFIX --enable-interwork --enable-multilib \
    --with-gnu-as --with-gnu-ld --disable-nls
  make $PARALLEL
  make install
  cd ..
  rm -rf build/* $NEWLIB $NEWLIB.tar.gz
  # Yes, you need to build gcc again!
  cd build
  ../$GCC/configure --target=$TARGET --prefix=$PREFIX --enable-interwork --enable-multilib \
    --enable-languages="c,c++" --with-newlib --disable-shared --with-gnu-as --with-gnu-ld
  make $PARALLEL
  make install
  cd ..
  rm -rf build/* $GCC
  wget -c ftp://ftp.gnu.org/gnu/gdb/$GDB.tar.bz2
  tar xfvj $GDB.tar.bz2
  cd build
  ../$GDB/configure --target=$TARGET --prefix=$PREFIX --enable-interwork --enable-multilib
  make $PARALLEL
  make install
  cd ..
  rm -rf build $GDB $GDB.tar.bz2
    The final toolchain is located in /tmp/arm-cortex-toolchain per default, and is ca. 170 MB in size. I explicitly created the build script in such a way that it minimizes the amount of disk space used during the build (ca. 1.2 GB or so, compared to more than 3 GB in the "naive" approach). Using the "-j 2" option for make (see script) you can speed up the build quite a bit on multi-core machines (ca. 30 minutes vs. 60 minutes on an AMD X2 dual-core box). Also, you can change the script to build for other target variants if you want to (arm-elf or arm-none-eabi, for example). Checkout the blog entry How to build arm gnu gcc toolchain for Mac OS X by Piotr Esden-Tempski for similar instructions for Mac OS X users. Oh, and while I'm at it does anybody have any idea why there are no pre-built toolchains for embedded (microcontroller) ARM targets in Debian? There are some toolchains for other microcontroller architectures (avr, m68hc1x, h8300, z80) but not too much other stuff. Is there some specific reason for the missing ARM toolchains (other than "nobody cared enough yet")? I have heard about Emdebian, but from a quick look that seems to be more intended for toolchains with Linux/libc, not for microcontroller firmware (i.e. no MMU, no Linux, no libc etc.), but maybe I'm wrong?

    3 March 2009

    Lucas Nussbaum: PhD !

    This blog post is long overdue, but like Lenny, it was finally released. Yes, I defended my PhD thesis on December 4th. So I m officially a Doctor from the Universit Joseph Fourier Grenoble. The general context of my thesis is distributed systems, like peer-to-peer systems and applications running on HPC (High Performance Computing) cluster and grids. More specifically, I worked on methods and tools to study such systems, trying to answer the following questions: take a given application that will run on a distributed system. What can we learn or verify about its performance or its characteristics? Will it scale well, even with 1000 or 10000 nodes? Does this app perform better than this another app? Under which conditions? (that s probably the hardest question, because you need to be able to run both apps under the same conditions if you want a fair comparison!) My work involved studying basic building blocks that can be used to study distributed systems, like network emulators (Dummynet, Linux s traffic control subsystem, NISTNet). I also designed P2PLab, which allows to emulate network-centric peer-to-peer systems using a cluster, targetting experiments with thousands of emulated instances of the application. For example, it allowed to run experiments with ~15000 emulated BitTorrent nodes using 160 real machines. So what s next? Well, my first-priority plan is to make use of my PhD to apply to an academic position (maitre de conf rences, i.e assistant professor). If you know an open position where I would be a good fit, don t hesitate to tell me! Of course, this plan might very well fail (I will know around end of June). In that case, I ll probably be looking for a job, likely Free-Software-related. Again, if you hear of something for me, ping me!

    Uwe Hermann: How to use the full size of your (x)term when connecting to some other box serially with minicom

    minicom terminal size 1 Just as a reminder for myself, as I'll probably need this more often in the future (and maybe it's helpful for others): Per default, if you use a big xterm (232x74 in my case) where you start minicom, the $COLUMNS and $LINES environment variables will be 80x24 nevertheless, and those applications which honor them (vim, for example) will be too small and not use the full xterm size of 232x74. 
      $ minicom
  $ echo $COLUMNS; echo $LINES
  80
  24
    minicom terminal size 2 You can fix that like this: 
      $ eval  resize 
  $ echo $COLUMNS; echo $LINES
  232
  74
    After you do eval resize the variables are updated and vim will use the full xterm size. That's all.

    Lucas Nussbaum: Creating a large file without zeroing it: update

    Given the large number of comments I got (26!), I feel obliged to post a summary of what was said. First, the problem:
    I want to create a large file (let s say 10 GB) to use as swap space. This file can t be a sparse file (a file with holes, see wikipedia if you don t know about sparse files).
    Since I m going to mkswap it, I don t care about the data that is actually in that file after creating it. The stupid way (but only solution on ext3) to create it is to fill it with zeroes, with is very inefficient. Theodore Tso provided more information in a comment, which I m copying here:
    Yes, it will work on ext4. A convenient which makes this easy to use can be found here at http://sandeen.fedorapeople.org/utilities/fallocate.c. It was written by Eric Sandeen, a former XFS developer who now works for Red Hat, who has been a big help making sure ext4 will be ready for Fedora and Red Hat Enterprise Linux. (Well, I guess I shouldn t call him a former XFS developer since he still contributes patches to XFS now and then, but he s spending rather more time on ext4 these days.) One warning about the program; it calls the fallocate system call directly, and it doesn t quite have the right magic architecture-specific magic for certain architectures which have various restrictions on how arguments need to be passed to system calls. In particular, IIRC, I believe there will be issues on the s390 and powerpc architectures. The real right answer is to get fallocate into glibc; folks with pull into making glibc do the right thing, please talk to me. Glibc does have posix_fallocate(), which implements the POSIX interface. posix_fallocate() is wired to use the fallocate system call, for sufficiently modern versions of glibc. However, posix_fallocate() is probablematic for some applications; the problem is that for filesystems that don t support fallocate(), posix_fallocate() will simulate it by writing all zeros to the file. However, this is not necessarily the right thing to do; there are some applications that want fallocate() for speed reasons, but if the filesystem doesn t support it, they want to receive the ENOSPC error message, so they can try some other fallback which might or might not involve writing all zero s to the file. The other shortcoming with posix_fallocate() is that it doesn t support the FALLOC_FL_KEEP_SIZE flag. What this flag allows you to do is to allocate disk blocks to the file, but not to modify the i_size parameter. This allows you to allocate space for files such as log files and mail spool files so they will be contiguous on disk, but since i_size is not modified, programs that append to file won t get confused, and tail -f will continue to work. For example, if you know that your log files are normally approximately 10 megs a day, you can fallocate 10 megabytes, and then the log file will be contiguous on disk, and the space is guaranteed to be there (since it is already allocated). When you compress the log file at the end of the day, if the log file ended up being slightly smaller than 10 megs, the extra blocks will be discarded when you compress the file, or if you like, you can explicitly trim away the excess using ftruncate().
    fallocate works fine: creating a 20 GB file is almost immediate. Also, syncing or umounting the filesystem is also immediate, and reading the file returns only zeros. I m not sure how it is implemented, but it looks nice :-). However, it still doesn t solve my initial problem: mkswap works, but not swapon: 
    :/tmp# touch tmp
:/tmp# /root/fallocate -l 10g tmp
:/tmp# ls -lh tmp
-rw-r--r-- 1 root root 10G Mar  3 11:01 tmp
:/tmp# du tmp
10485764	tmp
:/tmp# mkswap tmp
Setting up swapspace version 1, size = 10737414 kB
no label, UUID=a316ce8e-cf33-412b-8dc0-e10d9f2ebdbb
:/tmp# strace swapon tmp
[...]
swapon( /tmp/tmp )                      = -1 EINVAL (Invalid argument)
write(2,  swapon: tmp: Invalid argument\n , 30swapon: tmp: Invalid argument
) = 30
exit_group(-1)
    (swapon works fine if the file is created normally without using fallocate()). Any other ideas?

    Wouter Verhelst: DVswitch tally lights

    So you do computer stuff for work, and what do you do in the weekend? Right, more computer stuff. Not that I dislike it, obviously. But, well. The computer stuff that I did this weekend was situated mainly around dvswitch. During their talk at the Debian devroom at FOSDEM, Ben and Holger mentioned that one of the things they'd still like to see implemented in DVswitch is the ability to do tally lights. Such lights are useful, not only for the benefit of those in front of the camera, but also for the benefit of those behind the camera allowing them to know when they're free to roam about in order to find something interesting to show, or when they should keep the camera somewhat stead because they're live. Since I was planning on using dvswitch to record the concert (dutch only) of the choir group that I'm part of, and since a concert has different requirements than does a talk, I set about implementing tally light functionality. For now, the actual tally light is just a laptop screen which turns red when you're live, or green when you're not but there's nothing stopping anyone from changing that into, say, a USB-controlled light or some such. In any case, it works now. It's not entirely pretty (involving two processes working with the same socket) and not entirely finished yet, either (it only works for primary sources, not secondary sources), but it gets the job done. It did require me to refresh knowledge that I hadn't used in literally 10 years, however. I had some C++ at school, but haven't used it since my final exam on that course, and while the code is still readable, it did require me to refresh my memory at some levels. Oh my... Anyway, that was yesterday, for the most part. Today, a friend came over with a DV camera (since I don't have any), and we ran some tests. Most of it worked immediately, but there were a few bugs, which I ironed out today. Right now, it works correctly the parts that are implemented, at least. This video stuff is rather fun to play with.

    Obey Arthur Liu: Google Summer of Code 2009 at Debian needs you

    2009-summer-of-code-logo-final-r3-no-url-011 In case you ve been living under a rock these past years, I shouldn t have to tell you what this is about :). Well, just in case.
    The Google Summer of Code (GSoC) is an international program that offers student developers stipends to write code for various open source software projects. Debian has participated since 2006, mentoring dozens of students on Debian projects. The important part of the 2009 edition of the Google Summer of Code is going to start next week with the Organizations application period (March 9th). By that time, we should have listed a reasonable number of ideas on the dedicated wiki page. We will try this year to improve on the performance of the previous years, starting first with more and more dedicated manpower. If you have some time to spare to help manage our Summer of Code bid this year, we can make it a much better experience for the students and for Debian. Help is immediately needed in many areas. Some examples:

    By mid-March, we will need: Further in the spring: In the summer: As you can see, there is much work ahead. It s time to pitch out your favorite pet project :)
    Remember! The Summer of Code has become a prominent outreach forum for open source organizations. It puts a spotlight on each of them to provide a well-rounded and deep experience of open source development. Right now, you can help with the Wiki, join us on IRC on #debian-soc on OFTC or join the mailing-list at soc-coordination on alioth. The short flyers-friendly URL for the Summer of Code at Debian is : <http://wiki.debian.org/gsoc>. Publicize it! See you this summer!

    2 March 2009

    Ingo Juergensmann: HowTo: Migrate RAID1 to RAID5

    As I wrote last week (German), I had the plan to make a RAID5 out of my existing RAID1 after I received my third 1 TB harddisk. Migrating to RAID5 doesn't work online yet, because mdadm doesn't support the use of --grow and --level together, as you can read in the man page when looking for "-l, --level":


    -l, --level=
    Set raid level. When used with --create, options are: linear, raid0, 0, stripe, raid1, 1, mirror, raid4,
    4, raid5, 5, raid6, 6, raid10, 10, multipath, mp, faulty. Obviously some of these are synonymous.

    When used with --build, only linear, stripe, raid0, 0, raid1, multipath, mp, and faulty are valid.

    Not yet supported with --grow.


    But there's always a way to obtain your goal. If you're brave enough you can find the solution by a quick internet search. Ok, I'm not that brave to try this without a backup, but you shouldn't do that kind of work without having a good backup anyway.

    But before I describe the way how to do it, as usual a strong disclaimer: use this howto on your own risk! There's no warranty that this will work for you and you should take care to have a backup of your data. Whoever is doing this migration without having a backup risks the loss of all the data!

    I'll describe the migration using an example... there are three logical volumes (LVs) with 1 GB in size each. This is enough for testing purposes and demonstrates how the migration works. You can use real partitions like swap partitions if you want. The LVs are r1, r2, and r3 and are within the Volume Group (VG) /dev/vg:


    r1 vg -wi-a- 1.00G
    r2 vg -wi-a- 1.00G
    r3 vg -wi-a- 1.00G


    Two of these LVs are being setup for a RAID1 /dev/md5:

    CODE:
    muaddib:/home/ij# mdadm --create /dev/md5 -l 1 -n 2 /dev/vg/r[12]
    mdadm: /dev/vg/r1 appears to be part of a raid array:
    level=raid1 devices=2 ctime=Thu Feb 26 16:16:59 2009
    mdadm: /dev/vg/r2 appears to be part of a raid array:
    level=raid1 devices=2 ctime=Thu Feb 26 16:16:59 2009
    Continue creating array? yes
    mdadm: array /dev/md5 started.


    The warning to be a part of another raid array can be ignored. It's just a testing array. The result should look similar to:


    md5 : active raid1 dm-12[1] dm-11[0]
    1048512 blocks [2/2] [UU]
    [========>............] resync = 40.2% (422900/1048512) finish=0.7min speed=14096K/sec


    Now a filesystem can be created on the raid array and some data can be stored there:

    CODE:
    muaddib:/home/ij# mkfs.xfs -f /dev/md5
    meta-data=/dev/md5 isize=256 agcount=4, agsize=65532 blks
    = sectsz=512 attr=2
    data = bsize=4096 blocks=262128, imaxpct=25
    = sunit=0 swidth=0 blks
    naming =version 2 bsize=4096 ascii-ci=0
    log =internal log bsize=4096 blocks=1200, version=2
    = sectsz=512 sunit=0 blks, lazy-count=0
    realtime =none extsz=4096 blocks=0, rtextents=0
    muaddib:/home/ij# mount /dev/md5 /mnt
    muaddib:/home/ij# cp pics/backdrops/*.jpg /mnt/
    muaddib:/home/ij# dir /mnt/
    amigager_back1.jpg Dansk-Dunes14.jpg Dansk-Nature-2.jpg
    CapeCod_085.jpg Dansk-Dunes15.jpg Dansk-Priel.jpg
    ct-1-p1600.jpg Dansk-Dunes16.jpg Dansk-Woods-1.jpg
    ct-2-p1600.jpg Dansk-Dunes17.jpg earth_lights_lrg.jpg
    Dansk-Beach1.jpg Dansk-Dunes18.jpg HanseSail-AlterStrom2.jpg
    Dansk-Beach2.jpg Dansk-Dunes2.jpg HanseSail-AlterStrom.jpg
    Dansk-Beach3.jpg Dansk-Dunes3.jpg HanseSail-Mast.jpg
    Dansk-Beach4.jpg Dansk-Dunes4.jpg HanseSail-Warnemuende.jpg
    Dansk-Beach5.jpg Dansk-Dunes5.jpg LinuxInside_p1600.jpg
    Dansk-Beachstones.jpg Dansk-Dunes6.jpg prerow.jpg
    Dansk-Cliffs.jpg Dansk-Dunes7.jpg sgi-1440.jpg
    Dansk-Dunes10.jpg Dansk-Dunes8.jpg sgi.jpg
    Dansk-Dunes11.jpg Dansk-Dunes9.jpg Sonnenuntergang-2.jpg
    Dansk-Dunes12.jpg Dansk-Dunes.jpg Sonnenuntergang.jpg
    Dansk-Dunes13.jpg Dansk-Nature-1.jpg
    muaddib:/home/ij# umount /mnt


    After umounting the real challenge arise: creation of a RAID5 label! Normally this is no issue, but I guess you like your data and think twice before proceeding... but hey! You have a backup anyway, don't you?!

    CODE:
    muaddib:/home/ij# mdadm --create /dev/md5 --level=5 --raid-devices=2 /dev/vg/r[12]
    mdadm: /dev/vg/r1 appears to be part of a raid array:
    level=raid1 devices=2 ctime=Mon Mar 2 18:18:09 2009
    mdadm: /dev/vg/r2 appears to be part of a raid array:
    level=raid1 devices=2 ctime=Mon Mar 2 18:18:09 2009
    Continue creating array? yes
    mdadm: array /dev/md5 started.
    muaddib:/home/ij# cat /proc/mdstat
    md5 : active (auto-read-only) raid5 dm-12[2](S) dm-11[0]
    1048512 blocks level 5, 64k chunk, algorithm 2 [2/1] [U_]
    muaddib:/home/ij# cat /proc/mdstat
    Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
    md5 : active raid5 dm-12[2] dm-11[0]
    1048512 blocks level 5, 64k chunk, algorithm 2 [2/1] [U_]
    [>....................] recovery = 3.1% (33152/1048512) finish=0.5min speed=33152K/sec


    After stopping /dev/md5 the new RAID5 label can be written. The data ought to be safe because of the RAID5 algorithm when running with 2 disks. To verify the theory you can mount /dev/md5 again. The next steps can be done with the array online.


    muaddib:/home/ij# mount /dev/md5 /mnt
    muaddib:/home/ij# dir /mnt/
    amigager_back1.jpg Dansk-Dunes14.jpg Dansk-Nature-2.jpg
    CapeCod_085.jpg Dansk-Dunes15.jpg Dansk-Priel.jpg
    ct-1-p1600.jpg Dansk-Dunes16.jpg Dansk-Woods-1.jpg
    ct-2-p1600.jpg Dansk-Dunes17.jpg earth_lights_lrg.jpg
    Dansk-Beach1.jpg Dansk-Dunes18.jpg HanseSail-AlterStrom2.jpg
    Dansk-Beach2.jpg Dansk-Dunes2.jpg HanseSail-AlterStrom.jpg
    Dansk-Beach3.jpg Dansk-Dunes3.jpg HanseSail-Mast.jpg
    Dansk-Beach4.jpg Dansk-Dunes4.jpg HanseSail-Warnemuende.jpg
    Dansk-Beach5.jpg Dansk-Dunes5.jpg LinuxInside_p1600.jpg
    Dansk-Beachstones.jpg Dansk-Dunes6.jpg prerow.jpg
    Dansk-Cliffs.jpg Dansk-Dunes7.jpg sgi-1440.jpg
    Dansk-Dunes10.jpg Dansk-Dunes8.jpg sgi.jpg
    Dansk-Dunes11.jpg Dansk-Dunes9.jpg Sonnenuntergang-2.jpg
    Dansk-Dunes12.jpg Dansk-Dunes.jpg Sonnenuntergang.jpg
    Dansk-Dunes13.jpg Dansk-Nature-1.jpg


    The next step is to add the third "disk":

    CODE:
    muaddib:/home/ij# mdadm --add /dev/md5 /dev/vg/r3
    mdadm: added /dev/vg/r3
    muaddib:/home/ij# cat /proc/mdstat
    md5 : active raid5 dm-13[2](S) dm-12[1] dm-11[0]
    1048512 blocks level 5, 64k chunk, algorithm 2 [2/2] [UU]


    That was the first step. As you can see the third "disk" has been added as a spare device. Because we don't want a spare but a RAID5 we need to expand the number of disks to 3 and tell the RAID to grow it's capacity:

    CODE:
    muaddib:/home/ij# mdadm --grow /dev/md5 --raid-devices=3
    mdadm: Need to backup 128K of critical section..
    mdadm: ... critical section passed.
    muaddib:/home/ij# cat /proc/mdstat
    Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
    md5 : active raid5 dm-13[2] dm-12[1] dm-11[0]
    1048512 blocks super 0.91 level 5, 64k chunk, algorithm 2 [3/3] [UUU]
    [>....................] reshape = 3.1% (33472/1048512) finish=3.0min speed=5578K/sec


    The last two commands were made with the mounted filesystem that just needs to get enlarged. With XFS you make this happen by invoking xfs_growfs:

    CODE:
    muaddib:/home/ij# df -h /mnt
    Filesystem Size Used Avail Use% Mounted on
    /dev/md5 1020M 21M 1000M 2% /mnt
    muaddib:/home/ij# xfs_growfs /mnt
    meta-data=/dev/md5 isize=256 agcount=4, agsize=65532 blks
    = sectsz=512 attr=2
    data = bsize=4096 blocks=262128, imaxpct=25
    = sunit=0 swidth=0 blks
    naming =version 2 bsize=4096 ascii-ci=0
    log =internal bsize=4096 blocks=1200, version=2
    = sectsz=512 sunit=0 blks, lazy-count=0
    realtime =none extsz=4096 blocks=0, rtextents=0
    data blocks changed from 262128 to 524256
    muaddib:/home/ij# df -h /mnt
    Filesystem Size Used Avail Use% Mounted on
    /dev/md5 2.0G 21M 2.0G 1% /mnt


    Done!

    If you have an LVM on your RAID you'll need to use the appropriate LVM tools to enlarge the PVs and VGs as well. But the hardest work is already done. The reshaping can take a lot of time, as you can see here:


    md4 : active raid5 sda6[0] sdc6[2] sdb6[1]
    969161152 blocks super 0.91 level 5, 64k chunk, algorithm 2 [3/3] [UUU]
    [>....................] reshape = 2.8% (27990592/969161152) finish=1485.0min speed=10562K/sec


    There might be other fallpits if you change your setup from 2-disk arrays to 3-disk arrays. For example you'll need to adopt the changes to your configuration files like /etc/mdadm/mdadm.conf. But this has not much to do with the migration from RAID1 to RAID5 itself.

    Many thanks to Goswin Brederlow for his advice and writing a wishlist bug: #517731

    Michal &#268;iha&#345;: Gammu stable version 1.23.1

    After recently introduced tradition, I again come with bugfix update for 1.23.0 called 1.23.1. This time there is no critical fix as in 1.22.1, but few fixes, which might annoy users, for example forgotten installation of gammu-smsd-monitor tool. Full list of changes: You can download from usual place: http://cihar.com/gammu/, Debian users will find packages in unstable soon, SUSE, Fedora and Mandriva users can check repository in OpenSuse Build Service and Ubuntu in my PPA.

    Ian Wienand: YUI ButtonGroup Notes

    Some tips and things to check if your YUI ButtonGroup isn't behaving as you wish it would. Hopefully, this will save someone else a few hours!

    Joey Hess: re: Declarative .deb maintainer scripts

    Lars wonders about debhelper's approach of inserting script fragments into package maintainer scripts. It's really very interesting to survey debhelper's collection of fragments, in its autoscripts directory. Of the 55 fragments, the mean length is 4.5 lines, and the mode (and also shortest[1]) length is 3 lines. The 32 scripts that are each three lines follow a very simple pattern: 
    if [ "$1" = something ] && exists some-script; then
    some-script some-parameters
fi
    It would be nice to get that down to Lar's more declarative one line approach: 
    some-script some-parameters $@
    In practice though, many of these scripts are not always available, and so the postinst has to test for them before running them. And making them test the postinst's parameters to see if they should do anything makes them less general and less flexible (ie, not able to be run easily by a sysadmin), and so keeping the "$1" test in the postinst is reasonable. So, I think I've done a pretty good job at keeping debhelper script fragments short and keeping most of the possibly buggy bits that might need maintenace out of debhelper. The exceptions tend to be either older scripts, from a time when I was less careful about doing do, and fragments of code that I could not pawn off onto some other package, often because there was no package that owned the issue. (The dh_usrlocal code is the best example of that.) The most promising way to improve things seems to be using dpkg triggers, which is why I was very enthuisiastic when we finally got them, over a year ago. Triggers let many of these hooks into maintainer scripts go away completely. Rather than each package having to test for and call update-menus, menu can simply trigger on the modification of any menu file. Once menu finishes the conversion to using triggers, debhelper can drop those fragments entirely. Triggers seem likely to be able to eliminate well over 90% of the things we need to put into maintainer scripts, and I hope at least half of debhelper's script fragments can eventually go away thanks to them. The others seem more difficult. You probably cannot, for example, make a trigger that does something sane when an init script is installed. Debhelper has at least three different fragements that it can put into postinst scripts to handle init scripts, and these only cover the most common three cases (start, don't start, don't restart on upgrade). Moving even these things into a declarative form has long been a dream of mine. Maybe it could be done with a control file that specifies which of the methods for running the package's init script to use for this package. But it seems we can't do away with maintainer scripts entirely, no matter how hard we try. That's because maintainer scripts are our only way to deal with other crippling bugs in old versions of a package, and with upgrade issues, and with all the other myriad things that we put custom code in them to deal with. Pity.
    [1] Slight oversimplification; two scripts cram the 3-line form in one line for no good reason and are counted as 3-lines above.

    Theodore Ts'o: SSD s, Journaling, and noatime/relatime

    On occasion, you will see the advice that the ext3 file system is not suitable for Solid State Disks (SSD s) due to the extra writes caused by journaling and so Linux users using SSD s should use ext2 instead. However, is this folk wisdom actually true? This weekend, I decided to measure exactly what the write overhead of journaling actually is in actual practice. For this experiment I used ext4, since I recently added a feature to track the amount of writes to the file system over its lifetime (to better gauge the wear and tear on an SSD). Ext4 also has the advantage that (starting in 2.6.29), it can support operations with and without a journal, allowing me to do a controlled experiment where I could manipulate only that one variable. The test workload I chose was a simple one: For the first test, I ran the test using no special mount options, and the only difference being the presence or absence of the has_journal feature. (That is, the first file system was created using mke2fs -t ext4 /dev/closure/testext4, while the second file system was created using mke2fs -t ext4 -O ^has_journal /dev/closure/testext4.)
    Amount of data written (in megabytes) on an ext4 filesystem
    Operation with journal w/o journal percent change
    git clone 367.7 353.0 4.00%
    make 231.1 203.4 12.0%
    make clean 14.6 7.7 47.3%
    What the results show is that metadata-heavy workloads, such as make clean, do result in almost twice the amount data written to disk. This is to be expected, since all changes to metadata blocks are first written to the journal and the journal transaction committed before the metadata is written to their final location on disk. However, for more common workloads where we are writing data as well as modifying filesystem metadata blocks, the difference is much smaller: 4% for the git clone, and 12% for the actual kernel compile. The noatime mount option Can we do better? Yes, if we mount the file system using the noatime mount option:
    Amount of data written (in megabytes) on an ext4 filesystem mounted with noatime
    Operation with journal w/o journal percent change
    git clone 367.0 353.0 3.81%
    make 207.6 199.4 3.95%
    make clean 6.45 3.73 42.17%
    This reduces the extra cost of the journal in the git clone and make steps to be just under 4%. What this shows is that most of the extra meta-data cost without the noatime mount option was caused by update to the last update time for kernel source files and directories. The relatime mount option There is a newer alternative to the noatime mount option, relatime. The relatime mount option updates the last access time of a file only if the last modified or last inode changed time is newer than the last accessed time. This allows programs to be able to determine whether a file has been read size it was last modified. The usual (actually, only) example that is given of such an application is the mutt mail-reader, which uses the last accessed time to determine if new mail has been delivered to Unix mail spool files. Unfortunately, relatime is not free. As you can see below, it has roughly double the overhead of noatime (but roughly half the overhead of using the standard Posix atime semantics):
    Amount of data written (in megabytes) on an ext4 filesystem mounted with relatime
    Operation with journal w/o journal percent change
    git clone 366.6 353.0 3.71%
    make 216.8 203.7 6.04%
    make clean 13.34 6.97 45.75%
    Personally, I don t think relatime is worth it. There are other ways of working around the issue with mutt for example, you can use Maildir-style mailboxes, or you can use mutt s check_mbox_size option. If the goal is to reduce unnecessary disk writes, I would mount my file systems using noatime, and use other workarounds as necessary. Alternatively, you can use chattr +A to set the noatime flag on all files and directories where you don t want noatime semantics, and then clear the flag for the Unix mbox files where you care about the atime updates. Since the noatime flag is inherited by default, you can get this behaviour by setting running chattr +A /mntpt right after the filesystem is first created and mounted; all files and directories created in that file system will have the noatime file inherited. Comparing ext3 and ext2 filesystems
    Amount of data written (in megabytes) on an ext3 and ext2 filesystem
    Operation ext3 ext2 percent change
    git clone 374.6 357.2 4.64%
    make 230.9 204.4 11.48%
    make clean 14.56 6.54 55.08%
    Finally, just to round things out, I tried the same experiment using the ext3 and ext2 file systems. The difference between these results and the ones involving ext4 are the result of the fact that ext2 does not have the directory index feature (aka htree support), and both ext2 and ext3 do not have extents support, but rather use the less efficient indirect block scheme. The ext2 and ext3 allocators are also someone different from each other, and from ext4. Still, the results are substantially similar with the first set of Posix-compliant atime update numbers (I didn t bother to do noatime and relatime benchmark runs with ext2 and ext3, but I expect the results would be similar.) Conclusion So given all of this, where did the common folk wisdom that ext3 was not suitable for SSD s come from? Some of it may have been from people worrying too much about extreme workloads such as make clean ; but while doubling the write load sounds bad, going from 4MB to 7MB worth of writes isn t that much compared to the write load of actually doing the kernel compile or populating the kernel source tree. No, the problem was that first generation SSD s had a very bad problem with what has been called the write amplification effect , where a 4k write might cause a 128k region of the SSD to be erased and rewritten. In addition in order to provide safety against system crashes, ext3 has more synchronous write operations that is where ext3 waits for the write operation to be complete before moving on, and this caused a very pronounced and noticeable stuttering effect which was fairly annoying to users. However, the next generation of SSD s, such as Intel s X25-M SSD, have worked around the write amplification affect. What else have we learned? First of all, for normal workloads that include data writes, the overhead from journaling is actually relatively small (between 4 and 12%, depending on the workload). Further, than much of this overhead can be reduced by enabling the noatime option, with relatime providing some benefit, but ultimately if the goal is to reduce your file system s write load, especially where an SSD is involved, I would strongly recommend the use of noatime over relatime. Related posts (automatically generated):
    1. Should Filesystems Be Optimized for SSD s? In one of the comments to my last blog entry,...
    2. Aligning filesystems to an SSD s erase block size I recently purchased a new toy, an Intel X25-M SSD,...
    3. Fast ext4 fsck times This wasn t one of the things we were explicitly engineering...

    1 March 2009

    Julian Andres Klode: debimg update - creating images


    Much happened since the last time I wrote about debimg. The project is now registered on Alioth and has a mailing list. On the code side, there have also been several changes. First of all, the repository module has been merged into the master branch. This was the first step towards the creation of the image building, which happened today by introducing the image module. The code should be treated as Beta quality, but the project as a whole is Alpha, because the application utilizing debimg.core is still missing. As always, I hereby encourage to try out debimg, have a look at the examples, and help to develop it. Patches should be sent to the mailing list, created with git format-patch, and its usual settings (eg. prefixed with eg. [PATCH 1/2] ). The patches should be inline and validate in pyflakes and using pep8.py. See the README for some more recommendations. Because NEW seems to be really busy at the moment (and doko uploaded python2.6 and python3.1), I m not uploading the current state as 0.1.0~a1 to experimental, but wait until NEW is smaller (maybe it will be 0.1.0~b1 then). What is wanted/planned?
    • Compatibility configuration formats
      • (debimg.config.simple_cdd) A reimplementation of simple-cdd using debimg. This probably needs to wait until there is a module for dealing with the installer, but I want to implement an application to support simple-cdd configuration files.
      • (debimg.config.debian_cd) There could be an implementation of debian-cd s configuration format. This would allow people to easily try out debimg. We can only support a subset, though.
    • New configuration formats
      • (debimg.config.yaml) Debimg s native configuration format. This is the only one supported by the graphical frontends. Where possible, configuration between compatibility formats and this format will be provided.
    • Graphical Frontends:
      • (debimg.frontend.gtk2) The graphical GTK+ frontend for inexperienced users who just want to create their own disk.
      • (debimg.frontend.qt4) The graphical frontend written in QT4.
    • Text frontends
      • (debimg.frontend.text) The basic command-line frontend.
      • (debimg.ubuntu.frontend.text) A script to build Ubuntu images, which could be used to build the official Ubuntu Images. This requires interaction with the germinate tool for dependency resolution, and more. It s also not flexible enough for building custom images.
    Requirements for 0.1 Beta
    • Implement at least one configuration format and the build frontend.
    • Have at least one external contributor.
    More Changes Julian Andres Klode (6):
    • debimg/core/files: When creating a file object allow filename as source
    • debimg/core/resolver.py: Introduce Package.fullname, Package.component
    • debimg/core/repository.py: Merge the repository module.
    • debimg/core/resolver.py: Improve handling of certain dependency types
    • debimg/core/repository.py: Allow Repository.add_group to take a distro parameter
    • debimg/core/image.py: Introduce the image module.
    Posted in Debian, debimg, Ubuntu

    27 February 2009

    MJ Ray: New #ukgovOSS Action Plan

    Earlier this week, Tom Watson, Cabinet Office Parliamentary Secretary, published the Open Source, Open Standards and Re Use: Government Action Plan. It s had a pretty mixed reaction, with mild scepticism (niq s soapbox: Is gov.uk going open-source?) being the average reaction from what I ve read. I particularly liked the kind offer by Bristol Wireless to debianise Tom Watson s laptop. I think commentators are bang-on that the procurement process needs to change and that this sounds positive. I ll love it if I m wrong, but this looks like the lip service as usual which I ve seen in the last 10 years working on FOSS in the UK. I want to see the action that comes from this plan! When government actually starts buying FOSS from typical FOSS service providers and not just the IBMs of this world, then I ll believe it. My suspicion is re-ignited by some of the activites around this action plan. For example, does anyone know why the Cabinet Office didn t select FOSS to run their special public FOSS Aggregation page? (Actually, what s the best FOSS tag aggregator web service out there? I know we can set them up in Wordpress widgets, but what hosted services are there?) I m also a bit bemused that their page requires users to accept cookies until they expire, yet its privacy policy explicitly says You may suppress cookies after your visit or configure your Internet browser to prevent them. Yes, I can prevent them, but then it does nothing useful! (Based on a comment I made at the OSS Watch team blog and discussions with a few user groups.)

    Next.

    Previous.