Unnecessary library dependencies? / 1.2 release plans?
Axel Beckert
Today I updated the Debian package source to make it fit some recent
minor changes and noticed the following warnings:
dpkg-shlibdeps: warning: dependency on libdl.so.2 could be avoided if "debian/amora-cli/usr/bin/amorad" were not uselessly linked against it (they use none of its symbols).
dpkg-shlibdeps: warning: dependency on libz.so.1 could be avoided if "debian/amora-cli/usr/bin/amorad" were not uselessly linked against it (they use none of its symbols).
dpkg-shlibdeps: warning: dependency on libm.so.6 could be avoided if "debian/amora-cli/usr/bin/amorad" were not uselessly linked against it (they use none of its symbols).
dpkg-shlibdeps: warning: dependency on libfreetype.so.6 could be avoided if "debian/amora-cli/usr/bin/amorad" were not uselessly linked against it (they use none of its symbols).
dpkg-shlibdeps: warning: dependency on librt.so.1 could be avoided if "debian/amora-cli/usr/bin/amorad" were not uselessly linked against it (they use none of its symbols).
dpkg-shlibdeps: warning: dependency on libXext.so.6 could be avoided if "debian/amora-cli/usr/bin/amorad" were not uselessly linked against it (they use none of its symbols).
Is this really the case? Or are those false alarms?
BTW: How about the 1.2 release? I really would like to see 1.2's
enhancements in the next Debian release. The feature freeze for that
will be in March. My current plan to upload a even a pre-release
version of 1.2 to Debian unstable so that we have the features in for
the release, even if not everything is perfect yet. Fixing bugs after
the freeze is easy. Getting new versions with new features in isn't.
P.S.: I have now a Nokia N900 running Maemo. :-)
Regards, Axel
--
/~\ Plain Text Ribbon Campaign | Axel Beckert
\ / Say No to HTML in E-Mail and News | a...@deuxchevaux.org (Mail)
X See http://www.asciiribbon.org/ | a...@noone.org (Mail+Jabber)
/ \ I love long mails: http://email.is-not-s.ms/ | http://noone.org/abe/ (Web)
Ademar de Souza Reis Jr.
> Hi,
>
Hi.
> Today I updated the Debian package source to make it fit some recent
> minor changes and noticed the following warnings:
>
> dpkg-shlibdeps: warning: dependency on libdl.so.2 could be avoided if "debian/amora-cli/usr/bin/amorad" were not uselessly linked against it (they use none of its symbols).
> dpkg-shlibdeps: warning: dependency on libz.so.1 could be avoided if "debian/amora-cli/usr/bin/amorad" were not uselessly linked against it (they use none of its symbols).
> dpkg-shlibdeps: warning: dependency on libm.so.6 could be avoided if "debian/amora-cli/usr/bin/amorad" were not uselessly linked against it (they use none of its symbols).
> dpkg-shlibdeps: warning: dependency on libfreetype.so.6 could be avoided if "debian/amora-cli/usr/bin/amorad" were not uselessly linked against it (they use none of its symbols).
> dpkg-shlibdeps: warning: dependency on librt.so.1 could be avoided if "debian/amora-cli/usr/bin/amorad" were not uselessly linked against it (they use none of its symbols).
> dpkg-shlibdeps: warning: dependency on libXext.so.6 could be avoided if "debian/amora-cli/usr/bin/amorad" were not uselessly linked against it (they use none of its symbols).
>
> Is this really the case? Or are those false alarms?
You can ignore these. amorad doesn't require these symbols
itself, but libamora does. The right way to fix this would be
to link the library directly with whatever libs it needs
internally, but this is hardly a problem, because we already
provide the necessary build flags to the applications via
pkgconfig.
Patches are welcome as usual, but I believe this is of low
priority.
>
> BTW: How about the 1.2 release? I really would like to see 1.2's
> enhancements in the next Debian release. The feature freeze for that
> will be in March. My current plan to upload a even a pre-release
> version of 1.2 to Debian unstable so that we have the features in for
> the release, even if not everything is perfect yet. Fixing bugs after
> the freeze is easy. Getting new versions with new features in isn't.
I don't know about Adenilson's plans, but I have the following in
my TODO list:
1. Major refactorings on amora-gui. The code was written when I
was very inexperient in Qt. Just looking at the code makes my
eyes hurt. :-) I should have something ready in the next weeks.
2. The S60 client doesn't work on S60-5th generation phones
(touch-screens). I'm not familiar with the new python APIs, but
I hope it's easy to add a kind of "virtual keypad" (have seen
something similar with the gmail app), so that we can avoid having
to remake the whole UI there.
>
> P.S.: I have now a Nokia N900 running Maemo. :-)
I envy you... :-) Right now I'm stuck with a 5800 and
an old n800.
Cheers,
- Ademar
--
Ademar de Souza Reis Jr. <adema...@gmail.com>
http://www.ademar.org/ || http://blog.ademar.org/
^[:wq!
Adenilson Cavalcanti
Long time no see you! How are you doing man? I checked in you blog and
it seems that now you have a @debian.org email, right?
Congratulations!
:-)
>>
>> Is this really the case? Or are those false alarms?
>
I think concerning the linking issues, Ademar has answered it already.
>
>>
>> BTW: How about the 1.2 release? I really would like to see 1.2's
>> enhancements in the next Debian release. The feature freeze for that
>> will be in March. My current plan to upload a even a pre-release
>> version of 1.2 to Debian unstable so that we have the features in for
>> the release, even if not everything is perfect yet. Fixing bugs after
>> the freeze is easy. Getting new versions with new features in isn't.
Maybe we could package the server as it is now, it is not perfect but
is pretty stable (and the Qt based applet besides a bit crude is a big
improvement from usability view).
> I don't know about Adenilson's plans, but I have the following in
> my TODO list:
>
> 1. Major refactorings on amora-gui. The code was written when I
> was very inexperient in Qt. Just looking at the code makes my
> eyes hurt. :-) I should have something ready in the next weeks.
>
Hahhahaha... all good hackers are heavy critics of his own code?
I wonder if it would not be interesting to make it a plasmoid and make
it run inside of plasma-desktop (so we could use QGraphicsView and
make it a lot fancier). The cons: it would non longer work in Gnome.
Any thoughts?
> 2. The S60 client doesn't work on S60-5th generation phones
> (touch-screens). I'm not familiar with the new python APIs, but
> I hope it's easy to add a kind of "virtual keypad" (have seen
> something similar with the gmail app), so that we can avoid having
> to remake the whole UI there.
>
Well, I was expecting for nokia to finally release PyS60 2.0 and then
address the issue of touchscreen based cellphones. I checked the API
for touchscreen in PyS60 1.9.7rc and it sounded horribly. My personal
opinion is that Nokia is moving away from Python and focusing in Qt +
javascript.
In this case, it might be interesting to write a new client in Qt
(with the benefit that the same code base could run in both Symbian
and Maemo phones at least for UI code).
The current PoC for Maemo is a different code base than the client for
the cellphone, and if it was instructional to code it (EFL) and see it
running in both maemo and even openmoko, it would bring problems to
maintain both (PyS60 + PyEFL) and so this is one of the reasons why I
never made it public.
The only missing key here is connectivity: it would require us to
write a wrapper for service discovery and bluetooth socket init and
I/O for Linux and Symbian, since ATM Qt doesn't have it. If
successful, this classes could be reused by other projects too
(libqtbt sounds too zany?).
My only concern is that currently I'm lacking the free time to dive
into it and make it happen (and maybe because amora used to work
pretty well, it never attracted many contributors/developers since it
pretty much got the job done without hiccups). Any thoughts?
Best regards
Adenilson
Ademar de Souza Reis Jr.
> >>
> >> BTW: How about the 1.2 release? I really would like to see 1.2's
> >> enhancements in the next Debian release. The feature freeze for that
> >> will be in March. My current plan to upload a even a pre-release
> >> version of 1.2 to Debian unstable so that we have the features in for
> >> the release, even if not everything is perfect yet. Fixing bugs after
> >> the freeze is easy. Getting new versions with new features in isn't.
>
> Maybe we could package the server as it is now, it is not perfect but
> is pretty stable (and the Qt based applet besides a bit crude is a big
> improvement from usability view).
Just wait a few more days as a new applet is going to be
available in the next days (the carnival in Brazil is the best
time of the year to hack some code) :-)
>
> > I don't know about Adenilson's plans, but I have the following in
> > my TODO list:
> >
> > �1. Major refactorings on amora-gui. The code was written when I
> > �was very inexperient in Qt. Just looking at the code makes my
> > �eyes hurt. :-) I should have something ready in the next weeks.
> >
>
> Hahhahaha... all good hackers are heavy critics of his own code?
>
> I wonder if it would not be interesting to make it a plasmoid and make
> it run inside of plasma-desktop (so we could use QGraphicsView and
> make it a lot fancier). The cons: it would non longer work in Gnome.
> Any thoughts?
Since there's a libamora available, there's the possibility to
write different server frontends. Particularly I don't have
interest in a plasmoid implementation as I don't use KDE
(and don't plan to, fluxbox rocks!) :-)
So I'll focus on the amora-applet, which is simple but
should work on any desktop environment.
>
>
> > �2. The S60 client doesn't work on S60-5th generation phones
I think this is the best plan, but requires some manpower which
is probably not available at the moment. My hope with the pys60 client
is that porting it to the touch-based phones should take little
effort, but I haven't investigated it yet (in my dreams it's
just a matter of adding a few lines of code to add a virtual
keypad, as seen in gmail-app for s60).
The pys60-2.0 was available as an update for my N5800 XM, but I
couldn't find it anywhere else. I guess we're stuck with
the devel version (1.9.7) for a while.
Cheers,
- Ademar
--
Ademar de Souza Reis Jr. <ade...@ademar.org>
Axel Beckert
I'm glad to see that there is still life in here. :-)
On Tue, Feb 02, 2010 at 06:31:23PM -0300, Ademar de Souza Reis Jr. wrote:
> > Today I updated the Debian package source to make it fit some recent
> > minor changes and noticed the following warnings:
> >
> > [...]
> >
> > Is this really the case? Or are those false alarms?
>
> You can ignore these. amorad doesn't require these symbols
> itself, but libamora does. The right way to fix this would be
> to link the library directly with whatever libs it needs
> internally, but this is hardly a problem, because we already
> provide the necessary build flags to the applications via
> pkgconfig.
I see. Thanks for the explanation!
Does that have to do with the current static linking Adenilson once
told me about? If we want it to be available for others to code with,
we definitely need it as shared library (and on Debian in its own
package, built from probably the same source package). I'm sure those
warnings will be history then, too.
On Tue, Feb 02, 2010 at 09:55:23PM -0400, Adenilson Cavalcanti wrote:
> Long time no see you! How are you doing man? I checked in you blog and
> it seems that now you have a @debian.org email, right?
Yeah, I'm now an official Debian developer with full upload rights. No
more need to look for upload sponsors. :-)
> Congratulations!
> :-)
Thanks! :-)
> >> BTW: How about the 1.2 release? I really would like to see 1.2's
> >> enhancements in the next Debian release. The feature freeze for that
> >> will be in March. My current plan to upload a even a pre-release
> >> version of 1.2 to Debian unstable so that we have the features in for
> >> the release, even if not everything is perfect yet. Fixing bugs after
> >> the freeze is easy. Getting new versions with new features in isn't.
>
> Maybe we could package the server as it is now, it is not perfect but
> is pretty stable
I agree.
So I'll try to make the current ready for uploading to Debian.
Any plans to give the current (or a close future) state a version
number, even if only 1.2 beta or rc?
> (and the Qt based applet besides a bit crude is a big improvement
> from usability view).
Yep.
> I wonder if it would not be interesting to make it a plasmoid and make
> it run inside of plasma-desktop (so we could use QGraphicsView and
> make it a lot fancier).
But only if we can keep the current applet, too.
> The cons: it would non longer work in Gnome.
... neither XFCE or any of the DE-agnostic system trayers.
> Any thoughts?
On Wed, Feb 03, 2010 at 11:07:06AM -0300, Ademar de Souza Reis Jr. wrote:
> Since there's a libamora available, there's the possibility to
> write different server frontends. Particularly I don't have
> interest in a plasmoid implementation as I don't use KDE
> (and don't plan to, fluxbox rocks!) :-)
>
> So I'll focus on the amora-applet, which is simple but
> should work on any desktop environment.
I also think we should focus on wide range usability first.
> > 2. The S60 client doesn't work on S60-5th generation phones
> > (touch-screens). I'm not familiar with the new python APIs, but
> > I hope it's easy to add a kind of "virtual keypad" (have seen
> > something similar with the gmail app), so that we can avoid having
> > to remake the whole UI there.
>
> Well, I was expecting for nokia to finally release PyS60 2.0 and then
> address the issue of touchscreen based cellphones. I checked the API
> for touchscreen in PyS60 1.9.7rc and it sounded horribly.
From what I heard from otherwise Symbian fans is that the UI itself
seems horrible, too.
> My personal opinion is that Nokia is moving away from Python and
> focusing in Qt + javascript.
Hmmm, the GNOME guys seem to like JavaScript as UI scripting language,
too.
> In this case, it might be interesting to write a new client in Qt
> (with the benefit that the same code base could run in both Symbian
> and Maemo phones at least for UI code).
*nod*
> The current PoC for Maemo is a different code base than the client for
> the cellphone, and if it was instructional to code it (EFL) and see it
> running in both maemo and even openmoko, it would bring problems to
> maintain both (PyS60 + PyEFL) and so this is one of the reasons why I
> never made it public.
I see.
So I should keep away from my current idea that my next step would be
to build the Maemo/OpenMoko client and the server variants from one
source package for Debian? (Which btw. also "runs" in a chroot on the
N900 and I'll probably try to use it on the N900 from within the
Debian chroot. :-)
> My only concern is that currently I'm lacking the free time to dive
> into it and make it happen (and maybe because amora used to work
> pretty well, it never attracted many contributors/developers since it
> pretty much got the job done without hiccups).
Hehe, yeah, I know quite some happy users. :-)
On Wed, Feb 03, 2010 at 11:07:06AM -0300, Ademar de Souza Reis Jr. wrote:
> On Tue, Feb 02, 2010 at 09:55:23PM -0400, Adenilson Cavalcanti wrote:
> > >> BTW: How about the 1.2 release? I really would like to see 1.2's
> > >> enhancements in the next Debian release. The feature freeze for that
> > >> will be in March. My current plan to upload a even a pre-release
> > >> version of 1.2 to Debian unstable so that we have the features in for
> > >> the release, even if not everything is perfect yet. Fixing bugs after
> > >> the freeze is easy. Getting new versions with new features in isn't.
> >
> > Maybe we could package the server as it is now, it is not perfect but
> > is pretty stable (and the Qt based applet besides a bit crude is a big
> > improvement from usability view).
>
> Just wait a few more days as a new applet is going to be
> available in the next days
Ok.
> (the carnival in Brazil is the best time of the year to hack some
> code) :-)
Hehe. I'm quite happy that Zurich is one of the regions in Switzerland
where they don't have carneval (at least not during the usual carneval
time and not called carneval ;-)...
Regards, Axel
--
Axel Beckert - a...@deuxchevaux.org, a...@noone.org - http://noone.org/abe/
Axel Beckert
On Wed, Feb 03, 2010 at 11:07:06AM -0300, Ademar de Souza Reis Jr. wrote:
> > Maybe we could package the server as it is now, it is not perfect but
> > is pretty stable (and the Qt based applet besides a bit crude is a big
> > improvement from usability view).
>
> Just wait a few more days as a new applet is going to be
> available in the next days (the carnival in Brazil is the best
> time of the year to hack some code) :-)
Hrm, the current revision (r668) doesn't seem to build anymore:
Being in amora-server/amora-applet, make calls the following command
which fails:
$ g++ -o amorad-gui amora-server.o applet.o about.o moc_amora-server.o moc_applet.o moc_about.o qrc_amora-applet.o -L/usr/lib -ldbus-1 -lrt -lbluetooth -lX11 -lImlib2 -lXtst -lQtGui -lQtCore -lpthread
amora-server.o: In function `Amora':
/home/abe/amora/amora-server/amora-applet/amora-server.cpp:73: undefined reference to `amora_context_new'
/home/abe/amora/amora-server/amora-applet/amora-server.cpp:78: undefined reference to `amora_connection_callback'
/home/abe/amora/amora-server/amora-applet/amora-server.cpp:79: undefined reference to `amora_disconnection_callback'
/home/abe/amora/amora-server/amora-applet/amora-server.cpp:73: undefined reference to `amora_context_new'
/home/abe/amora/amora-server/amora-applet/amora-server.cpp:78: undefined reference to `amora_connection_callback'
/home/abe/amora/amora-server/amora-applet/amora-server.cpp:79: undefined reference to `amora_disconnection_callback'
amora-server.o: In function `~Amora':
/home/abe/amora/amora-server/amora-applet/amora-server.cpp:133: undefined reference to `amora_context_delete'
/home/abe/amora/amora-server/amora-applet/amora-server.cpp:133: undefined reference to `amora_context_delete'
/home/abe/amora/amora-server/amora-applet/amora-server.cpp:133: undefined reference to `amora_context_delete'
amora-server.o: In function `Amora::run()':
/home/abe/amora/amora-server/amora-applet/amora-server.cpp:138: undefined reference to `amora_start'
collect2: ld returned 1 exit status
make: *** [amorad-gui] Error 1
If I add just a "-lamora", it compiles again.
Any idea where to tell that qt4-qmake that this additional libary has
to be used when generating that line?
I could add a "SUBLIBS=-lamora" to the make call in the Debian
packaging, but this seems to be a generic problem.
Adenilson
That is funny, builds and compile fine here (Ubuntu 9.10)
Regards
Adenilson
Ademar de Souza Reis Jr.
Hi Axel.
I'm sorry for the late reply.
Please let me know the full sequences of commands you're using to
build amora.
It should work fine with the Makefile in the amora-server/ dir
(out of the box, without the need of anything extra) and should
also work fine in cases where libamora is installed on the
system.
Axel Beckert
On Thu, Feb 18, 2010 at 04:34:39PM -0300, Ademar de Souza Reis Jr. wrote:
> > Being in amora-server/amora-applet, make calls the following command
> > which fails:
> >
> > $ g++ -o amorad-gui amora-server.o applet.o about.o moc_amora-server.o moc_applet.o moc_about.o qrc_amora-applet.o -L/usr/lib -ldbus-1 -lrt -lbluetooth -lX11 -lImlib2 -lXtst -lQtGui -lQtCore -lpthread
> > amora-server.o: In function `Amora':
> > /home/abe/amora/amora-server/amora-applet/amora-server.cpp:73: undefined reference to `amora_context_new'
> > /home/abe/amora/amora-server/amora-applet/amora-server.cpp:78: undefined reference to `amora_connection_callback'
> > /home/abe/amora/amora-server/amora-applet/amora-server.cpp:79: undefined reference to `amora_disconnection_callback'
> > /home/abe/amora/amora-server/amora-applet/amora-server.cpp:73: undefined reference to `amora_context_new'
> > /home/abe/amora/amora-server/amora-applet/amora-server.cpp:78: undefined reference to `amora_connection_callback'
> > /home/abe/amora/amora-server/amora-applet/amora-server.cpp:79: undefined reference to `amora_disconnection_callback'
> > amora-server.o: In function `~Amora':
> > /home/abe/amora/amora-server/amora-applet/amora-server.cpp:133: undefined reference to `amora_context_delete'
> > /home/abe/amora/amora-server/amora-applet/amora-server.cpp:133: undefined reference to `amora_context_delete'
> > /home/abe/amora/amora-server/amora-applet/amora-server.cpp:133: undefined reference to `amora_context_delete'
> > amora-server.o: In function `Amora::run()':
> > /home/abe/amora/amora-server/amora-applet/amora-server.cpp:138: undefined reference to `amora_start'
> > collect2: ld returned 1 exit status
> > make: *** [amorad-gui] Error 1
> >
> > If I add just a "-lamora", it compiles again.
> >
> > Any idea where to tell that qt4-qmake that this additional libary has
> > to be used when generating that line?
> >
> > I could add a "SUBLIBS=-lamora" to the make call in the Debian
> > packaging, but this seems to be a generic problem.
>
> [...]
>
> Please let me know the full sequences of commands you're using to
> build amora.
"debuild -uc -us" or "dpkg-buildpackage -uc -us" :-)
Sorry for not mentioning this earlier. I didn't expect any difference
between building it for the package and just calling "make",
especially because I wrote that Makefile initially. ;-)
> It should work fine with the Makefile in the amora-server/ dir
> (out of the box, without the need of anything extra) and should
> also work fine in cases where libamora is installed on the
> system.
Don't bother, it works also here, if you just type "make". But it
doesn't work anymore if you try build the Debian package.
It's still on my todo list to find out why exactly this happens. I
would be glad if some else finds the issue or at least some hints, but
I don't mind, if you don't bother about package building issues which
don't happen otherwise.
As soon as I found it, I would like to upload a new package to Debian,
e.g. with a version number 1.2~pre-r674 or so to get it in before the
freeze. (Didn't manage that the last time.)
Axel Beckert
a small update on this issue:
On Thu, Feb 18, 2010 at 11:00:01PM +0100, Axel Beckert wrote:
> > > $ g++ -o amorad-gui amora-server.o applet.o about.o moc_amora-server.o moc_applet.o moc_about.o qrc_amora-applet.o -L/usr/lib -ldbus-1 -lrt -lbluetooth -lX11 -lImlib2 -lXtst -lQtGui -lQtCore -lpthread
> > > amora-server.o: In function `Amora':
> > > /home/abe/amora/amora-server/amora-applet/amora-server.cpp:73: undefined reference to `amora_context_new'
[...]
> > > collect2: ld returned 1 exit status
> > > make: *** [amorad-gui] Error 1
> > >
> > > If I add just a "-lamora", it compiles again.
[...]
> "debuild -uc -us" or "dpkg-buildpackage -uc -us" :-)
>
> Sorry for not mentioning this earlier. I didn't expect any difference
> between building it for the package and just calling "make",
> especially because I wrote that Makefile initially. ;-)
But it does. It's not the call to configure as I suspected first, but
somewhen later:
Build normal calls at the end:
g++ -o amorad-gui amora-server.o applet.o about.o moc_amora-server.o \
moc_applet.o moc_about.o qrc_amora-applet.o -L/usr/lib \
-L/home/abe/amora/amora-server/amora-cli -lamora \
-ldbus-1 -lrt -lbluetooth -lX11 -lImlib2 -lXtst -lQtGui \
-lQtCore -lpthread
Build the package, that line misses two essential parameters:
g++ -o amorad-gui amora-server.o applet.o about.o moc_amora-server.o \
moc_applet.o moc_about.o qrc_amora-applet.o -L/usr/lib \
-ldbus-1 -lrt -lbluetooth -lX11 -lImlib2 -lXtst -lQtGui \
-lQtCore -lpthread
I know a workaround,
> > > Any idea where to tell that qt4-qmake that this additional libary has
> > > to be used when generating that line?
> > >
> > > I could add a "SUBLIBS=-lamora" to the make call in the Debian
> > > packaging, but this seems to be a generic problem.
but would like to know why this happens and fix it for real.
Working on it...
Axel Beckert
On Sat, Feb 20, 2010 at 02:19:42AM +0100, Axel Beckert wrote:
> > > > $ g++ -o amorad-gui amora-server.o applet.o about.o moc_amora-server.o moc_applet.o moc_about.o qrc_amora-applet.o -L/usr/lib -ldbus-1 -lrt -lbluetooth -lX11 -lImlib2 -lXtst -lQtGui -lQtCore -lpthread
> > > > amora-server.o: In function `Amora':
> > > > /home/abe/amora/amora-server/amora-applet/amora-server.cpp:73: undefined reference to `amora_context_new'
> [...]
> > > > collect2: ld returned 1 exit status
> > > > make: *** [amorad-gui] Error 1
> > > >
> > > > If I add just a "-lamora", it compiles again.
Found the culprit: It was "$(PWD)" when setting the (in my case
previously unset) variable PKG_CONFIG_PATH. PWD is a environment
variable usually set in the shell environment and not during the build
process or by make.
When building Debian packages this variable is removed from the
environment. That's why the build worked manually but failed when
building the package. The result was the following nonsense value in
the variable PKG_CONFIG_PATH: ":/amora-cli"
I now changed the code so that we first determine the current working
directory in the Makefile using $(shell pwd), assigning this value to
a variable and using this variable instead of PWD.
I also removed the concatenation since according to the pkg-config man
page "the default directory will always be searched after searching
the path" and if unset in the beginning, the path would contain the
empty string as first path.
If removing the concatenation of a previous value PKG_CONFIG_PATH
causes problems for other build environments, please feel free to
re-add it. But it works fine for me without, independent if I build it
from the commandline or as Debian package.
Ademar: Are you finished with the announce code refactoring? If yes, I
would prepare a Debian package, test it, and if it works fine, upload
it to Debian unstable.
Ademar de Souza Reis Jr.
I was about to reply to your previous e-mail saying that
PKG_CONFIG_PATH (which was set by me a few commits ago) was not
being set in your build environment. Good to know you've found
the reason. :-)
>
> Ademar: Are you finished with the announce code refactoring? If yes, I
> would prepare a Debian package, test it, and if it works fine, upload
> it to Debian unstable.
I still have the final commit, but it requires testing and
unfortunately I can't use amora with my 5800 XM (touch screen).
I didn't succeed building amora-client with latest python due to
several changes in the API, so I'm stuck. (AFAIK a virtual keypad
would appear automagically when using pys60-2.0).
I'll search for and try to charge the battery of an old phone I
have at home, but if you can run a few tests with a phone of
yours, it'll be really welcome (there are a lot of changes, I'm
not very confident it'll work on the first try).
The code is in a wip branch on my personal git repository:
http://git.ademar.org/gitweb.cgi?p=amora-applet.git;a=shortlog;h=refs/heads/wip
$ git clone http://git.ademar.org/amora-applet.git
$ git checkout wip
(BTW, I'm ademar @ freenode if there's any question)
Thanks,