• Since upstream is now trying to keep a consistent ABI/API, packages have been renamed from libhdf5-xxx-X.Y.Z (X, Y and Z being the version number) to libhdf5-xxx-7 (7 being the version of the soname)
• The package libhdf5-serial-* have been renamed to libhdf5-7 or libhdf5-dev
• Symbol files have been added for all the libraries.
• arm archs have also libhdf5-openmpi-dev
• Support of HURD, armhf & s390x
• Help is now up to date and the debian/html.tgz.uu removed (thanks to the source format v3.0, two source tarballs are now used)
• A new package hdf5-helpers which contains h5cc, h5c++ and h5fc has been introduced
• Fix many lintian warnings
• Java HDF has been updated to version 2.8

cjac@proliant1:~$ uptime
 16:41:26 up 10 days, 22:15,  1 user,  load average: 0.00, 0.01, 0.05

1. Translate my Debian book into English: PARTLY DONE
   It took more time than expected to prepare and to run the fundraising campaign but it has been successful and the translation is happening right now.
2. Finish multiarch support in dpkg: DONE BUT NOT ENTIRELY MERGED YET
   Yes, multiarch support was already in the pipe last year in January. I completed the development between January and April (it was sponsored by Linaro) and since then it has mostly been waiting on Guillem to review it, tweak it, and integrate it.
3. Make deb files use XZ compression by default: TRIED BUT ABANDONED
   After discussing the issue with Colin Watson and Joey Hess during debconf, I came to the conclusion that it was not really desirable at this point. The objections were that debian-installer was not ready for it and that it adds a new dependency on xz for debootstrap to work on non-Debian systems. I believe that the debian-installer side is no longer a problem since unxz is built in busybox-udeb (since version 1:1.19.3-2). For the other side, there s not much to do except ensuring that xz is portable to all the other OS we care about. DAK has been updated too (see #556407).
4. Be more reactive to review/merge dpkg patches: PARTLY DONE
   I don t think we had any patch that received zero input. We still have a backlog of patches, and the situation is far from ideal but the situation improved.
5. Implement the rolling distribution proposed as part of the CUT project and try to improve the release process: NOT DONE
   We had a BoF during debconf, we discussed it at length on debian-devel, but in the end we did nothing out of it. Except Josselin Mouette who wrote a proof of concept for his idea. For me testing is already what people are expecting from a rolling distribution. It s just a matter of documenting how to effectively use testing, and of some marketing by defining rolling as alias to testing.
6. Work more regularly on the developers-reference: PARTLY DONE
   I did contribute some new material to the document but not as much as I could have hoped. On the other hand, I have been rather reactive to ensure that sane patches got merged. We need more people writing new parts and updating the existing content.
7. Write a 10-lesson course called Smart Package Management : NOT DONE
8. Create an information product (most likely an ebook or an online training) and sell it on my blog: NOT DONE
   This was supposed to happen after the translation of the Debian Administrator s Handbook. Since the translation is not yet over, I did not start to work on this yet.
9. By the end of the year, have at least 1/3 of my time funded by donations and/or earnings of my information products: NOT REACHED
   My target was rather aggressive with 700 each month, and given that I did not manage to complete any information product, I m already very pleased to have achieved a mean amount of 204 of donations each month (min: 91 , max: 364 ). It s more than two times better than in 2010. Thank you! Note that those figures do not take into account the revenues of the fundraising of the Debian Administrator s Handbook since they will be used for its translation.

2 comments Liked this article? Click here. My blog is Flattr-enabled.

• Music files. They're currently stored on a plug computer at home and served over DAAP, but DAAP seems to become less and less of a priority for music players (I'll keep the music players suck rant for another post), and it has its inconveniences too. Ideally, the files should be integrated in the filesystem of my work computer, the one that serves as a media player in the living-room, the one I use for playing the backing tracks when I'm practising the drums, and the laptop I use when on the road too.
• Backups. My BackupPC currently runs on the plug computer at home, so backups of my remote servers are in a geographically distinct location; but backups of my home computers are not, and I'd like to change that without having to copy files around by hand. Backups do contain confidential data, so this adds a constraint on the filesystem.
• Bazaar repositories. I do have a script that pushes and pulls stuff across computers for the many repositories I use, but it's still awkward that I need to do that.
• Parts of my home directory, such as my browser preferences and bookmarks, or the database of the Hamster time tracking tool, or the working directories of stuff I do for clients, and so on. Again, each of those can be done with specific means (bookmarks synced to a server, CouchDB-like database, DVCS and regular commits, etc.), but wouldn't it be much simpler if there only was one file to begin with?

• Availability means redundancy: some of the storage nodes will be on dedicated servers in datacenters, others at home; I can imagine setting up the firewall so that the home computers are reachable from outside, but sometimes network links go down, and the home computers are far from being on 100% of the time.
• Availability/redundancy also means automated replication and rebalancing: if a node is added to the grid (or switched on), it should automatically get its share of the files so as to contribute to availability if another node goes down at a later time.
• Confidentiality: at the very least, network communications must be encrypted and authenticated; ideally, individual storage nodes wouldn't need to be able to access the stored data. If I store bits of my backups on a friend's server, I don't want to have to trust them not to look at the data; also, my friend may actually want to be unable to look at my data (to provide for deniability in case someone else wants to look at it).
• Performance: native disk performance may not be realistically reachable, but the system must be smart enough (or configurable enough) to store files on both sides of the ADSL link, for instance, so not all accesses need to go through the bottleneck.
• Integration with the system: I want a filesystem, not a storage system. All applications know how to navigate a mounted filesystem; very few will interface with an specific application designed to store and fetch chunks of data.
• Scalability would be nice, although my personal needs are still well below the terabyte range and I can't see myself using more than a dozen nodes or so.

• Availability/redundancy 1: all three candidates work on the net, and they all provide for data replication. XtreemFS seems to operate on a fall-back mode while the other two are more distributed (meaning there's no canonical node hosting any particular file). Tahoe uses erasure codes (files can be split across N shares, k of which are enough to reconstruct the whole file; the N/k ratio controls the amount of redundancy); it seems to require the introducer node to be always up, which introduces a single point of failure, but this node can be replaced with no loss of data if it fails (this just requires reconfiguring the storage nodes, which can probably be automated). Ceph can work with any number of meta-data servers, so redundancy is assured there (data itself can be replicated in a configurable way too).
• Availability/redundancy 2: either I'm a fool and I didn't find out about that, or none of the three candidates provides for automated rebalancing. Apparently Tahoe provides a way to repair files without enough redundancy, but that needs to be run manually on each file, rather than being systematic, and it's a kind of add-on to the system rather than being properly integrated. Ceph only does rebalancing of meta-data. XtreemFS seems to work a bit like RAID1 with spare disks, but details are scarce.
• Confidentiality: Tahoe wins, hands down. Neither network sniffers nor storage nodes can see the contents of the stored files. They can't even find out about their name or the directory structure. XtreemFS encrypts the data on the network (but it is still stored in cleartext on the nodes). Ceph doesn't even try.
• Performance: Ceph wins (or loses less, at any rate): it seems possible to configure a topology for the storage nodes, and to drive the storage location policy according to this topology; so I could define sets of nodes ( my servers in datacenters , my plug computer at home , my desktop and laptop computers , my friends' computers ) and decide that each file should be stored at least once on each set of nodes. Tahoe stores shares of files on a number of storage nodes chosed in kind of a round-robin way; read access uses the same round-robin system, which means that you will probably end up fetching a file at least partially over your slow link even when you could fetch it entirely from the local network. The XtreemFS website doesn't seem to acknowledge the possibility of the network being slow.
• Integration: Ceph and XtreemFS win: they're native filesystems. Tahoe is in the storage and retrieval system category; the FUSE layer is marked as experimental and not recommended, and the SFTP layer (which can be mounted as a filesystem with sshfs) has many documented drawbacks. Maybe a WebDAV frontend, combined with fusedav, would provide a working alternative, but it's not implemented yet.
• Scalability: all three candidates boast about scalability (in data size and in number of nodes). Ceph seems to require some configuration every time a new storage node is added. Tahoe seems much more dynamic: new nodes (storage or clients) just need to be told where the introducer node is, and then they merge into the grid seamlessly by being told about other nodes (a bit like Bittorrent, where clients learn about each other by asking the tracker).

• A configurable dispatch policy, so that administrators could define their own behaviour. The current Tahoe parts already turn files into a number of blobs that only need to be stored on various nodes, and the function that chooses which nodes seems to be reasonably self-contained, so it could maybe even be made pluggable, and an administrator could implement a storage policy that matches the constraints and the network topology. Ditto for the function that picks which nodes the data is read from (which, as far as I can tell, is the same; splitting could bring some benefits here).
• A working FUSE implementation, either on top of SFTP if the drawbacks can be fixed, on top of WebDAV if that gets implemented, or native to Tahoe if that can be done.
• Automatic rebalancing of data when new nodes are added or turned on, or when an intermittent network link comes up. The current script seems to be an afterthought; if it can be made more automated and more reliable, I'll be happy with that.

• eCryptfs on top of Ceph. The file contents are still only accessible to those in possession of the adequate key, and replication/distribution is handled by Ceph. That could probably work; the main drawbacks I can see come from Ceph's administrative overhead and manual configuration.
• LUKS and a standard filesystem, on top of the part of Ceph that manages block devices (RADOS). I'm not sure this could be mounted simultaneously by several nodes, though.
• LUKS on top of Ceph's RADOS, and Lustre or GlusterFS on top of that? Am I even making sense?
• A kind of union filesystem with local caching, on top of Tahoe-LAFS. Say we take unionfs-fuse, and add local caching: if the requested file is already in cache, performance is near native; if not, we still get the advantages of Tahoe. I'm not sure how caching works with WebDAV, but once Tahoe gets a WebDAV frontend it might be a simple matter of adding a Squid cache between that and davfs.
• I even thought of building a filesystem on top of the Bittorrent protocol; redundancy would be obtained by ensuring that there are at least N distributed copies of a file among the peers. I gave up even before reaching the details phase, though, but maybe a variant of the idea could be workable.

1. Boot the installer in rescue mode and open a shell on the installed system:

   # # We start in dash, so switch to bash.
   # exec bash
   # mkdir -p /boot/efi
   # # Mount the EFI boot partition by UUID.
   # # It's probably called sda1 now, but is subject to change.
   # ls -l /dev/disk/by-uuid
   ...
   # echo >>/etc/fstab 'UUID=efi-boot-uuid /boot/efi vfat defaults 0 0'
   # mount /boot/efi
   # # Enable unstable sources, but use stable by default
   # echo >>/etc/apt/apt.conf 'APT::Default-Release "squeeze";'
   # echo >>/etc/apt/sources.list 'deb http://cdn.debian.net/debian/ sid main'
   # apt-get update
   ...
   # # Install unstable grub-efi-amd64
   # apt-get install -t unstable grub-efi-amd64
   ...
   # # Install GRUB to the EFI partition.  The '--removable' options
   # # inhibits setting EFI variables, which won't work because we booted
   # # through BIOS emulation.  Instead, it installs as the default boot
   # # loader.
   # grub-install --bootloader-id=GRUB --removable
   # # On the AMI/ASUS firmware, you cannot select a new bootloader
   # # directly but can invoke a 'shell'.  So I made GRUB the shell:
   # cp /boot/efi/boot/grub/grub.efi /boot/efi/shellx64.efi
   # exit
   

2. Reboot and select GRUB as the boot loader if necessary. In my case I had to enter the setup program and select 'EFI shell'. Debian should now boot from the hard drive.
3. Add a non-volatile boot option for GRUB (and make it the default):

   # apt-get install efibootmgr
   ...
   # modprobe efivars
   # efibootmgr -c -l '\efi\grub\grubx64.efi' -L GRUB
   

• Thai recompletes level 1
• I again sent yet another reminder to translators, in a desperate attempt to improve statistics below, which I consider poor

• 19 languages 100%: cs de eo es fr it ja kk mr nb nl pl pt ru sk sv th uk zh_CN
• 9 languages 99%: bg bs fa gu hi ko si ta te
• 1 language 97%: eu
• 2 languages 96%: he sr
• 5 languages 95%: ar be bn dz tr
• 4 languages 94%: ast ga id ro
• 5 languages 93%: el hu is km lo
• 1 language 92%: sl
• 4 languages 91%: et pa vi zh_TW
• others are 90% or below

• 14 languages 100%: cs de es fa fr it kk nl pt ru si sk uk zh_CN
• 9 languages 99%: be bg da eo id ja sl sv th
• 4 languages 98%: ca eu pt_BR ro
• 1 language 97%: is
• 1 language 96%: nb
• 3 langauges 95%: el fi he
• 7 languages 94%: ar ast dz gl hr vi zh_TW
• 8 languages 92%: bn bs hu ko ne pl sr tr
• 9 languages 91%: ga gu ka km lt mk mr ta te
• others are 90% or below

• 26 languages 100%: be bg bs ca cs de el eo es fa fi fr ga gl is it ja kk nb nl pt ru sk sv th tr
• 4 languages 98%: he hu uk zh_CN
• others are 90% or below

def get_auto_summary(self):
    h2t = html2text.HTML2Text()
    h2t.body_width = 0
    h2t.ignore_images = True
    h2t.ignore_links = True
    h2t.ignore_emphasis = True
    text = h2t.handle(self.body.rendered)
    return text.splitlines()[0]

Filed under: Django English Website 2 comments Flattr this!

Image by Cayusa via Flickr

#!/bin/sh
#
# Rygel daemon handling
RYGEL='/usr/bin/rygel'
RYGEL_ARGS=''
su -s /bin/sh -c "nohup $RYGEL $RYGEL_ARGS > /var/local/rygel/rygel.log 2>&1 &"
rygel
EXIT_CODE=$?
if [ $EXIT_CODE != 0 ] ; then
        return $EXIT_CODE
fi
PGROUP= ps --no-headers -o pgrp $$ 
PID= pgrep -g $PGROUP -f $RYGEL 
echo $PID > /var/run/rygel.pid
exit 0

Related articles

• Verizon planning Media Server for FiOS TV (techradar.com)
• Infographic: The Changing TV Landscape (readwriteweb.com)
• Evan Shapiro: TV: The Great Uniter? (huffingtonpost.com)
• Ubuntu Expands To TV, A Video Shows A Gorgeous Ubuntu TV Prototype In Action (essayboard.com)

• freebsd linux version is read from a file not from uts
• includes use __restrict not the auto make defined restrict which may not be present in third party packages
• libnucrsesw conditionally linked with watch for 8bit watch

• freebsd linux version is read from a file not from uts
• includes use __restrict not the auto make defined restrict which may not be present in third party packages
• libnucrsesw conditionally linked with watch for 8bit watch

Related articles

• procps-ng version 3.3.2 released (enc.com.au)