I’ve been at it for about 2 weeks now with what little time I have and the original suite consists of two programs: rqp and rqs. These two programs were a result of a rewrite of the “srpm” PHP program that Stew Benedict wrote years ago for the Mandriva secteam (and which has proven invaluable of the years). It handled only src.rpm files, so I rewrote and extended it to handle binary and source rpm files (rqp and rqs respectively). It was a quick-n-dirty extension that was used for a few years on the Mandriva secteam and worked really well (and probably is still working well for them).

I’ve gotten rqp converted to Python and it’s working quite well. Because rqp and rqs share a *lot* of functions, I wanted to write rqp.py and rqs.py and have a shared module between them (rq.py) and this is where I’m having issues. Does anyone know how to have a module get access to an object from the calling program? For instance, rqp uses the optparse module to nicely handle the commandline arguments, but a lot of the modules use options.foo to look up arguments that were passed. The functions in rq.py (the module) can’t seem to get the value of options, and while I could put the optparse stuff in the module, it would leave the actual rqp and rqs programs really really small (and I’d have to either put in two functions because the two programs use different syntax). So I’ve got in rqp.py:

import rq

which works ok, but if rq.db_connect() requires options.database (for instance), it can’t get it. So in rq.py, I tried doing a circular import or whatever it’s called by doing:

import options from rqp

But this doesn’t want to work either. The output looks quite sad:

% ./rqp.py -d
rqp 0.2 ($Id: rqp 275 2009-03-07 22:34:15Z vdanen $)

Traceback (most recent call last):
  File "./rqp.py", line 548, in 
    import rq
  File "/Users/vdanen/svn/scripts/rq/trunk/rq.py", line 11, in 
    from rqp import options
ImportError: cannot import name options

There has to be a way to make the options variable (and one or two others I think) accessible to the module, but I haven’t been able to find a way to do it. Does anyone know how this can be accomplished?

Here’s the link: If programming languages were religions….

_arguments:comparguments:303: invalid argument: ARG

Looks like the reason is that the subversion developers changed “arg” to “ARG”. So when I googled I found this helpful post:

ZSH Tab Completion Fix for Subversion 1.5 which basically points to this new _subversion functions file to be plopped into the zsh functions directory (/usr/share/zsh/4.3.4/functions; change the version to suit of course — the directory may also be slightly different on Linux vs OS X).

Now tab completion works properly and life is good. =)

Not only that, however, but subversion will upgrade parts of your working copy piecemeal. For instance, I keep all my web development stuff in ~/svn/websites/. So after upgrading to 1.5.2 today I did some work in ~/svn/websites/intranet/ and that directory, and it’s subdirectories, were upgraded to the new format. The top-level directory, however, and the rest of the working copy, were not (they were still using format 8 rather than format 9).

I guess with a CLI client this might not matter so much, but it caused me some grief using Cornerstone, a commercial svn client. Fortunately, the author is super-responsive and pointed me to this change-svn-wc-format.py script which I can use to update all my working copies (I’m not trusting subversion to do it properly for me right now).

Anyways, if anyone else gets in this same boat, here’s some info on how to resolve it. I like using Cornerstone on my mac (it’s about the only GUI svn client I can stand); otherwise I’d be using the CLI client and probably never would have found this.

The problem, in my particular case, is that my hoster is extremely anal about mail relays. If the from address isn’t locally-deliverable, it punts the message with a “relay not permitted”. This is simply foolish, and I’ve already complained, but I have my doubts they’ll change anything. In my case, the linsec.ca site is hosted at my domain hoster, but the mail for linsec.ca is handled by Google. So when a message goes out from wordpress@linsec.ca (regardless of whether it’s a deliverable address or not, regardless of whether I define an email address on the domain server (that would never really get mail, but I was hoping it would trick exim somewhat)), it gets punted as a relayed address because the MX records for linsec.ca don’t point to the server.

This could all be extremely easily avoided by letting people change the From address in WordPress. And it’s such a stupidly simple hack. So when I upgraded to the latest WordPress and found it *still* didn’t allow it, I finally implemented a quick fix and am putting it here for others who face the same irritation.


Index: wp-config.php
===================================================================
--- wp-config.php (revision 1109)
+++ wp-config.php (working copy)
@@ -23,6 +23,9 @@
// to enable German language support.
define ('WPLANG', '');

-?>
\ No newline at end of file
+?>


And that’s it. This would be so easy to have implemented upstream, I’m not sure why they haven’t done it already. Now I can set the from domain to something that is hosted on that machine and mails are delivered.