Some of these errors and their explanation:

• if a == None:
  Really common. None is a singleton, so you can (well, actually, have) to compare to it like ‘if a is None‘ or ‘if a is not None‘.
• if (condition):
  This is not really pythonic, if doesn’t take () around the condition in python, () purpose is grouping, you can use them in an if but only to clarify a really complex condition or similar stuff. Please don’t clutter code with unneeded characters.
• if len(list):
  This is a misunderstanding of Python way of things, any empty sequence (string, list, tuple) is False. So if you want to make sure a list is empty, just check if it’s False. Same for tuples, and in some ocassions for strings.
• if type(obj) is type(1):
  This is killing kittens, there’s a builtin function for this purpose, it’s called -surprise- isinstance(object, type). For example isinstance(123, int)

Read more about this and other conventions in PEP 8.

Sadly I had some problems with git-svn, concretely it failed half the way through sending my really big number of changes. The result was that I was left with uncommitted changes and missing commits after such set of changes. No need to say that I was really nervous about the state of my hard work of the week…

So after some desperate google searches and some questions to my personal GIT expert, desrt, I found this mail in google groups. I reproduce the process here:

How to save your neck when git-svn dcommit fails half through the process

1. Open .git/logs/HEAD
2. Look for your most recent commit (note that these commits are sorted by “unix time”, although you can also find the latest one by reading the shortlog there
3. Confirm that the commit you found is the right one: git show
4. git reset --hard hash from log
5. git svn rebase
6. git svn dcommit

This picks up where it left off, so you won’t loose anything, happy happy happy git .

Hope this saved your neck like it saved mine. Other tips welcome !

Update: Mike lets me know that the commands were bad written because of html entities and stuff, fixed now.

/usr/bin/ld:.libs/libgdk_pixbuf-2.0.ver:2: ignoring invalid character `\001′ in script
/usr/bin/ld:.libs/libgdk_pixbuf-2.0.ver:2: syntax error in VERSION script

the solution is to export a C locale before building, like this:

LC_ALL=C make

Update 30/12/08: The real solution as pointed by Xan is to use bash instead of dash for sh, reconfigure the dash package and select “DO NOT WANT” when asked:

sudo dpkg-reconfigure dash

So, to fix it, you just need to add this to the Device section of /etc/X11/xorg.conf:

Option “AccelMethod” “XAA“

You can see my bug report to the intel driver here: Bug 18806 – [855GM] Xorg crashes during resume if Accel is enabled with EXA

Note that it also works if you are using EXA and you disable Accel. I don’t recommend that solution. See the bug if you doubt if this applies for your laptop or system, it has lspci info about my card.

/usr/bin/ld:.libs/pygvariant.ver:2: syntax error in VERSION script

Sucker autotools, after like 1 hour of thinking I read the log (I haven’t read it ):

libtool: link: /bin/grep -E -e "init_pygvariant" ".libs/pygvariant.exp" > ".libs/pygvariant.expT"
libtool: link: mv -f ".libs/pygvariant.expT" ".libs/pygvariant.exp"
libtool: link: echo "{ global:" > .libs/pygvariant.ver
libtool: link:  cat .libs/pygvariant.exp | sed -e "s/\(.*\)/\1;/" >> .libs/pygvariant.ver
libtool: link:  echo "local: *; };" >> .libs/pygvariant.ver

So running all those commands made me discover that my function was still init_gvariant and not init_pygvariant.

That’s all for today.

$ echo $?

and that’s it.

But now I fixed it again, trick is to edit /usr/share/acpi-support/IBM.config:

# R50e
1834*|1842*|2670*)
ACPI_SLEEP=true;
SAVE_VIDEO_PCI_STATE=true;
# toggled false ->; true
SAVE_VBE_STATE=true;
POST_VIDEO=true;
;;


There! You must make those two vars be true. Maybe some tweaking to /etc/defaults/acpi-support would be needed. Most of time this should be all you need to do.

Add “$include /etc/inputrc” to your ~/.inputrc.

From lp #89235

Turns out that vesafb and vga16fb modules are responsible for this chaos. They seem to be stealing the memory managemen and hence making sis driver impossible to use due to it’s lack of descent performance.

What’s the fix? Blacklist vesafb and vga16fb and add sisfb to /etc/modules. You can try to add video=sisfb in the boot line of the kernel (grub’s menu.lst) too.

Note that Fedora doesn’t have sisfb built and is forcing vesafb into the kernel for it’s graphical boot. Ubuntu is doing the same, but they also build sisfb as a module.

So if you are using Fedora, you are screwed unless you rebuild your kernel, if you are using Ubuntu or Debian, make sure vesafb is not loaded (nor vga16fb) and have sisfb loaded sometime before X starts.

How can you be sure it worked? Grep /var/log/Xorg.0.log for ‘memcpy’ and see if the MB/s rate is descent, you can try with and then without the sisfb module to check if it’s making a difference. Here it does.