Search Results: "ianw"

29 November 2010

David Paleino: Using Git tutorial for Debian-Women

On the 25th of November I held a training session for the Debian Women project, about Using Git. A transcript of the session is available. The session took 2,5 hours, more than I really expected (one hour less), but I had many questions asked. There were ~160 attendants, but many of those asking questions seem to have missed that this was a "basic" session, for people who never used it. All in all, it was a great experience. While preparing the talk, I had the chance to re-read some forgotten manpages, which clarified some points, so it was really useful for me as well :) Given the kind of questions I had, it would be nice to have an "Advanced Git" session, maybe in January-February. Any volunteers? I'll sure be attending it :) FYI, the next session will be held by POX (Piotr O arowski) next Thursday (Dec, 2). It will be about Python libraries/application packaging, you'll have to read the introductory session as a pre-requisite.

16 November 2010

Debian News: Debian Women IRC Training Sessions begins

The Debian Women project is pleased to announce the -start of a series of training sessions to be held via IRC in the Debian Women IRC channel, #debian-women on

The first session has been scheduled for Thursday, 18th November at 20:00 UTC. Lars Wirzenius, will give an introductory lesson titled Introduction to Debian Packaging .

The main goal of this initiative is to encourage more people, specifically women, to contribute to Debian while introducing them to different aspects of the Debian Project. Topics will span a wide range of subjects related to daily Debian maintenance efforts as well as advanced tasks and are open to everybody, regardless of gender or previous involvements in the community.

Future sessions will be held on a regular basis, and will cover collaborative maintenance with git, Python modules and applications packaging, and many more. Please visit the Training Sessions wiki page regularly to check the up-to-date agenda and follow our group on You may also refer to the wiki to suggest new topics or sign up yourself as a trainer: we are always looking for more people to share knowledge and complete the schedule, so don t be shy!

For further information about the Debian Women project, please visit the Debian-Women website or send mail to the Debian Women mailing list.

24 August 2010

Debian News: Bits from the Debian Women project

The Debian Women project aims to get more women to participate in Debian, as packagers, bug reporters, technical documentation writers, bug fixers, translators, artists and in any other area that helps the development of Debian. These goals are achieved through IRC tutorials, a mentoring program, a mailing list and an IRC channel.

The Mentoring Program, allows men and women that want to contribute to Debian but aren t sure where or how to start, to get some help with their first steps.

There have been at least 38 women that have contributed in packaging software for Debian, and there are currently 11 female Debian Developers and 1 Debian Maintainer. We d like to raise those numbers to 50 packagers by the end of 2011, and 20 Debian Developers by the end of 2012.

There are some other interesting statistics about the current female participation in Debian.

We are also interested in getting more women to file and fix bugs, translate debconf templates or package descriptions, contribute to the release notes, as well as participate in any other areas of the Debian project. In order to do this, we will be holding some IRC training sessions in the near future, to help people get started. We are currently making the list of subjects and trainers, we ll publish more news about this once the first sessions are scheduled.

For more information you can join the IRC channel #debian-women on, or subscribe to the debian-women mailing list. If you are a Spanish speaker, you can also join the IRC channel #debian-mujeres on

Margarita Manterola

Ian Wienand: Split debugging info -- symbols

In a previous post I mentioned split debugging info. One addendum to this is how symbols are handled. Symbols are separate to debugging info (i.e. the stuff about variable names, types, etc you get when -g is turned on), but necessary for a good debugging experience. You have a choice, however, of where you leave the symbol files. You can leave them in your shipping binary/library so that users who don't have the full debugging info available will still get a back-trace that at least has function names. The cost is slightly larger files for everyone, even if the symbols are never used. This appears to be what Redhat does with it's system libraries, for example. The other option is to keep the symbols in the .debug files along-side the debug info. This results in smaller libraries, but really requires you to have the debug info files available to have workable debugging. This appears to be what Debian does. So, how do you go about this? Well, it depends on what tools you're using. For binutils strip, there is some asynchronicity between the --strip-debug and --only-keep-debug options. --strip-debug will keep the symbol table in the binary, and --only-keep-debug will also keep the symbol table.
$ gcc -g -o main main.c
$ readelf --sections ./main   grep symtab
  [36] .symtab           SYMTAB          00000000 000f48 000490 10     37  53  4
$ cp main main.debug
$ strip --only-keep-debug main.debug 
$ readelf --sections ./main.debug   grep symtab
  [36] .symtab           SYMTAB          00000000 000b1c 000490 10     37  53  4
$ strip --strip-debug ./main
$ readelf --sections ./main.debug   grep symtab
  [36] .symtab           SYMTAB          00000000 000b1c 000490 10     37  53  4
Of course, you can then strip (with no arguments) the final binary to get rid of the symbol table; but other than manually pulling out the .symtab section with objcopy I'm not aware of any way to remove it from the debug info file. Constrast with elfutils; more commonly used on Redhat based system I think. eu-strip's --strip-debug does the same thing; leaves the symtab section in the binary. However, it also has a -f option, which puts any removed sections during the strip into a separate file. Therefore, you can create any combination you wish; eu-strip -f results in an empty binary with symbols and debug data in the .debug file, while eu-strip -g -f results in debug data only in the .debug file, and symbol data retained in the binary. The only thing to be careful about is using eu-strip -g -f and then further stripping the binary, and consequently destroying the symbol table, but retaining debug info. This can lead to some strange things in backtraces:
$ gcc -g -o main main.c
$ eu-strip -g -f main.debug main
$ strip ./main
$ gdb ./main
GNU gdb (GDB) 7.1-debian
(gdb) break foo
Breakpoint 1 at 0x8048397: file main.c, line 2.
(gdb) r
Starting program: /home/ianw/tmp/symtab/main
Breakpoint 1, foo (i=100) at main.c:2
      2return i + 100;
(gdb) back
#0  foo (i=100) at main.c:2
#1  0x080483b1 in main () at main.c:6
#2  0x423f1c76 in __libc_start_main (main=Could not find the frame base for "__libc_start_main".
) at libc-start.c:228
#3  0x08048301 in ?? () 
Note one difference between strip and eu-strip is that binutils strip will leave the .gnu_debuglink section in, while eu-strip will not:
$ gcc -g -o main main.c
$ eu-strip -g -f main.debug main
$ readelf --sections ./main  grep debuglink
  [29] .gnu_debuglink    PROGBITS        00000000 000bd8 000010 00      0   0  4
$ eu-strip main
$ readelf --sections ./main  grep debuglink
$ gcc -g -o main main.c
$ eu-strip -g -f main.debug main
$ strip main
$ readelf --sections ./main  grep debuglink
  [27] .gnu_debuglink    PROGBITS        00000000 0005d8 000010 00      0   0  4

9 May 2010

Ian Wienand: This laptop has Super Cow Powers

This laptop has Super Cow Powers Tip: if you would like your own cow sticker, take a cute child through the checkouts at your local Whole Foods.

22 March 2010

Ian Wienand: What exactly does -Bsymblic do? -- update

Some time ago I wrote a description of the -Bsymbolic linker flag which could do with some further explanation. The original article is a good starting place. One interesting point that I didn't go into was the potential for code optimisation -Bsymbolic brings about. I'm not sure if I missed that at the time, or the toolchain changed, both are probably equally likely! Let me recap the example...
ianw@jj:/tmp/bsymbolic$ cat Makefile 
all: test test-bsymbolic
	rm -f *.so test testsym : liboverride.c
	       $(CC) -Wall -O2 -shared -fPIC -o $< : libtest.c
	   $(CC) -Wall -O2 -shared -fPIC -o $< : libtest.c
		     $(CC) -Wall -O2 -shared -fPIC -Wl,-Bsymbolic -o $@ $<
test : test.c
     $(CC) -Wall -O2 -L. -Wl,-rpath=. -ltest -o $@ $<
test-bsymbolic : test.c
	$(CC) -Wall -O2 -L. -Wl,-rpath=. -ltest-bsymbolic -o $@ $<
$ cat liboverride.c 
#include <stdio.h>
int foo(void)
	printf("override foo called\n");
	return 0;
$ cat libtest.c 
#include <stdio.h>
int foo(void)  
    printf("libtest foo called\n");
    return 1;
int test_foo(void)  
    return foo();
$ cat test.c
#include <stdio.h>
int test_foo(void);
int main(void)
	printf("%d\n", test_foo());
	return 0;
In words; provides test_foo(), which calls foo() to do the actual work. is simply built with the flag in question, -Bsymbolic. provides the alternative version of foo() designed to override the original via a LD_PRELOAD of the library. test is built against, test-bsymbolic against Running the examples, we can see that the LD_PRELOAD does not override the symbol in the library built with -Bsymbolic.
$ ./test
libtest foo called
$ ./test-bsymbolic 
libtest foo called
$ ./test
override foo called
$ ./test-bsymbolic 
libtest foo called
There are a couple of things going on here. Firstly, you can see that the SYMBOLIC flag is set in the dynamic section, leading to the dynamic linker behaviour I explained in the original article:
ianw@jj:/tmp/bsymbolic$ readelf --dynamic ./ 
Dynamic section at offset 0x550 contains 22 entries:
  Tag        Type                         Name/Value
 0x00000001 (NEEDED)                     Shared library: []
 0x00000010 (SYMBOLIC)                   0x0
However, there is also an effect on generated code. Have a look at the PLTs:
$ objdump --disassemble-all ./
Disassembly of section .plt:
[... blah ...]
0000039c <foo>:
 39c:   ff a3 10 00 00 00       jmp    *0x10(%ebx)
 3a2:   68 08 00 00 00          push   $0x8
 3a7:   e9 d0 ff ff ff          jmp    37c <_init+0x30>
$ objdump --disassemble-all ./
Disassembly of section .plt:
00000374 <__gmon_start__@plt-0x10>:
 374:   ff b3 04 00 00 00       pushl  0x4(%ebx)
 37a:   ff a3 08 00 00 00       jmp    *0x8(%ebx)
 380:   00 00                   add    %al,(%eax)
00000384 <__gmon_start__@plt>:
 384:   ff a3 0c 00 00 00       jmp    *0xc(%ebx)
 38a:   68 00 00 00 00          push   $0x0
 38f:   e9 e0 ff ff ff          jmp    374 <_init+0x30>
00000394 <puts>:
 394:   ff a3 10 00 00 00       jmp    *0x10(%ebx)
 39a:   68 08 00 00 00          push   $0x8
 39f:   e9 d0 ff ff ff          jmp    374 <_init+0x30>
000003a4 <__cxa_finalize@plt>:
 3a4:   ff a3 14 00 00 00       jmp    *0x14(%ebx)
 3aa:   68 10 00 00 00          push   $0x10
 3af:   e9 c0 ff ff ff          jmp    374 <_init+0x30>
Notice the difference? There is no PLT entry for foo() when -Bsymbolic is used. Effectively, the toolchain has noticed that foo() can never be overridden and optimised out the PLT call for it. This is analogous to using "hidden" attributes for symbols, which I have detailed in another article on symbol visiblity attributes (which also goes into PLT's, if the above meant nothing to you). So -Bsymbolic does have some more side-effects than just setting a flag to tell the dynamic linker about binding rules -- it can actually result in optimised code. However, I'm still struggling to find good use-cases for -Bsymbolic that can't be better done with Version scripts and visibility attributes. I would certainly recommend using these methods if at all possible. Thanks to Ryan Lortie for comments on the original article.

7 March 2010

Daniel Burrows: Installing OpenWRT on a Linksys WRT54GL v1.1

I finally got a few hours free this morning to check an item off my home system administration checklist: upgrading the wireless router's firmware to OpenWRT. There were a couple motivations for this, including the fact that my SoundBridge Radio couldn't maintain a connection to my firefly server using the built-in firmware, and I had read that OpenWRT would work better. Since this is posted on Planet Debian, I should mention why I didn't use DebianWRT. The basic answer is this text at the top of the DebianWRT homepage:
Currently the most common methods used to run Debian on these systems is to install OpenWRT or a similar firmware, add disk space either by USB storage or NFS, create a debian chroot by either running cdebootstrap from inside OpenWRT or debootstrap --foreign on a PC, and running Debian from this chroot. For example, instructions for the WLHDD.
I'm not sure whether this is because DebianWRT is experimental, or because its goal is to use routers as cheap general computers. Either way, it sounds way too complicated and/or fragile for what I'm interested in (i.e., a wireless router with better software). The goal here is to get something that does a better job than the built-in WRT firmware, but doesn't require too much tinkering to get working or to maintain. I have plenty of outlets for my tinkering urges already. Nothing here was exactly difficult, but it was hard to find all the information I needed to get things working. Hopefully documenting the steps I went through here will save someone else some time. Step 1: acquire the firmware This was trickier than you might think. If you click on the download link at the OpenWRT web site, you end up at the top of an FTP server populated with a vast quantity of stuff. Worse, when you find the actual firmware images, you'll quickly discover that there are piles and piles of them divided between sixteen directories, and no guidance as to which one to pick. And picking the wrong one will turn your beautiful router into a doorstop. Luckily, the OpenWRT documentation contains a section called "Getting Started". Unluckily, that section consists of the following text:
1.1 Getting started 1.1.1 Installation 1.1.2 Initial configuration 1.1.3 Failsafe mode
Whoops, someone forgot to execute on a TODO. :-) Undeterred, I consulted the usual fallback reference, Google. It pointed me at several references, some of which were hidden on other parts of the OpenWRT site. Armed with these, I was able to determine that:
  1. My WRT54GL v1.1 probably uses a Broadcom 5352 chipset.
  2. The correct firmware, according to multiple sources, is probably in the kamikaze top-level director, the latest version's subdirectory, and the bcrm-2.4 directory under the version (the link is to 8.09.2, which is current as of March 6, 2010). Apparently the bcrm47xx directory doesn't have wireless support; it helpfully contains a file called NO-BROADCOM-WIRELESS to warn you off, but unhelpfully doesn't include any additional information in that file (like what exactly is broken or that you can find a working firmware in a sibling directory) ... oh well.
  3. The firmware file that you want is openwrt-wrt54g-squashfs.bin, even though it doesn't match the model number of the router. This directory could use a README file explaining which hardware is supported by each of the dozen or so firmware files it contains.
Step 2: install the firmware After Step 1, this was a real relief. I just used the built-in Linksys firmware installer, pointed it at the .bin file, and it went. Step 3: configure the router The installation guide I followed was pretty much silent about what to do after I got the firmware on. Luckily, this is just a software problem, meaning it's much more familiar territory for me.
  1. First things first: I checked that I could still get a DHCP lease. It worked.
  2. Armed with that, I tried telneting to the router. I used the resulting root prompt to set a password on the root account.
  3. I logged out and tried telneting in. Apparently the router is configured to disallow root logins over telnet if you don't have a password. Good for them (although why allow telnet at all?); oops for me.
  4. Luckily, an ssh server was installed by default. I like using keys to log in, so I tracked down the documentation on configuring the server to use public-key authentication; it turns out there's a single global key file named /etc/dropbear/authorized_keys that's exactly like OpenSSH's per-user authorized_keys file. No idea what would happen if I had multiple users, but I won't.
  5. The next obstacle: I didn't have an Internet connection. For some reason, my cable modem didn't want to give the router a DHCP lease. On the off-chance that it was remembering too much, I rebooted it and ran ifup wan. That fixed the problem. I still don't know why.
  6. Not a step, but a useful note: in the process of figuring the above out, I found readlog. It's basically dmesg for syslog files; it shows the most recent lines written to syslog. This is useful because there isn't a real syslog file, due to the fact that there would be no room to store it on the 54GL.
  7. Finally, I had to get wireless working. The documentation is very helpful when it comes to describing the syntax of the wireless configuration. Unfortunately, I read the list of encryption options and missed the section right below where their meanings are explained (although, to be honest, I might not have understood the implications of the explanation without the research I did anyway).
    option encryption none, wep, psk, psk2, wpa, wpa2
    I wanted WPA2 encryption, so I entered wpa2. And nothing worked. After a good hour of trying different options on the client, swapping software components in and out on the router, experimenting with the encryption key syntax, and crawling Google, I finally found my answer. If you just want WPA2 encryption, you must not use wpa2 as the encryption type. Instead, use psk2. It turns out out that wpa2 actually means use WPA2 and also use an external RADIUS server for authentication. psk2 is the system you're familiar with from a typical consumer wireless router.
Step 4: enjoy And with that, it works. Unfortunately, contrary to what I wrote here originally, my Roku still doesn't work. On the other hand, having a real Linux installation is helpful for debugging it. Currently my suspicion is that the router isn't passing multicast packets between the wired and wireless interfaces (broadcast works fine, multicast doesn't). That said, it seems like if I restart Firefly just before I start playing music, I can play reasonably reliably -- as long as I don't stop, because if I do, the Roku forgets that the music server is there. Either way, I've spent about as much time fighting this as I can afford. :-/ One lingering worry I have is security; unlike Debian, which has both a security mailing list and tools to inform me when I need to install a security update, the OpenWRT firmware doesn't seem to have any mechanism for distributing security notices. True, there is an openwrt-security-announce list, but it appears to be entirely unused, as is openwrt-announce. Something to keep an eye on, then. Also (file under note to self), I need to remember to verify that the router isn't exposing services to the outside world. The default iptables configuration is hideously complex; with just a quick glance, it could be setting up a floral shop for all I can tell. I'll need to test this empirically and maybe analyze the rules in more depth.

16 December 2009

Holger Levsen: Debian Wine soon to be sold out?

In case you want to buy some (more) bottles of wine made for DebConf9, you need to hurry up. Also a bit more hurry is appropriate if you want it to be delivered til XMas :-)

(Picture credit belongs to Chris.)

I'm planing another (offline) sale at the 26C3 congress in Berlin at the end of the year, which might or might not work out. If it does, the number of bottles available for online ordering will be reduced significantly, and basically I'm only waiting for some details to be finalized for announcing this for real, so hurry up and mail order now - unless you have enough Debian wine bottles at home already :-)

Information how to order is available in our wiki at DebianWine. The profit made will be given to DebConf9, and as that has been dealt with finacially successfully, it will be given to DebConf10!

19 October 2009

Holger Levsen: Debian wine from DebConf9

Debian 5.0.2 wine, which was made to support DebConf9, is finally available to be bought on the internetz. Currently the shop user interface is German language only, but I've heard that this will be fixed eventually.


8 September 2008

Neil Williams: Gobby - collaborative editing for worksession meetings

A few speakers at DebConf8 used gobby during their talks to collate ideas without breaking the flow of the session.
I've just come back from the Emdebian meeting in Extremadura (of which more later) where we also used Gobby - FAI used it too. Once the network setup was working, it was simply a case of clicking Create Session in gobby on my laptop and everyone else clicking Join Session, entering the IP of my laptop (only accessible locally) and choosing a colour.
Gobby is real-time, currently plain-text only but clearly indicates how sections have been edited and has an integrated IRC box for each session. At the end of the meeting, every gobby user has a copy of every document they opened in every session they joined. updated to the moment they quit the session.
Based on using gobby in events like this, I'd strongly recommend that someone at each worksession-type meeting starts a gobby session and maintains that session for the duration of the meeting.
Gobby even does syntax highlighting - depending on how many people join and the colours they choose, this might become difficult so it can be turned off too.
There are only a few minor issues:
  1. The colour bar warning box isn't particularly intuitive - you need to click on what looks like a dimmed progress bar to select a unique colour for yourself.

  2. I initially thought that Gobby had no authentication - in a local meeting, anyone who can connect to the specified IP address is able to edit the document. Since then, I've noticed it does support password authentication and there is mention of fully encrypted connections so it may be possible to use it over public networks.

  3. According to Wikipedia, there is a gobby server that allows non-GNU/Linux clients to run gobby and join any gobby session - I didn't explore this and the Debian package doesn't mention anything about a server option or mixed-OS support.
    • Update - the server is called Sobby and is in Debian.

  4. The right hand side of the window is a bit wasted - maybe some kind of sidebar would be handy, especially docking the userlist into the window so that edits can be identified more quickly.

23 August 2008

Ian Wienand: Spice hacking

Sick of a ridiculous pile of tiny bottles falling everywhere in your cupboard? Spice Hacking Many people will sell you many expensive solutions. However, I think we've hit on something cheap, effective and practical; zip-lock bags in a deep tub, labelled with sticky tags. Spice Hacking Spice Hacking

6 July 2008

Ian Wienand: Netgear WG311 shielding

I recently picked up the Netgear WG311 V3 very cheap from Office Depot. The card seems to work fine with ndiswrapper; there are other guides on getting it working. The first problem was the reception was, in a word, rubbish. After putting the box back in it's usual home the house wireless was lucky to get a 7/100 signal rating. I found a work-around while the cheap external antenna I ordered is arriving; shield the antenna with foil. This increased signal to between 30-40/100, a considerable boost making it actually useful. Cheap RF Shielding The second problem was coming to terms with wpa_supplicant, of which the details often become very confusing very quickly. Here's the Debian 2-second guide for a simple, standard WPA network I was looking for:
  1. Add to /etc/network/interfaces
    iface wlan0 inet dhcp
    # Useful with ifup -v 
    #    wpa-debug-level 3
         wpa-conf /etc/wpa_supplicant.conf
  2. /etc/wpa_supplicant.conf should look like:

8 February 2007

Lucas Nussbaum: Running Debian on your Linksys WRT54G* sort of

I’m the happy owner of a Linksys WRT54GL. OpenWRT is nice, but … well. Debian is just nicer. And I couldn’t resist the idea of running Debian on this little MIPS system. Since there’s clearly not enough space available on the Linksys, I decided to install etch in a chroot, that I would mount using NFS. Joey tried that already, the Debian wiki provides some information, but I use another technique. First, on another system (an i386, I debootstrap’ed a mipsel etch, using –foreign. This tells debootstrap not to run the second stage:
debootstrap –arch mipsel –foreign etch /space/debian-mipsel Then, I modified /etc/exports to allow the router to mount that chroot:
/space/debian-mipsel,sync,no_root_squash) I mounted it on the router:
ipkg install kmod-nfs
insmod sunrpc
insmod lockd
insmod nfs
mount -t nfs star:/space/debian-mipsel /debian -o nolock
mount -t proc /dev/null /debian/proc
I set up some swap space on the NFS mount (mandatory, or debootstrap’s second stage will fail):
ipkg install losetup
ipkg install kmod-loop
ipkg install swap-utils
dd if=/dev/zero of=/debian/swapfile bs=1M count=100
losetup /dev/loop/0 /debian/swapfile
mkswap /dev/loop/0
swapon /dev/loop/0
I chrooted inside /debian, and ran debootstrap’s second stage:
chroot /debian /bin/bash
debootstrap/debootstrap –second-stage
When you are done playing, you can disable the swap space and umount everything:
swapoff /dev/loop/0
losetup -d /dev/loop/0
umount /debian/proc
sleep 1 # or umount /debian will fail
umount /debian
If you want to re-mount everything, all you need to do is:
insmod sunrpc
insmod lockd
insmod nfs
mount -t nfs star:/space/debian-mipsel /debian -o nolock
mount -t proc /dev/null /debian/proc
losetup /dev/loop/0 /debian/swapfile
swapon /dev/loop/0
chroot /debian /bin/bash
That first stage/second stage split in debootstrap is really cool: it’s an easy way to run Debian anywhere, only requiring to be able to chroot at some point.

13 June 2006

Carlos Villegas: Woody / Sarge / Etch boot processes compared

Debian distributions booting times (up to kde with autologin) in the same PC:
The input-output data was just available for Etch as it requires a 2.6 linux kernel.

Carlos Villegas: Benchmarking between boot processes

For the project to improve debian boot process, I've installed debian woody and debian sarge to see the changes in debian releases. Currently installing debian etch.

The first bootcharts are here for woody and sarge with a clean installation with autologin to kde. Funny to see woody being faster with 32 seconds while sarge has 44 seconds.

For debian woody I had some problems to use bootchart but they were solved thanks to the kind help of Baruch Even. The errors were:
  • bootchart requires tmpfs filesystem, while the kernel 2.2 that comes with woody doesn't have tmpfs. It was solved by installing kernel 2.4 and substituting tmpfs with ramfs in the /sbin/bootchartd script.
  • initrd ignores the kernel call to bootchartd, as it ignores the arguments given to the kernel. It was solved by renaming /sbin/init (e.g. /sbin/init-moved) and making the file /sbin/init link to /sbin/bootchartd. At the end of the latter, there renamed /sbin/init is called. It's perhaps an ugly tweak but worked for our means.
On the other hand, the first deliverable draft was added to the svn repository and is available for comments here. It is still on an early phase and needs to be converted from tex to html.

Finally, I'm checking out SUSE's implementation of startpar together with insserv for parallel execution. It is interesting to see a boot process that looks to be already LSB-compliant.

24 March 2006

Christine Spang: Now That s One Sexy Shirt

Debian Women shirt Came yesterday (thanks Hanna and Steve!). And yes, I am much too lazy to fix the red eye right now as I’m on my way out the door. I finally have some geeky Debian bling to show off to the unconverted. Bwaha.

1 November 2005

Clint Adams: Chicken, you know, fundamentally bourgeois concept

Ahmet's Caucasian Walnut Chicken
  • 1 pound chicken breast
  • 10 oz. walnuts
  • 1 cup bread crumbs
  • 2 cloves garlic
  • 1 tsp. salt
  • 1 tsp. cayenne pepper
  • 2 tbsp. olive oil
Boil 1 pound of chicken breast. Save broth. Put a 10 oz. package of walnuts in food processor, grind. Add 1 cup bread crumbs, 2 cloves garlic, and 1 teaspoon salt plus one cup or more of reserved chicken broth to the walnuts in the food processor to make a paste. Shred the cooked chicken into fine pieces. Place chicken in a serving bowl and spread the walnut paste on top. Mix 1 teaspoon of cayenne pepper with 2 tablespoons olive oil and sprinkle mixture on top of walnut chicken mixture. Serve with pita bread. May be served warm or chilled.