You are scaring away much more than that. I just came across an invitation for BugCon 2012. BugCon is a Mexican conference devoted to computer security I cannot comment on its level or value because, although it's a topic that has long interested me, I must recognize each day I feel less of an expert, nowadays finding myself at the level of a "sysadmin who tries not to be too dumb for his own job security". Oh, and also because it would be completely off-topic for this post. If you look at Vendetta's (the main organizer) blog post, it will probably give you the impression that the conference is just an excuse for the afterparty: Lets go see some b00bs! Do you think your fellow female hackers will have any interest in joining a bunch of sex-starved, hormone-infested teenagers who only want to pwn a website and grab more pr0n? Do you think females will feel welcome (or even mildly safe) between you? I would not think so. And I also think you are alienating any professional who might have any interest in joining your community, be it as a member, as a mentor, or whatnot. I cannot right now do a coherent post on this topic, but I can reference you to what I have seen (and read) over the last almost 10 years, when the issue was first brought up to our attention. I am very glad to see that, at least in the Free Software area, there has been a real change of mindset. I hope you are in time to think about it and rectify.

• Timeline of incidents in Geekfeminism. Note that while it seems we see more as time passes, I am almost sure it's because we are more aware of the problem, not because it occurs more often. I hope I'm not mistaken.
• Debconf ftp-masters talk. Myself a Debian person, my first contact with this problematic was being at the DebConf3 ftp-masters talk And the discussion and action that followed. This led to the creation of the Debian Women group, one of the most (socially, not technically) influent parts of Debian. Great thanks and admiration to their members, as well as to the (male and female alike) people who have worked to form it and make it heard.
  I think Debian Women sparked other similar projects such as GnomeWomen (and there is a list with further projects in there), but I cannot authoritatively say who was there first.
• Planet Fedora up-skirting photo (the original post is still available) showed the communit does no longer tolerate this behaviour. Good!
• The Open Source Boob Project. One of the most childlike attempts at humor that surely alienated many would-be female geeks.
• Another conference season, another dumb sexist, a post by Piers Cawley addressing this issue after attending the CouchDB + Ruby: Perform like a Pr0n star talk. Quoting him, Apparently, the difference between 80s truck salesmen and Matt s audience is that at least 80s salesmen had the grace to look embarrassed.
• Liz Keogh: "I am not a pr0n star: Avoiding unavoidable associations", a hacker woman that clearly felt offense by the CouchDB Pr0n Star joke, and did a thorough and interesting analysis, extending the effects to your work environment.
• Just Say You're Sorry Already (regarding the same incident on CouchDB+Ruby)
• Richard Stallman's EMACS virgins joke incident. It's sad how it's impossible to get Stallman to acknowledge he can also make mistakes and make feel people insulted.
• [update] And of course, MadameZou mentions the very important 2002 HOWTO: HOWTO encourage women in Linux?

Oh, and not the description of an incident, but a very interesting and thoughtful take on this: [pdf] Interesting analysis by Hannah Wallach on the numbers and motivations of women in Free Software groups. I don't know if Hannah has published this in article form, but many interesting points can be understood by looking at the presentation. My good friend Vendetta: I don't mean this post (longer than what I originally intended) as a way to say you and the conference you are organizing for the third year (IIRC) already is unprofessional or targetted to pimply teenagers. I know the work you have put in it. I hope you see the points I'm trying to drive You are of course free to have whatever afterparty you have. But, if as the main organizer, you are giving the images of nice chicks at Hooters more weight and relevance than to the conference itself... you are doing yourself a disservice. I hope you can rectify it, and make BugCon attractive to hacker women as well.

When you start your journey with Debian, you tend to have lots of questions. You ll find some answers in various documentations but there always are remaining questions. Those can be asked on various support channels:

• on mailing lists (debian-user@lists.debian.org for the English-speaking one);
• on IRC (channel #debian on irc.debian.org);
• on questions & answers websites like ask.debian.net;
• on web forums like forums.debian.net;
• on every other places where Debian users hang out together (on a booth during a conference, during an install party of a Linux User Group, etc.).

Those are the places where you can also start your journey as a Debian contributor instead of asking questions, you just have to answer questions of other users! Let me share some advice if you want to do some user support. User support is difficult It s not always an easy task. Some users are more skilled than others and there might be difficulties related to the language, English is not always the native language of a user who asks a question in English. Be respectful and courteous when you answer user questions, even if they made mistakes. You re effectively representing Debian and you should give out a good image of the project. If you don t have the patience or the time needed to do a good answer, don t reply and let someone else take care of this user. I invite you to read (and follow!) the Debian Community Guidelines. Avoid RTFM answers, instead you should show the users how they could have found (alone) the solution to their problem. We don t want to scare people away, we want to grow our community. But it s also rewarding In some cases, the problem reported by the user will be a real problem and you ll have an opportunity to file a good bug report, thus helping to improve Debian for everybody. Often, you don t even have the answer to the user s question. But you re more skilled than him/her to do researches on the web, or you know of a good documentation that might contain the relevant bits of information, in any case you re doing further research to help this user. In this process, you also grow your own skills since you re learning stuff that you didn t know yet. At least that s how I learned many things during my first year in the Debian community there s no reason why you couldn t learn lots of stuff that way, in particular if you also read the answers of other skilled people on those channels (it takes a bit of training to learn who are the skilled people though). I still believe that doing user support is one of the best ways to join the Debian community and to start contributing. It helps you to grow your skills, and to slowly progress from average user to advanced user .

If you want to start contributing to Debian, click here to subscribe to my newsletter and get future updates for new contributors. You can also follow me on Identi.ca, Google+, Twitter and Facebook.

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

Below is an email I received from Representative Rick Larsen s office. I don t recall ever having identifying myself as PVT Adams-Collier in any communications with his office, though I could have done so at some point. Maybe. I also don t recall contacting his office directly concerning SOPA. I blogged a few things and mentioned him on facebook a couple of times, though. It is good to know that I don t always have to go directly to my representative to have my voice heard. For those playing along at home, I think the best course of action would be for producers to perform searches for their work on peer-to-peer file sharing search engines such as http://thepiratebay.org/ and http://scrapetorrent.com/. If producers find that their work is being distributed in a way which is contrary to their wishes, I advise the producer or their agent to contact the individuals operating seeds with high share ratio in order to ensure that they perform AAA before accepting new peers into the swarm. Those seed operators who refuse to negotiate reasonable AAA terms should be issued C&D orders, and legal action should be taken, should they fail to comply with the request. [edit 2012-01-24T05:27:44] It would probably be wise to impose a minimum fee of $5 for seed operators per content package they distribute. This will encourage them to pass this fee on to their subscribers in a legal and responsible manner. I recommend that it be distributed in the same fair and concise way in which the tickets are distributed for toll violations on the Tacoma Narrows Bridge. Ask me how I know. This will provide content producers a valuable distribution channel which is closely in touch with the consumers of the producers media. I believe that if the producer puts forth effort in good faith to develop and maintain relationships with key distribution points, we will see a situation where both content producers and consumers get what they want. The authorization phase of the AAA system could charge a Payment Card Industry or bitcoin account a reasonable fee. My employer produces content delivery appliances which would serve quite well the role of AAA gateway. For an example of this use case in action (sans account billing), I recommend contacting seeding participants of the Debian CD/DVD swarms. I will proxy such requests if there is interest. An alternative might be a tool developed for the online gaming community with a strange name: http://www.evenbalance.com/

---

Dear Pvt. Adams-Collier: Thank you for contacting me about the Stop Online Piracy Act (SOPA) and the Protect IP Act (PIPA). I wanted to update you on my views on this important issue. I am opposed to SOPA and PIPA in their current forms. I believe that these bills create unacceptable threats to free speech and free access to the internet. I have heard from many of you in Northwest Washington who are deeply concerned about the potential impacts of SOPA and PIPA. Online piracy is a serious problem that costs U.S. businesses billions of dollars. Government agencies must be empowered to stop and prosecute intellectual property thieves. But in doing so we cannot undermine freedom of speech or jeopardize the free flow of information on the internet. I will work with my colleagues to see that any final anti-online piracy legislation protects the internet and does not encroach on free speech rights. Please be assured that I will keep your thoughts in mind should I have the opportunity to vote on any legislation that would impact online piracy and internet freedom on the House floor. Again, thank you for contacting me. I encourage you to contact me in the future about this or any other issue of importance to you. Sincerely, Rick Larsen
United States Representative
Washington State, 2nd District

[edit 2012-01-24T05:28:09] Sincerely, C.J. Adams-Collier
San Juan County Democratic Central Committee (*whew*) PCO
San Juan County, Washington State, Orcas 3 District

As LibreOffice is approaching its final 3.5.0 release, I d like to sum up the RTL status for RC1. So far, 6 RTL related bugs were resolved in the 3.5 cycle (#32530, #34222, #40950, #43790, #43793, #44078), and a few minor issues reported directly to the developer s mailing list got quick responses. Most importantly, the new features of page break and header/footer not only support RTL but actually looks good. During the LibreOffice conference I was suggested to help with these features, providing feedback, and I m glade the needed attention was given to it. Besides that, a few l10n and translation issues were solved in the process of doing the Hebrew translation (which also reflects on other RTL languages). At a few cases, these issue because a general l10n issues which affects all the languages. In general, I found the core developers responsive to mails about RTL support. I m sure the talk about RTL problems during the conference helped, as well as being more active in the project and having more personal acquaintance with the developers. That s being said, RTL support for LibreOffice still has problems, which I hope will be pushed during the 3.5.x cycles (full list at Bug 43808, the rtl meta bug). As to get some focus regarding was is to be done, I m listing the top problems:

1. #44657 RTL UI: Horizontal scrollbar in calc main window is broken
2. #33302 brackets inverted in rtl text (mac only)
3. #37692 RTL list numbering reverses its direction
4. #42070 - RTL support in broken in presenter Console extension
5. #32531 - Incorrect cursor key movement between table cells of different directionality
6. #104515 - RTL UI: moving active embedded object to the left moves it to the right (reported for OO.org, but verified in LibO)
7. #37128 - Writer saves text alignment of RTL paragraph not according to the ODF specification

I hoped to have the first two done for 3.5.0, but didn t succeed in getting them fixed. Will keep trying
Filed under: i18n & l10n, Israeli Community, LibreOffice

The script isn't fully automated yet, I'm running it manually and watching for errors, but I do now have a simple script (~100 lines of perl) which runs edos-debcheck against each of the supported Emdebian architectures for unstable-grip and picks out those packages which are missing from the subset of packages which Emdebian monitors for Grip.

I was hoping to make these scripts into a normal Debian package but there are some limitations in that the scripts need to assume various pieces of Debian infrastructure. e.g. I started off using rsync to pull in the Packages files (along with Release and Sources) because apt has annoying behaviours with multiple architectures. (Emdebian Grip processes 7 architectures simultaneously on blavet.debian.org). Peter Palfrader kindly arranged for a local mirror to be available and now the entire Packages processing can be done using symlinks. Much, much better.

Actual package movement data comes directly from dak via projectb - something else which makes packaging these scripts for use on non debian.org boxes a bit hard.

Once again, I am indebted to the EDOS team (please, please keep working on edos-debcheck - it hasn't had uploads recently) because I tried to get this working with germinate but failed. (Colin - I'll be looking to borrow some of your time to work out what was going wrong.)

The dependency resolution script now means that I can meet release team requirements that when foo is updated in sid to depend on libbar2 but Emdebian Grip only has libbar1, the scripts will automatically pick up libbar2 and add it to Emdebian Grip. The current sid version gets pulled in and (the theory goes) will migrate into testing-grip as an almost automatically valid candidate. Processing of the dependency can happen within hours of the updated version of foo arriving in Emdebian Grip but as long as it happens within a few days I think everyone will be fine with it.

I've got a sync script too which can periodically run across the entire suite and check for packages which have slipped the net. I'll have to see how often that needs to run but once a week doesn't sound too painful.

Processing for Emdebian Grip is very fast. Most of the time is taken uploading:

2012-01-23 22:24:42 add sid-grip deb main armhf libfltk-images1.3 1.3.0-5em1

2012-01-23 22:24:52 add sid-grip deb main i386 libfltk-images1.3 1.3.0-5em1

2012-01-23 22:25:07 add sid-grip deb main mips libfltk-images1.3 1.3.0-5em1

2012-01-23 22:25:25 add sid-grip deb main powerpc libfltk-images1.3 1.3.0-5em1

2012-01-23 22:26:00 add sid-grip deb main amd64 libstdc++6-4.5-dev 4.5.3-12em1

2012-01-23 22:26:34 add sid-grip deb main armel libstdc++6-4.5-dev 4.5.3-12em1

(It was a lot longer, comparatively, when I was having to rsync and then dget instead of just read from the local filesystem.)

I've also been working on an init script which will gradually work through the subset of packages by order of Priority - approximately what a new architecture (like armhf) would do. Note that Emdebian Grip supports armhf already. The only slight concern is whether the init script needs to be throttled back to not flood the queues with hundreds of uploads an hour (which it could end up doing, at least for the first 24 hours).

Logs of package movements are available: http://www.emdebian.org/grip/logs.php

Packages can be searched too: http://www.emdebian.org/grip/search.php

More on Emdebian Integration on the Debian wiki: http://wiki.debian.org/EmdebianIntegration

Now all I need is a fix for #655919 FTP team?

I gave a presentation on UEFI at LCA 2012 - you can watch it here, with the bonus repeat (and different jokes) here. It's a gentle introduction to UEFI, followed by some discussion of the problems we've faced in dealing with implementation bugs.

The fundamental problem is that UEFI is a lot of code. And I really do mean a lot of code. Ignoring drivers, the x86 Linux kernel is around 30MB of code. A comparable subset of the UEFI tree is around 35MB. UEFI is of a comparable degree of complexity to the Linux kernel. There's no reason to assume that the people who've actually written this code are significantly more or less competent than an average Linux developer, so all else being equal we'd probably expect somewhere around the same number of bugs per line. Of course, not all else is equal.

Even today, basically all hardware is shipping with BIOS by default. The only people to enable UEFI are enthusiasts. Various machines will pop up all kinds of dire warnings if you try to turn it on. UEFI has had very little real world testing. And it really does show. In the few months I've been working on UEFI I've discovered machines where SetVirtualAddressMap() calls code that has already been (per spec) discarded. I've seen cases where it was possible to create variables, but not to delete them. I've seen a machine that would irreparably corrupt its firmware when you tried to set a variable. I've tripped over code that fails to parse invalid boot variables, bricking the hardware. Many vendors independently fail to report the correct framebuffer stride. And those are just the ones that have ended up on hardware which crosses my desk, which means I haven't even tested the majority of consumer-grade hardware with UEFI.

The problems with UEFI have very little to do with its design or the ability of the people implementing it. After a few years of iterative improvements it stands a good chance of being more reliable and useful than BIOS. Increased commonality of code between vendors is a blessing and a curse - in the long term it means that these bugs can be shaken out, but in the short term it means that at least one hardware-destroying bug has ended up carried by multiple vendors. Right now we're still in the short term and it's likely that we'll find yet more UEFI bugs that cause all sorts of problems. The next few years will probably be a bumpy ride.

comments

For my day job I build storage systems. A lot of what I do at present involves caring a lot about how different OSes deal with things like new LUNs being presented from a SCSI target, or errors along a subset of the available paths to a device. It will come as no surprise to you to discover that they all suck (for values of all equal to Linux, Solaris, Windows and VMWare). New LUNs are particularly annoying. I'm in the situation that creation and removal of a LUN is exceptionally easy. Hmmm. Maybe I need to back up here a bit first. SCSI has the concept of a target (think, device, eg hard drive). Each target can present multiple logical units. Each of these is assigned a number - a Logical Unit Number. Most devices (a hard drive, or a CDROM drive) will present a single LUN. A storage array will tend to present multiple LUNs; one for each volume that is exported to the host. At the host level each LUN really just looks like a separate device (for Linux /dev/sda and /dev/sdb may well be separate LUNs on the same array, rather than 2 separate arrays/hard drives, for example. At the block device level you don't care about the difference usually). Anyway. For various reasons I end up adding and removing LUNs quite often. And there are ways for the array to indicate that this has happened to the host (the UNIT ATTENTION/REPORT LUNS DATA CHANGED check condition seems to be favoured these days, as a complete Fibre Channel LIP can be disruptive). What I'd like to happen in that case is the host to pick up the check condition and drop and/or add the devices that have changed. Instead everything wants a manual rescan. rescan-scsi-bus tends to be simplest for Linux. Windows wants a manual refresh in Disk Administrator. VMWare a "Rescan HBAs" from vSphere. Solaris a "devfsadm -C" and possibly a "cfgadm -al" first. And all of these can be temperamental about picking up the changes. We've done a lot about hotplug for the desktop user experience, without doing the same level for the server experience. I appreciate that there are situations that you don't want your server to reconfigure things without being told to, but the current situation can be detrimental (for example Linux multipathing will hold a device open even after it's disappeared and is returning an "INVALID LUN" response; it would be much better if it could cleanly close that device and wait for it to return). Storage is capable of being much more than just a single block device these days, and it's a shame that nothing seems to deal fully with that fact. (Yes, yes, I should write and submit patches, but I appreciate that there's not always a simple answer, nor necessarily an answer that works for all situations automatically. Plus, y'know, not enough hours in the day and I hope you all appreciate I've taken a break from watching BSG to write this.)

Today, six months have passed since the massacre I survived at Ut ya. It strangely feels simultaneously as if it happened ages ago, and as if it happened yesterday. I will write a longer post at some point, to try to sum up some thoughts, feelings and reflections I have made in the aftermath. But this post is actually intended to be somewhat, albeit weirdly, cheerful because today, of all dates, I was given a link to a web album by the Police where they post photographs of items they have recovered and cleared for re-release. And I got a kick out of this. Check it out!

I m getting my OpenVMS shirt back! Yay for conference T-shirts!

Something I've picked up from reading about economics is the concept of "the margin". It's a way of thinking about problems that more people ought to take into consideration. What is "the margin"? It's that space on a line, in the middle, between two extremes, where the transition from "yes" to "no" occurs. If I offered you a million dollars for the computer you're reading this on (for broad definitions of 'computing device'), you'd probably take me up on the offer. For 0 dollars, you would not. Somewhere, in the middle, is a number where you'd change your mind from "nope, won't sell" to "well... sure, what the heck". That is, loosly defined, a margin. As an example, when people debate about "intellectual property", they often use terrible examples: companies like Microsoft, or performers such as Lady Gaga. Those are bad examples because they are complete outliers, way off on one end of the curve. It's hard to disagree with "so what if Lady Gaga earns a bit less revenue from her music, she's got plenty to live on" when you talk about copyright being a means for artists to support themselves with. Thinking "at the margin" is about those bands that currently barely sell enough music to work professionally as musicians. In scenario A, they are able to work creating music, thus creating more, and likely better music than if they merely pursued it as a hobby. In scenario B, they fall on the other side of the margin and therefore have to get 'real jobs'. This means that their music takes a back seat, and they produce less of it. Now, copyright and company are a complex conundrum with many facets; my point is simply that when thinking about big changes, we should think what will happen at the margin, not what will happen to the outliers.

PHP 5.4.0 is around the corner, with RC6 released this weekend. With the courtesy of Ond ej Sur it s already available in experimental. Earlier this week, Raphael Geissert, tested some PHP extensions with the new version and reported 16 bugs (severity: important) against those who failed to build with PHP 5.4. As they will become RC bugs when 5.4.0 will enter unstable (probably around mid February), I preferred to handle them sooner than later. The result is 3 patches sent (one already uploaded) and 5 NMUs done. During the process I poked through a lot of upstream SCMs. In the way I found out a trivial change was done in PECL s SVN two years ago for all the extensions located there, which got me suspicious regarding some extensions we have. For non PECL hosted extensions, I had to track if and when a fix was done and use it for building or do a trivial fix myself. Packages using the 3.0 (quilt) source format were extremely easy to fix, and I was quite happy it generally went fast. In general I m a passive subscriber to the Debian PHP Maintainers mailing list, and finally could help actually and not just reply emails. For me it s also doing some Debian work after a few months of focusing on the coming LibreOffice 3.5 release. update [26/1/2012]: From the 16 issues, only 2 aren t fixed already or will be on the next upstream release. As their upstreams are dead, this is in the hands or the debian people, at least till they ll FTBFS on unstable (instead of experimental).
Filed under: Debian GNU/Linux, PHP

Hard to believe I've consumed all of 1981's Usenet posts now on olduse.net, and it's been running for 7 months already.

---

Last night, there was a "very long" post, describing nearly every node on usenet in 1982. There had been a warning about this post the day before, since it would take many sites half an hour to download at 300 baud. It was handily formatted as a shell script, which created per-node files. So, I ran this code nobody has run since 1982. It worked. I got files. I tossed them on the olduse.net wiki, and used some ikiwiki code TOVA contracted me to write just a few months ago, to make clickable links on my usenet map. The map data was contributed in another post a while back. By 1982, usenet is getting nearly impossible to map with 1982 technology of ascii art. I enjoyed throwing graphviz, git, wikis, and the web at it. So, we have a collaboration across time, me and "Mark" and a lot of people who described their usenet nodes and piles of technology that make creating a mashup easy. Awesome!

---

I blog about stuff I find on the olduse.net blog. It's an open blog; Koldfront also blogs there, and we welcome other bloggers. Some of the highlights for me have included: As the space shuttle program is winding down, reading the excitement about the first shuttle flights, and the play-by-play coverage of a launch, posted to net.columbia by a high school student borrowing his dad's account. (A usegroup name that's hard to read without remembering its fate). The announcements of the Motorola M68k, the IBM PC, and the CD-ROM. Reading the TCP-IP digest, and Postel's plans for launching IPv4 soon, while the world IPv6 launch is being planned now. (The nay-sayers are especially fun to read. Including the guy who was concerned about the address space size, in 1981!) Learning that nethack ascention tales have a history streching back 30 years, to rogue, and that the stories back then had much the same flavor as they do today. Various celebrity sightings. Dennis Ritchie teaching C and Unix. Bill Joy talking vi. RMS talking .. nuclear politics? The general development of usenet. B-news being rolled out, groups proliferating, many first inklings of what will be major problems and developments in 5 or 10 years. A shift in tone is already apparent, by now usenet is not only about announcements, there are already some flames. Still 9 years to go!

I really should write these a bit more often. Wow, I can't believe it was over 4 years ago that I started having occasional face to face meetings with the ISC DHCP folks. The entire ISC DHCP team (of 5) was in town for an all-hands meeting, and Larissa Shapiro, the Product Manager for DHCP (and BIND) suggested it would be a good opportunity for another catch up. Given the current (bad) state of DHCP 4.2 in unstable, I thought this was an excellent idea, and so we all had lunch on Tuesday. I pretty much set the agenda, and it was

• general state of 4.2.2 in Debian
• situation with GNU/Hurd and their patch to fix an FTBFS (#616290)
• the current FTBFS issues with kFreeBSD (#643569)
• the embedded BIND sources in the DHCP source
• removal of the RFCs from the embedded BIND source (#645760)

The general state of 4.2.2 in Debian In a nutshell, it's a bit of a mess. We've got release critical bugs, build failures, the whole cat and kaboodle. It makes me very sad, because 4.2.2 was the first 4.2 series that I had a chance to upload, and I was very excited to do so, because it contains the hotly desired LDAP patches merged upstream. Unfortunately, it's also got the beginnings of the BIND/DHCP merger that's going to be BIND 10, and that is all a bit of a mess. It's directly responsible for the kFreeBSD FTBFS and the introduction of the RFCs, which are both keeping 4.2.2 out of testing. I gave the ISC folks a high-level overview of how Debian development works, and the normal progression of packages from unstable to testing to stable, and the release process and whatnot, and impressed upon them the implications of the current release critical bugs. I also showed them how Ubuntu development fitted into the picture. Finally, I showed them the popcon statistics for DHCP. I think they found it useful. FTBFS issues on kFreeBSD This was a good segue to #643569. The issue is actually with the embedded BIND sources. I'd already forwarded this bug upstream when it first happened, but I don't know what had happened to it. They seemed to act as if this was the first they'd heard of it. I'm hoping that they can get this fixed in 4.2.3, which is due around the end of the quarter. Embedded BIND sources Since we were already talking about an issue caused by the embedded BIND sources, we moved on to talking about #645760 and the existence of the embedded BIND sources in general. It should be pretty straightforward for them to strip the RFCs out of the source. They've already done it in the past for the DHCP sources, so I'm also hopeful that this will get resolved in 4.2.3. The issue of the embedded BIND sources is apparently a bit more complicated, although the day before our meeting, Michael Gilbert filed #643569 and #645760, so I hope that the ISC folks can take a look at these patches and see if it's feasible to adopt them. Patches for GNU/Hurd Finally we talked about #616290, which I know is near and dear to the GNU/Hurd porters' hearts. We probably spent the most time talking about this. The DHCP developers have concerns about accepting a patch for an OS that they do absolutely no testing on, and also questioned the viability of the OS in general. They stressed that they're fairly thin in numbers relative to what they have on their plate to achieve this year, and so pushed back pretty firmly on accepting the current patch. I relayed the frustration that the Hurd folks were having about a lack of dialogue around the patch (most of the interaction has been via an ISC support person). There was actually a bit of a split between the developers, with one of them appreciating that the Hurd was unlikely to go anywhere as a platform without a working DHCP client, so in some regards, they were condemning the platform by taking the position they were taking. They're going to go away and take another look at the patch and try to come back with some actionable feedback on what needs to change to make it more acceptable to them, so we'll see what comes of this. I'm not particularly optimistic that anything acceptable to the GNU/Hurd folks is likely to happen any time soon, but maybe if the patch gets cleaned up a bit more, I'll just bite the bullet and start applying it to the Debian package. BIND 10 One of the guys is more involved in BIND 10 than DHCP, and asked if I could help out with the packaging of a build dependency for BIND 10. It seemed like #578387 was languishing so I offered to pick it up. I've not packaged a library before, mainly because the library packaging guide has scared me off it (I feel I lack the deep C fu that seems necessary), but I figured that this would be a good learning opportunity, so I'm going to dive in.

For the sake of anyone else who s fighting their screens, I ve got a script that will do this (but very very slowly) setup script

xrandr --output VGA1  --auto
xrandr --output LVDS1 --auto
xrandr --output VGA1  --rotate left
eval " monconf "

monoconf script

#!/usr/bin/env python
import subprocess
output = subprocess.check_output(["/home/tag/.bin/mon.ls"])
output = [ item.split() for item in output.split("\n") ]
mons =  
for mon in output:
    if len(mon) > 0:
        if mon[1] == "connected":
            res=mon[2]
            res=res.split("x")
            for item in res[1].split("+"):
                res.append(item)
            res.pop(1)
            mons[mon[0]] = res
BOTTOM_LEFT = "LVDS1"
TOP_RIGHT="VGA1"
LEFT_WIDTH  = mons[BOTTOM_LEFT][0]
LEFT_HEIGHT = mons[BOTTOM_LEFT][1]
RIGHT_WIDTH  = mons[TOP_RIGHT][0]
RIGHT_HEIGHT = mons[TOP_RIGHT][1]
print "xrandr --output %s --pos 0x%s" % (
    BOTTOM_LEFT,
    (int(RIGHT_HEIGHT) - int(LEFT_HEIGHT)))
print "xrandr --output %s --pos %sx0" % (
    TOP_RIGHT,
    int(LEFT_WIDTH)
)

and the mon.ls command

xrandr -q   grep "^[^\ ].*"   grep -v Screen

All of this is super hacky, but it works.

Kim Jong-Il is gone. That said, he continues to live on, looking at things, on the popular blog Kim Jong-Il Looking At Things which continues to be updated with new content from the archives. It is now joined by Kim Jong-Un Looking At Things. I think I agree with Jo o Rocha, creator of the original, that the younger Kim seems to be missing some hard-to-pin-down quality that made the original work well.

Debtags for derivative distributions Sometimes I do cool stuff and I forget to announce it. Ok, so I recently announced a new Debtags website. I forgot to say in the announcement that the new website does not only know of Debian packages: see for example this page, at the very bottom it says: "Distributions: oneiric, precise, sid, testing". This means that already, here and now, debtags.debian.net can be used to tag packages from both Debian and Ubuntu, and can easily be extended to cover the entire Debian ecosystem. If you are a package maintainer, you will notice that your maintainer page shows your packages from everywhere. If you want to filter things a bit, for example hide obsolete packages from an old Debian Stable or Ubuntu LTS, just click on the "Settings" link on the top right to configure the page. How it works The magic is in this mergepackages script, which is run daily, and exports merged Packages files at dde.debian.net. The debtags.debian.net concept of Packages and Sources files are just those all-merged.gz and all-merged-sources.gz. The merging is simple: that rebuild script processes files in order, and the first version of a package that is found is chosen as the base for the one that will go in the merged Packages file. Some fields like "Description" are just taken from this pivot package, others like Architecture or dependencies are merged into it. It's arbitrary, but works for me: the result has all the packages with all their possible architectures and dependencies, and is ready to be indexed with apt-xapian-index. At the moment I pull data from Debian and Ubuntu, but you can see that the script can easily be extended to pull data from any Debian-style ftp archive, so any Debian derivative can go in. I've already started negotiations with the Derivatives Census on how to add any Debian derivative and keep the list up to date. How to export tags for your own distribution I'll use Ubuntu as an example since the data is already available. The way you add Debtags to the Ubuntu packages file is just this one:

1. Get the full reviewed tag database
2. Optionally filter out those packages that you are not interested in
3. Tweak this script to build an overrides file.
4. Give the overrides file to your favourite ftp archive building tool.

The make-overrides is a bit rusty: if you improve it, please send me your changes. That is it, nothing else required, no excuses, it's ready, here, now! Hitches and gotchas This merged Packages file is a bit of a hack, and suffers from name conflicts across distributions, where two different softwares are packaged in two different distributions with the same name. Ideally, name conflicts should not happen: if a derivative decided to package kate and call it gedit, they deserve to have it tagged uitoolkit::gtk. I think it's rather important that the whole Debian ecosystem works as much as possible with a single package namespace. However, that reasoning fails if you take time into account: packages get renamed, like git and chromium, and may mean completely different things, for example, if you compare Debian Stable with Debian Sid. This last is a problem caused by debtags only working with package names but not package versions. I have a strategy in mind based on being able to override the stable tag database using headers in debian/control; it still needs some details sorted out, but I'm confident we will be able to address these issues properly soon enough. Why stop at the Debian ecosystem? Why indeed. I'm clearly trying to use FOSDEM, and the CrossDistribution devroom as the venue to discuss just that.

I'll be in Great Britain next week. I'll come to the Debian Party 2008 in Cambridge on Saturday 23rd August and will be back to London to visit 'till Wednesday 27th August. I'm staying by myself in a nice little hotel in Bloomsbury.

It will be very interesting to meet Debian people and probably do some pitching for my Aptitude GTK project which is making nice progress.

I've never been to London before. In fact, I've been once when very young and all that I can remember is that the hot dogs seemed nice :). I'm currently reading the Lonely Planet book about London and filling my program. Hi, London!

Hi folks!

We're almost done for the official Summer of Code program and I thought that I couldn't let it end without another update, so here we are (you may thank Daniel Burrows for additional poking).

The Gtk+ interface for Aptitude is making great progress. The product is not final yet but already implements many of the planned ideas, with others to come.




So, let's see the tasks presented in my previous update:

• A real user interface <- much progress here


• Being reliable <- check! we don't crash all the time anymore


• Packages dependencies, pre-dependencies, etc. <- check!


• Hyperlinks between packages <- check!


• Advanced package search <- check!


• Tags support (tag clouds ?) <- well, no clouds yet, but we have tags


• Linking with interesting data sources like popcon <- not done yet


• A lot of interesting things <- well..

In some more details: we are now much closer to the final interface. Some things are not done yet, for example, notification bars la Iceweasel (or is it Firefox ?) are in the works for unobtrusive notifications about important things and a little guidance.

We are much more reliable now. We eliminated lots of memory management problems that resulted from, mmh, imperfect coding discipline. We also lock the interface when important backend stuff reload to prevent the user from shooting himself in the foot when triggering an install when the APT cache is reloading for example.. The backend refactoring took a sizable part of this second term but it was worth it. The code is now much cleaner and uses no more (at least much fewer) ugly unscalable hacks.

One very important feature of Aptitude is the ability to easily display all kinds of dependencies and navigate through them by hyperlinking. It's now working in the Gtk+ interface as well. Feel free to click on whatever looks like a package or a package version.

We now support the powerful Aptitude package searching syntax. Daniel Burrows is talking with Enrico Zini to bring the power of apt-xapian-index to Aptitude: autocompletion! lightning fast full-text searches! tag clouds! ponies!

There is still a lot to be done. I'm not going away after the GSoC program. I'm here to stay, for Aptitude and Debian. Daniel Burrows has been very helpful and supportive. The Debian community is as awesome as I knew it before participating in the program.

Daniel Burrows is planning to merge the Gtk+ interface into the main branch in September and packages may appear into Experimental. With the very interesting evolutions of the upcoming Adept-3, Lenny+1 will show very interesting changes in the area of packages managers.

Now for you. I need you to test my interface. All necessary instructions are on the development trac : http://dev.graffit.net/aptitude/trac.

In case you've been living under a rock these past years, I shouldn't have to tell you what this is about :). Well, just in case.
The Google Summer of Code (GSoC) is an international program that offers student developers stipends to write code for various open source software projects. Debian has participated since 2006, mentoring dozens of students on Debian projects.

The important part of the 2009 edition of the Google Summer of Code is going to start next week with the Organizations application period (March 9th). By that time, we should have listed a reasonable number of ideas on the dedicated wiki page.

We will try this year to improve on the performance of the previous years, starting first with more and more dedicated manpower. If you have some time to spare to help manage our Summer of Code bid this year, we can make it a much better experience for the students and for Debian.

Help is immediately needed in many areas. Some examples:

• Map out which areas in Debian could benefit from a Summer of Code project and connect the right people with the right projects ideas


• Ideas, Ideas, Ideas for Summer of Code projects

By mid-March, we will need:

• Dedicated documentation to present Debian to the prospective student


• Publicity material to promote the Summer of Code at Debian


• Ideas, Ideas, Ideas for Summer of Code projects

Further in the spring:

• Mentors, people to review proposals, do interviews


• Ideas, Ideas, Ideas for Summer of Code projects

In the summer:

• Mentoring students


• Testing and feedback for projects


• Internal communication with the community

As you can see, there is much work ahead. It's time to pitch out your favorite pet project :)
Remember! The Summer of Code has become a prominent outreach forum for open source organizations. It puts a spotlight on each of them to provide a well-rounded and deep experience of open source development.

Right now, you can help with the Wiki, join us on IRC on #debian-soc on OFTC or join the mailing-list at soc-coordination on alioth.

The short "flyers-friendly" URL for the Summer of Code at Debian is : <http://wiki.debian.org/gsoc>. Publicize it!

See you this summer!

As sort of new year's resolution I started picking up the habit to work on release critical bugreports for squeeze again. The number is way to high to be healthy, but at least it is (still) below the amount of release critical bugreports for unstable. It will be an uneven fight because it seems that there are quite some people working on weeding out release critical bugreports in unstable, but those who are interested in weeding out releasing critical bugreports in stable seems to be limited, even though it is one of our supported releases and thus should receive quite some attention, at least by the corresponding package maintainers themself. So here is the list that I managed so far:

• 651792: not relevant for squeeze
• 653520: builds on squeeze
• 654568: re-add version information lost in reassign
• 654276: not relevant for squeeze
• 654257: not failing on squeeze
• 654810: not happening on squeeze
• 654459: not relevant for squeeze
• 654406: not release critical at all, shipped as upstream
• 655007: python2.7 isn't default in squeeze
• 655372: doesn't fail in squeeze
• 527403: libjack-dev in squeeze provides libjack0.100.0-dev
• 622903: not relevant for squeeze
• 625764: squeeze has older version of libvelocity-tools-java, not affected
• 654818: does work in squeeze
• 647795: squeeze still has libahven1-dev
• 647796: squeeze still has libahven1-dev
• 636823: not obsolete in squeeze
• 628500: no perl 5.14 in squeeze
• 629255: no perl 5.14 in squeeze
• 629284: no perl 5.14 in squeeze
• 629293: no perl 5.14 in squeeze
• 636132: no perl 5.14 in squeeze
• 636268: no perl 5.14 in squeeze
• 636271: no perl 5.14 in squeeze
• 636517: no perl 5.14 in squeeze
• 636520: no perl 5.14 in squeeze
• 636521: no perl 5.14 in squeeze
• 636522: no perl 5.14 in squeeze
• 636823: not obsolete dependencies in squeeze

That makes 29 squeeze RCs squashed so far, I hope I can keep up with it. Enjoy!

/debian permanent link Comments: 2 Flattr this

Like last year, here s a list of Debian related goals that I d like to achieve this year. I might not have the time to implement all the projects, but I like to write them down to keep me motivated. And maybe it can inspire other people to implement some of them (or to help me).

1. Finish the translation of the Debian Administrator s Handbook The target is to have the book available in April. It would be nice to complete the liberation fund until then so that the book is immediately made available under a DFSG-free license.
2. Update the Debian Administrator s Handbook for Wheezy
Translating the book in English is only the start of the journey. The real challenge is to keep the book up-to-date with each subsequent release of Debian. And Wheezy should hopefully be released in 2012 since the freeze is in June.
3. Design and implement the Debian Package Maintenance Hub It s an ambitious project that aims to merge and replace the PTS, the DDPO and their respective mail variants. It should also standardize the flow of information directed towards package maintainers. I m going to use the DEP process to drive this project. This could easily take most of the year, but hopefully I ll motivate other people to chime in and help.
4. Implement dpkg --check-db and dpkg --repair-db While dpkg is fairly reliable, it s not exempt of bugs and more annoyingly, harddrives/filesystems are not 100% reliable either, thus it happens that some internal database files get corrupted. Given that most files are text based, advanced users can manually fix them but many less skilled users are just left with a broken system that they tend to reinstall. To avoid this, we could provide a command that would try to automatically bring back the internal database to a sane state by looking for a working backup to restore (while at the same time marking some packages as requiring re-installation since we have some indications that they were present).
5. Implement storage of dpkg s internal files in Git This would be an extension of the former idea. Installing a package dpkg-db-history (any idea for a better name?) would setup dpkg hooks that would record every database change in a git repository. This repository could then be used to restore the last working version of the database.

Besides those concrete projects, I want to do better than last year on the topic of funding my Debian work. I will thus reiterate some objectives:

1. Write useful articles for Debian users and Debian contributors. They should complete the pages Mastering Debian, Contributing to Debian 101, Debian Packaging Tutorials, and help me increase the audience of this blog.
2. Write at least one Debian-related ebook (different from the Debian Admin Handbook) and sell it. It could be an ebook targetting testing users since I believe that many more users could benefit from it if they had some better knowledge of the limitations and of the way to mitigate the problems that arise from time to time. Or maybe it could be an ebook for people who want to start contributing to Debian, it could even be bundled with a few hours of mentoring.
3. By the end of the year, have at least 1/3 of my time funded by donations and/or earnings of my information products. This means doing 3,5 times better than in 2011. It should be doable given that the sales of the Debian Administrator s Handbook will contribute to this goal (once the translation is over).

That makes up lots of challenges for this year. Feel free subscribe to my newsletter to stay up-to-date with my progress and to get my monthly summary of the Debian/Ubuntu news. It s also a good way to help me reach those goals since you will be informed of all my new projects.

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