The boys loved climbing up and down these areas, some of which were quite tall. They discovered different kinds of rock on the way up and down, and with my help avoided discovering too much of the mud at the bottom.
We hiked back to our camping spot through grass almost as tall as Oliver much to his delight and then after warming up by the fire for a bit, went off in the other direction. There is a grove of trees by the creek over there, which surprise became another train. Here are the boys explaining how it works.
<iframe allowfullscreen="allowfullscreen" frameborder="0" height="315" src="https://www.youtube.com/embed/43EcEK8F_ic?rel=0" width="560"></iframe>
They helped pack things back up, too. Actually, it took some convincing to get Jacob to not pull up all the stakes for the tent before I was ready for them.
Things didn t go perfectly, but then, they never do, and that was OK with everyone. Camping is an adventure, and it wouldn t be an adventure if you knew every detail beforehand.
It is rare in life to be able to think that I have enough time to do anything the boys might want to do. Spend half an hour pretending a tree is a train sure, no problem.
Today Oliver asked to go camping again, and was a bit disappointed when I didn t agree to go camping again right this minute, today. Jacob said, we had an EXCELLENT time and gave me hugs thinking about it.
I have a lot of happy memories about the creek. We camped at the same spot where I went fishing or camped as a child. There have been family gatherings and even a birthday party out there. The boys and I have enjoyed a hike or a wagon ride to the area, but as I learned, nothing could possibly match the excitement of camping there.
It is wonderful to add another happy memory of a time at the creek. And it s even better to see another generation of Goerzens discover that there s a lot of fun to be had down by the creek.
In the 3.x days of KDE, there were some wonderful applications. One of them I still admire, is kscope. Recently, I stumbled upon this blog entry and thought of sharing my living with kscope.The move from KDE 3 to KDE 4 was a big one. During that move, the kscope author decided to port kscope to a Qt only application. That is what we have as the latest kscope, 1.9x version. But, on personal taste, it is not as good as the 1.6x series.With no viable replacement to my knowledge, making use of kscope 1.6x on Debian (and Ubuntu) was the choice. Thanks to the way it is all packaged by the KDE, it is easy.Kscope depends on 2 packages for its functionlity: kdelibs4c2a and kate. kdelibs4c2a is unsupported, but for the dire needs, you live with it. The library can be easily pulled from the snapshot website, or just get the package from the old distribution URLs. The same goes for kate and kscope (1.6x)Install the kdelibs4c2a package. 16:55:27 rrs@champaran:~$ apt-cache policy kdelibs4c2a
kdelibs4c2a:
Installed: 4:3.5.10.dfsg.1-5
Candidate: 4:3.5.10.dfsg.1-5
Version table:
*** 4:3.5.10.dfsg.1-5 0
100 /var/lib/dpkg/status
libkateinterfaces.so.0@ libkateutils.so.0@libkateinterfaces.so.0.0.0 libkateutils.so.0.0.0

Many of the SAN components in Debian have me involved. So I think out to give an update on what the state of SAN would be in Debian Wheezy. Open-iSCSI: Just uploaded a newer version to experimental which eventually will crawl into testing. It should fix all release goals for Wheezy. Please give it a good testiscsitarget: Same goes here. This one is already in testing. Please test. It has some bugs reported, all in needinfo, as they haven't been easily reproducible or reported complete.multipath-tools: It is in pretty good shape. Some minor bugs. But still, please test. :-)Open-FCoE: Being dependent on hardware, for which I couldn't manage resource commitment, this one is literally untested. It lies in testing, untested.LIO Target: The newest target implementation for Linux. It is also available in testing, has had some minor bugs reported by users, and fixed. If you use, or anticipate to use it in the Wheezy life cycle, now is the time to test.
apport just cleared the new queue and is now available in experimental. For those who do not know what apport is:At this moment, it is quite broken. The crashes are not intercepted by update-notifier on my box. With it now in experimental, my intent is to slowly integrate it well with all dependent tools for Debian. It won't be ready for the Wheezy release, but hopefully for the one after that.On the Ubuntu side, Canonical hosts a retracing service that takes user reported core dumps and generates a usable backtrace. For Debian, my plan is to have a chroot kind interface, where in the user could opt-in to download all debug packages to generate a valid backtrace. This could go as the debian backend for apport in the future. On the bug reporting side, afaik, we do not have a web interface to lodge bugs. To report bugs (minus the core dumps), we will want a backend to submit it over email. The current apport report gathering tool is pretty good (if compared to other tools like reportbug), so here the low hanging fruit would be to just take the report and feed in email to our BTS server. For the eyes:Debugging program crashes without any automated tools has been pretty time consuming and hard for both developers and users. Many program crashes remain unreported or unfixed because:
- Many crashes are not easily reproducible.
End users do not know how to prepare a report that is really useful for developers, like building a package with debug symbols, operating gdb, etc.
- A considerable part of bug triage is spent with collecting relevant information about the crash itself, package versions, hardware architecture, operating system version, etc.
- There is no easy frontend which allow users to submit detailed problem reports.
- Existing solutions like bug-buddy or krash are specific to a particular desktop environment, are nontrivial to adapt to the needs of a distribution developer, do not work for crashes of background servers (like a database or an email server), and do not integrate well with existing debug packages that a distribution might provide.
Apport is a system which
- intercepts crashes right when they happen the first time,
- gathers potentially useful information about the crash and the OS environment,
- can be automatically invoked for unhandled exceptions in other programming languages (e. g. in Ubuntu this is done for Python),
- can be automatically invoked for other problems that can be automatically detected (e. g. Ubuntu automatically detects and reports package installation/upgrade failures from update-manager),
- presents a UI that informs the user about the crash and instructs them on how to proceed,
- and is able to file non-crash bug reports about software, so that developers still get information about package versions, OS version etc.
A while back, I was thinking. Playing the flute or whistling on a
bottle is the exact same technique; but, in my opinion, the sound that
comes from a bottle has some interesting overtones, making for a nice
sound. Since the material of which an instrument is made is in large
part responsible for the overtones that it produces (apart from the
technique used by the musician), I wondered if nobody had ever come up
with the idea of making a flute in glass.
Turns out that, of course, this has already happened. In fact, the
modern concert flute wouldn't have been possible without one Claude
Laurent, a Parisian instrument maker who received a patent for "a new
[method of] making flutes from crystal"; part of his patent described a
method of attaching the valves to the instrument. It was this method
which was used by Theobald Boehm when he invented the fingering system
that defines the modern concert flute.
The price of an intact Laurent flute today is, of course, beyond my
budget; and it doesn't look like there are any glass flutes being made
that use the Boehm system. But that doesn't mean there aren't
any glass flutes being made anymore; indeed, a short look
around the Internet quickly turned up Hall Crystal Flutes, a family-owned
business from Rochester in the US state of Washington. As the price was
not too insane (49 USD for the instrument, plus almost the same amount
for shipping it to Belgium), I ordered one of their piccolos in C.
Last wednesday, a woman from the post office rang my doorbell, with a
pakage containing the new instrument. Unfortunately, however, it had a
customs tax of slightly more than what was in my wallet at the time,
which meant I could only fetch it from the post office the next day. At
least I could pay in plastic there.
After having had it for a few days, I can make a few
observations:
setcap cap_net_raw+ep /usr/sbin/vbladevblade gets the mac address of the initiator, the shelf and slot number, the network device and the block device.
/usr/sbin/vblade -m $mac 0 0 eth0 $dev
apt-get install atftpd ipxe ln -s /usr/lib/ipxe/undionly.kpxe /var/lib/tftpboot
if exists user-class and option user-class = "iPXE" filename ""; option root-path "aoe:e0.0"; else filename "undionly.kpxe";
#!/bin/sh case $1 in prereqs) echo "udev" exit 0 ;; esac . /usr/share/initramfs-tools/hook-functions copy_exec /sbin/aoe-discover manual_add_modules aoe/etc/initramfs-tools/scripts/local-top/aoe:
#!/bin/sh case $1 in prereqs) echo "udev" exit 0 ;; esac ifconfig eth0 up sleep 10 modprobe aoe aoe-discover udevadm settle --timeout=30

Francesca Ciceri, photo by Andrew McMillan, CC-BY-SA 2.0
To my great surprise, no one treated me like an idiot for that error.Since then, I joined the WWW team and helped them apply the shiny new design provided by Kalle S derman. A lot of work was done during the week immediately before the release of the new website. Oh that was a week! We worked night and day to have the new design ready for February 6th, and it was fantastic when we finally published it, simultaneously with the release of Squeeze. At the same time, I started to contribute more actively to the Debian Publicity team, not only translating news but also writing them. It can sound scary for a non native English speaker to write something from scratch in English, but you have to keep in mind that your text will be reviewed by native speakers before being published. And we have some fantastic reviewers in the English localisation team: particularly Justin B Rye, who is tireless in his effort and more recently Moray Allan. I think I m particularly lucky to work with all these people: there s a special mood in both Publicity and WWW team, which makes you feel happy to do things and at the same time pushes you to do more just because it s fun to work with them sharing jokes, ideas, rants, patches and hugs. Rapha l: I believe that you have been trough the new member process very quickly. You re now a Non-Uploading Debian Developer. How was the experience and what does this mean to you? Francesca: Becoming a Debian Developer was not so obvious for me, because I didn t need to be a DD for the work I do in Debian. For instance, I don t maintain packages, so I had no reasons to want to become a DD in order to have uploading rights. For a while I didn t really feel the necessity of being a DD. Luckily, some people started to pester me about it, asking me to apply for the NM process. I remember Martin Zobel-Helas doing this for an entire week every single day, and Gerfried Fuchs doing it as well. Suddenly, I realized that people I worked with felt that I deserved the DD status and that I simply had thought I didn t. As a non coder and a woman, there probably was a bit of impostor syndrome involved. Having people encouraging me, gave me more confidence and the desire to finally become a DD. And so I did. The process for non uploading DD is identical to the one to become an uploading DD, with one exception: in the second part of the process (named Tasks and Skills) instead of questions about how to create and maintain packages, there are questions about the non packaging work you usually do in Debian. The general resolution which created the possibility to become a non uploading DD gave us a chance to recognize the great effort of Debian contributors who work in various area (translations, documentation, artworks, etc.) that were not always considered as important as packaging efforts. And this is great because if you are a regular contributor, if you love Debian and you are committed to the project, there are no reasons to not be an official member of it. With regards to this, I like the metaphor used by Meike Reichle in her recent talk about the Debian Women Project (video recording here):
a Debian Developer status is a lot like a citizenship in a country that you re living in. If you live in a country and you don t have citizenship, you can find a job, buy a house, have a family [...] but if this country at any point in time decides to go into a direction that you don t like, there s nothing you can do about it. You are not in the position to make any change or to make any effect on that country: you just live there, but there s no way that you can excercise influence on the people who run this country.Rapha l: You recently joined the Debian Press Team. What does it involve and how are you managing this new responsibility? Francesca: The Press Team is basically the armed wing of the Publicity Team: it handles announcements that need to be kept private until the release, moderate the debian-announce and debian-news mailing list and maintain contacts with press people from outside the project. The real job, so, is done within the Publicity Team. The most important part of our work is to write announcements and the newsletter: while the newsletter is published bi-weekly, the announcements need to be write in a shorter timeframe. Localization is really important in spreading Debian word, so we work closely with translators: both announcements and DPN are usually translated in four or five different languages. The publicity work could be stressful, as we have strict deadlines, we need to take quick decisions and often do last-minute changes. Personally, I like it: I work better under pressure. But I know that is sometimes difficult for contributors to accept that we can t debate endlessly on details, we have just to go on and do our best in a given timeframe.
The publicity work could be stressful, as we have strict deadlines, [ ]. Personally, I like it.Raphael: You re one of the main editor behind the Debian Project News. What s the role and scope of this newsletter? Francesca: Debian Project News is our beloved newsletter, direct successor of the Debian Weekly News founded by Joey Hess in 1999 and later kept alive by Martin Schulze. In 2007, Debian Weekly News was discontinued but in 2008 the project was revived by Alexander Reichle Schmehl. The idea behind DPN is to provide our users an overview of what is happening inside and outside the project. As the core team of editors is formed by three people, the main problem is to be able to collect enough news from various sources: in this sense we are always glad when someone points us to interesting blogposts, mails and articles. DPN is also a good chance for non coders to contribute to Debian: propose news, write paragraphs and review the draft before the publication are quite easy tasks but very useful. English native speakers can do a proofread (as no one of the main editors is a native speaker) while others can always translate DPN in their native language. People who want to help us can take a look at our wiki page.
DPN is also a good chance for non coders to contribute to Debian.Just yesterday I realized that since January we don t miss or delay an issue: so I d like to thank the fantastic team of editors, reviewers and translators who made it possible. The team is now working on another way of spreading Debian s message: a long-time project is finally becoming real. Stay tuned, surprise arriving! Raphael: You re trying to organize IRC training sessions but that doesn t seem to take off in Debian, while it s quite common in the Ubuntu community. How do you explain that? Francesca: I m not sure about it: both Debian users and contributors seemed to appreciate this initiative in the past. I was quite surprised by the amount of Debian members present during the various sessions and by the amount of interesting questions asked by the users. So the only reason I can think about is that I need to put more enthusiasm in convincing the teams to do it: they need more encouragement (or to be pestered more!). I, for myself, think that IRC training sessions are a great way to promote our work, to share our best practice, to talk about our project to a wider audience. And I ll sure try to organize more of them. Help, suggestions, ideas are really welcome! Raphael: If you could spend all your time on Debian, what would you work on? Francesca: There is a project I d like to give more love, but I always end up without the time to do it: the debian-community.org project. Back in 2007, Holger Levsen founded it with the aim of reducing the gap between Debian contributors and Debian users, giving all an opportunity to contribute, share ideas and more. The project was discontinued and I d really like to revive it: in these years various things have changed, but I think that the core idea of having a node to connect existing local communities is still good and doable. In Debian we don t have the wide and well articulated local infrastructure present in other distributions (Ubuntu, particularly, but also Fedora): even if I don t like too centralized structures, I think that a better connection between the project and local groups of users and on-line communities would be a step forward for the project. Being part of the Events Team, I m aware of how much we need to improve our communication with local groups. An example is the events organization: sometimes, Publicity and Events teams even don t know about regional Debian related events (like booth at conferences, workshops, talks, install parties, etc) and this is a shame because we could offer a lot of help in organizing and promoting local events. What we lack is better communication. And debian-community.org project could give us exactly this. Could be a cluster of local groups, a platform for events organization and even a useful resource for newbies who want to find a local group near them. I started some effort in this sense, sending a proposal about it, working on a census of Debian local groups. Any help is appreciated! I m really curious to see how many Debian communities (from all around the world and the web) are out there, and I d love to have members from these communities better connected with the Debian Project. Raphael: What s the biggest problem of Debian? Probably the bikeshedding feticism of almost all of us. It s the other side of the coin of Debian s commitment to technical excellence and our perfectionism, but sometimes it leads just to endless discussions about details, and it is a blocker for various initiatives. In Debian, you have to be really patient and in a way stubborn to push some changes. This is frustrating sometimes. On the other hand, I really appreciate how people take some times to think to each proposals, give some feedback and discuss about it: the process could be annoying, indeed, but the result is often an improvement of the initial proposal. Raphael: Is there someone in Debian that you admire for their contributions? Most of my teammates are simply brilliant and adorable and hard-working. But I have to admit that I particularly admire David Pr vot: beside being a webmaster he does a lot of things, from French translations to DPN editing. All his contributions have a great quality and he s able to push you always further in doing things and doing them better. He is a good example of how I d like to be as contributor: smart, tireless, friendly.
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, Google+, Twitter and Facebook.
3 comments Liked this article? Click here. My blog is Flattr-enabled.
Falcon is a programming language which is not yet packaged for
Debian. I saw that the ITP#460591 is owned by my Debian
mentor and good friend Kartik Mistry. So I jumped in to
help him finish this package.
Ok enough of introduction now directly to point. We thought its better to base
the Debian package on upstream Git repository itself so we can do snapshot release like Go Language
package is doing. So in this post I'm going to give steps we used to do this and also guidelines
on future packaging of Falcon.
git clone http://git.falconpl.org/falcon.git
git checkout -b upstream
git remote add upstream-falcon http://git.falconpl.org/falcon.git
git branch --set-upstream upstream-falcon
git checkout master
git remote set-url origin git.debian.org:/git/collab-maint/falconpl.git
git checkout upstream
git archive --format=tar HEAD gzip -9 > ../falconpl_0.9.6.8-git20120403.orig.tar.gz
git tag upstream/0.9.6.8-git20120403
pristine-tar commit ../falconpl_0.9.6.8-git20120403.orig.tar.gz
Since installing a whiteboard in our kitchen, conversations at the
Acetarium have been moving in new and interesting directions.
For example, Mika and I recently noticed that, when rotated correctly, the
skeletal formula for 2,3-dimethyl-2-butanol looks pretty friendly!
I look after a lot of systems, and most of them want identical and simple backups taking of their filesystems. Currently I use backup2l which works but suffers from a couple of minor issues.
In short I want to take a full filesystem backup (i.e. Backup "/"). I wish to only exclude a few directories and mounted filesystems.
So my configuration looks like this:
# List of directories to make backups of.
# All paths MUST be absolute and start with a '/'!
SRCLIST=( / /boot -xdev )
# The following expression specifies the files not to be archived.
SKIPCOND=( -path '/var/backups/localhost' -o -path '/var/run/' -o \
-path '/tmp' -o -path '/var/tmp' \
-o -path '/dev' -o -path '/spam' \
-o -path '/var/spool/' )
The only surprising thing here is that I abuse the internals of backup2l because I know that it uses "find" to build up a list of files - so I sneakily add int "-xdev" to the first argument. This means I don't accidentally backup any mounted gluster filesystem, mounted MySQL binary/log mounts, etc.
backup2l then goes and does its jobs. It allows me to define things to run before and after the backup runs via code like this:
# This user-defined bash function is executed before a backup is made
PRE_BACKUP ()
if [ -d /etc/backup2l/pre.d/ ]; then
run-parts /etc/backup2l/pre.d/
fi
So what is my gripe? Well I get a daily email, per-system, which shows lots of detail - but the key thing. The important thing. The thing I care about more than anything else, the actual "success" or "fail" result is only discoverable by reading the mail.
If the backup fails, due to out of disk, I won't know unless I read the middle of the mail.
If the pre/post-steps fail I won't know unless I examine the output.
As I said to a colleague today in my view the success or failure of the backup is the combination of each of three distinct steps:
Subject: Backup Success - $(hostname) - $(date)So I've looked around at programs such as backup-ninja, backup-manager and they seem similar. It is a shame as I mostly like backup2l, but in short I want to do the same thing on about 50-250 hosts:
Voting is open in the Debian Project Leader Elections 2012
So now I need to figure out who to vote for. This year I didn t take part in the discussions (all my spare time was bought, basically). The platforms are linked from the Debian Project Leader Elections 2012 page above and the key discussions were:
In (roughly) 2008 I read "Blood Music" my first Greg Bear novel and
devoured it in a weekend, in only two or three reading sessions. That happens
very rarely, and when it does I often wonder whether it's the quality of the
writing or some combination of that and your personal moods and tastes at the
time that is responsible. My next Bear was "Darwin's Radio" in mid-2010 which,
whilst good, did not provoke the same feverish read. I might write short
reviews for both at some point in the future, but right now I can't remember
either well enough to do so.
In the last few weeks I read "Hull Zero Three" which was quite a different
beast. The novel first captured my attention due to the unusual way it was
promoted: via a video, which was created using a modified Quake 2 engine. It
wasn't a great video but the novelty made it interesting.
The story begins with a first-person narrator waking up from a sort-of hyper
sleep on a generation starship that has clearly had some serious problems. He
has to run to escape danger before he has an opportunity to figure out exactly
what has happened and what he is running from, or to.
Something has gone horribly wrong on the ship: it's nowhere near where it
should be going and nobody should be awake. The narrator's memory is fractured,
fabricated and unreliable; the ship is hostile, and whilst it's mechanical, it
cyclically changes and re-arranges it's hulls in an almost organic way. He is
joined by a rotating cast of similarly confused refugees of varying shapes and
sizes. Language and cultural barriers serve to further magnify the sense of
alienation that you experience on behalf of the story teller. The troupe are
persued through the corridors by a collection of lethally efficient killer
"things", contrasting with the background by being organic in nature but
mechanical in behaviour and appearance.
The scale of the ship is necessarily massive, and Bear does an impressive job
of capturing the awe you might feel when considering it. Three huge,
cigar-shaped hulls, joined by "spars" to an enormous chunk of ice captured from
the Oort cloud on exodus from the solar system. The ice serves as a mixture of
"fuel" for the biological ship systems and as part of a shield system for the
hulls from cosmic rays. However, in part due to the narrator's confusion, it
was hard to follow the very abstract descriptions of the environment in the
earlier stages of the story. I found myself re-reading passages to try and
understand the comparisons being offered and scales presented.
In common with the two earlier Bears I've read, 'body horror' features
prominently in this story. It feels like a "Dead Space" or "Resident Evil" in
space in a hard SF novel which seriously attempt to capture real speculative
science.
Like "Blood Music", I found myself compelled to read "Hull Zero Three" at every
available opportunity. I finished it off in a very enjoyable reading session
outdoors in the spring sunshine. It was an enjoyable read, well written but not
beyond criticism, with some interesting takes on well-worn themes. Very
reminiscent of the movie "Pandorum" (which was a surprisingly good movie).
I m in the middle of plotting and designing a library to handle loading, processing and interpreting Geo-location data.
I have a fairly substantial corpus of data (latitude data since 2010-ish, on and off), and a bit of motivation to hack something up.
So far, I would like to see a lib to do most (or all) of the following:
Next.