Search Results: "zed"

13 March 2011

Francois Marier: Setting up RAID on an existing Debian/Ubuntu installation

I run RAID1 on all of the machines I support. While such hard disk mirroring is not a replacement for having good working backups, it means that a single drive failure is not going to force me to have to spend lots of time rebuilding a machine.

The best possible time to set this up is of course when you first install the operating system. The Debian installer will set everything up for you if you choose that option and Ubuntu has alternate installation CDs which allow you to do the same.

This post documents the steps I followed to retrofit RAID1 into an existing Debian squeeze installation. Getting a mirrored setup after the fact.

OverviewBefore you start, make sure the following packages are installed:
apt-get install mdadm rsync initramfs-tools
Then go through these steps:
  1. Partition the new drive.
  2. Create new degraded RAID arrays.
  3. Install GRUB2 on both drives.
  4. Copy existing data onto the new drive.
  5. Reboot using the RAIDed drive and test system.
  6. Wipe the original drive by adding it to the RAID array.
  7. Test booting off of the original drive.
  8. Resync drives.
  9. Test booting off of the new drive.
  10. Reboot with the two drives and resync the array.
(My instructions are mostly based on this old tutorial but also on this more recent one.)

1- Partition the new driveOnce you have connected the new drive (/dev/sdb), boot into your system and use one of cfdisk or fdisk to display the partition information for the existing drive (/dev/sda on my system).

The idea is to create partitions of the same size on the new drive. (If the new drive is bigger, leave the rest of the drive unpartitioned.)

Partition types should all be: fd (or "linux raid autodetect").

2- Create new degraded RAID arraysThe newly partioned drive, consisting of a root and a swap partition, can be added to new RAID1 arrays using mdadm:
mdadm --create /dev/md0 --level=1 --raid-devices=2 missing /dev/sdb1
mdadm --create /dev/md1 --level=1 --raid-devices=2 missing /dev/sdb2
and formatted like this:
mkswap /dev/md1
mkfs.ext4 /dev/md0
Specify these devices explicitly in /etc/mdadm/mdadm.conf:
DEVICE /dev/sda* /dev/sdb*
and append the RAID arrays to the end of that file:
mdadm --detail --scan >> /etc/mdadm/mdadm.conf
dpkg-reconfigure mdadm
You can check the status of your RAID arrays at any time by running this command:
cat /proc/mdstat

3- Install GRUB2 on both drivesThe best way to ensure that GRUB2, the default bootloader in Debian and Ubuntu, is installed on both drives is to reconfigure its package:
dpkg-reconfigure grub-pc
and select both /dev/sda and /dev/sdb (but not /dev/md0) as installation targets.

This should cause the init ramdisk (/boot/initrd.img-2.6.32-5-amd64) and the grub menu (/boot/grub/grub.cfg) to be rebuilt with RAID support.

4- Copy existing data onto the new driveCopy everything that's on the existing drive onto the new one using rsync:
mkdir /tmp/mntroot
mount /dev/md0 /tmp/mntroot
rsync -auHxv --exclude=/proc/* --exclude=/sys/* --exclude=/tmp/* /* /tmp/mntroot/

5- Reboot using the RAIDed drive and test systemBefore rebooting, open /tmp/mntroot/etc/fstab, and change /dev/sda1 and /dev/sda2 to /dev/md0 and /dev/md1 respectively.

Then reboot and from within the GRUB menu, hit "e" to enter edit mode and make sure that you will be booting off of the new disk:
set root='(md/0)'
linux /boot/vmlinuz-2.6.32-5-amd64 root=/dev/md0 ro quiet
Once the system is up, you can check that the root partition is indeed using the RAID array by running mount and looking for something like:
/dev/md0 on / type ext4 (rw,noatime,errors=remount-ro)

6- Wipe the original drive by adding it to the RAID arrayOnce you have verified that everything is working on /dev/sdb, it's time to change the partition types on /dev/sda to fd and to add the original drive to the degraded RAID array:
mdadm /dev/md0 -a /dev/sda1
mdadm /dev/md1 -a /dev/sda2
You'll have to wait until the two partitions are fully synchronized but you can check the sync status using:
watch -n1 cat /proc/mdstat

7- Test booting off of the original driveOnce the sync is finished, update the boot loader menu:
update-grub
and shut the system down:
shutdown -h now
before physically disconnecting /dev/sdb and turning the machine back on to test booting with only /dev/sda present.

After a successful boot, shut the machine down and plug the second drive back in before powering it up again.

8- Resync drivesIf everything works, you should see the following after running cat /proc/mdstat:
md0 : active raid1 sda1[1]
280567040 blocks [2/1] [_U]
indicating that the RAID array is incomplete and that the second drive is not part of it.

To add the second drive back in and start the sync again:
mdadm /dev/md0 -a /dev/sdb1

9- Test booting off of the new driveTo complete the testing, shut the machine down, pull /dev/sda out and try booting with /dev/sdb only.

10- Reboot with the two drives and resync the arrayOnce you are satisfied that it works, reboot with both drives plugged in and re-add the first drive to the array:
mdadm /dev/md0 -a /dev/sda1
Your setup is now complete and fully tested.

Ongoing maintenanceI recommend making sure the two RAIDed drives stay in sync by enabling periodic RAID checks. The easiest way is to enable the checks that are built into the Debian package:
dpkg-reconfigure mdadm
but you can also create a weekly or monthly cronjob which does the following:
echo "check" > /sys/block/md0/md/sync_action
Something else you should seriously consider is to install the smartmontools package and run weekly SMART checks by putting something like this in your /etc/smartd.conf:
/dev/sda -a -d ata -o on -S on -s (S/../.././02 L/../../6/03)
/dev/sdb -a -d ata -o on -S on -s (S/../.././02 L/../../6/03)
These checks, performed by the hard disk controllers directly, could warn you of imminent failures ahead of time. Personally, when I start seeing errors in the SMART log (smartctl -a /dev/sda), I order a new drive straight away.

8 March 2011

Evgeni Golov: Desktop in a shell: irssi

Continuing my series about my desktop in a shell, in this chapter I will present you my irssi setup.Irssi is the most customized part of my setup, using many scripts from the irssi-scripts Debian package and some from the internet , handling 6 irc networks with a total of 34 channels plus JabberXMPP, ICQ, Twitter and identi.ca. My custom irssi settingsI like my conversations to look like Buddy, you rock instead of Buddy: you rock , so:
/set completion_char ,I also like *long highlighted text*, so:
/set emphasis_multiword onHide mIRC and ANSI colors when turned on. This can be used to eliminate angry fruit salad syndrome in some channels. (Quote from irssi.org/documentation/settings, do I have to say more?):
/set hide_colors onWhen talking in more than one channel, it sometimes comes handy to repeat something from the past said in THAT channel, not searching though all:
/set window_history onTell irssi to shutup when away, noone will hear/see the beep anyways:
/set beep_when_away offI want my screen to inform me about new messages, so I need this:
/set bell_beeps onBeep for query text, notices, dcc, dcc text and hilight:
/set beep_msg_level MSGS NOTICES DCC DCCMSGS HILIGHMy used irssi scriptsactive_notice.pl (from irssi-scripts)Show notices in the active window or the corresponding query instead of the status-window.
No further configuration needed.adv_windowlist.pl (from anti.teamidiot.de)Some really smart windowlist, see my previous post about adv_windowlist.pl, I won t explain its features and settings here again.autorealname.pl (from irssi-scripts)Show peoples real-name when they join (my $nick $name memory is poor :()
No further configuration needed.chansort.pl (from irssi-scripts)Automatically sort my channels alphabetically, grouped by network.
Enable via /set chansort_autosort on<Update>kaimi asked me yesterday, whether chansort could ignore the network and just sort ALL channels in alphabetical order. Well, it could not, until yesterday ;) Fetch either the patch against chansort.pl or my chansort-ng.pl and set chansort_ignore_network to ON. You can also set chansort_ignore_windowtype to mix channels and queries if you like to.</Update>hack-whois-in-current-window.pl (from dgl.cx)Display /whois in the current window or the corresponding query instead of the status-window.
No further configuration needed.keepnick.pl (from irssi-scripts)Restore my nick after it is free again (like after a ping timepout).
Set the nick via /keepnick [-net chatnet] [nick]nickserv.pl (from irssi-scripts)Automatically authorize me on networks with NickServ.
Enable by settings services address, nick and password via:
/nickserv addnet freenode NickServ@services.
/nickserv addnick freenode Zhenech mypass
screen_away.pl (from irssi-scripts)Set away when screen is detached.
Will be enabled automatically, but you maybe want to tweak screen_away_message :)seen.pl (from irssi-scripts)Add a /seen nick command to lookup when and where nick was online the last time.
No further configuration needed.trackbar.pl (from irssi-scripts)Draw a line when you switch irssi windows so you can see which part of the conversation you have already seen.
No further configuration needed.BitlBeeI m using BitlBee as my irssi-to-every-im gateway of choice ;) But while it sounds easy, my setup isn t. I am using BitlBee only to connect to jabber.die-welt.net, my Jabber/XMPP server. There I have a pyICQt instance running, to connect to ICQ via Jabber (yes, BitlBee would support that directly, but that would fail on me when I would like to connect from a different Jabber-client). Twitter and identi.ca are handled via Jabber too: identi.ca does support this by themself, for Twitter I use the tweet.im service.
But besides of my strange setup, BitlBee is easy: apt-get install bitlbee, connect irssi to localhost:6667, you will be force-joined to &bitlbee, where you do:
register somepassword
account add Jabber you@jabberserber.example.com jabberpassword
account on 0
and done, you@jabberserver.example.com is online :)The all awaited screenshot (from my last irssi-post):

And the whole ~/.irssi/config: http://files.die-welt.net/irssi-config.txt, read it carefully while waiting for the next post about newsbeuter :)

3 March 2011

Rapha&#235;l Hertzog: People behind Debian: Christian Perrier, translation coordinator

Christian is a figure of Debian, not only because of the tremendous coordination work that he does within the translation project, but also because he s very involved at the social level. He s probably in the top 5 of the persons who attended most often the Debian conference. Christian is a friend (thanks for hosting me so many times when I come to Paris for Debian related events) and I m glad that he accepted to be interviewed. He likes to speak and that shows in the length of his answers :-) but you ll be traveling the world while reading him. My questions are in bold, the rest is by Christian. Who are you? I am a French citizen (which is easy to guess unless you correct my usual mistakes in what follows). I m immensely proud of being married for nearly 26 years with Elizabeth (who deserves a statue from Debian for being so patient with my passion and my dedication to the project). I m also the proud father of 3 wonderful kids , aged 19 to 23. I work as team manager in the Networks and Computers Division of Onera the French Aerospace lab , a public research institute about Aeronautics, Space and Defense. My team provides computer management services for research divisions of Onera, with a specific focus put on individual computing. I entered the world of free software as one of the very first users of Linux in France. Back in the early 1990 s, I happened (though the BBS users communities) to be a friend of several early adopters of Linux and/or BSD386/FreeBSD/NetBSD in France. More specifically, I discovered Linux thanks with my friend Ren Cougnenc (all my free software talks are dedicated to Ren , who passed away in 1996). You re not a programmer, not even a packager. How did you come to Debian? I m definitely not a programmer and I never studied computing (I graduated in Materials Science and worked in that area for a few years after my PhD). However, my daily work always involved computing (I redesigned the creep testing laboratory and its acquisition system all by myself during my thesis research work). An my hobbies often involved playing with home computers, always trying to learn about something new. So, first learning about a new operating system then trying to figure out how to become involved in its development was quite a logical choice. Debian is my distro of choice since it exists. I used Slackware on work machines for a while, but my home server, kheops, first ran Debian 1.1 when I stopped running a BBS on an MS-DOS machine to host a news server. That was back in October 1996. I then happened to be a user, and more specifically a user of genealogy software, also participating very actively in Usenet from this home computer and server, that was running this Debian thing. So, progressively, I joined mailing lists and, being a passionate person, I tried to figure out how I could bring my own little contribution to all this. This is why I became a packager (yes, I am one!) by taking over the geneweb package, which I was using to publish my genealogy research. I applied as DD in January 2001, then got my account in July 2001. My first upload to the Debian archive occurred on August 22nd 2001: that was of course geneweb, which I still maintain. Quite quickly, I became involved in the work on French localization. I have always been a strong supporter of localized software (I even translated a few BBS software back in the early 90 s) as one of the way to bring the power and richness of free software to more users. Localization work lead me to work on the early version of Debian Installer, during those 2003-2005 years where the development of D-I was an incredibly motivating and challenging task, lead by Joey Hess and his inspiring ideas. From user to contributor to leader, I suddenly discovered, around 2004, that I became the coordinator of D-I i18n (internationalization) without even noticing :-) You re the main translation coordinator in Debian. What plans and goals have you set for Debian Wheezy? As always: paint the world in red. Indeed, this is my goal for years. I would like our favorite distro to be able to be used by anyone in the world, whether she speaks English, Northern Sami, Wolof, Uyghur or Secwepemcts n. As a matter of symbol, I use the installer for this. My stance is that one should be able to even install Debian in one s own language. So, for about 7 years, I use D-I as a way to attract new localization contributors. This progress is represented on this page where the world is gradually painted in red as long as the installer supports more languages release after release. The map above tries to illustrate this by painting in red countries when the most spoken language in the country is supported in Debian Installer. However, that map does not give enough reward to many great efforts made to support very different kind of languages. Not only various national languages, but also very different ones: all regional languages of Spain, many of the most spoken languages in India, minority languages such as Uyghur for which an effort is starting, Northern Sami because it is taught in a few schools in Norway, etc., etc. Still, the map gives a good idea of what I would like to see better supported: languages from Africa, several languages in Central Asia. And, as a very very personal goal, I m eagerly waiting for support of Tibetan in Debian Installer, the same way we support its sister language, Dzongkha from Bhutan. For this to happen, we have to make contribution to localization as easy as possible. The very distributed nature of Debian development makes this a challenge, as material to translate (D-I components, debconf screens, native packages, packages descriptions, website, documentation) is very widely spread. A goal, for years, is to set a centralized place where translators could work easily without even knowing about SVN/GIT/BZR or having to report bugs to send their work. The point, however, would be to have this without making compromises on translation quality. So, with peer review, use of thesaurus and translation memory and all such techniques. Tools for this exist: we, for instance, worked with the developers of Pootle to help making it able to cope with the huge amount of material in Debian (think about packages descriptions translations). However, as of now, the glue between such tools and the raw material (that often lies in packages) didn t come. So, currently, translation work in Debian requires a great knowledge of how things are organized, where is the material, how it can be possible to make contribution reach packages, etc. And, as I m technically unable to fulfill the goal of building the infrastructure, I m fulfilling that role of spreading out the knowledge. This is how I can define my coordinator role. Ubuntu uses a web-based tool to make it easy to contribute translations directly in Launchpad. At some point you asked Canonical to make it free software. Launchpad has been freed in the mean time. Have you (re)considered using it? Why not? After all, it more or less fills in the needs I just described. I still don t really figure out how we could have all Debian material gathered in Rosetta/Launchpad .and also how Debian packagers could easily get localized material back from the framework without changing their development processes. I have always tried to stay neutral wrt Ubuntu. As many people now in Debian, I feel like we have reached a good way to achieve our mutual development. When it comes at localization work, the early days where the everything in Rosetta and translates who wants stanza did a lot of harm to several upstream localization projects is, I think, way over. Many people who currently contribute to D-I localization were indeed sent to me by Ubuntu contributors .and by localizing D-I, apt, debconf, package descriptions, etc., they re doing translation work for Ubuntu as well as for Debian. Let s say I m a Debian user and I want to help translate Debian in my language. I can spend 1 hour per week on this activity. What should I do to start? Several language teams use Debian mailing lists to coordinate their work. If you re lucky enough to be a speaker of one of these languages, try joining debian-l10n-<yourlanguage> and follow what s happening there. Don t try to immediately jump in some translation work. First, participate to peer reviews: comment on others translations. Learn about the team s processes, jargon and habits. Then, progressively, start working on a few translations: you may want to start with translations of debconf templates: they are short, often easy to do. That s perfect if you have few time. If no language team exists for your language, try joining debian-i18n and ask about existing effort for your language. I may be able to point you to individuals working on Debian translations (very often along with other free software translation efforts). If I am not, then you have just been named coordinator for your language :-) I may even ask you if you want to work on translating the Debian Installer. What s the biggest problem of Debian? We have no problems, we only have solutions :-) We are maybe facing a growth problem for a few years. Despite the increased welcoming aspects of our processes (Debian Maintainers), Debian is having hard times in growing. The overall number of active contributors is probably stagnating for quite a while. I m still amazed, however, to see how we can cope with that and still be able to release over the years. So, after all, this is maybe not a problem :-) Many people would point communication problems here. I don t. I think that communication inside the Debian project is working fairly well now. Our famous flame wars do of course still happen from time to time, but what large free software project doesn t have flame wars? In many areas, we indeed improved communication very significantly. I want to take as an example the way the release of squeeze has been managed. I think that the release team did, even more this time, a very significant and visible effort to communicate with the entire project. And the release of squeeze has been a great success in that matter. So, there s nearly nothing that frustrates me in Debian. Even when a random developer breaks my beloved 100% completeness of French translations, I m not frustrated for more than 2 minutes. You re known in the Debian community as the organizer of the Cheese & Wine Party during DebConf. Can you tell us what this is about? This is an interesting story about how things build themselves in Debian. It all started in July 2005, before DebConf 5 in Helsinki. Denis Barbier, Nicolas Fran ois and myself agreed to bring at Debconf a few pieces of French cheese as well as 1 or 2 bottles of French wine and share them with some friends. Thus, we settled an informal meeting in the French room where we invited some fellows: from memory, Benjamin Mako Hill, Hannah Wallach, Matt Zimmermann and Moray Allan. All of us fond of smelly cheese, great wine plus some extra p t home-made by Denis in Toulouse. It finally happened that, by word of mouth, a few dozens of other people slowly joined in that French room and turned the whole thing into an improvized party that more or less lasted for the entire night. The tradition was later firmly settled in 2006, first in Debconf 6 in Mexico where I challenged the French DDs to bring as many great cheese as possible, then during the Debian i18n meeting in Extremadura (Sept 2006) where we reached the highest amount of cheese per participant ever. I think that the Creofonte building in Casar de C ceres hasn t fully recovered from it and is still smelling cheese 5 years after. This party later became a real tradition for DebConf, growing over and over each year. I see it as a wonderful way to illustrate the diversity we have in Debian, as well as the mutual enrichment we always felt during DebConfs. My only regret about it is that it became so big over the years that organizing it is always a challenge and I more and more feel pressure to make it successful. However, over the years, I always found incredible help by DebConf participants (including my own son, last year a moment of sharing which we will both remember for years, i think). And, really, in 2010, standing up on a chair, shouting (because the microphone wasn t working) to thank everybody, was the most emotional moment I had at Debconf 10. Is there someone in Debian that you admire for their contributions? So many people. So, just like it happens in many awards ceremonies, I will be very verbose to thank people, sorry in advance for this. The name that comes first is Joey Hess. Joey is someone who has a unique way to perceive what improvements are good for Debian and a very precise and meticulous way to design these improvements. Think about debconf. It is designed for so long now and still reaching its very specific goal. So well designed that it is the entire basis for Joey s other achievement: designing D-I. Moreover, I not only admire Joey for his technical work, but also for his interaction with others. He is not he loudest person around, he doesn t have to .just giving his point in discussion and, guess what? Most of the time, he s right. Someone I would like to name here, also, is Colin Watson. Colin is also someone I worked with for years (the D-I effect, again ) and, here again, the very clever way he works on technical improvements as well as his very friendly way to interact with others just make it. And, how about you, Rapha l? :-) I m really admirative of the way you work on promoting technical work on Debian. Your natural ability to explain things (as good in English as it is in French) and your motivation to share your knowledge are a great benefit for the project. Not to mention the technical achievements you made with Guillem on dpkg of course! Another person I d like to name here is Steve Langasek. We both maintain samba packages for years and collaboration with him has always been a pleasure. Just like Colin, Steve is IMHO a model to follow when it comes at people who work for Canonical while continuing their involvment in Debian. And, indeed, Steve is so patient with my mistakes and stupid questions in samba packaging that he deserves a statue. We re now reaching the end of the year where Stefano Zacchiroli was the Debian Project Leader. And, no offense intended to people who were DPL before him (all of them being people I consider to be friends of mine), I think he did the best term ever. Zack is wonderful in sharing his enthusiasm about Debian and has a unique way to do it. Up to the very end of his term, he has always been working on various aspects of the project and my only hope is that he ll run again (however, I would very well understand that he wants to go back to his hacking activities!). Hat off, Zack!I again have several other people to name in this Bubulle hall of Fame : Don Armstrong, for his constant work on improving Debian BTS, Margarita Manterola as one of the best successes of Debian Women (and the most geeky honeymoon ever), Denis Barbier and Nicolas Fran ois because i18n need really skilled people, Cyril Brulebois and Julien Cristau who kept X.org packaging alive in lenny and squeeze, Otavio Salvador who never gave up on D-I even when we were so few to care about it. I would like to make a special mention for Frans Pop. His loss in 2010 has been a shock for many of us, and particularly me. Frans and I had a similar history in Debian, both mostly working on so-called non technical duties. Frans has been the best release manager for D-I (no offense intended, at all, to Joey or Otavio .I know that both of them share this feeling with me). His very high involvment in his work and the very meticulous way he was doing it lead to great achievements in the installer. The Installation Guide work was also a model and indeed a great example of non technical work that requires as many skills as more classical technical work. So, and even though he was sometimes so picky and, I have to admit, annoying, that explains why I m still feeling sad and, in some way, guilty about Frans loss. One of my goals for wheezy is indeed to complete some things Frans left unachieved. I just found one in bug #564441: I will make this work reach the archive, benefit our users and I know that Frans would have liked that.
Thank you to Christian for the time spent answering my questions. I hope you enjoyed reading his answers as I did. Subscribe to my newsletter to get my monthly summary of the Debian/Ubuntu news and to not miss further interviews. You can also follow along on Identi.ca, Twitter and Facebook.

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

1 March 2011

Kai Wasserb ch: Weather Forecasts In A KDE Environment

As Squeeze was just released, some might be on the lookout for a replacement for LiquidWeather++, a SuperKaramba script. Others might just search for the first time for a way to have a weather forecast displayed on their desktop. With my yaWP maintainer hat on, I'd like to recommend yaWP for the job. Why yaWP? Short answer: because it's the best (SCNR). Longer answer: because yaWP is easy to use, yet highly customizable. yaWP can track the forecasts of several cities for you, you can put yaWP on your desktop or in your control bar. You can limit the amount of days displayed (in the control bar mode). It's localized for many languages (if your language isn't among the already existing ones, please consider translating yaWP). yaWP can work with multiple services, is themeable and can display a satellite image for your area. Now, some of you might still (don't ask me why) prefer a different Plasmoid for displaying the weather forecasts. But even those can benefit from yaWP and use one of its three data engines (AccuWeather, Google Weather Service and Weather Underground (Wunderground)), thanks to KDE's Weather Ions. Ok, and how does it look? Please remember, that yaWP can be themed, so the picture below just shows one option of many. A screenshot of yaWP displaying data
Included from screenshots.debian.org (License: GPL2 or later + OpenSSL exception)

26 February 2011

Joey Hess: infrastructure update

I'm surprised to be on the porch hearing rushing water. I tend to think of up here as high and mostly dry, but not this time of year. Yesterday was such a soaking rain, very annoying at the time as I did chores and drove out from town. Now there are two little creeks here. That's a sound I've missed.. Pity that all the water is going to waste. I discovered the reason the large cistern is not filling up is simply because the pipe into it is not connected to the feeder pipe in the spring. It seems like a complete shambles really, with layer upon layer of pipes, all broken. I will have to wait until the water is down to dig and find out what's going on, and fix it. In the last of the evening light today I got the house's two battery banks finally combined into one bank. I had planned this out long ago, and bought one long cable I'd need, so was surprised to find I needed two long cables. Had to slide batteries around like a big sokoban puzzle, and swap several cables to make it work. While I was away I'd charged up the bank that had gone unused most of the winter. So they were near equalized and the combination seems to have gone ok. I got through the lean part of the year with only half the batteries; there never seemed to be a good time to combine them. It remains to be seen if the solar panels can keep my increased capacity filled. I hope this was only an early taste of spring. Would be nice to have some more icy weather so I can put off dealing with refrigeration a little while longer. I have my eye on a 12v/propane fridge.

25 February 2011

Patrick Schoenfeld: Let me introduce DPKG::Log and dpkg-report

We have customers, which require a report about what we've done during maintenance windows. Usually this includes a report about upgrades, newly installed packages etc. and obviously everything we've done apart from that.
Till now we've prepared them manually. For a greater bunch of systems this is a big PITA, because to be somehow useful you have to collect the data for all systems and after that, prepare a report where you have:

Its also error-prone because humans make mistakes.

Perl to the rescue!
At least the part about generating a report about installed/upgraded/removed packages could be automated, because dpkg writes a well-formed logfile in /var/log/dpkg.log. But I noticed that there appearently is no library specialised at parsing that file. Its not a big deal, because the format of that file is really simple, but a proper library would be nice anyway.
And so I wrote such a library.
It basically takes a logfile, reads it line by line and stores each line parameterized into a generic object.

Its features include:

Based on that, I wrote another library DPKG::Log::Analyse, which takes a log, parses it with DPKG::Log and then extracts the more relevant information such as installed packages, upgraded packages, removed packages etc.

This, in turn, features:
- Info about newly installed packages
- Info about removed packages
- Info about upgraded packages
- Info about packages which got installed and removed again
- Info about packages which stayed halfinstalled or halfconfigured at the end of the logfile (or defined reporting period)


These libraries are already uploaded to CPAN and packaged for Debian.
They passed the NEW queue very quickly and are therefore available for Sid:

http://packages.debian.org/sid/libdpkg-log-perl

As an example use (and for my own use case, as stated above), I wrote dpkg-report, which uses the module and a Template::Toolkit based template to generate a report about what happened in the given logfile.
It currently misses some documentation, but it works somehow like this:

Report for a single host over the full log:
dpkg-report

Report for a single host for the last two days:
dpkg-report --last-two-days

Report for multiple hosts (and logfiles):
The script expects that each log file has the name <systemname>.dpkg.log so that it can guess the hostname from the system and can grab all such log files from a directory if a directory is specified as log-file arguments:</systemname>

dpkg-report --log-file /path/to/logs

This will generate a report about all systems without any merging.

Report for multiple hosts with merging:
dpkg-report --log-file /path/to/logs --merge

This will do the following:
A (fictive) report could look some what like this:

dpkg-Report for all:
------------------------
Newly Installed:
abc
Removed:
foo
Upgraded:
bar (0.99-12 - 1.00-1)

dpkg-Report for test*:
------------------------
Newly Installed:
blub

dpkg-Report for test1:
------------------------
Upgraded:
baz (1.0.0-1 -> 1.0.0-2)

dpkg-Report for test2:
------------------------
Upgraded:
zab (0.9.7 -> 0.9.8)

Currently this report generator is only included in the source package or in the git(hub) repository of the library. I wonder if it makes sense to let the source package build another binary package for it.
But its only a 238 lines perl script with a dependency on the perl library so I'm unsure if it warrants a new binary package. What do others think?

24 February 2011

Sean Finney: git merge -s theirs

...For the cases where, yes, you actually do want it. For the impatient assuming you're in a clean checkout on the tip of your current branch:
git merge -s ours ref-to-be-merged
git diff ref-to-be-merged   git apply -R --index
git commit -F .git/COMMIT_EDITMSG --amend
you can then double check that everything is as you expect with git diff ref-to-be-merged, which should be empty. The longer story It's noted from time to time that git does not have a -s theirs option to complement the -s ours strategy when merging (or, it did, but it was removed long ago, see below). For those not savvy the idea with git merge -s ours is to pretend as though a merge from some other branch has occurred, though the result remains the current branch's contents, unchanged. This is a neat trick that can be used to show that all changes in some branch have been superceded by the current branch, which can help ease merges further down the line as parallel devlopment continues. However, there is no corresponding -s theirs option, which would conversely say that "everything developed up to here is superceded by this other branch". This feature was discussed and discarded by one of the git authors, who instead advised a developer to throw away the previous work and start on a fresh branch:
One big problem "-s theirs" has, compared to the above "reset to origin, discarding or setting aside the failed history" is that your 'master' history that your further development is based on will keep your failed crap in it forever if you did "-s theirs". Hopefully you will become a better programmer over time, and you may eventually have something worth sharing with the world near the tip of your master branch. When that happens, however, you cannot offer your master branch to be pulled by the upstream, as the wider world will not be interested in your earlier mistakes at all.
In what would probably qualify as "most cases", he's right, but sometimes you do want to do this, and not because you have "crap" in your history, but perhaps because you want to change the baseline for development in a public repository where rebasing should be avoided. In debian, for example, it's pretty common for maintainers who use git-buildpackage to build debian packages from git to have two branches: an "upstream" branch and a "debianized" branch. The upstream branch will follow the changes from the upstream project (either by importing tarballs, or by pulling directly from the project's git repo if they also use git), while the debianized branch contains all the packaging related changes as well as any debian-specific changes to the code. In this context, if the upstream project uses git and rebases their history (out of your control), or if they shift development to a different branch, you might want to have a way to merge with their latest changes without rebasing/abandoning your current debian branch. Hence, a "theirs" merge. The author is totally right that the upstream project may be less interested in pulling from such a repository (since they would drag in the entire previous history), and if that's a problem you might need to splinter off the old branch and start a fresh branch instead. But at least for the projects with which I work, I find that it's more likely that pulling is pretty much one way upstream to debian, and that the patches flow back to the upstream project by way of bug trackers, git format-patch sendmail, or quilt patches sitting in the patch-tracker. And if it becomes a problem later you're no worse off, you can still split off a new branch or take some other action. So anyway, I asked Teh Internetz and found a few hits in the right direction, such as this guy at stack overflow, or this guy here. But from an aesthetic point of view I thought their solutions still left some room for improvement--they were both more complicated, involved setting up temporary branches, and I don't know, just weren't pretty on the eyes. So, ending where I started, this is the relatively clean and easy to follow 3 lines I conjured up, which I will give to teh internetz for posterity.
git merge -s ours ref-to-be-merged
git diff ref-to-be-merged   git apply -R --index
git commit -F .git/COMMIT_EDITMSG --amend
Alternatively, if you want to keep the local upstream branches fast-forwardable, a potential compromise is to work with the understanding that for sid/unstable, the upstream branch can from time to time be reset/rebased (based on events that are ultimately out of your control on the upstream project's side). This isn't a big deal and working with that assumption means that it's easy to keep the local upstream branch in a state where it only takes fast-forward updates. However, on the debian branch your less interested in the clean upstream development, and instead want to keep a sane history of the debianization work, so on this branch you still do something like a merge -s theirs (though in this case, you probably want to amend the previous version's ./debian dir back in post-merge). So applying the same approach as above with the slight modification, in practice (assuming you're on the clean tip of the debian unstable branch, that'd be):
git branch -m upstream-unstable upstream-unstable-save
git branch upstream-unstable upstream-remote/master
git merge -s ours upstream-unstable
git diff ref-to-be-merged   git apply -R --index --exclude="debian/*"
git commit -F .git/COMMIT_EDITMSG --amend
PS In spirit, this is a similar approach to what's done by the XSF team, though I would argue that with what I'm describing both the approach and the resulting history are a bit cleaner and easier to follow. Also, thanks to ron, mrvn, jcristau, and nthykier on #debian-devel for some quick reviewing of this.

23 February 2011

Julien Danjou: Handling my music collection with git-annex

git-annex is a recent tool allowing to manage files with git without having theirs contents checked into git. I've been looking at it with some interest in the past few weeks in order to use it to handle my music collection on the various computers I use. My laptop just got a new SSD drive which is quite small and cannot handle the whole collection. By using git-annex, I'm now able to only check out part of my music collection and keeping it synchronized with all my others computers. Using git-annex is pretty trivial once you understand the concepts. I've set up a a git repository in my Music directory, like that:
% git init
Initialized empty Git repository in /home/jd/Music
Then I initialized git annex:
% git annex init "Music on keller"
So now I'm able to import all my date into git annex. git-annex offers several backends to store data. WORM is the default, but is not a good choice for file that could be modified, and music files can be, at least when editing the metadata. Therefore, I chose the slow but more reliable SHA1 backend.
% git annex add --backend=SHA1 .
That can be long, so you should be patient. Then you should commit the fact you annexed files:
% git commit -a -m "Imported my music collection"
[master 82d060f] Imported my music collection
Now, it's done. You can go on another computer and clone the repo:
% git clone ssh://keller/~/Music
% cd Music
% git annex get "Incubus - Light Grenades"
And then let the magic happens. It will retrieve the whole directory for you. Do not forgot to commit the fact that you got those album on that machine! The concept used by git-annex is quite simple. All files are replaced by symlinks pointing to .git-annex/SHA1:filechecksum.log. This file contains lines, whose format is:
retrieval-timestamp is-file-present uuid-of-the-repository
Indicating if the file is present in a repository. This logs file are commited into the repository, whereas the real content is stored in the .git/annex directory and therefore not commited. I recommend to take a look to the walkthrough page to get more idea and what you can and cannot do with git-annex. Flattr this

22 February 2011

Erich Schubert: Taking Google Calendar to the limits

The Global Lindy Hop Map I've built as a toy project is actually a calendar with geo annotated events. It currently is backed by a custom database using Xapian for the search functionality to improve performance.
The data comes from around 150 Google calendars from various dancing communities. I'm preprocessing the data to have reliable geo information as well as doing some filtering and HTML formatting.
Instead of putting everything into my own database - which doesn't know about recurrence rules, but relies on materialized recurrences - I've also tried to sync all 150 calendars into one huge "master" calendar.
However, using the Google Gdata APIs to access this calendar takes way too long for the website to be usable. This is not too surprising, there are like 3500 instances in the calendar and some of this will require the computation of recurrence rules. And I cannot do the synchronization without a local ID mapping cache anyway (I can recover a lost cache from additional information I put into the calendar though). There are around 60 event instances per day, since most come from weekly repetitions.
The HTML embed rendering can take quite a while to load (albeit the results apparently are cached somewhere) - looking at december either hits some processing limit or times out after around 40 seconds.
Looks like I'm going beyond the scope Google Calendar was designed for. :-)

17 February 2011

Cyril Brulebois: Debian XSF News #5

Time for a fifth Debian XSF News issue!

16 February 2011

David Welton: The UnderPerformingStocks.com sale - halfway in

A few weeks ago, I had an "out-there" idea to try creating and selling a site at the same time. So far, it's not exactly raking in a major amount of cash: www.underperformingstocks.com is For Sale on Flippa! At $100 with a couple of bids, it doesn't look like I'll be able to retire on it! That said, I haven't spent a great deal of time on it, and part of the idea of the experiment was to limit the amount of time the 'new idea' would distract me from other things. I did hope to receive a few more "audience requests" in terms of what to build on Flippa.com, though. Hopefully, things will heat up a bit during the final two weeks of the auction, but I don't think "flipping" web sites is really a business I want to be in. It's been fun to see how much you can build with how little, though, what with all the widgets and API's out there these days. Since I'm a coder at heart, I also released some Ruby code that utlizes Google's stock screener API: https://github.com/davidw/google-screener - it's under the Apache license, and is kind of neat to play around with, I think, and is what I use to fetch information for the site.

14 February 2011

Bernd Zeimetz: debian buildds still fail on complex dependencies

Not only that it took 4 years to fix #403246 (sbuild dependancy resolution fails when b-dep on A B ; A uninstallable), but our lovely Debian buildds still don't accept packages which use such a dependency due to running too old sbuild versions. Time to get rid of this annoying bug finally!

John Goerzen: Lots of Snow, Being Stuck, and Fun

Those of you that watch my twitter know that we got dumped on with snow recently. The final estimate reported by local papers is 17 to 19 inches. IMG_5301.JPG That s my car. You might understand why I went home at 1PM Tuesday and worked from home the rest of the afternoon. The county didn t get the roads opened until 5:30PM Wednesday, so we were stuck. Terah s dad kindly opened the driveway for us though. Without that, we wouldn t have even known where it was. marla-IMG_4180.JPG Jacob and Oliver loved playing in the snow. It was a HUGE hit for them. Both of them hated to go back inside when it was time. Oliver had trouble walking, or even standing up, but that didn t stop him from begging for more every chance he got. IMG_5345.JPG On Saturday, I took Jacob outside to play. We had in mind building a snow tunnel. We went to one of the big piles of snow left by the tractor after our driveway was cleared, and I dug out a space underneath it that Jacob could crawl through. He got a little scoop (he insisted on calling it my shovel ) and helped dig too. He had a great time with it. He was very anxious to go inside, and it probably didn t help his eagerness that the cats could freely walk through it long before he could. They were around and taking a great interest in the proceedings. One of then stretched out on my back while I was stretched out pulling snow out from the pile. Finally Jacob got to go through. He had a little trouble because it wasn t tall enough for him to crawl like he usually does (though still plenty big for him to get through with lots of room to spare), but he came out beaming. I then went and got the camera and got some photos of his second trip through. IMG_5424.JPG You d think that this might be the highlight of a 4-year-old s snow excursion. And given his excitement, you might be very convinced of that. But you d be wrong. What Jacob really wanted was a snow train. So I drew some train track-sized lines in the snow with my shovel. Then I was supposed to draw a train engine. He had been planning this for hours before we even went outside, and I knew very well what was supposed to go on the engine: a snowball for a headlight. We then added passenger cars and a coal car, because apparently that s what you do with snow trains. And the result: IMG_5445.JPG When we went inside, Terah asked Jacob about his snow experience. Jacob was very happy, until she asked him if his snow train was a real train or a drawing of a train. Then he became very sad when he said it was a drawing of a train, and decided it was not what he wanted AT ALL. So today we went out again. This time I built a snow train that stands up, complete with snowballs for wheels. I asked him if it was right, and he kept saying, No, I want a REAL train. Finally I asked him what the difference between a real snow train and this one was. Apparently a real train would be on tracks, move around, make noise, and take us places. Fortunately he didn t dwell too long when I explained I couldn t build one of those. And then today s highlight was writing JACOB in the snow. He had started by drawing larger and larger J letters with his arm, and finally asked me to make one. I made footprints in the shape of a very large J, which he loved. He had me make another one, and then the rest of the letters in his name.

12 February 2011

Joey Hess: d-i is ten

I just realized that the Debian Installer is ten years old! It actually got started ten years ago last summer, but now is also an apt anniversary -- ten years ago, I successfully booted d-i for the first time. It's amazing that d-i has been around as long as Debian Developers who have "been with the project longer than most". (Many of whom have been long-time contributors to d-i themselves.) Astonishing that my basic design has held up and remains relevant. And every time I boot up the Debian kFreeBSD installer, or run the graphical installer, or hear someone raving about how easy Ubuntu was for them to install (and know d-i was underneath), I'm amazed at the places people have taken d-i. The code has recently moved to git. As changes like ext4 by default start to flow in to d-i, with Wheezy development starting up, I hope to see more people enticed into working on d-i. Anyone can do like Matthew Palmer has done with netcfg -- pick a component of d-i that interests you, check out its git repository, and take it from being reasonably well team-maintained to awesomely you-maintained. In five or ten years Matthew will be able to look back at all the people who have used d-i to install over IPv6, and on WPA wireless, and with his other netcfg improvements. Trust me, it's a great feeling. Previously: d-i retrospective (better written than the above & well worth a re-read)

David Welton: Book Review: Start Small, Stay Small, A Developer's Guide to Launching a Startup

<iframe frameborder="0" marginheight="0" marginwidth="0" scrolling="no" src="http://rcm.amazon.com/e/cm?lt1=_blank&amp;bc1=000000&amp;IS2=1&amp;bg1=FFFFFF&amp;fc1=000000&amp;lc1=0000FF&amp;t=dedasys-20&amp;o=1&amp;p=8&amp;l=as4&amp;m=amazon&amp;f=ifr&amp;asins=B003YH9MMI" style="width: 120px; height: 240px; float: left; margin-right: 10px;"></iframe> I tend to be a sucker for business books, to the point where I created (and later sold) a site to discuss them. Part of the motivation for creating that site was that a lot of them tend to contain one good idea, and an inordinate amount of fluff. This book does not - it's good material that could not easily be summarized because it's full of information. I think it's actually one of the more relevant books I've ever read in that, for my situation, the idea behind it really speaks to me. I work as a consultant during the days, and I like it a lot. Rather than working on the same old thing year after year, I get to meet new people, new clients, new situations, and help them out, which is motivating. However, consulting has its downsides too, in that it doesn't create a great deal of long-term value. Once you've finished up a project, it's on to the next one, or no money comes in. I'm also a bit older and more set in my ways: I did my time in the California Bay Area, and I don't relish going back and working like mad on a "Real Startup" with VC backing, crazy hours, and having the thing consume my life. The idea behind "Start Small, Stay Small" is to find and create really niche products: stuff that will earn you some extra money as a developer, but also niches that are small enough to not really be interesting to larger companies that need a lot of income to justify a forray into a particular market segment. This, then, becomes your 'competitive advantage': Microsoft, or even 37 Signals, simply isn't going to chase after a market that is worth 20,000 dollars a year. And yet for someone working on their own, if you manage to set up something that brings in that money, and mostly automate it so that it's not a second job, it's a tidy extra bit of money. Several projects like that might even be enough to live on, depending on your lifestyle. With that in mind, the authors, Rob Walling and Mike Taper, delve into the details of how to go about doing so. The whole thing is done under the assumption that you don't have a lot of time or money to throw at things that don't bring in concrete results in relatively short order. Various subjects discussed in detail include how to find a niche, how to create a sales web site, how to measure market demand, conversion rates, how to productively outsource less critical portions of your business, and much more. They also discuss what sorts of numbers to look at for various aspects of the business, and anchor the discussion with real numbers for many things, rather than just giving you a hand-wavy phrase that's not that useful in the real world. It's not a 'timeless' book as all the concrete numbers and techniques reference technologies, sites, and the market dynamics of 2011, but after all, that's part of what makes it good. Other things I didn't like so much were being sold on their for-pay "micropreneur community", and the relatively high price of the book but I think it's worth it given the real advice you get. If you don't like marketing, and think that products succeed or fail on their merits alone, of course the book will leave you cold, but of course you're wrong about that anyway!

11 February 2011

Julien Viard de Galbert: Triage X Bugs of the Week (TXBW12)

This report is 2 week late It was delayed by an important event, not the release of squeeze, but the birth of my first child: C lestine is born Monday the 31th of January. My wife and C lestine are both fine now but the firsts days were not that easy. I m starting to recover from the lack of sleep, but I m still very late on my debian tasks ;) So I guess I just drop Triaging for week 13, 14 and maybe 15 Now the bugs I triaged just before : The X Strike Force (still) needs you ! You can have a look at the X Strike Force Bug Closing Procedure and check XSF unstable bugs sorted by date.

10 February 2011

MJ Ray: OpenBiblio Principles

There s a lot of exciting activity going on around libraries at the moment. One of them is the OpenBiblio Principles, which are:
  1. When publishing bibliographic data make an explicit and robust license statement.
  2. Use a recognized waiver or license that is appropriate for data.
  3. If you want your data to be effectively used and added to by others it should be open as defined by the Open Definition (http://opendefinition.org) in particular non-commercial and other restrictive clauses should not be used.
  4. Where possible, explicitly place bibliographic data in the Public Domain via PDDL or CC0.
Happily, our co-op has decided to support these principles. I feel that the third one is particularly important: non-commercial clauses lock out many cooperatives and social enterprises from sharing and helping. If you ve got an idea for an app using open bibliographic data (you can enter the idea or a prototype app), you ve just about got time to enter the OpenBiblio Challenge before it closes on 17 February and win some money. Good luck!

9 February 2011

Richard Darst: whiteboard.debian.net

A while ago (early 2009), I created whiteboard.debian.net as a way to do real-time editing collaboration. While working for DebConf, I really wanted to be able to collaboratively edit text with people, and all of the web-based solutions I found at the time were non-free. Thus, I took mobwrite and wrote a very thin wrapper around it. Mobwrite is where all the cleverness is (and mobwrite is way beyond my expertise, by the way). Mobwrite is Apache licensed, so you can use it in other places, too.Thus, whiteboard.debian.net was begun. It was never publicized very much. It has no authentication required and no history (the "static link" does provide limited recovery for mistakes, though). Here is a test whiteboard; open it in two tabs and watch the text areas sync. Any whiteboard is created if you go to a valid URL.I just deployed a slightly newer version of whiteboard. You can now see an options page for each whiteboard, and it can render in several lightweight markup languages (good for drafting+previewing things). If you have other options to add there, let me know.If you are interested in collaborative text editing, there are some other options. There is a Debian titanpad, an "open" instance of now-open-sourced Etherpad, and it has history support. Use titanpad.com and you don't have to log in. Here is a test pad. For a non-web application, Gobby exists. Use gobby-0.5 for smart undo history if everyone uses squeeze or above.Is whiteboard still relevant in light of the options above that store history? I'm sure it depends, but for now, whiteboard works well for a low-overhead scratch space and for cases where you don't want to have a history trail. I also tend to use it as a simple pastebin or a personal notepad when I don't want to worry about having traces left behind. In short, it is so minimal you don't have to think about starting one up for something. I have found that collaborative writing really helps to get things done, thus, I hope that whiteboard (or a similar tool) can be useful to you.

8 February 2011

Joey Hess: mapping git repositories

Git has lots of tools to map the history of a git repository. But, I have not been able to find tools to map networks of git repositories. Possibly noone has done it because such networks tend to be pretty centralized really, with low levels of (visible) interconnection, and so not that interesting, like this network of all known branches of ikiwiki. Soon after I started using git-annex, I realized the repositories using it would tend to be more interconnected, and less centralized, and generally a more complex, rich fabric than I'd seen in my use of git before. So I've built "git annex map", which uses graphviz to spit out fun maps like this. (Green nodes are trusted drives; red nodes are not currently available.)
Previously: git tube map

7 February 2011

Alexander Reichle-Schmehl: What a night! What a day!

Wow, that was a night. I'm still quite tired from the weekend. Someone told me, that ~ 1 000 people subscribed to our live denting via identi.ca, and about 12 000 via twitter. And that does not even include those, who followed us via the respective web interfaces! While it was quite exhausting (we tried to watch about 7 irc channels for the important stuff, I partly had ~80 windows in my irssi (which is especially bad, since I only have keyboard shortcuts for the first 40) and there whas also a constant need to watch for mails and due to translations also our spamfilters), it was also very nice to think that somewhere there are release parties going on with people looking at our dents, maybe even having them running on a big monitor or projector ;) One thing that remains to be done, are the left-over dents we prepared as time killers: Since the release process went quite smoothly (and we didn't have the time to check all our dents for the limit of 140 chars ;) we still have some of them left. Since some of them where requested (and I poked other people to get me the numbers) here are the remaining dents: I especially like the one about debian-curiosa ;) Update 1: The 600 USD where collected during DebConf5, not DebConf3. Update 2: Small clarification about the number of subscriptions on identi.ca and twitter: They didn't followed a live-stream channel, but they do follow our general channel. We are not sure, how many people where subribed before we announced the live denting; some saw 700 subscribers on identi.ca, which would mean ~200 seem to have subscribed for the release dents (still not including the ones just following us the old fashioned way via a browser).

Next.

Previous.