Umh, is today the quote your neighbour day? No? Thought so... Still, for the second time in a couple of minutes, I'm quoting/translating here. This time, I'm quoting a short text posted by fellow Mexican Debian guy Rodrigo Gallardo: Deceptions (hmm... Not in the let you down sense, but in the deceiving sense. Sometimes it is hard to translate a single word without twisting it around). My translation is far from perfect - Read it in Spanish, you will enjoy it more. Rodrigo says:

Things and actions are what they are, and the consequences of them will be what they will be; why then should we desire to be deceived? Joseph Butler

I was in Colima, sitting on a slide in a city park, that day I understood why somebody might want to be drunk. Several years later, this time in Tlalpan, I understood why somebody would want to believe in a god. And sometimes I am truly sorry not to be able to embrace neither of both longings. The idea of letting go the facts, to believe they have an inner order, although covered in mistery, or they are just far away, blurry. But where others see destiny, I see things falling naturally in their place. Where others see beauty in the mistery, I see a challenge. And even more beauty in an elegant explanation, in understanding. Motivation, not in the promise of future welfare but in the certainty of this limited but tangible present welfare. Freedom in the absence of a purpose, and inmortality in the little pebble I am in the great human building. I suppose that if Revernd Butler knew his phrase inspired this divagation, it would not make him precisely happy. But, things are what they are, and his argument says what it says.

At work I've been promoting the use of pkg-config and modules to solve the problems of avoiding hard-coded paths and an environment where we've multiple compilers. In summary, "module load intel-cc" to load the intel compiler, "module load netcdf-intel" to, which among other things appends /ichec/packages/netcdf/4.0-intel/pkgconfig to $PKG_CONFIG_PATH, and then:

NCDF_INCS :=  pkg-config netcdf --cflags 
NCDF_LIBS :=  pkg-config netcdf --libs 

in the application code. Replace "intel-cc" and "netcdf-intel" with "gcc" and "netcdf-gcc", and it builds with gcc. This would work better if upstream supplied .pc files, which means the next stage in world domination is to send patches to do just that. But it's not that easy, apparently. netcdf (for example) supplies two libraries, libnetcdf.so and libnetcff.so, with the second including code only needed for Fortran. So, for gcc I have the following netcdf file:

prefix=/ichec/packages/netcdf/4.0-gcc
exec_prefix=$ prefix 
libdir=$ prefix /lib
includedir=$ prefix /include
Name: netcdf
Description: netCDF libraries, include files and development tools (gcc version)
Version: 4.0
Libs: -L$ libdir  -Wl,--as-needed -lnetcdf   -lnetcdff 
Cflags: -I$ includedir 

While for Intel I have:

prefix=/ichec/packages/netcdf/4.0-intel
# Add fortran libs 
forlibs=/ichec/packages/intel/fce/11.0.081/lib/intel64
exec_prefix=$ prefix 
libdir=$ prefix /lib
includedir=$ prefix /include
Name: netcdf
Description: netCDF libraries, include files and development tools
Version: 4.0
Libs: -L$ libdir  -lnetcdf -L$ forlibs   -lnetcdff -lifcore
Cflags: -I$ includedir 

The main problem is that --as-needed is not understood by non GNU-ld linkers, and must be conditionally removed somehow. Any ideas ? (There is a second wrinkle of needing to add additional libraries for Intel Fortran here, but I'm sure I can remove that with the addition of more .pc files.). A second issue is that --as-needed can break otherwise working pkg-config usages. Thanks to galtgendo at PhP Bugs for this example:

alastair@ailm:~$ cc -o testx  -Wl,--as-needed  pkg-config glib-2.0 --cflags  test.c  pkg-config glib-2.0 --libs 

works, but:

alastair@ailm:~$ cc -o testx  -Wl,--as-needed  pkg-config glib-2.0 --cflags    pkg-config glib-2.0 --libs  test.c
/tmp/ccsUEwtk.o: In function  main':
test.c:(.text+0x20): undefined reference to  g_print'
collect2: ld returned 1 exit status

The problem being that --as-needed removes libraries as unnecessary before the linker sees the test.o code. Tags programming, debian, work, pkg-config, shared-libs, lazyweb

I usually use this blog to post about stuff I have written or that is somehow related to my work / professional life. This time, however, I'll just use it to share with you a short text my father published in the column he writes in the La Uni n de Morelos newspaper, Academia de Ciencias de Morelos: La Ciencia, desde Morelos para el mundo. My father has lived for over 20 years in Cuernavaca, la Ciudad de la Eterna Primavera (the city of the eternal Springtime), ~80Km south of Mexico City. Cuernavaca was for long years known mostly as a weekend city for Mexico City's middle-upper class, but it has grown way beyond that. According to Wikipedia, in Cuernavaca's metropolitan area there are about 700,000 inhabitants. And the city is blatantly built with no planning, no urbanistic analysis of any kind. I have been familiar for many years with the program to put some rational order renumber Cuernavaca's streets. Roberto Tamariz, the sociologist who built my father's house (yes, in a stroke of genius he acted as an architect for a piece of land he had bought - the results are quite decent, given his real occupation, but his lack of architectural background tends to literally come up from the floor every now and then), was involved in a municipal project to renumber Cuernavaca's streets, probably some 15 years ago. Anyway, Roberto's work was never really finished due to the severe lackings of our political culture. In this (one-and-a-third pages long, quite easy to read) text I am attaching to this post, my father writes about Cuernavaca's strange street naming system, the mathematical solutions (and political intrincacies) about renumbering a two dimensional space (and, of course, he could not help but wander into the third- and fourth-dimentional spaces, although very briefly). I like how this guy writes, all in all. Enjoy!

Attachment	Size
Calles y numeros de Cuernavaca.pdf	231.99 KB

While I'm not a fan of cut-n-paste coding, on the odd occasion it's handy to grab a snippet of code out of someone else's blog and plop it in. Jeff Atwood of Coding Horror has a solution to some of the downsides of ripping a bit of code from somewhere on the Internet: publishers of code snippets generate a new GUID, tag each code snippet with a GUID, and you paste that comment in with the rest of the code when you take it. Then, if you (or someone else) needs to look at the context of the chunk of code, find it's author, look for improvements or commentary, or see who else has used that snippet in their own projects, you can search for that GUID and you should come up with only that GUID as a result.

What I propose is this:

// codesnippet:1c125546-b87c-49ff-8130-a24a3deda659
- (void)fadeOutWindow:(NSWindow*)window 
        // code
 

Attach a one line comment convention with a new GUID to any code snippet you publish on the web. This ties the snippet of code to its author and any subsequent clones. A trivial search for the code snippet GUID would identify every other copy of the snippet on the web:

http://www.google.com/search?q=1c125546-b87c-49ff-8130-a24a3deda659

How very, very cunning. He also proposes that if you modify a snippet and republish it, you should keep the old GUID and also add one of your own, so you can track the origin and help other people find your alternate version. Attaching unique identifiers to chunks of code and sending them all around the Internet. Does this sound like distributed revision control to anyone else? A lot easier to master than Git's UI, too...

(Sometimes a blog is just somewhere to put stuff you'll otherwise forget.)

dpkg -l colrm 90 colrm 1 2 grep '^ ' column -t

(There are two spaces in that grep, just in case it doesn't come out right in the final blog rendering.)

For those times when you just want the package list without the fluff - or, as a script that can accept a parameter:

#!/bin/sh

dpkg -l "$*" colrm 90 colrm 1 2 grep '^  ' sort column -t

$ ~/scripts/versiontable.sh apt* dpkg*

Could add grep ii as an extra pipe in that (after the initial dpkg -l call) to only list installed versions etc.

$ ~/scripts/versiontable.sh dpkg* apt*

apt              0.7.21

apt-arm-cross    0.7.11

apt-cross        0.13.0

apt-doc          0.7.21

aptitude         0.4.11.11-1+b1

apt-show-source  0.10

apt-utils        0.7.21

dpkg             1.14.26

dpkg-cross       2.5.1

dpkg-dev         1.14.26

dpkg-www         2.54+nmu1

Interesting side-effects though - *foo* is different to "*foo*" or \*foo\*. Might be better to use $@ but that means always needing quote marks for multiple package queries.

This new xorg.conf-less X is a great idea, but now I have to add all the sections back in order to define "Virtual" and get monitor-spanning. Or maybe I'm missing another xrandr trick.

From the exoplanets mailing list:

A 1.9 Earth mass exoplanet (period 3 days)
has been detected around Gliese 581 (Mayor et al).
See
http://exoplanet.eu/planet.php?p1=Gl+581&p2=d
It is the lightest planet detected up to date around a main sequence star.
In addition, the planet Gliese 581 d has a revised period of 67 days,
bringing it in the habitable zone of the parent star.
Jean Schneider

Gliese 581d is now more solidly inside the habitable zone; it was considered before to be on the outer edge of the habitable zone (this work moves its believed semi-major axis from 0.25 AU to 0.22 AU). Gliese 581d was a maybe for habitability (see this Centauri dreams article for example), depending on cloud cover, etc. Now its definitely in. The new Gl 581e is beyond the classical habitable zone. These planets are quite close in: Rory Barnes and colleagues at Lunar and Planetary Laboratory in Arizona did some good work on the habitability of Gliese 581 c (paper online) and concluded that it would be tidally heated to such a degree it was probably never habitable. Such tidal heating might make Gl 581e habitable; time to run the model again. Correction: On reading the ESO Press release and paper (via) it appears that Gl 581e is inside the orbit of Gl 581b, and too close to the star to be habitable. To date, planets have been labelled b, c, d .. as they are discovered, and they've been discovered shortest-period first, so 'b' also meant closest to the star. Now Gl 581e is closest to the star, with a period of 3 days. Tags exoplanets, tides, astronomy, habitability

DarkSEO has some code to attack php3bb captchas. (Note: I didn't even look at the code, it could be a virus or anything).I do not find that very surprising that this has happened, most of the captchas around are very naive, and I've seen multiple scientific articles detailing how to attack various captchas. Many use colors and thin lines to make them look hard, but after applying a naive energy function and doing some blurring to remove the thin lines, they break down.ReCaptcha is quite interesting, because it doesn't bother with some useless colorification that doesn't change contrast. But I wonder if it can't be overrun by spammers and how long it will scale. Still I figure it is what I would pick right now, because they can upgrade it if it actually is attacked by solvers.It doesn't help much for the proxy attack on Captchas though (offer users to view some pr0n in exchange for solving a Captcha that you actually were given to solve by another site) - at least not when combined with some XSS and/or bot net. (The 'obvious' proxy approach can be IP-filtered.)

This morning the build of the Parma Polyhedra Library (ppl) finished on my m68k buildd:

buildd@spice:~$ head logs/ppl_0.10-4_20090228-2019
Automatic build of ppl_0.10-4 on spice by sbuild/m68k 98
Build started at 20090228-2019
....
Finished at 20090421-0636
Build needed 1231:16:23, 1342752k disk space

Yes, the build needed 51 days 10:16:23 on that 68040/40, mostly because the build needed some amount of memory that exceeded the available 64 MB. Nevertheless I'm not the only one that wasn't very happy about the long build times of ppl as bug #517659 shows. It kept me away from shutting down the buildd for a long time to do the yearly clean up of the inner parts (removing the dust), but led to a rather high uptime as already reported. Now I can shutdown the machine for the clean up and attaching it to a UPS in the next days - after more than 510 days!

Following to the email sent regarding the French law known as HADOPI (I blogged about it a few weeks ago), I had a meeting this afternoon with my local representative. This half an hour meeting allowed me to explain my fears regarding this firewall which could be set up on French citizens computers to enable them to prove their non-culpability (provided their computer runs a popular proprietary OS). My representative kindly listened to me and his assistant understood the situation very well. I was even impressed that they have worked a lot on this law before the meeting. They both proposed to raise this issue to Christine Albanel, the current French Minister for Culture and Communication, who is at the origin of this law. They agreed to say that this wouldn t be changed for the next lecture (planned for the end of the month), as this particular chapter was meant to be detailed in further texts. They also admitted that this law had little chance to be really applied as is, as they consider some aspects to be anti-constitutional - they hence think that the French Constitutional Council will prevent this law to be applied, at least as it is when writing this post.
My representative also admitted that this law was somewhat outdated (even if not yet voted!). Actually, this kind of law will ever be outdated I kindly thank my representative for his time and his frankness (even if on the bad side for this law, he was very open to my thoughts). Good to know France is still a real Democracy!

Ok, here we go again. I do hope somebody, somewhere is finding these posts of some use. *g*

• Changeling: I ll confess I m not very fond of Angelina Jolie, and I watched this movie exclusively because it came from Clint Eastwood. I gave it 5/5, which may be a tad too much, but that s how I felt right after it finished. It s not a light movie, but I do think everybody should give it a try when they find themselves in the mood.
• One Fine Day: This romantic comedy doesn t have much of a high rating on IMDB, and maybe I m too fond of George Clooney myself, but it pleased me enormously. Thanks to Marc HE Brockschmidt for having recommended it to me in the first place, though probably you shouldn t bother if you can t stand the genre at all. Ah, and Michelle Pfeiffer.
• Sling Blade: I was left deeply in awe by this movie, and even more so when I found out the director, writer and main role are all the same person, Billy Bob Thornton. One of the things that pleased me the most was the ending, because I found it included a good share of food for thought, particularly regarding how the characters would get on with their lives afterwards, which is not shown. Again, not a light movie, I ll reckon.
• Sideways: I enjoyed this movie a lot, and I should watch it sometime again, because I think I didn t scratch it enough. Which is great, because it s rather difficult combining hilarity with reflection. Viva la escena in the fast food restaurant.
• Tiempos de az car: I ve comitted to watching some more Spanish films, and this one is the more remarkable of those I ve seen as of late. This is a bittersweet love story spawning more than 30 years, and has Ver nica Forqu and Charo L pez in wonderful supporting roles. I should watch more films of Charo L pez.

Isaac watched Love Actually recently, and I oooh ed quite a bit when he told me, because that movie has one of my favourite or should I say powerful scenes of all times for me, and recalling it brings me instant joy and often instant tears. I think these three (spoiling) minutes are so powerful because, albeit they are fully anticipated for the spectator, they come as a complete surprise to both protagonists (obviously to her, but also to him, given the dialog that takes place once she gets down the stairs; that tiny dialog is in fact the most powerful bit of it all).

Today was the season opener for Tripoli Colorado at their launch site on the buffalo ranch near Hartsel, Colorado. After huge snowfalls along the front range of the mountains in the last few days, we were a little tentative about going, but it turned out to be nearly perfect flying conditions! There was apparently much less snow this week on the high plains west of the front range, and by this morning the snow had almost entirely disappeared, the skies were clear and blue, and the winds were calm except for a few gusty bursts in the afternoon. This launch site is really something special, at 8800 feet above mean sea level, in the middle of a huge area of wide-open short grass prairie. We love flying there, and today the drive to and from the launch site through the snow-covered Colorado Rockies was just beautiful! Son Robert and I flew three rockets today, including his LOC/Precision Lil Nuke with added payload section on an Aerotech G54W-M reload, and our Polecat Aerospace 5.5 inch Goblin kit on one of the relatively new Aerotech I245G-M "Mojave Green" green-flame reloads. But by far the highlight of the day was flying my Giant Leap Vertical Assault on a Cesaroni J335 red-flame reload... with serial number 1 of TeleMetrum on board collecting our first-ever flight data! From the ground, it looked like a textbook perfect dual-deploy flight, with a small drogue chute out at apogee around 4000 feet above ground, and the main chute deploying at 700 feet above ground for a beautiful, soft landing only a couple minutes walk from the launch rail. The ejection events were controlled by a PerfectFlite MiniAlt/WD. The data recovered from it shows a big negative spike in the altitude right at apogee, coincident with firing of the apogee deployment charge. I have to assume this means the aft bulkhead on the avionics bay in the reconstructed coupler section isn't sealing well, and some pressure from the apogee deployment charge leaked in to the avionics bay "fooling" the altimeter into thinking the altitude was lower for a sample or two. Clearly, that needs to get fixed before that airframe flies again. Further evidence that we had a mighty kick from the apogee ejection charge was discovered when we went to clean the motor casing. The Cesaroni reloads are packaged in a plastic liner tube that slides into the reusable aluminum case. When we pulled the spent reload out of the case, it was significantly shorter than when it was loaded, suggesting that the ejection charge forced the forward closure on the reload backwards compressing the heat-softened plastic. This could be evidence that the reconstructed coupler was slow to separate from the booster airframe due to excessive friction? The flight data recovered from the TeleMetrum board looks great until apogee, when the data collection stopped. Since I flew firmware that was compiled and flashed on the flight line from Keith's latest git commit as of this morning, it's entirely possible that there was a software bug that caused data collection to terminate at apogee. We'll investigate that. But I personally think what actually happened is that we experienced a temporary short in the power supply at the time the apogee ejection charge fired. On extraction of the electronics sled from the avionics bay this evening, I noticed that one of the mounting screws has gone missing. If it wasn't snug enough, and vibrated loose during flight, it could have been torn loose at the time of the ejection event and shorted something as it rattled around in the avionics bay. The screw is now just missing, but may have fallen out when we were extracting data on the flight line just after the flight without being noticed at the time. So I'm not inclined to worry much about this, at least until we can get some more flight data! Keith post-processed the raw flight data and presented me with a plot showing two traces, acceleration and barometric altitude. The data from the accelerometer closely matches the published data for the motor we flew, which is a really cool result, and my 10-year-old son enjoyed figuring out why the rocket showed negative acceleration after the motor burn out but was still climbing. (See, there really is some science education hidden in the fun!) All in all, we had a great time, and it's totally cool to have data from a first flight of TeleMetrum! Can't wait to fly it again!

Structure Synth is an application for creating 3D structures from a set of user specified rules. It is an attempt to make a 3D version of Context Free (a free -GPL ed- program that generates images from written instructions called a grammar). The cool thing about Structure Synth is that it has a simple language for writing recursive scripts that can generate complex structures (kinda Processing, but in 3D), and you can feed the result into Sunflow (a rendering system for photo-realistic image synthesis, already available in Debian) to generate Escher-like cool images. The program is waiting in the NEW queue, but you can temporarily download my packages (for Debian SID amd64) if you want. Even though I ve tried hard to be the one to blog about this, my friend Javier Candeira has won the competition and has been able to write about this earlier than me Spanish readers might want to have a look at JoSeKBlog, where he describes how to combine Structure Synth and Sunflow, and where I first read about the existence of the program.

/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

I had written a few weeks ago about my new (almost) empty xorg.conf file and explained how I had to edit an HAL .fdi file to change my keyboard layout and define my compose key. The Debian Xstrike Force have written a complete guide on the Debian wiki explaining this input hotplug system. I have found that there is no need to edit .fdi files, just set the following options at the end of /etc/default/console-setup: Even better, they should now be automatically grabbed from your existing xorg.conf when upgrading!

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.

LVM can be a virtue. However, it can also be a pain at times; for instance, there's loss of diskspace due to LVM's metadata that needs to be stored as well. This amounts to approximately 5% of the diskspace (if I'm not mistaken), which can be quite a bit. Also, this is an extra abstraction layer, which requires memory and CPU time to be processed. This will be negligable on most modern computers, but sometimes it isn't. I had a system that had quite a few things on LVM, and wanted to get rid of them. Unfortunately, to remove the LVM physical volumes would mean that I'd have to get rid of the data, which would mean storing it somewhere else, which in turn would probably mean that I wouldn't be able to use the system for quite a long time. That wasn't acceptable. So, instead, what I did was to export a whole hard disk (one with enough space to hold the logical volumes on that machine) using NBD, and migrate stuff that way:

• First, set up the NBD export. The config file should look something like this:

[generic]
	user = nbd
	group = disk
[export]
	exportname = /dev/hde
	port = 1234

This will export all of /dev/hde on port 1234. Obviously you wouldn't want to do this on an untrusted network, but that's always true with NBD (in my case, the link was a 1M crossed cable -- quite safe).
• Next, we'll connect the client:

nbd-client <server> 1234 /dev/nbd0

... assuming /dev/nbd0 is not in use yet. Provided the client machine is running kernel 2.6.26 or newer and nbd-client 2.9.10 or later (e.g., Debian Lenny or later), and you're running udev, this will create a number of /dev/nbd0pX device nodes, with X starting at 1, one for each partition on the disk. Of course, one can also export a specific partition rather than the whole disk, or just one file on a filesystem, or create a physical volume of the entire disk rather than just a partition -- your choice.
• Now we need to add the networked block device to the LVM volume group. Assuming the second partition is the one we want to use:

pvcreate /dev/nbd0p2
vgextend /dev/<vg> /dev/nbd0p2

If you now run 'vgdisplay', you'll see that the size of the LVM volume has increased considerably.
• Next, we'll want to move data over the network. Assuming the 'local' LVM volume is on /dev/sda7:

pvmove -v /dev/sda7

This will show progress information every 15 seconds while the data is being moved from the local hard disk to the NBD device. You'll be able to continue using the system as usual--although of course the system will gradually get slower and slower as more and more data is only available through a comparatively slow network connection.
• Once everything's moved to the other sytem, you're all set to change stuff locally:

vgreduce -a /dev/<vg>
cfdisk /dev/sda
...

• Finally, you'll need to move the data from the NBD device back to the local hard disk. If you're still using LVM, that can be done using another pvmove operation. If not, you'll have to do something else, like cp -a. Obviously in that case, there will be some time in which you won't be able to use the system properly.

This final step might not be as simple as it sounds; e.g., if your /home filesystem is on LVM currently and you want to move that out of LVM, you'll have to make sure only root is logged on; If /var is on LVM, too, you may have to go to single-user; etc. Figuring out the details for this one is left as an exercise to the reader. However, I will note that since somewhere between etch and lenny, doing root-on-NBD is possible; and if you're running unstable, then doing root-on-LVM-on-NBD should be possible, too, although I would suggest a little caution before trying that. In any case, using NBD in this way just saved me a whole lot of no-computer-time here. Which is great.

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! ;-)

I've previously mentioned my plans on redoing my blog. Well, I've settled down on some design issues already (posts will be stored as mini Atom feeds, which makes the generation of Atom feeds for the blog and categories trivial, and gives me maximum flexibility. I already have a working converter for my existing blog to Atom posts.)Generating static HTML pages from that will be easily possible using an XSTL transformation (for example), and I got the feedback that I could just use Google AppEngine for blog comments, so my actual blog could remain static-only (and thus much more secure and reliable). Any attack/spammer/bot can then only kill the comment functionality, not my own site.Which brings me to another design consideration: the editing widget. Either for the blog comment application, for writing my own blog entries (via a https protected script or whatever) or maybe for a small CMS I've been thinking about - having a reliable HTML in-browser editing widget is something I could use every now and then (well, I'm not doing much Web stuff anymore these days).Geniisoft has a good overview over in-browser (aka: Through The Web, TTW) editors. The top candidates seem to be:

• FCKeditor
• TinyMCE
• Xinha

I've heard before of FCKeditor and TinyMCE; I think I've been on the Xinha page before, too. However, comments on them have not always been good.To some extend they all seem to have (to some extend) feature creep which usually is a bad sign - most often this means that there are security issues in one or another module or plugin.TinyMCE for example has been described as "a bit of a pain" and "a tad clumsy" on the GSoC mailing list. I have had less fights with it than with the Debian Wikis (MoinMoin) markup language though.I'm not looking for anything as big as these - I just need an editor that allows for some basic formatting (bold etc., links) and that produces reasonable XHTML output. I'll be feeding the output through some custom cleanup script anyway, which will kill disallowed code. So I don't want any editor which allows the user to create code that will then be killed afterwards.Any personal experiences with any of these, or an important alternative that I might have missed (no PHP involved, please!) - email me (no comments on blog) at erich AT debian org.Update: I've received a couple of pointers. Please don't send me links to projects that are not actively maintained anymore - I don't want to care about having to fix bugs in the editor widget myself.One link I've received twice is actually quite impressive: WYMeditor. It doesn't try to look like a word processor, but actually is more of a semantic editor. Much more what I'm looking for than any of the others. I've also received a link to the Yahoo! UI Library Editor, which is quite clutter-free, but in the default setup at least very text-formatting oriented, not very semantic (that doesn't mean you couldn't change it that way, I guess you can). I was also pointed to Dojo, but that framework is totally feature creep (which also explains why it loads so slowly I guess), and the last time I looked at it's source code, I had some WTF moments - code quality at least outside of core doesn't seem to be very high (Yes, that code implements the "mod 7" operation using list shifts instead of a simple arithmetic operation).Looks like I'll give the first try to WYMeditor. Update #2: the code seems to be rather ... complex. I'm looking for something neat and clean; it doesn't need to bring along yet another XHTML schema and validator ... Maybe I should try one of the others first?