Discussion:
Bug in Dates on N800 and build Q - WAS Re: Archives of list available?
Jeffrey Perry
2007-10-15 02:53:55 UTC
Permalink
I recently discovered how to reproduce the bug in Dates that I mentioned
in my message back in 2007-07-09.

I have filed a new bug in bugzilla describing it.

Briefly...

1) Add a web-based ical like the US Holidays Ical available from Apple's
site (don't download it - just use the url)
2) double-click on a holiday and nothing happens (expected since you
can't edit web calendars)
3) Now double click on an empty day to create a new event there -
instead of the normal dialog appearing - the application simply closes.

Next I tested on my desktop by building Dates.

Repeated steps above - no crash, and nice dialog appears asking about
the event you wish to create.

I hope I have provided enough detail...please let me know if there is a
place I can find log messages from Dates...

In a related area, I've been dabbling from time to time setting up
scratchbox for development for the N800...
I just fetched Dates from SVN and ran autogen.sh - Of course
gnome-common is not installed and it failed... Any hints on getting
things configured to build for N800? Do I really need to install gnome
to build for N800? My guess is it's not there when dates is run.

Thank you for your assistance!

--Jeff
I'm very interested in using Dates and Contacts over GPE because of your
technical design choice for synchronization with Evolution. Using a lite
eds server sounds like a nice clean approach. GPE sounds like it can
currently sync with evolution but only via use of a combination of
OpenSync and MultiSync. I have yet to try this.
Note that Opensync is the new name for the backend of the old Multisync,
and "multisync" is now a UI for opensync.
I recently installed Dates on my N800 and quickly managed to get it to
crash (consistently) by adding a webcal. I had thought about taking a
stab at debugging it. I found the dev environment setup a bit of a
hurdle but think I've got things working.
Next, I tried to add the repository for o-hand to /etc/apt repositories
list and then did an apt-get update and finally tried apt-get install
dates - I got an error :-( It couldn't find the package I requested even
though the repository info is in the /var package management cache.
Can you mail your sources.list and what happens when you try to install
dates? If you are trying to install dates inside an Intel scratchbox
you'll get errors because we haven't build Intel packages: you'll have
to build them yourself for now.
Another question. According to the web site for o-hand, your company had
a lot to do with the work on the software for the tablets. Which parts
did they work on? Sounds like the embedded Linux OS and probably drivers
as well. Anything else?
The window manager is written by OpenedHand, porting EDS to use DBus,
the addressbook application, roster/addressbook sync, parts of the
desktop, and several development tools. I think that is most things.
http://o-hand.com/blog/?p=13 is our press release for the N800 release.
I'm also wondering about the name of your project: pimlico. A google
search on this led me to a site selling datebk+ for the Palm. This app
came installed on one of my previous Palms and I found it quite helpful.
Any relation? Did o-hand work on this commercial project also?
No, there is no relation. We hadn't heard of the PalmOS suite until
people started asking if there is a relation.
Also...as an aside, I second the recent email requesting some sort of
roadmap or general plan for 0.2 - perhaps just marking the bugzilla bugs
and enhancements you plan to close with a target version 0.2 in
bugzilla? I just looked and it does not look like you have that field in
your setup :-(
There is no explicit roadmap for the Pimlico project really. Contacts
is currently being rewritten in a more modular form, Dates needs a few
features added to make the calendar pretty much feature complete, and
Tasks needs a little bit more magic.
If there is anything in particular you want, file a bug and we'll see
what we can do. Patches are welcome too. ;)
Ross
--
To unsubscribe send a mail to pimlico+unsubscribe-xEU7zwZjznfQT0dZR+***@public.gmane.org
Jeffrey Perry
2007-11-19 21:24:07 UTC
Permalink
I checked on bug #293) (http://bugzilla.o-hand.com/show_bug.cgi?id=556)
recently ...looks like there has been no change.

I now find myself with a little time and I'd like to investigate it.

I need some general developer setup questions answered.

I have a scratchbox maemo dev environment setup now. (Maemo SDK 3.2
since I will be targeting an N800)


General plan:

*) First try debugging under scratchbox X86 target.

Question #1:

Is this pointless, since I already know this bug does not occur
when run outside scratchbox on my x86 desktop?

*) Failing that, or not seeing the bug there...

Setup some sort of remote (I think scratchbox calls it TRANSPARENT)
debugging environment and use gdb running on the tablet to debug the
issue over a local usb connection

Question #1.5: Pointers to howtos on remote debugging on the N800 are
are welcome. I will of course be looking around
myself at maemo and via google.
Question #2:

Looks like dates needs libecal. Where can I find it in SVN so I can
build it inside scratchbox?

Question #3:

Will I need to build any other libs to get this to setup for
debugging? contacts? esd sync with dbus flags???

Question #4:

General question on the state of this project: Is continued
development for the N800 of the pimlico apps including the sync feature
a priority for Open Hand? I wish to try to help a bit, but of course
want to be sure my efforts contribute to other progress on the project.
Any word on releasing a roadmap with some dates? (I know this is a
recurring question - just hoping the answer has changed recently with
the arrival of the N810)

Thank you for your time and assistance!

--Jeff
--
To unsubscribe send a mail to pimlico+unsubscribe-xEU7zwZjznfQT0dZR+***@public.gmane.org
Ross Burton
2007-11-19 22:17:52 UTC
Permalink
Post by Jeffrey Perry
*) First try debugging under scratchbox X86 target.
Is this pointless, since I already know this bug does not occur
when run outside scratchbox on my x86 desktop?
Definitely worth a go, as its a lot easier to debug here.
Post by Jeffrey Perry
*) Failing that, or not seeing the bug there...
Setup some sort of remote (I think scratchbox calls it TRANSPARENT)
debugging environment and use gdb running on the tablet to debug the
issue over a local usb connection
You could try running an ARM maemo and Xephyr. Sometimes this works
like the x86 scratchbox. However a proper network debugging thingy is
probably the best idea.
Post by Jeffrey Perry
Question #1.5: Pointers to howtos on remote debugging on the N800 are
are welcome. I will of course be looking around
myself at maemo and via google.
Never tried it myself, so I can't help, sorry. Running dates in a
terminal might give enough asserts to help debug the problem.
Post by Jeffrey Perry
Looks like dates needs libecal. Where can I find it in SVN so I can
build it inside scratchbox?
Source is in http://svn.o-hand.com/repos/eds-dbus/. You'll want to
merge the packaging in packages/maemo3.0-full with a source checkout
from trunk/ of the relevant date. Using the latest trunk may work, but
maybe not. Basically, use our packages unless you can demonstrate that
the crash is in libecal.
Post by Jeffrey Perry
Will I need to build any other libs to get this to setup for
debugging? contacts? esd sync with dbus flags???
You'll want to build Dates with full debugging, that should be enough to
guide further debugging.
Post by Jeffrey Perry
General question on the state of this project: Is continued
development for the N800 of the pimlico apps including the sync feature
a priority for Open Hand?
Development of the suite as a whole is important. We're currently
focused on OpenMoko ports (including complete rewrites of Contacts and
Dates), which when finished will be ported to Maemo and the desktop.

Sync is something which needs to be done at some point.
Post by Jeffrey Perry
I wish to try to help a bit, but of course
want to be sure my efforts contribute to other progress on the project.
Any word on releasing a roadmap with some dates? (I know this is a
recurring question - just hoping the answer has changed recently with
the arrival of the N810)
Considering that Maemo ports of Pimlico are done in the respective
developer's spare time, a roadmap would be a waste of time. For Tasks
you can look at the bugzilla, which I use as a future feature list. For
Contacts and Dates, as I said all current work is on completing the
rewrites for OpenMoko. Hopefully once that is done, Maemo ports can be
worked on. Help on this is welcomed, thanks to the new code
architecture porting to new platforms is a lot easier.

Ross
--
OpenedHand Ltd.

Unit R Homesdale Business Center / 216-218 Homesdale Road /
Bromley / BR1 2QZ / UK Tel: +44 (0)20 8819 6559

Expert Open Source For Consumer Devices - http://o-hand.com/
------------------------------------------------------------
Jeffrey Perry
2007-11-20 00:42:04 UTC
Permalink
Thanks for all the info... a few followup questions...

I'm found the eds in svn, and am setting up to build it in the X86
scratchbox.
It is complaining of missing m4 macros...

Checking for required M4 macros...
gnome-compiler-flags.m4 not found
libtool.m4 not found
intltool.m4 not found
gtk-doc.m4 not found

The first one is part of gnome common and apt-get install gnome-common
indicates I have the latest version - I did an apt-cache search and
found no dev version of this package (something like gnome-common-devel
perhaps???) Do you usually run autogen.sh inside scratchbox when doing
development? I probably need some more packages - but I'm not sure which
ones to add. I suppose fetching the source for some and building them -
MIGHT give me what I need - but I probably don't want to build
gnome-common. Who knows how many other dependencies I may need to track
down for that to work.

One more thing, could you please clarify your comment about
"packages/maemo3.0-full with a source checkout from trunk/ of the
relevant date.". I have a source checkout of dates. I see that eds-dbus
in svn has a "packages/maemo3.0-full" directory. Is this the one you
mean? It looks like there are a bunch of one-click install files there.
These might allow me to avoid the need to compile eds-dbus before
working on dates - that's great. So, should I just install libecal and
libecal-dev? Do I need to install others from there too?

--Jeff
Post by Ross Burton
Post by Jeffrey Perry
*) First try debugging under scratchbox X86 target.
Is this pointless, since I already know this bug does not occur
when run outside scratchbox on my x86 desktop?
Definitely worth a go, as its a lot easier to debug here.
Post by Jeffrey Perry
*) Failing that, or not seeing the bug there...
Setup some sort of remote (I think scratchbox calls it TRANSPARENT)
debugging environment and use gdb running on the tablet to debug the
issue over a local usb connection
You could try running an ARM maemo and Xephyr. Sometimes this works
like the x86 scratchbox. However a proper network debugging thingy is
probably the best idea.
Post by Jeffrey Perry
Question #1.5: Pointers to howtos on remote debugging on the N800 are
are welcome. I will of course be looking around
myself at maemo and via google.
Never tried it myself, so I can't help, sorry. Running dates in a
terminal might give enough asserts to help debug the problem.
Post by Jeffrey Perry
Looks like dates needs libecal. Where can I find it in SVN so I can
build it inside scratchbox?
Source is in http://svn.o-hand.com/repos/eds-dbus/. You'll want to
merge the packaging in packages/maemo3.0-full with a source checkout
from trunk/ of the relevant date. Using the latest trunk may work, but
maybe not. Basically, use our packages unless you can demonstrate that
the crash is in libecal.
Post by Jeffrey Perry
Will I need to build any other libs to get this to setup for
debugging? contacts? esd sync with dbus flags???
You'll want to build Dates with full debugging, that should be enough to
guide further debugging.
Post by Jeffrey Perry
General question on the state of this project: Is continued
development for the N800 of the pimlico apps including the sync feature
a priority for Open Hand?
Development of the suite as a whole is important. We're currently
focused on OpenMoko ports (including complete rewrites of Contacts and
Dates), which when finished will be ported to Maemo and the desktop.
Sync is something which needs to be done at some point.
Post by Jeffrey Perry
I wish to try to help a bit, but of course
want to be sure my efforts contribute to other progress on the project.
Any word on releasing a roadmap with some dates? (I know this is a
recurring question - just hoping the answer has changed recently with
the arrival of the N810)
Considering that Maemo ports of Pimlico are done in the respective
developer's spare time, a roadmap would be a waste of time. For Tasks
you can look at the bugzilla, which I use as a future feature list. For
Contacts and Dates, as I said all current work is on completing the
rewrites for OpenMoko. Hopefully once that is done, Maemo ports can be
worked on. Help on this is welcomed, thanks to the new code
architecture porting to new platforms is a lot easier.
Ross
--
To unsubscribe send a mail to pimlico+unsubscribe-xEU7zwZjznfQT0dZR+***@public.gmane.org
Ross Burton
2007-11-20 09:59:59 UTC
Permalink
Post by Jeffrey Perry
I'm found the eds in svn, and am setting up to build it in the X86
scratchbox.
It is complaining of missing m4 macros...
Checking for required M4 macros...
gnome-compiler-flags.m4 not found
libtool.m4 not found
intltool.m4 not found
gtk-doc.m4 not found
The first one is part of gnome common and apt-get install gnome-common
indicates I have the latest version - I did an apt-cache search and
found no dev version of this package (something like gnome-common-devel
perhaps???) Do you usually run autogen.sh inside scratchbox when doing
development? I probably need some more packages - but I'm not sure which
ones to add. I suppose fetching the source for some and building them -
MIGHT give me what I need - but I probably don't want to build
gnome-common. Who knows how many other dependencies I may need to track
down for that to work.
You'll need to copy the files into /usr/share/aclocal, by default they
are in the tools directories and not accessible.
Post by Jeffrey Perry
One more thing, could you please clarify your comment about
"packages/maemo3.0-full with a source checkout from trunk/ of the
relevant date.". I have a source checkout of dates. I see that eds-dbus
in svn has a "packages/maemo3.0-full" directory. Is this the one you
mean? It looks like there are a bunch of one-click install files there.
These might allow me to avoid the need to compile eds-dbus before
working on dates - that's great. So, should I just install libecal and
libecal-dev? Do I need to install others from there too?
To build a package of EDS, you'll need a checkout of both trunk/ and
packages/maemo3.0-full.

For the initial debugging you don't need to build EDS at all, there
should be x86 packages for libecal and libecal-dev (you'll also need
libedata-cal) on maemo.o-hand.com (there were last time I looked
anyway!).

Ross
--
OpenedHand Ltd.

Unit R Homesdale Business Center / 216-218 Homesdale Road /
Bromley / BR1 2QZ / UK Tel: +44 (0)20 8819 6559

Expert Open Source For Consumer Devices - http://o-hand.com/
------------------------------------------------------------
Jeffrey Perry
2007-11-21 03:52:57 UTC
Permalink
Thanks for the tips and assistance.
I am taking your advice and using eds from the o-hand repository.

When running autogen.sh, pkg-config could not find libecal-1.2.so even
though it is installed.

Is there a package I am missing that would have allowed autogen.sh to
obtain this info from pkg-config?

I'm making some progress...

It was a bit messy (suggestions welcome on the more proper way to do
this) but I have an X86 dates executable inside scratchbox.
When run, it is having trouble locating the dbus address (I did start
dbus)

Any ideas? The error messages are below as part of my notes...

What follows are my full notes on the build process for dates so far...
---------------------------------------------------------------------------

Notes on setting up Nokia Tablet for development of pimlico pim apps
suite

URLS
----

http://www.o-hand.com
http://pimlico-project.org
http://bugzilla.o-hand.com/show_bug.cgi?id=556
http://svn.o-hand.com/repos/eds-dbus/
http://svn.o-hand.com/repos/dates/

I reported bug #556, a crash which happens on the tablet but not on the
desktop.

My interest is to learn more about tablet development and debugging by
looking into this bug.

Building Dates under scratchbox with Maemo 3.2 SDK (X86 target)
---------------------------------------------------------------

* Login to scratchbox target SDK_X86 as a user


* Add maemo repository to /etc/apt/sources.list
Edit /etc/apt/sources.list and add this line

deb http://maemo.o-hand.com/packages/ bora/

Don't forget to do an update

apt-get update


* Install the libecal library that is needed by dates
Not sure we need all of these but they seem likely to be useful.

apt-get install libecal libecal-dev libecal-dbg

* Checkout the latest code for the Dates package

svn co http://svn.o-hand.com/repos/dates/trunk dates

* Building dates gets a bit (that's an understatement) messy
The following has worked for me twice - but may break at any moment
The first wrinkle is that pkgconfig (which is run by autogen.sh)
fails to locate info for the libecal1-2.so library..and things go
downhill from there...

+ Create some symlinks - seems autogen can't find libtool.m4 and
intltool.m4

ln -s
/scratchbox/compilers/cs2005q3.2-glibc-i386/arch_tools/share/aclocal/libtool.m4
/usr/share/aclocal/libtool.m4

ln
-s /scratchbox/devkits/doctools/share/aclocal/intltool.m4 /usr/share/aclocal/intltool.m4

+ Run autogen.sh with no parameters

+ Modify configure.ac (remove libecal1-2 from the pkgs required list)

+ Run configure again (autogen.sh runs it too)
Since we have libecal-1.2.so but autogen could not find it since
pkg-config does not know how to locate it, we tell configure.

./configure
CPPFLAGS='-I/targets/SDK_X86/usr/include/evolution-data-server-1.4
-I/targets/SDK_X86/usr/include/libxml2
-I/targets/SDK_X86/usr/include/'
DATES_LIBS='-L /targets/SDK_X86/usr/lib/ -l libecal-1.2'

+ Run make
Even after all we just did, the last step (link to build dates) will
fail
So...

cd src

gcc -std=c99 -Wall -I/usr/include/glib-2.0
-I/usr/lib/glib-2.0/include
-I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include
-I/usr/include/atk-1.0
-I/usr/include/pango-1.0 -I/usr/include/freetype2
-I/usr/include/gconf/2
-I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include -g -O2
-o dates dates_gtk.o dates_main.o dates_callbacks.o
gconf-bridge.o /targets/SDK_X86/usr/lib/ libecal-1.2.so
-L/home/jperry/dates/src -l ./.libs/libgtkdatesview.a
-L /targets/SDK_X86/usr/lib/ -l libecal-1.2.so

Build should finish and you now have the executable dates.


Testing
--------

* Startup Xephyr (outside scratchbox)
* Start dbus (outside scratchbox)

/etc/init.d/dbus start

* Inside scratchbox, run dates.

dates

The following errors appear :-(
Seems I have some sort of DBUS issue.

[sbox-SDK_X86: ~/dates/src] > ./dates
dates[26775]: GLIB WARNING ** default - Error retrieving local time zone
dates[26775]: GLIB WARNING ** libecal - Cannot activate ECal: Unable to
determine the address of the message bus
dates[26775]: GLIB CRITICAL ** libecal - file e-cal.c: line 851:
assertion `ecal != NULL' failed
dates[26775]: GLIB WARNING ** GLib-GObject - invalid (NULL) pointer
instance
dates[26775]: GLIB CRITICAL ** GLib-GObject - g_signal_emit_valist:
assertion `G_TYPE_CHECK_INSTANCE (instance)' failed
dates[26775]: GLIB ERROR ** default - Error creating system calendar:
file e-cal.c: line 851: assertion `ecal != NULL' failed
aborting...
FreeFontPath: FPE "/usr/share/fonts/X11/misc" refcount is 2, should be
1; fixing.
Extended Input Devices not yet supported. Impelement it at line 625
in ../../../../hw/kdrive/src/kinput.c
Aborted (core dumped)
Could not init font path element /usr/X11R6/lib/X11/fonts/misc, removing
from list!
Could not init font path element /usr/share/fonts/X11/cyrillic, removing
from list!
Could not init font path element /usr/share/fonts/X11/Type1, removing
from list!
Could not init font path element /usr/X11R6/lib/X11/fonts/Type1,
removing from list!
Could not init font path
element /var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType, removing from
list!


----------------------------------------------------------------------------
Post by Ross Burton
Post by Jeffrey Perry
I'm found the eds in svn, and am setting up to build it in the X86
scratchbox.
It is complaining of missing m4 macros...
Checking for required M4 macros...
gnome-compiler-flags.m4 not found
libtool.m4 not found
intltool.m4 not found
gtk-doc.m4 not found
The first one is part of gnome common and apt-get install gnome-common
indicates I have the latest version - I did an apt-cache search and
found no dev version of this package (something like gnome-common-devel
perhaps???) Do you usually run autogen.sh inside scratchbox when doing
development? I probably need some more packages - but I'm not sure which
ones to add. I suppose fetching the source for some and building them -
MIGHT give me what I need - but I probably don't want to build
gnome-common. Who knows how many other dependencies I may need to track
down for that to work.
You'll need to copy the files into /usr/share/aclocal, by default they
are in the tools directories and not accessible.
Post by Jeffrey Perry
One more thing, could you please clarify your comment about
"packages/maemo3.0-full with a source checkout from trunk/ of the
relevant date.". I have a source checkout of dates. I see that eds-dbus
in svn has a "packages/maemo3.0-full" directory. Is this the one you
mean? It looks like there are a bunch of one-click install files there.
These might allow me to avoid the need to compile eds-dbus before
working on dates - that's great. So, should I just install libecal and
libecal-dev? Do I need to install others from there too?
To build a package of EDS, you'll need a checkout of both trunk/ and
packages/maemo3.0-full.
For the initial debugging you don't need to build EDS at all, there
should be x86 packages for libecal and libecal-dev (you'll also need
libedata-cal) on maemo.o-hand.com (there were last time I looked
anyway!).
Ross
--
To unsubscribe send a mail to pimlico+unsubscribe-xEU7zwZjznfQT0dZR+***@public.gmane.org
Jeffrey Perry
2007-11-21 04:28:37 UTC
Permalink
Much build messiness can be avoided by setting the PKG_CONFIG_PATH
environment variable :-)

In fact it all just works...

The easy way to build dates:

export PKG_CONFIG_PATH="/targets/SDK_X86/usr/lib/pkgconfig"
autogen.sh
make


No back to sorting out my dbus issue...think I might need to figure out
how to install the evolution-data-server.
Post by Jeffrey Perry
Thanks for the tips and assistance.
I am taking your advice and using eds from the o-hand repository.
When running autogen.sh, pkg-config could not find libecal-1.2.so even
though it is installed.
Is there a package I am missing that would have allowed autogen.sh to
obtain this info from pkg-config?
I'm making some progress...
It was a bit messy (suggestions welcome on the more proper way to do
this) but I have an X86 dates executable inside scratchbox.
When run, it is having trouble locating the dbus address (I did start
dbus)
Any ideas? The error messages are below as part of my notes...
What follows are my full notes on the build process for dates so far...
---------------------------------------------------------------------------
Notes on setting up Nokia Tablet for development of pimlico pim apps
suite
URLS
----
http://www.o-hand.com
http://pimlico-project.org
http://bugzilla.o-hand.com/show_bug.cgi?id=556
http://svn.o-hand.com/repos/eds-dbus/
http://svn.o-hand.com/repos/dates/
I reported bug #556, a crash which happens on the tablet but not on the
desktop.
My interest is to learn more about tablet development and debugging by
looking into this bug.
Building Dates under scratchbox with Maemo 3.2 SDK (X86 target)
---------------------------------------------------------------
* Login to scratchbox target SDK_X86 as a user
* Add maemo repository to /etc/apt/sources.list
Edit /etc/apt/sources.list and add this line
deb http://maemo.o-hand.com/packages/ bora/
Don't forget to do an update
apt-get update
* Install the libecal library that is needed by dates
Not sure we need all of these but they seem likely to be useful.
apt-get install libecal libecal-dev libecal-dbg
* Checkout the latest code for the Dates package
svn co http://svn.o-hand.com/repos/dates/trunk dates
* Building dates gets a bit (that's an understatement) messy
The following has worked for me twice - but may break at any moment
The first wrinkle is that pkgconfig (which is run by autogen.sh)
fails to locate info for the libecal1-2.so library..and things go
downhill from there...
+ Create some symlinks - seems autogen can't find libtool.m4 and
intltool.m4
ln -s
/scratchbox/compilers/cs2005q3.2-glibc-i386/arch_tools/share/aclocal/libtool.m4
/usr/share/aclocal/libtool.m4
ln
-s /scratchbox/devkits/doctools/share/aclocal/intltool.m4 /usr/share/aclocal/intltool.m4
+ Run autogen.sh with no parameters
+ Modify configure.ac (remove libecal1-2 from the pkgs required list)
+ Run configure again (autogen.sh runs it too)
Since we have libecal-1.2.so but autogen could not find it since
pkg-config does not know how to locate it, we tell configure.
./configure
CPPFLAGS='-I/targets/SDK_X86/usr/include/evolution-data-server-1.4
-I/targets/SDK_X86/usr/include/libxml2
-I/targets/SDK_X86/usr/include/'
DATES_LIBS='-L /targets/SDK_X86/usr/lib/ -l libecal-1.2'
+ Run make
Even after all we just did, the last step (link to build dates) will
fail
So...
cd src
gcc -std=c99 -Wall -I/usr/include/glib-2.0
-I/usr/lib/glib-2.0/include
-I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include
-I/usr/include/atk-1.0
-I/usr/include/pango-1.0 -I/usr/include/freetype2
-I/usr/include/gconf/2
-I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include -g -O2
-o dates dates_gtk.o dates_main.o dates_callbacks.o
gconf-bridge.o /targets/SDK_X86/usr/lib/ libecal-1.2.so
-L/home/jperry/dates/src -l ./.libs/libgtkdatesview.a
-L /targets/SDK_X86/usr/lib/ -l libecal-1.2.so
Build should finish and you now have the executable dates.
Testing
--------
* Startup Xephyr (outside scratchbox)
* Start dbus (outside scratchbox)
/etc/init.d/dbus start
* Inside scratchbox, run dates.
dates
The following errors appear :-(
Seems I have some sort of DBUS issue.
[sbox-SDK_X86: ~/dates/src] > ./dates
dates[26775]: GLIB WARNING ** default - Error retrieving local time zone
dates[26775]: GLIB WARNING ** libecal - Cannot activate ECal: Unable to
determine the address of the message bus
assertion `ecal != NULL' failed
dates[26775]: GLIB WARNING ** GLib-GObject - invalid (NULL) pointer
instance
assertion `G_TYPE_CHECK_INSTANCE (instance)' failed
file e-cal.c: line 851: assertion `ecal != NULL' failed
aborting...
FreeFontPath: FPE "/usr/share/fonts/X11/misc" refcount is 2, should be
1; fixing.
Extended Input Devices not yet supported. Impelement it at line 625
in ../../../../hw/kdrive/src/kinput.c
Aborted (core dumped)
Could not init font path element /usr/X11R6/lib/X11/fonts/misc, removing
from list!
Could not init font path element /usr/share/fonts/X11/cyrillic, removing
from list!
Could not init font path element /usr/share/fonts/X11/Type1, removing
from list!
Could not init font path element /usr/X11R6/lib/X11/fonts/Type1,
removing from list!
Could not init font path
element /var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType, removing from
list!
----------------------------------------------------------------------------
Post by Ross Burton
Post by Jeffrey Perry
I'm found the eds in svn, and am setting up to build it in the X86
scratchbox.
It is complaining of missing m4 macros...
Checking for required M4 macros...
gnome-compiler-flags.m4 not found
libtool.m4 not found
intltool.m4 not found
gtk-doc.m4 not found
The first one is part of gnome common and apt-get install gnome-common
indicates I have the latest version - I did an apt-cache search and
found no dev version of this package (something like gnome-common-devel
perhaps???) Do you usually run autogen.sh inside scratchbox when doing
development? I probably need some more packages - but I'm not sure which
ones to add. I suppose fetching the source for some and building them -
MIGHT give me what I need - but I probably don't want to build
gnome-common. Who knows how many other dependencies I may need to track
down for that to work.
You'll need to copy the files into /usr/share/aclocal, by default they
are in the tools directories and not accessible.
Post by Jeffrey Perry
One more thing, could you please clarify your comment about
"packages/maemo3.0-full with a source checkout from trunk/ of the
relevant date.". I have a source checkout of dates. I see that eds-dbus
in svn has a "packages/maemo3.0-full" directory. Is this the one you
mean? It looks like there are a bunch of one-click install files there.
These might allow me to avoid the need to compile eds-dbus before
working on dates - that's great. So, should I just install libecal and
libecal-dev? Do I need to install others from there too?
To build a package of EDS, you'll need a checkout of both trunk/ and
packages/maemo3.0-full.
For the initial debugging you don't need to build EDS at all, there
should be x86 packages for libecal and libecal-dev (you'll also need
libedata-cal) on maemo.o-hand.com (there were last time I looked
anyway!).
Ross
--
To unsubscribe send a mail to pimlico+unsubscribe-xEU7zwZjznfQT0dZR+***@public.gmane.org
Jeffrey Perry
2007-11-21 06:02:22 UTC
Permalink
Yes! I fixed the dbus startup issue :-)

As a normal user under X86 scratchbox target...

export DBUS_SESSION_BUS_ADDRESS=unix:path=/tmp/session_bus_socket

Then: ./dates

:-)

(also note: you must have started the af-sb-init.sh script must be run
first so you are running in the maemo tablet gui simulator)
Post by Jeffrey Perry
Much build messiness can be avoided by setting the PKG_CONFIG_PATH
environment variable :-)
In fact it all just works...
export PKG_CONFIG_PATH="/targets/SDK_X86/usr/lib/pkgconfig"
autogen.sh
make
No back to sorting out my dbus issue...think I might need to figure out
how to install the evolution-data-server.
Post by Jeffrey Perry
Thanks for the tips and assistance.
I am taking your advice and using eds from the o-hand repository.
When running autogen.sh, pkg-config could not find libecal-1.2.so even
though it is installed.
Is there a package I am missing that would have allowed autogen.sh to
obtain this info from pkg-config?
I'm making some progress...
It was a bit messy (suggestions welcome on the more proper way to do
this) but I have an X86 dates executable inside scratchbox.
When run, it is having trouble locating the dbus address (I did start
dbus)
Any ideas? The error messages are below as part of my notes...
What follows are my full notes on the build process for dates so far...
---------------------------------------------------------------------------
Notes on setting up Nokia Tablet for development of pimlico pim apps
suite
URLS
----
http://www.o-hand.com
http://pimlico-project.org
http://bugzilla.o-hand.com/show_bug.cgi?id=556
http://svn.o-hand.com/repos/eds-dbus/
http://svn.o-hand.com/repos/dates/
I reported bug #556, a crash which happens on the tablet but not on the
desktop.
My interest is to learn more about tablet development and debugging by
looking into this bug.
Building Dates under scratchbox with Maemo 3.2 SDK (X86 target)
---------------------------------------------------------------
* Login to scratchbox target SDK_X86 as a user
* Add maemo repository to /etc/apt/sources.list
Edit /etc/apt/sources.list and add this line
deb http://maemo.o-hand.com/packages/ bora/
Don't forget to do an update
apt-get update
* Install the libecal library that is needed by dates
Not sure we need all of these but they seem likely to be useful.
apt-get install libecal libecal-dev libecal-dbg
* Checkout the latest code for the Dates package
svn co http://svn.o-hand.com/repos/dates/trunk dates
* Building dates gets a bit (that's an understatement) messy
The following has worked for me twice - but may break at any moment
The first wrinkle is that pkgconfig (which is run by autogen.sh)
fails to locate info for the libecal1-2.so library..and things go
downhill from there...
+ Create some symlinks - seems autogen can't find libtool.m4 and
intltool.m4
ln -s
/scratchbox/compilers/cs2005q3.2-glibc-i386/arch_tools/share/aclocal/libtool.m4
/usr/share/aclocal/libtool.m4
ln
-s /scratchbox/devkits/doctools/share/aclocal/intltool.m4 /usr/share/aclocal/intltool.m4
+ Run autogen.sh with no parameters
+ Modify configure.ac (remove libecal1-2 from the pkgs required list)
+ Run configure again (autogen.sh runs it too)
Since we have libecal-1.2.so but autogen could not find it since
pkg-config does not know how to locate it, we tell configure.
./configure
CPPFLAGS='-I/targets/SDK_X86/usr/include/evolution-data-server-1.4
-I/targets/SDK_X86/usr/include/libxml2
-I/targets/SDK_X86/usr/include/'
DATES_LIBS='-L /targets/SDK_X86/usr/lib/ -l libecal-1.2'
+ Run make
Even after all we just did, the last step (link to build dates) will
fail
So...
cd src
gcc -std=c99 -Wall -I/usr/include/glib-2.0
-I/usr/lib/glib-2.0/include
-I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include
-I/usr/include/atk-1.0
-I/usr/include/pango-1.0 -I/usr/include/freetype2
-I/usr/include/gconf/2
-I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include -g -O2
-o dates dates_gtk.o dates_main.o dates_callbacks.o
gconf-bridge.o /targets/SDK_X86/usr/lib/ libecal-1.2.so
-L/home/jperry/dates/src -l ./.libs/libgtkdatesview.a
-L /targets/SDK_X86/usr/lib/ -l libecal-1.2.so
Build should finish and you now have the executable dates.
Testing
--------
* Startup Xephyr (outside scratchbox)
* Start dbus (outside scratchbox)
/etc/init.d/dbus start
* Inside scratchbox, run dates.
dates
The following errors appear :-(
Seems I have some sort of DBUS issue.
[sbox-SDK_X86: ~/dates/src] > ./dates
dates[26775]: GLIB WARNING ** default - Error retrieving local time zone
dates[26775]: GLIB WARNING ** libecal - Cannot activate ECal: Unable to
determine the address of the message bus
assertion `ecal != NULL' failed
dates[26775]: GLIB WARNING ** GLib-GObject - invalid (NULL) pointer
instance
assertion `G_TYPE_CHECK_INSTANCE (instance)' failed
file e-cal.c: line 851: assertion `ecal != NULL' failed
aborting...
FreeFontPath: FPE "/usr/share/fonts/X11/misc" refcount is 2, should be
1; fixing.
Extended Input Devices not yet supported. Impelement it at line 625
in ../../../../hw/kdrive/src/kinput.c
Aborted (core dumped)
Could not init font path element /usr/X11R6/lib/X11/fonts/misc, removing
from list!
Could not init font path element /usr/share/fonts/X11/cyrillic, removing
from list!
Could not init font path element /usr/share/fonts/X11/Type1, removing
from list!
Could not init font path element /usr/X11R6/lib/X11/fonts/Type1,
removing from list!
Could not init font path
element /var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType, removing from
list!
----------------------------------------------------------------------------
Post by Ross Burton
Post by Jeffrey Perry
I'm found the eds in svn, and am setting up to build it in the X86
scratchbox.
It is complaining of missing m4 macros...
Checking for required M4 macros...
gnome-compiler-flags.m4 not found
libtool.m4 not found
intltool.m4 not found
gtk-doc.m4 not found
The first one is part of gnome common and apt-get install gnome-common
indicates I have the latest version - I did an apt-cache search and
found no dev version of this package (something like gnome-common-devel
perhaps???) Do you usually run autogen.sh inside scratchbox when doing
development? I probably need some more packages - but I'm not sure which
ones to add. I suppose fetching the source for some and building them -
MIGHT give me what I need - but I probably don't want to build
gnome-common. Who knows how many other dependencies I may need to track
down for that to work.
You'll need to copy the files into /usr/share/aclocal, by default they
are in the tools directories and not accessible.
Post by Jeffrey Perry
One more thing, could you please clarify your comment about
"packages/maemo3.0-full with a source checkout from trunk/ of the
relevant date.". I have a source checkout of dates. I see that eds-dbus
in svn has a "packages/maemo3.0-full" directory. Is this the one you
mean? It looks like there are a bunch of one-click install files there.
These might allow me to avoid the need to compile eds-dbus before
working on dates - that's great. So, should I just install libecal and
libecal-dev? Do I need to install others from there too?
To build a package of EDS, you'll need a checkout of both trunk/ and
packages/maemo3.0-full.
For the initial debugging you don't need to build EDS at all, there
should be x86 packages for libecal and libecal-dev (you'll also need
libedata-cal) on maemo.o-hand.com (there were last time I looked
anyway!).
Ross
--
To unsubscribe send a mail to pimlico+unsubscribe-xEU7zwZjznfQT0dZR+***@public.gmane.org
Jeffrey Perry
2007-11-21 06:19:58 UTC
Permalink
Hmm...some display issues with names of calendars.

* Color box next to each shows white for both personal calendar and US
Holidays even though I picked Red for US Holidays

* Also need to figure out how often the webcal is updated - I see no
mention of Thanksgiving (should be Nov 23) on it!? So either there is a
network issue within the scratchbox env or the time for update has not
yet come perhaps?? or there could be a problem with the webcal server
providing the info (nope - just checked using a desktop web browser)
Post by Jeffrey Perry
Yes! I fixed the dbus startup issue :-)
As a normal user under X86 scratchbox target...
export DBUS_SESSION_BUS_ADDRESS=unix:path=/tmp/session_bus_socket
Then: ./dates
:-)
(also note: you must have started the af-sb-init.sh script must be run
first so you are running in the maemo tablet gui simulator)
Post by Jeffrey Perry
Much build messiness can be avoided by setting the PKG_CONFIG_PATH
environment variable :-)
In fact it all just works...
export PKG_CONFIG_PATH="/targets/SDK_X86/usr/lib/pkgconfig"
autogen.sh
make
No back to sorting out my dbus issue...think I might need to figure out
how to install the evolution-data-server.
Post by Jeffrey Perry
Thanks for the tips and assistance.
I am taking your advice and using eds from the o-hand repository.
When running autogen.sh, pkg-config could not find libecal-1.2.so even
though it is installed.
Is there a package I am missing that would have allowed autogen.sh to
obtain this info from pkg-config?
I'm making some progress...
It was a bit messy (suggestions welcome on the more proper way to do
this) but I have an X86 dates executable inside scratchbox.
When run, it is having trouble locating the dbus address (I did start
dbus)
Any ideas? The error messages are below as part of my notes...
What follows are my full notes on the build process for dates so far...
---------------------------------------------------------------------------
Notes on setting up Nokia Tablet for development of pimlico pim apps
suite
URLS
----
http://www.o-hand.com
http://pimlico-project.org
http://bugzilla.o-hand.com/show_bug.cgi?id=556
http://svn.o-hand.com/repos/eds-dbus/
http://svn.o-hand.com/repos/dates/
I reported bug #556, a crash which happens on the tablet but not on the
desktop.
My interest is to learn more about tablet development and debugging by
looking into this bug.
Building Dates under scratchbox with Maemo 3.2 SDK (X86 target)
---------------------------------------------------------------
* Login to scratchbox target SDK_X86 as a user
* Add maemo repository to /etc/apt/sources.list
Edit /etc/apt/sources.list and add this line
deb http://maemo.o-hand.com/packages/ bora/
Don't forget to do an update
apt-get update
* Install the libecal library that is needed by dates
Not sure we need all of these but they seem likely to be useful.
apt-get install libecal libecal-dev libecal-dbg
* Checkout the latest code for the Dates package
svn co http://svn.o-hand.com/repos/dates/trunk dates
* Building dates gets a bit (that's an understatement) messy
The following has worked for me twice - but may break at any moment
The first wrinkle is that pkgconfig (which is run by autogen.sh)
fails to locate info for the libecal1-2.so library..and things go
downhill from there...
+ Create some symlinks - seems autogen can't find libtool.m4 and
intltool.m4
ln -s
/scratchbox/compilers/cs2005q3.2-glibc-i386/arch_tools/share/aclocal/libtool.m4
/usr/share/aclocal/libtool.m4
ln
-s /scratchbox/devkits/doctools/share/aclocal/intltool.m4 /usr/share/aclocal/intltool.m4
+ Run autogen.sh with no parameters
+ Modify configure.ac (remove libecal1-2 from the pkgs required list)
+ Run configure again (autogen.sh runs it too)
Since we have libecal-1.2.so but autogen could not find it since
pkg-config does not know how to locate it, we tell configure.
./configure
CPPFLAGS='-I/targets/SDK_X86/usr/include/evolution-data-server-1.4
-I/targets/SDK_X86/usr/include/libxml2
-I/targets/SDK_X86/usr/include/'
DATES_LIBS='-L /targets/SDK_X86/usr/lib/ -l libecal-1.2'
+ Run make
Even after all we just did, the last step (link to build dates) will
fail
So...
cd src
gcc -std=c99 -Wall -I/usr/include/glib-2.0
-I/usr/lib/glib-2.0/include
-I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include
-I/usr/include/atk-1.0
-I/usr/include/pango-1.0 -I/usr/include/freetype2
-I/usr/include/gconf/2
-I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include -g -O2
-o dates dates_gtk.o dates_main.o dates_callbacks.o
gconf-bridge.o /targets/SDK_X86/usr/lib/ libecal-1.2.so
-L/home/jperry/dates/src -l ./.libs/libgtkdatesview.a
-L /targets/SDK_X86/usr/lib/ -l libecal-1.2.so
Build should finish and you now have the executable dates.
Testing
--------
* Startup Xephyr (outside scratchbox)
* Start dbus (outside scratchbox)
/etc/init.d/dbus start
* Inside scratchbox, run dates.
dates
The following errors appear :-(
Seems I have some sort of DBUS issue.
[sbox-SDK_X86: ~/dates/src] > ./dates
dates[26775]: GLIB WARNING ** default - Error retrieving local time zone
dates[26775]: GLIB WARNING ** libecal - Cannot activate ECal: Unable to
determine the address of the message bus
assertion `ecal != NULL' failed
dates[26775]: GLIB WARNING ** GLib-GObject - invalid (NULL) pointer
instance
assertion `G_TYPE_CHECK_INSTANCE (instance)' failed
file e-cal.c: line 851: assertion `ecal != NULL' failed
aborting...
FreeFontPath: FPE "/usr/share/fonts/X11/misc" refcount is 2, should be
1; fixing.
Extended Input Devices not yet supported. Impelement it at line 625
in ../../../../hw/kdrive/src/kinput.c
Aborted (core dumped)
Could not init font path element /usr/X11R6/lib/X11/fonts/misc, removing
from list!
Could not init font path element /usr/share/fonts/X11/cyrillic, removing
from list!
Could not init font path element /usr/share/fonts/X11/Type1, removing
from list!
Could not init font path element /usr/X11R6/lib/X11/fonts/Type1,
removing from list!
Could not init font path
element /var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType, removing from
list!
----------------------------------------------------------------------------
Post by Ross Burton
Post by Jeffrey Perry
I'm found the eds in svn, and am setting up to build it in the X86
scratchbox.
It is complaining of missing m4 macros...
Checking for required M4 macros...
gnome-compiler-flags.m4 not found
libtool.m4 not found
intltool.m4 not found
gtk-doc.m4 not found
The first one is part of gnome common and apt-get install gnome-common
indicates I have the latest version - I did an apt-cache search and
found no dev version of this package (something like gnome-common-devel
perhaps???) Do you usually run autogen.sh inside scratchbox when doing
development? I probably need some more packages - but I'm not sure which
ones to add. I suppose fetching the source for some and building them -
MIGHT give me what I need - but I probably don't want to build
gnome-common. Who knows how many other dependencies I may need to track
down for that to work.
You'll need to copy the files into /usr/share/aclocal, by default they
are in the tools directories and not accessible.
Post by Jeffrey Perry
One more thing, could you please clarify your comment about
"packages/maemo3.0-full with a source checkout from trunk/ of the
relevant date.". I have a source checkout of dates. I see that eds-dbus
in svn has a "packages/maemo3.0-full" directory. Is this the one you
mean? It looks like there are a bunch of one-click install files there.
These might allow me to avoid the need to compile eds-dbus before
working on dates - that's great. So, should I just install libecal and
libecal-dev? Do I need to install others from there too?
To build a package of EDS, you'll need a checkout of both trunk/ and
packages/maemo3.0-full.
For the initial debugging you don't need to build EDS at all, there
should be x86 packages for libecal and libecal-dev (you'll also need
libedata-cal) on maemo.o-hand.com (there were last time I looked
anyway!).
Ross
--
To unsubscribe send a mail to pimlico+unsubscribe-xEU7zwZjznfQT0dZR+***@public.gmane.org
Ross Burton
2007-11-21 09:08:35 UTC
Permalink
Post by Jeffrey Perry
Yes! I fixed the dbus startup issue :-)
As a normal user under X86 scratchbox target...
export DBUS_SESSION_BUS_ADDRESS=unix:path=/tmp/session_bus_socket
The correct way is to start the Maemo environment with af-sb-init.sh
start, and then do run-standalone.sh ./dates. Or use the launcher in
Maemo.

Ros
--
OpenedHand Ltd.

Unit R Homesdale Business Center / 216-218 Homesdale Road /
Bromley / BR1 2QZ / UK Tel: +44 (0)20 8819 6559

Expert Open Source For Consumer Devices - http://o-hand.com/
------------------------------------------------------------
Jeffrey Perry
2007-11-21 18:56:01 UTC
Permalink
Ahh yes, Thank you. I remember reading about that script - forgot to use
it.
Post by Ross Burton
Post by Jeffrey Perry
Yes! I fixed the dbus startup issue :-)
As a normal user under X86 scratchbox target...
export DBUS_SESSION_BUS_ADDRESS=unix:path=/tmp/session_bus_socket
The correct way is to start the Maemo environment with af-sb-init.sh
start, and then do run-standalone.sh ./dates. Or use the launcher in
Maemo.
Ros
--
To unsubscribe send a mail to pimlico+unsubscribe-xEU7zwZjznfQT0dZR+***@public.gmane.org
Jeffrey Perry
2007-11-21 19:24:03 UTC
Permalink
Ahh ok, this seems to fix most quirks

+ Display issues - the two i mentioned earlier are gone
one new: Month view does not seem to highlight in any way
days with events from web calendar. Example: Thanksgiving

I can't attempt reproducing my reported bug until I figure
out why. I seem to recall making it happen while in month view.

+ Web calendar - US Holidays now displays events in non-month
views - so it's fetching and parsing the web cal

NEW: Came across a crash while clicking around and selecting items from
menus (sorry I don't recall which steps caused it) I notice the console
contains these lines (probably harmless) just before the segfault.


dates[2469]: GLIB WARNING ** default - Failed to get calendar query
dates[2469]: GLIB WARNING ** default - Failed to open file
'/usr/local/share/dates/oh-about-logo.png': No such file or directory
/usr/bin/run-standalone.sh: line 11: 2469 Segmentation fault (core
dumped) $*
[sbox-SDK_X86: ~/dates/src] > /dev/dsp: No such file or directory
maemo_af_desktop[2403]: GLIB DEBUG default - HildonHome is background: 0

I do have the core dump and am looking at it right now.

I have it, if anyone is interested. If you want I will open a new bug,
but can't give you reproduction steps for it this time.

In case anyone is interested, here is a summary of the stack from using
gdb.

(gdb) bt
#0 0x4072d4e4 in g_object_unref () from /usr/lib/libgobject-2.0.so.0
#1 0x08068244 in dates_view_free_calendar (cal=0x81604c0) at
dates_view.c:4754
#2 0x08068302 in dates_view_remove_all_calendars (view=0x8089a60) at
dates_view.c:4802
#3 0x0805b978 in dates_update_calendars (cal_list=0x1a2, d=0xbf5967e0)
at dates_callbacks.c:1495
#4 0x4070e128 in gconf_client_change_set_from_current ()
from /usr/lib/libgconf-2.so.4
#5 0x40705d21 in gconf_listeners_notify ()
from /usr/lib/libgconf-2.so.4
#6 0x4070e1e5 in gconf_client_change_set_from_current ()
from /usr/lib/libgconf-2.so.4
#7 0x4070e38a in gconf_client_notify () from /usr/lib/libgconf-2.so.4
#8 0x407ccae1 in g_child_watch_add () from /usr/lib/libglib-2.0.so.0
#9 0x407c98e7 in g_main_context_dispatch ()
from /usr/lib/libglib-2.0.so.0
#10 0x407cb285 in g_main_context_acquire ()
from /usr/lib/libglib-2.0.so.0
#11 0x407cb5aa in g_main_loop_run () from /usr/lib/libglib-2.0.so.0
#12 0x40130def in gtk_dialog_run () from /usr/lib/libgtk-x11-2.0.so.0
#13 0x4073fa38 in g_cclosure_marshal_VOID__VOID ()
from /usr/lib/libgobject-2.0.so.0
#14 0x4072929b in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0
#15 0x4073e408 in g_signal_has_handler_pending ()
from /usr/lib/libgobject-2.0.so.0
#16 0x4073f358 in g_signal_emit_valist ()
from /usr/lib/libgobject-2.0.so.0
#17 0x4073f646 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0
#18 0x402906d5 in gtk_widget_activate ()
from /usr/lib/libgtk-x11-2.0.so.0
#19 0x401b49fc in gtk_menu_shell_activate_item ()
from /usr/lib/libgtk-x11-2.0.so.0
#20 0x401b4e79 in gtk_menu_shell_activate_item ()
from /usr/lib/libgtk-x11-2.0.so.0
#21 0x401a5614 in gtk_marshal_VOID__UINT_STRING ()
from /usr/lib/libgtk-x11-2.0.so.0
#22 0x407295d9 in g_cclosure_new_swap ()
from /usr/lib/libgobject-2.0.so.0
#23 0x4072929b in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0
#24 0x4073df7b in g_signal_has_handler_pending ()
from /usr/lib/libgobject-2.0.so.0
#25 0x4073f0ad in g_signal_emit_valist ()
from /usr/lib/libgobject-2.0.so.0
#26 0x4073f646 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0
#27 0x40290851 in gtk_widget_activate ()
from /usr/lib/libgtk-x11-2.0.so.0
#28 0x401a3bdd in gtk_propagate_event ()
from /usr/lib/libgtk-x11-2.0.so.0
#29 0x401a3e3f in gtk_main_do_event () from /usr/lib/libgtk-x11-2.0.so.0
#30 0x4039e841 in gdk_event_get_graphics_expose ()
from /usr/lib/libgdk-x11-2.0.so.0
#31 0x407c98e7 in g_main_context_dispatch ()
from /usr/lib/libglib-2.0.so.0
#32 0x407cb285 in g_main_context_acquire ()
from /usr/lib/libglib-2.0.so.0
#33 0x407cb5aa in g_main_loop_run () from /usr/lib/libglib-2.0.so.0
#34 0x401a334c in gtk_main () from /usr/lib/libgtk-x11-2.0.so.0
#35 0x080583fd in main (argc=1, argv=0xbf596904) at dates_main.c:569
Post by Jeffrey Perry
Ahh yes, Thank you. I remember reading about that script - forgot to use
it.
Post by Ross Burton
Post by Jeffrey Perry
Yes! I fixed the dbus startup issue :-)
As a normal user under X86 scratchbox target...
export DBUS_SESSION_BUS_ADDRESS=unix:path=/tmp/session_bus_socket
The correct way is to start the Maemo environment with af-sb-init.sh
start, and then do run-standalone.sh ./dates. Or use the launcher in
Maemo.
Ros
--
To unsubscribe send a mail to pimlico+unsubscribe-xEU7zwZjznfQT0dZR+***@public.gmane.org
Jeffrey Perry
2007-11-22 05:30:40 UTC
Permalink
Ok, day before Thanksgiving here in the US - so I didn't get as much
time to look at his as I hoped but here is an update.

* The bug does reproduce inside scratchbox SDK_X86 :)

* Back trace follows (looks like it might be helpful to build a debug
version of eds-dbus - I can see in e-cal.c (part of libcal) that
it is being called and would like to know where specifically things go
amuck... Research for another day...


#0 0x404afacb in e_cal_create_object () from /usr/lib/libecal-1.2.so.3
#1 0x08059690 in dates_new (d=0xbf8fc2f0, comp=0x819a690, select=1) at
dates_callbacks.c:597
#2 0x0805ae74 in dates_new_cb (source=0x8089a60, d=0xbf8fc2f0) at
dates_callbacks.c:1200
#3 0x0805bd6f in dates_button_press_cb (widget=0x0, event=0x0,
d=0xbf8fbafc) at dates_callbacks.c:1661
#4 0x401a5614 in gtk_marshal_VOID__UINT_STRING ()
from /usr/lib/libgtk-x11-2.0.so.0
#5 0x4072929b in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0
#6 0x4073e408 in g_signal_has_handler_pending ()
from /usr/lib/libgobject-2.0.so.0
#7 0x4073f0ad in g_signal_emit_valist ()
from /usr/lib/libgobject-2.0.so.0
#8 0x4073f646 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0
#9 0x40290851 in gtk_widget_activate ()
from /usr/lib/libgtk-x11-2.0.so.0
#10 0x401a3bdd in gtk_propagate_event ()
from /usr/lib/libgtk-x11-2.0.so.0
#11 0x401a3e3f in gtk_main_do_event () from /usr/lib/libgtk-x11-2.0.so.0
#12 0x4039e841 in gdk_event_get_graphics_expose ()
from /usr/lib/libgdk-x11-2.0.so.0
#13 0x407c98e7 in g_main_context_dispatch ()
from /usr/lib/libglib-2.0.so.0
#14 0x407cb285 in g_main_context_acquire ()
from /usr/lib/libglib-2.0.so.0
#15 0x407cb5aa in g_main_loop_run () from /usr/lib/libglib-2.0.so.0
#16 0x401a334c in gtk_main () from /usr/lib/libgtk-x11-2.0.so.0
#17 0x080583fd in main (argc=1, argv=0xbf8fc414) at dates_main.c:569
--
To unsubscribe send a mail to pimlico+unsubscribe-xEU7zwZjznfQT0dZR+***@public.gmane.org
Ross Burton
2007-11-22 10:13:00 UTC
Permalink
Post by Jeffrey Perry
Ok, day before Thanksgiving here in the US - so I didn't get as much
time to look at his as I hoped but here is an update.
* The bug does reproduce inside scratchbox SDK_X86 :)
* Back trace follows (looks like it might be helpful to build a debug
version of eds-dbus - I can see in e-cal.c (part of libcal) that
it is being called and would like to know where specifically things go
amuck... Research for another day...
#0 0x404afacb in e_cal_create_object () from /usr/lib/libecal-1.2.so.3
#1 0x08059690 in dates_new (d=0xbf8fc2f0, comp=0x819a690, select=1) at
dates_callbacks.c:597
#2 0x0805ae74 in dates_new_cb (source=0x8089a60, d=0xbf8fc2f0) at
dates_callbacks.c:1200
Yeah, you'll need a debug package for libecal to trace that.
Alternatively, just before calling e_cal_create_object, print all of the
arguments to the console.

Ross
--
OpenedHand Ltd.

Unit R Homesdale Business Center / 216-218 Homesdale Road /
Bromley / BR1 2QZ / UK Tel: +44 (0)20 8819 6559

Expert Open Source For Consumer Devices - http://o-hand.com/
------------------------------------------------------------
Ross Burton
2007-11-21 09:07:48 UTC
Permalink
Post by Jeffrey Perry
Much build messiness can be avoided by setting the PKG_CONFIG_PATH
environment variable :-)
In fact it all just works...
export PKG_CONFIG_PATH="/targets/SDK_X86/usr/lib/pkgconfig"
autogen.sh
make
It looks like your scratchbox setup is bust, that should just work.
What does "sb-conf cu" print?

Ross
--
OpenedHand Ltd.

Unit R Homesdale Business Center / 216-218 Homesdale Road /
Bromley / BR1 2QZ / UK Tel: +44 (0)20 8819 6559

Expert Open Source For Consumer Devices - http://o-hand.com/
------------------------------------------------------------
Jeffrey Perry
2007-11-21 18:54:46 UTC
Permalink
sb-conf prints: SDK_X86
Post by Ross Burton
Post by Jeffrey Perry
Much build messiness can be avoided by setting the PKG_CONFIG_PATH
environment variable :-)
In fact it all just works...
export PKG_CONFIG_PATH="/targets/SDK_X86/usr/lib/pkgconfig"
autogen.sh
make
It looks like your scratchbox setup is bust, that should just work.
What does "sb-conf cu" print?
Ross
--
To unsubscribe send a mail to pimlico+unsubscribe-xEU7zwZjznfQT0dZR+***@public.gmane.org
Jeffrey Perry
2007-11-19 22:23:48 UTC
Permalink
I meant bug #556 - not sure why I first typed 293.
Post by Jeffrey Perry
I checked on bug #293) (http://bugzilla.o-hand.com/show_bug.cgi?id=556)
recently ...looks like there has been no change.
I now find myself with a little time and I'd like to investigate it.
I need some general developer setup questions answered.
I have a scratchbox maemo dev environment setup now. (Maemo SDK 3.2
since I will be targeting an N800)
*) First try debugging under scratchbox X86 target.
Is this pointless, since I already know this bug does not occur
when run outside scratchbox on my x86 desktop?
*) Failing that, or not seeing the bug there...
Setup some sort of remote (I think scratchbox calls it TRANSPARENT)
debugging environment and use gdb running on the tablet to debug the
issue over a local usb connection
Question #1.5: Pointers to howtos on remote debugging on the N800 are
are welcome. I will of course be looking around
myself at maemo and via google.
Looks like dates needs libecal. Where can I find it in SVN so I can
build it inside scratchbox?
Will I need to build any other libs to get this to setup for
debugging? contacts? esd sync with dbus flags???
General question on the state of this project: Is continued
development for the N800 of the pimlico apps including the sync feature
a priority for Open Hand? I wish to try to help a bit, but of course
want to be sure my efforts contribute to other progress on the project.
Any word on releasing a roadmap with some dates? (I know this is a
recurring question - just hoping the answer has changed recently with
the arrival of the N810)
Thank you for your time and assistance!
--Jeff
--
To unsubscribe send a mail to pimlico+unsubscribe-xEU7zwZjznfQT0dZR+***@public.gmane.org
Jeffrey Perry
2007-11-24 17:30:09 UTC
Permalink
Made typo on last attempt to send to list...
Jeffrey Perry
2007-11-25 05:08:05 UTC
Permalink
Update - not much progress I'm afraid.

* I'm annoyed by a gdb error about source being newer than executable
when tracing into e-cal.c (dbus version) - despite checking the rev
installed from the o-hand repository (554) and downgrading my checkout
to that version (both for dates and eds)

* Turned on glib feature to crash on critical messages -
the easier to get a nice core dump on anything which should be of
concern

* Better characterized the bug - this bug effects recurring events
It is not a webcal related issue.

Noted: After double click on webcal event a warning on console
"could not find recurring event"
This is probably relevant and noteworthy - I had been ignoring it.

Thanksgiving and Christmas
both cause the crash - they both have a recurrence rule.
The issue may come done to a recurrence rule feature that is not
yet implemented. There is evidence of this in the ecal code -
a comment to the effect that only 8 rules are implemented by libical
but there should be "107 * 7"??

Also noted, dbus assertion failing after the initial double click
on webcal event - the message says the dbus proxy went away...not
sure if this is a separate issue or caused by the main bug.

* I am able to avoid the crash by using gdb to force
a return from e_cal_generate_instances_for_object
(dbus version of e-cal.c) just before the unref function is
called...so there may be a reference counting issue here.
A quick inspection did not reveal where ref was being called on the
object in question.

I would like to be able to avoid the bug at a higher level of code
and now suspect the ical parser as choking on the ics and not
producing a reasonable representation for dates - perhaps it sets
the recurrence flag but fails to finish the recurrence rule parsing
due to use of some not yet implemented feature...?
Post by Jeffrey Perry
Made typo on last attempt to send to list...
email message attachment, "Forwarded message - Re: [pimlico] Debugging
Bug #556"
-------- Forwarded Message --------
Subject: Re: [pimlico] Debugging Bug #556
Date: Sat, 24 Nov 2007 11:18:54 -0500
Ok, I got this setup and it works nicely.
I set things up as suggested in the maemo debugging wiki page -
including installing another gdb ie "native" gdb and setting up an alias
to use it in all cases. I know it supports threads and the scratchbox
version does not. Is there any reason I will ever need the scratchbox
version?
I found another reference to the symlink need on another wiki page which
discussed debugging and mentioned that installing
maemo-debugging-scripts would set this up along with installing the
debug files for libc and other stuff. So I installed it.
It would have been nice if the maemo SDK install docs suggested this, or
even did it as part of the installer (since it's needed for development)
and for that matter the installer probably should have installed the
"native" gdb AND setup the alias to use it....Anyway I'm set now.
THEORY
------
I have a working theory on this bug - I think perhaps double clicking on
a web cal appointment causes the dbus proxy to lose it's connection (I
see the warning about this on the console), then of course clicking on
any other day causes a crash because this proxy is probably used again.
This is just a theory though - need to confirm when this message appears
- if it appears after the double-click on the web-cal, then it makes
sense and my debugging will have to go in that direction.
More details...
It looks like a private copy of the ecal object is created
(e_cal_create_object in e-cal.c of libecal-dbus), then passed to a
evolution data server function
(org_gnome_evolution_dataserver_calendar_Cal_create_object) that I can't
locate the source for (Do you know where I can find it?), but when it
returns the priv pointer is null. The icalcomp pointer is also null
after this call - before the call it points to a nice icalcomp. I did
trace into icalcomponent_as_ical_string and confirmed that it is
returning a nice ical formatted string.
I have the variable values just before the call - but want to gain more
familiarity with the whole system and the way dates works - so want to
be able to step into the e_cal_create_object function.
Looks like I have installed the needed debug lib libecal-dbg from the
o-hand repository. The problem is that I want to use this lib - located
in /usr/lib/debug/usr/lib and LD_LIBRARY_PATH seems to be ignored (even
though I put it in .bashrc to make sure it is in place in case
run-standalone.sh launches sub-shells) I also recall and have checked
the ld man page section describing LD_RUN_PATH. This environment
variable does not seem to help either :-(
PS. I'm currently reading a wiki page on maemo debugging which says I
may need a symlink under /usr/lib/target to the real location...I may
try this but it doesn't feel like the correct solution.
That's the correct solution. gdb uses automagic to find the debug
libraries in /usr/lib/debug (they are not libraries, but ELF files with
the debug sections), but the scratchbox insanity breaks that magic. You
need the symlinks to let the magic work again.
Ross
--
To unsubscribe send a mail to pimlico+unsubscribe-xEU7zwZjznfQT0dZR+***@public.gmane.org
Loading...