Re: Promotion
Hi, same here, so it might be a general problem with the Diablo promoter. Besides taking 9 days for the package interface to recognize that a package has been updated, and then complaining that the package didn't have a proper description (which it certainly has). The package icon is not imported, either. Please somebody look at the Diablo package interface to see what's going wrong. For information, my stuck Diablo package is 'fmradio-player 2010.03.20-2'. Regards, Martin 2010/4/4, George Kibardin george-kibar...@yandex.ru: Hi everybody, It seems that I missed something. Suddenly I cannot promote the latest version of my app from diablo extras-devel to diablo extras. I've read this http://wiki.maemo.org/Uploading_to_Extras, tried this https://garage.maemo.org/promoter/diablo and still no luck. I see my app in extras-devel, but there is nothing like promote button. P.S. I see that for Fremantle promotion process is more complex, but I still cannot get the idea - what to do to initiate promotion process? Best, George ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Not able to install Hildon Test Automation Framework on N900
Hi , I tried the steps suggested in the following link. http://hildon-test-aut.garage.maemo.org/installation.html Steps I have tried: 1. Installed all .deb packages as pointed by the above link. 2. arm_for_testing on. executed the command rebooted 3. Install Dogtail from the above link cd dogtail; ./setup.py install 4. Then tested an example application sniff, which is present in the dogtail. - sniff not working - It throws error ImportError: cannot import name checkForA11yInteractively I enabled Accessibility through gconftool-2 --type bool --set /desktop/gnome/interface/accessibility true But still the same error. I jus tried the following 1. python2.5 2. import pyatspi Traceback (most recent call last): File stdin, line 1, in module ImportError: No module named pyatspi I installed python-at-spi_0.6.1-1osso2_armel.deb package from the above link. but still it is showing no module pyatspi. All I need is to install dogtail and thus Hildon Test Automation framework successfully and write some test scripts on N900. any Help will be greatly appreciated. -Praveen. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
ssh uploading to gregale/bora/chinook extras broken?
Hello, I have a problem with upload binary deb to gregale/bora/chinook extras. Is this supposed to be working? First I noticed that server key was changed so I needed to remove old one from known hosts. And then uploading via dput still fails with permisison denied, see below Permission denied (publickey). lost connection Warning: The execution of '/usr/bin/scp' as 'scp -p /scratchbox/users/maemo/home/maemo/scummvm/scummvm_1.1.0_armel.deb /scratchbox/users/maemo/home/maemo/scummvm/scummvm_1.1.0_armel.changes fano...@garage:/var/www/extras/incoming/gregale' returned a nonzero exit code. Error while uploading. I have checked my garage account and my ssh key is still there. My ~/.dput.cf has following section [gregale-extras] login = fanoush fqdn = garage method = scp hash = md5 allow_unsigned_uploads = 0 incoming = /var/www/extras/incoming/gregale Same thing happens with Bora. It worked fine last time I needed it (2009-12-01). And BTW I canot find this in maemo wiki anywhere (due to cleanups?) It should be documented in http://wiki.maemo.org/Extras. Nearest relevant topic is http://wiki.maemo.org/Uploading_to_Extras-devel#dput Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: ssh uploading to gregale/bora/chinook extras broken?
On Wed, Apr 7, 2010 at 10:16, Frantisek Dufka duf...@seznam.cz wrote: I have a problem with upload binary deb to gregale/bora/chinook extras. Is this supposed to be working? First I noticed that server key was changed so I needed to remove old one from known hosts. And then uploading via dput still fails with permisison denied, see below Permission denied (publickey). [...] fano...@garage:/var/www/extras/incoming/gregale' Should this now be drop.maemo.org? The change wasn't well communicated at all, especially the impact on the legacy servers. One of the advantages of the new servers was to fix bug #3354. If the old server is still used for legacy builds, you might still be seeing it: https://bugs.maemo.org/show_bug.cgi?id=3354 HTH, Andrew -- Andrew Flegg -- mailto:and...@bleb.org | http://www.bleb.org/ Maemo Community Council chair ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Not able to install Hildon Test Automation Framework on N900
From: praveen koduru prawin1...@gmail.com Hi , I tried the steps suggested in the following link. http://hildon-test-aut.garage.maemo.org/installation.html This is a really old guide. The target were the Nokia 770/810, not sure if works fine on N900. Steps I have tried: 1. Installed all .deb packages as pointed by the above link. 2. arm_for_testing on. executed the command rebooted 3. Install Dogtail from the above link cd dogtail; ./setup.py install 4. Then tested an example application sniff, which is present in the dogtail. - sniff not working - It throws error ImportError: cannot import name checkForA11yInteractively AFAIK, sniff have never worked. Have you tried to use directly dogtail? Something like: from dogtail import tree tree.root.dump () I enabled Accessibility through gconftool-2 --type bool --set /desktop/gnome/interface/accessibility true This is the way to enable the accessibility in the desktop, and it is more recently that the package version number used in that link. So, in this framework, this gconf variable is not used at all, it is just based on GTK_MODULES and other custom things. But still the same error. I jus tried the following 1. python2.5 2. import pyatspi Traceback (most recent call last): File stdin, line 1, in module ImportError: No module named pyatspi I installed python-at-spi_0.6.1-1osso2_armel.deb package from the above link. but still it is showing no module pyatspi. pyatspi is the last python accessibility bindings. This python-at-spi package is about the old python bindings. Try something like: $python2.5 import atspi And if it works, you could a script like this: #!/usr/bin/env python # Return the name of the applications currently registered import atspi desk = atspi.registry.getDesktop(0) for i in xrange(desk.getChildCount()): app = desk.getChildAtIndex(i) print Index: %d % i try: print Application name: %s % app.getName() print Application elements: %d % app.getChildCount() except Exception: print Error getting name or childcount print All I need is to install dogtail and thus Hildon Test Automation framework successfully and write some test scripts on N900. any Help will be greatly appreciated. As I said, have you tried to use directly dogtail instead of use Sniff? BR === API (apinhe...@igalia.com) ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: ssh uploading to gregale/bora/chinook extras broken?
Andrew Flegg wrote: Permission denied (publickey). [...] fano...@garage:/var/www/extras/incoming/gregale' Should this now be drop.maemo.org? The change wasn't well communicated at all, especially the impact on the legacy servers. Oh, thanks, I totally missed the server name change. But anyway drop.maemo.org works for scp login but now I am getting scp: /var/www/extras/incoming/gregale: No such file or directory What are corect paths for binary uploads to gregale/bora/chinook? Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Not able to install Hildon Test Automation Framework on N900
Thanks for the quick response Piñeiro.
I tried your 2 steps. Please find the results below.
Step 1:
Nokia-N900-42-11:/home/opt# python
Python 2.5.1 (r251:54863, May 23 2007, 17:32:51)
[GCC 3.4.4 (release) (CodeSourcery ARM 2005q3-2)] on linux2
Type help, copyright, credits or license for more information.
from dogtail import tree
Creating logfile at /tmp/dogtail/logs/log_20100407-130759_debug ...
Detecting distribution: Debian (or derived distribution)
Warning: AT-SPI's desktop is visible but it has no children. Are you running
any AT-SPI-aware applications?
tree.root.dump ()
{root}
(I have opened contacts and then did tree.root.dump(). but stilll giving
{root} only)
Step 2:
import atspi
works fine; I tried the script you have given. script executed but with no
prints
Nokia-N900-42-11:/home/opt# ./Piñeiro.py
Nokia-N900-42-11:/home/opt#
-Praveen
On Wed, Apr 7, 2010 at 3:14 PM, Piñeiro apinhe...@igalia.com wrote:
From: praveen koduru prawin1...@gmail.com
Hi ,
I tried the steps suggested in the following link.
http://hildon-test-aut.garage.maemo.org/installation.html
This is a really old guide. The target were the Nokia 770/810, not
sure if works fine on N900.
Steps I have tried:
1. Installed all .deb packages as pointed by the above link.
2. arm_for_testing on. executed the command rebooted
3. Install Dogtail from the above link
cd dogtail; ./setup.py install
4. Then tested an example application sniff, which is present in the
dogtail.
- sniff not working
- It throws error
ImportError: cannot import name
checkForA11yInteractively
AFAIK, sniff have never worked.
Have you tried to use directly dogtail? Something like:
from dogtail import tree
tree.root.dump ()
I enabled Accessibility through gconftool-2 --type bool --set
/desktop/gnome/interface/accessibility true
This is the way to enable the accessibility in the desktop, and it is
more recently that the package version number used in that link.
So, in this framework, this gconf variable is not used at all, it is
just based on GTK_MODULES and other custom things.
But still the same error.
I jus tried the following
1. python2.5
2. import pyatspi
Traceback (most recent call last):
File stdin, line 1, in module
ImportError: No module named pyatspi
I installed python-at-spi_0.6.1-1osso2_armel.deb package from the above
link. but still it is showing no module pyatspi.
pyatspi is the last python accessibility bindings. This python-at-spi
package is about the old python bindings. Try something like:
$python2.5
import atspi
And if it works, you could a script like this:
#!/usr/bin/env python
# Return the name of the applications currently registered
import atspi
desk = atspi.registry.getDesktop(0)
for i in xrange(desk.getChildCount()):
app = desk.getChildAtIndex(i)
print Index: %d % i
try:
print Application name: %s % app.getName()
print Application elements: %d % app.getChildCount()
except Exception: print Error getting name or childcount
print
All I need is to install dogtail and thus Hildon Test Automation
framework
successfully and write some test scripts on N900.
any Help will be greatly appreciated.
As I said, have you tried to use directly dogtail instead of use
Sniff?
BR
===
API (apinhe...@igalia.com)
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Not able to install Hildon Test Automation Framework on N900
From: praveen koduru prawin1...@gmail.com
Thanks for the quick response Piñeiro.
I tried your 2 steps. Please find the results below.
Step 1:
Nokia-N900-42-11:/home/opt# python
Python 2.5.1 (r251:54863, May 23 2007, 17:32:51)
[GCC 3.4.4 (release) (CodeSourcery ARM 2005q3-2)] on linux2
Type help, copyright, credits or license for more information.
from dogtail import tree
Creating logfile at /tmp/dogtail/logs/log_20100407-130759_debug ...
Detecting distribution: Debian (or derived distribution)
Warning: AT-SPI's desktop is visible but it has no children. Are you running
any AT-SPI-aware applications?
Anyway, please check if at-spi is running.
tree.root.dump ()
{root}
(I have opened contacts and then did tree.root.dump(). but stilll giving
{root} only)
As far as I remember arm-for testing just enable the accessibility
support for the applications included in the testing framework.
What it does is replace the launcher file application, in order to
launch the applications supported with GTK_MODULES=gail:hail:atk-bridge.
Remember that in maemo there are a maemo-launcher/invoker
application. Applications are loaded using this application.
I bet that contacts was not included in this framework, as it is a
really recent application.
You could try to modify by hand the contacts launch file, replacing
/usr/bin/osso-addresbook to something like this:
#!/bin/sh
unset AF_DEFINES_SOURCED
source /etc/osso-af-init/af-defines.sh
export GTK_MODULES=gail:hail:atk-bridge
exec maemo-summoner /usr/bin/osso-addressbook.launch
That is what arm-for-testing does (more or less, AFAIK) for the
supported applications.
Note: probably you should require to reboot the device after that.
Step 2:
import atspi
works fine; I tried the script you have given. script executed but with no
prints
Nokia-N900-42-11:/home/opt# ./Piñeiro.py
Nokia-N900-42-11:/home/opt#
It doesn't print anything as no application is registered on at-spi.
BR
===
API (apinhe...@igalia.com)
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Not able to install Hildon Test Automation Framework on N900
I have checked atspi is running or not like this
import atspi
(no errors). Is this the way to check whether it is running or not??
I am trying to get the object of Calculator app on N900. I really dont
know how to do that. where as on desktop I did like this for opening an
Totem application.
totem = tree.root.application('totem')
MovieMenu=totem.menu('Movie').click()
This justed worked on Desktop. Whereas to get the object of Calculator
App on Maemo. I did this
Calc=tree.root.application('/usr/bin/osso_calculator')
searching for child of {root}: /usr/bin/osso_calculator application
(attempt 3)
searching for child of {root}: /usr/bin/osso_calculator application
(attempt 4)
... and the trying went on.
So could you please suggest me how to get the object of Calculator and
click one button with that.
Thanks a lot for your help.
-Praveen
On Wed, Apr 7, 2010 at 4:35 PM, Piñeiro apinhe...@igalia.com wrote:
From: praveen koduru prawin1...@gmail.com
Thanks for the quick response Piñeiro.
I tried your 2 steps. Please find the results below.
Step 1:
Nokia-N900-42-11:/home/opt# python
Python 2.5.1 (r251:54863, May 23 2007, 17:32:51)
[GCC 3.4.4 (release) (CodeSourcery ARM 2005q3-2)] on linux2
Type help, copyright, credits or license for more information.
from dogtail import tree
Creating logfile at /tmp/dogtail/logs/log_20100407-130759_debug ...
Detecting distribution: Debian (or derived distribution)
Warning: AT-SPI's desktop is visible but it has no children. Are you
running
any AT-SPI-aware applications?
Anyway, please check if at-spi is running.
tree.root.dump ()
{root}
(I have opened contacts and then did tree.root.dump(). but stilll
giving
{root} only)
As far as I remember arm-for testing just enable the accessibility
support for the applications included in the testing framework.
What it does is replace the launcher file application, in order to
launch the applications supported with GTK_MODULES=gail:hail:atk-bridge.
Remember that in maemo there are a maemo-launcher/invoker
application. Applications are loaded using this application.
I bet that contacts was not included in this framework, as it is a
really recent application.
You could try to modify by hand the contacts launch file, replacing
/usr/bin/osso-addresbook to something like this:
#!/bin/sh
unset AF_DEFINES_SOURCED
source /etc/osso-af-init/af-defines.sh
export GTK_MODULES=gail:hail:atk-bridge
exec maemo-summoner /usr/bin/osso-addressbook.launch
That is what arm-for-testing does (more or less, AFAIK) for the
supported applications.
Note: probably you should require to reboot the device after that.
Step 2:
import atspi
works fine; I tried the script you have given. script executed but with
no
prints
Nokia-N900-42-11:/home/opt# ./Piñeiro.py
Nokia-N900-42-11:/home/opt#
It doesn't print anything as no application is registered on at-spi.
BR
===
API (apinhe...@igalia.com)
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: proper icon path
On 2010-04-06 15:35, Stefanos Harhalakis v...@v13.gr wrote: On Tuesday 06 of April 2010, daniel wilms wrote: ext Stefanos Harhalakis wrote: I'm currently using /usr/share/icons/hicolor/64x64/apps/, but I see other applications using /usr/share/icons/hicolor/64x64/hildon, or even /usr/share/icons/hicolor/scalable/apps and /usr/share/icons/hicolor/scalable/hildon. Is there a proper location or is everything acceptable? The proper location for the icons is in: /usr/share/icons/hicolor/scalable/hildon/ Thank you for clarifying that. Is there a reason why scalable was chosen? AFAIK for desktop systems this is supposed to hold scalable graphics like SVGs while bitmaps icons are supposed to go under /usr/share/icons/hicolor/AxB/ (AxB being the dimension) (or perhaps I know wrong). I would also like to know this, as I was going to edit a few wiki pages that mention install locations for icons. However, all the locations above seem to work just fine (I tested with a few applications), and the freedesktop.org icon naming specification suggests that ‘apps’ is the correct subdirectory to use: http://standards.freedesktop.org/icon-naming-spec/icon-naming-spec-latest.html#context Daniel, is /usr/share/icons/hicolor/scalable/hildon/ the canonical location for all application icons on Fremantle, and if so, where is this documented? -- David King | http://amigadave.com/ | dav...@openismus.com ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Promotion
On Wed, April 7, 2010 10:06, Martin Grimme wrote: Hi, Hi, same here, so it might be a general problem with the Diablo promoter. Besides taking 9 days for the package interface to recognize that a package has been updated, and then complaining that the package didn't have a proper description (which it certainly has). The package icon is not imported, either. Please somebody look at the Diablo package interface to see what's going wrong. For information, my stuck Diablo package is 'fmradio-player 2010.03.20-2'. You use long lines in your control file where 80 chars is recommended. The importer didn't like that so it left the entries empty. I've now changed the importer to import long lines too. Regards, Martin -- Niels Breet maemo.org webmaster ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Promotion
On Sun, April 4, 2010 20:42, George Kibardin wrote: Hi everybody, It seems that I missed something. Suddenly I cannot promote the latest version of my app from diablo extras-devel to diablo extras. I've read this http://wiki.maemo.org/Uploading_to_Extras, tried this https://garage.maemo.org/promoter/diablo and still no luck. I see my app in extras-devel, but there is nothing like promote button. The promote link is found on the armel version page of your application: http://maemo.org/packages/package_instance/view/diablo_extras-devel_free_armel/feedcircuit/0.7.6-2/ The link doesn't show because you are not using one of the sections listed in http://wiki.maemo.org/Package_Categories P.S. I see that for Fremantle promotion process is more complex, but I still cannot get the idea - what to do to initiate promotion process? Same thing. Go to the armel version of the package in fremantle extras-devel and click on promote. Best, George -- Niels Breet maemo.org webmaster ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: ssh uploading to gregale/bora/chinook extras broken?
On Wed, April 7, 2010 12:16, Frantisek Dufka wrote: Andrew Flegg wrote: Permission denied (publickey). [...] fano...@garage:/var/www/extras/incoming/gregale' Should this now be drop.maemo.org? The change wasn't well communicated at all, especially the impact on the legacy servers. Oh, thanks, I totally missed the server name change. But anyway drop.maemo.org works for scp login but now I am getting scp: /var/www/extras/incoming/gregale: No such file or directory Seems I missed a link there. Does it work for you now? What are corect paths for binary uploads to gregale/bora/chinook? I've added gregale to the wiki here: https://wiki.maemo.org/Uploading_to_Extras-devel#dput Bora has been dead for a while now, chinook is also EOL. Frantisek -- Niels Breet maemo.org webmaster ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
PR1.2 SDK for Extras-devel: how to solve?
Hi, The number of issues being caused by the deployment of PR1.2 SDK to the fremantle autobuilder is becoming critical. It doesn't even matter when PR1.2 is released, as we should have a way of dealing with this in-place for the next upgrade. BACKGROUND ~~ After the PR1.2 SDK was released, Niels deployed it to the autobuilder; enacting a plan which was discussed on this list. This has caused problems with libhildon dependencies, but the problems aren't just limited to that library: http://lists.maemo.org/pipermail/maemo-developers/2010-March/025668.html Both Niels and the Council believe we should do something to assist. WHAT WE SHOULD DO ~ We *need* to do something, both to improve the situation in -devel and -testing today, and test an approach for the next upgrade. The main requirements here are, I think: * It's not an excessive amount of work * It's a viable long term strategy * The QA process doesn't get broken Thoughts and comments from developers, or anyone else with a idea, will be much appreciated. OPTIONS ~~~ 1) Deploy SDKs as they are released; treat -devel and -testing as trunk. This is what we have now, I think we can say it doesn't work if there's going to be more than a few days between SDK release and device upgrade. Since Nokia doesn't pre-announce release dates, and last minute bugs could cause problems; I think we can rule this one out. 2) Revert the builder. This is basically a step backwards. Changing the builder config is easy. Cleaning up -devel and rebuilding the affected packages is quite some work as we don't have any scripts for that made yet. 3) Hack the SDK, create some kind of hybrid. This'd be bad enough if limited to just libhildon, but isn't viable and WILL cause unforeseen problems. Veto :-) 4) Create separate repos, build queues for pre- and post-1.2. Similar to what's been done for Extras proper. Creating the repos will be about a day work, but the part that sits on top of that (management scripts, Packages interface, QA queue) will probably take a week of work. There are hard issues around QA here. 5) Try building in each SDK in turn. My suggestion; when someone uploads to fremantle auto-builder it attempts to build the package against the PR1.1 SDK. If it succeeds, it goes into Extras-devel. If it fails to build, it gets built with the PR1.2 SDK, and so on. For an app with compile time symbol resolution (e.g. C/C++), this'd handle both cases quite nicely. Python apps would have to depend on the specific versions of bindings which gave them the features they wanted - again, not too much of a problem. At extras(-stable) promotion time you could even decide, based on actual binary package dependencies, whether to put in fremantle-1.2 or both fremantle-1.2 fremantle extras repos. This would fix another common complain, what if I don't upgrade for a few weeks. Larger packages could be prevent from being tried to built twice by stating a forced build dependency on a PR1.2 version of any system package. Some software won't install from -devel and -testing as it does now, but that will be reduced to the set of software which is actually using features that are unavailable. A HAM patch could grey out applications which were uninstallable, or show some other indication. This is, effectively, reinventing the more intelligent dpkg-shlibdeps: http://wiki.debian.org/Projects/ImprovedDpkgShlibdeps However, it deals with the following three circumstances: 1) Application uses API which has changed in later SDK. This will be built with PR1.1 SDK, succeeds and goes into Extras-devel. Can be promoted to Extras-testing but there's no clear way for a tester to know it won't work if their device is running the latest OS. 2) Application uses API which is unchanged in later SDK. This will be built with PR1.1 SDK, succeeds and goes into Extras-devel. Can be promoted to Extras-testing and tested on any device with PR1.1 or PR1.2. Once promoted it COULD go into fremantle and fremantle-1.2. 3) Application uses API which is introduced in later SDK. This will be built with PR1.1 SDK and fail. It will be rebuilt with PR1.2 SDK, succeed and go into Extras-devel. Can be promoted to Extras-testing and tested by testers using the most recent release. Once promoted it will go into fremantle-1.2. 6) Case-by-case basis. Developer complains: add a temporary exception to autobuilder to build $APPNAME with PR1.0/1.1 SDK, but goes into the shared extras-devel as now. Thanks in advance, Andrew -- Andrew Flegg -- mailto:and...@bleb.org | http://www.bleb.org/ Maemo Community Council chair ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Not able to install Hildon Test Automation Framework on N900
From: praveen koduru prawin1...@gmail.com
I have checked atspi is running or not like this
import atspi
(no errors). Is this the way to check whether it is running or not??
No, I mean something more simple:
ps aux | grep at-spi
I am trying to get the object of Calculator app on N900. I really dont
know how to do that. where as on desktop I did like this for opening an
Totem application.
totem = tree.root.application('totem')
MovieMenu=totem.menu('Movie').click()
This justed worked on Desktop. Whereas to get the object of Calculator
App on Maemo. I did this
Calc=tree.root.application('/usr/bin/osso_calculator')
searching for child of {root}: /usr/bin/osso_calculator application
(attempt 3)
searching for child of {root}: /usr/bin/osso_calculator application
(attempt 4)
... and the trying went on.
As I told you before, arm-for-testing on doesn't enable a11y for all
applications. Take into account that this link is for a automatic
testing framework, so it only include some applications.
In order to load the a11y modules, GTK_MODULES need to be set to
GTK_MODULES=gail:hail:atk-bridge.
arm-for-testing on change the launcher of the supported applications
in order to be sure that GTK_MODULES has the correct values.
So could you please suggest me how to get the object of Calculator and
click one button with that.
You could try the same suggestion I made in the previous mail related
with the contacts application. Try to change the calculator launcher,
in order to use the summoner and have the envvar with the correct
value:
#!/bin/sh
unset AF_DEFINES_SOURCED
source /etc/osso-af-init/af-defines.sh
export GTK_MODULES=gail:hail:atk-bridge
exec maemo-summoner /usr/bin/osso-addressbook.launch
In the same way, you could create a simple gtk application, without
maemo-launcher, and then try to execute it by hand in this way:
$GTK_MODULES=gail:hail:atk-bridge ./my-gtk-application
Thanks a lot for your help.
You are welcome, sorry for not be enough clear in my explanations, and
thanks to test it. I have Try if all a11y pieces works on n900 in my
TODO list for a long time.
-Praveen
BR
===
API (apinhe...@igalia.com)
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: PR1.2 SDK for Extras-devel: how to solve?
On Wed, 7 Apr 2010 14:55:51 +0100 Andrew Flegg and...@bleb.org wrote: Hi, The number of issues being caused by the deployment of PR1.2 SDK to the fremantle autobuilder is becoming critical. It doesn't even matter when PR1.2 is released, as we should have a way of dealing with this in-place for the next upgrade. BACKGROUND ~~ After the PR1.2 SDK was released, Niels deployed it to the autobuilder; enacting a plan which was discussed on this list. This has caused problems with libhildon dependencies, but the problems aren't just limited to that library: http://lists.maemo.org/pipermail/maemo-developers/2010-March/025668.html Both Niels and the Council believe we should do something to assist. WHAT WE SHOULD DO ~ We *need* to do something, both to improve the situation in -devel and -testing today, and test an approach for the next upgrade. The main requirements here are, I think: * It's not an excessive amount of work * It's a viable long term strategy * The QA process doesn't get broken Thoughts and comments from developers, or anyone else with a idea, will be much appreciated. OPTIONS ~~~ 1) Deploy SDKs as they are released; treat -devel and -testing as trunk. This is what we have now, I think we can say it doesn't work if there's going to be more than a few days between SDK release and device upgrade. Since Nokia doesn't pre-announce release dates, and last minute bugs could cause problems; I think we can rule this one out. 2) Revert the builder. This is basically a step backwards. Changing the builder config is easy. Cleaning up -devel and rebuilding the affected packages is quite some work as we don't have any scripts for that made yet. 3) Hack the SDK, create some kind of hybrid. This'd be bad enough if limited to just libhildon, but isn't viable and WILL cause unforeseen problems. Veto :-) 4) Create separate repos, build queues for pre- and post-1.2. Similar to what's been done for Extras proper. Creating the repos will be about a day work, but the part that sits on top of that (management scripts, Packages interface, QA queue) will probably take a week of work. There are hard issues around QA here. 5) Try building in each SDK in turn. My suggestion; when someone uploads to fremantle auto-builder it attempts to build the package against the PR1.1 SDK. If it succeeds, it goes into Extras-devel. If it fails to build, it gets built with the PR1.2 SDK, and so on. For an app with compile time symbol resolution (e.g. C/C++), this'd handle both cases quite nicely. Python apps would have to depend on the specific versions of bindings which gave them the features they wanted - again, not too much of a problem. At extras(-stable) promotion time you could even decide, based on actual binary package dependencies, whether to put in fremantle-1.2 or both fremantle-1.2 fremantle extras repos. This would fix another common complain, what if I don't upgrade for a few weeks. Larger packages could be prevent from being tried to built twice by stating a forced build dependency on a PR1.2 version of any system package. Some software won't install from -devel and -testing as it does now, but that will be reduced to the set of software which is actually using features that are unavailable. A HAM patch could grey out applications which were uninstallable, or show some other indication. This is, effectively, reinventing the more intelligent dpkg-shlibdeps: http://wiki.debian.org/Projects/ImprovedDpkgShlibdeps However, it deals with the following three circumstances: 1) Application uses API which has changed in later SDK. This will be built with PR1.1 SDK, succeeds and goes into Extras-devel. Can be promoted to Extras-testing but there's no clear way for a tester to know it won't work if their device is running the latest OS. 2) Application uses API which is unchanged in later SDK. This will be built with PR1.1 SDK, succeeds and goes into Extras-devel. Can be promoted to Extras-testing and tested on any device with PR1.1 or PR1.2. Once promoted it COULD go into fremantle and fremantle-1.2. 3) Application uses API which is introduced in later SDK. This will be built with PR1.1 SDK and fail. It will be rebuilt with PR1.2 SDK, succeed and go into Extras-devel. Can be promoted to Extras-testing and tested by testers using the most recent release. Once promoted it will go into fremantle-1.2. 6) Case-by-case basis. Developer complains: add a temporary exception to autobuilder to build $APPNAME with PR1.0/1.1 SDK, but goes into the shared extras-devel as now. Thanks in advance, Andrew Hello all, Pardon the intrusion from somebody who doesn't usually post on this list, but I think I might have some input. It seems to me that the real problem is actually the difficulty in
Bora/OS2007 extras is dead? Re: ssh uploading to gregale/bora/chinook extras broken?
Niels Breet wrote: Seems I missed a link there. Does it work for you now? Yes. Thanks. Bora has been dead for a while now, chinook is also EOL. Bora is dead? Oh really? So why there is http://maemo.org/downloads/OS2007/ with old version I cannot update? When and why was this discussed/decided? I am using OS2007 on my N800 and I like it (Opera, no huge menus, better UI speed overall). I want to support people who do want to keep OS2007 on their N800. And Bora is also alive as a hacker edition for 770. As for Chinook, well, Diablo broke some stuff in browser so it may be a good choice too but killing it is understandable. But why OS2007? Should we kill 770/OS2006 too? Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: PR1.2 SDK for Extras-devel: how to solve?
On Wed, Apr 7, 2010 at 15:13, Bryan Jacobs n...@landwarsin.asia wrote: It seems to me that the real problem is actually the difficulty in implementing #4 above. If there were magically separate infrastructure for each incompatible release, there would be no issue - a developer uploads their package to each repository for which it builds (preferably through a list of checkboxes in the web interface), and a user selects one or more package sources that match the preinstalled software on their device. No problems, mate. True; however what about the QA process? The UI at http://maemo.org/packages/ is getting better, but it's also getting more familiar. How do we: a) not confuse ad-hoc testers b) ensure that versions in all repos get tested? One suggestion would be to promote all versions simultaneously, but there are obvious drawbacks with that! So the real issue is that creating a new branch requires a nontrivial amount of work. This is a computerized system; computers excel at automation. Why not spend the one-off time to allow for near-instant creation of a new branch? Once that's done, future releases will just consist of oh, I should create a new repository for this release. Let me run that script again with a new name and then upload the new SDK release to it. Indeed. Have I missed some important consideration? I think the issues aren't technical (although streamlining the repo creation is obviously part of it), but more procedural. I could be wrong. I wonder what the testing squad think (I'll poke VDVsx). Cheers, Andrew -- Andrew Flegg -- mailto:and...@bleb.org | http://www.bleb.org/ Maemo Community Council chair ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: PR1.2 SDK for Extras-devel: how to solve?
On Wed, 7 Apr 2010 15:41:48 +0100 Andrew Flegg and...@bleb.org wrote: On Wed, Apr 7, 2010 at 15:13, Bryan Jacobs n...@landwarsin.asia wrote: It seems to me that the real problem is actually the difficulty in implementing #4 above. If there were magically separate infrastructure for each incompatible release, there would be no issue - a developer uploads their package to each repository for which it builds (preferably through a list of checkboxes in the web interface), and a user selects one or more package sources that match the preinstalled software on their device. No problems, mate. True; however what about the QA process? The UI at http://maemo.org/packages/ is getting better, but it's also getting more familiar. How do we: a) not confuse ad-hoc testers b) ensure that versions in all repos get tested? Each QA tester (probably) only uses one device for testing. If this is true, this means that applications get tested on the platform the QA testers are on. This doesn't guarantee coverage for any particular application/SDK combination, but it does mean that things that are important to (the QA) users will get more throughly used. I'm not convinced that's a bad thing. As long as the QA users make both positive and negative bug reports, I think this will probably work out while not totally satisfying (b) above. (a) is OK because each QA tester just uses the repos matching their device, and upgrades whenever the next level meets their own personal comfort level with the bleeding-edge-to-stability spectrum. One suggestion would be to promote all versions simultaneously, but there are obvious drawbacks with that! I wouldn't do that. I'd promote things when you have enough negative bug reports about the particular version. Some things will never get promoted if nobody loves them. Tough cookies - if nobody cares enough to test the package as it is, does it really need promotion? So the real issue is that creating a new branch requires a nontrivial amount of work. This is a computerized system; computers excel at automation. Why not spend the one-off time to allow for near-instant creation of a new branch? Once that's done, future releases will just consist of oh, I should create a new repository for this release. Let me run that script again with a new name and then upload the new SDK release to it. Indeed. Have I missed some important consideration? I think the issues aren't technical (although streamlining the repo creation is obviously part of it), but more procedural. I could be wrong. I wonder what the testing squad think (I'll poke VDVsx). I can't really say anything about whatever internal rules would restrict this from working. I obviously have an interest in the process working better than it has, so I felt like commenting. It would be a shame if it were more than a technical problem. It's easier to argue for longer about qualitative things. Cheers, Andrew Bryan Jacobs signature.asc Description: PGP signature ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
GSoC project discussion - MeeGo cloud storage support
Hi, First of all, I'm sorry I'm posting this so close to the deadline, I know how important it is to discuss any idea with developers and possible mentors beforehand. I'm interested in working on the cloud storage support project for the Maemo and MeeGo community. Before boring you with details about myself, I'd like to present you my ideas and hopefully get some feedback that will help me improve my final application. My proposed solution involves developing several separate applications that will communicate over DBus. The main application (which I will call cloud-storage for now) will be responsible for detecting which cloud storage services are available and will handle general configuration (like what folders to share, which services to use for each folder etc.). It will export a DBus object probably called com.meego.CloudStorage. It will watch for changes in files and folders and automatically notify the corresponding service implementations. A different application will provide an UI for configuring the service, implemented using Qt. Every cloud storage service will be implemented as a different process which will export a DBus object (something like com.meego.CloudStorage.Service.ServiceName). The object will include methods for uploading files and folders and signals for mirroring changes on the remote side. Each service will need to be configured separately by providing username, password and other necessary information. Services that I find interesting to implement first include Ubuntu One, Dropbox and Google Docs (Google now allows storing any file online, not only documents), with others following. The reasoning behind using DBus is that it allows great flexibility in many ways including programming language, perhaps also different implementations for the same service. It also allows other applications to interact or monitor the syncing process. Adding or removing services will be just as easy as installing some package. DBus being the only major dependency (apart from any libraries which cloud storage service implementation might use), the framework should have no problem running on both Maemo and MeeGo, or even on desktop environments. So, I'm eager to know what you think about the feasibility of this idea. I have intentionally omitted details about the implementation or specification, those will be included in my application. Right now, I want to know if implementing this over DBus seems like a good idea. An initial draft of my application supportiof my application supporting this idea will follow very soon. Thanks, Felix Kerekes (sttwister) ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: PR1.2 SDK for Extras-devel: how to solve?
Andrew Flegg wrote: Hi, The number of issues being caused by the deployment of PR1.2 SDK to the fremantle autobuilder is becoming critical. It doesn't even matter when PR1.2 is released, as we should have a way of dealing with this in-place for the next upgrade. I've copied the contents of your message to the wiki: http://wiki.maemo.org/Task:PR1.2_autobuilder I have also added some stuff about dpkg-shlibdeps that we have been discussing on IRC a few minutes ago. Feel free to add any extra options or cons of existing ones. -- Javier ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: PR1.2 SDK for Extras-devel: how to solve?
On Wed, April 7, 2010 16:41, Andrew Flegg wrote: On Wed, Apr 7, 2010 at 15:13, Bryan Jacobs n...@landwarsin.asia wrote: It seems to me that the real problem is actually the difficulty in implementing #4 above. If there were magically separate infrastructure for each incompatible release, there would be no issue - a developer uploads their package to each repository for which it builds (preferably through a list of checkboxes in the web interface), and a user selects one or more package sources that match the preinstalled software on their device. No problems, mate. True; however what about the QA process? The UI at http://maemo.org/packages/ is getting better, but it's also getting more familiar. How do we: a) not confuse ad-hoc testers b) ensure that versions in all repos get tested? This is a non-trivial issue. Testing against all repos is not going to work, imagine what happens when we have PR1.2+1 etc. One suggestion would be to promote all versions simultaneously, but there are obvious drawbacks with that! That would make the most recent repo the best supported and tested repo. Older repos might or might not work. But then again, that is what -devel is now too. So the real issue is that creating a new branch requires a nontrivial amount of work. This is a computerized system; computers excel at automation. Why not spend the one-off time to allow for near-instant creation of a new branch? Once that's done, future releases will just consist of oh, I should create a new repository for this release. Let me run that script again with a new name and then upload the new SDK release to it. Indeed. Have I missed some important consideration? I think the issues aren't technical (although streamlining the repo creation is obviously part of it), but more procedural. I could be wrong. There is also the technical issue that after SSU you would need to change your catalog settings in your device manually for -devel and -testing. Getting that changed in AM is probably not going to happen. Cheers, Andrew -- Andrew Flegg -- mailto:and...@bleb.org | http://www.bleb.org/ Maemo Community Council chair -- Niels Breet maemo.org webmaster ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Bora/OS2007 extras is dead? Re: ssh uploading to gregale/bora/chinook extras broken?
On Wednesday 07 April 2010 15:39:29 Frantisek Dufka wrote: Niels Breet wrote: Bora has been dead for a while now, chinook is also EOL. Bora is dead? Oh really? So why there is http://maemo.org/downloads/OS2007/ with old version I cannot update? When and why was this discussed/decided? It wasn't, as far as I know. Killing chinook was, and I agree that it is probably the right thing to do. But gregale, bora and diablo are important. Graham ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: GSoC project discussion - MeeGo cloud storage support
An initial version of my application can be found here: http://socghop.appspot.com/gsoc/student_proposal/show/google/gsoc2010/sttwister/t127066037516 Cheers, Felix Kerekes (sttwister) ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: PR1.2 SDK for Extras-devel: how to solve?
I would like to throw in my 2 pence as well for what its worth. The idea is to give a choice to the developer to choose which SDK the autobuilder needs to use and to which repo the app needs to go to. Providing an option in the debian control file to build against the user specified SDK since the developer knows what SDK he/she uses. e.g: Xsbc-sdk : PR1.2 Also, we can maintain n and n-1 version of the repository at any time to limit the number of maemo OS trunks. does it look feasible ? - Original Message - From: Andrew Flegg Sent: 04/07/10 03:41 PM To: Bryan Jacobs Subject: Re: PR1.2 SDK for Extras-devel: how to solve? On Wed, Apr 7, 2010 at 15:13, Bryan Jacobs n...@landwarsin.asia wrote: It seems to me that the real problem is actually the difficulty in implementing #4 above. If there were magically separate infrastructure for each incompatible release, there would be no issue - a developer uploads their package to each repository for which it builds (preferably through a list of checkboxes in the web interface), and a user selects one or more package sources that match the preinstalled software on their device. No problems, mate. True; however what about the QA process? The UI at http://maemo.org/packages/ is getting better, but it's also getting more familiar. How do we: a) not confuse ad-hoc testers b) ensure that versions in all repos get tested? One suggestion would be to promote all versions simultaneously, but there are obvious drawbacks with that! So the real issue is that creating a new branch requires a nontrivial amount of work. This is a computerized system; computers excel at automation. Why not spend the one-off time to allow for near-instant creation of a new branch? Once that's done, future releases will just consist of oh, I should create a new repository for this release. Let me run that script again with a new name and then upload the new SDK release to it. Indeed. Have I missed some important consideration? I think the issues aren't technical (although streamlining the repo creation is obviously part of it), but more procedural. I could be wrong. I wonder what the testing squad think (I'll poke VDVsx). Cheers, Andrew -- Andrew Flegg -- mailto:and...@bleb.org | http://www.bleb.org/ Maemo Community Council chair ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: PR1.2 SDK for Extras-devel: how to solve?
2010/4/7 Ram Kurvakat rkma...@gmx.com: The idea is to give a choice to the developer to choose which SDK the autobuilder needs to use and to which repo the app needs to go to. Providing an option in the debian control file to build against the user specified SDK since the developer knows what SDK he/she uses. e.g: Xsbc-sdk : PR1.2 Another Maemo-specific control field? No thanks :) Just create two repositories. It worked fine for Chinook and Diablo, and developers uploaded the same source package to Chinook and Diablo without problems until the Chinook autobuilder was closed down. The situation with pre-PR1.2 and PR1.2 is similar to Chinook and Diablo. We can think of PR1.2 as Maemo 5.1 the same way Diablo has been Maemo 4.1. As for testing/QA: Testers will simply use the repository for which they have got firmware on their devices. Which is why I support the idea of community firmware testing (which would allow both testers and developers to test apps on the real devices with the real firmware). Do you really want people to test apps in the SDK and pretend that they will work the same way on a real device? Thomas ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Re: Promotion
It works now! Thank you! 07.04.10, 15:07, Niels Breet ni...@maemo.org: On Sun, April 4, 2010 20:42, George Kibardin wrote: Hi everybody, It seems that I missed something. Suddenly I cannot promote the latest version of my app from diablo extras-devel to diablo extras. I've read this http://wiki.maemo.org/Uploading_to_Extras, tried this https://garage.maemo.org/promoter/diablo and still no luck. I see my app in extras-devel, but there is nothing like promote button. The promote link is found on the armel version page of your application: http://maemo.org/packages/package_instance/view/diablo_extras-devel_free_armel/feedcircuit/0.7.6-2/ The link doesn't show because you are not using one of the sections listed in http://wiki.maemo.org/Package_Categories P.S. I see that for Fremantle promotion process is more complex, but I still cannot get the idea - what to do to initiate promotion process? Same thing. Go to the armel version of the package in fremantle extras-devel and click on promote. Best, George -- Niels Breet maemo.org webmaster ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: PR1.2 SDK for Extras-devel: how to solve?
On Wednesday 07 April 2010 16:54:28 Niels Breet wrote: On Wed, April 7, 2010 16:41, Andrew Flegg wrote: On Wed, Apr 7, 2010 at 15:13, Bryan Jacobs n...@landwarsin.asia wrote: It seems to me that the real problem is actually the difficulty in implementing #4 above. If there were magically separate infrastructure for each incompatible release, there would be no issue - a developer uploads their package to each repository for which it builds (preferably through a list of checkboxes in the web interface), and a user selects one or more package sources that match the preinstalled software on their device. No problems, mate. True; however what about the QA process? The UI at http://maemo.org/packages/ is getting better, but it's also getting more familiar. How do we: a) not confuse ad-hoc testers b) ensure that versions in all repos get tested? This is a non-trivial issue. Testing against all repos is not going to work, imagine what happens when we have PR1.2+1 etc. I agree. There is little point in having repositories for old versions if nothing can ever get promoted into them because there are very few testers left. Unless they are really intended just to be archives: they work while the new version is being introduced (like where we are at at the moment with PR1.2) but once the new version has been out a few weeks, they just drop into archive mode with no promotions, just an archive of software for the old version. One suggestion would be to promote all versions simultaneously, but there are obvious drawbacks with that! That would make the most recent repo the best supported and tested repo. Older repos might or might not work. But then again, that is what -devel is now too. Actually I would make the process make all versions eligible for promotion simultaneously -- once the latest version is tested the developer can promote the other versions without QA when they wish but they can choose to do some more testing themselves if they wish. In an earlier discussion I had proposed another alternative: have a single repository but multiple autobuilders feeding it. I could submit to either the PR1.1 or PR1.2 autobuilder but the output would go into a single place. This seems more efficient than the build with PR1.1 and if that fails try PR1.2 option but otherwise quite similar. The only problem I have noticed so far with that would come when you introduced a new version which made use of some PR1.2 feature, and hence was built with PR1.2. At that time, the PR1.1 version would no longer be installable (as it has a lower version number and is in the same repository). But for cases like this, where PR1.2 is expected to be fairly quickly adopted once it is eventually released, this would probably work well enough. Graham ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: PR1.2 SDK for Extras-devel: how to solve?
On Wed, 7 Apr 2010 21:27:30 +0100 Graham Cobb g+...@cobb.uk.net wrote: On Wednesday 07 April 2010 16:54:28 Niels Breet wrote: On Wed, April 7, 2010 16:41, Andrew Flegg wrote: On Wed, Apr 7, 2010 at 15:13, Bryan Jacobs n...@landwarsin.asia wrote: It seems to me that the real problem is actually the difficulty in implementing #4 above. If there were magically separate infrastructure for each incompatible release, there would be no issue - a developer uploads their package to each repository for which it builds (preferably through a list of checkboxes in the web interface), and a user selects one or more package sources that match the preinstalled software on their device. No problems, mate. True; however what about the QA process? The UI at http://maemo.org/packages/ is getting better, but it's also getting more familiar. How do we: a) not confuse ad-hoc testers b) ensure that versions in all repos get tested? This is a non-trivial issue. Testing against all repos is not going to work, imagine what happens when we have PR1.2+1 etc. I agree. There is little point in having repositories for old versions if nothing can ever get promoted into them because there are very few testers left. Unless they are really intended just to be archives: they work while the new version is being introduced (like where we are at at the moment with PR1.2) but once the new version has been out a few weeks, they just drop into archive mode with no promotions, just an archive of software for the old version. You want to keep the repositories for exactly that reason. People can keep using their devices with no disruption of service. I, at least, feel that having the latest version of an application is secondary to avoiding a backwards leap in functionality. One suggestion would be to promote all versions simultaneously, but there are obvious drawbacks with that! That would make the most recent repo the best supported and tested repo. Older repos might or might not work. But then again, that is what -devel is now too. Actually I would make the process make all versions eligible for promotion simultaneously -- once the latest version is tested the developer can promote the other versions without QA when they wish but they can choose to do some more testing themselves if they wish. That sounds decent to me. And it would help keep old/extras as up-to-date as new/extras. In an earlier discussion I had proposed another alternative: have a single repository but multiple autobuilders feeding it. I could submit to either the PR1.1 or PR1.2 autobuilder but the output would go into a single place. This seems more efficient than the build with PR1.1 and if that fails try PR1.2 option but otherwise quite similar. The only problem I have noticed so far with that would come when you introduced a new version which made use of some PR1.2 feature, and hence was built with PR1.2. At that time, the PR1.1 version would no longer be installable (as it has a lower version number and is in the same repository). But for cases like this, where PR1.2 is expected to be fairly quickly adopted once it is eventually released, this would probably work well enough. This is the only solution proposed so far which I would reject out of hand. It's what we've got right now, more or less. As a developer, this is fine - I can use PR1.2 packages. As a user, this is a nightmare. My applications disappear forever for reasons that are unclear to me. When I contact a developer, they say wait for the PR1.2 release to come out. When I ask Nokia, they say We do not discuss release dates for future firmware updates. It's better than the current situation in that packages not using 1.2 functionality aren't broken, but it's still not optimal and I feel it should be avoided at all costs. Remember, you also break packages DEPENDING on the ones using 1.2 functionality. The disruption could be very large if, say, Nokia were to update glibc. Graham ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers signature.asc Description: PGP signature ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
