Finally after fixing a lot of code (errors caused specially because of the different behaviour used on shell scripts) here are some of the first outputs generated by the scripts.

This post should give a better idea of how DeBaBaReTools work.

---

Test packages:

• kcheckgmail (one for etch an other for sarge; with an accidental duplicate .orig in the .dsc files)
  
• zend-framework
  
• php-htscanner
  

$ ls /home/raphael/Deb/repository/pub/UploadQueue/
kcheckgmail_0.5.7.2-0+etch1.diff.gz php5-htscanner_0.8.1-1_i386.deb
kcheckgmail_0.5.7.2-0+etch1.dsc php-htscanner_0.8.1-1.diff.gz
kcheckgmail_0.5.7.2-0+etch1_i386.changes php-htscanner_0.8.1-1.dsc
kcheckgmail_0.5.7.2-0+etch1_i386.deb php-htscanner_0.8.1-1_i386.changes
kcheckgmail_0.5.7.2-0+etch1_source.changes php-htscanner_0.8.1-1_source.changes
kcheckgmail_0.5.7.2-0+sarge1.diff.gz php-htscanner_0.8.1.orig.tar.gz
kcheckgmail_0.5.7.2-0+sarge1.dsc zend-framework_1.0.2-1.diff.gz
kcheckgmail_0.5.7.2-0+sarge1_i386.changes zend-framework_1.0.2-1.dsc
kcheckgmail_0.5.7.2-0+sarge1_i386.deb zend-framework_1.0.2-1_source.changes
kcheckgmail_0.5.7.2-0+sarge1_source.changes zend-framework_1.0.2.orig.tar.gz
kcheckgmail_0.5.7.2.orig.tar.gz

I've included the already built binary packages (built by a previous, functional, version of wannaBuild) because I'm recreating my repository from scratch.

So let's run processIncoming:

$ DEBUG=1 EXTRA_PROBE_DIRS=$PWD/backends VERBOSE=1 ./processIncoming 2> /tmp/log
processIncoming v0.1 started.
Processing /home/raphael/Deb/repository/pub/UploadQueue/php-htscanner_0.8.1-1_i386.changes...
Processing /home/raphael/Deb/repository/pub/UploadQueue/zend-framework_1.0.2-1_source.changes...
Processing /home/raphael/Deb/repository/pub/UploadQueue/kcheckgmail_0.5.7.2-0+sarge1_i386.changes...
Processing /home/raphael/Deb/repository/pub/UploadQueue/php-htscanner_0.8.1-1_source.changes...
Processing /home/raphael/Deb/repository/pub/UploadQueue/kcheckgmail_0.5.7.2-0+sarge1_source.changes...
Processing /home/raphael/Deb/repository/pub/UploadQueue/kcheckgmail_0.5.7.2-0+etch1_source.changes...
Processing /home/raphael/Deb/repository/pub/UploadQueue/kcheckgmail_0.5.7.2-0+etch1_i386.changes...
mv'ing "/home/raphael/Deb/repository/pub/UploadQueue/kcheckgmail_0.5.7.2-0+etch1.diff.gz" to "/home/raphael/Deb/repository/incoming/accepted/"
mv'ing "/home/raphael/Deb/repository/pub/UploadQueue/kcheckgmail_0.5.7.2-0+etch1.dsc" to "/home/raphael/Deb/repository/incoming/accepted/"
mv'ing "/home/raphael/Deb/repository/pub/UploadQueue/kcheckgmail_0.5.7.2-0+etch1_i386.changes" to "/home/raphael/Deb/repository/incoming/accepted/"
mv'ing "/home/raphael/Deb/repository/pub/UploadQueue/kcheckgmail_0.5.7.2-0+etch1_i386.deb" to "/home/raphael/Deb/repository/incoming/accepted/"
mv'ing "/home/raphael/Deb/repository/pub/UploadQueue/kcheckgmail_0.5.7.2-0+etch1_source.changes" to "/home/raphael/Deb/repository/incoming/accepted/"
mv'ing "/home/raphael/Deb/repository/pub/UploadQueue/kcheckgmail_0.5.7.2-0+sarge1.diff.gz" to "/home/raphael/Deb/repository/incoming/accepted/"
mv'ing "/home/raphael/Deb/repository/pub/UploadQueue/kcheckgmail_0.5.7.2-0+sarge1.dsc" to "/home/raphael/Deb/repository/incoming/accepted/"
mv'ing "/home/raphael/Deb/repository/pub/UploadQueue/kcheckgmail_0.5.7.2-0+sarge1_i386.changes" to "/home/raphael/Deb/repository/incoming/accepted/"
mv'ing "/home/raphael/Deb/repository/pub/UploadQueue/kcheckgmail_0.5.7.2-0+sarge1_i386.deb" to "/home/raphael/Deb/repository/incoming/accepted/"
mv'ing "/home/raphael/Deb/repository/pub/UploadQueue/kcheckgmail_0.5.7.2-0+sarge1_source.changes" to "/home/raphael/Deb/repository/incoming/accepted/"
mv'ing "/home/raphael/Deb/repository/pub/UploadQueue/kcheckgmail_0.5.7.2.orig.tar.gz" to "/home/raphael/Deb/repository/incoming/accepted/"
mv'ing "/home/raphael/Deb/repository/pub/UploadQueue/php5-htscanner_0.8.1-1_i386.deb" to "/home/raphael/Deb/repository/incoming/accepted/"
mv'ing "/home/raphael/Deb/repository/pub/UploadQueue/php-htscanner_0.8.1-1.diff.gz" to "/home/raphael/Deb/repository/incoming/accepted/"
mv'ing "/home/raphael/Deb/repository/pub/UploadQueue/php-htscanner_0.8.1-1.dsc" to "/home/raphael/Deb/repository/incoming/accepted/"
mv'ing "/home/raphael/Deb/repository/pub/UploadQueue/php-htscanner_0.8.1-1_i386.changes" to "/home/raphael/Deb/repository/incoming/accepted/"
mv'ing "/home/raphael/Deb/repository/pub/UploadQueue/php-htscanner_0.8.1-1_source.changes" to "/home/raphael/Deb/repository/incoming/accepted/"
mv'ing "/home/raphael/Deb/repository/pub/UploadQueue/php-htscanner_0.8.1.orig.tar.gz" to "/home/raphael/Deb/repository/incoming/accepted/"
mv'ing "/home/raphael/Deb/repository/pub/UploadQueue/zend-framework_1.0.2-1.diff.gz" to "/home/raphael/Deb/repository/incoming/accepted/"
mv'ing "/home/raphael/Deb/repository/pub/UploadQueue/zend-framework_1.0.2-1.dsc" to "/home/raphael/Deb/repository/incoming/accepted/"
mv'ing "/home/raphael/Deb/repository/pub/UploadQueue/zend-framework_1.0.2-1_source.changes" to "/home/raphael/Deb/repository/incoming/accepted/"
mv'ing "/home/raphael/Deb/repository/pub/UploadQueue/zend-framework_1.0.2.orig.tar.gz" to "/home/raphael/Deb/repository/incoming/accepted/"

The DEBUG=1 var makes the scripts (it works on all the scripts of DeBaBaReTools) set -x.

$ cat /tmp/log wc -l
2542

:)

Now, let's see what happens when an unsigned file is in the upload queue.
For this I've copied zend-framework_1.0.2-1_source.changes again to UploadQueue and stripped the signature information (note that it is only the .changes file):

$ DEBUG=1 EXTRA_PROBE_DIRS=$PWD/backends VERBOSE=1 ./processIncoming 2> /tmp/log
processIncoming v0.1 started.
Processing /home/raphael/Deb/repository/pub/UploadQueue/zend-framework_1.0.2-1_source.changes...
gpgv: no valid OpenPGP data found.
gpgv: the signature could not be verified.
Please remember that the signature file (.sig or .asc)
should be the first file given on the command line.
mv'ing "/home/raphael/Deb/repository/pub/UploadQueue/zend-framework_1.0.2-1_source.changes" to "/home/raphael/Deb/repository/incoming/rejected/"
processIncoming v0.1 stopped.

$ wc -l < /tmp/log
374

$ ls /home/raphael/Deb/repository/incoming/rejected
zend-framework_1.0.2-1_source.changes

Nice :D

So, let's continue with needsBuild:

$ DEBUG=1 EXTRA_PROBE_DIRS=$PWD/backends VERBOSE=1 ./needsBuild 2> /tmp/log
needsBuild v0.2 started.
Architectures: i386 amd64 all
Now processing /home/raphael/Deb/repository/incoming/accepted/kcheckgmail_0.5.7.2-0+etch1_i386.changes
mv'ing "/home/raphael/Deb/repository/incoming/accepted/kcheckgmail_0.5.7.2-0+etch1_i386.deb" to "/home/raphael/Deb/repository/incoming"
mv'ing "/home/raphael/Deb/repository/incoming/accepted/kcheckgmail_0.5.7.2-0+etch1_i386.changes" to "/home/raphael/Deb/repository/incoming"
Now processing /home/raphael/Deb/repository/incoming/accepted/kcheckgmail_0.5.7.2-0+etch1_source.changes
NOT Adding kcheckgmail to be built in i386 for the etch distribution (already listed)
Adding kcheckgmail to be built in amd64 for the etch distribution
mv'ing "/home/raphael/Deb/repository/incoming/accepted/kcheckgmail_0.5.7.2-0+etch1.dsc" to "/home/raphael/Deb/repository/incoming"
mv'ing "/home/raphael/Deb/repository/incoming/accepted/kcheckgmail_0.5.7.2.orig.tar.gz" to "/home/raphael/Deb/repository/incoming"
mv'ing "/home/raphael/Deb/repository/incoming/accepted/kcheckgmail_0.5.7.2-0+etch1.diff.gz" to "/home/raphael/Deb/repository/incoming"
mv'ing "/home/raphael/Deb/repository/incoming/accepted/kcheckgmail_0.5.7.2-0+etch1_source.changes" to "/home/raphael/Deb/repository/incoming"
Now processing /home/raphael/Deb/repository/incoming/accepted/kcheckgmail_0.5.7.2-0+sarge1_i386.changes
mv'ing "/home/raphael/Deb/repository/incoming/accepted/kcheckgmail_0.5.7.2-0+sarge1_i386.deb" to "/home/raphael/Deb/repository/incoming"
mv'ing "/home/raphael/Deb/repository/incoming/accepted/kcheckgmail_0.5.7.2-0+sarge1_i386.changes" to "/home/raphael/Deb/repository/incoming"
Now processing /home/raphael/Deb/repository/incoming/accepted/kcheckgmail_0.5.7.2-0+sarge1_source.changes
NOT Adding kcheckgmail to be built in i386 for the sarge distribution (already listed)
Adding kcheckgmail to be built in amd64 for the sarge distribution
mv'ing "/home/raphael/Deb/repository/incoming/accepted/kcheckgmail_0.5.7.2-0+sarge1.dsc" to "/home/raphael/Deb/repository/incoming"
mv'ing "/home/raphael/Deb/repository/incoming/accepted/kcheckgmail_0.5.7.2-0+sarge1.diff.gz" to "/home/raphael/Deb/repository/incoming"
mv'ing "/home/raphael/Deb/repository/incoming/accepted/kcheckgmail_0.5.7.2-0+sarge1_source.changes" to "/home/raphael/Deb/repository/incoming"
Now processing /home/raphael/Deb/repository/incoming/accepted/php-htscanner_0.8.1-1_i386.changes
mv'ing "/home/raphael/Deb/repository/incoming/accepted/php5-htscanner_0.8.1-1_i386.deb" to "/home/raphael/Deb/repository/incoming"
mv'ing "/home/raphael/Deb/repository/incoming/accepted/php-htscanner_0.8.1-1_i386.changes" to "/home/raphael/Deb/repository/incoming"
Now processing /home/raphael/Deb/repository/incoming/accepted/php-htscanner_0.8.1-1_source.changes
NOT Adding php-htscanner to be built in i386 for the sid distribution (already listed)
Adding php-htscanner to be built in amd64 for the sid distribution
mv'ing "/home/raphael/Deb/repository/incoming/accepted/php-htscanner_0.8.1-1.dsc" to "/home/raphael/Deb/repository/incoming"
mv'ing "/home/raphael/Deb/repository/incoming/accepted/php-htscanner_0.8.1.orig.tar.gz" to "/home/raphael/Deb/repository/incoming"
mv'ing "/home/raphael/Deb/repository/incoming/accepted/php-htscanner_0.8.1-1.diff.gz" to "/home/raphael/Deb/repository/incoming"
mv'ing "/home/raphael/Deb/repository/incoming/accepted/php-htscanner_0.8.1-1_source.changes" to "/home/raphael/Deb/repository/incoming"
Now processing /home/raphael/Deb/repository/incoming/accepted/zend-framework_1.0.2-1_source.changes
Adding zend-framework to be built in all for the sid distribution
mv'ing "/home/raphael/Deb/repository/incoming/accepted/zend-framework_1.0.2-1.dsc" to "/home/raphael/Deb/repository/incoming"
mv'ing "/home/raphael/Deb/repository/incoming/accepted/zend-framework_1.0.2.orig.tar.gz" to "/home/raphael/Deb/repository/incoming"
mv'ing "/home/raphael/Deb/repository/incoming/accepted/zend-framework_1.0.2-1.diff.gz" to "/home/raphael/Deb/repository/incoming"
mv'ing "/home/raphael/Deb/repository/incoming/accepted/zend-framework_1.0.2-1_source.changes" to "/home/raphael/Deb/repository/incoming"
needsBuild v0.2 stopped.

$ wc -l < /tmp/log
1983

And a quick look at sid's needsBuild list:

$ cat /home/raphael/Deb/repository/build/data/needsBuild.sid
php-htscanner_0.8.1-1 i386 built
php-htscanner_0.8.1-1 amd64 needsBuild
zend-framework_1.0.2-1 all needsBuild

So, next time processIncoming is run all those files will be installed in the repository :yes:

(of course, I first have to fix my reprepro setup :s)

These questions came in as comments this week, but I think they're worth a whole post. Peter Swan asked:

"This may seem like a dumb question, but I have not seen anywhere the answer to it. Can a satellite dish be mounted in a loft space or must it be mounted outside?"

There are few dumb questions. DIY dish info is still rather hard to find. You can install a dish behind a window and I've read about special tiles which allow satellite frequencies through on analoguesat's pages about hiding dishes but I don't know anyone using them. A more usual solution is either a hidden location such as a flat roof with baffle boards (dishes only need to see the Clarke belt, which is an elevation of about 20 degrees in England) or to use a non-dish antenna like the digiglobe or the LX2000 pipe. I think it's a really good idea to put the dish somewhere that you can fix it easily. Even the best dish seems to age eventually. I suspect some "professional" installers put the dishes at tops of walls to encourage repair call-outs. Marcus asked:

"Is it possible to receive British satellite television in other countries? I am living in Finland and I was considering purchasing a sky system from the UK and installing it over here. Would it work? Also would I be able to connect a sky set-top box to a different dish?"

Yes, you can get British TV in other countries. Getting external TV like BBC World is easy, but BBC UK services are on Astra 2D, which is focused on the UK. Coverage maps are available on many sites and it looks like Finland isn't well-covered. You'd need a colossal dish. You can connect Sky boxes to other dishes. Sky dishes and Sky LNBs need to go together, sometimes called Skyware, but dishes and boxes are interchangeable. A Sky system will work in Finland, but will only receive services on the other beams like 2A and I doubt Sky will register you at a non-UK address (anyone know for sure?). Also, Sky boxes are horribly crippled for anything other than Sky services and hopefully BBC Freesat will make BBC UK services easier-to-use with standard boxes.

On Friday 2007-11-02, I watched Larry Lessig give a presentation at the University of Washington entitled Is Google (2008) Microsoft (1998)? Since it was Lessig, the talk was articulate and thought-provoking, and he used his slides very well (unlike many presenters who just read bullet points).

The argument he made is that Google is like Microsoft in some ways (and so are other companies like Facebook). In his analysis, the problem with Microsoft was that so many companies made themselves Microsoft-dependent, which both forced other companies to follow suit (due to network effects) and gave Microsoft leverage they could use against everyone in their ecosystem (e.g., Netscape). According to Lessig, Microsoft was not evil to use this leverage, but you have to recognize that Microsoft will do what is best for Microsoft, and this may not be what is best for you. He then suggested that we should be aware of the potential for the same thing to happen; in support of this point, he quoted excerpts from the terms of service from the APIs of Google and Facebook, which contain typical statements like we reserve the right to terminate your use of this service for any reason or for no reason, and asked: What if Microsoft had written this license agreement?

But it seemed to me that this wasn't his main point. He was using this observation as a springboard to talk about issues revolving around competition and public policy. Specifically, he feels that we should work towards a more just model of interaction between companies and users whose work makes the company more valuable (by contributing to a software ecosystem, by posting content on the Web site, etc). But the correct way to do this (he says) is not via competition, after-the-fact litigation, or voluntary codes of conduct: competition may not be around to enforce good behavior (as we've seen with Microsoft), litigation may be too late and ineffective (again, see Microsoft), and voluntary codes of conduct will disappear as soon as they get in the way of the bottom line. The correct approach, he argued, is across-the-board regulation so that all the companies have to play by the same rules.

From there he went on to talk about governmental corruption. He said (quoting Robert Reich's book Supercapitalism) that the reason we consistently look for solutions in the market and in voluntary compliance is that our governmental system is broken and does not effectively regulate corporations in the public interest. But Lessig is optimistic that we can change things (he joked that his publisher was unhappy with this point of view, because his brand has been built on pessimism). In his view, the politicians in Washington, by and large, want to be honest and do good, but they aren't able to within the current political system. For instance, on the few occassions that he managed to get access to lawmakers to discuss copyright issues, it was often the first time they had heard that there was more than one side to the argument. He thinks we need a national political movement that will shame politicians into being less corrupt.

This is all a simplification of what he said, of course; unfortunately, I wasn't able to find a recording of this talk on Lessig's Web site, or I'd point you at primary source material. I don't know if this is because he chose not to post it, or because it just hasn't been made available yet.

My view

In general, I thought that the speech was very interesting and well thought out. But as much as I'd like to buy into his optimism that we can fix our system, I don't think it's well-founded, for two reasons.

First, he argued that competition will resolve some of these problems (that was before and after he said we can't rely on competition, which I found confusing and may indicate that I misunderstood something). His evidence for this seemed to be that when Microsoft was dominating the world, users responded by reducing their dependence on Microsoft products and by switching to alternatives such as Linux. But, in fact, although more people may be using Linux than in the past, virtually everyone is still only using Windows, it's still almost impossible to find a programming job that isn't Windows-only, and Microsoft is still raking in money hand over fist; indeed, they're doing so well that they're planning to expand their workforce by a third. To take just one data point of many: I ride the bus to Seattle and back, and I regularly see other people using laptops as they commute. Virtually all the laptops run Windows. Occasionally I'll see a Mac, and every few months I'll see a guy running Linux on his laptop; I say "a guy" because it's the same guy every single time. So by my estimation, use of Linux on laptops in buses on the 545 route from Redmond to Seattle is way below 1%, with Macintoshes somewhere around 5%.

To broaden my point, I think Lessig has fallen into a trap that highly intelligent people, particularly those in academia, tend to fall into. In academia, you are surrounded by people who value learning and thinking deeply about the world. These are people who will give serious and unbiased consideration to questions like what is the social effect of my acceptance of the Facebook Terms of Service? and If I become dependent on this service, will that possibly affect me in five years if the company decides to act against my interests? The problem with this is that these people are not representative of the population at large. The population at large thinks why is this check-box getting in the way of me sending pictures to my friends? And I have no doubt that any kid who, e.g., refuses to sign up for Facebook as a protest against their TOS will be roundly mocked in their social circles for being a weird antisocial nonconformist. (of course, this may not apply to the small minority of people like myself whose social circles consist of weird antisocial nonconformists)

Second, Lessig's optimism about the political system seemed to be based on his observation that the people in government are, by and large, not venally corrupt: they want to do good, but the system is constructed in a way that makes this impossible. To me, that's a tremendously disheartening statement. If our problem were simply a few, or even many, corrupt politicians, this would be a solvable problem: even nowadays, Americans have some ability to choose who gets elected, and I believe that a sufficiently well-coordinated campaign could replace bad politicians with good ones.

But if the problem is that the system is corrupt even when the individuals are honest, it's a much deeper problem and frankly one that I don't know how to solve. While individuals have some direct control over who gets elected, we have no way to directly change the system that produces the corruption; the levers to do this are in the hands of the politicians elected through that broken system. It's unlikely that the politicians themselves will fix the problem, because they've benefited deeply from it: if the system is left as it is, well over 90% of Congress members will keep
their jobs in the next election cycle, and any effective change seems likely (by definition) to disrupt this cushy arrangement.

On the other hand, running new candidates for office will not fix the problem. After all, if the problem is that the system is corrupt even when the participants are honest, then putting more honest people into government will have no effect. In order to get elected, these new politicians will have to become just as corrupt as the old ones, because that's how the system is set up. So we might change the faces, but we'll have the same old problems.

I recall two specific concrete proposals that Lessig made to make the system more responsive. First, he suggested shaming politicians who engage in corrupt behavior -- presumably taking large donations from interested parties. I don't see how this will help. Americans generally have a very low regard for the political class as it is; will pointing out particular examples of politicians taking money really make a difference when it comes to votes? And if it doesn't, will it really produce any change in their behavior? Politicians are motivated by votes the same way corporations are motivated by money; unless they stand a chance of losing their job (which is virtually impossible in any event), there's no reason for them to change how they behave.

His second proposal was for a system of contributions where it's impossible for any individual to prove they had donated a particular amount of money to a particular candidate. Even assuming it could be implemented perfectly, I don't think this will really solve the problem, for two reasons. First, it's not generally a secret what moneyed interests want. Politicians who want to attract large donations can just take positions that they know will appeal to donors of that sort. The donors themselves can make this easier on the candidates by, e.g., posting public position statements on issues of the day. Secondly, and this is far more insidious, even if politicians honestly represent their positions, then because success in running for office is so tied to the amount of money the candidate can raise, only candidates who hold opinions favorable to large corporations and wealthy individuals will be able to get elected. In fact, for all I know this is what happens already!

But with all that said, it was a really interesting talk and Lessig tied together some things you might not think would go together. If a video or Flash presentation becomes available, I would recommend watching through it. And hopefully my pessimistic predictions will be wrong; it's certainly happened before.

While bumbling about on a search engine, I found slides from a talk I gave in 2001 and these 2005 consultation submissions to the Department of Culture... about TV and the WSIS Civil Society Internet Governance Caucus Here's some other stuff on other sites I wrote about since the last round-up of this sort:

A Cambridge Co-operator: Sorry!

EASF :: View topic - What happened to Norwich Citywide Co-op?

Bond films and the Roger Moore humor controversy Ultimate James Bond Fan Blog

Does Having Fewer Rules Inspire Hard Work? etbe

The Right Width for Your Blog

The Right Width for Your Blog

Shine OpenStreetMap Cycle Map :: GravityStorm

Social mapping Tom Chance's website

Russ Nelson: Chordite versus CyKey

The prescient TomTom

robmyers - Bender's Big Score

Citing References in Blog Posts etbe

Matt Lee - Advogato Exploring Freedom

Ross Burton

Inside the Box Blog Archive Linux On a Mobile PC

Javascript performance in browsers

Bryan Clark : Web Browser Homepage

BBC SPORT Sport Editors' Blog Behind the Scenes at BBC Sport: Weekend feedback

][ stefano maffulli The end of a phase

A Cambridge Co-operator: Shoefayre / Cambridge City

(Persone) 12 25 Septembro 2007, 5:21

Buxy: DSA needs a leader

[10/30/2007]
Version 0.4.7                               "Where did all these
                                             balloons come from?
                                             And why am I wearing
                                             a fake nose?"

- New features:

  * The options dialogs have been completely replaced by a new
    interface, based on a top-level list view.  This fixes many
    deficiencies of the old interface: it handles long strings more
    gracefully, avoids many of the focus-handling bugs that the old
    dialogs had, and should generally be better-behaved.
     (Closes: #197976, #331200, #424708)

  * Prompts that ask you to enter text will now wrap to multiple lines
    when the text gets long, rather than hiding parts of the string.

  * The online help and other Help-menu itmes are now top-level views,
    which should make them somewhat more usable. (Closes: #434349)

  * Support for the "Breaks" field and for trigger states (thanks to
    Michael Vogt and Ian Jackson for patches and prodding).
    (Closes: #438543)

  * Two new styles, "PkgDowngraded" and "PkgDowngradedHighlighted",
    are provided to control how downgraded packages look.  By default
    these packages look like any other installed package.
    (Closes: #434442)

  * aptitude can now display homepage URLs stored in the Homepage
    field of packages.

There are bug-fixes too, but those aren't as fun. So instead I think I'll include some diffstat output. Everyone likes diffstat!

daniel@alpaca:~/programming/aptitude/head$ hg diff -r 0.4.6.1:0.4.7   diffstat
 .hgtags                                            1 
 NEWS                                              92 +
 b/src/apt_config_treeitems.cc                    477 ++++++
 b/src/apt_config_treeitems.h                     156 ++
 b/src/generic/util/browser.h                      42 
 configure.ac                                      20 
 doc/en/aptitude.xml                              187 ++
 help-fr.txt                                       10 
 po/ChangeLog                                      24 
 po/dz.po                                         188 +-
 po/es.po                                          82 -
 po/gl.po                                          19 
 po/ne.po                                        1277 +++++++++--------
 po/pt.po                                          20 
 po/ru.po                                          97 -
 po/sv.po                                        1854 ++++++++++++--------------
 po/zh_CN.po                                       23 
 src/Makefile.am                                    2 
 src/apt_info_tree.cc                               4 
 src/apt_options.cc                               598 +++++---
 src/apt_options.h                                 12 
 src/cmdline/cmdline_action.cc                      6 
 src/cmdline/cmdline_check_resolver.cc              2 
 src/cmdline/cmdline_do_action.cc                 134 +
 src/cmdline/cmdline_prompt.cc                    124 -
 src/cmdline/cmdline_search.cc                      4 
 src/cmdline/cmdline_show.cc                       20 
 src/cmdline/cmdline_why.cc                        64 
 src/defaults.cc                                    4 
 src/dep_item.cc                                    1 
 src/desc_parse.cc                                  2 
 src/generic/apt/apt.cc                            32 
 src/generic/apt/apt.h                             30 
 src/generic/apt/aptcache.cc                       54 
 src/generic/apt/aptcache.h                        21 
 src/generic/apt/aptitude_resolver_universe.cc     28 
 src/generic/apt/aptitude_resolver_universe.h      57 
 src/generic/apt/infer_reason.cc                   22 
 src/generic/apt/log.cc                             8 
 src/generic/apt/matchers.cc                      531 +++++--
 src/generic/apt/matchers.h                        28 
 src/load_grouppolicy.cc                           25 
 src/menu_tree.cc                                  12 
 src/pkg_columnizer.cc                             19 
 src/pkg_grouppolicy.cc                            27 
 src/pkg_grouppolicy.h                              9 
 src/pkg_info_screen.cc                            10 
 src/pkg_item.cc                                   31 
 src/pkg_item.h                                     7 
 src/pkg_subtree.cc                                22 
 src/pkg_subtree.h                                 12 
 src/pkg_tree.cc                                    4 
 src/pkg_tree.h                                     1 
 src/pkg_ver_item.cc                               31 
 src/pkg_ver_item.h                                 5 
 src/pkg_view.cc                                   24 
 src/reason_fragment.cc                            10 
 src/solution_fragment.cc                           5 
 src/solution_item.cc                              76 -
 src/solution_item.h                               14 
 src/ui.cc                                        179 +-
 src/vscreen/fragment.cc                          140 +
 src/vscreen/fragment.h                            40 
 src/vscreen/ref_ptr.h                              5 
 src/vscreen/testvscreen.cc                        20 
 src/vscreen/vs_editline.cc                       310 +++-
 src/vscreen/vs_editline.h                         33 
 src/vscreen/vs_tree.cc                           113 +
 src/vscreen/vs_tree.h                             40 
 src/vscreen/vs_treeitem.cc                         4 
 src/vscreen/vs_treeitem.h                         21 
 src/vscreen/vs_util.cc                             1 
 72 files changed, 4853 insertions(+), 2754 deletions(-)

Even though Adrian von Bidder suggests that I'm starting a bit early with the DPL campaigning, I thought I could add a few more thoughts to the blagosphere.

Adrian suggested to make the discussion of our of "vision of Debian" a regular event on debconf - I think it's a nice idea, but that doesn't mean we should keep silent about that topic the rest of the year. I think one of the problems we see in Debian is that we are missing an aim to strive for. We are currently just moving from release to release, while more and more developers have actually lost interest in stable releases. The impression that a common ground like Debian 4.0 is irrelevant seems to prevail, because the people most vocal in our user base usually want to see the newest and shiniest software on their desktop. We have been spending more and more effort to cater to their wishes and have ignored the fact that a majority of Debian-based installations are not run by such people, but by system administrators who do mass roll-outs and neither want nor need the newest X.org with more *bling*.

Ubuntu, the biggest Debian-based distribution, has found its users by packing up new software behind a nice installer, adding some branding elements and then shipping it. Stability is an issue for Ubuntu, but they don't spend as much time as we do on eliminating the last seemingly important bug in some esoteric software package before actually releasing. That observation is the ground for one of my ideas: Our current metric to determine how far testing is away from a release is counting the number of rc bugs - it doesn't matter if the rc bug is X.org crashing for all people or if it is a policy violation in a package with 12 users. Perhaps we should start thinking about a new metric, keeping in mind that for a majority of users, some bugs matter a lot and some matter not at all. With the release of etch, the number of installations of popcon has risen a lot, so for the first time, we have actual usage data that could help us with such a metric. There are a few problems with that approach, though:

• Popcon data is inherently wrong, because single computer installations tend to have popcon, while large installations (like the one in Extremadura) don't.
• A majority of popcon users uses the last stable release, not the one currently in development.
• 3 bugs in packages seldomly used can be more annoying for our users than one central bug - you might be able to find a work around somewhere for something that happens to a lot of people, but a bug only hitting a few users will stay unfixed for a long time.

I don't have more time right now, so the rest of my ideas will follow in the next few days, so stay tuned or add me to your killfile.

It's this time of the year again: The one where I look back at my involvement in the project and decide that I've been a member long enough, so I should probably get out. For Debian, there are two ways to do it: Either become MIA or become DPL. As I have too many real life connections to other DDs, I guess I can't really do the MIA thing, so I should probably get elected as DPL. Whenever I consider this way out, I think about all the issues that make me unhappy about Debian. This time, I've written them down. So, here's a list of things I would like to see and would work on if I had the power to do so:

• Enforce addition of new architectures to the main archive. This includes kfreebsd-* and hurd-* - after all, we claim to be the universal OS. I've sometimes heard that our ftp mirrors wouldn't be able to handle the increased archive size - I don't believe that. We had the mirror split to work around this, not everyone is forced to mirror all architectures anymore. If actual Debian hardware should be a problem, we should use the money we collect to get the hardware we need.


• Make backports.org official, just like volatile. This doesn't mean kicking out the current team and give the responsibility for bpo to the dysfunctional ftp-team, but simply move the service as it is into Debian. A start for that would be to add backports.debian.org as CNAME for backports.org and then add fitting hints to our release notes.


• Resurrect the practice of porting machines. In ancient times, Debian had all kinds of machines available to all developers so that they could log in and debug architecture-specific porting problems. Nowadays, Debian collects hardware, Debian's hardware collects dust and Debian's BTS collects porting bugs. At the moment, most of these machines are not available to the developer body and access is granted to only a handful of persons besides DSA.


• Fix the constitution, so that the ftp-team, the account managers, the buildd admins, the system administrators and all other teams that currently don't see themselves as delegates of the DPL can in some way be changed when they are not doing their job. There is currently a GR for that in preparation, see the excellent proposal from Josip Rodin for more information. When that is done, we can turn to actually fixing those teams, starting by giving full permissions to active people that currently have only restricted access (ie Joerg Jaspert should be able to modify the LDAP holding Debian's account data and should also get to act as full ftp-master, not only -assistant). There are also quite a few people experienced with the tasks of the other teams, so we should add some of these people soonish.


• [Not really depending on DPL super cow powers:] Work on half-releases, like etch + 1/2. Besides adding a newer kernel for hardware support and updating the installer, we could think about adding backports packages to update desktop stuff. Many people seem to be interested in that.

Besides those things that I really miss in Debian, there are also a few things I would simply like to see done in the near future:

• Add more buildd admins.


• Resolve our conflicts with the FSF, get them to accept that we don't like the GFDL and then go on with lobbying for free software.


• Improve our appearance on conferences by creating common Debian material. This means creating "official" ISO images for DVDs from time to time (just like they are done by people for a specific conference from time to time), creating official information material that can be translated by the l10n teams, discuss guidelines for the people behind the booth (like "Please don't wear a shirt which allows visitors to see what you've eaten in the last week") and give advice for presentations.


• Clean up the DD list, so that we stop telling people that there are ~1000 DDs if only ~600 actually work on Debian. Yes, work on that is already on the way.


• Create a place (a ML, wiki page, pseudo package) where Debian people can simply drop interesting ideas. Often, busy developers have great ideas for new projects, but lack the time to actually implement them. Usually, the inside knowledge is only needed to conceive the idea, not to implement it, so we should have a place where people with free time at their hands can find great ideas. It shouldn't be needed to actually describe every detail of your idea, it should be more like "Wouldn't it be cool to collect all left socks and then get to world domination by tying them together?". This could also be the basis for a bounty system (and of course for the GSoC people)


• dpkg development - symbol-based shlibs look almost ready, but what happened to Wig&Pen alias dpkg-source v2?


• At some point, we should discuss our vision of Debian. I guess we won't find a common one, but it would be interesting to see where people want to see Debian in 5 (or 10) years. Should we "just" be a supermarket so that CDDs and forks can be based on us? Should we work on reintegrating all those efforts into Debian proper? Is that even possible?


• We should create a team (or, preferably, a DPL delegate) whose sole task is to communicate with the rest of the Debian ecosystem, so that common problems can be noticed, discussed and solved. I have to admit that I have lost track and couldn't say how many distributions are using Debian as their basis nowadays, but there seem to be quite a lot. I wish for a place where I can find such information (or at least a person who I can ask about it).

So, what do you think? Are all of those ideas crap or should we perhaps try to implement them? Have I missed something important?

I have just read Career Development for Geeks [1] by Erik de Castro Lopo [2]. It makes some interesting points about a traditional approach to an IT career. The path I followed for most of my career (after I had a few years experience) was to work as a contractor and happily leave jobs without having anything else lined up. Erik suggests getting Engineers rather than managers to give references, it’s an interesting idea. Engineers can give better references about quality of work, while managers can speak on behalf of their employer (in theory). In practice a sane manager won’t give a bad review for legal reasons so the value of a reference from a manager is probably limited. Of course one problem with reviews is that I have never heard of a recruiting agent or employer actually verifying the ID of a reference. I could be listed on a friend’s CV as a senior manager in a multi-national company (which doesn’t have a major Australian presence) and give a good review and it seems unlikely that the typical recruiter would work it out. For someone with plenty of spare time and no significant assets (no risk of being sued) it could be entertaining to apply for a bunch of positions that they are not qualified for with friends using pre-paid mobile phones to give references. This could be done as a documentary on corporate hiring practices, or to simply try and get the highest paid job possible. Based on observing some former colleagues it seems that little skill is required to get a job and that when people do really badly they get paid for at least a few months. I am constantly amazed when reading reports about so-called “con artists” who commit crimes for what are often small amounts of money. Getting an income significantly greater than average without knowing anything about how to do the work is very common and is never treated as fraud (the classic example was a former colleague who wanted to write his own encryption algorithm but who didn’t even know about binary and therefore couldn’t use operations such as XOR). Erik’s main suggestion for dealing with recruiting agents is to talk about projet management issues (recruiters don’t understand technology). My way of dealing with them has been to assure them that I know it all and tell them to forward my CV to the client. Another suggestion is to learn new skills and diversify your skills. I don’t supoprt this because I believe that the majority of people who read my blog are significantly more skillful than the typical programmer. If an area of technology starts to go out of fashion then it’s the people with the least skills who suffer the most. If you are good at your work and enjoy it then it shouldn’t matter much if people around you are being laid off. Of course to rely on this you have to be working in a reasonably large field. For example if you develop software in a language which has hundreds of programmers then you may be at risk, but if there are tens of thousands of programmers using the language then you only need to be in the most skillful 10% to be assured of employment for the next decade or two. That said there are benefits to moving around, meeting new people, and working on new contracts. One thing you don’t want is to have 10 years of experience which are the same year repeated 10 times! Update: Here is a paper Erik submitted to OSDC on the same topic [3]. Mostly the advice is the same but with more detail and in a better format for reading.

• [1] http://www.mega-nerd.com/Career-dev/career-dev.pdf


• [2] http://www.mega-nerd.com/erikd/Blog


• [3] http://www.mega-nerd.com/erikd/cddg.pdf

Share This

Jonathan Schwartz: “[L]ater this week, we’re going to use our defensive portfolio to respond to Network Appliance, filing a comprehensive reciprocal suit. As a part of this suit, we are requesting a permanent injunction to remove all of their filer products from the marketplace, and are examining the original NFS license - on which Network Appliance was started. By opting to litigate vs. innovate, they are disrupting their customers and employees across the world. “In addition to seeking the removal of their products from the marketplace, we will be going after sizable monetary damages. And I am committing that Sun will donate half of those proceeds to the leading institutions promoting free software and patent reform (in specific, The Software Freedom Law Center and the Peer to Patent initiative), and to the legal defense of free software innovators. We will continue to fund the aggressive reexamination of spurious patents used against the community (which we’ve been doing behind the scenes on behalf of several open source innovators). Whatever’s left over will fuel a venture fund fostering innovation in the free software community.” Bravo.

Linux-hero wrote about how Ubuntu kills your hard drive. The situation is somewhat less clear than you might think from the article, but the basic takeaway message is that Ubuntu doesn't touch your hard drive power management settings by default. In almost all cases, it's more likely to be your BIOS or the firmware on your hard drive.

The script that's executed when you plug or unplug your laptop is /etc/acpi/power.sh. The relevant sections are:

function laptop_mode_enable  
...
    $HDPARM -S $SPINDOWN_TIME /dev/$drive 2>/dev/null
    $HDPARM -B 1 /dev/$drive 2>/dev/null
 

That is, when the laptop_mode_enable function is called, we set the drive power parameters. Now, by default laptop_mode_enable isn't called:

if [ x$ENABLE_LAPTOP_MODE = xtrue ]; then
    (sleep 5 && laptop_mode_enable)&
fi

because ENABLE_LAPTOP_MODE is false in the default install (check /etc/default/acpi-support). This means that, by default, we do not alter the hard drive power settings. In other words, the APM settings that your drive is using in Ubuntu are the ones that your BIOS programmed into it when the computer started. This is supported by the fact that people see this issue after resuming from suspend. We don't touch the hard drive settings at that point, so the only way it can occur is if your BIOS or drive default to this behaviour.

If you enable laptop mode, then we will enable aggressive power management on the drive and that may lead to some reduction in hard drive lifespan. That's a fairly inevitable consequence of laptop mode, since it only makes sense if the laptop enages in aggressive power management. But, as I said, that's not the default behaviour of Ubuntu.

There's certainly an argument that we should work around BIOSes, but in general our assumption has been that your hardware manufacturer has a better idea what your computer is capable of than we do. If a laptop manufacturer configures your drive to save power at the cost of life expectancy, then that's probably something you should ask your laptop manufacturer about.

Original post can be found here. Interview: Today we are interviewing Andrea Veri, fresh MOTU and eager Ubuntu volunteer. Age: 18
Location: Udine, Italy
IRC Nick: bluekuja How long have you used Linux and what was your first distro?
I started using Linux at the end of 2005 using Red Hat and Fedora distros, contributing on writing several pages for Fedora documentation (mostly server docs) but mainly working on some packaging-related activities (introducing ctorrent, gtorrent-viewer and v2strip packages inside Fedora) for more than 3 months until the beginning of March 2006 when I decided to move definitely to Ubuntu after discovering it at a friend s party. Was love at first sight that made me leaving every Fedora plan and project creating my first personal wiki page on wiki.ubuntu.com some days later. How long have you been using Ubuntu?
In fact, I started using Ubuntu at the beginning of 2006, firstly getting involved inside the Edubuntu family making real the possibility to have an Edubuntu Italian support and website area inside the current Italian LoCo Team. When did you get involved with the MOTU team and how?
Right after joining the Ubuntu brigade I started checking out MOTU documentation, mainly packaging guide plus debian new maintainer s guide, trying to understand every single new word and applying directly to a source package every lesson learned during developer s world travel . After getting introduced and fascinated from an active community, I had to left the project for a while for some small problems, restarting everything on May 2007 with my first sponsored upload inside the archive. My packaging passion increased right after meeting Alexander Sack inside #ubuntu-mozillateam irc channel some days later, deciding to work directly with him as my mentor for both Debian and Ubuntu distributions. What helped you learning packaging and learning how the Ubuntu teams work?
I started with Debian New Maintainer s guide and Ubuntu s packaging guide moving then to package my first applications learning from already-packaged software and asking if needed to Alexander improving and learning every time from him or from other developers a new Ubuntu Team lesson. Favorite part of working with MOTU?
Introducing a fix making tons of users happy is one of the best things I appreciate of being a MOTU. Mentoring, sponsoring, helping out new contributors or students is something special as well. Any advice for people wanting to help with MOTU?
I always suggest to start with a package a new contributor cares about personally, that s useful to improve/fix the package itself during its maintenance.
Reading MOTU and Debian documentation is a great starting point as well to avoid any strange question on our MOTU irc channel. What packages/areas of Universe are you most interested in?
I m currently working on a vast area of packages, but I ll try to focus on p2p (Peer-2-Peer) applications both for Universe and Main. I planned to create a MOTU-p2p team really soon including it inside the existing motu-torrent team, but it will take some months to organize everything up; contributors (testers/packagers) are currently missing. Any Plans for Hardy Heron?
I ll keep working on a large number of packages but as I said before I would like to focus on having an updated situation of p2p applications, introducing libtorrent-rasterbar and its related clients like btg or linkage. Creating a working team with interested contributors and developers will be the first step to work on. Favorite quote?

As for me, all I know is that I know nothing. Socrates

What do you do in your other spare time?
I love going around with my motorbike, listening good music, playing basketball and meeting up with friends around the city centre. Pic of you, your work area, and/or your screen?

I am a purist when it comes to food. A huge purist. And yesterday I ended up at Miller's Pizza on Upper Baggot Street, Ballsbridge, Dublin, Ireland, and I enjoyed a Thai Prawn Green Curry Pizza, while colleagues of mine were devouring Mexican Salsa on Pizza Dough and similarly "perverse-sounding" foods. Unfortunately, their menu behind the above link is out of date (someone should let them know ), but that should not stop anyone with an appreciation for eclectic food and an adventurous vein from stopping to eat at this place the next time you're in Dublin. NP: Devin Townsend: Ziltoid the Omniscient

I attended my first half-yearly meeting as a member of the co-operative group yesterday evening at 7pm. The event for the strangely-named Kennet and Avon area was held at Jury's Hotel near Queen Square, which is a part of Bristol I've not visited for a while, so I got there a bit early to find it. I found it easily, which gave me a few minutes spare to visit the co-operative food store on the Centre (pictured), which is the first rebranded one I've seen. It looks light and airy and the staff were friendly. I didn't find everything I was looking for, but after exiting, I noticed I'd not seen around the corner of the L-shaped store! Anyway, the meeting itself was chaired by Peter Begley and was attended by six elected reps, three regional officers, four trading managers (all food?) and about 50 members by my reckoning. There was a comment later in the meeting about the low turnout from Bath - it seems that a meeting for each city had been requested and refused. There was also a comment about lack of transport from Weston-super-Mare, about which I'm not sure: trains between WsM and Bristol are at least hourly. Maybe there should be a shuttle between station and meeting for people who can't walk, but it seems nuts to run a bus from here when trains are faster and have space. Officer Chris Griffiths gave a presentation (with loud music!) about our community support, including windfarms on the co-operative farms, Farm to Fork, the Woodcraft Folk, the Queens Award for Sustainable Development, community chef visits to Ilfracombe and Bath, community challenge, Mukti Mitchell's Low Carbon Lifestyle Tour, Fairtrade fashion shows, Holyland Handicrafts Co-operative at Bath Christmas Market, BAND (D is for Daycare, but I missed the rest), Toy Box Library Bath, Avonmouth Community Centre Association and Oldfield Park Juniors. Frank Jones presented the business interim report, noting that the group has a 2.2% increase of revenue before reinsurance premiums, but the bad weather has hit the insurance arm, reducing the overall profit. Nevertheless, we still paid a total of 38 million pounds to and on behalf of members. The closure of WsM Dolphin Square and the gain of the co-operative pharmacy in Milton were mentioned in passing. There was a short presentation about the constitutional review. The first members' consultation ends on 26 October, so send in your comments soon. There was particular concern about some multi-thousand-pound payments to elected representatives who stand down. Then came member questions, which I'll describe in another post, approval of past minutes, reports of the local co-operative party (success in Bath+NES, 8 councillors in Bristol, loss of 2 councillors in N.Somerset) and presentations to Frank Jones and Simon Crew of 10-year elected service awards. The meeting closed at 9pm.

In the last few days, I have replaced the two 20 inch CRT monitors that I have hardly used the last years with two 20 inch TFT displays, and my company (finally) gave me a 19 inch TFT display to accompany my notebook display at work. Maybe I should take that as a hint that they want to see me in the office more frequently rather than in my home office which I generously use these days. At home, I built a “new” computer from mainly used parts to drive the two 20 inchers. I have learned a lot about X in the last days, but spent too much time with it. I have been running my Desktop with older X and two CRTs for quite some time, but I hardly ever used it due to the setup of my now ex-flat. Back then, I learned that the “two monitors, one display, one screen, one desktop” option of X was called Xinerama and statically configured: You write down your display layout in xorg.conf and it uses it. Configuration changes mean restarting the X server. KDE notices Xinerama automatically, designates one monitor the “main monitor” and displays its panel there. You can move windows from one monitor to the other one, but changing virtual desktops always changes what both monitors display. This is not really what I want, since I often have “static” contents (news reader, mail reader, chat windows, help screens etc) on one monitor while I do my normal work on the other monitor, which involves changing virtual desktops. So I was rather happy when I learned upon the arrival of the external TFT display for the notebook that you can work without Xinerama. In that case, the X server comes up with one display and two screens, which KDE uses to display two independent desktops which can be independently configured, but can both be accessed with one mouse and one keyboard. For me, this means that I finally can independently change virtual desktops on both monitors, but pay the price that I cannot display a certain virtual desktop on monitor 1 now, and on monitor 2 in five minutes, and that a window opened on monitor 1 is never going to be shown on monitor 2 without serious interference. This looked ok for me. Additionally, you can use different font sizes on the different monitors as defaults, which comes in handy if both monitors are blatantly different in size (which is the case with the notebook and its external monitor). However, with that setup, KDE seems to be challenged when it comes to saving the configuration. Some things (such as desktop background and panel config) seem to save fine, desktop independent, other things (such as open windows and their position) are lost when the session exitst. My daily visit to Kevin&Kell (which used to be in a browser window that was saved with my session) has badly suffered since then. Then, a few weeks ago, somebody talked me into trying the X server from experimental. Which is when my dual-desktop setup ceased working. The nice people on #debian-x told me that Xinerama is a thing of the past, and is currently in the process of being replaced by Xrandr 1.2. The removal of “my” two monitor, two screens, two desktop setup is collateral damage, and if I still want that behavior, the X.org upstream considers this an issue to be handled by the Window Manager / Desktop Environment now. Gee, thanks. That’s what I call a regression. After spending half a day cursing and ranting, and even considering to go back to lenny’s (or even etch’s) X.org, I finally settled on going with the “new” way as I was going to lose my independent desktops sooner or later anyway. Again, with the friendly help of the people on #debian-x, I found out about a lot of advantages of the latest X servers. In most basic cases, the latest X server does not need a configuration file any more. It autodetects your hardware and chooses whatever modes it finds optimal. It does a pretty decent job in doing so. If one wants to influence how the X system comes up, once can always write an Xorg.conf file - the configfileless server even writes the “virtual config file” it uses to the log as a starting point. Additionally, almost everything regarding screen layout can be reconfigured at run time using the xrandr binary from a command line. Even a hardware change (such a new monitor plugged into the powered on notebook) is correctly detected. Cute. This allows me to reconfigure my notebook depending on where it currently is and which external monitor (or projector) is connected. This can be perfected if I find out whether X offers a hook to plug a reconfiguration script into that is called when the X server starts or when the system is waking up from standby or hibernation with the X server running. A lot to do, and great potential for elegant stuff. However, while I am talking about hibernation, this is a downside of the new driver: When the system wakes up from hibernation, the X server sometimes confuses itself enough to become nearly unuseable: I had it become psychotic when plugging in the external monitor (which can do 1600x1200 points) after waking it up from hibernation at the office. The internal display can only do 1400x1050, and the box thought that the external monitor only had 1050 y axis pixels, displaying bit garbage in the lower part of the big monitor, and showing a useable, but unintelligible panel. When opening any browser or any other application with considerable text amounts in the window, all fonts become unreadable once one scrolls down. Restarting the X server helps and everyting is fine. But I do not use hibernation to force myself to log out of X after waking up. After going back to the “one monitor mode”, the X server now thinks that my virtual desktop is 1600x1200 and only shows 1400x1050, with dead space at the right and lower side of the virtual desktop. xrandr does not allow me to reisize the FB below 1600x1200. No idea what’s going on here. In most of the cases, calling xrandr --auto for each output will fix the issues at run time, but sometimes a session restart is needed. Code needs to stabilize quite a bit before becoming useable in production. There are a few disadvantages that will remain: Both monitors will change their contents when the virtual desktop is changed, and both displays will use the same default font size (which might be inappropriate if both displays are of different size). But I think, when the issues are cleared up, that I can live with these disadvantages. The “new” desktop system that I built has a Matrox G450 dual head graphics card, and unfortunately, the Xrandr 1.2 enabled X server from experiemental has shown to be unuseable: Upon some mode changes, the X server goes into an endless loop and proves itself to be unkillable short of SIGKILL. And if it dies, it sometimes pulls the entire system with it. There is a corresponding bug in the upstream BTS, but it hasn’t received any noticeable attention by the upstream developers. So I might find myself configuring one last Xinerama config before I can finally completly migrate to Xrandr 1.2 on the desktop as well. Then I’ll probably need to bug the KDE upstream people to implement a two-desktops-on-a-single-screen feature in one of their future versions so that I can get my independent-desktop-things back. But that’s a far far away future.

Thanks to Damyan Ivanov for the upload, svn-buildpackage 0.6.22 is now in experimental. The upload was done to experimental due to the big number of changes affecting it and because I wanted to get a fairly significant amount of testing of the major fixes before propagating the code to unstable.

This release should fix 15 (yes, fifteen) bugs[0], most of which were important bugs or bugs affecting usability.

The major fixes are:

• mkdir -p like functionality in the repo for the tags and other possibly missing directories - this means that even repositories created with older broken versions should be fixed automatically[1]
  
• .svn/deb-layout is no longer a broken cache, but only a real local override for the layout information; .svn/deb-layout is created only on express request via --svn-savecfg; note that although .svn/deb-layout is no longer created automatically, old checkouts should be purged of this cruft (unless the override is wanted)
  
• build dependencies are not required on --svn-export
• automatic creation of the origDir when using origUrl
• some code clean up
  

Installing the package on an etch, lenny or sid system should be straight forward: just get the deb from experimental and install it (no backporting is necessary).


If you usually use svn-buildpackage, please install the experimental version and report any bugs and/or success stories. I am particularly interested in feedback related to the behaviour around .svn/deb-layout and the other methods of specifying layout information.

Please send success stories to me directly eddy.petrisor @ gmail.com. Bugs should be directed to the BTS, but I hope there will be mail just directly to me :-) .


[0] I wonder, does the thickness of the yellow area on these graphs ever decreases?
[1] as soon as the breakage would have been visible in the past

Well, I forgot to say where you can get git-dch and many people worried about it on IRC. git-dch is part of git-buildpackage lastest version and come with a nice set of options to allow you to customize its behaviour and like. Guido is nice as upstream since he’s very open for suggestions and I do think that if you have any suggestion to give, you shoul do.

I recently discovered some perl behaviour that I cannot explain. My goal in this code was to get the matched string in $1. I see how only having a scalar for multiple possible matches (the result of g) could be a problem, but I expected to alyway get something. The effect instead is that $1 may or may not be defined, depending on apparently unrelated changes like setting the i option or changing the regexp in a way which does not alter the matched text. My test case follows.

#!/usr/bin/perl
use warnings;
use strict;
#use re 'debugcolor';
my $text = <<END;
XXWY
XXWZ
END
# $1 is defined only if I remove either of ?, g or i
my $count = $text =~ s#(XXW?Y)##gi;
print "REMOVED: <<$1>>\nCOUNT: $count\n";

Today’s kernel: 2.6.23 + 2.6.23-hrt1 patchset + mactel patches. That gives an amd64 tickless kernel that just works and I’m not observing the weird behaviour I observed with 2.6.22-hrt6 that forced me back to a 2.6.21 kernel. I still need to remove the HID_QUIRK_POWERBOOK_ISO_KEYBOARD quirk for my GEYSER IV ISO keyboard, otherwise the @ and < are swapped. The good news, on the audio side, is that I don’t need to manually fix the pin config for the HDA codec anymore, which is a great step forward :-) There’s a patched radeontool available that introduces a radeontool power low command to switch the chip into low power mode. And it works. Saves about 45 minutes of battery power, bringing the laptop’s autonomy to something like 2:15 hours. Still far, far away from the 4 hours I had on the PowerBook but it’s a step forward. This also means the laptop is now quiet; I don’t hear the fans anymore. I’ve had this laptop for 11 months now, and it’s something I was really, really looking forward to. Update on the EFI firmware update 1.4: this update really fixes the keyboard issue in legacy bootloaders, I’ve had a working keyboard in LILO at each and every (re)boot since I installed it.