Some PEP‘s have revolved around the problem of software versioning and dependency tracking.

So, in addition to having some blueprints such as those proposed by the Semantic Versioning guidelines, one needs specifics on how to integrate those practices in our day to day work with version control systems.

Setuptools saves the day by introducing versioning via git tags. In a post by Douglas Creager a strategy to use setuptools with git tags is devised. The workflow for tagging a new version results in:

1. Tag your release via git tag if the changes are significant.
2. Run python setup.py install, to bump the version on the filesystem.
3. git push.

The following code makes it happen:

# Fetch version from git tags, and write to version.py.
# Also, when git is not available (PyPi package), use stored version.py.
version_py = os.path.join(os.path.dirname(__file__), 'version.py')

try:
    version_git = subprocess.check_output(["git", "describe"]).rstrip()
except:
    with open(version_py, 'r') as fh:
        version_git = open(version_py).read().strip().split('=')[-1].replace('"','')

version_msg = "# Do not edit this file, pipeline versioning is governed by git tags"
with open(version_py, 'w') as fh:
    fh.write(version_msg + os.linesep + "__version__=" + version_git)

setup(name="yourpythonpackage",
      version="{ver}".format(ver=version_git),

As an addition to the git tags workflow proposed by Douglas, the ‘__version__’ attribute will be stored in version.py file. This allows the versions to be tracked even when our git repository is not available (i.e, via PyPi package installation), or when such a version needs to be queried from inside your own package.

Thanks Guillermo and Brad for the feedback and suggestions on this strategy.

UPDATE:

This documentation below has been superseeded by a much simpler, generalized and automated alternative: VirtualEnv-burrito.

Continue reading →

So you cannot wait for a few days when the new ubuntu release comes out with updated opennebula packages, but you need them right now. What are the options ?

1. As the seasoned UNIX guy you are, you go with the good old tar xvfz & compile it yourself, wasting time both by managing its intrinsic dependencies, build dependencies and whatnot: #FAIL
2. You get more intrepid and try to perform some black magic with apt-pinning, risking your system’s integrity if you don’t do it properly (thanks @alexmuntada!): #FAIL
3. You realize that you want manageable distribution packages as opposed to unmantainable and hard to share hacks and go for the recommended alternative to apt-pinning (using deb-src): #WIN

Now, the #BIGWIN would have been giving back to the community by building my own package and contributing it via PPA or whatever packaging system you use, but that good practice will come eventually

Så din webbläsaren funkar inte en dag, vad kan jag gjörde ? Kör GDB med firefox !


$ firefox -g
+ MOZDIR=/home/cristobal/.mozilla
+ LIBDIR=/usr/lib/firefox-3.6.10
+ APPVER=
+ META_NAME=firefox
+ GDB=/usr/bin/gdb
+ DROPPED=abandoned
+ which /usr/bin/firefox
+ NAME=/usr/bin/firefox
+ [ xfirefox != x ]
+ NAME=/usr/bin/firefox
+ basename /usr/bin/firefox
+ APPNAME=firefox
+ [ ! -f /usr/lib/firefox-3.6.10/firefox ]
+ want_debug=0
+ [ 1 -gt 0 ]
+ want_debug=1
+ shift
+ [ 0 -gt 0 ]
+ FOUND=
+ [ -d /home/cristobal/.mozilla/firefox ]
+ FOUND=firefox
+ FOUND_BETA=
+ BETA_LIST=
+ [ -d /home/cristobal/.mozilla/firefox-3.1 ]
+ [ -d /home/cristobal/.mozilla/firefox-3.5 ]
+ [ -d /home/cristobal/.mozilla/firefox-3.6 ]
+ [ firefox != -a != ]
+ [ != -a firefox = ]
+ [ 1 -eq 1 ]
+ [ ! -x /usr/bin/gdb ]
+ mktemp /tmp/mozargs.XXXXXX
+ tmpfile=/tmp/mozargs.bnrfme
+ trap [ -f "/tmp/mozargs.bnrfme" ] && /bin/rm -f --
"/tmp/mozargs.bnrfme" 0 1 2 3 13 15
+ echo set args
+ echo sh /usr/lib/firefox-3.6.10/run-mozilla.sh /usr/bin/gdb
/usr/lib/firefox-3.6.10/firefox-bin -x /tmp/mozargs.bnrfme
sh /usr/lib/firefox-3.6.10/run-mozilla.sh /usr/bin/gdb
/usr/lib/firefox-3.6.10/firefox-bin -x /tmp/mozargs.bnrfme
+ CMDNAME_USER=firefox sh /usr/lib/firefox-3.6.10/run-mozilla.sh
/usr/bin/gdb /usr/lib/firefox-3.6.10/firefox-bin -x
/tmp/mozargs.bnrfme
GNU gdb (GDB) 7.1-ubuntu
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "i486-linux-gnu".
For bug reporting instructions, please see:
...
Reading symbols from /usr/lib/firefox-3.6.10/firefox-bin...(no
debugging symbols found)...done.

(gdb) bt
#0 0xb7fe2422 in __kernel_vsyscall ()
#1 0xb7fbb245 in sem_wait@@GLIBC_2.1 () from /lib/tls/i686/cmov/libpthread.so.0
#2 0xacfe90e9 in event_wait () from /usr/local/lib/libtokenapi.so
#3 0xad32a4a4 in CInternalThreadObject::EventHandlingThread() () from
/usr/local/lib/personal/libP11.so
#4 0xad32dec6 in CHandleTokenEventThread::Run() () from
/usr/local/lib/personal/libP11.so
#5 0xacfe8934 in CThread_posix::RunInternal() () from
/usr/local/lib/libtokenapi.so
#6 0xacfe8981 in CThread_posix::RunProcess(void*) () from
/usr/local/lib/libtokenapi.so
#7 0xb7fb496e in start_thread () from /lib/tls/i686/cmov/libpthread.so.0
#8 0xb638ca4e in clone () from /lib/tls/i686/cmov/libc.so.6


Visst, /usr/local/lib/libtokenapi.so är den skyldige. Följa en andra post här om du vill fixa det, lycka till !

It took a while to figure out this little annoying config issue while setting my android phone for development, so here it goes (thanks to comments on androidboss.com).

At the time of writing these lines, if you follow the official android documentation on this topic, you’ll probably get this frustrating error message.

$ ~/bin/android/tools/adb devices
List of devices attached 
????????????	no permissions

Then, to fix it, you should edit your “/etc/udev/rules.d/50-android.rules” that way:

SUBSYSTEM==”usb”, SYSFS{idVendor}==”0fce”, MODE:=“0666″

Please, mind the “:=” on MODE, instead of just “=”. This last one doesn’t work on Ubuntu 10.04. After restarting the udev daemon connecting/desconnecting the device, you should get something like:

$ ~/bin/android/tools/adb devices
List of devices attached 
CB511JDU5Y	device

Hope that helps !

UPDATE: Filed the issue on android bugtracker.