Re: [MeeGo-dev] MeeGo Reconstructed - a plan of action and direction for MeeGo

2011-10-04 Thread Mika Laitio

OBS is a very useful tool, just not for the purposes you were
apparently forced to use it for. I've used it for the commit, push
package, wait for build failure type development cycle as well, and I
agree, it's far from optimal - but for easily making heavily


There are couple of ways to speed up the development also when working 
in the OBS environment, especially when really trying to solve real 
development problems. Here couple of tips.


1) offline option -o when doing osc build will speed up things a 
little when trying to do a multiple local builds in a row, as then the

obs does not try to get the latest dependency list from the server.
osc build -o armv8el as an example...

2)When doing a development, you can first create the chroot env with
  osc build command and then after the first build have started switch
  to chroot environment

a) osc co Project:DE:Trunk/ohm
b) cd Project:DE:Trunk/ohm
c) osc build armv8el
   ... wait the build to complete or fail and then switch to chroot env
d) cd /var/tmp/osc-build-root/
e) sudo su
f) chroot .
g) cd home/abuild/rpmbuild/BUILD/ohm-1.1.14
h) run commands like make/make install on chrooted bash shell
i) edit the files by using your favourite editor from another shell
   from dir /var/tmp/osc-build-root/home/abuild/rpmbuild/BUILD/ohm-1.1.14

3) you can have multiple chrooted environments by editing build-root
   variable from the ~/.oscrc file. I for example prefer of having 
something like: build-root = /obs/buildroots/%(repo)s-%(arch)s


4) You can force that osc build command will always put certain 
packages to chroot env in addition of the direct dependencies of certain 
app by listing these extra packages is ~/.oscrc file.

For example: extra-pkgs = gdb strace

What I am also missing would be an easy way to configure the QT creator 
easily to use the qt, qml and gcc from the chrooted env.

(So I could just do the qml editing with the qt-creator by using those
components that happens to be installed in the chroot env that the osc 
build command has created.) So if somebody knows ways to do that, I 
would be very interested.


Mika

customised distributions, OBS is great.


e.g. seeing our duicontrolpanel on MeeGo-MeeGo installation instead of
Harmattan is a whole different experience than seeing it on Harmattan
device),


snip


But good news, there is a easy technology to make a superb UI framework 
rapidly, QML.
It needs some work,  needs to be consistent UI concept, excellent graphics 
(which have a meaning,


The technology is, at the end of the day, not that important (though I
agree that QML makes life a lot easier) - at the end of the day, you
can have the best written UI in the world, and it will still look like
complete and utter crap without decent theming.

Hopefully we can poke some of the awesome graphical people around like
wazd to give us a hand with some of this.


- Many of the lower layers have been already open sourced by companies and
it is just about utilizing them and doing the top of the cake right. There
are some missing pieces, but filling the gaps should not be impossible.


One of the missing gaps, at least on Handset CE, is the settings
application. As you point out, it is not visually pleasing, it has
flickering text (!! Wifi before changing to the actual text), and
other issues which make it a bit pailful to use.

Given your experience with it, would you like to dedicate some time to
making it more usable, perhaps even doing some thinking on how to
approach it from the QML world?

BR,

Robin
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev
http://wiki.meego.com/Mailing_list_guidelines


___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev
http://wiki.meego.com/Mailing_list_guidelines


Re: [MeeGo-dev] howto prevent unrequired build dependency remove when doing local osc builds?

2011-04-12 Thread Mika Laitio

Why do you want MCE build dependencies when building the kernel?


Because quite often when I am developing and testing some packages, I 
will first do manual editing, building and copying binaries for N900  in 
the chrooted environment.


# /usr/sbin/qemu-binfmt-conf.sh
# cd /var/tmp/Trunk_Testing-armv7el
# chroot .
# cd mce
# make
... then scp the binaries build on non-chrooted terminal which has 
network access to n900 for testing


Once I am happy with that, I will usually do the patches and then run 
local obs build for final testing before committing changes to obs server.


So now what happens is that if I do local obs kernel build, it has 
removed all mce related devel-headers and before I can continue with 
that I must re-install all mce packages by doing a local obs build for mce.


I have worked around this now by collecting a huge list of packages 
under extra-pkgs option in .oscrc



The packages are removed from the chroot, but they are still cached locally for 
the next MCE build, meaning you will not be pulling them again from the repos.
If you want to jump straight to building without removing anything, you can try 
--noinit option

--noinit, --no-init
 Skip initialization of build root and start with build
 immediately.


What I would like to have is some kind of option update existing rpm's 
and install only a new dependencies without uninstalling anything.


Mika
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev
http://wiki.meego.com/Mailing_list_guidelines


[MeeGo-dev] howto prevent unrequired build dependency remove when doing local osc builds?

2011-04-06 Thread Mika Laitio

I have setted in my .oscrc
build-root = /var/tmp/%(repo)s-%(arch)s

If I first build mce locally with osc build armv8el Trunk_Testing, I 
have in my build root all packages that were required for building the 
mce on /var/tmp/Trunk_Testing-armv8el


But If I will after that build kernel locally again with same osc build 
armv8el Trunk_Testing, osc will now install all additional dependencies 
required by the kernel build to this same /var/tmp/Trunk_Testing-armv8el 
directory.
That's fine, but for some reason it seems also be removing all 
dependencies that were required by the MCE but are not required for the 
kernel build.


...
   warning: /etc/gconf/2/path saved as /etc/gconf/2/path.rpmsave
   deleting GConf-dbus-devel
   deleting dbus-devel
   deleting dbus-glib-devel
   deleting glib2-devel
   deleting libdsme
...

Is there any method for preventing this?
I know that one solution is to configure in oscrc a package specific 
build roots, but as each chroot takes about 1 gb of harddrive,
I would rather try to have just arch specific chroots that contains all 
non-conflicting build dependencies for many different pacakages 
simultaneously.


Mika
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev
http://wiki.meego.com/Mailing_list_guidelines


[MeeGo-dev] howto restart and trace the meegotouch-systemui applets

2011-03-15 Thread Mika Laitio

Hi

I am trying to find out the best/official way for debugging the battery 
applet problems in N900 that I believe are in meegotouch-systemui which 
provides a set of libraries.
If I add some printf/debug messages for example to 
batterybusinesslogic.cpp and then rebuild and install the libraries to 
N900, can I somehow restart the battery applet from the command line in 
a way I could see the debug messages?


Mikat
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev
http://wiki.meego.com/Mailing_list_guidelines