Re: Maemo5 on Beagleboard
What's your state? Has anyone actually been able to do something with the mouse? Perhaps this helps taken from http://maemo-beagle.garage.maemo.org/alpha.html To make the mouse cursor visible, you should rename the transparent cursor directory: # sudo mv usr/share/icons/xcursor-transparent usr/share/icons/xcursor-transparent.bak Greetings ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo5 on Beagleboard
Kees Jongenburger wrote: What's your state? Has anyone actually been able to do something with the mouse? Perhaps this helps taken from http://maemo-beagle.garage.maemo.org/alpha.html To make the mouse cursor visible, you should rename the transparent cursor directory: # sudo mv usr/share/icons/xcursor-transparent usr/share/icons/xcursor-transparent.bak That's changed. There is something else now, but removing that doesn't help. I tried to modify libmatchbox2 (as Carsten suggested) but I didn't get the pointer with that either. -- Tuomas ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo5 on Beagleboard
On Sat, Oct 31, 2009 at 12:19 PM, Tuomas Kulve tuo...@kulve.fi wrote: Kees Jongenburger wrote: What's your state? Has anyone actually been able to do something with the mouse? Perhaps this helps taken from http://maemo-beagle.garage.maemo.org/alpha.html To make the mouse cursor visible, you should rename the transparent cursor directory: # sudo mv usr/share/icons/xcursor-transparent usr/share/icons/xcursor-transparent.bak That's changed. There is something else now, but removing that doesn't help. I tried to modify libmatchbox2 (as Carsten suggested) but I didn't get the pointer with that either. xroach , naeko , xeyes , xev :P Greetings ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Autobuilder repository priority ?
I have a small issue with the autobuilder. The whole thing started out by having a package that compiled nice in the SDK but not in the autobuilder due to a versioning mismatch (in my case python-dbus, but it's a generic problem as you'll see). After some snooping around, I realized the problem was that the SDK had 0.83.0-1maemo1 in fremantle/tools/free (and that's what got used when compiling in the SDK), however, the autobuilder insists on using 0.83.0-1maemo3 from fremantle/free (-devel). The problem is IMHO that the repository priorities seem to be wrong. The autobuilder should be using the highest version in the TOP PRIORITY repository that satisfies a dependency to avoid breakage because of unstable stuff in -devel and because otherwise a package can't be promoted without dragging other folks' packages with them. Thoughts ? Regards, Attila ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: How to check SDK version?
On Oct 31, 2009, at 2:01, Graham Cobb wrote: On Saturday 31 October 2009 00:28:21 Jeremiah Foster wrote: On Oct 30, 2009, at 10:58, Graham Cobb wrote: On Friday 30 October 2009 08:11:37 Reshma Prasanna wrote: Hi, I'm new to Maemo but I'm using a PC that already has a Maemo SDK installation (done by someone else). Please tell me how to find out which version of the SDK is installed? i.e. Is the SDK version 5.0 alpha, 5.0 beta or 5.0 stable version? cat /etc/maemo_version Is /etc/maemo_version canonical? Probably not. And in things like configure scripts I always check against versions of installed libraries, not against the SDK name. However, it is good enough to answer the question someone left me an SDK which version is it! Indeed. :) And well said I might add. MUD uses it as the default for the SDK name (which it uses to select alternative entries in its build file) but the user can override it if it is wrong. I wonder if we can make /etc/maemo_version canonical through some heuristic. I will see if an opportunity arises to do so. Jeremiah ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Autobuilder repository priority ?
2009/10/31 Attila Csipa ma...@csipa.in.rs: I have a small issue with the autobuilder. The whole thing started out by having a package that compiled nice in the SDK but not in the autobuilder due to a versioning mismatch (in my case python-dbus, but it's a generic problem as you'll see). After some snooping around, I realized the problem was that the SDK had 0.83.0-1maemo1 in fremantle/tools/free (and that's what got used when compiling in the SDK), however, the autobuilder insists on using 0.83.0-1maemo3 from fremantle/free (-devel). The problem is IMHO that the repository priorities seem to be wrong. The autobuilder should be using the highest version in the TOP PRIORITY repository that satisfies a dependency to avoid breakage because of unstable stuff in -devel and because otherwise a package can't be promoted without dragging other folks' packages with them. Thoughts ? The reason of this is that apt designed so that it will always install higher possible version of package. It's actually rather good than bad. Imagine what would happen if it would work another way. No new python-dbus ever :) The solution for this is to go to bugs.maemo.org and report your problem to Pymaemo project and wait for a fix. Or, better, to provide patch. You can also discuss this with pymaemo developers on their irc channel or mailing list: http://pymaemo.garage.maemo.org/getinvolved.html -- BR, Ed ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Tentative: UX meets Code hackfest in December @ Barcelona
El Viernes, 30 de Octubre de 2009, Quim Gil escribió: For budgeting and also practical purposes we will keep the number of participants around 50 people even if we get more requests. The criteria will be defined more or less by fast response, travel costs, community involvement and of course Maemo excellence in Code or UX. General feedback about the hackfest itself is also welcome. We will share here more news. Hi Quim. Will the venue be open to people who want to silently look and listen? In my case, I have zero real involvement with the Maemo community right now, but since I saw your keynote at GCDS and the first N900 specs, I've been lurking a lot and looking for all news about Maemo that I could find. I'm a long term Debian and KDE user, and I've contributed a little bit to both projects in the past (packaging and coding), so I have some development knowledge, and I'm really eager to have a Maemo device in my hands and find time to do something with it. I live in Barcelona, so my idea is to help wherever is needed in exchange for the chance to chat with people and learn. Maybe I can pick people at the airport and bring them to the meeting place, or help as a translator (outside of the airport and the hotel, the locals are not usually good with english ;-) ), etc. If the venue is very space constrained and there is no space for people in my situation, who don't have much to teach, but want to learn, I can still be available if you want somebody to find a place to have dinner or grab a good beer/coffee/whatever. Greetings. -- Alex (a.k.a. suy) | GPG ID 0x0B8B0BC2 http://barnacity.net/ | http://disperso.net ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Autobuilder repository priority ?
On Saturday 31 October 2009 11:45:54 Attila Csipa wrote: The problem is IMHO that the repository priorities seem to be wrong. The autobuilder should be using the highest version in the TOP PRIORITY repository that satisfies a dependency to avoid breakage because of unstable stuff in -devel and because otherwise a package can't be promoted without dragging other folks' packages with them. Thoughts ? The current behaviour is by design, but that doesn't stop us reconsidering whether it is still the best approach! Part of the original intent of the current behaviour was to allow the community to upgrade packages which are present in the SDK. Of course, since Diablo (I think) Nokia has taken steps to prevent the community from upgrading packages which are installed on the device but it still works for things which are in the SDK but not on the device. However, I'm not sure if that is still useful. It is useful behaviour for things which are not in the SDK at all. When we first created extras-devel one of the problems it was created to solve was that a library maintainer would introduce a new version of a library without applications being tested to make sure they still work with the new library (and I think, back in the Maemo 1/2 days, that there were some actual problem cases). So part of the point of extras-devel was to allow application developers to pick up the latest libraries -- and all developers were expected to use extras-devel in their ordinary scratchbox builds so they were always building and testing against the latest libraries. At that time, extras-devel was not intended to be a just see if it compiles and the package builds type of repository -- it was expected that developers had done some testing and thought that applications and, particularly, libraries were ready for wider use, at least among the developer community. By the way, at that time, most developers had a test repository to allow them to do things like test installation before putting it in extras-devel. When the autobuilder and, later, promotion were created it was deliberate that dependencies would be promoted so that the latest version (the one the application developer had tested with) would be promoted. The downside, of course, is that the library developer may have found a bug in their new library and not want it promoted! It may be that, with a larger community, this needs to be re-thought. Let's reconsider how we want the repositories (and related issues like promotions) to work. Graham ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Autobuilder repository priority ?
On Saturday 31 October 2009 14:49:24 Ed Bartosh wrote: is IMHO that the repository priorities seem to be wrong. The autobuilder should be using the highest version in the TOP PRIORITY repository that satisfies a dependency to avoid breakage because of unstable stuff in -devel and because otherwise a package can't be promoted without dragging other folks' packages with them. Thoughts ? The reason of this is that apt designed so that it will always install higher possible version of package. It's actually rather good than bad. Imagine what would happen if it would work another way. No new python-dbus ever :) This is not entirely correct (and definitely not recommended in our case of the autobuilder). Apt uses priorities (both repository and package level priorities can be defined, 'pinned') to decide which package to use to satisfy a dependency, and only if the priorities are equal does it base the choice on version number. Why is the current (same-priority, version only) approach bad ? Say, my app depends on python-dbus. I test it with version A, currently in the SDK and it works just fine. I upload and promote my app. All is well. However, later, the pymaemo team uploads a newer, experimental B version into -devel. From that point on I am NO LONGER ABLE to reliably update my application nor promote it (this actually happened to me, my stuff compiles in SDK, but not in the autobuilder for this very reason). But you can specify a fixed version dependency (the one in SDK and extras), you say ? But THEN I get to the problem of no updates. If bugs get squashed in the -devel version of the library I'm using, the user will never be able to upgrade to it, as my package is insisting on the old version (and the package manager wisely rather skips updates than removing already installed packages). Ubuntu and Debian solve this problem by advising different repository priorities. Stable has a highest priority, Testing is lower and Unstable is lowest. If there is a package in Stable that satisfies my requirement, that's the one that should be used. But then it will never get updated, you say ? Wrong ! Remember what I said up there - if the priority is the same, the version decides. So, the moment a new version of the dependency reaches *Stable*, it will become the highest priority and will get updated. It's a recommendation that dependencies should be REALISTICALLY listed. You should not depend on a high version number just because it's new or even because it's the one bundled on the system (!). You should depend on the minimal version that provides the actual functionality you require. Hope my problem is a bit more clear now. Regards, Attila ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
QA process = bug fixing disincentive?
Hi, After working 'til stupid o'clock last night on a new version of Hermes, today someone's found a bug which'll impact a small number of people. The fix is trivial. However, I find myself *not* wanting to fix it as it'll need to go through another round of testing. Although the principle of resetting package karma to 0 made some sense - as any change could fundamentally break the package - it's also true that a one-line change to a relatively mature package probably won't change whether it's optified; its power usage profile; its package description and icon etc. Perhaps there's an argument that some proportion of the karma earned should be retained, inversely related to length of time in -testing so far? Thoughts welcome. 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: OT (hope not too much) N900 FW
Hi all, Delfim Machado schrieb: [...] Can i do something to recover it so i can play with him in the weekend or i must wait for monday? Sorry the little OT I also broke the firmware of my N900 and now I am looking for a way to recover it using my Ubuntu PC? Is it possible to get a firmware image somewhere? Do I have to wait until the device is released officially? Thanks for any hint, Uwe smime.p7s Description: S/MIME Cryptographic Signature ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: QA process = bug fixing disincentive?
Hi, 2009/10/31 Andrew Flegg and...@bleb.org: Hi, After working 'til stupid o'clock last night on a new version of Hermes, today someone's found a bug which'll impact a small number of people. The fix is trivial. However, I find myself *not* wanting to fix it as it'll need to go through another round of testing. Although the principle of resetting package karma to 0 made some sense - as any change could fundamentally break the package - it's also true that a one-line change to a relatively mature package probably won't change whether it's optified; its power usage profile; its package description and icon etc. Perhaps there's an argument that some proportion of the karma earned should be retained, inversely related to length of time in -testing so far? I strongly agree with you. I've not released anything yet in Maemo repository but I'll do it soon, I hope the whole experience won't be too much frustrating :\ By the way, I've upgraded to Hermes 0.2 but I haven't used it yet, what is the bug you're talking about? Best regards, -- Andrea Grandi email: a.grandi [AT] gmail [DOT] com website: http://www.andreagrandi.it PGP Key: http://www.andreagrandi.it/pgp_key.asc ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: QA process = bug fixing disincentive?
On Sat, Oct 31, 2009 at 18:55, Andrea Grandi a.gra...@gmail.com wrote: By the way, I've upgraded to Hermes 0.2 but I haven't used it yet, what is the bug you're talking about? Some Facebook UIDs will now overflow MAXINT, and so I need to store it in gconf as a long, rather than an int. 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: QA process = bug fixing disincentive?
Hi, I just threw away 5 karma to make some changes (but I think worthwhile). I think the idea is that when there's many more users, 10 silly karma points will be nothing. Until then, have faith, or something like that. :) Frank On Sat, Oct 31, 2009 at 1:43 PM, Andrew Flegg and...@bleb.org wrote: Hi, After working 'til stupid o'clock last night on a new version of Hermes, today someone's found a bug which'll impact a small number of people. The fix is trivial. However, I find myself *not* wanting to fix it as it'll need to go through another round of testing. Although the principle of resetting package karma to 0 made some sense - as any change could fundamentally break the package - it's also true that a one-line change to a relatively mature package probably won't change whether it's optified; its power usage profile; its package description and icon etc. Perhaps there's an argument that some proportion of the karma earned should be retained, inversely related to length of time in -testing so far? Thoughts welcome. 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 ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: QA process = bug fixing disincentive?
On Sat, Oct 31, 2009 at 19:26, Frank Banul frank.ba...@gmail.com wrote: I just threw away 5 karma to make some changes (but I think worthwhile). I think the idea is that when there's many more users, 10 silly karma points will be nothing. Until then, have faith, or something like that. :) That's the theory, anyway :-) 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: QA process = bug fixing disincentive?
On Saturday 31 October 2009 19:43:40 Andrew Flegg wrote: After working 'til stupid o'clock last night on a new version of Hermes, today someone's found a bug which'll impact a small number of people. The fix is trivial. However, I find myself *not* wanting to fix it as it'll need to go through another round of testing. Yeah, I know the feeling. Both as the person who has the silly UID that causes problems and as a person who has/had stuff in -testing with 7 karma (collected over a week) and had to seriously consider whether to let the existing package go to extras or push the (not significantly altered, with minor fixes and more user friendly defaults) version and start karma collection from 0. There is a definitely a conflict there. I support Jeremiah's suggestion that minor packaging/typo fixes that do not alter app functionality (e.g. when you go from 1.0-maemo0 to 1.0-maemo1) should not reset app karma. Should require some discipline so people would not abuse this, but still better than forcing releases to be spaced 10+ days no matter how large the changes or how simple the fix. Although the principle of resetting package karma to 0 made some sense - as any change could fundamentally break the package - it's also true that a one-line change to a relatively mature package probably won't change whether it's optified; its power usage profile; its package description and icon etc. Yes, there is definitely a sense of throwing out the baby with the bathwater here - as is, with a sufficiently mature app, NOT applying simple fixes will get the app to the user quicker, and applying the fixes will keep the app AWAY from the users. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: QA process = bug fixing disincentive?
On Oct 31, 2009, at 20:27, Andrew Flegg wrote: On Sat, Oct 31, 2009 at 19:26, Frank Banul frank.ba...@gmail.com wrote: I just threw away 5 karma to make some changes (but I think worthwhile). I think the idea is that when there's many more users, 10 silly karma points will be nothing. Until then, have faith, or something like that. :) I wonder if we can preserve a package's karma if it only gets a package upgrade. Lets say you only have a little typo in your app, you fix that, and upload a new package with a new package version. Since you didn't upload a new _app_ version, your karma is preserved. This way we allow devs to make small changes and keep karma, make big changes and bump your app version and start over at zero. Does that sound worthwhile and implementable? Jeremiah ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: QA process = bug fixing disincentive?
Hi, 2009/10/31 Attila Csipa ma...@csipa.in.rs: There is a definitely a conflict there. I support Jeremiah's suggestion that minor packaging/typo fixes that do not alter app functionality (e.g. when you go from 1.0-maemo0 to 1.0-maemo1) should not reset app karma. Should require some discipline so people would not abuse this, but still better than forcing releases to be spaced 10+ days no matter how large the changes or how simple the fix. even more important: what if developer/users find a security bug that should really be fixed as soon as possible? In a normal Linux distribution, patched package is released and available after few hours. Here it would pass lot of time before final user can apply the patch. -- Andrea Grandi email: a.grandi [AT] gmail [DOT] com website: http://www.andreagrandi.it PGP Key: http://www.andreagrandi.it/pgp_key.asc ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
RE: QA process = bug fixing disincentive?
Hi, From: maemo-developers-boun...@maemo.org [maemo-developers-boun...@maemo.org] On Behalf Of ext Andrea Grandi [a.gra...@gmail.com] Sent: 31 October 2009 22:06 To: Attila Csipa Cc: maemo-developers@maemo.org Subject: Re: QA process = bug fixing disincentive? even more important: what if developer/users find a security bug that should really be fixed as soon as possible? In a normal Linux distribution, patched package is released and available after few hours. Here it would pass lot of time before final user can apply the patch. I think the problem here is that some braindead system has been introduced, which doesn't account for the actual work being done. So, if it's ok that somehow the karma goes down, it should be lowered accordingly to the severity of the bug found. Which also means that all the lost karma (plus some more?) should be re-instated once the bug is fixed and the fix release and verified. This would actually give an incentive to bugfixing. igor ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Autobuilder repository priority ?
2009/10/31 Attila Csipa ma...@csipa.in.rs: On Saturday 31 October 2009 14:49:24 Ed Bartosh wrote: is IMHO that the repository priorities seem to be wrong. The autobuilder should be using the highest version in the TOP PRIORITY repository that satisfies a dependency to avoid breakage because of unstable stuff in -devel and because otherwise a package can't be promoted without dragging other folks' packages with them. Thoughts ? The reason of this is that apt designed so that it will always install higher possible version of package. It's actually rather good than bad. Imagine what would happen if it would work another way. No new python-dbus ever :) This is not entirely correct (and definitely not recommended in our case of the autobuilder). Apt uses priorities (both repository and package level priorities can be defined, 'pinned') to decide which package to use to satisfy a dependency, and only if the priorities are equal does it base the choice on version number. Why is the current (same-priority, version only) approach bad ? Say, my app depends on python-dbus. I test it with version A, currently in the SDK and it works just fine. I upload and promote my app. All is well. However, later, the pymaemo team uploads a newer, experimental B version into -devel. From that point on I am NO LONGER ABLE to reliably update my application nor promote it (this actually happened to me, my stuff compiles in SDK, but not in the autobuilder for this very reason). True. However there can be another situation: SDK version of python-dbus is buggy and you can't use it with your application. You would have to wait until new fixed version of python-dbus reaches high priority repo to be able to build your application with it. Not so good for application developer, either. I don't want to say that current uproach is the best, just want to show you another side of the problem. But you can specify a fixed version dependency (the one in SDK and extras), you say ? But THEN I get to the problem of no updates. If bugs get squashed in the -devel version of the library I'm using, the user will never be able to upgrade to it, as my package is insisting on the old version (and the package manager wisely rather skips updates than removing already installed packages). Ubuntu and Debian solve this problem by advising different repository priorities. Stable has a highest priority, Testing is lower and Unstable is lowest. If there is a package in Stable that satisfies my requirement, that's the one that should be used. Are you sure it works this way? I thought that packages are built with dependencies from unstable in Debian, just like they're built against extras-devel in Maemo. But then it will never get updated, you say ? Wrong ! Remember what I said up there - if the priority is the same, the version decides. So, the moment a new version of the dependency reaches *Stable*, it will become the highest priority and will get updated. It's a recommendation that dependencies should be REALISTICALLY listed. You should not depend on a high version number just because it's new or even because it's the one bundled on the system (!). You should depend on the minimal version that provides the actual functionality you require. Hope my problem is a bit more clear now. It was clear from your previous mail. Actually python-dbus is not very good example. It's not only SDK package. I might be wrong but I think it's included into PyMaemo releases and is delivered through Extras. Nokia included it into SDK, but this is a special case. SDK packages shouldn't be uploaded to extras-devel at all. There are plans to implement checks on autobuilder side to prevent this. -- BR, Ed ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Autobuilder repository priority ?
On Saturday 31 October 2009 23:35:08 you wrote: Ubuntu and Debian solve this problem by advising different repository priorities. Stable has a highest priority, Testing is lower and Unstable is lowest. If there is a package in Stable that satisfies my requirement, that's the one that should be used. Are you sure it works this way? I thought that packages are built with dependencies from unstable in Debian, just like they're built against extras-devel in Maemo. You're right you can't change pinning on the *builder* within the *same* queue, that would make no sense. The problem is that the autobuilder already uses a mix of repositories (as you said later, having packages from extras-* overriding SDK stuff is not right) and that we can't skip the promotion process (i.e. no security.debian.org that is handled differently). If I was unclear as to the goal - I don't want to cross-reference repo contents (bad, bad idea). I want to be able to issue updates to packages that have been already promoted and got to the general public (obviously not typo fixes but stuff that is REALLY important), and for that, we need a queue that has a different repository layout (i.e. no extras-devel overriding extras). Actually python-dbus is not very good example. It's not only SDK package. I might be wrong but I think it's included into PyMaemo releases and is delivered through Extras. Nokia included it into SDK, but this is a special case. I just ran into this problem personally with python-dbus, hence the mention, but I did say the problem is more generic than that :) Regards, Attila ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Why should it be so hard and should I even bother with Extras for fremantle?
I'm a power user and not the only one. And what I used my current tablets for were testing networks and doing other low level stuff, mainly from xterm, but sometimes from python front-ends to linux. So I ported a number of utilities under Linux to maemo/diablo and started to do it for fremantle. Way back when, I complained that half of what I wanted to install was invisible except under red pill mode, and after getting all the noise about not using it and explanations, for those utilities I thought were significant, I created versions in user/* because it is the only way they would be visible. One of them was socat. So I ported it and now that I submitted it for fremantle they say it shouldn't be put in user/ so I'm both confused and annoyed. This is the iTunes Application Store by mob justice. I don't like your app so you can't have it in extras!. No one reported any actual bug, or problem, they just don't want to make it available to users or anyone else using the normal means. There is only one option and I'm trying to play by the rules - and going thorough all the steps. I have it in user/utilities which is probably where it belongs, but someone suggested user/development. Normally I wouldn't mind, but first, no guarantee anyone will actually change their vote, second, it is really annoying since I have to bump the version too or it won't build, reconstruct the source uploads, upload them, build them, hope nothing goes wrong, and promote them JUST TO CHANGE ONE STUPID STRING that someone doesn't like AND MAY NOT RESULT IN APPROVAL. A lot of effort for probably nothing. So we're back to having to do dpkg, hack around the application manager, turn on or add red pill mode and all that junk again. Or just tell everyone to enable extras-testing so they can have access to disliked programs and have to put up with unstable betas? Is there some category under user/* I can put it in without worrying about being rejected except for actual bugs, or did all the discussion about how to avoid the ugly hacks yet be able for users to actually get to my programs result in nothing? ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
