[08:10] <asac> moin moin
[08:38] <ogra> yawn yawn
[08:39] <cooloney_> asac: ogra morning guys
[08:40] <ogra> cooloney, hey, thanks for poking the NIC issue :)
[08:40] <asac> dmart: there?
[08:40] <asac> hi cooloney
[08:42] <cooloney> ogra: no problem, i got no clue about that, so asked for help. heh
[08:43] <ogra> gah, seems i dont het uboot off my back today ...
[08:43] <ogra> *get
[09:34] <ogra> asac, no go for the NIC fix
[09:54] <asac> huh?
[09:54] <asac> ogra: thought you ignore that until we get input from fsl
[10:19] <ogra> asac, FSL attached a patch to bug 507887#
[10:19] <ubot4> Launchpad bug 507887 in uboot-imx "NIC not properly initialized in uboot code" [High,Confirmed] https://launchpad.net/bugs/507887
[10:20] <ogra> but seems its only half the fix
[10:26] <asac> ogra: cool. and not ;)
[10:26] <ogra> right
[10:26] <ogra> there were 3 patches overall attached to three bugs
[10:26] <ogra> sadly none for the MMC issue and all of them against 2009.08
[10:27] <ogra> so nothing that helps us
[10:27] <ogra> the L2 fix looks intresting though
[10:27] <asac> the NIC patch looks simple enough
[10:27] <asac> to check if it would work on .01
[10:27] <asac> where is the L2 patch attached?
[10:28] <ogra> mail
[10:28] <ogra> the NIC patch doesnt work
[10:28] <ogra> as i said above (and in teh bug), we seem to miss the actual patch that implements the function
[10:29] <asac> heh. can you reply in bug and to mail?
[10:29] <ogra> i did
[10:29] <ogra> well, not by mail though
[10:30] <asac> kk
[10:30] <ogra> see commants 3,4 and 5 on bug 507887
[10:30] <ubot4> Launchpad bug 507887 in uboot-imx "NIC not properly initialized in uboot code" [High,Confirmed] https://launchpad.net/bugs/507887
[13:48] <ogra> fsck from util-linux-ng 2.16
[13:48] <ogra> e2fsck 1.41.9 (22-Aug-2009)
[13:48] <ogra> /dev/sda6: clean, 146136/2321984 files, 948823/9277521 blocks (check deferred; on battery)
[13:49]  * ogra pokes his babbage with a pointy stick ...
[13:49] <ogra> you got no battery you darn thing !!!
[13:51] <ogra> ogra@babbage2:~$ sudo cat /proc/apm
[13:51] <ogra> 1.13 1.2 0x02 0xff 0xff 0xff -1% -1 ?
[13:51] <ogra> mumble
[14:24] <asac> bug 456659
[14:24] <ubot4> Launchpad bug 456659 in linux-fsl-imx51 "suspend/resume failure on imx51" [High,In progress] https://launchpad.net/bugs/456659
[14:25] <asac> bug 488267
[14:25] <ubot4> Launchpad bug 488267 in ffmpeg "ffmpeg should be built with -marm for lucid on armel" [Low,Fix released] https://launchpad.net/bugs/488267
[15:16] <ogra> cooloney, do you know if the FSL kernel patches change anything wrt /proc/apm output ?
[15:28] <asac> https://wiki.ubuntu.com/MobileTeam/ReleaseStatus/Lucid
[15:28] <asac> ogra: plars: GrueMaster: persia: dyfet: ^^
[15:29] <ogra> asac, i think the fact that we have an outdated uboot is also RC (if RC means release critical :) )
[15:30] <ogra> i.e. i doubt we'll ever get a fix for the MMC issues for 2009.01 ... so i think they should still be on release team radar
[15:30] <ogra> (which in turn enforces us to update to .08)
[15:30] <asac> ogra: well. thats covered
[15:31] <asac> or do we have a bug for that?
[15:31] <asac> imo its well covered by the other two problems
[15:31] <asac> which reminds me that i should RC the other bug if its not yet
[15:31] <ogra> we have a bug for the MMC issue
[15:31] <ogra> not for "hey we chose an old version" :)
[15:31] <asac> ogra: can you target for lucid + milestone alpha-3
[15:31] <asac> and gimme bug id ;)
[15:31]  * ogra digs
[15:32] <ogra> Bug 506761
[15:32] <ubot4> Launchpad bug 506761 in uboot-imx "lucid uboot hangs on fatload uImage on fsl TO2 TO2.5 and TO3" [Medium,Confirmed] https://launchpad.net/bugs/506761
[15:32] <asac> thx
[15:33] <asac> ogra: why is that wontfix for lucid?
[15:33] <asac> that demotes that to non-RC ;)
[15:33] <ogra> uh
[15:33]  * asac changes that
[15:33] <asac> also its medium ;)
[15:33] <asac> thats overly polite -> critical now
[15:34] <ogra> you did set the Wontfix :P
[15:34] <ogra> and the Medium :)
[15:34] <asac> really?
[15:34] <asac> ouch
[15:34] <asac> oh... maybe when i thought that the paritioning was good enough
[15:34] <ogra> right
[15:34] <ogra> right after the commant about partitioning
[15:35] <asac> ogra: the version revision thing is not RC?
[15:35] <ogra> because it "doesnt block release"
[15:35] <ogra> not for now imho
[15:35] <asac> dyfet: did busybox -marm work?
[15:35] <ogra> as long as FSL stands to their promises and we get a fixed release
[15:35] <asac> yeah
[15:35] <asac> ok
[15:36] <dyfet> asac: yes
[15:36] <ogra> asac, i'm about to upload busybox
[15:36] <dyfet> asac: already posted for sponsor
[15:36] <ogra> Bug 511197
[15:36] <ubot4> Launchpad bug 511197 in busybox "fails to build on arm lucid (thumb2)" [Undecided,Confirmed] https://launchpad.net/bugs/511197
[15:36] <asac> dyfet: where?
[15:36] <ogra> got that in my queue ...
[15:36] <asac> ah in the bug
[15:36] <asac> just ping me here ;)
[15:36] <ogra> just didnt get to it yet
[15:36] <asac> i read bugmail at most twice a decade :-P
[15:36] <asac> lol
[15:37] <ogra> asac, dont worry, i need some sponsoring points anyway ;)
[15:38] <ogra> asac, did you talk with doko about Bug 417009 (shipping the jaunty libgcc_uno.so
[15:38] <ogra> )
[15:38] <ubot4> Launchpad bug 417009 in openoffice.org "all openoffice apps die in 'com::sun::star::ucb::InteractiveAugmentedIOException' on armel in karmic" [High,Confirmed] https://launchpad.net/bugs/417009
[15:39] <ogra> its still "confirmed" so i assume we still ship the hack
[15:40] <ogra> asac, if you want the hack gone that should be on our list
[15:43] <asac> ogra: talked to doko about this today
[15:43] <ogra> ah, good
[15:43] <ogra> does he see a chance to get that fixed ?
[15:43] <asac> he said its not RC if we ensure that we build it again from fresh sources
[15:43] <asac> aka the lib
[15:44] <ogra> well, we still ship old crap :)
[15:44] <asac> not RC because the fix is so unlikely, that it doesnt make sense to stirr up release team
[15:44] <ogra> ok
[15:44] <asac> plars: so after talking to doko about python dove killage, he mentioned that python wasnt even build in lucid yet, so maybe the python2.6 package that is building right now, will help
[15:50] <ogra> fsck from util-linux-ng 2.16
[15:50] <ogra> e2fsck 1.41.9 (22-Aug-2009)
[15:50] <ogra> /dev/sda6 has been mounted 40 times without being checked, check forced.
[15:50] <ogra> Pass 1: Checking inodes, blocks, and sizes
[15:50] <ogra> GEEZ !!!!
[15:50] <ogra> i only added a printf !
[15:50] <ogra> why the heck does it not think its on battery anymore °!
[15:51]  * ogra reboots again
[15:52] <asac> ogra: wrong negation? feels ok if it doesnt think its on battery ;)
[15:52] <asac> unless you have a battery :-P
[15:52] <asac> oh
[15:52]  * asac should read more backlog
[15:52] <asac> good
[15:52] <ogra> well, you saw the code before
[15:52] <asac> ogra: do you get a warning during build?
[15:52] <asac> like missing prototype?
[15:52] <ogra> i just added a printf to print out the value of the ac
[15:52] <ogra> nope
[15:52] <asac> so stdio is probably included ;)=
[15:52] <asac> ?
[15:52] <asac> ok
[15:53] <ogra> lets see, probably it was actually an enforced check because 40 mounts were done
[15:53] <asac> does it build with all warnings?
[15:53] <asac> maybe
[15:53] <ogra> mountall: Could not connect to Plymouth
[15:53] <ogra> fsck from util-linux-ng 2.16
[15:53] <ogra> e2fsck 1.41.9 (22-Aug-2009)
[15:53] <ogra> /dev/sda6: clean, 146112/2321984 files, 949695/9277521 blocks
[15:53] <ogra> init: plymouth-log main process (3168) terminated with status 111
[15:53] <ogra> hmm, it really doesnt see the battery anymore
[15:53] <ogra> now thats weird
[15:55] <ogra>                 if (fscanf(f, "%s %s %s %x", tmp, tmp, tmp, &acflag) != 4)
[15:55] <ogra>                         acflag = 1;
[15:55] <ogra> is the original code
[15:56] <ogra>                 if (fscanf(f, "%s %s %s %x", tmp, tmp, tmp, &acflag) != 4)
[15:56] <ogra>                         printf("acflag is: %x", acflag);
[15:56] <ogra>                         acflag = 1;
[15:56] <ogra> is what i made out of it
[15:56] <ogra> it doesnt exec the printf ... nor does it set acflag
[16:23] <plars> asac: cool, will give it a try
[16:48] <asac> uff
[16:48] <asac> so next week i want a better meeting
[16:48] <asac> ;)
[16:48] <asac> more success to report
[16:48] <asac> please make that happen :)
[16:48] <ogra> heh
[16:49] <ogra> at least you didnt have to report many disasters :)
[16:56] <asac> ogra: when did pitti send that announce?
[16:56] <asac> was that in a thread?
[16:56] <asac> i cant even find it ;)
[16:56] <ogra> you mean the moving of people from rookery to a new machine ?
[16:56] <asac> no. the moving of the work itesm from macaroni to people ;)
[16:57] <asac> http://people.canonical.com/~pitti/workitems/canonical-mobile.html
[16:57] <asac> vs
[16:57] <asac> http://macaroni.canonical.com/~pitti/workitems/canonical-mobile.html
[16:57] <ogra> hmm
[16:58] <ogra> asac, ubuntu-platform@
[16:58] <asac> ogra: right. but was that standalone mail or a reply to an existing thread?
[16:58] <ogra> 20.01.2010 14:25:05
[16:58] <ogra> standalone
[16:58] <asac> i have all that in my main inbox
[16:59] <ogra> with a big ANNOUNCE tag
[16:59] <asac> ok i dont have it ;)
[16:59] <ogra> look for ANNOUNCE in the subject
[16:59] <asac> guess it was killed in a my eager zero inbox effort ;)
[16:59] <ogra> heh
[17:01] <ogra> hmm, so powertop seems to miss some kernel options on imx51
[17:58] <armin76> asac: what about snapdragon? :)
[18:01] <asac> fta: i will demote the ffmpeg depends for this upload ... so its not rejected because depends arent fulfillable
[18:01] <asac> we can put that back when its in
[18:02] <fta> asac, /me sad. why not use !armel instead?
[18:02] <asac> fta: we have it on armel. just not in the archive
[18:02] <asac> its not because of armel ... just because of archive
[18:03] <asac> i dont want to block the chromium upload on first getting the other stuff up
[18:03] <fta> why is it rejected in the 1st place?
[18:03] <asac> if its not fulfillable
[18:03] <asac> then it cant go in
[18:03] <asac> all depends need to be there
[18:03] <asac> so its recommends now.
[18:03] <asac> you can drive the ffmpeg als in
[18:03] <fta> why not submit it first?
[18:03] <asac> its just licensing for that
[18:03] <asac> because i dont want to wait any longer
[18:03] <fta> *sigh* ok
[18:03] <asac> you could have uploaded it ;)
[18:04] <asac> would be great if you could do.
[18:19] <armin76> asac: chromium now fails for me :P
[18:19] <armin76>   export LD_LIBRARY_PATH=/var/tmp/portage/www-client/chromium-9999/work/chromium-9999/out/Release/lib.host:/var/tmp/portage/www-client/chromium-9999/work/chromium-9999/out/Release/lib.target:$LD_LIBRARY_PATH; cd v8/tools/gyp; mkdir -p /var/tmp/portage/www-client/chromium-9999/work/chromium-9999/out/Release/obj.target/geni; "/var/tmp/portage/www-client/chromium-9999/work/chromium-9999/out/Release/mksnapshot" "/var/tmp/portage/www-client/chrom
[18:19] <armin76> ium-9999/work/chromium-9999/out/Release/obj.target/geni/snapshot.cc"
[18:19] <armin76> pure virtual method called
[18:19] <armin76> terminate called without an active exception
[18:22] <armin76> what was that error about?
[18:23] <armin76> and i'm using gcc-4.3
[18:35] <asac> that was about -fno-strict-alias breakage for ggc 4.3
[18:35] <asac> if you are really sure everything uses gcc 4.3 on your system now then i dont know
[18:35] <asac> but i would expect it doesnt
[18:35] <asac> you can try -fno-tree-sink
[18:36] <asac> grab the patch from our packaging .head
[18:36] <asac> no_tree_sink_v8.patch
[18:36]  * asac out
[18:38] <armin76> well, but the -fno-tree-sink is used only if gcc_version=44
[18:38] <armin76> and it worked before, i'm wondering if you now need gcc-4.4 :P
[19:32] <plars> new python didn't help btw
[20:47] <asac> damn
[20:47] <asac> plars: there?
[20:48] <asac> plars: so you basically can go to console, and make the board hang by running import pybootchargui right?
[20:48] <plars> asac: yes
[20:48] <plars> asac: right, that one and uno both seem to do it so far.  Haven't found others yet
[20:48] <asac> plars: so idea is to run python -v
[20:49] <asac> that should spit out the modules that get implicitly imported
[20:49] <asac> if you | tee that to a file you might be able to try each of those until you find which import causes this
[20:49] <plars> ah, neat, didn't know about that
[20:49] <asac> right
[20:50] <plars> ok, the last thing I see it trying to import was cStringIO
[20:50] <plars> need to reboot, sec
[20:50] <asac> yeah
[20:50] <asac> so check if that alone causes it ;)
[20:50] <asac> then we can check what it does etc.
[20:50] <asac> also ... did you find any module you could import without a hang?
[20:51] <plars> asac: yes, plenty.  These had been the only two so far that I found that caused it to hang
[20:52] <asac>  cat ./Modules/cStringIO.c  | pastebinit
[20:52] <asac> http://pastebin.com/f51e45d28
[20:52] <plars> cStringIO imports ok, must be something after that
[20:53] <asac> plars: so we dont see the module that fails to import?
[20:54] <asac> e.g. it hangs before the dump?
[20:54] <plars> asac: correct
[20:54] <asac> plars: can you paste the current import list?
[20:56] <plars> asac: I don't think it's an import from there...
[20:56] <plars> asac: importing socket gives me the same impot list with python -v, and that's the last thing that this module imports
[20:57] <asac> from where?
[20:58] <asac> let me check something
[20:58] <plars> asac: I'm still looking at uno
[20:59] <asac> ah
[20:59] <asac> http://paste.ubuntu.com/360871/
[21:00] <asac> thats import uno on x86
[21:00] <asac> >>> import pybootchartgui
[21:00] <asac> import pybootchartgui # directory /usr/lib/pymodules/python2.6/pybootchartgui
[21:00] <asac> # /usr/lib/pymodules/python2.6/pybootchartgui/__init__.pyc matches /usr/lib/pymodules/python2.6/pybootchartgui/__init__.py
[21:00] <asac> import pybootchartgui # precompiled from /usr/lib/pymodules/python2.6/pybootchartgui/__init__.pyc
[21:00] <asac> thats the thing i get for bootchart
[21:00] <asac> so its not that easy :(
[21:08] <asac> plars: do you know about other modules that cause this hang?
[21:09] <plars> asac: those are the only two I've found so far
[21:10] <asac> # pybootchartgui/__init__.pyc has bad magic
[21:10] <asac> what does that mean?
[21:13] <asac> plars: maybe removing the precompiled bits helps? sudo rm /usr/lib/pymodules/python2.6/pybootchartgui/*.pyc
[21:13] <asac> sorry...  just trying random things
[21:18] <asac> >>> import pybootchartgui
[21:18] <asac> import pybootchartgui # directory pybootchartgui
[21:18] <asac> # pybootchartgui/__init__.pyc has bad magic
[21:18] <asac> import pybootchartgui # from pybootchartgui/__init__.py
[21:18] <asac> # wrote pybootchartgui/__init__.pyc
[21:18] <asac> ah ... now i see where its coming from.
[21:18] <asac> the package ships an old __init__.pyc here:
[21:18] <asac> /usr/share/python-support/pybootchartgui/pybootchartgui/__init__.pyc
[21:18] <asac> remove that ;)
[21:19] <plars> asac: interesting
[21:19] <plars> I don't have that file
[21:20] <plars> and I don't see any .pyc file in the dpkg -L list
[21:20] <asac> odd
[21:20] <asac> dpkg -L pybootchartgui  | grep pyc$
[21:20] <asac> /usr/share/python-support/pybootchartgui/pybootchartgui/__init__.pyc
[21:20] <asac> well. its karmic
[21:20] <plars> however after the earlier rm, I seem to be able to run pybootchartgui
[21:20] <asac> so its probably clean ;)
[21:20] <asac> cool ;)
[21:20] <plars> so maybe... but what about uno?
[21:21] <plars> and where did some stray .pyc come from? this was a new install
[21:21] <asac> plars: have you tried to reinstall pybootchargui after python upgrade?
[21:21] <asac> maybe give that a try
[21:21] <plars> no
[21:21] <asac> maybe it needs just fresh .pyc
[21:21] <asac> the other directory i asked you to clean is generated during install
[21:21] <asac> by python-central or something
[21:22] <asac> not sure if tere are triggers that recreate all .pyc if python is updated though
[21:22] <asac> to be sure check if reinstalling still keeps pybootchartgui working
[21:22] <plars> also...
[21:22] <plars> sudo rm /usr/lib/python2.6/dist-packages/uno.pyc
[21:22] <plars> import uno still hangs
[21:23] <asac> plars: uno is something different. thats ooo
[21:24] <asac> thats a different beast
[21:24] <plars> asac: right, but symptom is the same
[21:24] <asac> yes
[21:24] <asac> plars: so does reinstalling pybootchartgui make keep it working?
[21:24] <asac> ;)
[21:24] <plars> asac: have to wait for the reboot
[21:24] <plars> I hung it again trying uno
[21:25] <asac> ah ok
[21:26]  * asac checks something
[21:27] <plars> asac: pybootchartgui seems to be working now
[21:28] <asac> very good
[21:30] <asac> plars: have you tried to remove /usr/lib/python2.6/socket.pyc as well?
[21:30] <plars> asac: no, but importing socket seemd ok
[21:30] <plars> asac: no help
[21:30] <asac> ok.
[21:31] <asac> so i somehow dont get rid of the thought that the uno issue has something to do with the
[21:31] <asac> uno thin we have in OOO
[21:31] <asac> e.g. the bug that requires us to ship the jaunty so
[21:31] <asac> i am not sure if that is pyuno.so though
[21:31] <asac> do you remember?
[21:31] <plars> asac: no idea, sorry
[21:31] <asac> the bug about this was https://bugs.edge.launchpad.net/ubuntu/+source/binutils/+bug/436617
[21:32] <ubot4> Launchpad bug 436617 in binutils "ARM unwind table linker processing broke OO's uno2cpp" [High,Confirmed]
[21:32] <plars> will be interesting to boot the next livecd if it has the new python in it and see if it works
[21:32] <asac> let me poke chris
[21:38] <asac> plars: so ... pyuno.so pulls in that ugly jaunty libgcc3_uno.so
[21:38] <asac> through libpyuno.so
[21:39] <asac> somehow
[21:39] <asac> guess thats not build with thumb2
[21:39] <plars> I see
[21:39] <plars> I'm afraid that all of this may be hit or miss until x0
[21:40] <plars> from the sounds of things, this all likely relates back to that
[21:40] <asac> the gcc3_uno.so thing probably yes.
[21:44] <asac> plars: anyway, so with just removing pyuno we get a booting desktop now?
[21:44] <asac> plars: if thats the case thats all we can hope for ;)
[21:44] <asac> and we should consider to just do it to get working images until we get X0 to test
[21:44] <plars> asac: oh, pyuno was never preventing it from booting, just happened to be another pythong module I noticed that caused trouble.  Previously I was able to get it booting by taking pybootchartgui out of the init
[21:45] <plars> asac: so no reason to remove uno
[21:45] <asac> plars: cool. so basically with a reinstalled bootchart it works?
[21:45] <plars> asac: seems to be, tomorrows image will be good to double-check with
[21:45] <asac> guess we have flaky but working images tomorrow with some luck then ;)
[21:46] <asac> plars: great. with that you can go and do more positive stuff until we get news on hardware/kernel front i guess. thanks a lot!!!
[21:46] <plars> asac: thanks for all your help!
[21:48] <asac> no thanks to you ... at least i can somehow sleep again ;)
[21:48] <asac> the good I get out of this is that if we have everything recompiled the Y1 boards might become more and more stable ;)
[21:53] <plars> asac: I didn't think you ever slept!
[21:53] <asac> its those things i tell you :-P
[21:54] <asac> actually i skip the timezone lag for sprints this way
[21:54] <asac> i just keep my live going in central US time ;)
[21:54] <asac> anti-jetlag method its called
[21:55] <plars> heh
[23:19] <asac> persia: http://pastebin.com/f429b20ae ... anything else you would like to see there?
[23:23] <persia> asac: From policy 4.1.4, missing bits include:
[23:24] <persia> 1. how to generate the fully patched source, in a form ready for editing, that would be built to create Debian packages.
[23:24] <persia> (most people do this with debian/rules patch, which might work for your CDBS mess)
[23:25] <persia> 3. Remove source modifications that are currently being applied when building the package
[23:25] <persia> This might just be telling someone to unroll the tarball, but I'm not sure.
[23:26] <persia> You've hit #2 and #4 well, and added lots of other interesting stuff :)
[23:30] <asac> persia: 1. is covered in patching
[23:30] <asac> section
[23:30] <asac> imo
[23:30] <asac> and 3. sounds odd ;)
[23:30] <asac> not sure what that means
[23:30] <asac> some patches are feature patches, some are needed to build (or at least there might be patches)
[23:31] <asac> i dont think anyone can ask for keeping those separately documented ;)
[23:31] <asac> for me patching section also tells 3.
[23:31] <persia> asac: You7re supposed to provide a step-by-step guide, not say "start a local build and break in" :)
[23:31] <asac> yeah. thats bad ;) but debian/rules patch is broken :-P
[23:31] <asac> the joy of cdbs
[23:31] <persia> I've always interpretedf "remove source modifications" as being both classes of packages.  Someone who does silly things gets to keep both parts.
[23:32] <asac> anyway, for a reasonably educated guy this shouldnt be a problem ;)
[23:32] <persia> You know, lots of people don't use CDBS anymore :)
[23:32] <asac> right. but kick off a local build is quite generic ;)
[23:32] <asac> you can even use the instructions in the section above ;)
[23:32] <asac> good. i think all is fine. thanks!
[23:32] <persia> Well, but it's also a non-ideal way to do it, because you have to break it.
[23:33] <asac> thats a bug
[23:33] <asac> debian/rules patch should just work, but last time i checked it didnt
[23:33] <persia> There's probably a CDBS rule like secret-internal-quilt-patched-but-not-built-but-you-don't-know-the-rule-name: rule that one could call.
[23:33] <asac> heh. we tried a bit
[23:33] <asac> its a bug in the tarball.mk i think
[23:33] <persia> Oh.  Ugh.
[23:33] <asac> we have that in firefox etc.
[23:34] <persia> Did I mention that tarball-in-tarball is ugly too :)
[23:34] <asac> but let me assure oyu its not a practical problem
[23:34] <asac> you want to edit and then usually continue build anyway ...
[23:34] <asac> yes, but without tarball in tarball you dont want to build the sources regularly
[23:34] <persia> Anyway, your README.source is massively better than not having one at all, especially for such a confusing package using a strange special private CDBS derivative.
[23:34] <asac> heh
[23:35] <persia> I understand the problem, I just think the solution is more RAM :)
[23:42] <asac> so with enough ram, even cdbs-edit-patch would be great experience ;)
[23:43] <persia> Well, not as bad, assuming the content was fully cached or one is operating on a tmpfs
[23:44] <persia> I'd probably still use quilt, but that's just because I've come to not like digging through CDBS when I wanted to figure out how to do something.  dh(1) makes my life easier.
[23:46] <asac> aha