Re: Proper location of "Kernel" modules
Another benefit of one meta-package would be that testers will only have to rate one package for you to promote the kernel modules to extras/maemo.org. Martin 2010/1/19, Martin Grimme : > Hi, > > it sounds like that the NTFS and UTF-8 are optional dependencies for > wizardmounter. > I would put them into a non-user category and provide a meta-package > depending on these visible in the user/* category. The meta-package > could be named something like "NTFS support for Wizardmounter and > TrueCrypt". IMHO there's no point in advising it as global NTFS > support for the N900 as other applications cannot make use of it by > default. > > Just my 2¢. > > > Martin > > 2010/1/19, Nathan Anderson : >> >> Over the last week or so, I've uploaded three different Kernel >> Modules; Cifs, NTFS, and NLS_UTF8. I had stuck them in the proper >> user/* >> categories but was questioning if I should (Cifs, should be a prereq of >> Wizard Mounter, so it won't have to be "found" by a end user to install >> it). >> >> >> But the other two are modules that are only rarely asked for (NTFS - >> Ability to access Windows NT File Systems, and NLS_UTF8 is used by file >> drivers for UTF8 support). >> >> Should they be put in a real user/* category to be easily found and >> installed or should they be basically hidden so only "experts" who run >> apt-get can get it? What do you all think? >> >> I also could put NLS_UTF8 as a pre-req of Cifs, but it is only >> required if you want to use UTF8 volume mounting, otherwise it isn't >> needed >> or loaded. >> I also could put NTFS as a pre-req of TrueCrypt, since off the top >> of my head it is the only item currently that can need access to NTFS >> volumes. >> >> Nathan >> >> ___ >> 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: Proper location of "Kernel" modules
Hi, it sounds like that the NTFS and UTF-8 are optional dependencies for wizardmounter. I would put them into a non-user category and provide a meta-package depending on these visible in the user/* category. The meta-package could be named something like "NTFS support for Wizardmounter and TrueCrypt". IMHO there's no point in advising it as global NTFS support for the N900 as other applications cannot make use of it by default. Just my 2¢. Martin 2010/1/19, Nathan Anderson : > > Over the last week or so, I've uploaded three different Kernel > Modules; Cifs, NTFS, and NLS_UTF8. I had stuck them in the proper user/* > categories but was questioning if I should (Cifs, should be a prereq of > Wizard Mounter, so it won't have to be "found" by a end user to install it). > > > But the other two are modules that are only rarely asked for (NTFS - > Ability to access Windows NT File Systems, and NLS_UTF8 is used by file > drivers for UTF8 support). > > Should they be put in a real user/* category to be easily found and > installed or should they be basically hidden so only "experts" who run > apt-get can get it? What do you all think? > > I also could put NLS_UTF8 as a pre-req of Cifs, but it is only > required if you want to use UTF8 volume mounting, otherwise it isn't needed > or loaded. > I also could put NTFS as a pre-req of TrueCrypt, since off the top > of my head it is the only item currently that can need access to NTFS > volumes. > > Nathan > > ___ > 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
Proper location of "Kernel" modules
Over the last week or so, I've uploaded three different Kernel Modules; Cifs, NTFS, and NLS_UTF8. I had stuck them in the proper user/* categories but was questioning if I should (Cifs, should be a prereq of Wizard Mounter, so it won't have to be "found" by a end user to install it). But the other two are modules that are only rarely asked for (NTFS - Ability to access Windows NT File Systems, and NLS_UTF8 is used by file drivers for UTF8 support). Should they be put in a real user/* category to be easily found and installed or should they be basically hidden so only "experts" who run apt-get can get it? What do you all think? I also could put NLS_UTF8 as a pre-req of Cifs, but it is only required if you want to use UTF8 volume mounting, otherwise it isn't needed or loaded. I also could put NTFS as a pre-req of TrueCrypt, since off the top of my head it is the only item currently that can need access to NTFS volumes. Nathan ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Finger-Friendly Entry Completion/ComboboxEntry
I have to give a bump to this. Does anyone know the secret behind the browser URL bar? Is the code even posted somewhere (Not sure, is that part of the browser open source?). It's perfect for what I need... Thanks! On Tue, Jan 5, 2010 at 5:15 PM, Brent Chiodo wrote: > I'm trying to add search history support to a hildon.Entry but am having a > bit of trouble. In short, I want to have the user type into the entry and if > what they are typing is present in their history, have a list appear showing > what their current entry matches in their history. If the user taps on an > item in the list, it should set the entry to that value (basically a > gtk.ComboboxEntry that is populated based on what the user has currently > entered into the entry). > > Looking through the PyGTK widgets, it seemed that a gtk.EntryCompletion was > exactly what I was looking for. I tried creating a hildon.Entry and using > the .set_completion() method to set the entry but that doesn't appear to > work very well. The main problems are: > > 1) The generated list doesn't seem to popup reliably (sometimes it will, > sometimes it won't) > 2) The rows in the popup aren't clickable -- you can select them via the > up/down then return buttons on the keyboard, but are not directly clickable. > 3) The rows aren't finger-friendly at all (not that you can click them > anyway...) > > So, how would I go about creating the above? It is doable, because I pretty > much need to know how to make something like the builtin browser uses in > it's toolbar (actually, the browser search bar is exactly what I want to > implement, I just don't know what widget(s) are required to do it). > > Thanks for reading! > > -- > Best Regards, > > Brent Chiodo > -- Best Regards, Brent Chiodo ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: running application automatically at system startup
.2010/1/18 Kimmo Hämäläinen : > On Sun, 2010-01-17 at 08:47 +0100, ext ibrahim wrote: >> cheers; >> >> I wonder how to make my application run automatically at system startup. >> I've read about many ways to do so ( different ways for different linux >> distributions) but I'm not sure which way is the right one. I don't want >> to mess things up by using an inappropriate way. >> So, is there any way to make my (console)app run automatically when the >> phone starts?? > > You can do that by installing a startup script under > the /etc/X11/Xsession.post directory (see scripts there for examples). A lot of these types of questions are gems, especially for people not familiar with the platform. We might be able to tell people coming from the Windows world "its just like (desktop) linux" until we have to add "except for where its not". Is anyone collecting these "How do I..." questions and putting them on the wiki? Ed Page ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
LCA: How to destroy your community
Here is a good article in LWN about a presentation by Josh Berkus. How many of these points apply to Nokia? I'm afraid way too many. http://lwn.net/SubscriberLink/370157/2a06baf10df8e58a/ Some gems: 1) "It's also important to set up an official web site which is down as often as it's up. It's not enough to have no web site at all; in such situations, the community has an irritating habit of creating sites of its own. But a flaky site can forestall the creation of those sites, ensuring that information is hard to find. " 3) "There should be no useful information about the code, build methods, the patch submission process, the release process, or anything else. Then, when people ask for help, tell them to RTFM." 4) "Project decisions should be made in closed-door meetings." 5) "Employ large amounts of legalese." 7) "Keep the decision-making powers unclear" 8) "Screw around with licensing. Community members tend to care a lot about licenses, so changing the licensing can be a good way to make them go elsewhere. Even better is to talk a lot about license changes without actually changing anything;" 10) "Silence. Don't answer queries, don't say anything. A company which masters this technique may not need any of the others; it is the most effective community destroyer of them all. " -Jeff ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Follow up from QA meeting on IRC
On Thu, Nov 12, 2009 at 03:06, Jeremiah Foster wrote: > > This email is a set of action points that were brought up during > the QA meeting on IRC which Valerio suggested. I felt the meeting was > quite productive, we have some more things to discuss and we have some > 'actionable items' as it were. To join up the community, there's now a thread on tmo about this: http://talk.maemo.org/showthread.php?t=41179 Sorry to resurrect an old thread. Cheers, Andrew -- Andrew Flegg -- mailto:and...@bleb.org | http://www.bleb.org/ ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Backwards compatibility broken PR1.1 SDK
Graham Cobb on 01/18/2010 04:42 PM wrote: I do think there may be an option 1.5: Turning Linux into Windows shouldn't be a project goal of Maemo. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Backwards compatibility broken PR1.1 SDK
On Monday 18 January 2010 21:08:33 Niels Breet wrote:
> I've been discussing this issue with some people before as hypothetical
> case, but now it seems that we run into it: Compiling an application
> against the PR1.1 SDK creates packages which can not be installed on
> earlier firmware releases.
The problem isn't really new: we have had it with all Maemo releases in the
past. For versions 1-3 it was something the developer had to handle
themselves, for version 4 it impinged on the autobuilder and is one reason we
insisted on a new name ("Diablo") for the release after Chinook, so it was
easy to build different versions (although, in fact, binaries built on
Chinook normally run perfectly well on Diablo).
For GPE I still build against Maemo 2, Maemo 3 and Maemo 4 and, in each case,
I use the SDK from the .0 release to build binaries which will run on any .*
release.
> The autobuilder uses the repository.maemo.org repository, so it
> automatically uses newer packages when they are available.
A particular autobuilder queue name should always use a fixed SDK release,
with contents which never change. That is what the "queue name" really
means, in my opinion.
> 1: Only compile against the original SDK.
>This prevents new features from ever be available to developers,
>but should work until there is real API/ABI breakage in a new
>firmware.
This should be the answer for "small" releases (like we have here). Just in
case anyone is confused, in most cases building against an old library does
**not** mean that running with a new version is prevented: so bug fixes in
newer releases of libraries work fine. The only thing this option prevents
is using a new **feature** (in particular, a new function call) in the new
library which was not in the old library.
> 2: Use version specific repositories
>This needs Application Manager support as we need to fetch from a
>separate repository every time. Also requires us to build against
>every sdk version known to man.
For "larger" releases (in particular, ones with new features in libraries
which developers may want to use), the release should be given a new name and
a new repository and a new autobuilder queue should be created. If backwards
compatability is expected, it would be feasible to populate the new
repositories (extras, extra-testing and extras-devel) by just copying the
packages from the previous release but new versions of the packages could be
built to use the updated libraries if they wished.
> 3: Depend on >= mp-fremantle-generic-pr | maemo-version
>We would need a hack in the autobuilder to add depends to pr and
>maemo version. This way a user needs to upgrade to at least the
>required firmware image. I think this will make it easier for an
>end-user to understand what is happening.
I don't like this. We should not have an application forcing a maemo software
upgrade. Different people will have very different tolerance to doing
software upgrades (most of us developers and power users are keen to try new
releases, but most ordinary users will resists as long as possible).
It certainly can't be the case that just building after the new release has
been shipped means your users have to upgrade. If I have thousands of users,
I need to be able to ship new releases to them without forcing an upgrade.
Don't forget that upgrades are not even available to all users at the same
time (today we have the Vodafone problem, which will only get worse in future
with different operator versions and different country versions available at
different times).
I do think there may be an option 1.5: create multiple autobuilder queues
which feed the same repository but build against different SDK releases. For
example, a "fremantle" queue which builds against the base release (for
ever), and a "fremantle-pr1.1" queue which builds against the new SDK (for
ever), but both populate the same repository (extras-devel fremantle). That
would allow the applciation developer to decide which users they are willing
to support. If the application supports all fremantle users it submits to
the fremantle queue. But if it uses a new feature (or even an important bug
fix) from the pr1.1 release the maintainer could submit it to the
fremantle-pr1.1 queue.
If we did this, I wouldn't object to automatically adding a dependency on the
device software version, as long as it is worked out from which queue you
submit to.
Graham
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Backwards compatibility broken PR1.1 SDK
Niels Breet on 01/18/2010 03:08 PM wrote: Can we, like with the opt problem, come to a solution with community power[tm]? An SONAME change during a distribution version's lifetime is quite nasty. Most, if not all, distributions frown upon such a thing. I'm surprised that this was done, given the locked down state of some Brainstorm ideas. I realize that sometimes it is unavoidable, but a e-mail to the maemo-developers list would have been helpful. More communication the better. :) The proper way to handle it would be option 3. The Maemo build system should be able to perform "Broken Dependency" checks daily (or upon your request) to insure a stateful system. An e-mail[1] to maemo-developers (or the appropriate list) should be sent that lists the broken packages. If there are packages that were built against an older SONAME, a Maemo or Nokia member should rebuild those packages and file bugs with the project if a rebuild fails. The package release number should be incremented and a changelog entry that defines "Rebuild for $LIBRARY_NAME change" should be added. [1] http://lists.fedoraproject.org/pipermail/test/2010-January/087997.html ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Backwards compatibility broken PR1.1 SDK
Hi, I've been discussing this issue with some people before as hypothetical case, but now it seems that we run into it: Compiling an application against the PR1.1 SDK creates packages which can not be installed on earlier firmware releases. In this case we have have a libosso version which is higher than the one in previous releases. As this dependency gets automatically added when compiling in the PR1.1 SDK this poses a problem. The autobuilder uses the repository.maemo.org repository, so it automatically uses newer packages when they are available. For Extras this means that install of an application which is compiled against the new SDK fails without any description we can expect an end-user to understand. This is something which should be prevented. How can we work around this problem: 1: Only compile against the original SDK. This prevents new features from ever be available to developers, but should work until there is real API/ABI breakage in a new firmware. 2: Use version specific repositories This needs Application Manager support as we need to fetch from a separate repository every time. Also requires us to build against every sdk version known to man. 3: Depend on >= mp-fremantle-generic-pr | maemo-version We would need a hack in the autobuilder to add depends to pr and maemo version. This way a user needs to upgrade to at least the required firmware image. I think this will make it easier for an end-user to understand what is happening. We could, with help of the AM team, even detect in the AM that a firmware upgrade is required and give a the end user a nice warning/description. Currently the AM doesn't have any means to detect which firmware version a package requires. Option 3 solve that issue at the same time. If you have an alternative solution on how to go about fixing this issue, then please let me know. Can we, like with the opt problem, come to a solution with community power[tm]? -- Niels Breet maemo.org webmaster ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Missing dependencies in extras devel
Me too with FriendStatus :( And I uploaded it today afternoon. http://maemo.org/packages/package_instance/view/fremantle_extras-devel_free_armel/friendstatus/0.7/ On Mon, Jan 18, 2010 at 11:59 AM, Thomas Troy wrote: > I have the same issue with the same dependencies with my app. > http://maemo.org/packages/package_instance/view/fremantle_extras-devel_free_armel/webtexter/0.7.4 > > I uploaded on Saturday morning and I think the error wasn't appearing then. > You seemed to upload around the same time. > > Also the issue only shows up on the armel version. The i386 shows > correctly. > > > > > > > On Mon, Jan 18, 2010 at 7:27 AM, Mikko Mehtonen > wrote: > >> Hi, >> >> I sent a new version of call forwarding applet to extras devel builder, >> and now it has some missing dependencies even though these hasn't been any >> changes since previous version: >> >> >> http://maemo.org/packages/package_instance/view/fremantle_extras-devel_free_armel/callforwarding/0.4/ >> >> Does extras devel have old package versions or something? >> >> Mikko >> ___ >> 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 > > -- Best Regards Tan Miaoqing Software engineer, Maemo Devices Nokia Devices R&D http://www.linkedin.com/in/tanmiaoqing http://twitter.com/rabbitrun84 ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: repository.maemo.org down
Ville M. Vainio wrote: > On Mon, Jan 18, 2010 at 10:12 AM, wrote: > apt-get update seems to work now, but there still seems to be problem > with bz2 (trying to install toolchain with maemo-sdk, i.e. Maemo SDK+ > & sb2): > just replace all repository.maemo.org with stage.maemo.org in .maemo-sdk/index.toolchains best regards, -- Thomas Tanner -- email: tan...@gmx.de GnuPG: 1024/5924D4DD ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: SDK rootstraps updated
On Monday 18 January 2010 15:23:09 Niels Breet wrote: > The autobuilder has not been updated yet, this is on my todo list still. Niels, The autobuilder environment must not change -- it needs to remain as the original Fremantle release SDK. Otherwise packages built using the autobuilder will not run on devices which have not been upgraded to the latest software. > I hope to do that this evening. (UTC+1) Please don't! Graham ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Open new browser window using Qt
Thank you, it worked! So, why is OSSO_BROWSER_REQ_INTERFACE there? Is there any list of what interfaces implements which calls? It seems a bit unclear to me... El lun, 18-01-2010 a las 09:19 +0200, daniel wilms escribió: > Hi, > > > > QDBusInterface browserProxy (OSSO_BROWSER_SERVICE, > > OSSO_BROWSER_REQ_PATH, OSSO_BROWSER_REQ_INTERFACE, > > QDBusConnection::systemBus()); > > browserProxy.call (OSSO_BROWSER_OPEN_NEW_WINDOW_REQ, url, true); > this one should work: > > QDBusInterface browserd (OSSO_BROWSER_SERVICE, > OSSO_BROWSER_REQ_PATH, > OSSO_BROWSER_SERVICE); > browserd.call (OSSO_BROWSER_OPEN_NEW_WINDOW_REQ,"maemo.org"); > > > Daniel ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: SDK rootstraps updated
On Monday 18 January 2010 12:23:09 Niels Breet wrote: > The updated rootstraps are probably there PR1.1 ones? Wasn't the sdk > updated at the same time as the PR1.1 firmware? Who puts maemo-sdk-rootstrap_5.0_armel.tgz on the server? They should be the one to ask. The SDK has been updated, the peculiar thing is that the timestamps didn't change. Also, the MD5SUM file is different, but doesn't match the original 5.0 final release nor the latest one (as of today). So it seems there were at least 3 versions. One approach would be to use version numbering and changelogs! Who does this? -Jeff ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: SDK rootstraps updated
> 2010/1/18 Graham Cobb : > >> On Monday 18 January 2010 14:08:07 Jeff Moe wrote: >> >>> Take note, since the service restoration, the Maemo 5 SDK rootstraps >>> have been (silently?) updated with no changes to timestamps: >> >> Thanks Jeff for noticing this. >> >> >> Niels or Ed, do you have any idea what has happened here? >> >> > Unfortunately I'm not aware of any changes. > And autobuilder still uses old SDK rootstraps unless Niels or other > admins did something. The updated rootstraps are probably there PR1.1 ones? Wasn't the sdk updated at the same time as the PR1.1 firmware? The autobuilder has not been updated yet, this is on my todo list still. I hope to do that this evening. (UTC+1) Ed: Can you see if you the devkit for pr1.1 needs to be changed for the /opt bug? I haven't had time to follow that at all lately and I don't want to mess things up :) > > -- > BR, > Ed -- Niels Breet maemo.org webmaster ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: SDK rootstraps updated
Dnia poniedziałek, 18 stycznia 2010 o 16:03:53 Jeff Moe napisał(a): > On Monday 18 January 2010 11:51:00 Marcin Juszkiewicz wrote: > > They could also just repack it and put there. Please compare both and > > share result. > > 736k diff. Also, the gzip appeared to be corrupt in the original version. > Perhaps they should do version numbering of the SDKs as well, such as: > maemo-sdk-rootstrap_5.0.3_armel.tgz And SDK versions should be more linked to firmware drops so s/5.0.3/5.0.2009.51-1/ or something like this. Regards, -- JID: h...@jabber.org Website: http://marcin.juszkiewicz.com.pl/ LinkedIn: http://www.linkedin.com/in/marcinjuszkiewicz ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: SDK rootstraps updated
2010/1/18 Graham Cobb : > On Monday 18 January 2010 14:08:07 Jeff Moe wrote: >> Take note, since the service restoration, the Maemo 5 SDK rootstraps have >> been (silently?) updated with no changes to timestamps: > > Thanks Jeff for noticing this. > > Niels or Ed, do you have any idea what has happened here? > Unfortunately I'm not aware of any changes. And autobuilder still uses old SDK rootstraps unless Niels or other admins did something. -- BR, Ed ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: SDK rootstraps updated
On Monday 18 January 2010 11:51:00 Marcin Juszkiewicz wrote: > Dnia poniedziałek, 18 stycznia 2010 o 15:08:07 Jeff Moe napisał(a): > > Take note, since the service restoration, the Maemo 5 SDK rootstraps have > > been (silently?) updated with no changes to timestamps: > > > To clarify, they have changed the contents of > > maemo-sdk-rootstrap_5.0_armel.tgz (and i386), updated the MD5SUM, but the > > files have the same timestamp. I assume you'll want the latest one that is > > in the repo if you tried the previous one (which may have been broken). > > They could also just repack it and put there. Please compare both and share > result. 736k diff. Also, the gzip appeared to be corrupt in the original version. But it wasn't just a corrupt gzip, as things clearly changed, such as: diff -ruN armel-old/etc/maemo_version armel-new/etc/maemo_version --- armel-old/etc/maemo_version 2009-12-02 06:02:44.0 -0700 +++ armel-new/etc/maemo_version 2010-01-13 01:47:42.0 -0700 @@ -1 +1 @@ -5.0update2 Fremantle +5.0update3 Fremantle Perhaps they should do version numbering of the SDKs as well, such as: maemo-sdk-rootstrap_5.0.3_armel.tgz -Jeff ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: repository.maemo.org down
On Mon, Jan 18, 2010 at 10:12 AM, wrote: > Ok, > > Thanks for the info. > > The problem you are seeing is called last mile acceleration and should not be > there. It tries to be helpful and opens the zip on the fly for you, which is > not what apt-get wants. > > Mailing support to turn it off. apt-get update seems to work now, but there still seems to be problem with bz2 (trying to install toolchain with maemo-sdk, i.e. Maemo SDK+ & sb2): Select (0..3)? 3 Using direct Internet access... --2010-01-18 16:55:20-- http://repository.maemo.org/sb2/toolchain/cs2007q3-glibc2.5-i486-i486-pc-linux-gnu-i686-pc-linux-gnu-3.tar.bz2 Resolving repository.maemo.org... 193.184.164.139, 193.184.164.146 Connecting to repository.maemo.org|193.184.164.139|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 7955 (7.8K) [text/html] Saving to: `/tmp/.maemo-download-13287/cs2007q3-glibc2.5-i486-i486-pc-linux-gnu-i686-pc-linux-gnu-3.tar.bz2' 100%[=>] 7,955 --.-K/s in 0.07s 2010-01-18 16:55:21 (115 KB/s) - `/tmp/.maemo-download-13287/cs2007q3-glibc2.5-i486-i486-pc-linux-gnu-i686-pc-linux-gnu-3.tar.bz2' saved [7955/7955] Uncompressing and extracting '/tmp/.maemo-download-13287/cs2007q3-glibc2.5-i486-i486-pc-linux-gnu-i686-pc-linux-gnu-3.tar.bz2'... bunzip2: /tmp/.maemo-download-13287/cs2007q3-glibc2.5-i486-i486-pc-linux-gnu-i686-pc-linux-gnu-3.tar.bz2 is not a bzip2 file. Package '/tmp/.maemo-download-13287/cs2007q3-glibc2.5-i486-i486-pc-linux-gnu-i686-pc-linux-gnu-3.tar.bz2' uncompression failed. Please, try again. -- Ville M. Vainio http://tinyurl.com/vainio ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: SDK rootstraps updated
Dnia poniedziałek, 18 stycznia 2010 o 15:08:07 Jeff Moe napisał(a): > Take note, since the service restoration, the Maemo 5 SDK rootstraps have > been (silently?) updated with no changes to timestamps: > To clarify, they have changed the contents of > maemo-sdk-rootstrap_5.0_armel.tgz (and i386), updated the MD5SUM, but the > files have the same timestamp. I assume you'll want the latest one that is > in the repo if you tried the previous one (which may have been broken). They could also just repack it and put there. Please compare both and share result. Regards, -- JID: h...@jabber.org Website: http://marcin.juszkiewicz.com.pl/ LinkedIn: http://www.linkedin.com/in/marcinjuszkiewicz ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: SDK rootstraps updated
On Monday 18 January 2010 14:08:07 Jeff Moe wrote: > Take note, since the service restoration, the Maemo 5 SDK rootstraps have > been (silently?) updated with no changes to timestamps: Thanks Jeff for noticing this. Niels or Ed, do you have any idea what has happened here? As a developer, it is important that I have access to all the released SDK and rootstrap versions explicitly. There are two main reasons: 1) Software built for release to users must be built against the SDK for the earliest release to be supported, otherwise library dependencies will prevent installation on earlier releases. That means, for example, that software intended to be run on Fremantle should normally be built against the SDK which was released with the official shipping of the device, even if a newer SDK is available. On the other hand, the developer will often find it convenient to keep their main development scratchbox target up to date in order to get bug-fixes for the various tools. 2) When trying to fix a problem reported by users it may be important to be able to build against a particular SDK release (either to reproduce problems or test possible solutions or workrounds). To be fair, the second reason is unusual (I only find myself creating a test scratchbox target with a specific SDK release about once a year) but if we do not make sure we always archive (and change the name of) SDK and rootstrap releases it becomes impossible. Graham ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
SDK rootstraps updated
Take note, since the service restoration, the Maemo 5 SDK rootstraps have been (silently?) updated with no changes to timestamps: The current rootstrap: je...@espejo:/var/www$ ls -l repository.maemo.org/stable/fremantle/armel/MD5SUM -rw-r--r-- 1 jebba jebba 137 2010-01-13 03:48 repository.maemo.org/stable/fremantle/armel/MD5SUM je...@espejo:/var/www$ cat repository.maemo.org/stable/fremantle/armel/MD5SUM 290e68bfd874e3d6049e0016624b13e5 maemo-sdk-rootstrap_5.0_armel.full 1524f4b4e4e9cd6693611e2584772eb8 maemo-sdk-rootstrap_5.0_armel.tgz The previous rootstrap (note identical timestamp): je...@espejo:/var/www$ ls -l /home/jebba/armel-sdk/MD5SUM -rw-r--r-- 1 jebba jebba 137 2010-01-13 03:48 /home/jebba/armel-sdk/MD5SUM je...@espejo:/var/www$ cat /home/jebba/armel-sdk/MD5SUM 0b071fde66418d634fad51908eb25bd4 maemo-sdk-rootstrap_5.0_armel.full 1cccaa63e7ae4f8cb38a4ca4eeb94d02 maemo-sdk-rootstrap_5.0_armel.tgz To clarify, they have changed the contents of maemo-sdk-rootstrap_5.0_armel.tgz (and i386), updated the MD5SUM, but the files have the same timestamp. I assume you'll want the latest one that is in the repo if you tried the previous one (which may have been broken). -Jeff ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: D-Bus signals in python
On Sat, Jan 16, 2010 at 5:34 AM, Matan Ziv-Av wrote: > can someone please translate this to python for me: > > dbus-send --type=signal --session /com/nokia/hildon_desktop > com.nokia.hildon_desktop.set_state int32:128 > > I found how to call methods, but sending signals does not appear to work. Take a look at this: http://cgit.freedesktop.org/dbus/dbus-python/tree/examples/example-signal-emitter.py Hope that helps, -- Anderson Lizardo OpenBossa Labs - INdT Manaus - Brazil ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: O2 Germany - Homezone?
Hi, I don't think so, but this could be handled by a desktop widget if anybody with O2 Germany contract volunteers to write it. Martin 2010/1/18, Christopher Intemann : > Hi, > > does the Nokia N900 display the homezone-symbol with O2 Germany simcards? > Thanks, > > Chris > ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
ANN: hop-2.0.0 for Freemantle and Chinook
Hi there, We have completed a first version of the Maemo port of Hop. It is available for both Freemantle and Chinook (check http://hop.inria.fr for details). Hop is a Web SDK that let you write interactive Web applications. For now, we are releasing the SDK and just a couple of Web applications that mostly serve as examples. Theses applications are not very fancy but still you might enjoy our "hopclock" demo that uses the orientation of the device when executed by Fennec on the N900. We are working on implementing multimedia applications with Hop on the N900/N8x0, in particular, applications using the builtin cameras. We hope to release these applications soon. -- Manuel Serrano -|-|-|-|-|-|-|-|-|-|-|-|- HOP is a software development kit designed for the Web 2.0. It works hand by hand with the browsers in order to enhance the capabilities of the latters. It is designed for programming interactive web applications such as web agendas, web galleries, music players, etc. It is compatible with the major modern Web browsers (e.g., Firefox, Safari, Chrome, Opera, and IE 8). HOP features: * a versatile Web server supporting HTTP/1.0 and HTTP/1.1, * an optimizing native code compiler for server code, * an on-the-fly Javascript compiler for client code, * an extensive set of widgets for programming fancy and portable Web GUIs, * a native multimedia support for enabling ubiquitous Web multimedia applications. * fast WebDAV level 1 support, * an extensive set of libraries for the mail, calendars, databases, Web technologies, ... HOP 2.0.0 (14 January 2009) is available at: http://hop.inria.fr The release 2.0.0 is a major release. Its highlights are: * new version of the client-side (JavaScript) compiler that improves performance and enhances debugging facilities, * new language features (e.g., client and server module blending), * new GUI elements (e.g., AUDIO, VIDEO, COLOCHOOSER, ...), * new weblets, * new runtime system (e.g., improved server side pushes, better support of keep-alive for server and proxy connections, ...). The Hop native port of the Web server is known to work efficiently on: * All Linux platforms (x86, PowerPC, ARM Maemo, ...), * MacOS X 10.5, * FreeBSD. For other platforms Hop can be executed using the pre-compiled JVM version. Announce of previous Hop release (1.11.0): - The release 1.11.0 is a major release. Its highlights are: * new client-side (JavaScript) compiler, * new server implementation (performances significantly improved), * new widgets, * new weblets, * language improvements. Announce of previous Hop release (1.10.0): - The release 1.10.0 is a major release. * Many new linguistics extensions. * Many new APIs. * Many new Widgets. * New weblets (such as hzbuilder a wizard for building new weblets). * New faster client-side compiler. * New faster Web broker. Announce of previous Hop release (1.9.3): - The release 1.9.3 is a minor bugs fix release. Announce of previous Hop release (1.9.2): - The release 1.9.2 is a minor release. It significantly improves the overall performance of the Web browser, by using an enhanced implementation of keep-alive HTTP connections. This version also fixes errors still remaining in the version 1.9.1. Announce of previous Hop release (1.9.1): - The release 1.9.1 is a minor release. It fixes glitches of the version 1.9.0 and delivers a new pre-installed weblet, HzBuilder, that imlements a Web assistant for building simple Hop programs. Announce of previous Hop release (1.9.0): - The release 1.9.0 is a major release. It highlights are: * new linguistic forms (e.g., "comet" server events). * new APIs (e.g., multimedia, cryptography, ...). * new implementations (e.g., new fast Web server scheduling, new support for keep-alive connections, new compilation techniques, ...). Announce of previous Hop release (1.8.6): - The release 1.8.6 is a minor release that fixes minor installation bugs. * Minor bug fixes. Announce of previous Hop release (1.8.5): - The release 1.8.5 is a minor release that fixes minor installation bugs. * It mostly contains fixes that enable packaging Hop is standard Linux distributions. Announce of previous Hop release (1.8.4): - The release 1.8.4 is a minor release that fixes two important problems: 1- Hz timeout was expressed in micro-seconds instead of milli-seconds. Hence, synchronizations and installations where freque
Re: Programmatically showing the desktop in Fremantle
On Mon, 2010-01-18 at 12:10 +0100, Hamalainen Kimmo (Nokia-D/Helsinki) wrote: > On Thu, 2010-01-14 at 23:56 +0100, ext Matan Ziv-Av wrote: > > On Thu, 14 Jan 2010, obb770 wrote: > ... > > There is no way equivalent to exit_app_view, but in a modified > > hildon-desktop I am working on, I add a similar dbus signal for > > selecting any of the desktop modes. See here for details: > > > > http://talk.maemo.org/showthread.php?t=38314 > > > > I'll use this thread for a question regarding hildon-desktop. Where is > > hildon-desktop developed? In other words If I want a patch to be > > included in hildon-desktop, whom should I contact? > > If more and more applications will start controlling the desktop state, > it could lead to unpredictable behaviour and/or chaos, so I'm not very > fond of that. The desktop UI and its transitions works as they were > specified by UI and interaction experts. > > If you want the switcher to ignore your application, please try using > _NET_WM_STATE_SKIP_PAGER. See Sorry, I meant _NET_WM_STATE_SKIP_TASKBAR... > http://standards.freedesktop.org/wm-spec/wm-spec-latest.html#id2552903 > for more information. > > -Kimmo > > > ___ > 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: Programmatically showing the desktop in Fremantle
On Thu, 2010-01-14 at 23:56 +0100, ext Matan Ziv-Av wrote: > On Thu, 14 Jan 2010, obb770 wrote: ... > There is no way equivalent to exit_app_view, but in a modified > hildon-desktop I am working on, I add a similar dbus signal for > selecting any of the desktop modes. See here for details: > > http://talk.maemo.org/showthread.php?t=38314 > > I'll use this thread for a question regarding hildon-desktop. Where is > hildon-desktop developed? In other words If I want a patch to be > included in hildon-desktop, whom should I contact? If more and more applications will start controlling the desktop state, it could lead to unpredictable behaviour and/or chaos, so I'm not very fond of that. The desktop UI and its transitions works as they were specified by UI and interaction experts. If you want the switcher to ignore your application, please try using _NET_WM_STATE_SKIP_PAGER. See http://standards.freedesktop.org/wm-spec/wm-spec-latest.html#id2552903 for more information. -Kimmo ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: running application automatically at system startup
On Sun, 2010-01-17 at 08:47 +0100, ext ibrahim wrote: > cheers; > > I wonder how to make my application run automatically at system startup. > I've read about many ways to do so ( different ways for different linux > distributions) but I'm not sure which way is the right one. I don't want > to mess things up by using an inappropriate way. > So, is there any way to make my (console)app run automatically when the > phone starts?? You can do that by installing a startup script under the /etc/X11/Xsession.post directory (see scripts there for examples). -Kimmo > > thanks in advance > > ___ > 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
O2 Germany - Homezone?
Hi, does the Nokia N900 display the homezone-symbol with O2 Germany simcards? Thanks, Chris ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Missing dependencies in extras devel
I have the same issue with the same dependencies with my app. http://maemo.org/packages/package_instance/view/fremantle_extras-devel_free_armel/webtexter/0.7.4 I uploaded on Saturday morning and I think the error wasn't appearing then. You seemed to upload around the same time. Also the issue only shows up on the armel version. The i386 shows correctly. On Mon, Jan 18, 2010 at 7:27 AM, Mikko Mehtonen wrote: > Hi, > > I sent a new version of call forwarding applet to extras devel builder, and > now it has some missing dependencies even though these hasn't been any > changes since previous version: > > > http://maemo.org/packages/package_instance/view/fremantle_extras-devel_free_armel/callforwarding/0.4/ > > Does extras devel have old package versions or something? > > Mikko > ___ > 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: Autobuilder/SDK dpkg too old to support triggers
> > Simple 'apt-get update/upgrade' will give dpkg 1.14.25 in any > > Fremantle SDK. > > Yeah, but the version that matters is the one in the debian-etch devkit, > not the one in the rootstrap. Run dpkg --version, and you will be > surprised... :-) OMG... I did not know that sbox do so much damage... > > Never mind how badly nokia Maemo team broke Debian which was used as base > > long > > time ago methods from it should work. > > Well, thank god we didn't break Debian. :-) But, yeah, Maemo is in a > very bad shape, distribution wise. I wanted to wrote that base system in Maemo5 is just too broken. For Fremantle it is not possible to fix it, but maybe for Harmattan nokia can upgrade base system to at least Lenny + some upgrades requested by developers. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: D-Bus signals in python
On Sat, 16 Jan 2010, Patrick Beck wrote: what does this command? I haven't seen any reaction. I have search for a documention too, but i have not found any, which describe your path. It is only in my version of hildon-desktop, and opens the launcher (application menu). An similar command in the standard hildon-desktop is: dbus-send --type=signal --session /com/nokia/hildon_desktop com.nokia.hildon_desktop.exit_app_view I have found here a small site with a few examples => http://wiki.maemo.org/Documentation/Maemo_5_Developer_Guide/DBus/DBus_in_Freemantle The examples there cover calling methods and listening to signals. I want to send a signal. -- Matan. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
RE: repository.maemo.org down
Ok, Thanks for the info. The problem you are seeing is called last mile acceleration and should not be there. It tries to be helpful and opens the zip on the fly for you, which is not what apt-get wants. Mailing support to turn it off. Tero > -Original Message- > From: ext Ville M. Vainio [mailto:vivai...@gmail.com] > Sent: 18 January, 2010 10:08 > To: Kojo Tero (Nokia-D/Helsinki) > Cc: maemo-developers@maemo.org > Subject: Re: repository.maemo.org down > > On Mon, Jan 18, 2010 at 9:49 AM, wrote: > > >> Am I the only one that's seeing / being bothered by r.m.o being > down? > >> ;-) > > > > No you are not the only one. > > It coming back up now. Needs a dns change that is propagating right > now. > > Yep, my apt-get install finally succeeded. > > apt-get update (in scratchbox) is still broken though: > > Get:2 http://repository.maemo.org fremantle/sdk/non-free Packages > [6433B] > 51% [1 Packages gzip 0] [2 Packages 241/6433B 3%] > gzip: stdin: not in gzip format > Err http://repository.maemo.org fremantle/sdk/free Packages > Sub-process gzip returned an error code (1) > Ign http://repository.maemo.org fremantle/sdk/free Sources/DiffIndex > Get:3 http://repository.maemo.org fremantle/tools/free Packages [6433B] > 81% [3 Packages 2899/6433B 45%] > gzip: stdin: not in gzip format > Err http://repository.maemo.org fremantle/sdk/non-free Packages > Sub-process gzip returned an error code (1) > Get:4 http://repository.maemo.org fremantle/tools/non-free Packages > [6433B] > 82% [3 Packages gzip 0] [4 Packages 1975/6433B 30%] > gzip: stdin: not in gzip format > Err http://repository.maemo.org fremantle/tools/free Packages > Sub-process gzip returned an error code (1) > 99% [4 Packages gzip 0] [Waiting for headers] > > > -- > Ville M. Vainio > http://tinyurl.com/vainio ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: repository.maemo.org down
On Mon, Jan 18, 2010 at 9:49 AM, wrote: >> Am I the only one that's seeing / being bothered by r.m.o being down? >> ;-) > > No you are not the only one. > It coming back up now. Needs a dns change that is propagating right now. Yep, my apt-get install finally succeeded. apt-get update (in scratchbox) is still broken though: Get:2 http://repository.maemo.org fremantle/sdk/non-free Packages [6433B] 51% [1 Packages gzip 0] [2 Packages 241/6433B 3%] gzip: stdin: not in gzip format Err http://repository.maemo.org fremantle/sdk/free Packages Sub-process gzip returned an error code (1) Ign http://repository.maemo.org fremantle/sdk/free Sources/DiffIndex Get:3 http://repository.maemo.org fremantle/tools/free Packages [6433B] 81% [3 Packages 2899/6433B 45%] gzip: stdin: not in gzip format Err http://repository.maemo.org fremantle/sdk/non-free Packages Sub-process gzip returned an error code (1) Get:4 http://repository.maemo.org fremantle/tools/non-free Packages [6433B] 82% [3 Packages gzip 0] [4 Packages 1975/6433B 30%] gzip: stdin: not in gzip format Err http://repository.maemo.org fremantle/tools/free Packages Sub-process gzip returned an error code (1) 99% [4 Packages gzip 0] [Waiting for headers] -- Ville M. Vainio http://tinyurl.com/vainio ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
