Search Results: "ed"

18 March 2012

Gustavo Franco: Debian testing (wheezy) keyboardless install

I couldn't find an end-to-end document online about this just bits and pieces here and there. Let me describe how to install Debian testing (wheezy) without a keyboard using an USB flash drive and ssh.

I've got an HP Microserver a month or so ago and this is the step by step of my second install. The first one was also keyboardless but didn't involve an USB flash drive to bootstrap. I've used tftpd and dhcp from my laptop, but forgot to capture the notes to make a blog post. Shame on me.

Here's what you need:
The last two requirements are optional for hardcore preseeders. If you don't know what I mean. You aren't one of them. :)

Here's the step by step to install using SSH:
At this point you have all that you need to do a regular install using an USB flash drive and it's kinda of well documented. Well, we still need to change it to make it work without a keyboard and give you the ability to ssh into the installer.

Create a preseed.cfg in the root directory of the USB flash drive containing the following:
d-i netcfg/get_hostname string HOSTNAME
d-i netcfg/get_domain string DOMAIN
d-i anna/choose_modules string network-console
d-i network-console/password password INSERT_A_PASSWORD_HERE
d-i network-console/password-again password INSERT_A_PASSWORD_HERE

Edit syslinux.cfg in the root directory of the USB flash drive to look like this:
default netinst
prompt 0
timeout 5
label netinst
menu label netinst
 kernel linux
 append auto=true vga=normal file=/preseed.cfg initrd=initrd.gz priority=critical
My wishlist to the d-i hackers out there:
  • A boot-ssh.img.gz with the syslinux.cfg and preeseed.cfg above. In this case, it would be much more trivial to document in the installer manual how to use such a great feature.

Pablo Lorenzzoni: Time to change Window Manager again?

Ten years ago I was a fan of NEXTSTEP desktops and a die hard user of Window Maker. I love dockapps, and used to collect them. Things changed, and, as I moved from Desktops to Laptops, I began using simpler Window Managers. The powerful keyboard-shortcuts Fluxbox along with its capability to join windows with tabbing won me over and I began using it in my Laptop, while preserving Window Maker in my Desktop. In time, Fluxbox were used in both sides. Then the netbooks came and I bought an EeePC. The screen was so small that even the non-obstructive nature of Fluxbox were not enough. I began to try tiling window managers and I settle for Awesome. I was using Fluxbox in my Desktop and my Laptop, but Awesome was running in my Netbook. Tiling was making a lot of more sense and I could be productive, even in a small Netbook. Eventually, I started using Bluetile in my Laptop. Also, Bluetile was written in Haskell, and I was interested in Functional Languages by that time Now I got a new Laptop, and, since it features a Realtek 8191SE Wi-fi card, I had to install Wheezy (in my laptop, I usually run stable). Wheezy comes with the new GNOME 3 desktop, of which I read a lot. I decided to give it a try. I am missing advanced tiling (it seems that GNOME3 tiling works just in the side-by-side approach) and I also think that creating custom launchers should be improved but so far I am not disliking it, which is a good step toward adopting it. I ll give it a week to convince me. Let s see how it works its charm on me :-)

Andrew Pollock: [life] Guantanamo: My Journey

I first learned that David Hicks had written an autobiography when I saw some press coverage of there being an attempt by the Australian Government to ban the sale of it, so I asked my sister if she could get me a copy for my birthday before any ban happened. The book doesn't appear to be available on Amazon. I sat down and tried to read it almost immediately, but at the time found his writing style to be rather inarticulate, so I put the book down for a month or so. When I next had a platelet donation to make, I took it along with me, and forced myself to read it for duration of the donation. On the second reading, I managed to engage with the book, and from that point on, once I made it through his early years in that initial forced reading session, it ended up being quite enthralling. I plugged my way through the 456 pages in a bit over a month I guess. We'll never truly know the full story of David Hicks, because I'm sure that unless there's some sort of inquiry (and even then, there's multiple country's governments involved), the full story won't come out. I was always sympathetic to Hicks' plight, since I don't believe that anyone should be held without due process let alone for anywhere near as long as he was. Certainly, the way the book reads, Hicks comes across as a very young, naive, but principled individual. Like many Australians, he got the travel bug, and by way of it, got to interact with some different cultures, which awakened a hunger for social justice in him (at least that's my interpretation of his portrayal). I guess I have a different mental image of torture than Hicks did, because I didn't really find any incidences of what I'd consider torture in his story. There was plenty of despicable, inhumane treatment though, so I can see how the line might get blurry, particularly if you're the one experiencing it. Specifically on the (mis)treatment of the detainees: it was pretty bad, based on the book. I'm surprised there haven't been more whistle blowers that have come out. I can't believe that the many soldiers who were stationed there could treat detainees the way Hicks says they were treated and then can look themselves in the mirror. The ICRC seemed well apprised of the detainees conditions (since they seemed to have the most access to them of any non-military people). I don't know what confidentiality is imposed on them in return for that access, though. The fact that he's able to string a sentence together at all after the treatment he describes for the length of time he received it, I think is pretty amazing. I couldn't imagine having to endure what he says he went through. I did feel quite appalled by my own country's complete disregard for his plight, and similarly in the way the US Government treated these detainees for as long as they did. Given there are still 171 detainees in Guantanamo today, it makes me wonder what the conditions and treatment are like there now. It certainly seems to have fallen out of the mainstream press. Overall, not the most well written book, but a fascinating and shocking account of what happened to one person. I think Hicks should be congratulated for the courage to relive his experiences to get them down on paper, and Random House should also be congratulated for publishing his work, which I'm sure put them under some political pressure. I have no idea how well the book has sold, or how widely it has been read, but I certainly recommend it.

Gregor Herrmann: RC bugs 2012/10-11

since I was travelling in the pre-ultimate week for a few days, there was no report about my RC bugs fixing activities. so here we go with an overview covering two weeks:

Sylvain Beucler: FreeGLUT for OpenGL ES

FreeGLUT on Android The OpenGL ES port of FreeGLUT is progressing :) Now we have: In addition, the work is available in the official repository! http://freeglut.svn.sourceforge.net/viewvc/freeglut/trunk/freeglut/freeglut/ Question: Mesa and Android ship GLES 1&2 in separate libraries. So at first glance, we'll have to ship 3 FreeGLUT builds: Though, EAGL (on iPhone) can initialize either GLES 1 or 2 at run-time. Maybe it's possibly to do that by dlopen'ing the GLES library dynamically, but this won't work for static builds - and make distro packagers cringe unless I'm mistaken ;) Do you think there's a way to provide a unified version?

Charles Plessy: Debian-installer in a cloud.

Debian Med prepares a metapackage for multi-purpose image machines, containing packages for bioinformatics that can be used in command line or via scripts, and that do not depend on too many other packages. I would like to prepare such an image for the Amazon cloud in the most secure manner, and the simplest way is to build it automatically in order to not have to clean anything at the end of the process. I tried for months so use the Debian installer, but banged my head against walls repeatedly, as it was impossible to re-partition the volume on which the installer was started. In the end, I figured out that this was not necessary. For instance, one can start an image containing the installer on a micro instance (-t t1.micro), with an additional volume of one gibibyte (-b /dev/sdb=:1:false) to install Debian on, and preseed the installer via instance metadata (-f preseed.txt) using a file prepared in advance. When the installation finishes, the instance terminates instead of stopping (--instance-initiated-shutdown-behavior terminate), and its volumes disappear, except the one where Debian was installed (/dev/sdb=:1:false). Debian-installer in Stable is not often updated, and its size is very small. One can therefore think of releasing one machine image per zone and architecture. I did so for T ky (ap-northeast-1) on amd64. It contains the kernel, its initrd, and a GRUB 1 menu for pvgrub, that passes the following options: console=hvc0 auto=true priority=critical url=http://169.254.169.254/latest/user-data DEBIAN_FRONTEND=text. Two key pieces are missing in the resulting system. When the kernel is installed or updated, the GRUB 1 configuration file for pvgrub must be refreshed. Also, the system must be able to retrieve a public SSH key provided through the instance metadata, to allow one to log in without using a predefined password. These two functions are provided by the cloud-init package, available in Ubuntu and Fedora. I am looking for volunteers to maintain or co-maintain cloud-init in Debian.

Soeren Sonnenburg: Shogun got accepted at Google Summer of Code 2012

SHOGUN has been accepted for Google Summer of Code 2012. SHOGUN is a machine learning toolbox, which is designed for unified large-scale learning for a broad range of feature types and learning settings. It offers a considerable number of machine learning models such as support vector machines for classification and regression, hidden Markov models, multiple kernel learning, linear discriminant analysis, linear programming machines, and perceptrons. Most of the specific algorithms are able to deal with several different data classes, including dense and sparse vectors and sequences using floating point or discrete data types. We have used this toolbox in several applications from computational biology, some of them coming with no less than 10 million training examples and others with 7 billion test examples. With more than a thousand installations worldwide, SHOGUN is already widely adopted in the machine learning community and beyond. SHOGUN is implemented in C++ and interfaces to all important languages like MATLAB, R, Octave, Python, Lua, Java, C#, Ruby and has a stand-alone command line interface. The source code is freely available under the GNU General Public License, Version 3 at http://www.shogun-toolbox.org. During Summer of Code 2012 we are looking to extend the library in three different ways:
  1. Improving accessibility to shogun by developing improving i/o support (more file formats) and mloss.org/mldata.org integration.
  2. Framework improvements (frameworks for regression, multiclass, structured output problems, quadratic progamming solvers).
  3. Integration of existing and new machine algorithms.
Check out our ideas list and if you are a talented student, consider applying!

17 March 2012

Matthew Garrett: More ways for firmware to screw you

Some of my recent time has been devoted to making our boot media more Mac friendly, which has entailed rather a lot of rebooting. This would have been fine, if tedious, except that some number of boots would fall over with either a clearly impossible kernel panic or userspace segfaulting in places that made no sense. Something was clearly wrong. Crashes that shouldn't happen are generally an indication of memory corruption. The question is how that corruption is being triggered. Hunting that down wasn't terribly easy.

My first thought was that we were possibly managing to load the kernel over a region used by UEFI code. UEFI defines two types of code - boot services and runtime services. While runtime services code and data must be preserved by the OS, in theory boot services code and data is available to the OS once the firmware has exited. In practice, that's not true. It seemed entirely possible that the kernel might be ending up on top of some of that boot services code or data and getting trodden on. Grub now has code to avoid putting the kernel on boot services, so testing the latest code seemed like a good plan. But no, crashes still happened.

That pretty much ruled out the bootloader. My next thought was that executing some of the firmware code was triggering a write to some other memory that contained the kernel. Josh Boyer suggested the next trick, which was to try marking the kernel read-only to see whether anything was hitting it. x86 lets you mark pages as read-only - any attempt to write to them should take a fault. UEFI functions are executed in the context of the kernel, so share the same page tables. That let me rule this out, since everything still went just as wrong and I wasn't taking an extra fault first.

However, at this point I was reasonably happy that it wasn't the kernel itself being overwritten - faults were occurring in userspace code as well. That was a pretty strong indication that what was happening was continuing to happen once userspace had started, so it wasn't a direct response to a firmware call. I made sure of that by stubbing out all the calls that could be triggered after kernel initialisation, and saw the same failures. Once all attempts to be clever have failed, it's time to just start using brute force. The kernel lets you reserve areas of RAM by passing arguments like memmap=0xlength$0xstart to block length bytes starting at start from being used. It took a while, but I finally found a 256MB range that made a difference - reserving it resulted in the machine booting reliably, letting the OS use it resulted in occasional crashes.

Definite progress. Comparing that memory range to the EFI memory map was helpful. There were several blocks of UEFI boot services data present there, which really seemed like too much of a coincidence. By reserving each of them in turn, I'd traced it down to a single 31MB region of boot service data - that is, memory reserved by the firmware for use by the UEFI boot services. Per spec, this is available to the OS once the boot environment has been exited. Nothing other than the OS should be touching this after boot, but something clearly was. Tracking down what was far easier than I expected, although the first attempt was a failure. Setting it read-only should have triggered a fault, but didn't. That was rather confusing. But, rather than give up, I patched the kernel to fill the region with 0xff at kernel init. Then I booted the system, read it back and looked for values that weren't 0xff. I got this:
00000000  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff   ................ 
*
001568a0  ff ff ff ff ff ff ff ff  ff ff ff ff 84 00 00 00   ................ 
001568b0  00 20 a7 ac 46 00 00 00  00 00 00 00 00 00 06 01   . ..F........... 
001568c0  c2 0b 0c 00 ff ff ff ff  ff ff ff ff ff ff ff ff   ................ 
001568d0  ff ff 0a 04 f0 03 82 0d  40 00 00 00 ff ff ff ff   ........@....... 
001568e0  ff ff 00 21 00 36 9a 80  ff ff ff ff ff ff 00 7e   ...!.6.........~ 
001568f0  00 09 43 48 41 2d 47 75  65 73 74 01 04 02 04 0b   ..CHA-Guest..... 
00156900  16 32 08 0c 12 18 24 30  48 60 6c 2d 1a 0e 18 1a   .2....$0H l-.... 
00156910  ff ff 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................ 
00156920  00 00 00 00 00 00 00 dd  09 00 10 18 02 00 10 01   ................ 
00156930  00 00 dd 1e 00 90 4c 33  0e 18 1a ff ff 00 00 00   ......L3........ 
00156940  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................ 
00156950  00 00 bd ea f8 b3 ff ff  ff ff ff ff ff ff ff ff   ................ 
00156960  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff   ................ 
*
022fb000
That's a lot of 0xffs (around 31MB of them) with one small section that contains an 802.11 probe packet with the SSID of the hospital across the road from my house. Apple support network booting off wireless networks. It seems that the firmware brought up the wireless card, associated with this network (it's the only public one nearby) and then left the card DMAing packets into RAM. The read-only page attribute only applies to CPU-initiated accesses, so it could do this without triggering a page fault. It also explained why it was so random - whether memory corruption occurred would depend on whether a packet appeared between that memory being used by the OS and the kernel reinitialising the wireless card. It certainly explains why I couldn't reproduce it when I left the machine repeatedly rebooting on the bus home.

How do we fix this? Unsure. With luck disconnecting the UEFI driver in the bootloader should quiesce the hardware, but without testing I'm not sure of that yet. For now it's just another example of firmware managing to break expectations in deeply strange ways.

comment count unavailable comments

DebConf team: Make DebConf12 a success: donate or become a sponsor (Posted by Leandro Gomez)

The Debian Project s annual conference is slowly coming closer. Visiting places around the world since 2000, DebConf will take place this year in Managua, Nicaragua, in July and will again provide an opportunity for people who contribute to Debian to meet in person for face-to-face collaboration and discussions. At DebConf we try to bring together as many Debian contributors as possible, including those who could not afford to attend from their own resources. You can help make DebConf12 a success by your organisation becoming a sponsor, or by donating money as an individual. Individual donations can be made online in either US dollars or euros. If you are interested in becoming a sponsor, you can find more information about DebConf12 sponsor page or directly contact <sponsors@debconf.org>. In addition to monetary donations, sponsorship can be provided in the form of in-kind donations, or by lending equipment for the conference period.

Kai Wasserb ch: The joy of building Wine in a non-multiarch environment

This is an updated and consolidated post for/of two previous blog entries. Before I continue, let me make it clear, that this post isn't intended to criticise anybody. It is meant as a instruction leaflet to go with my unofficial (source) package(s). The best idea, until all build dependencies of Wine have been made multiarch ready (we're almost there), is to create a base.tgz for pbuilder in which you make the required changes. So you don't have to remember applying them everytime (note, this is only needed for amd64 builds). After you created yourself a base.tgz for Wine, do the follwoing:
  1. Log into the chroot stored in your base.tgz for Wine: pbuilder --login --save-after-login --basetgz /path/to/your/wine.base.tgz
  2. Update the package list and installed packages with aptitude update && aptitude safe-upgrade unless you know, everything is updated.
  3. Install ia32-libs-dev and libjpeg-dev: aptitude install ia32-libs-dev libjpeg-dev
  4. Work around #638543:
    1. cd /usr/lib32
    2. rm libjpeg.so libjpeg.so.62* (you can also remove the libjpeg.a and libjpeg.la files)
    3. ln -s libjpeg.so.8 libjpeg.so
    4. cd /usr/include
    5. ln -s x86_64-linux-gnu/jconfig.h
  5. As we build build with GCC 4.5 (due to a problem with GCC 4.6, see WineHQ bug #22053 for more details) on amd64 (i386 isn't using GCC 4.5 anymore (since the 1.5.0-0.2 packages), because that resulted in linking errors), we hit #638418. To work around that, you need to create the symlink yourself. Execute ln -s x86_64-linux-gnu/asm asm in /usr/include.
  6. Exit the chroot, pbuilder should now update your base.tgz.
  7. Build the source package with pbuilder.
For i386 users this shouldn't be required. Not even the symlinking of the asm directory, as we don't use GCC 4.5 anylonger on i386 (due to various linking errors). Though that comes at the cost of potential issues with e.g. Steam.

Ana Beatriz Guerrero Lopez: Debian accepted for the Google Summer of Code 2012. Students wanted!

Great news! Debian has been accepted into the Google Summer of Code (GSoC) program this year for the seventh time. Now we are looking for students to work this summer with us in one of our exciting projects. If you are interested, now would be a good time to get in touch with the mentors; remember that discussing your application before submitting it is always recommended so that you can get feedback from the community.
Please also read the FAQ and timeline in the Google Summer of Code website. Besides contacting with the mentors, you can also get in touch with us on our IRC channel #debian-soc (in irc.debian.org) and the soc-coordination mailing list if you have any questions. I am hoping to see many great applications from students wainting to improve Debian :)

Christian Perrier: 2012 update 15 for Debian Installer localization

Status for D-I level 1 (core D-I files): Status for D-I level 2 (packages that have localized material that may appear during default installs, such as iso-codes, tasksel, etc.): Status for D-I level 3 (packages that have localized material that may appear during non-default installs, such as win32-loader) Full 100% completeness (hall of fame) for 17 languages: Belarusian, Bulgarian, Catalan, Czech, German, French, Indonesian, Italian, Japanese, Kazakh, Dutch, Polish, Portuguese, Russian, Slovak, Swedish, Turkish

16 March 2012

Matt Brown: Kindle Reading Stats

I ve written before about my initial investigations into the Kindle, and I ve learnt much more about the software and how it communicates with the Amazon servers since then, but it all requires detailed technical explanation which I can never seem to find the motivation to write down. Extracting reading data out of the system log files is however comparatively simple. I m a big fan of measurement and data so my motivation and goal for the Kindle log files was to see if I could extract some useful information about my Kindle use and reading patterns. In particular, I m interested in tracking my pace of reading, and how much time I spend reading over time. You ll recall from the previous post that the Kindle keeps a fairly detailed syslog containing many events, including power state changes, and changes in the Booklet software system including opening and closing books and position information. You can eyeball any one of those logfiles and understand what is going on fairly quickly, so the analysis scripts are at the core just a set of regexps to extract the relevant lines and a small bit of logic to link them together and calculate time spent in each state/book. You can find the scripts on Github: https://github.com/mattbnz/kindle-utils Of course, they re not quite that simple. The Kindle doesn t seem to have a proper hardware clock (or mine has a broken hardware clock). My Kindle comes back from every reboot thinking it s either at the epoch or somewhere in the middle of 2010, the time doesn t get corrected until it can find a network connection and ping an Amazon server for an update, so if you have the network disabled it might be many days or weeks of reading before the system time is updated to reality. Once it has a network connection it uses the MCC reported by the 3G modem to infer what timezone it should be in, and switches the system clock to local time. Unfortunately the log entries all look like this:
110703:193542 cvm[7908]: I TimezoneService:MCCChanged:mcc=310,old=GB,new=US:
110703:193542 cvm[7908]: I TimezoneService:TimeZoneChange:offset=-25200,zone=America/Los_Angeles,country=US:
110703:193542 cvm[7908]: I LipcService:EventArrived:source=com.lab126.wan,name=localTimeOffsetChanged,arg0=-25200,arg1=1309689302:
110703:193542 cvm[7908]: I TimezoneService:LTOChanged:time=1309689302000,lto=-25200000:
110703:183542 system: I wancontrol:pc:processing "pppstart"
110703:193542 cvm[7908]: I LipcService:EventArrived:source=com.lab126.wan,name=dataStateChanged,arg0=2,arg1=:
110703:183542 cvm[7908]: I ConnectionService:LipcEventArrived:source=com.lab126.cmd,name=intfPropertiesChanged,arg0=,arg1=wan:
110703:183542 cvm[7908]: W ConnectionService:UnhandledLipcEvent:event=intfPropertiesChanged:
110703:193542 wifid[2486]: I wmgr:event:handleWpasupNotify(<2>CTRL-EVENT-DISCONNECTED), state=Searching:
110703:113542 wifid[2486]: I spectator:conn-assoc-fail:t=374931.469106, bssid=00:00:00:00:00:00:
110703:113542 wifid[2486]: I sysev:dispatch:code=Conn failed:
110703:183542 cvm[7908]: I LipcService:EventArrived:source=com.lab126.wifid,name=cmConnectionFailed,arg0=Failed to connect to WiFi network,arg1=:
 Notice how there is no timezone information associated with the date/time information on each line. Worse still the different daemons are logging in at least 3 different timezones/DST offsets all interspersed within the same logfile. Argh!! So our simple script that just extracts a few regexps and links them together nearly doubles in size to handle the various time and date convolutions that the logs present. Really, the world should just use UTC everywhere. Life would be so much simpler. The end result is a script that spits out information like:

B000FC1PJI: Quicksilver: Read 1 times. Last Finished: Fri Mar 16 18:30:57 2012
- Tue Feb 21 11:06:24 2012 => Fri Mar 16 18:30:57 2012. Reading time 19 hours, 29 mins (p9 => p914) ... Read 51 books in total. 9 days, 2 hours, 29 mins of reading time
 I haven t got to the point of actually calculating reading pace yet, but the necessary data is all there and I find the overall reading time stats interesting enough for now. If you have a jailbroken Kindle, I d love for you to have a play and let me know what you think. You ll probably find logs going back at least 2-3 weeks still on your Kindle to start with, and you can use the fetch-logs script to regularly pull them down to more permanent storage if you desire.

Christian Perrier: [life] Running update

We're now 2.5 months in 2012 and I'm indeed getting closer of my first big goal of the year : the 80km run of Paris Ecotrail. The race takes place next Saturday, March 24th, with a start at 12:00 in the South-West of Paris area (close to our place). The race is mostly a trail race in woods and forests in the neighbourhood of Paris, going up and down in our small hills and valleys, passing along pools and lakes and indeed showing the natural beauties we have less than 20km away from center Paris. The race ends at the Eiffel Tower. And they really mean it! The race ends at Eiffel Tower's *first floor* after climbing the steps there. Those of you who have been there can imagine the surprise of tourists from all over the world when hundreds of "road warriors" wearing water backpacks, head lamps and looking a bit tired come and climb the Old Lady's stairs. So, in case you happen to be touring in Paris on the week-end of March 24-25, just pop up at Eiffel Tower around 10-11pm (yes, at night) and try to spot a bubulle crawling up there to reach the finish line..:-) To prepare this, I already ran 538km in 2012, mostly done either with my daily commute runs...or with week-end long runs (up to 37km on march 4th, and many others above 20km). I ran two half-marathons as well: one in February, where I nearly broke my record, finishing it in 1h37'45" even though this is a quite though race with two hills. I was very in shape that day and was lucky to run with a friend setting the pace for me, which helps a lot. Another half-marathon last Sunday in Rambouillet was also a good race, though I was secretly hoping to break my record there (the race is flat, much more than the former one). I had however to slow down from a 4'35"/km pace to 4'50"/km in order to preserve my condition. And, finally, I completed the race in 1h39'53". So, two half-marathons in less than 1h40 again. That sounds promising for the Ecotrail (even if there nothing similar between a flat half-marathon and a hilly ultra-trail) and also for the next marathon, in June. I'll keep you posted about the Ecotrail race but I can announce in advance that I'll be using the Runtastic app on my brand new Android phone, and people will be able to follow my race live here. And you'll even be able to cheer at /me..:-) Next running update on Sunday 25th to give you the outcome....

James Morrison: Penance driven development

Recently, I got to try out working in a couple different environments. Working in these environments helped me formalize some of the things that I like and some of the things I don't like. With these new environments I've come to realize my style of development. It's called penance driven development. It's called this because there are two important things:
1) It's better to ask forgiveness than for permissions
2) You need to be deserving of forgiveness.

So the concept is simple, whenever you break something, you first fix the symptom, then you improve the infrastructure so similar breaks should be harder to do. The cost of the penance doesn't have to be huge, but the penance has to be done, otherwise technical debt accumulates and people believe there is no downside to breaking things.

What needs to be improved depends on what is missing. For example, if an engineer broke a feature, but that feature didn't have a test, the penance should be to write a test. Even if the one that broke the feature isn't the owner or the one that wrote the feature. If someone breaks the build and no one noticed because the continuous build didn't email, the fix could be setting up the continuous build to email out build failures, or even better, run each change on a build bot before allowing commits.

I think I'll have to start a penance of the day blog/twitter stream.

I've been practicing this style of development for most of my career, and it's similar if less precise than the 5 whys . As mentioned in the The Lean Startup, the cost of the penance should be proportional to the cost of the break.

Michal &#268;iha&#345;: Weblate 0.7

Continuing at same pace (one release every two days), I can announce Weblate 0.7. The major change is built in full text search and displaying of context for currently translated message (either based on location in po file or by string similarity based on full text data). Full list of changes for 0.7: You can find more information about Weblate on it's website, the code is hosted on Github. If you are curious how it looks, you can try it out on demo server. You can login there with demo account using demo password or register your own user. Weblate is now also being used https://l10n.cihar.com/ as official translating service for phpMyAdmin, Gammu, Weblate itself and others.

Filed under: English Weblate 0 comments Flattr this!

Dominique Dumont: Config::Model and cme to help debian transitions

Hello As maintainer of libwx-scintilla-perl, I had to update the package to update a dependency declation to close bug #662427. The dependency was good enough for the package to work but it blocked the linpng15 transition. This is yet another detail to remember when updating package: whether the dependencies are impacted by a transition. As I m really bad at remembering such details, I ve added the relevant check in the dpkg control source model used by cme. Now running cme check dpkg will warn you if a dependency impacts a transition. And cme fix dpkg will fix you dependency list as resquested by a transition. Well, that holds true for the transition I m aware of. Feel free to contact me if more transition checks are needed. For those who are curious (or want to send me a patch for another transition), here s the actual implementation of these new checks. All the best

Petter Reinholdtsen: Writing and translating documentation in Debian Edu

Documentation in Debian Edu is provided in several languages, and it is important to make it both easy to contribute and to keep the translated versions in sync. To do this we have come up with what we believe is a very efficient work flow.
  1. The documentation is written in a moinmoin wiki (see for example the Squeeze release manual) with support for exporting the content as docbook XML.
  2. This docbook document is given to po4a to extract a gettext style .pot file with the content, which in turn is used to create .po files with the translated text.
  3. The .po files are given to translators, and they can always tell which part of the original wiki document is new or changed. They can use their normal translation tools like lokalize or poedit to write the translation. There is even a system in place to handle translated images.
  4. The translated .po files are combined with the original docbook XML document using po4a to create a translated docbook document.
  5. The final step is to use all the generated docbook files and create PDF and HTML version of the original and translated documents.
This setup work very well, but have a few issues. The biggest issue is that the docbook support we use in moinmoin is not actively maintained. The docbook support is also buggy, and our build system contain workarounds to make sure the generated docbook is usable despite these bugs. If you want to have a look at our setup, it is all there in the debian-edu-doc package.

Christian Perrier: [life] No more teens at home...

So, since Wednesday, we have no more teenagers among our children. Indeed, our youngest, Magali, turned 20 and we happily celebrated that in a japanese restaurant in Paris : Magali is living in a (very) small flat in Paris as she attends preparation courses for exams meant to enter physical therapist schools. She's currently working very hard to prepare these and is left with only one week before the first exam. We're 100% confident that she'll succeed. Really, the days where our little shrimp was crawling across her bed, turning clockwise and finally sleeping in the width of the bed....do not seem so far. And still, these folks we call "our kids" are now grown-up persons living their own lives : Jean-Baptiste (some of my friends reading this blog have met him at DebConf 10) will soon enter profesionnal life after graduating an engineering school in electronics, at 24. Sophie, now 22, will resume her social worker school in Bordeaux in September and will probably start working as social worker ("assistante sociale", in French) afterwards. And we hope that our little shrimp (which her sister calls "mini-poop") starts a physical therapist school next year. So, well, more and more, Elisabeth and I are old parents and weeks where we're indeed both alone at home are now common (not to mention weeks where only one of us is alone either because she has professionnal commitments on some other side of the planet or I have some free software event on another side of the planet). It is indeed really likely that this year's holidays will be the first ones where we have a distant travel...which we'll be doing alone. Holidays in Nicaragua (you probably guess why Nicaragua) are much awaited and will be enjoyed a lot, but still...:-) So, well, to all those of you who read this and are parents, or plan to become parents, be happy. The wonder that it is lasts for years and it's very hard to describe precisely the link that connects parents and their children. At least the one we have with our children, which both us and them are proud of. And that pride and this link have no price. I really wish you guys to develop the same with your newborns (particularly those of you who very very very recently became parents anbd, yes I mean you who know who you are...).

Paul Wise: Report from the recent Debian bug squashing party in Perth

We recently held a Debian bug squashing party (BSP) in Perth, Western Australia. Over the weekend we had about 10 or so people show up to participate, learn about fixing bugs in Debian and try to fix some. The BSP co-incided with a weekend heat wave with temperatures reaching 38 C and the venue lacked air conditioning. Most of the attendees were new to Debian development but were Debian users. Our focus was on release critical bugs highlighted by rc-alert and the UDD bugs list, but we also discussed IPv6 bugs in CUPS and some bugs that were affecting UCC infrastructure. The UCC president also worked on fixing their door-locking system, replacing the broken system based on an ancient modem with an Arduino board. We managed to fix, work on or investigate 12 or more bugs. I was hoping we would get through more, but the weather and the average experience level conspired against us. After we were done on Sunday a few of us went down to the local pub to have a meal, a beer and some geeky conversation. All in all we had a good time and got some bugs fixed. The UCC president seemed to be keen on doing another BSP, hopefully we can do another one before the freeze happens. There were a few people who missed the BSP so it would be good to give them a chance to work on some bugs. Thanks go to the UCC folks for the venue and to PLUG folks for helping with organisation and promotion of the event.

Next.

Previous.