Re: Updating the info for Extras-devel non-free
On Fri, Nov 27, 2009 at 12:15:57PM +0200, Quim Gil wrote: Hi, ext Jeremiah Foster wrote: I am hesitant here, some of the testing process may require source packages, either now or in the future. I am not certain that non-free packages deserve to get all the free quality assurance that the community provides. I think they should be grateful that they are included at all and if they want to go through testing, they need to at least provide a source package. So the questions is in fact non-technical: - Do you want non-free apps showing up in http://maemo.org/packages/repository/qa/fremantle_extras-testing/ ? Absolutely. If non-free apps can go to Extras by bypassing testing, that defeats the whole purpose of the QA process. The average end-user doesn't know or care about the difference between free and non-free, but if something he installed from maemo.org Extras did something bad or didn't work, that's extremely bad for maemo.org and extras as a whole. The other route you can take is to not accept non-free apps into extras at all. - Do you want non-free apps showing up in http://maemo.org/downloads/Maemo5/ ? Why not, if they have gone through the same quality gate as free apps. Testers with a strong opinion about open source might not be interested at all on this, but other users might be indeed interested in becoming betatesters of a non-free app in exchange of checking the lastest versions some days/weeks before regular users get them in Ovi or elsewhere. I perfectly understand this view but I hope this is also looked from the end user's p-o-v. Cheers, Jari ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Never Try to Outsmart the OS
On 5/14/07, Acadia Secure Networks [EMAIL PROTECTED] wrote: Misha, the version numbers shown in the application manager installed apps menu are as follows: *App Version #* X11VNC 0.8-3 Free42 1.4.27-hildon3 Unfortunately the metadata associated with the app that is shown in the application manager does not indicate from where the app was taken. I am pretty sure that I took the Free42 app from the maemo downloads www site. Regarding X11VNC, I am less certain of where I got that from. Perhaps you got it from http://mike.saunby.googlepages.com/x11vncfornokia7702 ? IIRC the desktop file pointed to a shell script that acted like on/off button, alternatively starting and stopping the service. Is it a problem if it's not launched via D-Bus? Br, Jari -- .signature: No such file or directory ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: Application Manager scripting, second try
Hi Mariuses and all, I must say that I like this second try better :D One thing that I wondered is that could the Adding catalogues interaction flow be handled with the same [install] group syntax as the second Installing a package from the network catalogues flow. With the difference that the [install] group would only have a `catalogues' key and no `package' key. But at a second thought it might be a bit confusing if the catalogues are treated differently in these two cases... On Mon, Feb 26, 2007 at 08:42:23PM +0100, Kees Jongenburger wrote: For example, the following file will offer to install the `maemofoo` package from the Foobar catalogue: [install] catalogues = foobar package = maemofoo [foobar] name = Foobar Catalogue name[en_GB] = Foobar Catalogue name[de_DE] = Foobar Katalog uri = http://foobar.com/repository components = main I would try to make the file more self describing so that that you really can create a syntax for it. therefore I would replace the [foobar] with [catalogue]. does the glib ini file parser allow mutiple init entries with the same name? Nope, it does not allow multiple groups with same name. [catalogue] id = foobar name = Foobar Catalogue name[nl_NL] = . Yet another possibility would be to name the catalogue groups like this: [catalogue foobar] name = ... Perhaps it would be more descriptive but I don't have a really strong preference here. Cheers, Jari -- Jari Tenhunen, stardate [-29]7206.34 :wq ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: Enriching the Application Manager scripting experience
On Fri, Feb 23, 2007 at 04:28:37PM +0200, Marius Gedminas wrote: [snip] distautomatic//dist This looks a bit strange (=not intuitive). Compare this to a hyphotetical .ini-based format like the one used by GNOME/Freedesktop .desktop files [install] repo_name = Foobar Catalogue repo_name[de_DE] = Foobar Katalog repo_deb = http://example.com/ mistral main repo_deb_3 = http://example.com/ bora main package = maemofoo I've never really liked the syntax of these ini-style install files. Especially the artificially generated structure (with underscores, e.g. repo_deb_3) looks ugly to me. I know it's too late but why not use simply: [install] package = maemofoo [repository] name = Foobar Catalogue dist = mistral deb = http://example.com/ mistral main I know that the improvement would be merely cosmetic but actually it's not that easy to make it radically better because of the limitations of GKeyFiles and the GLib parser (only one level of hierarchy, group names must be unique). Of course you could have support for multiple repos by allowing magic group names (repository-*) or having something like [install] package = maemoxyzzy repositories = maemofoo maemobar ... [maemofoo] name = Foobar ... [maemobar] ... but that's a bit clumsy, although cleaner. [install] temporary_file_relative_repo_deb = .repository/mistral mistral temporary_file_relative_repo_deb_3 = .repository/bora bora package = frozen-bubble crazy-parking repo_name = Foobar Games repo_name[de_DE] = Foobar Spiele repo_deb = http://foobar.com/ mistral main repo_deb_3 = http://foobar.com/ bora main Looks even uglier. The old GKeyFile format used by IT OS 2007 is still supported. You can embed a X-expression in it as comments like so: # install-instructions # ... # /install-instructions Ouch. Comments that are not really comments. I can't say I like it. +1 [install] repo_deb_3=deb http://foobar.com/ bora main package=maemofoo If the Hildon Application Manager encounters such a file with an embedded X-expression, it will use that and ignore the rest. If there is no X-expression, it will transform the GKeyFile according to the following rules. Summary: I would prefer a straightforward extension of the current .ini-based file format. My suggestion is that if you're going to change it, do it right this time. Backwards-compatibility is nice but if you see that GKeyFiles will cause inevitable problems in the future, drop them now. Do, however, think a bit about the format so that people don't need to have Lisp knowledge to write them. Br, Jari -- Jari Tenhunen, stardate [-29]7187.98 :wq ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] libcst sources?
On Thu, Feb 01, 2007 at 03:43:56PM +0200, [EMAIL PROTECTED] wrote: Hi, Let me create a bit of confusion here ;) There are tutorials here: http://maemo.org/platform/docs/howtos/certman.html http://maemo.org/platform/docs/certman-api.html but those are *not* for the certificate manager (I know, thats not what the web pages say, but trust me). Those are for the libcst, which is a low-level library that interfaces the certificate database, not the certificate manager. Libcst should be available somewhere (at least in Bora's repository). The real certificate manager is close-sourced yet we have the -dev package with headers available in Bora's repository (AFAIK). To cause even more confusion, the source package for libcst seems be ... `certman' (as `apt-get source libcst' would've told you): http://repository.maemo.org/pool/bora/free/source/certman_1.7.9.tar.gz Cheers, Jari Br, --jakub From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of ext Alutoin Mikko Sent: 01 February, 2007 14:33 To: maemo-developers@maemo.org Subject: [maemo-developers] libcst sources? Hello all, Where can I download the sources of libcst, please? Cheers, Mikko ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers -- Jari Tenhunen, stardate [-29]7077.59 :wq ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Unresolved issues (Week 46)
On Wed, Nov 22, 2006 at 01:29:09PM +0100, Panagiotis Issaris wrote: Hi, On Wed, 2006-11-22 at 12:50 +0100, Laurent GUERBY wrote: ... But it produces .ilbc files that I couldn't read anywhere except on my Nokia 770. A converter or direct output in a more readily available format would be great. Would it be possible to put some samples publicly accessible? The .ilbc files contain simply raw iLBC frames (20 ms) one after another. Exactly the same stuff that dspilbcsrc produces and dspilbcsink eats. Yes, it would be best to use some container format but at least I'm not aware of any for iLBC. Regards, Jari T -- Jari Tenhunen, stardate [-29]6721.81 :wq ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Proposal for streamline maemo repositories
On Thu, Sep 14, 2006 at 10:38:21AM +0200, Koen Kooi wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Andrew Flegg schreef: On 9/14/06, Devesh Kothari [EMAIL PROTECTED] wrote: Proposal to streamline maemo repos. PLEASE give your feedback and concerns. If anyone can improve or shoot this down, then it is YOU. Proposal: 1. To change the name of the contrib repository name to extras [snip] Impact to developers/contributors/users of contrib - Currently configured repository in /etc/apt/sources.list would have to be changed [snip] Sorry, I think you're too late. You should have considered these issues in advance, and introducing another please change your settings to users just looks a little unprofessional so soon after the EABI change (which we all agree was worthwhile, but the users don't think they see the benefit). *If* you want to make such a change, make sure you release a new firmware image that has all the changes and have a short changeover period to minimize the annoyance. And if you are going to release a new firmware image, please release an RC first to get rid of the most obvious bugs. I don't see how this would affect the firmware image because contrib/extras repo is not configured there by default. It seems there was a typo in the URLs in Devesh's mail. I guess it should be http://repository.maemo.org/extras/ instead of ...extra/ ?? Anyways, I feel that this slight reorganization is needed and to me it's not that big of a deal. Br, Jari -- Jari Tenhunen, stardate [-29]6376.04 :wq ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
[maemo-developers] Re: [maemo-users] Using osso_iap_cb example
On Mon, Jul 24, 2006 at 11:24:24PM -0700, Brad Burleson wrote: I'm trying to capture the events generated when the 770 goes on and off-line, and I've written a simple test program just to mess around. The callback gets registered, but I never see any output from the callback. I suspect it's something simple. Anyone got any ideas? (I think maemo-developers is a better forum for this) It seems that the callback isn't actually registered (on D-BUS) until you call some osso-ic function that does something on D-BUS. So, after calling osso_iap_connect() you might have a better chance. Of course there's then the side effect that you have requested a connection and the system will try to keep it on indefinitely. If that's a problem (you only want to monitor), you should be able to use the ICD D-BUS API directly and listen for the status_changed signal: http://www.maemo.org/platform/docs/howtos/howto_connectivity_guide.html#DBUSInterfaceICD Cheers, Jari -- Jari Tenhunen, stardate [-29]6121.15 :wq ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Developing for IT2006
On Tue, Jun 27, 2006 at 01:33:17PM +0200, Luca Donaggio wrote: 2006/6/27, Luca Donaggio [EMAIL PROTECTED]: I created a .deb for i386 and installed it in Scratchbox with dpkg -i. Result is that DBUS was looking for com.nokia.grsync service, while in grsync.service service's name is defined as it.opbyte.grsync; I changed my .desktop accordingly: X-Osso-Service=it.opbyte.grsync and it worked! Now I still have to understand why it doesn't come up hildonized! Definitely today is not my day! I solved the not hildonized issue, I missed a CFLAGS=-DMAEMO2 in debian/rules! However, when launching the application from the menu in Scratchbox this is what I see on the terminal: hn-wm.c:264,hn_wm_top_service() Called with 'it.opbyte.grsync' hn-wm.c:302,hn_wm_top_service() ### Failed to read memory limits, using scratchbox ?? hn-wm.c:335,hn_wm_top_service() unable to find service name ' it.opbyte.grsync' in running wins hn-wm.c:336,hn_wm_top_service() Thus launcing via osso_manager_launch() hn-wm.c:1210,hn_wm_dbus_method_call_handler() Checking if service: ' it.opbyte.grsync' is watchable and the application is usable for some seconds ( 1 min.) then it suddenly dies without any error (it doesn't segfaoult, though). I remember something similar used to happen with IT2005 too, and it was related to DBUS not being able to properly register the service. This is what I do in main.c: gtk_init (argc, argv); [...] program = HILDON_PROGRAM(hildon_program_get_instance()); osso_context = osso_initialize(PACKAGE, VERSION, FALSE, NULL); Hi! What exactly is PACKAGE here? If you use other prefix than com.nokia, you need to supply the full service name (in your case it.opbyte.grsync) as the first parameter for osso_initialize(). There have been some attempts to fix the com.nokia issue in OS 2006 edition so things should (mostly) work also with non-com.nokia service names, provided that you use the same full org.domain.foobar name everywhere (desktop, service, osso_initialize() etc). Br, Jari -- Jari Tenhunen, stardate [-29]5981.12 :wq ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Re: Disconnect rfcomm stays between bt_disconnected and rf_disconnected
On Thu, Apr 06, 2006 at 01:59:09PM +0200, koos vriezen wrote: 2006/4/6, Johan Hedberg [EMAIL PROTECTED]: On Thu, Apr 06, 2006, koos vriezen wrote: For the short term, it would be helpfull if someone could point to a way to disable this device, like w/ offline mode or plastic cover, programmaticaly. Using the commandline: hciconfig hci0 down hciconfig hci0 up When having such a state: Running as root /usr/sbin/hciconfig hci0 down return immediately w/o resetting the device 'hciconfig hci0 down; hciconfig hci0 up' failed for me too, i.e. it didn't revive the BT. So that trick isn't excactly the same as putting the cover on or switching to offline mode. Johan, do you have any idea on what is causing the BT jam in these cases? Cheers, Jari -- Jari Tenhunen, stardate [-29]5571.25 :wq ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] osso_initialize()
On Fri, Mar 10, 2006 at 10:35:05AM +0200, Tomi Ollila wrote: Luca Donaggio [EMAIL PROTECTED] writes: Have you checked that the constant PACKAGE_VERSION has exactly the same value (1.0.0) as in the line Version= in your .desktop file? If they're not the same osso_initialize() will fail! oooh nooo!!!1!11!! That must have been my problem. Errr, this doesn't sound right. If I read freedesktop.org's desktop entry spec [1] correctly, the Version key should be the version of the Desktop Entry Specification, *not* the version of the application. And this is also what the tutorial says (Version of the application desktop file). So, I cannot believe that maemo-af-desktop would mis-interpret it as the *application version*. Anyway, maybe the maemo tutorial would benefit from a link to the specification? Regards, Jari [1] http://standards.freedesktop.org/desktop-entry-spec/desktop-entry-spec-latest.html -- Jari Tenhunen, stardate [-29]5436.34 :wq ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] use shell script to start application
On Fri, Jan 20, 2006 at 12:37:03PM +0100, Johannes Eickhold wrote: gpsdrive has to be started via the script usr/bin/gpsdrive.sh. If I specify this file in the .desktop file, gpsdrive can be started in the correct way from the menu and via run-standalone.sh usr/bin/gpsdrive.sh but doesn't show up in the task navigator. If I specify .../usr/bingpsdrive (the binary executable) in the .desktop file, only the application is startet broken (needed parts from the script are not executed) BUT it shows up in the task navigator after that. If I start it via run-standalone.sh everyting is fine (e.g. correct startup AND showing in task navigator). How can I fix this? For me it works when I add the name of the binary (in this case gpsdrive) to the StartupWMClass field of the .desktop file. According to the tutorial, StartupWMClass is needed when binary name is different than D-BUS service name. Based on my experiments it is also needed if there is no X-Osso-Service field in the .desktop file. To my knowledge, StartupWMClass should actually match the WM_CLASS property of the application, which usually is the name of the binary but not always. I recently had a similar problem where the application had a weird WM_CLASS that differed from the binary name. How this thing connects to the shell script issue, I don't know. Br, Jari -- Jari Tenhunen, stardate [-29]5191.33 :wq ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
