Broadcom wireless under Hardy (Alpha 5)

Problem: wireless not working even using bcm43xx fwcutter trick used on previous occasions successfully.

Looked in system log – System>Administration>SystemLog kern.log
ERROR: Firmware file “b43/ucode5.fw” not found or load failed.
Huh? That’s not even a file made by bcm43xx.

Initial diagnostics:
lspci | grep Network
returned:
02:0b.0 Network controller: Broadcom Corporation BCM4306 802.11b/g Wireless LAN Controller (rev 03)

Solution:
Don’t use BCM43xx any more – doesn’t work. Use b43-fwcutter. See http://linuxwireless.org/en/users/Drivers/b43#fw-b43legacy

NB don’t bother using make etc on the tarball – just grab the suitable deb file from the hardy util site. Get by searching for Hardy util b43. Obviously, if I had access to the internet I could use synaptic or apt-get but no wireless = no internet (see Catch 22 ;-)).

then gksu b43-fwcutter -w /lib/firmware ~Desktop/wl_apsta-3.130.20.0.o
NB gksu not sudo when a graphical application

Working on the assumption that I can use the legacy v3 file (incorrect – see below).

Still a problem – there is now a folder called /lib/firmware/b43legacy
So tried:
sudo nautilus /lib/firmware/b43legacy and it contains ucode5.fw etc
Shame the folder has legacy as part of its name
Renamed the folder to b43 in a shameless attempt to get the system going

New issue (possibly progress though):
b43-phy0 ERROR: YOUR FIRMWARE IS TOO OLD. Firmware from binary drivers older than version 4.x is unsupported. You must upgrade your firmware files.

Hmmm – deleted all old bcm43xx firmware files from main /lib/firmware folder.
sudo rm -r /lib/firmware/b43legacy

Rebooted.

Nope.

Ah – download v4 wl_apsta.o file
wget http://downloads.openwrt.org/sources/broadcom-wl-4.80.53.0.tar.bz2

get wl_apsta.o from inside that file and put on desktop.

then sudo b43-fwcutter -w /lib/firmware ~Desktop/wl_apsta.o

Right – everything was automatically put it in b43 subfolder, not b43legacy. Starting to click into place. As is often the case, it all makes total sense backwards 😉 .

Looking good – can see my wireless network showing with a decent signal. Supply password. Hmmm waiting for network key.

To be continued …

[Easter 2008] – use latest, v4 wl_apsta.o
sudo b43-fwcutter -w /lib/firmware ~Desktop/wl_apsta.o
Hmm still waiting for network key.
Even tried unsecured neighbourhood wireless network. Still no success.

And continued …

[Hardy Heron RC]
Waiting for network key (sigh …)
At least dual/multiple monitor support is getting much better.
Intrepid Ibex
Hmmm try v11 rather than v8 of b43-fwcutter deb (google b43 deb)
Nope

Kexi review (Access bruiser but not Access Killer yet)

After my disappointing experiences with OpenOffice Base last year I was worried that Kexi wouldn’t be much good. But it was – within its limits. The interface seemed excellent and intuitive and even though it wasn’t anywhere near as familiar to me as the Access interface (many thousands of hours) I found myself getting quite fast at it quite easily. My real issues relate to scripting. It was exciting to see that I could use python with Kexi as my scripting language but it is not clear yet how to add lots of sophisticated functionality e.g. when I update this field I want to check 3 other values and some data in the database and enable, disable some widgets and produce some messageboxes. This may well be easy (someone please correct me) but I don’t have lots of time to gamble on this if it is not ready. If I can get that sorted (including lots of good documentation on how to control and read from the widgets using python), I will take the next step and check out Kugar – the reporting part of Kexi. If all these parts work, and there is at least one decent book on Kexi in English, we might actually have an Access Killer. Kexi + MySQL + Kugar could be a winning combination for rapid application development – especially by non-programmers.

[update version 2.2 is released and looks promising – http://www.koffice.org/news/koffice-2-2-released/]

PyInstaller Round 2

Round 1 was nearly 18 months ago (PyInstaller1.2) and enabled me to successfully deploy a GUI application as a folder (although the XP button styles weren’t quite right – solved below).

Round 2 lasted about 8 hours and involved pyInstaller 1.3 on XP with python 2.5, wxPython 2.8.7.1, and win32com 2.1.0. If I’d had these tips at the beginning it would have taken 20 minutes max 🙁 :

  1. Don’t name any folders “python”. It shouldn’t matter and usually it doesn’t but sometimes it does. Use mypy or something similar instead. That could have saved 6 hours right there 😉 . If a module was referred to as python.msaccess, for example, the python part would be treated as a module and expected to have an __init__ method. NB everything worked fine except when it was processed into an executable by pyinstaller.
  2. When testing the build process of a spec file, set console to True (or 1) and debug to True (or 1).
  3. When running the build process from a batch file, add the command
    pause
    as the final line. Then you can see all the errors, if any, and have a chance at fixing them. Can also add something like raw_input(“Hit Enter to continue”) at the end of Config.py etc to ensure files like upx are configured successfully.
  4. To identify problems with the executable, run it from a batch file, and include pause as the final command on its own line. NB make the exe with debug=True and Console=True for these steps (revert when issues fixed).
  5. Set console=False (or 0) so that XP buttons look more attractive than the older, rectangular form.
    Rounded XP buttons
                     vs
    Rectangular XP buttons

    XP and wxPython and XP buttons etc
  6. If doing a single file executable, remember to add a.binaries after a.scripts
    a.scripts, a.binaries,
    and set exclude_binaries=False
  7. It really is quite easy to edit a spec file – it is just python after all.
  8. Scripts should be without comma separation and with single backslashes in the makespec process (Batch file), and with commas and double backslashes in the python spec file.
  9. Icon images etc can be kept in the same folder as the executable for ease of portability. Inside the script they should not have an absolute path.
  10. Start with a simple HelloWorld test as per the very helpful http://www.thescripts.com/forum/thread579554.html to check all systems are working before tackling a more complex, real-world example which will require getting down and dirty with the spec document.
  11. python “…Build.py” “…..” won’t work on my system – need “C:\Python25\python.exe” “etc …”

There is excellent documentation available at PyInstaller Manual

UPDATE: got a mysterious error on a script that worked well until it was processed by pyinstaller. Without all the gruesome details, it was because I had the wxPython application set to not redirect its output AND I had some print statements tucked away in some code. At some point (when the printed output reached 4096 bytes?) up popped an [Error 9] Bad file descriptor error. In future, diagnose by making an output.txt file and setting redirect to true. What is in the output file?

UPDATE: Use the -w parameter to skip the DOS window during execution.

UPDATE: Pyinstaller 1.5 with Python 2.6 (Round 3)