Archive for July, 2011


How to install new harmattan dev packages to use on QtSDK

Filed Under: harmattan, n9, n900, n950, qtsdk by cpscotti — Comments Off on How to install new harmattan dev packages to use on QtSDK
July 25, 2011

One thing I’ve been using a lot lately is Madde’s mad-admin to add development packages to the build tree that QtSDK uses to build armel applications and I pretty much figured that out alone – well, not completely alone but after seeing a how-to related to qtmobility installation for Maemo that used this without really explaining what was what).

Preamble:

QtSdk comes with a full build environment (analogue to what one`s got on scratchbox) for armel applications. This is used every time you build a Qt project selecting a device (N9(|(0|5)0)). This whole mechanism stays quite hidden inside the sdk’s files.

Problem:

Your application may have dependencies (headers, shared libs) on packages that are not provided with QtSDK. Without proper installation of this dependencies on QtSDK’s environment, you’ll never get code-completion, compiling or linking using the default SDK.

In a normal desktop-only world, you’d normally install development packages for a given library to then be able to compile/build applications that use such library. Only after installing those packages you’ll have the proper headers, shared libraries, etc needed to build your, “higher level”, application.

Debian packages tagged by the -dev suffix usually carry what is needed (e.g. headers) for a developer to “develop” something that uses the homonimous library. While the package without the -dev suffix carry what is needed to RUN (e.g. shared library) an application that uses such package. (worth nothing that a foo-dev package will normally depend on the foo pkg).

The question is: How to do this inside QtSDK’s own world.

The secret (for Harmattan) is inside

[sourcecode language=”shell”]
/QtSDK/Madde/bin/
[/sourcecode]

PS: for maemo it’s inside

[sourcecode language=”shell”]
~/QtSDK/Maemo/4.6.2/bin
[/sourcecode]

but works pretty much the same way.

There you’ll find to binaries that make handling this libraries/dependencies business as easy as on a normal debian system.

Say you have a library called libfoo and that you already have it built and packaged for harmattan/armel (well, that’s what I use Scratchbox for…but that stays for another post). You’ll probably have files like

[sourcecode language=”shell”]
libfoo_1.0_armel.deb
libfoo-dev_1.0_armel.deb
[/sourcecode]

Well, just do:

[sourcecode language=”shell”]
you@box:~/QtSDK/Madde/bin$ ./mad set harmattan-platform-api
you@box:~/QtSDK/Madde/bin$ ./mad-admin xdpkg -i ../path-to-that-deb/libfoo_1.0_armel.deb
Package ‘libfoo’ installed.
you@box:~/QtSDK/Madde/bin$ ./mad-admin xdpkg -i ../path-to-that-deb/libfoo-dev_1.0_armel.deb
Package ‘libfoo-dev’ installed.
[/sourcecode]

In line 1 you-re setting which target you are referring (you can select which target you are using in QtCreator’s project management window.
After that, on line 2 and 4 it’s pretty much the same thing as using dpkg -i. Voila! Now your QtCreator will recognize your new lib and all’s good.
Remember that you’ll need that foo_1.0_armel.deb package installed on the device but that should be automatic if you reference to it on your debian/control file and if that package is in the same
repository as your application.

Well, gotta go back to something useful.
Hope this helps someone.

Permalink

N9(|50) Full SDK + Scratchbox Installation + Setup

Filed Under: harmattan, Linux, n9, n950, qt, thinkpad by cpscotti — Comments Off on N9(|50) Full SDK + Scratchbox Installation + Setup
July 25, 2011

Hi there!

So I got a new computer, why am I even talking about it? Because now I’ll have to set up everything I have on the new box.

To start with, the box is a Lenovo ThinkPad T520 with a clean Ubuntu 11.04, amd64 install.

For the record, 10.10 just won’t work with the T520, apparently all that sand in the bridge makes the old ubuntu skid and fall to death. After installing 317Mb of updates, upgraded to 11.04, disabled Unity (after a horrid 30 minute trial; don’t wanna talk about it now..) and finally started doing something useful.

Ok, now let’s get to the useful part, this post will mostly be just a collection of links anyway.

QtSDK; follow the instructions on that page to run the installer. Run the custom installation and select, under Experimental, Harmattan  (I picked both the Remote Compiler  and the Qt Quick Components for Symbian ones too..). I`d recommend getting Qt`s sources here too. Installation takes a long time so don’t bother and take yourself some coffee time.

Harmattan Scratchbox: Even though most of the work/development for the N9(|50) can be done through the QtSDK, one’s quite locked in there. I highly recommend using scratchbox for many reasons. Among them:

  1. makes it really easy to compile/build a generic linux package to harmattan. Many times you can take a package’s source from ubuntu/devian, build it inside scratchbox (with the proper target – HARMATTAN_ARMEL – set) and you’ll have a working .deb for Harmattan even if it’s got nothing to do with Qt. Building a .deb within QtSDK for a package that doesn`t use qmake just doesn’t make sense and will probably be a PITA.
  2. Makes the task of packaging comprehensible and “clean” without too many black magic (if you are familiar with debian packages, you`ll feel at home).
  3. Using the HARMATTAN_X86 target you can test your application/package/sw in an equivalent (but compiled to your pc`s own native architecture) environment that really works and has got all the harmattan qt quick components. QEMU is just unusable for me.

Basically, if you consider using anything further than Qt/QML pure apps, you`ll probably need it. If you didn’t get anything I said above, forget this whole guide and go do something else.

A very good guide on how to set Scratchbox up is here . The guide is pretty good and the python script there is pure magic.

Finally this article explains really well how to use scratchbox.

This is basically all you need to start..

Back to work now! 😀

Permalink

Bash History, History Expansion and that command+args you aways forget

Filed Under: bash, gnu, Linux by cpscotti — Comments Off on Bash History, History Expansion and that command+args you aways forget
July 19, 2011

Since I’m taking this blog thing a lot more serious now, I’ll devote a quick blog post to one of the things I love more about the Bourn Again SHell: history.

Working in a Linux environment inevitably makes you use a shell (i.e. the actual brain behind the famous “temrinal”). There are many shells one could use but I’ll risk saying bash is the most common. In all fairness, if you are any sort of coder/developer/debugger/hacker/script-kiddie/indiana-jones-of-the-computer-world you’ll eventually fall in love with it. It’s also worth mentioning that most people (me included), they never “sat down” to learn bash. We just started copy&pasting commands we saw somewhere, then you start reading whatever you’re posting, then you learn to use manpages (or equivalent), etc.. 5 years later you certainly “know your ways”.

For all bash/shell related problems/questions, there are probably 5 different ways around it. That said, it’s common to stick always to the same tools/methods for solving all problems…

“this way works, so why learning anything new?”

Basically, Time! The more culturally aware you are in terms of bash & bash scripting; the quicker you’ll solve your problems.

Finally, after all this obvious blogish talk, let’s get to the point:

[sourcecode language=”shell”]
history
[/sourcecode]

That command shows all the previous commands you (your user) executed. Ages ago I learned to use it with grep to see what command I had executed that had *string* on it.

[sourcecode language=”shell”]
history | grep g++
[/sourcecode]

This one’s really useful and if that’s new to you, this post is already worth it’s effort. But that one’s clumsy,
you’ll probably end up copying & pasting something by using that filthy rat of yours or by petting that flat life-less thing on
your notebook – that’s not efficient.

By running that command you’ll see that there’s an index for each command executed; for example:

[sourcecode language=”shell”]
#lol.. those are the oldest entries on my history (5k commands long)
cpscotti@clovis-laptop:~$ history
1  cd push-snowboarding/
2  git status -s
3  cd PushBurton2
4  ls
5  git status -s
6  git add *.cpp *.h
…
[/sourcecode]

That index is there for a very nice reason; History Expansion. By entering !index, you’ll run that line again. Suppose I want to
run an old command again ( e.g. meego-sb-session start ) which is hard to remember or too long to type, one can just find out the
index for the last occurrence of that command and.. voila!

[sourcecode language=”shell”]
[sbox-HARMATTAN_X86: ~] > history | grep start
167  history | grep start
168  meego-sb-session start
501  meego-sb-session start
503  history | grep start
[sbox-HARMATTAN_X86: ~] > !168
meego-sb-session start
…
[/sourcecode]

But hey, if you are still lazy to type in those two lines.. we can go further!
There’s another command I execute quite often that’s just a PITA to remembering/type..:

[sourcecode language=”shell”]
cpscotti@clovis-laptop:~$ Xephyr :2 -host-cursor -screen 854x480x16 -dpi 96 -ac +extension Composite &
[/sourcecode]

Diving a bit more into history‘s manpages you’d find the ” ? “and a lot more!
I won’t explain much, just watch! 😀

[sourcecode language=”shell”]
cpscotti@clovis-laptop:~$ !?Xep?
Xephyr :2 -host-cursor -screen 854x480x16 -dpi 96 -ac +extension Composite &
[/sourcecode]

Of course you have to “know your past” otherwise you’ll end up executing bizarre commands but well.. that works great for me!

Enjoy!

 

Oh, one last thing! You can “pimp up” your history’s size! I think Ubuntu’s default is 2000.. way to small in my opinion! Just edit HISTSIZE inside your .bashrc script!

(in doubt check manpages for bash and history!)

Permalink

Preventing CPU Meltdown

Filed Under: Hack, Linux, Shell by cpscotti — Comments Off on Preventing CPU Meltdown
July 11, 2011

Ok, I’ll try this.

For real now.

Yesterday my notebook’s fan had its last spins. The bastard was bugging me for a while but now it’s gone.. was I a bit more emotional I’d probably be crying now.

So basically, my notebook is running on fukushima-mode. No fan.. wild and dangerous computing. The problem is that whenever I get into something serious (any long compilation or watching a 1080p snowboarding video like this) it grows hotter and hotter until the kernel steps in with a VERY mean attitude, killing the whole thing and shutting down the machine and interrupting whatever I was doing.

At some point I figured I could manually kill -STOP $naughtyJob wait for the cpu to cool it’s guts and then let the naughtyjob continue whatever it was doing with -CONT. Nice idea.. I bet you can’t do that on Windows – well, probably you can but I don’t wanna know and don’t come telling me!

The problem is that sometimes you just don’t realise the damn machine is already too hot until you see the shutdown screen and start raving about the new FAN that’s not even on the mail yet! The rational thing a Control Engineer would do is automate the -STOP/-CONT process – behold the life-saving shell script! Wasn’t god written in awk anyway?

The basic idea is to set a “too hot” and a “chilling” points; if it’s too hot the script STOPs the processor using more CPU at the time. If it’s chilling, the script CONTs those processes. You definitely need a quite big band in between the two points (see Hysteresis)  so that your script won’t run amok on you and get everything even worse.. I’m with 65ºC/80ºC now.

Drumroll please… (Ok.. this is just a hour-hack.. works for me, saving the day till my new fan arrives)

[sourcecode language=”shell”]
#!/bin/bash
hotT=80
coolT=65

watchT=1
coolDownT=3

while true;
do
sleep $watchT
temp=`cat /proc/acpi/thermal_zone/THM/temperature | awk ‘{print $2}’`

if [ $temp -lt $coolT ]
then
echo "Chilling"
cat haltedReactors.list | while read -e tLine;
do
fukuPid=`echo $tLine | awk ‘{print $2}’`
fukuComm=`echo $tLine | awk ‘{print $3}’`
kill -CONT $fukuPid
zenityLine="Restarted "$fukuComm", pid: "$fukuPid
zenity –info –text "$zenityLine"&
done
rm -f haltedReactors.list
touch haltedReactors.list
fi

if [ $temp -gt $hotT ]
then
echo "Burning"

fukushimaLine=`ps -A -o pcpu,pid,comm –sort pcpu | tail -n 1`
fukushimaPid=`echo $fukushimaLine | awk ‘{print $2}’`
fukushimaComm=`echo $fukushimaLine | awk ‘{print $3}’`

kill -STOP $fukushimaPid
zenityLine="Stopped "$fukushimaComm", pid: "$fukushimaPid
echo $zenityLine
zenity –info –text "$zenityLine"&

echo $fukushimaLine >> haltedReactors.list
sleep $coolDownT

fi

done
[/sourcecode]

I’m using this for two hours now. So far firefox-bin was paused twice and spotify once. On the bright side, the hot machine’s running strong since this ungodly morning started.

Have fun!

Permalink