Search Results: "pm"

21 April 2009

Biella Coleman: Wintercamp Videos

A little over a month ago, I went to Amsterdam to participate in Wintercamp, an event that brought together various networked groups, from free software projects to human rights groups. We spent a chunk of time interviewing participants from these groups about the nature of organizing (and unorganizing ) and the high quality videos are now up. If you are interested in either learning about the groups there or in more meta issues (about the growth, life, rebirth, and at times death of networked organizations), these videos may be an interesting watch.

19 April 2009

Biella Coleman: Paris in June (and better with hackers)

/tmp/lab announces the second Hacker Space Festival
(Paris, 26-30 June 2009) Hacker Space Festival 2009 Call For Proposals HSF2009 In 2008, we organized HSF[1] on the spot, as an ad-hoc meeting for
hackerspaces-related networks, technical and artistic research emerging
from them and social questionning arising from them. This sudden
experiment proved to be a huge success, as much as on the
self-organizing level as on the participants and meetings quality, as
well as the emotionally-charged ambient, the kind of which you make
fond memories. The 2008 edition generated a strong emulation in France, from its
historical role as the first official hack meeting there, and in Europe
with the subsequent creation of the Hacker Space Brussels[2], the
rapprochement with The Fiber in Amsterdam and the hackerspaces.org[3]
network. Initiatives of hackerspace openings in Grenoble or Lille, or
the upcoming FrHack[4] conference show an actual enthusiasm in the
French hackers community that was doomed to the underground not so
long ago. We salute these initiatives and their diversity! Soon enough, we wanted to reiterate the HSF experience : however, it
was out of the question to institutionalize this temporary autonomous
zone, nor make it an ersatz of the previous edition, nor even to wrap
it into an elite or underground aura. On the opposite, we ardently
desire; and especially to explore further, in all directions some
lesser known domains (see below) et foster meeting and sharing around
experiences at the confluence of art, technology and politics. The world financial crisis, the decay of democracy in Europe, the
obscurantism, paranoia and lack of culture presiding over legislation
(Internet and Reaction Err Creation Law[5][6]) seem a fertile
environment for the sensible development of new (social ) life forms.
Quick! Let s rest for a few days in jubilation and ecstasy to take a
deep breathe of freedom under the indelicate smells of the medicine
factory nearby! For if the public space is shrinking to oblivion, where any side-step
becomes suspect, and that, from an early age (deviant behavior
detection in nursery school), where moving without a mobile phone
becomes suspect (hello you Julien Coupat[7], a French political
prisoner in France!), there s a domain that the Leviathan would have a
lot of trouble to contain, and for a reason: that of sensitivity. Even
the desperate attempts of the State to block the free and premonitory
expression of sense (hello you Demeure du Chaos![8]) cannot do anything
against a loud laughter or a knowing glance, a sensual kiss or an
explosion of colors. Sensitivity, we could say, is what is left to a human being when she
has nothing anymore, and differenciates her from the body corporate or
the institution, that are, in essence, devoid of it. Therefore, Art
definitely remains the public space to share between humans, and only
between us. And if it the last one to share, we propose to explore it
and take it over during the upcoming edition of the Hacker Space
Festival, from the 26th to 30th of June, 2009 at Vitry sur Seine[9]. ========================================================================
Keynote Speakers: Sergey Grim and Larry Fake with Eric Schmoudt
Groogle Summer of Crode, Survivor style
VLC, I vote against you because you really fucked up when ========================================================================
== W A N T E D ========================================================= Focus on solutions rather than problems. * The Final (Hardware) Frontier: Open FPGA Cores, Reverse Engineering
* Designer Religions and Creative Beliefs Systems
* WiFiDoors & WiFi System-on-Chip controllers firmware hacking,
infection & backdooring
* Telecom Core Network Equipment Reverse Engineering: MSC, STP,
Switches,
* Algebraic Attacks and Modern Cryptography Attacks
* Autonomous, Parasitic and Viral Drones
* Enhanced or Infected Reality Swarms
* Auto-Builders / Self-Fabrication
* Embedded OS breakins stories & recipes
* Actualization rather than mere concepts
* FPGA & ASIC hacking / backdooring
* Cloud+Privacy+Open Source: O Brave New World?
* Explosion-Proof clothing
* Radio Appz & Hackz: Mesh @ RF Layer 1-3
* Database & Privacy
* Problematic & Ethical Open Source/Content Licenses
* Institutional Relationships: Lobbying or Licking?
* Non Lethal Protection (anti-taser vests?)
* Survival in the Age of the Ministry of Immigration and National
Identity
* Mental asylum improvised visit
* Open Source Legacy Media(TM) Production Solutions (TV, Radio, Press,
DRM)
* Gas Sensors & Environmental Benchmarking
* Building Hackerspaces Without Money
* Milsatcomm hacking: Military satellites shots, broken birds in the
sky
* Other research topics on security and insecurity
* Academics and Hackers
* Organics and Fermentation
* Clean Food in Tainted Environment
* Low Impact Energy & Recycling
* Media Sandwich: layers of crap makes good food?
* Deconstructing Carla Sarkozy
* Knitting DIY Factory (jazzy, eh?)
* Signs of life among industrial wasteland
* Hallucinogenic & Computing: Can you Code on Acid?
* Mesh Networking (Wireless BattleMesh Royal!)
* Legal Sabotage: When Democracy Needs You And anything that does not fit. ========================================================================
== P R O P O S E ======================================================= Send you contributions to HSF2009-CFP@lists.tmplab.org + Type of the proposal: 1. conference (45min. presentation + 10min. for questions)
2. workshop / demo (30min. 2 heures)
3. installation / performance (music, plastic, sound, video) Lightning talks can be proposed and organized until the last moment,
according to available space and schedule, in the form of BarCamps or
Blitz Conferences. + Required Information: * Title of the presentation
* Type (see above)
* Language : French or English
* Name of speaker(s)
* Affiliation (organization / company)
* Short biography
* Abstract (5 to 10 lines)
* Topics / Keywords
* Includes a demo? YES NO
* Release during the festival? YES NO
* Internet connection required? YES NO + Acceptable Formats * Open Document
* PDF
* Plain Text
* RTF + Agenda * beginning of proposals : now
* end of proposals : 01 May 2009
* selection notification : 07 May 2009
* publication of program : 15 May 2009 + Evaluation criteria for proposals: 1. Innovating Topic
2. Open Technology
3. Demonstration / Live Act
4. DIY Reproducibility
5. Fun Potential The Programming Committee resembles that of last year
See : http://hackerspace.net/committee ========================================================================
== V E N U E =========================================================== /tmp/lab
6 Bis rue Leon Geffroy
94400 Vitry sur Seine
France http://hackerspace.net/directions ========================================================================
== P A R T I C I P A T E =============================================== Email : http://lists.tmplab.org/listinfo.cgi/hsf2009-talk-tmplab.org
CFPmail: HSF2009-CFP@lists.tmplab.org
IRC : irc://irc.freenode.net/frlab
Jabber : xmpp:hsf2009@space.cepheide.org?join
Wiki : http://hackerspace.net/hsf2009 ========================================================================
== L I N K S =========================================================== The CFP is available online at http://hackerspace.net/cfp [1] http://hackerspace.net/hsf2008
[2] http://hsb.wikidot.com/
[3] http://hackerspaces.org/
[4] http://www.frhack.org/
[5] http://jaimelesautistes.fr/
[6] http://laquadrature.net/
[7] http://fr.wikipedia.org/wiki/Julien_Coupat
[8] http://www.demeureduchaos.org/
[9] http://hackerspace.net/
Philippe Langlois
Email: philippelanglois@free.fr
PGP Key: 8DAEE244

Manoj Srivastava: Manoj: Looking at porcelain: Towards a generic, distribution agnostic tool for building packages from a VCS

This is a continuation from before. Before I go plunging into writing code for a generic vcs-pkg implementation, I wanted to take a close look at my current, working, non-generic implementation: making sure that the generic implementation can support at least this one concrete work-flow will keep me grounded. One of the features of my home grown porcelain for building package has been that I use a fixed layout for all the packages I maintain. There is a top level directory for all working trees. Each package gets a sub-directory under this working area. And in each package sub-directory, are the upstream versions, the checked out VCS working directory, and anything else package related. With this layout, knowing the package name is enough to locate the working directory. This enable me to, for example, hack away at a package in Emacs, and when done, go to any open terminal window, and say stage_release kernel-package or tag_releases ucf without needing to know what the current directory is (usually, the packages working directory is several levels deep /usr/local/git/debian/make-dfsg/make-dfsg-3.91, for instance. However, this is less palatable for a generic tool imposing a directory structure layout is pretty heavy. And I guess I can always create a function called cdwd, or something, to take away the tedium of typing out long cd commands. Anyway, looking at my code, there is the information that the scripts seem to need in order to do their work.

Staging area. This is where software to be built is exported (and this area is visible from my build virtual machine).
- User specified (configuration)
Working Area. This is the location where all my packaging work happens. Each package I work on has a sub-directory in here, and the working directories for each package live in the package sub-directory. Note: Should not be needed.
- User specified.
Working directory. This is the checked out tree from the VCS, and this is the place where we get the source tree from which the package can be built.
- Since we know the location of the working are, if the package name is known, we can just look in the package s sub-directory in the working area.
  - For rpm based sources, look for the spec file
  - For Debian sources, locate debian/rules
- If package name is not known, look for spec or debian/rules in the current directory, and parse either the spec file or debian/changelog.
- If in a VCS directory, look for the base of the tree
  - tla tree-root
  - bzr info
  - git rev-parse --show cdup
  - hg root
  - You have to climb the tree for subversion
- If you are in a debian directory, and changelog and rules files exist
Then, look for the spec file or debian/rules in the base directory
package name
- User specified, on the command line
- If in the working directory of the package, can be parsed from the spec or changelog files.
upstream tar archive
- Usually located in the parent directory of the working directory (the package specific sub-directory of the working area)
- If pristine-tar is in use, given two trees (branches, commits. etc), namely:
  - a tree for upstream (default: the branch ~upstream~)
  - a tree for the delta (default: the branch ~pristine-tar~)
  The tree can be generated
- Given an upstream tree (default: the branch ~upstream~), a tar archive can be generated, but is likely to be not bit-for-bit identical to the original tar archive.

So, if I do away with the whole working area layout convention, this can be reduced to just requiring the user to:

Specify Staging area
Call the script in the working directory (dpkg-buildpackage imposes this too).
Either use pristine-tar or have the upstream tar archive in the parent directory of the working directory

Hmm. One user specified directory, where the results are dumped. I can live with that. However, gitpkg has a different concept: it works purely on the git objects, you feed it upto three tree objects, the first being the tree with sources to build, and the second and third trees being looked at only if the upstream tar archive can not be located, and passes the trees to pristine tar to re-construct the upstram tar. The package name and version are constructed after the source-tar archive is extracted to the staging area. I like the minimality of this. This is continued here.

17 April 2009

Matthew Garrett: Intel's commitment to open source driver support

Update: It turns out that the original PSB code is still on the moblin site - I just failed to notice that there's two pages of git repositories. I fail. Last update is from March 2008, though.

Edited again: An up-to-date version of the drm code is available as part of the Moblin kernel SRPM - repo.moblin.com isn't obviously linked off the Moblin website, but I should have thought to find and check their source repository.

By and large, working with Intel is a pleasure. In fact, a while ago I said so in a fairly obvious way. So it's a shame that the support for Poulsbo is still an absolute fucking mess with absolutely no obvious end in sight. Intel's Moblin group (the people who seem to be closest to having responsibility for providing any public Linux support for that hardware, though it's really not clear if they've got any more say in this than I do) have a kernel team that don't want or need a git tree despite having someone who's working on forward porting the driver to modern kernels - probably a job that requires more than one person given what a godawful fucking mess the last public release was, but it'd at least be nice to see what the current state is. Especially since you don't even seem to be able to get the last public release - moblin's git repositories have been rearranged and I can't find the psb-kmod one on their gitweb any more.

The most terribly depressing thing about this is that development is clearly still happening internally. Ubuntu is still being sent tarball releases by Intel, not that the code's getting any better judging by the type of diff involved. This is made even more entertaining by the bug in question being private, leaving no indication whatsoever about what bugs this code is meant to fix or why.

Closed development, random private tarball drops to partners without any public releases or changelogs, no indication of any upstream release, kernel developers entirely unrelated to the development of the driver trying to get code merged so people can actually use the hardware they bought? I'd expect this of some random far-east vendor with no experience in working with Linux, but not a company that's consistently one of the top ten contributors to the kernel and has frequently touted their level of support. There's no meaningful support for Poulsbo. There's just a thin cardboard cutout that's been carefully placed in front of a hole filled with users' hopes and money.

Seriously Intel. Sort it the fuck out.

16 April 2009

Manoj Srivastava: Manoj: Towards a generic, distribution agnostic tool for building packages from a VCS

I have been involved in vcs-pkg.org since around the time it started, a couple of years ago. The discussion has been interesting, and I learned a lot about the benefits and disadvantages of serializing patches (and collecting integration deltas in the feature branches and the specific ordering of the feature branches) and maintaining integration branches (where the integration deltas are collected purely in the integration branch, but might tend to get lost in the history, and a fresh integration branch having to re-invent the integration deltas afresh). However, one of the things we have been lax about is getting down to brass tacks and getting around to being able to create generic packaging tools (though for the folks on the serializing patches side of the debate we have the excellent quilt and the topgit packages). I have recently mostly automated my git based work-flow, and have built fancy porcelain around my git repository setup. During IRC discussion, the gitpkg script came up. This seems almost usable, apart from not having any built-in pristine-tar support, and also not supporting git submodules, which make is less useful an alternative than my current porcelain. But it seems to me that we are pretty close to being able to create a distribution, layout, and patch handler agnostic script that builds distribution packages directly from version control, as long as we take care not to bind people into distributions or tool specific straitjackets. To these ends, I wanted to see what are the tasks that we want a package building script to perform. Here is what I came up with.

Provide a copy of one or more upstream source tar-balls in the staging area where the package will be built. This staging area may or may not be the working directory checked out from the underlying VCS; my experience has been that most tools of the ilk have a temporary staging directory of some kind.
Provide a directory tree of the sources from which the package is to be built in the staging area
Run one or more commands or shell scripts in the staging area to create the package. These series of commands might be very complex, creating and running virtual machines, chroot jails, satisfying build dependencies, using copy-on-write mechanisms, running unit tests and lintian/puiparts checks on the results. But the building a package script may just punt on these scripts to a user specified hook.

The first and third steps above are pretty straight forward, and fairly uncontroversial. The upstream sources may be handled by one of these three alternatives:

compressed tar archives of the upstream sources are available, and may be copied.
There is a pristine-tar VCS branch, which in conjunction with the upstream branch, may be used to reproduce the upstream tr archive
Export and create an archive from the upstream branch, which may not have the same checksum as the original branch

The command to run may be supplied by the user in a configuration file or option, and may default based on the native distribution, to dpkg-buildpackage or rpm. There are a number of already mature mechanisms to take a source directory and upstream tar archive and produce packages from that point, and the wheel need not be re-invented. So the hardest part of the task is to present, in the staging area, for further processing, a directory tree of the source package, ready for the distribution specific build commands. This part of the solution is likely to be VCS specific. This post is getting long, so I ll defer presenting my evolving implementation of a generic vcs-pkg tool, git flavour, to the next blog post. This is continued here.

Peter Eisentraut: Web browsers vs. debtags

So I wanted to see what web browsers are available in Debian. The first stop was http://packages.debian.org/. Going to the page of one browser package and clicking on "Browser" in the tags area only gives you the explanation of the tag, but not the list of other packages with that tag. Is that available somewhere?

So next try maybe grep-dctrl ... oh, grep-debtags appears to be the ticket.

$ grep-debtags -n -sPackage web::browser
arora
browser-history
caudium-dev
caudium-modules
caudium-perl
caudium-pixsl
caudium-ultralog
chimera2
conkeror
cookietool
dhelp
edbrowse
elinks
elinks-lite
elvis
elvis-console
epiphany-browser
epiphany-browser-dev
epiphany-extensions
epiphany-gecko
ezmlm-browse
galeon
galeon-common
gtkcookie
iceweasel
jsmath
junior-internet
kazehakase
konq-plugins
links
links2
lynx
lynx-cur
lynx-cur-wrapper
mozilla-firefox-adblock
mozilla-noscript
netrik
netsurf
saods9
stripclub
sugar-web-activity
surfraw
w3m
w3m-el
w3m-img
wapua
claws-mail-dillo-viewer
dillo
konqueror
midori

How many of those are actually web browsers? Probably about half of them. (Example: caudium (not listed) is a web server, caudium-dev is its development package, not very close to a web browser.)

This would actually be quite a useful interface if the tags had any relationship to reality. I was in fact looking for a lightweight graphical browser, so this is a plausible command:

$ grep-debtags -n -d -sPackage web::browser -a interface::x11 -a -! suite::gnome -a -! suite::kde

which gives me 15 hits, of which 8 or 9 are actual web browsers.

Well, my search for a lightweight browser stopped here:

iceweasel
lightweight web browser based on Mozilla

Yeah! ;-)

15 April 2009

Julian Andres Klode: python-apt to become first Debian package to support Python 3

Python 3.1 is still in experimental, but python-apt already has a fully working Python 3 version. With the patch being available in the jak branch, python-apt Bug#523645 can be closed soon. And this is not the only change. Memory usage has been decreased by 10MB by creating the Package() objects on the fly instead of pre-creating all 25000 ones. All classes which previously supported the has_key() method now support __contains__, which allows you to write key in mapping . But that s not all. The Package class now gained support for setting the candidate version of a package, in the same way you get it, using the property: mypkg.candidate = max(mypkg.versions). And you can now pass file descriptors to functions previously only working with file() objects. But we re not done yet. The complete API change is pending, renaming everything to PEP-8 compliant names and deprecating the old ones, which will be removed at a later time (after the release of Squeeze). The module apt.debfile is not affected by this change, because it already used the correct names. But for Python 3, we will not keep backward compatibility, in order to make coding easier and to make it clear that applications should be ported to the new API. And if you want to get your feature into python-apt now is your time. If you want something merged, provide the code, the documentation (with example) and a list of use cases; and report a wishlist bug in the Debian BTS. And if you want to write a tutorial about python-apt, write it in reStructuredText and I will add it to the documentation. The documentation is currently basically an API reference and there could be much more text. Python-apt 0.7.90 is currently uploading. The whole development will result in python-apt 0.8. Posted in Debian

Julien Danjou: Taking the other direction

I've started to develop awesome more than 18 months ago, and somehow I feel it's time to stop a bit and think where we come from and where we are going to. The motivation I never though I'd be written a window manager one day. That seems kinda stupid when you see how many window manager there's around. As many people, I've tested and have been using tons of window manager: Window Maker, Fluxbox, etc. In August 2007, I was using fvwm since 2004 and was quite happy with it. I used the famous fvwm-crystalhttp://www.fvwm-crystal... as a configuration starter and then rewrote lots of stuff. Digging into fvwm configuration files was boring, and since I'm lazy, I never really configured it to fit entirely my needs. The thing is that, in July 2007, my workstation died. I bought a new one based on the amd64 architecture. Too bad, with this new box, fvwm decided that it will not longer runs and was segfaulting almost every time I logged in. I was really upset. Another failure in the window manager world. So I decided to get the yearly ride of testing many window managers. I went on the no more developed stuff like the *boxes, ion3, etc but well, I did not like them, there were not powerful enough, too bugged or upstream was insane. Then I found xmonad. The Haskell configuration file format made my cry. I did not want to learn Haskell, it seemed too obfuscated to me. At that time it was even not packaged for Debian, so I gave up. But I found dwm in the meantime, and I loved it. It was simple, and the source code was almost understandable and easy to hack. I subscribed to the dwm mailing-list, in order to participate to its development, etc But I got really disappointed. No patch were welcome and the development seemed to be almost finish in this sight. People patches were lying around, but no one really care. Each user was managing its own set of patches. That's not what I learnt and what I love in free software. So, as many users, I began to maintain my patches in my corner. But I began to have more ideas The jdwm I just added a 'j' in front of dwm and started to hack it days and nights to add many feature I missed, like multi-head, etc On 5th September 2007, I created a git repository to host my code. That's gonna be awesome. Five days later, on 10th September, I finally found a name for my new pet: awesome, borrowed from Barney Stinson who heavily uses and abuses this word. The 1.x branch The first releases until December were noted 1.x. It was just a better dwm with a simple flat configuration file.. The configuration file used libconfig, but it was a very poor choice. And I was not able to put in into Debian because of name clash. The 2.x branch The 2.x branch came in January 2008 with a brand new configuration file format based on libconfuse, which was a bit more powerful. Many concepts and features that have been added in this branch are still used in the current 3.x branch. At this time, between December 2007 and April 2008, the community was growing smoothly. But as I said, awesome 2 was based on a flat configuration file. That raised a problem very soon: users expectation were growing and the development team (me and a couple of regular contributors) was unable to cope with them. One of the event that started to change my mind was the support for titlebars. When I've added titlebar support, it was minimal. It was on top of a window, with the window title. Dot. Then I've started to add a lot of options, like the application icon drawing, the position (left, right, bottom) etc. And then users started to ask for more, like: "add titlebar on windows only when the window is floating". That's ok, but that's complicated: that's again another option to do some stuff conditionally. And then, why don't add titlebar on windows when <insert random events here>? The 3.x branch Why At that time, around April 2008, I'd totally stopped development. I was trying to find a solution which was simple and powerful. But after 2 weeks of thinking, I was not able to find anything else than: use a real language for configuration. So, I've started prototyping awesome 3 using Lua. The choice was not obvious, and despite the problem Lua might suffer, it's one of the easiest language to integrate into an existing application. There's still a video of a first version here. But, let's go a little back: in January 2008, Arnaud Fontaine contacted me because he was interested to use awesome as one of its school project. He decided to port awesome from Xlib to XCB, a modern asynchronous X library. His work took some time, but in May 2008, Arnaud did finished to port git master version of awesome to use XCB. Consequently, I decided to start a new major branch, using XCB instead of Xlib (no change for users in this regard) and Lua instead of our previous flat configuration file format. Development It took me a while to get from here to there, but in September 2008, it was ready. We had a simple Lua API, and the XCB port was working perfectly. It took us some time to release and have something totally working, because we had to work on XCB and contribute back to the project. It was really not ready to use by an application, but we did great work in this area and it's now really fine. We're still here Releases continue to happens, 3.1 around December 2008, and 3.2 around March 2009. 3.3 should be here in June. One of the drawback we had, is that we moved many stuff from C to Lua. Why? Because writing things in Lua is quicker and easier to maintain than C, and makes thing more configurable for the user. For example, the layout algorithm used to organize window were written in C until 3.2 came out. At that time, users had no choice than using a set of predefined layout to organize their windows. Starting with 3.2, if they have minimal knowledge about geometry, they can start writing a layout function organising windows on the screen. But this kind of API changes was a bit rough for users, since they had to port some part of their configuration file to the new API. The thing is that the project was still a teenager at that time, not really knowing were it will go. But I'm happy to announce that API breakage are more and more rare (so far only one minor between 3.2 and 3.3), and anyway always for the Good. But I admit that it built a bad reputation around awesome 3.x during its first month of existence. Future direction I am currently working on 3.3 development. We have still many things to do. Time passing, we get more idea, and more users. And more users bring more ideas. We also have many more contributors, and some guys are even taking maintainer-ship of some code area. Conclusion My post title is "Taking the other direction" because I feel this way. I've got that feeling that some approaches in projects like GNOME are sometimes bad. Please don't misread me, I know we are not playing in the same yard. When adding a key shortcut for starting an application makes you dig into gconf, I wonder how this is a win for the user. Well, it's probably a win for the end-user, but I surely am not one of them. And I don't intend to target them with my software, anyway. And now, when I hear things like GNOME 3.0 and the "desktop shell" approach, that makes me smile. Guys, it was time, but have luck. What I see from here, is that any desktop control interface is wrong somehow, and that there's no approach that can fulfill all users wishes. I think that we, the awesome development team (no pun intended) took the direction of building a frame-work window manager rather than a solution written in marble. We (partially) solved the issue of UI ergonomic by not writing one and allowing the user to write his own. I don't say that's easy to do for most of users, but it's doable. And I think it's worth it: I use window managers since I use Linux, around 1998. If something like awesome came 5 years ago, I'd be using it so far, because you can write Fluxbox or WindowMaker using awesome in a hundred of Lua code. And you can write your own version of it. And it starts in less than 3 seconds, supporting almost all standard desktop specification (ICCCM, EWMH, XDG, system tray, message notification, D-Bus, etc), whereas many of the window mangers do not. You can even write and play space invaders. Finally, I'm happy about the the road we took so far, and hope we will continue into that direction. The rants I read about our project are not that big, compared to the kudos we received.

Julien Danjou: Taking the other direction

I've started to develop awesome more than 18 months ago, and somehow I feel it's time to stop a bit and think where we come from and where we are going to. The motivation I never though I'd be written a window manager one day. That seems kinda stupid when you see how many window manager there's around. As many people, I've tested and have been using tons of window manager: Window Maker, Fluxbox, etc. In August 2007, I was using fvwm since 2004 and was quite happy with it. I used the famous fvwm crystal as a configuration starter and then rewrote lots of stuff. Digging into fvwm configuration files was boring, and since I'm lazy, I never really configured it to fit entirely my needs. The thing is that, in July 2007, my workstation died. I bought a new one based on the amd64 architecture. Too bad, with this new box, fvwm decided that it will not longer runs and was segfaulting almost every time I logged in. I was really upset. Another failure in the window manager world. So I decided to get the yearly ride of testing many window managers. I went on the no more developed stuff like the *boxes, ion3, etc but well, I did not like them, there were not powerful enough, too bugged or upstream was insane. Then I found xmonad. The Haskell configuration file format made my cry. I did not want to learn Haskell, it seemed too obfuscated to me. At that time it was even not packaged for Debian, so I gave up. But I found dwm in the meantime, and I loved it. It was simple, and the source code was almost understandable and easy to hack. I subscribed to the dwm mailing-list, in order to participate to its development, etc But I got really disappointed. No patch were welcome and the development seemed to be almost finish in this sight. People patches were lying around, but no one really care. Each user was managing its own set of patches. That's not what I learnt and what I love in free software. So, as many users, I began to maintain my patches in my corner. But I began to have more ideas The jdwm I just added a 'j' in front of dwm and started to hack it days and nights to add many feature I missed, like multi-head, etc On 5th September 2007, I created a git repository to host my code. That's gonna be awesome. Five days later, on 10th September, I finally found a name for my new pet: awesome, borrowed from Barney Stinson who heavily uses and abuses this word. The 1.x branch The first releases until December were noted 1.x. It was just a better dwm with a simple flat configuration file.. The configuration file used libconfig, but it was a very poor choice. And I was not able to put in into Debian because of name clash. The 2.x branch The 2.x branch came in January 2008 with a brand new configuration file format based on libconfuse, which was a bit more powerful. Many concepts and features that have been added in this branch are still used in the current 3.x branch. At this time, between December 2007 and April 2008, the community was growing smoothly. But as I said, awesome 2 was based on a flat configuration file. That raised a problem very soon: users expectation were growing and the development team (me and a couple of regular contributors) was unable to cope with them. One of the event that started to change my mind was the support for titlebars. When I've added titlebar support, it was minimal. It was on top of a window, with the window title. Dot. Then I've started to add a lot of options, like the application icon drawing, the position (left, right, bottom) etc. And then users started to ask for more, like: "add titlebar on windows only when the window is floating". That's ok, but that's complicated: that's again another option to do some stuff conditionally. And then, why don't add titlebar on windows when <insert random events here>? The 3.x branch Why At that time, around April 2008, I'd totally stopped development. I was trying to find a solution which was simple and powerful. But after 2 weeks of thinking, I was not able to find anything else than: use a real language for configuration. So, I've started prototyping awesome 3 using Lua. The choice was not obvious, and despite the problem Lua might suffer, it's one of the easiest language to integrate into an existing application. There's still a video of a first version here. But, let's go a little back: in January 2008, Arnaud Fontaine contacted me because he was interested to use awesome as one of its school project. He decided to port awesome from Xlib to XCB, a modern asynchronous X library. His work took some time, but in May 2008, Arnaud did finished to port git master version of awesome to use XCB. Consequently, I decided to start a new major branch, using XCB instead of Xlib (no change for users in this regard) and Lua instead of our previous flat configuration file format. Development It took me a while to get from here to there, but in September 2008, it was ready. We had a simple Lua API, and the XCB port was working perfectly. It took us some time to release and have something totally working, because we had to work on XCB and contribute back to the project. It was really not ready to use by an application, but we did great work in this area and it's now really fine. We're still here Releases continue to happens, 3.1 around December 2008, and 3.2 around March 2009. 3.3 should be here in June. One of the drawback we had, is that we moved many stuff from C to Lua. Why? Because writing things in Lua is quicker and easier to maintain than C, and makes thing more configurable for the user. For example, the layout algorithm used to organize window were written in C until 3.2 came out. At that time, users had no choice than using a set of predefined layout to organize their windows. Starting with 3.2, if they have minimal knowledge about geometry, they can start writing a layout function organising windows on the screen. But this kind of API changes was a bit rough for users, since they had to port some part of their configuration file to the new API. The thing is that the project was still a teenager at that time, not really knowing were it will go. But I'm happy to announce that API breakage are more and more rare (so far only one minor between 3.2 and 3.3), and anyway always for the Good. But I admit that it built a bad reputation around awesome 3.x during its first month of existence. Future direction I am currently working on 3.3 development. We have still many things to do. Time passing, we get more idea, and more users. And more users bring more ideas. We also have many more contributors, and some guys are even taking maintainer-ship of some code area. Conclusion My post title is "Taking the other direction" because I feel this way. I've got that feeling that some approaches in projects like GNOME are sometimes bad. Please don't misread me, I know we are not playing in the same yard. When adding a key shortcut for starting an application makes you dig into gconf, I wonder how this is a win for the user. Well, it's probably a win for the end-user, but I surely am not one of them. And I don't intend to target them with my software, anyway. And now, when I hear things like GNOME 3.0 and the "desktop shell" approach, that makes me smile. Guys, it was time, but have luck. What I see from here, is that any desktop control interface is wrong somehow, and that there's no approach that can fulfill all users wishes. I think that we, the awesome development team (no pun intended) took the direction of building a frame-work window manager rather than a solution written in marble. We (partially) solved the issue of UI ergonomic by not writing one and allowing the user to write his own. I don't say that's easy to do for most of users, but it's doable. And I think it's worth it: I use window managers since I use Linux, around 1998. If something like awesome came 5 years ago, I'd be using it so far, because you can write Fluxbox or WindowMaker using awesome in a hundred of Lua code. And you can write your own version of it. And it starts in less than 3 seconds, supporting almost all standard desktop specification (ICCCM, EWMH, XDG, system tray, message notification, D-Bus, etc), whereas many of the window mangers do not. You can even write and play space invaders. Finally, I'm happy about the the road we took so far, and hope we will continue into that direction. The rants I read about our project are not that big, compared to the kudos we received.

Chris Lamb: Targeted optimisation with django-dumpslow

django-dumpslow is a reusable Django application that logs requests that take a long time to execute and provides an tool to summarise the resulting data. Modelled on mysqldumpslow, django-dumpslow is intended as a tool to determine which parts of a project might benefit most from optimisation and to provide valuable empirical data. The tool groups requests that are similar by exploiting Django's ability to reverse URLs - requests that use the same view are not counted distinctly. Views can then be grouped by the total accumulated time spent by that view or simply by their raw frequency in the logs. An example output is:

$ ./manage.py dumpslow
View                                         Accumulated time
=============================================================
example.views.slow                                     92.88
/unknown (unreversible url)                            16.84

If the log entries contain timestamps then django-dumpslow can optionally limit queries by a user-defined interval. This can be useful for generating regular reports of slow pages, perhaps by regularly emailing the "top 10 worst pages" to a development mailing list. Source, tarballs, etc. Patches welcome.

Axel Beckert: Useless Statistics, the 2nd

Myon recently posted a nice statistic about popular single letter package name prefixes. Just out of curiosity I started wondering about popular single letter package name suffixes: On a machine with Debian oldstable, stable, testing, unstable and experimental in its sources.list, I ran the following command:

$ apt-cache search -n .   \
    awk ' print $1 '   \
    sed -e 's/.$//'   \
    sort   \
    uniq -c   \
    sort -n

And to my surprise there is a non-obvious winner:

$ apt-cache search -n '^gp.$'
gpa - GNU Privacy Assistant
gpc - The GNU Pascal compiler
gpe - The G Palmtop Environment (GPE) metapackage
gpm - General Purpose Mouse interface
gpp - a general-purpose preprocessor with customizable syntax
gpr - GUI for lpr: print files and configure printer-specific options
gps - Graphical Process Statistics using GTK+
gpt - G-Portugol is a portuguese structured programming language
gpw - Trigraph Password Generator

But since I searched through the binary packages many other hits are more obvious, like the seven packages hbf-cns40-1 to hbf-cns40-7:

      [...]
      4 ar
      4 aspell-f
      4 automake1.
      4 cpp-4.
      4 e
      4 g++-4.
      4 gappletviewer-4.
      4 gcc-4.
      4 gcj-4.
      4 gcompris-sound-e
      4 gfortran-4.
      4 gij-4.
      4 go
      4 gobjc-4.
      4 gobjc++-4.
      4 h
      4 iceweasel-l10n-e
      4 iceweasel-l10n-k
      4 kde-i18n-f
      4 kde-i18n-h
      4 kde-l10n-e
      4 kde-l10n-s
      4 kile-i18n-e
      4 koffice-i18n-e
      4 koffice-i18n-s
      4 koffice-l10n-e
      4 koffice-l10n-f
      4 libqbanking
      4 myspell-f
      4 myspell-h
      4 openoffice.org-help-e
      4 openoffice.org-l10n-b
      4 openoffice.org-l10n-h
      4 openoffice.org-l10n-k
      4 sd
      4 tcl8.
      4 tk8.
      5 aspell-e
      5 aspell-h
      5 iceweasel-l10n-s
      5 kde-i18n-b
      5 kde-i18n-e
      5 kde-i18n-t
      5 kde-l10n-k
      5 openoffice.org-l10n-e
      5 openoffice.org-l10n-t
      5 pa
      5 tc
      6 gc
      6 kde-i18n-s
      6 libdb4.
      6 m
      6 openoffice.org-l10n-n
      6 openoffice.org-l10n-s
      6 s
      7 hbf-cns40-
      9 gp

But there are also some other interesting observations to make:

OpenOffice.org seems to have by far the biggest number of localisations, with KDE being 2nd.
There are 6 version of the Berkeley DB in Debian: libdb4.2 to libdb4.7 (including oldstable as mentioned above)

I leave it as an exercise to the reader to find the full names of the other package names starting with s, m, gc, pa or tc and having just one additional character. ;-)

Stefano Zacchiroli: xmonad + gnome on Debian

... finally I'm tiling too! Short story: I've just switched to xmonad as my window manager of choice within a Gnome desktop environment; I give some tips on how to achieve that quickly on a current Debian/unstable machine. /me and tiling window managers I switched to Gnome a long time ago. The benefit of that over good old window managers is enjoying an integrated environment and a workplace that you can find on other machines (e.g., the netbook you installed for your mother, the office desktop, the student lab machines, ...). Still, I've never been particularly happy about Gnome's default window manager: metacity. The feature I was missing the most is the ability to configure windows programmatically so that they appear where and how I want by default; sadly enough, the Gnome session mechanism is not yet able to do that properly. Hence, I've tried various time switching to a tiling window manager, imposing the extra requirement that it should integrate with Gnome. The coolest guy on the block of that area seems to be awesome and I gave it a try some months ago. I liked most of its (sometime revolutionary) principles, like window tagging, but I equally hated various aspects of it:

Documentation back then was horrible, starting from the manpage speaking of mod 1,2,3,4,5 without giving a hint about where the heck they are mapped to by default, ranging to the lack of references manual about what you can call from LUA configuration files. ... use the source, Luke ...
Community was mainly composed by super-users, which is good if you want to do some super-configuration. ... but is deeply bad if you are trying to get hints on how to make awesome cope with Gnome. I remember having been treated as a total luser on IRC, with people more interested in convincing me that I should stop using Gnome than in helping out achieving what I wanted to.

People nowadays tell me that awesome works fine with Gnome, so maybe I've just been unlucky back then, but sometime the first impression does count. I've never considered seriously xmonad, thinking (with no sound reason, apparently) that it was a project of the series: "I'm a fan of programming language $LANG, all my apps should be written in $LANG, my window manager is no exception", with LANG=haskell. Then two things happened:

a couple of weeks ago I stumbled upon the xmonad wiki and documentation, and I was impressed by the average quality of the information shipped there. It is not something you usually find in "language showcase" projects.
Patrick blogged about its switch to xmonad + Gnome, with enthusiastic feedback. If that's not a sign I don't know what it can be

Getting started with xmonad + Gnome on Debian There is a page explaining how to use xmonad with Gnome in the xmonad wiki, but a handful of additional tips will help you get started in Debian, even if you know (almost) nothing about Haskell (yet).

You should install packages xmonad and libghc6-xmonad-dev. Without the latter you will not be able to configure your xmonad; in particular you will not have access to the Gnome configuration library, which offers sane defaults for using xmonad with Gnome. (See below for a rant on the disk usage of installing the second package ...)

The (crazy) way in which xmonad works is that you create your config file as ~/.xmonad/xmonad.hs. That file is a full fledged Haskell program, which gets compiled to obtain your own xmonad executable which you run as your own window manager. /usr/bin/xmonad is the executable you initially run, but is just a wrapper around the compilation + run mechanism

Since you have installed libghc6-xmonad-dev, you have access to a module pre-configuring xmonad for Gnome, just use the following as your starting xmonad.hs:
```
import XMonad
import XMonad.Config.Gnome
main = xmonad $ gnomeConfig  
         modMask = mod4Mask
        
```

The modMask setting means that ALT will get delivered to applications, while all xmonad commands are delivered via the infamous windows key: no more conflicts between apps and WM \o/.

At this point you can configure xmonad as your Gnome window manager. Disable re-spawning of metacity in your session option, and run somewhere killall metacity ; xmonad & . For the next session runs you will have to remember the running xmonad in your Gnome session, as usual.

The default Gnome configuration is quite nice: you can retain your Nautilus desktop (in spite of what is written on the wiki), mod-p will get you a gnome-run dialog box, and appropriate padding for the (upper!) Gnome panel. The only glitch is that you will get 9 desktops which can clutter your workspace switched. My solution is to have the appler show workspaces on 2 rows but beware of bug 524065, which is really annoying.

Compositing works as well, by the means of xcompmgr. Just install it and register in your session the result of running xcompmgr -c &. No wonder that it is way faster than compositing manager support in metacity.

Finally, you can configure window placement in your xmonad.hs by doing something like the following (it already includes the shorter snippet given before):

import XMonad
import XMonad.Config.Gnome
myManageHook = composeAll [
                (className =? "Pidgin" <&&> title =? "Buddy List") --> doFloat
               , (className =? "Gnome-panel" <&&> title =? "Run Application") --> doFloat
               -- , (className =? "XEyes") --> doShift "7"
               ]
main = xmonad $ gnomeConfig  
         modMask = mod4Mask
       , manageHook = myManageHook <+> manageHook gnomeConfig

The above example will make the pidgin buddy list and run application dialog box float by default. The commented line is an example of how to deliver specific windows to arbitrary workspaces. To find out window properties on which match in your xmonad.hs, my magic command is xprop egrep "CLASS NAME". Note that you don't need to care about panel placement because it is already taken care of by the default gnome config. Still beware of not using myManageHook as your only management hook, you should update the default one using the <+> monad as I did above. xmonad rant So, what's wrong with xmonad + Gnome in Debian? Well, the fact that it will take about 200 Mb of disk space on amd64 by default. o_O Why so? Because xmonad is affected by the static linking hell which seems to be shared by modern statically typed functional languages, including in the category both Haskell and my beloved OCaml. In short, applications written for those language link statically code written in the implementation language in most cases; they rely on legacy shared libraries only for bindings to C libraries. For xmonad that means that if you are fine with the default configuration you will get a cheap 2 Mb binary package. If you are not, you will need to write your conffile ... which is a Haskell program ... using several contrib libraries ... and needing ghc6 to be compiled and run as your own window manager executable. This is plainly dumb and induces all the usual problems of static linking, like disk consumption due to non-shared (Haskell) code, and worries about staying up to date with the latest library release in case of fixes (including security fixes) need to be propagated to user executables. Truth to be said, /usr/bin/xmonad does a wonderful job in hiding all this to the final user, but still the design choice is an unpleasant one.

14 April 2009

Neil Williams: Experimenting with TDebs

This is a short summary of how I'm currently experimenting with dpkg to generate, check and install TDebs in a pbuilder chroot. Do NOT use my modified version of dpkg outside a chroot!. Also, I don't expect any of this to be useful or usable by anyone not running Debian sid. If you're reading this via an aggregator other than planet.debian.org, please don't try this on your own systems. (Comments complaining that it breaks Ubuntu will be deleted - I'll have good fun laughing at you but the comments will still be deleted.)

The code (such as it is) lives at git.debian.org and it's safe to build the package on the normal system, as long as you install it in the chroot. I actually use a --prefix to allow

sudo make install

to copy the executables into the right places in the chroot. I find that quite simple to do via the terminal plugin in Anjuta.

Building a TDeb for the first time:
I expect lots of comments here, this probably won't be entirely workable initially, but the idea is to get the source for a package that has translations, that is easy and quick to build, few build dependencies and one with which you are already familiar. Adapt that package to support a TDeb by adding the relevant Package: to debian/control. All you need to include is: XC-Package-Type: tdeb and ensure that the new package is Architecture: all. Current convention is to call it $sourcepkg-tdeb. (Yes, although TDebs are initially going to be for debconf support in Squeeze+1, initial experimentation is with program translations because it's easier.)

/usr/share/emdebian-tools/dh_gentdeb (from the emdebian-tdeb package in Debian) can help prepare the translation files by creating the debian/$sourcepkg-tdeb/ directory hierarchy but you could also do the same by installing all /usr/share/locale/ content in the tdeb package in debian/rules or debian/foo.install. Remember to remove the translation files from any other package.

Building the TDeb should be as simple as:

dpkg-deb --tdeb -b debian/pilot-qof-tdeb ../pilot-qof-tdeb_0.1.7-1_all.tdeb

You do not need to build the source itself but you may want to do that for other reasons. You can then view the contents using:

dpkg-deb -c ../pilot-qof-locale_0.1.7-1_all.tdeb

or

ar -t ../pilot-qof-locale_0.1.7-1_all.tdeb

Install (dpkg -i ../pilot-qof-locale_0.1.7-1_all.tdeb --lang vi) used to work but I've messed up something there, so any ideas on what I've done wrong would be appreciated.

Subverting git with subversion

Yes, I'm a git phobe. Don't flame me and any comments about my git foo by the git fanboy contingent will also be deleted.

I have to use git for this because the dpkg maintainers like git. That doesn't mean I have to like it or even use it. So, I use a local SVN repository. I do all my development work against that (because it's more friendly) and make local commits to it. Then, when I'm reasonably happy with the results, I copy the files across into git, fake a git commit message that more or less covers the real changes and use a script to "push" git to do what I intended. If (more likely, when) git decides to be all unfriendly and throw a completely unintelligible error message, I simply rm -rf git/path/, check out a fresh git, copy the real stuff from SVN and send the lot back as a single commit to git. Hah!

(For those who are not so blinded by their git obsession that they may actually care about my process, I can only say that local SVN is blisteringly fast and never, ever, fails.)

Biella Coleman: Paris in June (and better with hackers)

========================================================================
/tmp/lab announces the second Hacker Space Festival
(Paris, 26-30 June 2009)
======================================================================== Hacker Space Festival 2009 Call For Proposals HSF2009 In 2008, we organized HSF[1] on the spot, as an ad-hoc meeting for
hackerspaces-related networks, technical and artistic research emerging
from them and social questionning arising from them. This sudden
experiment proved to be a huge success, as much as on the
self-organizing level as on the participants and meetings quality, as
well as the emotionally-charged ambient, the kind of which you make
fond memories. The 2008 edition generated a strong emulation in France, from its
historical role as the first official hack meeting there, and in Europe
with the subsequent creation of the Hacker Space Brussels[2], the
rapprochement with The Fiber in Amsterdam and the hackerspaces.org[3]
network. Initiatives of hackerspace openings in Grenoble or Lille, or
the upcoming FrHack[4] conference show an actual enthusiasm in the
French hackers community that was doomed to the underground not so
long ago. We salute these initiatives and their diversity! Soon enough, we wanted to reiterate the HSF experience : however, it
was out of the question to institutionalize this temporary autonomous
zone, nor make it an ersatz of the previous edition, nor even to wrap
it into an elite or underground aura. On the opposite, we ardently
desire; and especially to explore further, in all directions some
lesser known domains (see below) et foster meeting and sharing around
experiences at the confluence of art, technology and politics. The world financial crisis, the decay of democracy in Europe, the
obscurantism, paranoia and lack of culture presiding over legislation
(Internet and Reaction Err Creation Law[5][6]) seem a fertile
environment for the sensible development of new (social ) life forms.
Quick! Let s rest for a few days in jubilation and ecstasy to take a
deep breathe of freedom under the indelicate smells of the medicine
factory nearby! For if the public space is shrinking to oblivion, where any side-step
becomes suspect, and that, from an early age (deviant behavior
detection in nursery school), where moving without a mobile phone
becomes suspect (hello you Julien Coupat[7], a French political
prisoner in France!), there s a domain that the Leviathan would have a
lot of trouble to contain, and for a reason: that of sensitivity. Even
the desperate attempts of the State to block the free and premonitory
expression of sense (hello you Demeure du Chaos![8]) cannot do anything
against a loud laughter or a knowing glance, a sensual kiss or an
explosion of colors. Sensitivity, we could say, is what is left to a human being when she
has nothing anymore, and differenciates her from the body corporate or
the institution, that are, in essence, devoid of it. Therefore, Art
definitely remains the public space to share between humans, and only
between us. And if it the last one to share, we propose to explore it
and take it over during the upcoming edition of the Hacker Space
Festival, from the 26th to 30th of June, 2009 at Vitry sur Seine[9]. ========================================================================
Keynote Speakers: Sergey Grim and Larry Fake with Eric Schmoudt
Groogle Summer of Crode, Survivor style
VLC, I vote against you because you really fucked up when ========================================================================
== W A N T E D ========================================================= Focus on solutions rather than problems. * The Final (Hardware) Frontier: Open FPGA Cores, Reverse Engineering
* Designer Religions and Creative Beliefs Systems
* WiFiDoors & WiFi System-on-Chip controllers firmware hacking,
infection & backdooring
* Telecom Core Network Equipment Reverse Engineering: MSC, STP,
Switches,
* Algebraic Attacks and Modern Cryptography Attacks
* Autonomous, Parasitic and Viral Drones
* Enhanced or Infected Reality Swarms
* Auto-Builders / Self-Fabrication
* Embedded OS breakins stories & recipes
* Actualization rather than mere concepts
* FPGA & ASIC hacking / backdooring
* Cloud+Privacy+Open Source: O Brave New World?
* Explosion-Proof clothing
* Radio Appz & Hackz: Mesh @ RF Layer 1-3
* Database & Privacy
* Problematic & Ethical Open Source/Content Licenses
* Institutional Relationships: Lobbying or Licking?
* Non Lethal Protection (anti-taser vests?)
* Survival in the Age of the Ministry of Immigration and National
Identity
* Mental asylum improvised visit
* Open Source Legacy Media(TM) Production Solutions (TV, Radio, Press,
DRM)
* Gas Sensors & Environmental Benchmarking
* Building Hackerspaces Without Money
* Milsatcomm hacking: Military satellites shots, broken birds in the
sky
* Other research topics on security and insecurity
* Academics and Hackers
* Organics and Fermentation
* Clean Food in Tainted Environment
* Low Impact Energy & Recycling
* Media Sandwich: layers of crap makes good food?
* Deconstructing Carla Sarkozy
* Knitting DIY Factory (jazzy, eh?)
* Signs of life among industrial wasteland
* Hallucinogenic & Computing: Can you Code on Acid?
* Mesh Networking (Wireless BattleMesh Royal!)
* Legal Sabotage: When Democracy Needs You And anything that does not fit. ========================================================================
== P R O P O S E ======================================================= Send you contributions to HSF2009-CFP@lists.tmplab.org + Type of the proposal: 1. conference (45min. presentation + 10min. for questions)
2. workshop / demo (30min. 2 heures)
3. installation / performance (music, plastic, sound, video) Lightning talks can be proposed and organized until the last moment,
according to available space and schedule, in the form of BarCamps or
Blitz Conferences. + Required Information: * Title of the presentation
* Type (see above)
* Language : French or English
* Name of speaker(s)
* Affiliation (organization / company)
* Short biography
* Abstract (5 to 10 lines)
* Topics / Keywords
* Includes a demo? YES NO
* Release during the festival? YES NO
* Internet connection required? YES NO + Acceptable Formats * Open Document
* PDF
* Plain Text
* RTF + Agenda * beginning of proposals : now
* end of proposals : 01 May 2009
* selection notification : 07 May 2009
* publication of program : 15 May 2009 + Evaluation criteria for proposals: 1. Innovating Topic
2. Open Technology
3. Demonstration / Live Act
4. DIY Reproducibility
5. Fun Potential The Programming Committee resembles that of last year
See : http://hackerspace.net/committee ========================================================================
== V E N U E =========================================================== /tmp/lab
6 Bis rue Leon Geffroy
94400 Vitry sur Seine
France http://hackerspace.net/directions ========================================================================
== P A R T I C I P A T E =============================================== Email : http://lists.tmplab.org/listinfo.cgi/hsf2009-talk-tmplab.org
CFPmail: HSF2009-CFP@lists.tmplab.org
IRC : irc://irc.freenode.net/frlab
Jabber : xmpp:hsf2009@space.cepheide.org?join
Wiki : http://hackerspace.net/hsf2009 ========================================================================
== L I N K S =========================================================== The CFP is available online at http://hackerspace.net/cfp [1] http://hackerspace.net/hsf2008
[2] http://hsb.wikidot.com/
[3] http://hackerspaces.org/
[4] http://www.frhack.org/
[5] http://jaimelesautistes.fr/
[6] http://laquadrature.net/
[7] http://fr.wikipedia.org/wiki/Julien_Coupat
[8] http://www.demeureduchaos.org/
[9] http://hackerspace.net/
Philippe Langlois
Email: philippelanglois@free.fr
PGP Key: 8DAEE244

12 April 2009

John Goerzen: Flowers, Music, and Grandparents

Flowers I ve written a lot lately about my Grandma Klassen, who passed away this week. But I m going to start this post about my Grandma Goerzen. She died when I was just an infant. I never knew her, but as the years pass, it seems that I remember her better and better. After we moved out to the farm where she and Grandpa Goerzen lived for decades, we noticed some flowers she had planted 30 years ago were still coming up, having withstood hail, hot summers, frost, construction equipment, and neglect all that time. Terah said, It s like your grandma left us a housewarming gift. Some of these flowers had never bloomed. Until this week. One bloomed for the first time the day Grandma Klassen died. A second bloom appeared the day of her funeral. Music #1 My jr. high and high school band teacher loves music (and old engines, but that s another story). You couldn t sign up for band at my high school; you d sign up for the class called LIFE. To him, music and life are indistinguishable. He says that anybody can speak to somebody, but music is the best way to speak to the heart. My Grandpa Klassen died when I was 11. Grandma Klassen, before her health declined, loved to tell me the story of the music at his funeral. At his funeral, my mom and I played a piano duet of Nearer, My God to Thee which we had already learned for a different event. When we were done, Rev. Epp went to the pulpit and said something along the lines of, If the music in heaven is as good as that, it ll be a great place indeed. I was just 11, and though music did speak to me at that age already, I don t think I understood how it moved people, such as my grandma, until many years later. Music #2 Grandma Klassen loved music, too, and that s reflected in each of her children all of them play trumpet, for instance. So it s no surprise that there was a lot of music this week. She died as two of her children were singing hymns to her at her room in the nursing home. Two of her grandchildren played trumpet for her at her burial. And my brother and his wife played trumpet and piano at her funeral. It was all beautiful, and like my band teacher said, it spoke to my heart. Music #3 I knew about gradma s love of music for quite awhile. When she was in better health, I took her to concerts sometimes. One of her favorite hymns was Joyful, Joyful, but she hadn t known it was based on Beethoven s 9th Symphony. I learned that the Wichita Symphony Orchestra was performing the 9th, and took her to the performance. She loved it, and I seem to recall that she kept talking about it for a few years afterwards. It certainly didn t hurt that the singing on the 4th movement was in German. I burned her a new-fangled CD of it, which I frequently saw in or near her CD player. The Kansas Mennonite Men s Chorus is an all-volunteer choir with about 300 members. They give a couple of concerts a year, and occasionally tour throughout North America and Europe. Their motto is we sing that others may live because 100% of money collected at their concerts goes directly to charity. Attending one of their concerts is a powerful experience not easily forgotten. I think the only time I ve heard a choir come close to being as amazing as that was when I had the opportunity to attend a Robert Shaw concert a few years ago. I went with grandma to one of the Kansas Mennonite Men s Chorus performances a few years ago. As you might expect, she loved it I think she called it powerfully good. This year, I finally joined the choir. I still remember that first practice. We warmed up by singing Holy God, We Praise Thy Name a song that has opened every KMMC concert for years. These people hadn t sung together for almost a year, and there were plenty of new people like me there too. But it only took a few bars of singing before I realized just what it was I had joined. The choir started out with the quietest, but most powerful singing you can imagine: Holy God, we praise thy name. By the time we got to the end of the page, the building was ringing from 300 men singing Infinite thy vast domain, everlasting is thy reign! at the top of their voices, in perfect harmony. We got to the end. The director said. . . Wow. I don t think a first practice ever spoke to my heart before that day. Music #4 Nearly 20 years ago, Grandma Klassen bought me a new bible. After she gave it to me, I asked her what some of her favorite passages were. She took me straight to the blessing in Numbers 6, and made sure I underlined it and bookmarked it. It goes like this:

The Lord bless you,
The Lord keep you,
Make his face to shine upon you and be gracious unto you,
The Lord life up his countenance upon you and give you peace.

My uncle had read this blessing to her the last time he talked to her. And the KMMC for years has ended their concerts with a beautiful benediction based on this passage. Grandma heard it at the concert I attended with her. It has been a favorite of my mom for years, too. So I had the thought: we really ought to sing it as a benediction at her funeral. It was hard to find the right mix of people on short notice, but we wound up with me singing baritone, my brother singing 2nd tenor (we both normally sing bass), and his wife both playing piano and singing 1st tenor, and relying on the piano to fill in the bass part. We had a little chance to practice before the funeral, but not a lot. The two of them have done a lot musically, but I haven t nearly as much, so I got in some extra practice at home, too. When it came time to sing, it was an emotional moment for sure more than a bit hard to focus, knowing the history and meaning of these words. When we got to and give you peace , and moved into the chorus of amen that finishes the song, I almost broke down right there, but didn t quite. We didn t give a perfect performance, for sure, on such short notice. (And they had me singing with them, so we wouldn t have been perfect even with plenty of notice!) But it didn t have to be perfect. After we ended the last, quiet amen , I think I heard about a half-dozen noses blowing all at once. My band teacher was right about music speaking to the heart. Later, during lunch, my aunt said to me, Wow, John, I ve never heard you sing before! That s right, and this may be the last time you hear me sing, too! I don t normally sing in a small group like this. A few minutes later, my uncle that gave the message came over and talked to the three of us. John, today you three brainwashed me. Oh? Yes. For years, I thought that there was no music as beautiful as the trumpet. After hearing you three sing, I have to reconsider. And so my band teacher was also right: music is life. My grandma was a person that could hardly speak without touching the heart. That beautiful melody of her life didn t stop when she died Tuesday afternoon. I ve been hearing it all week.

John Goerzen: Goodbyes

Yesterday was my grandma Klassen s funeral at Alexanderwohl Mennonite Church, where she had been a member for decades. My uncle, a pastor, gave the meditation. He had been a missionary in Vietnam during the war, and he remained there after the United States withdrawal. During that time, things were very dangerous for him, and all means of communicating with the family back home were completely cut off. My grandparents had no way of knowing if he was OK. He later heard of a conversation my grandma had with a neighbor one day during this time: Neighbor: You must be so worried about your son in Vietnam! Grandma: Not really. I gave him back to the Lord the day he graduated high school. Neighbor: If you re not worried, then I m REALLY worried! Grandma: Why worry? Heaven is just as close to Vietnam as it is to Kansas. That exchange sums her up pretty well, I think. She was so deeply religious that it gave her a great sense of peace about life. We heard so many stories about her this week. We heard how, when she was already in her upper 80s, she helped a farmer get his equipment out of the mud and ran some heavy farm machinery. She was in charge of my cousin s schoolwork for a little while (she lived with them back then, and his parents were taking a trip). She apparently made sure he did every little assignment left for him in exacting detail, even the ones that his mother had said were extra , just in case he needed something else to do. Apparently when his parents got back, he said he loved his time with grandma, but begged them to never put her in charge of his schoolwork again! I told the story of learning to play chess when I was a child. My grandpa was teaching me the game. I was having some trouble learning some of the rules, and was frustrated because he was also beating me (like usual). After a little while of me getting more and more frustrated, grandma said something to him in German and all of a sudden I started winning. Yesterday evening was the community Good Friday church, with the combined choirs of our church and Alexanderwohl singing. That wasn t the easiest thing to do after the funeral in the morning, but I m glad I did. Tomorrow I ll be singing again for Easter.

Andrew Pollock: [debian] Grappling with Git, episode 1

At work, we have a bit of a vested interest in the Puppet and Facter packages that are in Debian, because we ultimately consume them in Ubuntu. We noticed that what was in Debian unstable was lagging a bit behind what was released upstream, and when one of my co-workers tried getting in contact with the Debian developers that were maintaining the Puppet package and got no response, I got involved. I got in touch with Micah Anderson and got myself and Nigel Kersten added to the Alioth project for Puppet. Despite Jamie Wilkinson being listed as the maintainer of the facter package in Debian, he claimed this was news to him, and Matt Palmer, who was listed as an uploader, didn't really claim much knowledge of maintaining the package either, so we took that as blessing to take over that package as well. This is where the fun begins. I've been meaning to try out Git ever since Debconf 7, where all the cool kids were using it and raving about it. I've been meaning to make the Debian DHCP package collaboratively-maintained, and use Git for the revision control, but I haven't quite gotten off my good intentions and done it yet. Part of the problem is not knowing exactly what workflow I should use, and suffering from paralysis by analysis, reluctant to experiment, because I don't want to go down the wrong path. Anyway, this is about Puppet, not DHCP. The Puppet package, as it turns out, is already maintained in Git on Alioth, so the problem here was more one of figuring out what the current workflow was, and trying to follow it. This is where Nigel came in. Conveniently, the upstream Puppet development is done in Git also, and Nigel is a contributor to Puppet upstream, so he had some Git-fu. So between the instructions on how to get started with Git on Alioth and what he knew, we could start fumbling around. It seems like the Alioth Git repository was also tracking the upstream Puppet repository, as there were commits in the Alioth one by Luke Kanies, and we didn't really imagine that he was doing Debian-specific stuff. Here's what we ended up doing to try and get what was in the Alioth repository up to the upstream version 0.24.8 of Puppet:

git clone ssh://apollock@git.debian.org/git/pkg-puppet/puppet.git

This part was fairly straight forward. Clone what's in Alioth locally.

git remote add reductive git://reductivelabs.com/puppet
git remote update
git fetch --tags reductive

Next, we added a remote branch that tracked upstream. We called it "reductive", and we updated it. The bit that took some fiddling with was fetching the tags. Nigel later figured out that tags are inherently private to a repository, and normally stay that way. So if I have a local clone of say the upstream Puppet repository, I can tag it to my heart's content, and normally those tags would stay in my local repository, because they're probably only meaningful to me.

git checkout -b upstream/0.24.8 0.24.8

This bit took a bit of work to arrive at as well. What we wanted to do was create a new branch called upstream/0.24.8, which was at what was tagged 0.24.8 in the reductive repository. Nigel pondered what would happen if you already had a tag or a branch called "0.24.8" before you added the remote repository. This is also why we had to fetch the tags from the remote repository, so we had something to check out.

git checkout master
git merge upstream/0.24.8

Next, we switched back to the master branch and merged the contents of our local upstream/0.24.8 branch that we just created. This now got the Puppet source in the master branch up to what was released as version 0.24.8. (and this is better than just running uupdate?) We did some fiddling with the debian/control file and debian/changelog and fixed up a few things that Lintian was bitching about, and were done. I'd set up a sid chroot with cowdancer previously, and had to do some faffing around with git-buildpackage to convince it to use pbuilder. I ended up using

git-buildpackage --git-builder="pdebuild --debbuildopts '-i\.git -I.git' --basepath /var/cache/pbuilder/base-unstable.cow"

So now we've got most of what we want to ship checked into Git on Alioth. I have no idea if we've done it "right", I suspect we may have done something wrong by operating on the master branch. Looking at the revision history in the Git repository on Alioth, it looks like previously things have been done a few different ways. I certainly want to write up a definitive workflow once we've figured one out. We haven't uploaded the new package to unstable yet, because we're still trying to give it a modicum of testing, and we'd like to sort out the Facter package as well. The Facter package was a more greenfield exercise, as while there was already a Git repository on Alioth for it, it was empty. So Nigel had to do some futzing around to get it checked in the right way to make git-buildpackage want to build it. He did this by himself, so I'm not sure exactly what he did. I've since discovered that it's probably lacking some dependencies it needs, so that'll need to get fixed before it gets uploaded. I look forward to reading blog posts from the smart people who actually know how to use Git properly, telling me how we should have done it. I'm still very interested in coming up with a proper workflow for preparing packages and committing the changes, and for doing code review.

11 April 2009

Chris Lamb: Installing FogBugz the Debian way

Yeah, proprietary software is bad, but let's at least install it the Debian way. The following walkthrough assumes Debian lenny.

Install some prerequisites:

$ sudo apt-get install mysql-server-5.0 apache2-mpm-prefork libapache2-mod-php5 php5-mysql php5-curl php-pear mono-gmcs php5-imap curl dh-make-php dpkg-dev fakeroot build-essential cdbs php-http-request php-mail php-net-smtp php-db php-auth

Download and extract FogBugz:

$ cp ~/Downloads/fogbugz-setup-php-6.1.44.tar.gz .
$ tar xvfz fogbugz-setup-php-6.1.44.tar.gz
$ cd fogbugz

If you do not wish to install FogBugz to /opt/fogbugz, modify INSTALL_DIR at the top of install.sh to point to your intended target (e.g. /srv/bugs.example.com).
Create Debian packages of the missing PEAR libraries. For some reason, the php-mail-mime package in lenny is not recognised by FogBugz's install.sh, so we create a replacement.

#!/bin/sh
set -e
for PEAR_PKG in Auth_SASL HTTP_Client Mail_Mime XML_Tree
do
        PKG_TEMP=$(mktemp -d)
        cd $ PKG_TEMP 
        pear download $ PEAR_PKG 
        dh-make-pear $ PEAR_PKG *.tgz
        cd $(find -mindepth 1 -type d   head -n1)
        dpkg-buildpackage -uc -us -rfakeroot
        sudo dpkg -i ../*.deb
        rm -rf $ PKG_TEMP 
done

Run ./install.sh. You should see something like:

$ sudo ./install.sh
/***************************************\
*            FogBugz 6 Setup
\***************************************/
--    Checking for required tools
 +      found mono 1.9.1
[..]

FogBugz will offer to mangle your Apache configuration. Choose no and run the following, replacing /srv/bugs.example.com where appropriate:
```
$ sudo ln -s /srv/bugs.example.com/Accessories/fogbugz.conf /etc/apache2/sites-available/fogbugz
$ sudo a2ensite fogbugz
```
FogBugz will then offer to mangle your PHP configuration. Choose yes; but move the last handful of lines from (e.g. /etc/php5/apache2) into /etc/conf.d/fogbugz.ini.
After restarting Apache, you should be able to visit http://bugs.example.com/fogbugz/install1.php to continue installation.
On first run, FogBugz will "warn" about the lack of missing eAccelerator, a PHP JIT. Unfortunately, whilst eAccelerator is "open-source", useful distribution of it is illegal. Alternatives available in lenny would include php-apc and php-xcache.

Andrew McMillan: DAViCal 0.9.6.3 released

After far too long (too many holidays away from my keyboard :-) I've released DAViCal 0.9.6.3 and AWL 0.36. This is mostly a stability release, fixing all those little niggles that might only affect a few corner cases, but it frees me up now to concentrate on adding more functionality for a 0.9.7 release in due course. Hopefully this will be the last in the 0.9.6.x series. More information in the DAViCal release notes on the wiki. There are quite a few changes to the AWL libraries which this release depends on, but most of those changes have been driven by my Work Request Management System and Capital APMS projects, rather than from DAViCal.

10 April 2009

Obey Arthur Liu: Google Summer of Code 2009: Debian s Shortlist

Copy of http://lists.debian.org/debian-devel/2009/04/msg00421.html. Hi folks, We have been pretty busy these past few weeks with the whole Google Summer of Code 2009 student application process.
I can say that we have this year a very good set of proposals and I d like to thank all the students and mentors for this. I am going to present to you our shortlist of projects that we would like to be funded and believe we can reasonably manage to get funded. As always, remember that the number of slots is not final yet at this point so we can t promise anything. The first preliminary slot count given today was *10* (same as last year) and we hope to get *2* more (as we did last year). This shortlist is alphabetically ordered because we don t want to reveal the current internal rankings. I am inviting you to debate what you think is cool, what is useful, what is important to Debian, maybe give us pointers to resources or people that could be helpful for the projects. We will try to alter our current rankings to reflect the zeitgeist in Debian, while taking into account the personal information that we have about each student involved. The deadline for any modification is on the 15th, so get everything in by the 14th. The final selected projects will be announced by Google April 20th, ~12 noon PDT / 19:00 UTC. We ll have another announcement then. Three proposals need or may need a mentor, I indicated it. For more information about the projects or mentoring and how to talk to us directly, scroll down past the list. Debian s Shortlist : - Aptitude Package Management History Tracking
- Automatic Debug Packages Creation and Handling
- Debbugs Web UI: Amancay Strikes Back
- Control Files Parsing/Editing Library/Qt4-Debconf Qt4-Perl bindings
- Debian-Installer Support for GNU/kFreeBSD
- KDE/Qt4 Adept 3.0 Package Manager
- Large Scientific Dataset Package Management
- MIPS N32 ABI Port
- MTD Embedded Onboard flash Partitioning and Installation
- On-demand Cloud Computing with Amazon EC2 and Eucalyptus Integration
- Port back update-manager to Debian and all Derivatives
- Debian Autobuilding Infrastructure Rewrite And the details: Aptitude Package Management History Tracking Student: Cristian Mauricio Porras Duarte, Mentor: Daniel Burrows Aptitude currently does not track actions that the user has performed beyond a single session of the program. One of the most frequent requests from users is to find out when they made a change to a package, or why a package was changed; we want to store this information and expose it in the UI in convenient locations. As a side effect, this might also provide some ability to revert past changes. Automatic Debug Packages Creation and Handling Student: Emilio Pozuelo Monfort, Mentor: Marc Brockschmidt This proposal aims at providing debug binary packages for the packages in the Debian archive in an automatic manner, moving them away from the official Debian archive to an special one. This has the benefits of providing thousands of debug packages without any work needed from the developers, for all the architectures, without bloating
the archive. Debbugs Web UI: Amancay Strikes Back Student: Diego Escalante Urrelo, Mentor: Margarita Manterola The Amancay project aims to be a new read/write web frontend to Debian s BTS; allowing DDs and contributors to easily interact with bugs via an intuitive yet powerful interface, enabling new workflows and creating new contribution opportunities like triaging while upholding reporting quality. Control Files Parsing/Editing Library/Qt4-Debconf Qt4-Perl bindings Student: Jonathan Yu, Mentor: (probably) Dominique Dumont see below This project proposes a common library for parsing and manipulating Debian Control files, including control, copyright and changelog. Main ideas include validating and parsing of these files, with both Strict and Quirks modes for the parser. The second idea is a new frontend for Debconf using Qt4 (for which Perl bindings will be written). Debian-Installer Support for GNU/kFreeBSD Student: Luca Favatella, Mentor: Aurelien Jarno GNU/kFreeBSD is currently using a hacked version of the FreeBSD installer combined with crosshurd as its own installer. While this works more or less correctly for standard installations (read: the exact same installation as in the documentation), it does not allow any changes in the installation process except the hard disk partitioning. This project is about porting debian-installer on GNU/kFreeBSD, and to a bigger extent, make debian-installer less Linux dependant. KDE/Qt4 Adept 3.0 Package Manager Student: Mateusz Marek, Mentor: NEEDS MENTOR, see below. Finish Adept 3.0, a fully integrated package manager for Qt4/KDE4. Adept is currently the only viable path to a Debian native package manager on KDE that would support modern features such as tags, indexed search or good conflict resolving. With Aptitude-gtk still in development and only available for GTK+ and (K)PackageKit having fundamental problems, Debian needs this project to stay in control of its package management on KDE after much neglect in the recent years. Large Scientific Dataset Package Management Student: Roy Flemming Hvaara, Mentor: Charles Plessy Large public datasets, like databases for bioinformatics are typically too big and too volatile to fit the traditional source/binary packaging scheme of Debian. There are some programs that are distributed in Debian, like blast and emboss, that can index specialised databases, but Debian lacks a tool to install or update the datasets they need and keep their indexing in sync. MIPS N32 ABI Port Student: Sha Liu, Mentor: Anthony Fok This project first focuses on creating a new MIPS N32 ABI port for Debian. Different from O32 and N64, N32 is an address model which has most 64-bit capabilities but using 32-bit data structures to save space and process time. A second focus will be given on making such a mipsn32el arch fully optimized for the Loongson 2F CPU which gains more and more popularity in subnotebooks/netbooks in many countries. MTD Embedded Onboard flash Partitioning and Installation Student: Per Andersson, Mentor: Wookey Many embedded devices have MTD onboard flash as persistent storage like the Kurobox Pro NAS, the Neo Freerunner, the Sheeva Plug or the OLPC. With MTD flash being so popular and with increases in capacity, support for MTD partition/installation would make Debian even more interesting to a wide range of of devices, making it one step closer to being universal. On-demand Cloud Computing with Amazon EC2 and Eucalyptus Integration Student: David Wendt Jr, Mentor: (probably) Steffen Moeller see below In many academic fields, as well as commercial industries, people use clusters to distribute tasks among multiple machines. Many times this is done by packaging a whole operating system disk image, uploading it onto the cluster, and having the cluster run it in a VM. This project intends to make it easier for Debian to distribute prepared disk images templates like they distribute CD images now, for the users to recreate or customise these templates with Debian packages and for administrators to host such clusters with Debian. Port back update-manager to Debian and all Derivatives Student: Stephan Peijnik, Mentor: Michael Vogt The project would involve taking the distribution-(Ubuntu-)specific update-manager code, analyzing it, and creating a package with just its core functionality, decoupling the distribution-specific parts and thus making the core code extensible by distribution-specific add-ons. This in turn would remove the need of porting update-manager to Debian with every upstream release. An additional optional goal would be replacing the synaptics-backend with a python-apt based one. Debian Autobuilding Infrastructure Rewrite Student: Philipp Kern, Mentor: Luk Claes Rewrite the software that currently runs the Debian autobuilding infrastructure in a way that makes it more maintainable and robust. It will use Python as its programming language and PostgreSQL for the database backend. By harmonizing buildds, many build failures can be prevented and wasteful workload on buildd volunteers can be reduced. On mentoring:

KDE/Qt4 Adept 3.0 Package Manager:

Petr Rockai, the original developer of Adept has offered help to anyone willing to adopt Adept. Sune Vuorela has offered help for any Qt4 and KDE related issues. *We really need a mentor here*. The student is quite competent but Google dictates that we provide a mentor to handle student management.

Control Files Parsing/Editing Library/Qt4-Debconf Qt4-Perl bindings:

Dominique Dumont, although not DD, has signaled interest in mentoring this, although it hasn t been confirmed yet. Sune Vuorela has offered to help co-mentor for the Qt4-Debconf and Qt4-Perl bindings part.

On-demand Cloud Computing with Amazon EC2 and Eucalyptus Integration:

Steffen Moeller has signaled interest in mentoring this, although it hasn t been formally confirmed yet. Charles Plessy of the Debian Med team will provide help for use cases related issues. Eric Hammond, developer of the original vmbuilder image creation tool and maintainer of a set of Debian and Ubuntu images will provide help for Amazon EC2 and image creation issues. Chris Grzegorczyk from the Eucalyptus team will provide help for Eucalyptus and Eucalyptus/Debian integration issues. Contacting us: Considering the tight schedule, most stuff happens live on IRC: #debian-soc on irc.debian.org You can also consult our wiki page for some additional information:
<http://wiki.debian.org/SummerOfCode2009> We have a mailing-list at:
<http://lists.alioth.debian.org/mailman/listinfo/soc-coordination> Keep this discussion on debian-devel@lists.debian.org while cc-ing soc-coordination@lists.alioth.debian.org. This thread is for debian-devel primarily.

Next.

Previous.