Andrew,

wc -l <$file

(Inaugurating a new category which will be kind of my own dailty wtf) A pretty well known matter is how some tools can be abused. Usually, it is cat or grep. Typical examples include the following two:

cat foo grep bar

grep bar foo awk ' print $2 '

Obviously, the first one can be reduced to:

grep bar foo

and the second, to:

awk '/bar/ print $2 ' foo

awk and sed are often part of the reason grep gets abused, because a lot of people don t know the latter form above or its sed equivalent. They don t know they could restrict the match on a specific column, too, which could be important in some cases. Anyways, a few months ago, I saw the most beautiful short piece of combined useless use of something I ve ever seen, which also happens to be a pretty unusual type:

more $file wc awk ' print $1 '

Not only does it use more where even cat, while still being useless, would be a better choice, but it also manages to use awk where wc could take an option to achieve the same goal. Yes, the above can be simplified as:

wc -l < $file

We never found who was responsible for this nicety.

If a Debian General Resolution ballot asked me to choose between eat shit and die , I d vote for Further Discussion.

Really, now is the day 3 I am just considering this day 2 for I had to do a lot of things again due to my dumbness. Let me explain: I had a desktop environment in place (with fluxbox), wired network, and most of my daily softwares (Iceweasel, X-Chat, Pidgin, GkRellM), then I decided to test the Suspend-to-Disk At first, it seemed to work well: I made a swap file for uswsusp, just as documented what is not documented is that this file must be outside the encrypted partition! So, when I turned it on again, an error telling me about some corruption in the opened luks partition. I though OK, something gone mad, just a matter of running an e2fsck . So I booted with the netinst pendrive, opened the luks partition and ran it with -y. Everything seemed to be corrupted!!! It spend almost 5 minutes fixing bogus inodes and stuff before I decided to interrupt the process this fixed filesystem would never work anyway. So I began from scratch All over again. When I got into a working base-system, some other thought stroke me: what if Brenda were to use rohan (have I mentioned the name is rohan? I name all my machines after places in Middle-earth)? So, a minimal user-friendly desktop is needed After some research, I decided to go for LXDE. This is a minimalist desktop with OpenBox as the window-manager. I ve been using FluxBox for a long time now, so running another BlackBox-based would not be such a problem. LXDE is quite good. So far, everything I expected is working fine . Then I decided it s time to move on to configure the Wi-Fi stuff. I installed the RT2860 modules from Debian/EEEPC Repository and added rt2860sta to /etc/modules. At first I was worried that some reports of it not working with WEP showed up in a Google Search But nothing could be smoother! I installed wicd and it detected our WEP AP like a charm (and a bunch of other APs nearby)... after entering our key it just connected fine and I ve been using it since no glitches so far. I would like to play a little more, but I called the day since I got a lot of work going on Next item planned is the webcam

After two and half months of development, new Gammu stable release is out. Since last testing version there are only minor changes in vCard export, but full changelog since 1.21.0 is quite long:

• Disable ATOBEX for Motorola V180.
• vCard can now store caller group and private flag (bug #269).
• vCard now stores location and memory type.
• Add ID for Nokia 6131 NFC (bug #775).
• Better skipping of corrupted messages in AT (bug #768).
• Autoload 6510 module if phone is S40 (bug #767).
• Add ID for Nokia 6500s (bug #770).
• Add automatic detection of Nokia phones (bug #770).
• Catch error when calls can not be deleted (bug #738).
• Better documentation of addnew (bug #734).
• Fix detection of OBEX capability on older Siemens phones.
• Try to detect wrongly formatted CMGL reply (bug #771);
• Handle phones which fail to report supported charsets.
• Fixed encoding of WAP indicator messages.
• Support for photos in vCard (bug #227).
• vC* saving now protects against buffer overflows.
• Drop own crosscompilation support, rely on CMake one.
• Also standard CMake parameters used when possible (eg. BUILDSHAREDLIBS).
• Search does not create thread for non existing devices.
• Fixed possible crash when backing up ringtones.
• Fix possible race condition in searching.
• Fixed invoking of CMake with output to custom directory.
• Compile on platforms where ssize_t does not exist.
• Fix detection of towlower on some compilers.
• Make Bluetooth compile using BCC.
• Fix compilation if strtoull does not exist.
• Compile on platforms where intptr_t does not exist.
• Fixed compilation in BCC (see changes above).
• Check whether compiler supports FUNCTION.
• Reimplement locking and add tests for it.
• GSM_SetDebugFileDescriptor now accepts flag whether file descriptor can be closed (bug #749).
• Soname change due to API breakage (see above).
• Fixed compilation on Mac OS X, thanks to Juan A. Bertolin for testing.
• Script gammu-config can now also work with whiptail.
• Minor fixes in gammu-config script.
• Extra spaces from connection or device name are now stripped.
• Automatically reinitialize FBUS connection if it is dropped.
• Disable OBEX with Motorola Z6c, it is broken (bug #746).
• Refresh manufacturer information on second init of AT (bug #746).
• Always get charset information on AT phone initialization.
• Better handling of OBEX switching for Siemens phones.
• Fix flags for 2630 and 3109c (bug #752).
• Fix handling of caller groups and picture IDs (bug #752).
• Properly set calendar location while adding (bug #747).
• Sign Windows binaries during build.
• Detect long FM station names (bug #727).
• Add ID for Nokia 2630b.
• Handle properly very long lines in vcards (bug #728).
• Do not build and install locales if gettext is not compiled.
• Increase number of calendar entries (bug #725).
• Leak free test runs.
• Support backup of phone phonebook from Siemens (bug #732).
• Properly handle GetNextMemory on Siemens (bug #732).
• Save textual category to backup (bug #737).
• Enable dashboard testing using CTest/CDash.
• Add option to do coverage analysis.
• Properly handle debug file closing.
• Add test case for debug logging.
• Fix decoding of some SMS messages from Nokia phones (bug #735).
• Hack for (still) unknown error code (bug #733).

You can download from usual place: http://cihar.com/gammu/, Binary packages will be available soon in all usual places (Debian Unstable, OpenSuse build service, Ubuntu PPA repository).

I am quite sad to announce that I am discontinuing Adept development for good. Since Kubuntu will be changing its default manager to KPackageKit (I wish everyone involved good luck), I have no further motivation to work on Adept at all. I have mostly done the 3.0 overhaul since Jonathan Riddell is my friend, and I like to make my friends happy. However, since this is no longer a factor, and my time is likely better invested elsewhere, I am giving up altogether. Of course, if anyone steps up for maintainership, I will happily delegate Adept to them. It is in a relatively good shape these days, I hope. I will keep the source (darcs) repositories around as long as reasonably possible. If you are interested in taking over, even despite the Adept userbase declining sharply in near future, please drop me a mail. With Adept goes also libept, a more general-purpose library for working with APT. I will be around when people need me to fix it, but won t add anything on my own. I am not even sure what is Enrico s status on libept, but probably just consider libept as good as orphaned, too. On a more personal note, this closes a long (very long) chapter in my free software life. I d like to thank everyone involved with it, there have been many of you. Moreover, this apparently cuts the few remaining ties I had to KDE development community I will miss you. well, maybe one of those days UPDATE: No, this does not mean I am no longer friends with Jonathan. I don t know why, but already two people managed to read it that way. To put it in hopefully less ambiguous words: The fact that Jonathan is my friend is no longer a factor just because he does not need Adept anymore. Hope that helps.

I'm posting way too much to debian-vote right now, which I realize and which I'm going to try to cut back on. (I at least did start the lintian.d.o upgrade process today, so I got non-discussion Debian work done.) The reason why I keep reacting, though, is that I'm finding it frustrating that people seem to be asking the wrong question for resolving the firmware freeness argument. We currently have a strong disagreement over what the implications of the Debian Social Contract and DFSG should be for our release process. Some Debian Developers believe that releasing lenny as-is requires a special exception to the Social Contract. Some Debian Developers believe that releasing lenny as-is is consistent with the Social Contract. We've tried and failed to achieve consensus. That's the first point of my frustration: some people don't seem willing to accept that this has happened. They are apparently having a hard time understanding how anyone couldn't agree with them, and are therefore repeatedly reopening the discussion on which we don't have consensus. Once it's clear that consensus doesn't exist, this is very counter-productive. The discussion is futile, which frustrates people, and then in that frustration they become increasingly angry and harsh. Once consensus fails, all interesting decision-making processes start. A decision-making process basically reduces to "who decides?". When you have a dispute and consensus is not possible, some body has to make a decision. If people believe in the decision-making process, they can then support, or at least live with, the decision because they respect the process, even if they disagree with that particular outcome. The most important output of a decision-making process is closure: you stop debating and move on. If that doesn't happen, the decision-making process has failed, even if it makes a decision. Why does this all matter and why am I going on at such length about it? It's simply this, which I think is so important I'll highlight it:

Even people who strongly disagree on some issues can work together cordially and well in the same project provided that they can agree on a decision-making process in those areas where they disagree.

Agreeing on how decisions are made in Debian is important because that's how we continue to work together when we disagree (and we will disagree). If we can agree on how disputes are resolved, we can all respect and honor the outcome even if it isn't what we would have wanted, and then move forward. If we don't agree on how disputes are resolved, we'll keep re-arguing them rather than accepting the outcome. The discussions will get more heated, more people will get upset, and more people will not have fun working on Debian. What I've been trying to analyze on debian-vote is the "who decides" part of this question. We have a decision-making process outlined in the Debian constitution for non-technical decisions (of which this is one). That process is somewhat scattered through the document, but bringing it together in one place, it seems to go like this:

1. Developers are empowered to make decisions about their own work. That means that, according to the constitution, the primary people who get to decide how the SC and DFSG should apply are every Debian Developer in the tasks on which they're working.
2. The project leader can define an area of ongoing responsibility and delegate to a developer or a group of developers responsibility for making decisions in that area. There are two relevant delegations here. The ftp team has the delegated authority to determine what packages may enter Debian given, among other things, licensing and DFSG issues. The release team has the delegated authority to decide what goes into the next stable release and when that release happens. (Let's put aside quibbles over whether or not that authority was formally delegated; I think that we can all agree in practice that it's close enough.) The ftp team has accepted the relevant firmware packages into Debian main and hence have made a decision in their area of responsibility. The release team, through the lenny-ignore tag, has decided that the relevant packages can be part of the next release. Those are delegate decisions that have already been made, and neither of those teams seem to want to change their mind.
3. The final decision-making body in this case, therefore, is the developers at large, who can override any delegate decision via a GR. That's what Robert Millan proposed, although he doesn't seem to have realized he was doing that, and it's not marked as such on the ballot.

Now that this has happened, we all vote whether or not to override the delegate decision. The only option on the ballot that does so, by my reading, is the first one, so if the first option does not win the GR, the delegate decision is not overridden and both the ftp-master and release team decisions stand. This is why Further Discussion means we continue the release as previously planned. We have a decision-making process, which has been followed, and the current decision is to release including those packages. In order to change that decision, it has to be overridden. A result of Further Discussion on a GR means that GR does nothing, and hence the decision stands. The second point of frustration is the decision that option four on the ballot (delegate to the release team the power to make decisions about how DFSG issues affect what is included in the release) needs a 3:1 majority. They have already been delegated the authority to do that as part of their delegated authority to manage the release. The effect of option four on the project is therefore identical to Further Discussion; the only difference is whether we make a positive statement or fail to make a negative statement. It makes no sense to treat it as supersession of a foundation document when it just supports the existing decision-making process in the constitution. A third point of frustration is the apparent feeling that foundation documents like the DFSG are outside of the normal decision-making process described in the constitution. I can find no evidence of this in the constitution, but more fundamentally, the people arguing this are not stating what decision-making process they believe does apply other than "my view of the DFSG is obviously the only reasonable one and hence you should follow it." This reduces to a plea for consensus, which we've already established that we don't have, and hence, as mentioned above, is horribly unproductive to keep raising. There will never be a policy document that is so clear that everyone will agree on its implications in every situation. I find it much more useful to analyze governance processes by looking at who decides disputes rather than looking at position statements. The decision-making process is what will determine the outcome of all the really interesting cases.

Following my previous post, today I began to turn my brand new Asus EEE PC 901 into a Debian Machine. At first I wanted to do all in one day, but since work is taking too much out of me (and everything seems to take more time than expected), I ll have to split this in different days So, first things first. I read Debian Wiki on the issue and began by doing the most important: backing it up. So I got a daily netinst iso, put it on a USB Pendrive and followed the tip on backup over the network using netcat. Easy and effective, and took only 8 minutes on the 901 (I think the 35 minutes described on the wiki were for models with slower NICs). From there, I had to decide which version of the installer I d use. I chose Standard, since I want an encrypted disk on my EEE. So I run the installer and, on the partition manager, I deleted /dev/sda1 (where Xandros was installed), turning it into a 300 MB /dev/sda5 (to use as /boot) and a 3 GB /dev/sda6 building a Logical Volume over an LVM Volume Group with it and /dev/sdb1 (where the user directory was), and enciphering it. This took a long time, since, I believe, random data were being written to the device to increase crypto strength. I left /dev/sda 2,3,4 as they were, since they can belong to the Asus EEE Recovering System (and they don t take too much space :-) ) Now base system is installed, and wired network works like a charm Next steps will have to wait until tomorrow.

So I replaced my Latitude D410 with a shiny new Latitude E4300 (Intel Core 2 Duo SP9400 2.4 Ghz with 4 Gb RAM). Here are some notes about this laptop that might be interesting for others. SSD disk I now use an SSD drive for my main disk (Dell Ultra Performance SSD, it s the second generation of Samsung SSD) and I m satisfied with that choice, I can boot (an unmodified Debian desktop install) from the SSD in less than 30 seconds while the same system booting from a traditional hard-disk takes more than 45 seconds. X server The Intel GM45 graphic card is not auto-recognized by Xorg 7.3 (or rather by xserver-xorg-video-intel 2.3.2 which is in lenny) so you end up with the vesa driver by default. It s possible to force the usage of the intel driver by adding a Driver intel line in the device section of xorg.conf but I have opted to use Xorg 7.4 (available in experimental). With this version, I can successfully use the DVI output in the associated dock and I have working suspend/resume. It does create some interesting problems however since that version of the xserver relies on HAL to detect the keyboard layout and doesn t use the Keyboard section of xorg.conf. You have to create /etc/hal/fdi/policy/10-keymap.fdi by using /usr/share/hal/fdi/policy/10osvendor/10-keymap.fdi as template and reload HAL then restart X. Wifi support The Intel 5100 Wifi chipset requires Linux 2.6.27 at least for the new iwlagn driver. This driver also needs a new firmware (the iwlwifi-5000 one) that is not yet integrated in the non-free package firmware-iwlwifi (see #497717). Sound support It works ok with alsa and the version integrated in linux 2.6.27 but it still has some rough edges when used in combination with the dock. Using the output jack connector on the dock doesn t stop the output in the integrated loudspeakers and the volume on that connector is so low that you could think that it doesn t work at all if you don t pay attention. Using the microphone works fine. For reference, if you play in the mixer, Front mic means the microphone connected on the dock while Mic means the one connected on the laptop. Each Analog loopback X option goes pairwise with the corresponding Input source X setting. In order for the recording to work, I have to set Digital Input Source to Analog Input , Digital must be activated and Input source 1 defines the default input used for the recording. Bluetooth support Contrary to the previous laptop, Dell offered no choice on the bluetooth chipset, they only propose the Dell 365 Bluetooth Card so I took it but it doesn t seem to work out of the box. In fact I can t even see it with lspci or lsusb so I wonder if they did something wrong during the assembly. Googling on the topic didn t gave me any good result, let me a comment if you know how to get this working. Update: so apparently the bluetooth component is there (ID 0a5c:4500 Broadcom Corp.), it just appears as an USB hub so it s somewhat difficult to guess that it s effectively a bluetooth card. Freezes, in particular with an amd64 installation I first installed the system in 64 bits mode (amd64 architecture) but I had very regular freezes of the system (I couldn t finish a single kernel compilation for example). Since I switched to an i386 installation, the system is more stable but I still get an occasional freeze every other day. It might be that a more recent kernel fixes this or maybe it will be fixed with a future Dell Bios update we ll see, but it s my biggest complaint with this laptop so far. Links Lucas Nussbaum bought the same laptop, you might want to read his remarks as well. More details Load the full article only if you want to see the lspci and lsusb output on this laptop.


rhertzog@rivendell:~$ lspci -nnk
00:00.0 Host bridge [0600]: Intel Corporation Mobile 4 Series Chipset Memory Controller Hub [8086:2a40] (rev 07)
Kernel driver in use: agpgart-intel
Kernel modules: intel-agp
00:02.0 VGA compatible controller [0300]: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller [8086:2a42] (rev 07)
00:02.1 Display controller [0380]: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller [8086:2a43] (rev 07)
00:19.0 Ethernet controller [0200]: Intel Corporation 82567LM Gigabit Network Connection [8086:10f5] (rev 03)
Kernel driver in use: e1000e
Kernel modules: e1000e
00:1a.0 USB Controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #4 [8086:2937] (rev 03)
Kernel driver in use: uhci_hcd
Kernel modules: uhci-hcd
00:1a.1 USB Controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #5 [8086:2938] (rev 03)
Kernel driver in use: uhci_hcd
Kernel modules: uhci-hcd
00:1a.2 USB Controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #6 [8086:2939] (rev 03)
Kernel driver in use: uhci_hcd
Kernel modules: uhci-hcd
00:1a.7 USB Controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB2 EHCI Controller #2 [8086:293c] (rev 03)
Kernel driver in use: ehci_hcd
Kernel modules: ehci-hcd
00:1b.0 Audio device [0403]: Intel Corporation 82801I (ICH9 Family) HD Audio Controller [8086:293e] (rev 03)
Kernel driver in use: HDA Intel
Kernel modules: snd-hda-intel
00:1c.0 PCI bridge [0604]: Intel Corporation 82801I (ICH9 Family) PCI Express Port 1 [8086:2940] (rev 03)
Kernel driver in use: pcieport-driver
Kernel modules: shpchp
00:1c.1 PCI bridge [0604]: Intel Corporation 82801I (ICH9 Family) PCI Express Port 2 [8086:2942] (rev 03)
Kernel driver in use: pcieport-driver
Kernel modules: shpchp
00:1c.3 PCI bridge [0604]: Intel Corporation 82801I (ICH9 Family) PCI Express Port 4 [8086:2946] (rev 03)
Kernel driver in use: pcieport-driver
Kernel modules: shpchp
00:1d.0 USB Controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #1 [8086:2934] (rev 03)
Kernel driver in use: uhci_hcd
Kernel modules: uhci-hcd
00:1d.1 USB Controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #2 [8086:2935] (rev 03)
Kernel driver in use: uhci_hcd
Kernel modules: uhci-hcd
00:1d.2 USB Controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #3 [8086:2936] (rev 03)
Kernel driver in use: uhci_hcd
Kernel modules: uhci-hcd
00:1d.7 USB Controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB2 EHCI Controller #1 [8086:293a] (rev 03)
Kernel driver in use: ehci_hcd
Kernel modules: ehci-hcd
00:1e.0 PCI bridge [0604]: Intel Corporation 82801 Mobile PCI Bridge [8086:2448] (rev 93)
00:1f.0 ISA bridge [0601]: Intel Corporation ICH9M-E LPC Interface Controller [8086:2917] (rev 03)
00:1f.2 RAID bus controller [0104]: Intel Corporation Mobile 82801 SATA RAID Controller [8086:282a] (rev 03)
Kernel driver in use: ahci
Kernel modules: ahci
00:1f.3 SMBus [0c05]: Intel Corporation 82801I (ICH9 Family) SMBus Controller [8086:2930] (rev 03)
Kernel driver in use: i801_smbus
Kernel modules: i2c-i801
02:01.0 FireWire (IEEE 1394) [0c00]: Ricoh Co Ltd R5C832 IEEE 1394 Controller [1180:0832] (rev 05)
Kernel driver in use: firewire_ohci
Kernel modules: firewire-ohci
02:01.1 SD Host controller [0805]: Ricoh Co Ltd R5C822 SD/SDIO/MMC/MS/MSPro Host Adapter [1180:0822] (rev 22)
02:01.2 System peripheral [0880]: Ricoh Co Ltd R5C843 MMC Host Controller [1180:0843] (rev 12)
0c:00.0 Network controller [0280]: Intel Corporation Wireless WiFi Link 5100 [8086:4232]
Kernel driver in use: iwlagn
Kernel modules: iwlagn
$ lsusb
Bus 008 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 007 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 004 Device 019: ID 046d:c03d Logitech, Inc. M-BT69a Pilot Optical Mouse
Bus 004 Device 018: ID 0424:2228 Standard Microsystems Corp. 9-in-2 Card Reader
Bus 004 Device 017: ID 0424:2602 Standard Microsystems Corp.
Bus 004 Device 016: ID 0424:2502 Standard Microsystems Corp.
Bus 004 Device 007: ID 045e:00dd Microsoft Corp.
Bus 004 Device 006: ID 0c45:63fe Microdia
Bus 004 Device 004: ID 413c:2513 Dell Computer Corp.
Bus 004 Device 003: ID 413c:2513 Dell Computer Corp.
Bus 004 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 001 Device 005: ID 413c:8162 Dell Computer Corp.
Bus 001 Device 004: ID 413c:8161 Dell Computer Corp.
Bus 001 Device 003: ID 0a5c:4500 Broadcom Corp.
Bus 001 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 003 Device 002: ID 0a5c:5800 Broadcom Corp.
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Partagez cet article / Share This

At work, we have quite a few Debian servers. We have a few physical machines, then a number of virtual machines running under Xen. These servers are split up mainly along task-oriented lines: DNS server, LDAP server, file server, print server, mail server, several web app servers, ERP system, and the like. In the past, we had fewer virtual instances and combined more services into a single OS install. This led to some difficulties, especially with upgrades. If we wanted to upgrade the OS for, say, the file server, we d have to upgrade the web apps and test them along with it at the same time. This was not a terribly sustainable approach, hence the heavier reliance on smaller virtual environments. All these virtual environments have led to their own issues. One of them is getting security patches installed. At present, that s a mainly manual task. In the past, I used cron-apt a bit, but it seemed to be rather fragile. I m wondering what people are using to get security updates onto servers in an automated fashion these days. The other issue is managing the configuration of these things. We have some bits of configuration that are pretty similar between servers the mail system setup, for instance. Most of them are just simple SMTP clients that need to be able to send out cron reports and the like. We had tried using cfengine2 for this, but it didn t work out well. I don t know if it was our approach or not, but we found that hacking cfengine2 after making changes on systems was too time-consuming, and so that task slipped and eventually cfengine2 wasn t doing what it should anymore. And that even with taking advantage of it being able to do things like put the local hostname in the right places. I ve thought a bit about perhaps providing some locally-built packages that establish these config files, or load them up with our defaults. That approach has worked out well for me before, though it also means that pushing out changes isn t a simple hack of a config file somewhere anymore. It seems like a lot of the cfengine2/bcfg tools are designed for environments where servers are more homogenous than ours. bcfg2, in particular, goes down that road; it makes it difficult to be able to log on to a web server, apt-get install a few PHP modules that we need for a random app, and just proceed. Any suggestions?

So, in the Membership Status GR, we sent a clear message that we wanted those decisions to be postponed. Now, we have a responsibility to prove that we were not just rejecting any change, but that our vote was really a vote against the way those decisions were announced, and/or those particular decisions. I m convinced that our management of membership needs to be improved. I hope that in the next weeks/months, we will be able to discuss proposals about membership status. There s Joerg s, there s Lars , there s Raphael s, and there might be other ideas. Ideally, each of them would be discussed and improved separately (because we can t be expected to agree on one proposal right from the start), and finally we would get to vote on a coherent set of proposals (with an unbiaised ballot ;) to choose in which direction we want to change our management of membership. It would be great to use the DEP process or something similar for that. It is also interesting to compare this whole story with our current issue: a secretary that ignored valid criticism about a ballot and went on with asking to vote on it. In both cases, someone that is generally trusted and respected by the project made a mistake, and failed to acknowledge it, requiring strong actions from other DDs. I wonder how the secretary crisis will end

I use exetel for a number of services in Sydney. I have always found them to be the cheapest, even if their ability to support their service is sub-optimal. An example is right now, they are currently totally offline.

a2@eve:~$ dig +trace exetel.com.au
; <<>> DiG 9.5.0-P2 <<>> +trace exetel.com.au
;; global options:  printcmd
.           338458  IN  NS  G.ROOT-SERVERS.NET.
.           338458  IN  NS  H.ROOT-SERVERS.NET.
.           338458  IN  NS  I.ROOT-SERVERS.NET.
.           338458  IN  NS  J.ROOT-SERVERS.NET.
.           338458  IN  NS  K.ROOT-SERVERS.NET.
.           338458  IN  NS  L.ROOT-SERVERS.NET.
.           338458  IN  NS  M.ROOT-SERVERS.NET.
.           338458  IN  NS  A.ROOT-SERVERS.NET.
.           338458  IN  NS  B.ROOT-SERVERS.NET.
.           338458  IN  NS  C.ROOT-SERVERS.NET.
.           338458  IN  NS  D.ROOT-SERVERS.NET.
.           338458  IN  NS  E.ROOT-SERVERS.NET.
.           338458  IN  NS  F.ROOT-SERVERS.NET.
;; Received 228 bytes from 192.168.1.1#53(192.168.1.1) in 58 ms
au.         172800  IN  NS  ADNS2.BERKELEY.EDU.
au.         172800  IN  NS  AUDNS.OPTUS.NET.
au.         172800  IN  NS  NS1.AUDNS.NET.au.
au.         172800  IN  NS  NS2.AUDNS.NET.au.
au.         172800  IN  NS  DNS1.TELSTRA.NET.
au.         172800  IN  NS  SEC1.APNIC.NET.
au.         172800  IN  NS  SEC3.APNIC.NET.
au.         172800  IN  NS  ADNS1.BERKELEY.EDU.
;; Received 413 bytes from 2001:503:ba3e::2:30#53(A.ROOT-SERVERS.NET) in 620 ms
com.au.         259200  IN  NS  ns1.ausregistry.net.au.
com.au.         259200  IN  NS  ns2.ausregistry.net.au.
com.au.         259200  IN  NS  ns3.ausregistry.net.au.
com.au.         259200  IN  NS  ns3.melbourneit.com.
com.au.         259200  IN  NS  ns4.ausregistry.net.au.
com.au.         259200  IN  NS  dns1.telstra.net.
com.au.         259200  IN  NS  au2ld.CSIRO.au.
com.au.         259200  IN  NS  audns.optus.net.
com.au.         259200  IN  NS  ns1.audns.net.au.
;; Received 354 bytes from 2001:dc0:2001:a:4608::59#53(SEC1.APNIC.NET) in 1302 ms
exetel.com.au.      3600    IN  NS  ns2.exetel.com.au.
exetel.com.au.      3600    IN  NS  ns1.exetel.com.au.
;; Received 99 bytes from 128.242.113.189#53(ns3.ausregistry.net.au) in 193 ms
dig: couldn't get address for 'ns2.exetel.com.au': not found

This is something I reported (ticket #853640) to them around Oct 2008 (when they last had a failure), that the auDA has no in-balliwick glue for their DNS. I was told by their support supervisor, Dylan Friedewald, via email:

The DNS for helpdesk.exetel.com.au is operational and valid, I do not see the point in discussing that further.

It is interesting to note that Steve Waddington has blogged many times about customers being unable to identify issues, but it is even more interesting that when a customer does it is explicitly denied as being a problem and then ignored. Apart from no in-ballwick DNS glue, their nameservers are also open recursive ones. Great if you would like to perform a DoS attack against some unsuspecting person. I have raised other issues with them that warrant further investigation and corrective action, lest they affect all their customers. But I no longer have the time to continually ping them about things.

My home Asterisk configuration has been pretty static for a while. It works well, and so I haven't had a need to mess around with it. There's a couple of outstanding features I've wanted to implement for a while though, and I've now got one of them out of the way. All calls that come in from the local PSTN line, the Vonage ATA, and the SIP connection to Engin, hit a menu, where the caller selects whether they want to speak to Sarah or myself. The sole purpose of this is to determine what to do with the call if no one answers (which voicemail box or cell phone to send the call to). A convenient side-effect of this is that it defeats most telemarketers. Ages ago, I set up caller ID announcement to my MythTV setup, so if we happened to be watching TV or a recording when a call came in, it briefly popped up on the TV. Fortunately, we're not huge square-eyes, and spend more time goofing off on our laptops, so I wanted a way to display notifications on our laptops when calls came in as well. I had this crazy design in my head of having a server process on my Asterisk box, and then clients on our laptops could connect to it, and be informed of new calls. Before I went on a coding frenzy, and did something with the Observer pattern and more socket programming than I really wanted to, I thought I'd check if this was solved problem. Turns out, it kind of is. I found the Notify application for Asterisk (which I've made a package for Debian Etch), which blats a UDP message to particular host as part of a dialplan. It's more intended to go in person-specific extensions, but as the majority of calls go into the main menu and never come out before hitting a person-specific extension, and I still wanted to know about them for my own perverse pleasure, I added multiple calls to the Notify application in the main menu dialplan. The site for the application also mentioned some third-party clients for Linux and MacOS, but I've been looking for an excuse to try and write something that used Growl, so I wrote my own Python application, initially on Linux, and then I essentially swapped out the pynotify code for the equivalent Growl code, and it worked just as well on Sarah's Mac. So it's not quite the solution that I had in mind, because it doesn't really scale, but for our two-user home setup, it's adequate. I might still try and write some middleware between a client for this application and an infinite number of observers, but there's no urgency. The dialplan for our main menu now looks something like this:

exten => s,1,Background(for)
exten => s,n,AGI(mythtv-cid.agi)
exten => s,n,Notify($ CALLERID(num) $ CALLERID(name) $ EXTEN /icarus)
exten => s,n,Notify($ CALLERID(num) $ CALLERID(name) $ EXTEN /iapyx)
exten => s,n,Set(TIMEOUT(digit)=5)      ; Set Digit Timeout to 5 seconds
exten => s,n,Set(TIMEOUT(response)=10)  ; Set Response Timeout to 10 seconds
exten => s,n,Background(names/sarah)
exten => s,n,Background(press-1)
exten => s,n,Background(for)
exten => s,n,Background(names/andrew)
exten => s,n,Background(press-2)
exten => s,n,WaitExten

A call comes in, hits the menu, and the caller ID info is displayed on MythTV (if something's being watched) and our two laptops (if they're awake). Unfortunately my Git-fu is atrocious, so I can't figure out how to link to a web-browseable repository that contains the source for my client, but if I figure that out, I'll update this with a link later. Update I managed to summon enough Git-fu to put the repository online. It's available at http://git.andrew.net.au/?p=asterisk-notify-client.git;a=summary Now I just have to use it properly.

Pierre,

do we trust our release team ;

• No.

shall we delay the Lenny release for firmware issues or not (We answered that twice in the past with huge majorities btw) ;

• Possibly.

shall we modify the meaning the the SC/DFSG.

• Only to remove SC#5 or remove the DFSG#4 compromise.

How should I vote?

A while back, I wrote about this GObject-based Object/Relational mapper that I wrote, which is called 'GNoDbify'. It isn't complete yet, but parts of the library work; I use it for a project that I'm supposed to commercially support. For those who don't know what that is: an O/R mapper builds objects out of database tuples; so I can run a 'lookup' function on the object class and get one (or more) objects representing data from the database, then perform some modifications on that object, and store it back in the database; my O/R mapper does all the SQL magic. Last week, I've been working on another object that takes an array of GNoDbify objects, and presents them using the GtkTreeModel interface, for easy viewing in a GtkTreeView:

my @customers = Vpbs::Db::Customer->get_all();
my $model = GNoDbify::ListStore->new_from_array(@customers);
my $view = Gtk2::TreeView->new_with_model($model);
my $renderer = Gtk2::CellRendererText->new();
my $column = Gtk2::TreeViewColumn->new_with_attributes("Name", $renderer, "text", $model->get_column("name"));
$view->append_column($column);

And there you have it: a treeview showing all the names of all the customers in the database. On the classical approach, one would have to use DBI or some such to fetch data from the database, create a GtkListStore or something similar, and then append the data one row at a time to that. Of course that still happens here, in a manner of speaking, but it all happens behind the scenes. It also means that in an application which wants to show a load of data, I don't have to do the same thing all the time. The magic happens in the second line, and in the second-to-last line. GNoDbify::ListStore->new_from_array is pretty much self-explanatory, really. It takes an array of GNoDbify objects, and returns a GNoDbify::ListStore. The second-to-last line shows how to add a column to a GtkTreeView. With GtkListStore and GtkTreeStore you basically define yourself what column gets what number; however, with GNoDbify, that isn't as easy (it depends on the implementation of the GNoDbify subclass), so the ->get_column returns the number of a column as represented by the model, and wants the name of the field that you want the column of. Everything else is really the same. It won't stop here, though. The original plan for GNoDbify was that it could detect changes in the database, and update the tree model accordingly. Most of that has already been implemented in GNoDbify (though not yet in the ListStore thing), but just needs some debugging. The fun thing is, the above six lines of code would not have to change at all for that. Of course all this juicyness comes at a price. In order to generalize this much, I had to do a lot of extra stuff; so there's some performance loss. Especially in perl; most of GNoDbify is written in C, and converting perl arrays to and from C arrays is a process that can only be done by looping over the perl array (or the C array) and creating the other side of the equation. Obviously, that's a costly approach, performance-wise; an obvious optimization of the above example could be to have a subroutine that returns Customer objects already in a GtkTreeView in one API call. We'll see.

A variety of Debian tasks all lined up in the top priority - get it done now or not at all - work queue this morning. Two GR's, one RC bug fix and one long overdue experimental upload.
All I'm saying about the first GR (the "anti-ganeff" vote) is 2212. That was the most ridiculous GR I've come across so far, until vote3 which is just politics gone insane. My own opinion? 7235146 which disagrees quite a lot with bubulle even though I have the same aims as bubulle - that alone indicates the nature of the vote. The options are illogical, the vote is pointless, the subject matter is moot, the initial proposal doesn't have any understanding or relation to the real world and the amendments have been unnecessarily divided in such a way to make it all but impossible to be logical in the vote priorities. The abuse of votes by a vocal minority undermines the process itself. All in all, we desperately need an option that basically says stop being pathetic and get something useful done in all future GR's - as well as making it harder to make a GR in the first place. Over use of referenda is as poisonous to democracy as under use - just ask Ireland.
After all that political spin and muck spreading, I had to just do something useful as a partial compensation. So, after a ping from the MIT BSP I've fixed 507316.
I've also made the tslib experimental upload that has been quietly developing on my own system for a few days.
Right, now I'm getting back to adding more packages to Emdebian Grip - so far, we have enough packages for a basic XFCE/Gtk system with an email client, a blog client, a few GPE games and Thunar as file manager. Now need to add iceweasel and dependencies. Once that is done, I'll be switching my Acer Aspire1 from Debian Lenny to Emdebian Grip unstable and creating a testing repository for Grip. Once I've got some figures from that switch, I'll post some more details to debian-embedded@lists.debian.org.
Sigh. Emdebian Grip was meant to go alongside Debian Squeeze - it looks now as if Emdebian Grip will be released before Debian Lenny - it's even likely to use the Lenny installer and debian-live support. I hope the pedants are happy because I'm not.

It's a longstanding bug that java programs show empty gray windows when being used in many window managers. As there is OpenJDK now, I thought: It's free software now, so look at it and perhaps there is a way to fix it. As always, looking at java related stuff is a big mistake, but the code in question speaks volumes. The window configure code has:

        if (!isReparented() && isVisible() && runningWM != XWM.NO_WM
                &&  !XWM.isNonReparentingWM()
                && getDecorations() != winAttr.AWT_DECOR_NONE)  
            insLog.fine("- visible but not reparented, skipping");
            return;
         

and if you wonder how it detects if there is a non-reparenting window manager, it does it by:

     static boolean isNonReparentingWM()  
        return (XWM.getWMID() == XWM.COMPIZ_WM   XWM.getWMID() == XWM.LG3D_WM);
      

Yes, it really has a big list of 12 window managers built in for which it tests. And this is not the only place where it has special cases for some, but it does so all the time in the different places. But what Sun did not think about: There are more than 12 window managers out there. And with this buggy code it would need a list of every single one not doing reparenting (like ratpoison as when I read the bug reports correctly also awesome, wmii and a whole list of quite popular ones, too). Or it means that you are not supposed to run graphical java applications unless you use openlook, mwm (motif), dtwm (cde), enlightenment, kwm (kde), sawfish, icewm, metacity, compiz or lookinglass or no window manager at all. As I did not yet had realized that the old workaround of AWT_TOOLKIT=MToolkit no longer works in lenny before reading some debian-release mail, which means I haven't use any graphical java program for a long time, it seems I have decided for the latter. P.S.: I've sent a patch that one can at least manually tell java that one would like to see windows' contents as b.d.o/508650