Search Results: "beh"

23 March 2007

Martin F. Krafft: Epiphany and vertical tabs

Firefox is becoming totally unusable, and even though some extensions I need/want do not exist for Epiphany (like Web Developer and Firebug, Live HTTP headers, Stealther, UrlParams, Cookie Button, and plenty of the features of Tab Mix Plus (among others)). The single biggest obstacle keeping me from switching are vertical tabs. I usually have a browser window for each task I work on, and on average, I'll have 15 tabs open in it. With Firefox, I hacked the UI to make the tabs line up vertically on the left side of the window. That way, I can easily keep track of 30 open tabs, and I gain vertical space for the payload at the expense of window width. Dear lazyweb: do you know of a way to move the Epiphany tab bar to the left of the window and have it fill with tabs top-down? Please let me know! NP: 65daysofstatic / The Fall of Math Update: Lazyweb, you're aweseome! Rodney Jokerst referred me to his Epiphany extension, which does just what I want. Update: due to popular demand, here's the Firefox hack I use in chrome/userChrome.css: 
#content > tabbox  
  -moz-box-orient: horizontal;
 
.tabbrowser-strip  
  -moz-box-orient: vertical;
  /* note: you can set this to -moz-scrollbars-vertical instead,
  but then the scrollbar will *always* be visible. this way
  there is never a scrollbar, so it behaves like the tab bar
  normally does */
  overflow: -moz-scrollbars-none;
 
.tabbrowser-tabs  
  -moz-box-orient: horizontal;
  /* min-width: 50ex; */ /* >1680 pixels screens */
  /* min-width: 40ex; */ /* =1680,1600 pixels screens */
  /* min-width: 35ex; */ /* =1440 pixels screens */
  /* min-width: 30ex; */ /* <1440 pixels screens */
  min-width: 20ex; /* 1280 pixels screens */
  /* min-width: 17ex; */ /* this is almost the minimum to go down to on small screens */
  -moz-box-align: start;
 
/* Background for tabbrowser strip */
tabs.tabbrowser-tabs  
  background-color: grey !important;
 
.tabbrowser-tabs > stack > vbox > hbox > hbox  
  -moz-box-orient: vertical;
  -moz-box-align: stretch;
 
.tabbrowser-tabs > stack > vbox > hbox > hbox > tab  
  -moz-box-align: start;
  -moz-box-orient: horizontal;
 
/* to put the tabs on the right un-comment this line
  (not needed if using Tab Mix Plus) */
#content > tabbox  -moz-box-direction: reverse;
Even though the origins of this code are IRC channels and other forms of random pasting back and forth, of which I was a part, I took the above from this page.

Wouter Verhelst: On the Debian Mailinglist "Code of Conduct"

There's something which has been bothering me for a while. I haven't talked about it much since I don't consider it all that important after all and since I know I'm probably in a minority position, but whatever. Personally, I think the "do not Cc" policy in the Code of Conduct of Debian mailinglists is a big mistake. It serves no useful purpose (other than giving some people a reason to complain). If you want to make sure that people do not mail you unless you absolutely ask for it, then you should get their mail clients to support some sort of header to enforce that behaviour; and you should also make sure you set that header in your own mails. Most people on the Debian mailinglists use free software, after all, so doing this should be possible. Personally, I find it rather offensive that people can call Cc'ing you spamming, and get away with it. I refuse to even bother to keep track of who wants a Cc and who doesn't, and I refuse to use different keystrokes for 'reply to list' and 'reply to sender'. There's "reply" ("r", in mutt), which should go to the sender of the mail only; and there's "reply to all" ("g", in mutt), which should go to everyone who could read the original mail (either through direct, private mail or through list mail). Everything else requires special attention anyway, so it's pointless to try it. At least in my opinion. Oh well.

John Goerzen: bzr, again

I've talked a lot lately about different VCSs.

I got some interesting comments in reply to my most recent post. One person took issue with my complaint that nobody really understood how to specify a revision to git format-patch, and proceeded to issue an incorrect suggestion. And a couple of people complained about my comments about bzr, which generally came down to the released version of bzr didn't have anything compelling and also didn't support tags.

So I went into #bzr, asked them what bzr has that git, Mercurial, and darcs don't. And gave bzr the benefit of the doubt that 0.15 will be out soon and will be stable. What I got back were these general items:

  1. Renaming of directories (not in hg, git)
  2. 2-way sync with Subversion (not in hg, darcs)
  3. Checkouts (not in any others by default)
  4. No server-side push requirement


Let's look at these in more detail.

1. Renaming of directories

All of them can rename files and (excepting git) completely accurately track back the file's history. But consider this: if person A commits a change to branch A that adds a file, and person B then renames the directory that the file is in on his branch, will a merge cause person A's file to appear in the new directory name? In darcs and bzr, yes. In Mercurial and git, no.

So yes, this is a nice thing. But I have never actually had this situation crop up in practice, and even if it did, could be trivially remedied. I would say that for me, I don't really care.

[Update: Current stable releases of Mercurial can do this too. I'm not quite sure how, but it does work. So git is the only one that can't do that.]

2. 2-way sync with Subversion

This is a really nice feature and is present in both git and bzr. I haven't tested it either place, but if it works as advertised -- and properly supports tracking multiple related svn branches and merges -- would be slick. That was enough to make me consider using git, but in retrospect, I so rarely interact with people using svn that it is not that big a deal to me.

Still, for those that have to work with svn users, this feature in bzr and git could be a big one.

Better yet would be to get all those svn holdouts over to DVCS.

3. Checkouts

A bzr checkout is basically a way to make local commits be pushed to the remote repo immediately, as with svn. This is of no utility to me, though I can see some may have a use for it. But it can be done with hg hooks and probably approximated with scripting in others.

4. No server-side process necessary for pushing repos

bzr has built-in support to push to a server that has sftp only, and doesn't require a copy of itself on the server. While I believe that none of the other three have that, it is possible to rsync (and probably ftp) darcs and Mercurial repos to a server in a safe fashion by moving repo files in a defined order. Probably also possible with git. All four can pull repos using nothing but regular HTTP.

What bzr still doesn't have

Integrated patch emailing. The big thing is that it has no built-in emailing of patches support. darcs is extremely strong in this area, followed by hg, and git is probably third. "darcs send" is all it takes to have darcs look at the remote repo, figure out what you have that they don't, and e-mail a bundle of changesets to them. I posted an extension and later a patchset that does all this for Mercurial except for automatically figuring out what default email address to do (that'll come in a few days, I think). One feature Mercurial has had for awhile that Darcs hasn't is sending multiple textual diffs as a thread, with one message per changeset. bzr doesn't have any support for emailing patches yet, which is disappointing. Because of the strong support for this in darcs and Mercurial, people running those systems feel less of a need to publish their repos.

[Update: There is a plugin for bzr that seems to address some of this. I haven't tested it, and it's not in bzr core (so doesn't quite meet my very friendly for a newbie requirement), but this does exist, though apparently not as advanced as Mercurial]

Performance. Supposedly 0.15 is supposed to be better on this, but even if bzr achieves the claimed doubling of performance, most benchmarks I have seen would rate it as still being significantly behind git and Mercurial, though it may overtake darcs in some tests.

Extensive documentation. I would say that bzr's docs are better in some ways than git's (its tutorials especially), but lack depth. If you want to know some detail about how the repository works on-disk, it's not really documented. Darcs still has David's excellent manual, and Mercurial has the hg book which is still great as well.

Merging not as advanced. darcs is pretty obviously way on top here, but of the others, Mercurial does a pretty good job with its automatic handling of renames and automatic resolving of different branches that commit the same change (even if that same change is a rename, or an add of the same content). bzr can't resolve as much automatically.

Summary

Well, I'll say that bzr still doesn't look compelling enough for my use cases to use, and the lack of an easy-for-a-newbie-to-use automated email submission feature is a pretty big disappointment. Though I did appreciate the time those on #bzr spent with me, and if I needed to sync with svn users frequently, I'd probably choose bzr over git.

For now, I'm happy with sticking with darcs for my code and hg for my Debian work.

But all four communities are aggressively working on their weaknesses, and this landscape may look very different in a year.

22 March 2007

Andrew McMillan: Seamless Monitor Hotplugging with X Windows

There are times when you want to track the bleeding edge of a particular project, and having a new laptop is often one of those moments... I've recently bought an HP Compaq nx6320 and while most of it is working, one of the reasons I got it was because of Keith Packard's work on the RandR extensions for X. Well, I was definitely seeing this bug but with a small patch I can get the latest (experimental) packages for xserver-xorg-video-intel to work, and now with a few magic tweaks to my xorg.conf I can make my desktop expand to another monitor when I unsuspend at work, and contract back to just the laptop screen when I resume somewhere else. The Magic Expanding X Config First of all, when I got the driver to actually work, xrandr explained to me that my maximum resolution was 1400x1400: 
Screen 0: minimum 320 x 200, current 1400 x 1050, maximum 1400 x 1400
VGA disconnected (normal left inverted right)
LVDS connected 1400x1050+0+0 (normal left inverted right) 305mm x 228mm
   1400x1050      60.0*+
   1280x800       60.0  
   1280x768       60.0  
   1024x768       60.0  
   800x600        60.3  
   640x480        59.9  
TV disconnected (normal left inverted right)
Using a few clues from Ross Burton I managed to get that "maximum 1400x1400" to increase. The trick is to add a "Virtual" setting for screen size into your "Screen" Section, like so: 
Section "Screen"
        Identifier      "Default Screen"
        Device          "Intel 945GM/GMS/940GML"
        Monitor         "Laptop Panel"
        DefaultDepth    24
        SubSection "Display"
                Depth           24
                Virtual         2680 1050
        EndSubSection
EndSection
The downside of this is that if you set the width greater than 2048 (as I have here) then DRI won't work, so you won't get 3d stuff. I guess I can manage without ice-cream, just so long as I get my cake! Once I have the "Virtual" setting, when I resume at the office I can: 
xrandr --output VGA --mode 1280x1024 --pos 1400x0
And then when I resume somewhere without the external monitor, I can: 
xrandr --output VGA --off
Quibbles All of these features are kind of under development, but Xorg 7.3 will support this stuff, and then Gnome and suchlike will have to start thinking about how to deal with it. The dynamic screen changing is not something these environments are completely ready for. One example is that while I know that monitor is always on the RHS of my docking station, X wants it to be the primary monitor and Gnome moves both panels onto that screen. Perhaps that's not a choice that can be made automatically. Someone who had an external keyboard plugged into their docking station might want the opposite behaviour, and there is certainly no way the environment can magically know whether that monitor is left or right of my laptop screen. Eventually I expect that Gnome will recognise this monitor, and will make the panels and location automatically set the RandR environment to match the way I set it last time. It is also somewhat annoying that I have to actually choose the virtual size. No doubt this configuration will disappear in due course and it is not really surprising to see it for something which is admittedly quite bleeding edge! I noticed at LCA that Keith had his own screen set for a Virtual size of 2048x2048, and now I know why: that's the maximum size that is supported for DRI, so if I expand my desktop onto a 1280x1024 screen I'm going to have some overlap. In fact I could almost configure my external monitor to be above my normal screen and use it that way, but it would feel pretty weird I think. In the meantime I've gone back to "blank screen" for my screen saver which admittedly is currently the only application for 3d acceleration on my desktop. Remaining Problems with this Laptop The only outstanding issues for me with this laptop are: That's about the best Linux compatibility I have had for any of my last five laptops within a month of buying it. Most of them have had much more significant stuff less supported even after three years of use!

20 March 2007

Benjamin Mako Hill: PHLanthropy

Last week, I had planned to travel from Boston to Tampa with a connection in Philadelphia. I landed in Philadelphia without a problem but an ice storm descended on the airport and, after five hours of our flight's departure time being pushed back, the entire airport was closed and all flights for that day were canceled. When I arrived back at PHL the next day, two hours before the scheduled departure of my flight home -- my trip to Tampa was, by this point, called off entirely -- the airport was in chaos. Flights were still being canceled, airport information displays were inaccurate or switched off entirely and stranded travelers were everywhere. US Airways had deactivated the automatic ticket machines and there were thousands of people in scores of lines hoping for new tickets and assistance. But unlike the day before, we all knew that planes were theoretically going to be leaving and that, stuck outside, we were not going to be on them. People wanted boarding passes and they wanted them desperately. But the lines were not moving and nobody -- or almost nobody -- was going anywhere. Meanwhile, the four teams of TSA workers at the security station were standing idly talking to themselves like attendants at a light night gas station. The only people inside the terminal were those that had slept there or flown in that morning. After finding the end of a line, I asked someone what their line was for. Nobody knew, but each hoped it lead to someone who would assist with their particular problem. Usually they merely wanted to check in. Several people I asked had been waiting in line for five hours that morning only to find out that their line was, in fact, not a line at all but merely a mass of people leading nowhere or simply dissolving into other lines. Nobody knew what else to do so, I, like everyone else, queued up and hoped for the best. An impeccably dressed and obviously wealthy woman asked what I was in line was for. I told her that I didn't know but, like everyone else, hoped it would lead to a boarding pass. She wanted the same thing. She asked if there was a separate queue for first class and I pointed out that it seemed unlikely, in the chaos, that first class was getting special treatment. I pointed out that I also had a first class ticket -- it was the only seat available when the harried agent rebooked me the day before and I had not paid extra for this, but I did not tell her this. She nodded to me in camaraderie. She stood pensively next to me for five minutes and then fumbled for her wallet and ticket. She asked me if I would hold her place in line and I agreed. Five minutes later she reappeared with a boarding pass in her hand. Surprised, I asked her how she had obtained it. She stated, quietly so as not be overhead by the other would-be passengers but matter of factly, that she'd found a baggage handler and flashed a twenty dollar bill and her itinerary. She mentioned that the man she had paid had left but that, "any of them will do it." Sure enough, I was in the terminal less than ten minutes, and twenty dollars, later. Despite growing up partially in the third world, I've only personally bribed a person once before -- also in the United States. Like my previous experience, I didn't feel good about buying my way out of what seems to have, in fact, devolved into a racket. I have spent a lot of time reflecting on the situation and my action in the last several days. Everyone, or nearly everyone, outside the Philadelphia airport terminal had twenty dollars and most of them would have happily paid it to escape their predicament. The reason that most people did not pay off baggage workers is not because they found it prohibitively distasteful, although certainly some of them would have, but because most of us, and I include myself, would have spent the whole day frustrated, desperate, and standing line after line without even considering a bribe as an option. While we know it on some intellectual, reflective level, the vast majority of us do not, in practice, imagine that we can use money as a way to manipulate people into special treatment. As a result, even in situations like that morning in Philadelphia, I simply don't even think of the twenty in my wallet as a way to solve my problem. It's true that wealthy people, like the woman in line behind me, get what they want because they can pay lots of money for products and services. But it is not quite this simple. Some wealthy, powerful people get what they want in part because they think to use money in ways that the rest of us do not. Perhaps this is because this type of spending is frequently not an option for most of us or, we tell ourselves, perhaps even truthfully, because we find it distasteful and immoral. The difference between being inside or outside the terminal last Saturday was not about having or not having money. It was, in fact, about having a particular relationship to money and, through money, to other people. It was not about the value conferred by money but about a set of values that can result from having it in abundance.

14 March 2007

Neil Williams: g++-3.4 and g++-4.1 cross-built side-by-side

edos-debcheck reports that the emdebian toolchain for alpha built from gcc-3.4 cannot be installed on i386 (and possibly amd64) when the repository also contains the toolchain for gcc-4.1:
libstdc++6-dev-alpha-cross (= 3.4.6-5): FAILED
The following constraints cannot be satisfied:
libstdc++6-dev-alpha-cross (= 3.4.6-5) depends on libstdc++6-alpha-cross (>= 3.4.6-5) libstdc++6-alpha-cross (= 4.1.1-21)

Yet there is no problem with these for arm or other architectures (except possibly s390). In the main Debian archive (native build), g++-3.4 depends on the gcc-4.1 version of libstdc++6. http://packages.debian.org/unstable/devel/g++-3.4.

$ edos-debcheck -explain -failures -check libstdc++6-dev-arm-cross combined

reports no errors.
('combined' here is a result of appending the Packages file from Debian to the Packages file from Emdebian although the Emdebian repository is slightly behind my own data. I'll sort out the update tomorrow.).

The repository can only contain one version of libstdc++6, just like any one system can only install one version (at least in /usr/lib):
$ reprepro list unstable libstdc++6-alpha-cross
unstable main i386: libstdc++6-alpha-cross 4.1.1-21
unstable main amd64: libstdc++6-alpha-cross 4.1.1-21
unstable main powerpc: libstdc++6-alpha-cross 4.1.1-21

By building separately, the emdebian cross-build has a dependency on 3.4.6-5 and despite the >=, edos-debcheck reports that the dependency cannot be satisfied.
$ dpkg -I /var/emdebian/debian/pool/main/g/gcc-3.4/libstdc++6-dev-alpha-cross_3.4.6-5_all.deb grep Depends
Depends: gcc-3.4-base (= 3.4.6-5), g++-3.4-alpha-linux-gnu (= 3.4.6-5), libstdc++6-alpha-cross (>= 3.4.6-5), libc6.1-dev-alpha-cross (>= 2.3.5-10)

The next cross-build of gcc-3.4 on i386 for alpha needs to use the version of libstdc++6 from the repository instead of making an older version via dpkg-cross. Not sure why this only affects alpha cross-builds.

Lucas Nussbaum: Jabber clients and OS usage stats (3)

Using XMPP4R, I did some stats about Jabber clients usage on the Apinc Jabber server, which hosts im.apinc.org, jabber.fr, and many more using virtual hosting. I already did similar stats in March 2006 and September 2005. The poll was done by sending jabber:iq:version to online users, around 1:00 PM (french local time, most of the users are french). 1343 clients were pinged, and 1315 answered, which is better than last year (1145 answers). Of the 1145 jids that answered last year, 368 were also part of the poll this year (I don’t know if this is good, or not enough). Systems: Clients: (all clients with at least one reply are listed here) I also did some stats on the Linux distros. With 566 Linux users, one can consider that statistically signifiant. (Other distros are below 5 replies) The Debian/Ubuntu situation is interesting. Debian is not dying, even on the desktop ! The server is hosting jabber.ubuntu-fr.org, so the results are biased towards Ubuntu. Update: it seems that Psi reports “Debian GNU/Linux (testing/unstable)” even when running on Ubuntu. This is the case for ~5% of linux users. To server admins: if you are running a large jabber server with jabberd 1.6, it’s easy to give me the right to get the list of online users, so contact me if your are interested in me doing your users stats. It would be interesting to see if users from different servers/countries have different behaviours. I’m not sure if it’s possible with ejabberd and other servers.

Gunnar Wolf: High, cold, tiring, beautiful, delightful, proud... Should I go on?

[ Warning: Long post follows ]
Just today, I read that H01ger is happy he can wear just a T-shirt somewhere in Northern Germany. Well, from my point of view, much the opposite has happened. And I'm not just happy - I'm fucking proud!
About four years ago, Nadezhda went almost every weekend to hike to the mountains with the Grupo de los Cien people. I'll sidetrack a bit to speak about them: Grupo de los Cien is a group of mountain lovers (no relation with the enviromentalist group which later took the same name) that, since the 1950s, have built and maintained the high mountain shelters in Central Mexico. It is a group, by the way, with which Nadezhda fell completely in love - and now it's up to me to find out why ;-) But lets go back to the main topic.
Almost every week, she came back delighted and loaded of energy from a mountain hike. Almost every week, I told her I wished to go with her, of course, if they went to a simpler route. Of course, lugging around over 130Kg of humanity is no easy deal. And, after over a year and because of many problems that came together at once, she stopped going to the mountain as well. She always kept an eye on their friends, but so far had not been able to return to the mountain.

Ok, so last week she heard the group was organizing volunteers to go fix the Ayoloco 2 shelter. She signed up, and invited me. I was afraid, but accepted the challenge - Of course, full of fear.
Being this a historical event (at least in my life), I cannot but offer you some of the photos I took. And, yes, I've just started playing with Flickr. Lets see if it works for me ;-)
Saturday, 5 AM, we woke up. 5:50AM, we met part of the group near Daniel's house, in Condesa. 7 AM, we were having a nice breakfast (tamales and coffee, yum!) in Amecameca, still 28km from La Joya. From Amecameca, we went to Paso de Cort s, where we met the rest of the group, and from there we went by a little, bumpy and unpaved road until La Joya. Somewhat around 20 people started the hike at around 9 AM.


According to Google Earth, La Joya (just South of the Iztacc huatl - white woman or sleeping woman in N huatl) is at 3995m - And, of course, to start at that altitude is not easy. The air is very thin, and walking a little bit too fast quickly makes you feel the blood pumping, trying to get some more oxygen. I often remembered how my Bolivian friends behave in Potos , walking slowly even when in a hurry :)

We first went down a little valley, then up. The first portion of the hike was on soft, wet sand, with some grass (what we call zacate - Strong, hard grass, not what you commonly see in a garden). I soon learnt that was a blessing, as it was by far the easiest part. Then we went up a steep and quite rocky area - It started getting tricky for somebody not used to trusting his own feet. And it was steep, yes. This was the first time (of many, of course) I started thinking whether I should head back.

We reached what I foolishly thought was the summit, only to find a steeper, longer way to go. It started getting common to find little deposits of snow/ice (I don't know the exact term in English - it's called aguanieve in Spanish, literally snow-water. [[Update]: Thanks to the now-DD H01ger, I now know that aguanieve in English is called sleet]. I understand it's a bit harder than snow, but still much lighter than hail). We crossed a completely rocky section - No sand to hold the rocks to their place. That meant being extra careful (and thus, extra slow).

But just afterwards, in case it was not enough, Mother Nature answered my pleads for some sand - we crossed a section made exclusively of loose sand. And, please, if you have ever walked upwards on sand, imagine doing so at over 4000 meters. I was taking so much care of how and where I stepped that I strayed not more than 5 meters down of the path the group was following - Being able to climb back to the right path was really not easy. This was the point that not only I was thinking about heading back, but I'm sure Nadezhda thought I would abort the mission. She cheered me up, took some pictures of me as soon as I got out of the sand trap, and we were able to move on.

After the sand, some more rocks, and we started feeling the chilly wind. We entered a cloudy region - Humidity does get the coldness into your bones! We could not really see where was the rest of the group, so we proceeded the best way we could. Fortunately for Nadezhda and me, just behind us came the very experienced Mario Corsalini and led us. And, yes, we finally saw the Ayoloco 2 shelter.

I was by then exhausted, after some four hours of ascent. I ate one of my apples - The sweetest apple I have tasted so far. After resting a bit, and realizing I was almost frozen (we were at 2 Celsius under, with constant chilly, humid wind)... Then I started working with the guys, reinforcing the shelter, while Nadezhda and some other people painted the inside with. People started eating - of course, I joined them. And, after some time up there, we started going back down. Miguel ngel, a volunteer in the Izta-Popo park, walked a good portion of the descent with me, giving me tons of help and tips. Thank you, thank you, really. The descent is, of course, much easier - We were chatting most of the time, and we made only around two hours back. The weather was quite nice on us - We had some aguanieve falling every now and then (yes! Yes! many of you guys have heard/read me bitch on how I had never seen snow falling before - Ok, this is not exactly snow, but I think it qualifies as my first experience ;-) ), but aguanieve does not make you wet, as it bounces off the clothes. When we approached La Joya we started having some light rain. We hopped in the cars, and then the rain really began.
But even if this was not enough: Grupo de los Cien was celebrating the 83th birthday of one of its senior members, Poncho Rico. No, being 83 years old is not an excuse for skipping this memorable hike.

We went to Anatolio's house, very close to Amecameca, and had a delicious dinner, cake and drinks.
Nadezhda: Thank you. So, so, so very much. Thank you for being so patient with me, for dragging me up the Sleeping Woman. Thank you for getting me into this so very important and beautiful experience. I hope this will be the first of many. There is still a very long way for me to go before I'm really up to the challenge, but believe me: This will not be my last time on the mighty mountains.

Eddy Petri&#537;or: Wishlist for lenny... or why debian packaging is considered hard

(Update: Yes, Gunnar, the policy says that the debian/rules file must be a makefile, so if you do something else, you have a serious bug because of a policy break. Of course, probably there is nothing that should stop one from using, let's say bash, or python or perl, from a technical PoV.)

Erich has a wish list for Lenny.

What draw my attention was the very first "define and deploy a standard way of packaging software, that can be used for like 90% of packages", later he mentions rationale "other distributions (e.g. *BSD ports, Gentoo?) are ahead of us in this respect, having a standard way of packaging and building things and keeping track of changes."; these two quotes contain the real essence of Gentoo's success in the area of fast development.

A half a year ago I did an experiment in packaging a rpm, a deb and an ebuild for the same piece of software. What I observed back then made me think a lot about the entry level knowledge needed for a person to create a decent package for those types of package systems.

With the risk of being flamed by many people that will miss my point, I will tell you from the start that the deb would have been the most painful if had to start from scratch. Second would have been the rpm due to lack of good/updated documentation and the clear winner in lack of pain points was the ebuild. In reality places were switched between the deb and the rpm.

And before I start, please understand that what I want to point out is that the building system in debian is showing its age and we should do something about it, and is not about pointing people to documentation; it is about making things behave more sanely by default and not about having to read a whole day to understand why the package fails to install a file you just added then to find that you had to add the destination path to a debian/dirs file etc...


The deb had to be the most difficult. Not because I didn't do it before, or because it was hard, but because there are a lot of things that need to be done because the package management is not smart enough to do it by default (i.e. class inheritance does not exist, like is the case for the ebuilds or the macros for rpms).

The Debian approach is backwards, is reversed with regard to the others and the way it should be by default, to allow easier understanding of the packaging. You can, by default, make a package that is tweaked a lot. There is no concept (if you don't count cdbs which is boo-ed a lot by some people) or possibility to just say "make this package a package that is a standard linux app with the regular ./configure && make && make install recipe". And I don't count such a recipe the templates based on dh_make, that is way too verbose. A new maintainer wannabe has difficulties understanding why are those lines in there, and what they do, and most importantly, why is that order correct and no other. Another question which is legitimate is "is that the minimum or can that be trimmed"? (Follow debian-mentors and see how many people leave the .ex files just because they are afraid they will not know how to generate them again.)

Even the rpm has a concept of standard stuff to do for a package, there are some macros that implement that. And that is more logical for an untainted mind (as in not yet debianized) than what we have in the dh_make template, or worse, a clean and new debian/rules file. Why should one care to learn the ways and philosophy of make just to make a small package?


Let me tell you something that will feel like knife stab for many people in our community: the clear winner was the ebuild, not because I was smart or exciting, but because:

I did the ebuild in one day's work (it was less, but some will not believe me, so I'd say 1 day is reasonable enough) starting from absolutely 0 knowledge about the packaging system (if you don't count knowing to emerge package as knowledge).

What is done properly in the portage system is the fact that there are some default classes which your ebuild can inherit to behave more like a certain type of packages (base - a generic recipe, gnome, kde, games, sourceforge - they download tarballs directly, if needed - ...)

Why this is not possible for deb right now? Simple, we have it as a rule in the policy that the debian/rules file is a makefile. So even if one would implement a class-like model for deb packages, you'd still have the debian/rules file as a make file...

Gentoo implemented initially portage's default behaviour (and as a consequence, the "classes") in shell, later they migrated some parts to python and the whole portage is implemented in python now (while classes are implemented in bash). I am not saying that we should put python in essential, God forbid, probably the emdebian guys would stab me :-), I am saying that possibilities exist, alternatives should be possible.

I know, some will just say "show me the code", "making such a change over the entire archive is insane" or "the makefile is a really good way to do things like installing and building, after all, that's what it was designed for". Yes, all of these will miss the point, which is having nothing-to-do as a default policy for a package is a bad policy, it should be an empty/default package will use a standard recipe to build itself, and that recipe should be implemented in the build system.


And if you still don't believe me, just look at these few ebuilds and tell me you'd not be able to write them after a quarter after seeing one the first time and skimming over the docs or/and knowing what a regular gentoo user knows (what a keyword is, what is a slot). Also compare with the debian counter parts and don't forget the different building aids that we have.

http://sources.gentoo.org/viewcvs.py/gentoo-x86/games-arcade/amphetamine/amphetamine-0.8.10.ebuild?view=markup
http://svn.debian.org/wsvn/pkg-games/packages/trunk/amphetamine/debian/rules?op=file&rev=0&sc=0
http://svn.debian.org/wsvn/pkg-games/packages/trunk/amphetamine/debian/control?op=file&rev=0&sc=0
http://svn.debian.org/wsvn/pkg-games/packages/trunk/amphetamine/debian/postinst?op=file&rev=0&sc=0

http://sources.gentoo.org/viewcvs.py/gentoo-x86/games-arcade/holotz-castle/holotz-castle-1.3.8.ebuild?rev=1.3&view=markup
http://svn.debian.org/wsvn/pkg-games/packages/trunk/holotz-castle/debian/rules?op=file&rev=0&sc=0
http://svn.debian.org/wsvn/pkg-games/packages/trunk/holotz-castle/debian/control?op=file&rev=0&sc=0


http://sources.gentoo.org/viewcvs.py/gentoo-x86/games-arcade/late/late-0.1.0.ebuild?rev=1.10&view=markup
http://svn.debian.org/wsvn/pkg-games/packages/trunk/late/debian/rules?op=file&rev=0&sc=0
http://svn.debian.org/wsvn/pkg-games/packages/trunk/late/debian/postinst?op=file&rev=0&sc=0
http://svn.debian.org/wsvn/pkg-games/packages/trunk/late/debian/postrm?op=file&rev=0&sc=0


http://sources.gentoo.org/viewcvs.py/gentoo-x86/games-arcade/ppracer/ppracer-0.3.1.ebuild?rev=1.15&view=markup
http://svn.debian.org/wsvn/pkg-games/packages/trunk/ppracer/debian/rules?op=file&rev=0&sc=0


One more thing, the ebuilds mostly need not be updated when an upstream release occurs, they just need to be copied and given a different filename.

Erich Schubert: On initscripts

I was the maintainer of minit for some time, and spent some time adding some runit-like functionality to minit I then called "enitdir". It worked similar to runit (IIRC, maybe it was a different init). Basically you had a directory for each runlevel, which contained symlinks to all services supposed to be running. There is a symlink called "current" or something pointing to the current runlevel. enitdir monitored this symlink and the directories contents via dnotify, so it supposedly was both very fast and efficient at noticing changes there. Switching runlevels was as easy as "ln -snf current foobar"; starting and stopping services worked by removing the symlinks in the current runlevel or manually calling minit (for non-persistent changes, restarts, etc.) (I think I never uploaded a package with any of this, the minit packages remained really close to upstream. I intended to do a fork/rewrite named enit, but never got around to it. Many of my ideas are addressed by upstart.) However this didn't solve some integration issues. First of all, not all packages back then were using invoke-rc.d; this should be a lot better nowadays. But the major issues lie within handling multiple inits on one system. There is a hook that applications could use to prevent init scripts from running (which might be the answer to Wouters iniscripts post). It's called "policy-rc.d". However there are some things wrong with this approach: it doesn't really support the installation of multiple inits or handles the problems of switching between inits in any way. Basically, the moment we need to switch inits (and thus service startup/stopping behaviour!) is during reboot. While the old init is still running, any start/stop operations MUST still use the method appropriate for the current init system. Otherwise, major bugs can occur, especially with smarter init systems that respawn services. E.g. the user runs "apt-get install sysvinit mysql-server". Lets assume sysvinit has a debconf prompt 'make me the default init' and the user says yes. Next mysql-server is upgraded, during which it calls the sysvinit way of stopping the service (i.e. /etc/init.d/mysql-sever stop), then does some dangerous things to the database, then restarts the server. However, a smart init such as minit (when equipped with appropriate service files) will notice the mysql-server process dying and immediately restart it (notified by kernel, efficient and fast) while the upgrade script is still messing with the database files. Boom, there goes your database. I guess you got the point. So we probably need a smarter invoke-rc.d script. It should support Such an invoke tool could then for example look like this: 
if [ -e "/etc/enit/service/$1" ]; then
    enitctl start $1
else
    /etc/init.d/$1 start
fi
You get the idea, having the policy script figure handle compability for services that don't have an appropriate service description for this init system yet. (Yes, s/start/$2/ or something, above is pretty dumb, but helps bringing my idea over).

13 March 2007

Erich Schubert: Debian contribution portal

In a short mail exchange with Kevin Mark, he coined the term "contribute.debian.net" (or .org). I really like this name, and the idea behind it: Similar to packages.qa.debian.org/packagename, we create a platform trying to encourage people to contribute to Debian. Stuff that should be listed here includes: Other views include the canonical translation views (DDTP/DDTSS) or the current TODO page (which is not very widely known, I think, and probably not updated very often either) and such tools, of course. Again, similar to packages.qa.debian.org, but with a focus on non-DD-contributors.

Erich Schubert: Epiphany love

My favourite browser, epiphany, is installable in a new version from experimental. One of my biggest wishes was added: By middle clicking on the "new tab" button, you can open the URL in your pastebuffer in a new tab. Much nicer than making a new tab, killing the location bar contents without losing the copy buffer and pasting the new URL, isn't it? And actual a very canonical behaviour.

12 March 2007

Evan Prodromou: 20 Vent se CCXV

Another good day at South by Southwest. I had the night out last night, so I stopped at the Frogdesign Party for a while to see people and have some beers. I left to try to see Douglas Coupland's new movie, Everything's Gone Green. As a speaker I got a "gold" pass, which means I get to go see some of the films in the festival, but by the time I got to the theatre, it was at capacity. Too bad! Over to Club de Ville to see old friend Ben Cerveny, then trying to catch up with Niko, then an early night getting home. This morning I went to see Identity Woman (Kaliya Hamlin) talk about OpenID at the identity panel. It was a good discussion about identity and privacy, and I also got to meet Scott Kveton in person, too. Mike Linksvayer was there too, which was nice; it's great catching up with such a sympatico person. This afternoon I watched the incredibly valuable Everything You Always Wanted to Know About the Mobile Web...but Were Afraid to Ask. Great practical information for people willing to give mobile a try. I came away enthused and ready to make wikitravel.mobi a reality. Best of all was seeing Ben on his panel about virtual identity and avatars. Ben's got a talent for identifying the most intellectually stimulating thread in a conversation and following it with gusto, so it was really cool to see him talk on stage. tags:

La Traviata We stopped in for dinner at La Traviata, an Italian restaurant on Congress that Maj had heard good things about. The menu was nice but not too friendly to us pescevegetarians; we were excited when we heard that there was a seafood special that night. But the waiter came back to tell us that they weren't available. After we ordered, I heard the waitress behind me saying to her very big table, "...and we have two plates of the mahi-mahi available..." I stopped our waiter when he came by, and he was sheepish. "The chef was keeping those two plates for this big party." Oh. Our food was great -- I had a mushroom fettuccine, Maj had a grilled salmon with greens -- and we forgot about it. But the waiter came out later and said, "I talked about it with the chef and we want to extend our apologies. We should offer the specials to every customer equally. The chef wants to offer you dessert on the house." OK, sounds good. It doesn't take much to make up for a mistake, especially in the restaurant industry. La Traviata had good food, a really nice building, and great service up until then, but going that extra mile to make up for a mistake -- a debatable mistake I probably would have never thought about again -- gained my trust. More restaurants -- no, more businesses -- should have service like that. tags:

Blog review roundup I wanted to quickly shout-out to people who mentioned my talk at SXSW (Talks/SXSW07) in their blogs: I'm really glad to see so much positive response to the talk. I worked really hard on it, and the subject is obviously very dear to my heart. It's great when your work pays off and people appreciate it. tags:

Wiki BOF We're having a Wiki BOF lunch tomorrow at the 4th-floor coffee lounge. It should be fun. Thanks for announcing it, Liz! tags:

11 March 2007

Daniel Stone: sigh. just, sigh.

On behalf of the rest of Planet Ubuntu, I'd like to apologise for Stephan Hermann. Most everyone else there isn't half as obnoxious, so please ignore that entry.

Erich Schubert: SELinux policy customization

Russel Coker explained how to generate a local policy module from the error log. Note that this approach (audit2allow) suffers from the same problems that automatic policy learning suffers from (at least when not done very smartly). The generated policy will exactly cover the behaviour you had during logging; functionality that you didn't use is not covered, but misbehaviour that occured during this time is. Thats basically why SELinux doesn't use this autolearning approach considered a "benefit" of AppArmor by some (as you've just seen, you can do that with SELinux, too). So let me show you an alternate way: First of all, install the refpolicy-*-dev (from my experimental repository on alioth) or selinux-policy-refpolicy-dev (unstable) packages. Next you'll need an audit error to fix, e.g.: 
audit(1173577161.426:3436296): avc:  denied    search   for  pid=23862 comm="amavisd-new" name="lib" dev=md2 ino=63745 scontext=system_u:system_r:amavis_t tcontext=system_u:object_r:var_lib_t tclass=dir
So that obviously is amavis trying to access /var/lib (you can verify this by checking that ino= is the inode number of this directory). Looking at /var/lib/amavis reveals that these files are labeled amavis_var_lib_t, so the amavis policy is lacking just this simple tweak. While Russel's approach would work fine, I'll try to show how this would be fixed in the actual policy. The approach I use is documented somewhat in the README.Debian at least in my packages. I'll create a file named amavisfix.te: 
policy_module(amavisfix,1.0.0);
require  
        type amavis_t;
 
files_list_var_lib( amavis_t )
The name "files_list_var_lib" was looked up in the Refpolicy API documentation. Granted, it takes some time to get used to their naming scheme, but it's actually quite consistent. Now I run 
make -f /usr/share/selinux/refpolicy-strict/include/Makefile
and it creates a compiled module, amavisfix.pp, for me that I can install with "semodule -i amavisfix.pp". The audit error should now be gone, and amavis should function. I can now file a bug report with upstream that the amavis policy is lacking "files_list_var_lib( amavis_t )" and they'll be happy to add that. :-) Note that "files_list_var_lib" has an actual semantic meaning what the process is being granted; audit2allow lines are just technical representations of the access violations seen. Some of the more advanced SELinux IDEs might be able to suggest you appropriate interfaces by looking at the audit errors; I havn't tried them yet.

9 March 2007

Edd Dumbill: My preview of the O'Reilly Emerging Technology Conference 2007

I was honoured to be on the ETech 07 programme committee. Alas, I can't get there this year due to the very enjoyable reason of recent parenthood. Nevertheless, here are some of the talks I'd earmarked to attend.
Creating Addictive User Experiences (Kathy Sierra)Is it possible to say too many good things about Kathy Sierra? Any project or product built with attention to her advice about empowering users gets a huge head start to popularity and success. I was fortunate enough to spend a day with Kathy last year on a training course, and it was great to see the passion and commitment from her writing runs through her as a person, even behind the scenes.Applied Web Heresies (Avi Bryant)I'd go to this one out of insatiable curiosity. I believe that web conventions enable rapid application design (c.f. REST in Rails) but here's an argument that not following them also reaps rewards. Attend this talk prepared for involvement. I've never met a Squeaker without attitude.
Making Offline Web Applications a Reality (Zimbra)A short product talk, but taking web apps offline is an area to watch. Even if you don't think offline is that important to you, many of the same principles apply to application mobility. Take that key app data off onto your phone, watch or memory stick.Collective Intelligence, Indeterminacy, and the Illusion of Control (Charles Armstrong)More user-facing stuff. How do you give a user of a large nondeterministic piece of social software the idea that they're in control? This is an important topic to me: note how many pieces of social software fall by the wayside right away. For some, it's lack of utility, but that's influenced too by the degree of engagement and control a user feels.
No Program Left Behind: Liberating TV from the Tyranny of the Ephemeral (Tom Loosemore)There is no good reason not to listen to Tom Loosemore. Especially when he feels strongly about something. The idea of this talk is a "vision of a cheap consumer device sitting under your TV that will capture, store, and share all TV, forever." The TV industry sure needs its visionaries.
Patterns: From Fabrics to Fabrication (Dale Dougherty)Dale was responsible for getting my XML career off the ground, and you can find him at work behind some of the smartest things O'Reilly's done over the years. Make magazine was one of those, and now he's moving on to Craft. Design patterns for, er, real designs.RFID Guardian: A Personal Platform for RFID Privacy Management (Melanie Rieback)
Jamming bad RFIDs. Having just taken delivery of an RFID-enabled passport, this is starting to come home to me.Super Ninja Privacy Techniques for Web App Developers (Marc Hedlund)Despite the cute title, lots of good stuff here. Expectnation is going to end up with a truck load of user registrations, and their privacy is important to me. I imagine there'll be some good debate in the Q&A session for this talk.JavaScript: It's Happening All Over Again! (James A. Duncan)I've recently got the JS bug, thanks to JQuery. It's actually a fun and malleable language to work in. I'd go to this talk looking for fellow travellers and hints, though I'm a bit skeptical about Zimki itself.

8 March 2007

Junichi Uekawa: cowdancer bug 413912.

It was a bit tough. The question is about 'what file descriptor is safe to use for cowdancer?'.cowdancer is a preloaded library, and will be loaded with all applications under cowdancer control.The answer to this question will depend on the application behavior. The obviously wrong fds to use are 0, 1, and 2 which are standard input/output file descriptors,and people assume many things about them, and that was why 'screen' ./configure script failed to function within cowdancer.Using file descriptor 3 might feel safe, but applications are free to assume 3 is usable and issue, dup2 or close instructions on it.Hmmm...

7 March 2007

Eddy Petri&#537;or: The game Oolite was liberated

Yet another liberated game: Oolite, a clone of Elite.

I am the maintainer of the package; it was introduced as a non-free game in Debian, but a week ago upstream has announced that the game is now relicensed with a dual model licensing with GPL and cc-nc-sa 2.0 (the old license). Also, the change applies retroactively to the 1.65 release while further releases will be licensed GPL only and GPL/cc-nc-sa 3.0 for the code and data, respectively.

I have prepared the packages (oolite 1.65-5 and oolite-data 1.65-2) and Simon Richter agreed to make the honorary upload :-) tomorrow morning.

I hope he doesn't forget to build the packages by passing the '-sa' parameter to dpkg-buildpackage :-) and that these packages will reach Etch just in time for release.


As a bonus to this change, the game will be autobuilt on amd64, too.

(BTW, why isn't there any amd64 buildd in the non-free buildd network? Any technical reason?)

Update: the amd64 build seems that was behind in January when I installed the game on my new laptop. 1.65-4 seems that has been built a month ago, much later than the other arches.

Update: It seems that the package is on a positive trend on popularity: a constant rise in the number of oolite package installations is visible...

6 March 2007

John Goerzen: Re-Examining Darcs & Mercurial

I recently wrote an article or two about distributed version control systems.

I've been using Darcs since 2005. I switched to Darcs, in fact, 10 days after the simultaneous founding announcements of git and Mercurial.

Overall, I have been happy. I continue to believe that it is the most distributed of the distributed VCSs, which is a Good Thing.

However, I have lately started having trouble with Darcs hanging while working on my Debian packages. My post to the Darcs user list drew out a few other people whith this problem, which is a design flaw of Darcs.

So I revisited the VCS landscape. I re-examined git, Mercurial, and bzr. I eventually decided to give Mercurial a try. I avoided git because I write some code that is portable to Windows, and git isn't (or isn't very well). Also, git is complex to pick up for me, and I certainly don't want to force something complex onto my contributors. bzr seemed to still have some strange behaviors that it's had for awhile, and I couldn't find even one advantage of it over Mercurial. So off I went with Mercurial.

I quickly learned a bit of a philosophical difference from Darcs to Mercurial.

Darcs avoids conflicts at all costs. Mercurial makes handling conflict easy and, in many cases, automatic.

It is exactly this Darcs behavior that permits both is excellent "darcs send" feature (still unmatched in any other VCS), but also causes its hang problems.

I found Mercurial quite pleasant to work with, and *fast*. It seems to be edging out git in speed tests sometimes these days.

It is easy to get started with Mercurial. The mq system -- similar to quilt or other patch-management programs -- is really quite an amazing hybrid between patch management and version control. I frankly don't see any need for other patch-management tools anymore.

Mercurial has a "patchbomb" feature where you can select a range of changesets to send off, and it will generate nice emails with one changeset per email, and send them to your selected destination, optionally with an introductory message. The normal way of interacting with other Mercurial users is via the hg export/import commands, which send around simple unified diffs plus some additional header information, optionally in the git extended diff format.

I am happy with Mercurial and am in the process of converting my Debian repositories from Darcs to Mercurial. I'm going to keep my personal code in Darcs for the moment because "darcs send" is still easier than "hg email", but that may change before long, depending on how my experience goes.

I'd encourage others to give Mercurial a try. The community is also very nice and helpful.

I have contributed patches to Tailor to make it make exact copies of Darcs repos into Mercurial, which are now in its Darcs repo. There is also a thread on the Mercurial list with some of my initial questions/concerns coming from a Darcs perspective.

Edd Dumbill: Using sparklines to aid conference proposal selection

In a recent article I explained some of the mechanics behind putting together the schedule for XTech 2007. We've just added new visualization features to Expectnation that make proposal choice easier, and I thought I'd show some examples from the XTech 2007 review voting. Sparklines, devised by Edward Tufte, are thumbnail sketches of data that succinctly convey patterns. When Nat Torkington used sparklines to show reviewer voting patterns for OSCON program committee, it seemed a helpful addition to make to Expectnation. The profile of each reviewer is interesting — are they a harsh marker, or liberal with the top grades? — but sparklines really come into their own when drawn per proposal. Here are some small screenshots from this year's XTech voting, anonymized of course.
High flyers High scoring chart Reviewers are pretty unanimous about this proposal, as 4.0 is the top grade in our scoring system. The lack of variance suggests that I ought to ensure that all the assigned reviewers put in their scores — this could be just one person voting.  High scoring chart High scoring chart These next two are the pretty typical distribution for highly graded proposals: mostly top marks and a few average ones.  Middle rankingSome of the more interesting trends show up when the scoring isn't biased to either the top or bottom ends of the scale.  Medium scoring chartThe reviewers are unanimous about this paper's soundness. It's not made anyone go "wow", but there's nothing to grumble about either.  Medium scoring chartThis proposal clearly polarises opinion, and is such stands a better chance than the unanimous 3.0 above. Perhaps the subject matter or approach is controversial or timely.
Medium scoring chartAnother proposal that divides the reviewers' opinions. It's also worth me checking here that I don't either have a pathologically strict reviewer, or at the other end, a reviewer with a wild passion for the cause this paper advocates.  Low scoring The quality of submissions is usually so good that I don't give low graded proposals much attention, but the sparklines could alert me to potential oversights. Low scoring chartThis proposal seems to polarise opinion between "rubbish" and "ok", so it's interesting to me to check out the subject matter and see if I'm missing something with potential.  Low scoring chart Low scoring chart These proposals were not received at all well.In summary, I'm delighted to find a solid practical application for sparklines. My thanks to Nat Torkington for the inspiration. 

Next.

Previous.