Tuesday, December 23, 2008

Sandisk MP3 player problems on hardy

My Sandisk mp3 player isn't mounting properly under hardy:

[ 3063.523223] usb 5-5: new high speed USB device using ehci_hcd and address 3
[ 3065.287712] ehci_hcd 0000:00:1d.7: port 5 reset error -110
[ 3065.287781] hub 5-0:1.0: hub_port_status failed (err = -32)

Removing the module with 'sudo modprobe -r ehci_hcd' let it mount properly as suggested in the bug report.

Thursday, December 18, 2008

GDB tips


  • gdb --args ./binary arg1 arg2
  • You can do make and make install from inside gdb!
  • list - see where you are in the code
  • set follow-fork-mode child - as it suggests, follow the child at forks, default is parent.
  • Get core by setting 'ulimit -c unlimited' and debug with gdb ./binary pid.core Print variables and use up/down to traverse the call stack.
  • info break for a list of breakpoints.
  • finish - execute till return.
  • To print 100 bytes of memory pointed to by a pointer ppoint:
    x/100ub ppoint

Wednesday, December 17, 2008

Why darcs is better than bzr

I am all in favour of distributed revision control. Recently I tried bazaar (bzr) because it has superior windows support compared to any of the other candidates (git, darcs, mercurial etc.), and unfortunately I have to occasionally develop on windows. I was very disappointed by its 'send' functionality however. Here is my workflow that is broken:

How I want it to work:

  1. bzr init myrepo
  2. email repo to another disconnected network (email is the only comms available), where someone else works on the code as well
  3. bzr commit change1 change2 change3
  4. bzr send change1 change2 change3 -o bundle
  5. email bundle

Instead, I have to keep another copy of every repository that is the 'synced' version. I have about 20 repos which means I now need 40 directories, what a PITA. Remind me how this is better than subversion again? I'm starting to forget. So this is what I have to do:

  1. bzr init myrepo
  2. email repo to another disconnected network (email is the only comms available), where someone else works on the code as well
  3. cp myrepo myrepo_synced
  4. cd myrepo; bzr commit change1 change2 change3
  5. bzr send change1 change2 change3 -o bundle myrepo_synced
  6. email bundle

Keeping another repo just to keep track of synced state is exactly the sort of annoyance that distributed revision control is supposed to fix. Darcs solves this problem in a sensible manner, each bundle contains metadata for patch dependencies (revisions) that must be present for the patch to be applied successfully. Having to re-send the entire repository (as suggested in a mailing list thread - 'send' against null repo) for small changes is ridiculous.

Saturday, December 13, 2008

Google SPF checking FAIL

Google inbound SPF checking is shit. Even for hardfail specifications, it delivers the email to the user's inbox with no visual indication it has failed SPF. See below for an email that was delivered normally to my inbox when it should have been dropped, or at the very least marked as evil.


Delivered-To: xxxxxx@gmail.com
Received: by 10.210.77.11 with SMTP id z11cs98143eba;
Sat, 13 Dec 2008 21:10:18 -0800 (PST)
Received: by 10.150.53.2 with SMTP id b2mr9887397yba.167.1229231416967;
Sat, 13 Dec 2008 21:10:16 -0800 (PST)
Return-Path:
Received: from out1.smtp.messagingengine.com (out1.smtp.messagingengine.com [66.111.4.25])
by mx.google.com with ESMTP id 5si9650165ywd.41.2008.12.13.21.10.16;
Sat, 13 Dec 2008 21:10:16 -0800 (PST)
Received-SPF: fail (google.com: domain of evil@xxxxx.com does not designate 66.111.4.25 as permitted sender) client-ip=66.111.4.25;
Authentication-Results: mx.google.com; spf=hardfail (google.com: domain of evil@xxxxxxx.com does not designate 66.111.4.25 as permitted sender) smtp.mail=evil@xxxxxxxx.com
Received: from compute1.internal (compute1.internal [10.202.2.41])
by out1.messagingengine.com (Postfix) with ESMTP id 34BA11E6BF8
for ; Sun, 14 Dec 2008 00:10:16 -0500 (EST)
Received: from web7.messagingengine.com ([10.202.2.216])
by compute1.internal (MEProxy); Sun, 14 Dec 2008 00:10:16 -0500
Received: by web7.messagingengine.com (Postfix, from userid 99)
id 0E9F4545AD; Sun, 14 Dec 2008 00:10:16 -0500 (EST)
From: "xxxxxxxx"
To: xxxxxxxxxx@gmail.com
Content-Disposition: inline
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="ISO-8859-1"
MIME-Version: 1.0
X-Mailer: MessagingEngine.com Webmail Interface
Subject: testing spf
Date: Sun, 14 Dec 2008 00:10:16 -0500

sdflskjdf