Re: promotion of orphaned packages
On 14-Dec-11 03:00, Roberto Colistete Jr. wrote: This have been talked about, but stopped at a question - do you really want orphaned packages published in Extras ? If a problem surfaces or a bug gets reported, there is nobody to take care of it, and removal can get really tricky (who gets final say as how broken it has to be to ask Niels to remove it, what if there are other packages depending on the orphaned one, etc). My opinion : if the orphaned package is in extras-testing for a long time (1 month or more) and has a lot of positive votes (12, 2x the 6 needed to promotion), then it is reasonable that it is stable and well tested. So it should be promoted to extras by some Maemo admin member. Two problems: 1. The apps might have been tested on older versions of dependencies, which have been superseeded in the meantime. For example I have deprecated QtMobility 1.1, so it doesn't matter how well tested it was, that version of mobility is no longer available. Ditto for, say, things that depend on the kernel - it might work on one (old) version of the power kernel, but not another, etc. 2. It's not about promoting, it's about dealing with it when it's already in Extras and it goes wrong (and things do go wrong). If it's an orphaned package, there is a lack final authority who can (from a technical perspective) say what should be done, should it be a known issue, should it be removed, can someone take over, etc, etc. This is already a problem in Extras, it's just not too widespread (partially because the orphaned packages that could cause problem are stuck in testing) so we are in practice ignoring it. Best regards, Attila Csipa ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: R: promotion to extras
On 12/12/2011 08:19 PM, emme...@gmail.com wrote: You should also solve the problem of those applications that are ready to be promoted, but the maintainer is no longer alive. For example, after one month of the release, the promotion may become automatic, or we should enable Supertester to do this. This have been talked about, but stopped at a question - do you really want orphaned packages published in Extras ? If a problem surfaces or a bug gets reported, there is nobody to take care of it, and removal can get really tricky (who gets final say as how broken it has to be to ask Niels to remove it, what if there are other packages depending on the orphaned one, etc). Best regards, Attila Csipa ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Does Fremantle support any Qt Quick Components?
On Thursday 14 July 2011 23:15:46 you wrote: My question is very simple: are any of the Qt Quick Components packaged and working on Maemo 5? Not the latest greatest, but ... http://maemo.org/packages/view/qt- components/ Also, the custom branch should be usable directly (i.e. just get the stuff from https://qt.gitorious.org/qt-components/qt-components/commits/custom and shove it in your qml dir), with the caveat that in the case of Maemo5, you will have to use a version from before they switched to QtQuick 1.1. Personally, I wouldn't mind if some packaging support came from the community side, there are only so many packages and projects I can support myself. Best regards, Attila Csipa ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: package promotion blocked
On Wednesday 08 June 2011 12:00:39 you wrote: There probably is no reason to block it anymore. Any objections to removing the block, anyone? On Wed, Jun 8, 2011 at 1:05 AM, b0unc3 b0u...@email.it wrote: Hello, I would like to promote my package to the extras-testing, but I see a warning that says: Warning: Promotion of experimental Qtm based applications (libqtm11 or libqtm-extras) is blocked due to conflicts with stable versions. My package is a QML app, that, as far as I can tell, depends (needs) on libqtm-11-sensors and libqtm-11-declarative. Could someone please give some advice on which library I've to use to promote my package? Thank you. One little snag, I hope Niels can help me with it - we would need to lift the block BUT disable autopromotion for the packages in question to avoid having different versions of libqtm-11 in the same repositories... Best regards, Attila Csipa ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Qt SDK 1.1 RC released
On Saturday 09 April 2011 02:44:26 you wrote: That said, it doesn't matter much what Qt version is used for compilation, what matters is the library version installed on the device. ...with two (perhaps obvious) caveats - one, that the on-device libs must contain the APIs you used, and two, a Maemo specific, that your dependencies are right (because we RPATH the community versions of mobility). Best regards, Attila Csipa ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Qt SDK 1.1 RC released
Good news everyone, There has been an update on the long road to QtSDK 1.1, but we're almost there now - we got the RC today, and the final should not be that far away http://labs.qt.nokia.com/2011/04/06/qt-sdk-1-1-rc-released/ The differences are mostly bugfixes considering the Maemo side, here's the generic list: Qt 4.7.3 is included for Desktop and Symbian Update to Qt Mobility 1.1.2 Qt Assistant added as separate package (due to developer request) Installer can use system proxy on Linux Notification API moved from experimental to “Additional APIs” Several fixes for the Qt Simulator Several fixes for the installation/updating workflow This is pretty much it WRT to features expected in 1.1 final, too, the difference in RC and the final release will be just showstopper bugfixes. Best regards, Attila ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Printing with the N900
On Thursday 10 March 2011 16:40:50 you wrote: There are still promotion problems. However I was able to promote the packages cups-client, libcups2, libcupsimage2 and cups-common. Still problems with the main-package cups. What's the exact promotion problem ? I don't see any errors on http://maemo.org/packages/package_instance/view/fremantle_extras- devel_free_armel/cups/1.3.8-maemo12/ which is the latest cups I see... What should I do with the dev-packages? They are necessary to enable a systemwide printing support. Should I promote them, too? On the other side, they have dependencies, which are only available in the SDK. If you need -dev packages on end-user devices to be able to use the service, you're doing/packaging it wrong. Are you sure Build-depends is not enough to pick up whatever is needed ? Best regards, Attila Csipa ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
QtMobility 1.1.1
Good news everyone ! Qt Mobility 1.1.1 released (and now available from Extras-devel !) We are happy to announce our Qt Mobility 1.1.1 release. This release is a maintenance release which includes a lot of bug fixes and improved QML bindings. We have also enhanced the documentation and auto tests. For usage instructions, see http://wiki.forum.nokia.com/index.php/Latest_Qt_and_Qt_mobility_evaluation_on_Maemo This version, if it turns out stable enough, *will* end up in Extras. Here are some of the high priority bugs fixed in this release. * Multimedia: Pulseaudio plugin present on Maemo * Multimedia: Video graphics item causes a Symbian device to reboot * Multimedia: QMediaPlayer does not play an MP4 file if header is after the encoded data block * Multimedia: Memory leaks on Symbian * System Information: Symbian devices crashes when 32 char long WLAN access point name is used * Contacts: QML contacts model is not updated when a contact is deleted * Organizer: Opening a file dialog in calendar demo cause crashes on Symbian devices * Organizer: QML organizer item does not respect the detail changes * Messaging: QMessageManager::updateMessage() crashes on Symbian * Location: QLandmarkFetchRequest::waitForFinished() causes a crash on Symbian * Service Framework: Memory leaks on Symbian * Document Gallery: Mediabrowser displays 0 songs on Symbian * And hundreds more bug fixes As always, thank you for your feedback, bug reports and fixes so far and we look forward to hearing more from you. * Qt Bug Tracker: http://bugreports.qt.nokia.com * Code/Doc contributions: http://qt.gitorious.org * Mailing list: http://lists.qt.nokia.com/mailman/li...ility-feedback Best regards, Attila Csipa ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: [CSSU] Qt fixes in Maemo 5 Community SSU?
On Mon, Feb 28, 2011 at 3:45 PM, Andrew Flegg and...@bleb.org wrote: Hi, There are a couple of people with patches to Qt that they would like to see included in the CSSU. However, unlike Maemo core, Forum Nokia are actively maintaining the Maemo 5 Qt ecosystem (e.g. mcsp). Attila/Ville/..., what're your thoughts on rebuilding Qt as part of the CSSU? I don't know the specific patches, but what about in principle? Qt is somewhat tricky because of the Nokia repos and Ovi compatibility requirements (I know a lot of folks couldn't care less about those, but those are still hurdles when dealing with things on an official level). There are also questions of just how good compatibility would be (i.e. what do we do in the autobuilder with software requiring, say, QtQuick 1.1), or how can we make version switching painless for people using the QtSDK (which will always track official releases). The best would be, as always, to have those integrated upstream and let them trickle down through official channels. Now, while the trickling part is not something I would hold my breath for in the case of the N900, I still think it is very important that we keep things as close/merged with upstream as possible. Best regards, Attila ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Google Summer of Code 2011
On Monday 21 February 2011 10:30:46 you wrote: As Maemo has been discontinued probably now MeeGo should be in the focus. Maemo is not technically 'the project' here so it's corporate status is not precluding the community, upstream and/or related projects to apply with good ideas that are applicable to Maemo (say, some Qt related project). You are right, however, that perhaps there is a higher value in picking projects that are relevant to both Maemo and MeeGo, or, if possible, to join forces with MeeGo on an organizational level to have an even stronger application to the program. Best regards, Attila Csipa ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: adaptation of Extras QA hurdles
On Thursday 27 January 2011 22:02:36 you wrote: Maybe we could make it easy to leave a numeric rating + let the user pick one of a pre-defined set of labels (that's how it is done in Little Big Planet - it's mandatory to give a numeric rating after playing a community-created level, the label or tagging part can be skipped). So for example, after using an application, you can rate it from 1 star to 5 stars (which will be automatically synced with the website, ideally) and you can also pick one label that describes the application (i.e. cool, useful, rubbish, accelerometers, audio, video, crashing, funny, boring, online, contacts, productive, needs work, ... - you can see a list of labels on the LBP website: http://lbp.me/search?labels=) that doesn't really categorize the application, but gives a different kind of feedback without the useless short comments. Of course, this rate after usage feature could be turned off by default or made easy to deactivate globally. This is all really cool, but... don't take it the wrong way... not what extras QA is about. I.e. at that stage we should not really care about cool/uncool, productive or not, etc. It is a rather technical thing, does it break/bork/confuse/conflict with something/policies or not. I can see how this can be good for Extras in general, but not really how it would help the QA hurdles. Best regards, Attila Csipa ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: adaptation of Extras QA hurdles
On Thursday 27 January 2011 18:07:32 Andrew Flegg wrote: Unless we take extraordinary (and almost certainly self-defeating) actions like requiring KISStester to be installed to use any software from Extras-(devel|testing). In fact, I would very specifically argue against such an approach. The experience from various appstores tells us that forced/induced feedback is basically rubbish. Without wishing to insult anyone, most of the feedback gathered that way goes the lines of 'ooh, shiny' vs 'sucks'. We need more focused feedback than that - and IMHO having people opt in instead of out is IMHO the only way to do it (I would rather have 0.1% of good feedback than 10% of noise). That's not to say that a firm push behind KISStester wouldn't help with the QA process. I certainly like the idea of it a) doing automated checks and b) using notifications if I've installed a new version of an app and haven't rated it in a week. I would appreciate *some* help with it, though, esp considering A). In the meantime, I made a quick porting trip (pun intended) so now kisstester is done with QtQuick, and to my delight, it makes quite a difference (to my surprise, it wasn't that much hairier than python contrary to what I expected from good ole C++). Best regards, Attila Csipa ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Qt SDK 1.1 tech preview
The tech preview of Qt SDK 1.1 has been released. This gives you tooling to play with QML and QtQuick in general, a lot nicer IDE in general with a few extra Maemo and Symbian goodies (yes, this one is an all-around SDK, no more Nokia Qt SDK vs Qt SDK). Best regards, Attila ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Qt Mobility 1.1 for Fremantle
On Mon, Jan 10, 2011 at 5:43 PM, Cornelius Hald h...@icandy.de wrote: Doh, you're right, looks like I'm an old timer ;) Also looks like I have to clean out my scratchbox. Just checked and the needed features are in: /usr/share/qt4/mkspecs/features and using CONFIG += mobility11 works fine. And while we are at it, the tech preview version of 1.2 has also been pushed to extras-devel, and should be used analogously (i.e. CONFIG += mobility12). According to http://labs.qt.nokia.com/2010/12/24/qt-mobility-1-2-technology-preview/ the highlights are Bluetooth and NFC, with plenty other smaller nifties trailing. Best regards, Attila ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Qt Mobility 1.1 for Fremantle
On Monday 03 January 2011 03:59:34 you wrote: Where is the right place to discuss these packages? Maemo.org developers list, qt devnet, forum nokia, JIRA, ... ? General discussion here (or the tmo thread), I wanted to apply to bugs.maemo.org, but upon further though I'm afraid it will get mixed up with the 'real' upstream JIRA. Ideas/suggestions welcome. I have just tried to compile my application with the libqtm-11-contacts. I found out that the maemo5 backend is not part of the libqtm-11-contacts package. The application still works but it will use the backend from the official qtm libs (/usr/lib/qt4/plugins/contacts). Was that intentional or am I missing something? You're missing the fixed version that is being uploaded right now :) Paths are still not perfect, but that will come in the next iteration. Best regards, Attila Csipa ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Qt Mobility 1.1 for Fremantle
... and a happy new year ! We have kickstarted a community 'compatibility program' with a little Forum Nokia help which will focus on bringing the latest Qt and related tech tools/fixes/updates to developers, without having to worry about Nokia release schedules and support status. The first component that is released as part of this effort is QtMobility 1.1 (as 1.0.2 is getting long in the tooth), currently available as libqtm-11-* in extras-devel. If/when a SSU is released with 1.1 as the official, these libraries will be replaced with placeholders that point to those 1.1 libs. The bleeding edge can always be attained with libqtm-experimental which will permanently remain in extras-devel (after we test 1.1 this will switch to 1.2, etc). To use these packages you need do to CONFIG += mobility11 in your .pro file instead of just 'mobility' (as mobility will reference always the official one from the firmware). Enjoy (and provide feedback/patches !) Best regards, Attila ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Qt Mobility 1.1 for Fremantle
On Wednesday 29 December 2010 16:47:54 you wrote: This is really great news! I assume applications using it can not promoted to extras-testing until we have the SSU with libqtm-11-*, right? Right (well, mostly :). For now promotions should not be possible - but we might let these packages through to Extras as a compatibility measure later on, depending on feedback and SSU content. Best regards, Attila Csipa ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Qt Mobility 1.1 for Fremantle
On Wednesday 29 December 2010 17:04:21 you wrote: Will a similar effort be done for N8x0 folks? Is there any technical reason why Diablo should be locked in to qt 4.5.x instead of 4.7.1? Well, yes and no. You can certainly compile it (in fact at one point I compiled 4.7.0 for Diablo myself, but for some reason it was fairly sluggish), but there are things that need to be worked on before it makes sense to release it onto unsuspecting N8x0 users 1. inputmethod stuff - this is very custom work on 4.5, so those patches need to be transplanted carefully 2. the maemo5 module will not be available - IIUC it requires/wraps some hildon functionality which is not available on Diablo 3. It's big. I guess most people who had interest in Qt cloned their roots already, but it takes up significantly more space than 4.5 4. look into what's causing the performance regression Otherwise, if I look at it from the QtQuick angle, it's actually fairly OK (one of the QtQuick promise is actually observable here - a QML/components based application most of the time far easier to port to Diablo with 4.7 than a QWidget based application from Fremantle, performance notwithstanding). Best regards, Attila Csipa ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Qt Mobility 1.1 for Fremantle
On Wednesday 29 December 2010 16:50:33 you wrote: Great news and thanks - this is really needed. Are those based on the 1.1 release version or on 1.1 branch from Git? Should be the release, but the plan is to follow any point releases, i.e. should a 1.1.1 tag appear which is an identical API bugfix release, the same qtm-11 packages will update to that. We should also have qtm-12 which (currently) will follow releases, i.e. 1.2 techpreview, beta, etc. Best regards, Attila Csipa ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: PyQt issues on Diablo?
Oooh, just realized we're talking about *Diablo*. Let me check. On Fri, Dec 10, 2010 at 5:09 AM, Edward Page eop...@byu.net wrote: On Wed, Dec 8, 2010 at 4:58 AM, Attila Csipa ma...@csipa.in.rs wrote: This issue was due to some dependency/promotion issues which left PyQt in a half-promoted state. An update has been made some three weeks ago (during the conference :) and everything should be dandy after that. If not, the user should apt-get update to the latest PyQt (the problem is that the application manager might refuse to pull in all dependant packages and instead opt not to install the application). Hmm, I installed all of my Qt apps before then without a problem. Most of my users grabbed it this last week and are having the issues. Just to test that I could keep my device in a good state, I did what I expect my users to do (with extras-devel enabled): apt-get remove python2.5-sip4 apt-get autoremove apt-get update apt-get install dialcentral ejpi gonvert After doing all of that I ended up in the same situation as my users: Nokia-N810-43-7:~# /opt/ejpi/lib/ejpi_qt.py Traceback (most recent call last): File /opt/ejpi/lib/ejpi_qt.py, line 12, in module from PyQt4 import QtGui RuntimeError: the sip module implements API v8.0 but the PyQt4.QtGui module requires API v7.0 Any idea why it is still happening? Ed Page ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: PyQt issues on Diablo?
On Wed, Dec 8, 2010 at 4:50 AM, Edward Page eop...@byu.net wrote: I've been working on porting DialCentral to Qt. I've got some users wanting to test this out on Diablo but they are getting the following error: dialcentral_qt.py Traceback (most recent call last): File /opt/dialcentral/lib/dialcentral_qt.py, line 12, in module from PyQt4 import QtGui RuntimeError: the sip module implements API v8.0 but the PyQt4.QtGui module requires API v7.0 User Reports: http://talk.maemo.org/showpost.php?p=887774postcount=1350 http://talk.maemo.org/showpost.php?p=891411postcount=1375 http://talk.maemo.org/showpost.php?p=892019postcount=1378 I've not seen this at all on my n810. Seems like some packages got out of sync somehow. Anyone know anything further? This issue was due to some dependency/promotion issues which left PyQt in a half-promoted state. An update has been made some three weeks ago (during the conference :) and everything should be dandy after that. If not, the user should apt-get update to the latest PyQt (the problem is that the application manager might refuse to pull in all dependant packages and instead opt not to install the application). Best regards, Attila ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: QtQuick not present in PR1.3
On Fri, Nov 12, 2010 at 5:41 PM, Robin Burchell virot...@viroteck.netwrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/12/2010 03:36 PM, Alberto Mardegan wrote: Hi all, did anyone try to run QtQuick applications in PR1.3? I wrote sample.qml with these contents: = import QtQuick 1.0 I'm no QML expert, but where did you get the idea to do this? AFAIK it's currently 'import Qt 4.7' As Daniel says, QtQuick 1.0 is the way to do it starting with 4.7.1 and the 'generic' Qt documentation reflects that. The 4.7 notation has been deprecated so that QML versions could move quicker/independent from general Qt version releases across platforms. Of course you'd still have to use it on Maemo5 as PR1.3 has 4.7.0 Best regards, Attila ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Packaging - dpkg-shlibdeps problem
On Tue, Oct 12, 2010 at 4:47 PM, Felipe Crochik fel...@crochik.com wrote: Hi Daniel, Almost there…. I don’t get a compilation error anymore but now my communi package becomes dependent on libircclient-qt-dev (not libircclient-qt). Maybe I got it the “lib” idea wrong: libircclient-qt and libircclient-qt-dev share the exact same code the only difference is on the Makefile (and control). The dev package installs “everything” (headers, lib, mkspecs) and the “release” package just the lib. My communi package has: Build-Depends: libircclient-qt-dev, … Now when I create the communi package using dh_shlibdeps it adds the dependency to the “libircclient-qt-dev”. I assume there is a way to tell the libirccclient-qt-dev package that it’s “runtime” version is “libircclient-qt” or something like that, can you help me again? Once you are “here” anyway: I would assume there is a way to have both libircclient-qt and libircclient-qt-dev not need each to have its own “source” code. Is there a “smarter/better/easier” way of creating lib packages? You answered your question right there - you can (and should) generate all debs from one source package - debhelper's dh_install helps you control which file goes into which package via .install files. See http://www.tin.org/bin/man.cgi?section=1topic=dh_install (it even has an example for -dev packages). Best regards, Attila ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Packaging - dpkg-shlibdeps problem
On Tue, Oct 12, 2010 at 6:43 PM, Felipe Crochik fel...@crochik.com wrote: It seems that I am missing one (or some) piece(s) of the puzzle, I tried downloading the libqfacebook and libqfacebook-dev packages using apt-get source but it didn’t help at all. As far as I can tell the two packages are exact the same and I can’t make any sense of why the “object files” are included (*.o, …) and/or why on both you have a libqfacebook-dev folder inside the debian. Including *.o files or that dir sounds like missing or improper cleanup (=packaging error), but let's not digress, the bottom line is this: IINM you don't need to touch anything in the .pro file, you just need to a) specify both dev and binary packages in the debian/control file, one after the other. b) have a debian/libirccclient-qt-dev.install file that says something like 'usr/include' (do NOT include the libs !) c) have a debian/libirccclient-qt.install file that says something like 'usr/lib/libircwhatever.so' Considering you should already have all files in debian/tmp that's it, everything else is taken care of by debhelper (dh_install copies over the files specified in install from debian/tmp into per-package directories which are then later put into separate debs by dh_builddeb) ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Package promoting
2010/9/24 Benoît HERVIER kher...@khertan.net Does there is a way to know for an application from which package it come. dpkg -S /opt/bin/app Does it ll be accepted if like kisstester, i implements a dialog to user to permit it to vote for my apps after presenting him the rules of QA ? Not sure I understood... Is the question if the app can vote for itself ? Best regards, Attila ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Package promoting
On Thu, Sep 23, 2010 at 12:22 PM, Polyvertex polyver...@gmail.com wrote: Understood. That's only a part of my point. My main concern is that users don't always vote and do feedbacks plus the fact they currently don't know where to go if they want to. This is a fact. This problem cannot be seen with popular and visible applications but it becomes a blocking one with small applications, hence my initial post : the extras repository contains a too old version of my application since too long, and the right version is stuck into extras-testing. This is also a fact. The trouble is that no matter how popular apps like FAP or appdownloader get, IMO there will always be a very dominant number of users who will use the system-provided app manager. I agree that the scoring scheme for Extras which we DO have on maemo.org is grossly underutilized - something that IMO stems from the previous point (giving feedback is difficult and people don't install things from the web anyway). I feel the best we can do for *fremantle* is continue streamlining extras-testing (extras-assistant and FAP are of course very welcome to make this experience better for at least a portion of users) and try to get these points as clearly as possible through to the Harmattan program so that this stuff in the ends finds it's way to next-gen app managers. When I expose those two facts here, the answers I get is that things has been drastically improved since Chinook/Diablo epoch and one is even happy about the nature of my complain. Great. I'm not happy that there are things that are broken or inefficient - I just think it's a good thing that we ARE moving in a good direction of reducing delays without outright sacrificing the relatively safe-harbor nature of Extras. Not perfect, and needs continuous kaizen-style improvement, but moving ! (I *really* need to make some graphs...) Please forgive me if I discard something with something seen as a been-there-done-that, it's not dismissive of your enthusiasm or popping ideas in - it's just that some things have been debated over quite extensively and I don't see that anything has changed fundamentally that would make a difference. You see, in my example, I am perfectly aware that the testing version of my application will never reach this 10 karmas score and that it will be unlocked only because time has passed. This is a problem. Yes, that's why we will try to increase tester input volume with specialized tools. On a side note - it will be unlocked because you have at least 3 positive tester votes, the additional quarantine time is there only to avoid the tester votes 'overpowering' non-tester votes. And yes, I agree that we might need different rules for packages that are updates for things already in extras (as that is already listed in extras-testing procedure improvements). @Naresh: Hey, I'm a dev with packages in extras-* too ! :) Best regards, Attila ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: suspendprocess - poor man's power save
On Monday 20 September 2010 17:35:34 you wrote: There are some potential downsides for just suspending processes completely. Most of the processes have subscribed to several different D-BUS messages, X events etc. For example D-BUS will infinitely buffer messages that are sent to a connected client but not read by it. If these messages can be very frequent (say device orientation network condition messages), this will soon bloat D-BUS memory usage quite a bit. After D-BUS Hmm... the external launcher that suspends is meant for apps that cannot really handle/listen to dbus in the first place - if they can, they should react to the lose-focus / screen off messages directly, not through intermediary daemons, right ? Best regards, Attila Csipa ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Package promoting
On Wed, Sep 22, 2010 at 12:17 PM, Polyvertex polyver...@gmail.com wrote: After reading all related wiki pages on the subject, it seems that a package can be unlocked for promotion from extras-testing to extras only if : * the testing package gained 10 positives votes from the community * or if the package has been into extras-testing for a while (fixed delay ? how much ?) There are currently two options a) the package gathers 10 karma and has spent at least 10 days in extras-testing b) the package gathers 3 supertester (people with 100+ testing karma) thumbs ups and has spent at least 20 days in extras-testing I have personally paid a lot of attention to improve the process and hunt down stuck packages and their owners, so from the hundreds of packages now we're down to less than 50, still far from perfect, but a lot better. I will shortly publish some data about this changed during this year. PS If the package never gets 10 votes (or 3 tester votes) then it never gets unlocked. The idea behind extras-testing (and the default-on state of Extras) was that the community QAs the packages. I don't see automatic promotions in case of lack of votes as then we are serving people with software we can't even say anyone looked at. Best regards, Attila ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Package promoting
On Wed, Sep 22, 2010 at 1:10 PM, Polyvertex polyver...@gmail.com wrote: Indeed, I own a stuck package :) I am, in a weird way, happy that people are now complaining about packages being stuck for 15 days - as bad as it sounds, there were times where most of the packages spent months in testing without hopes of ever getting promoted. Now, only to get the average closer 10 and all will be dandy ! On a side note - I checked out you package, it already has 3 tester votes, so (unless somebody finds a blocker) it will be unlocked for promotion in about 5 days even if nobody else votes on it (but if they do, you get unlocked as soon as you reach 10 votes). Is there an exit backdoor somewhere ? :) A secret weapon is in the making - KISStester, which would allow easier feedback for users, and it also acts as a REMINDER for people who are using software that is in dire need of testing (the problem is that people *download* things from testing but forget/can't be bothered to come BACK to vote on it). Best regards, Attila ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: MADDE 'developer' account - good or bad?
On Wed, Sep 22, 2010 at 2:35 PM, Ville M. Vainio vivai...@gmail.com wrote: As many of you go, Nokia Qt SDK uses, through MADDE, a special 'developer' account (with it's own home directory) to do stuff on the device That means that it doesn't use the information (databases etc.) stored in the users home directory. I'm gradually starting to feel this is a bad idea, that leads to subtle problems when developers are trying to pretend that they are running their application as default user (and hence have direct access to all the data user has). Discuss :). The danger of messing up your install is probably too high if you did everything as 'user', so while with subtle problems, it is probably still the less dangerous path. Some sort of clone/restore user data to developer account *could* be useful though. Best regards, Attila ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: MADDE 'developer' account - good or bad?
On Wed, Sep 22, 2010 at 2:52 PM, Sivan Greenberg si...@omniqueue.comwrote: On Wed, Sep 22, 2010 at 1:45 PM, Attila Csipa ma...@csipa.in.rs wrote: the less dangerous path. Some sort of clone/restore user data to developer account *could* be useful though. How hard will it be to copy stuff from /home/user to /home/developer and then re-copy it once MADDE test has finished? My guess a mere shell command ? If there are no components that work with hardcoded usernames od uid/gids, that would roughly be it (for files, which are the most common problem IIUC). Services/daemons might get tricky but I suppose that is not a nearly as common scenario. Best regards, Attila ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: MADDE 'developer' account - good or bad?
On Wed, Sep 22, 2010 at 3:13 PM, Ville M. Vainio vivai...@gmail.com wrote: On Wed, Sep 22, 2010 at 3:01 PM, Attila Csipa ma...@csipa.in.rs wrote: If there are no components that work with hardcoded usernames od uid/gids, that would roughly be it (for files, which are the most common problem IIUC). Services/daemons might get tricky but I suppose that is not a nearly as common scenario. One-time copy can also be problematic if you are mutating the data in real time as 'user' while running a program (that is interested in the same data) as 'developer'. This is not an entirely unrealistic use case. Also, developer would be on separate dbus session bus from 'user' (UUIC). Considering all of this, I'm inclined to wish we had a I know what I'm using, please run this app as 'user'| checkbox in Nokia Qt SDK. Hey, I'm always for options :) But the point is that a non-destructive way of playing with data would be nice - with a little tweaking with su and friends you can make it run as 'user' anyway, right ? Best regards, Attila ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Package promoting
On Wed, Sep 22, 2010 at 3:09 PM, Polyvertex polyver...@gmail.com wrote: I think the maintainer should always have the ability to promote the package to extras by himself and take the risk of being under fire from users if he promote a very bad/bugged release and did not took enough time to resolve issues. This may also be added to the Karma system if this is not already done. Generally, that was the setup with the N8x0 and Maemo4.x, so we have tried that - IMO this works better (occasional developer frustration notwithstanding) from a user standpoint, so let's not backpedal on that - do everything to make it simpler for developers, but do not sacrifice users in the process. Reflashing might be trivial for some, but a serious endeavour for others. A secret weapon is in the making - KISStester, which would allow easier feedback for users, and it also acts as a REMINDER for people who are using software that is in dire need of testing (the problem is that people *download* things from testing but forget/can't be bothered to come BACK to vote on it). Well... As both of us said : most of the time, users don't vote. This is why the promoting process is way too constraining : it does not take users behavior into account at all... We'll see the effects when KISStester lands. The point is that ofter people don't even *know* they are downloading the version from extras-testing (since H-A-M does not show that info - and they might have installed it before it was promoted to extras-testing), they are forgetful, etc. So it's not like 99.999% of users don't care, it's just the process that is awkward for most. If we as much as double user response by flashing a 'hey, you have used this app from testing for N days now, care to give some feedback ?' in notifications (or 'you have uninstalled an app from extras-testing, was there something wrong with it ?'), that would already be big help. At that point the biggest concern will be educating people of leaving *good* feedback, but if we have bad results, we can always disable the vote-part and just leave comments - that can be very helpful, too. PS also for feedback - I often see for example problems being reported on talk - that goes to show that people are not comfortable with leaving comments within the testing process, so silence in testing does not necessarily mean all is well (but it does mean the process needs refining). Best regards, Attila ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Package promoting
On Wednesday 22 September 2010 18:15:57 you wrote: 1.Is the application useful? I think the average user is the better equipped to answer this question so getting as many votes/comments from the average community definitely helps. And herein lies the rub - extras-testing has nothing to do with usefulness. For people without the proper background thumbing down or up means little - and it would be a shame for an app to get thumbed down (esp if it's an upgrade for something already in Extras) because the icons aren't pretty enough or because the UI is not snappy or they simply think it is nut 'fun enough'. 2.Is the application safe for the system? Here the average user will not have much to help but I still think that having a bunch of power users report it has bugs, it crashes my system will be a good starting point. 3.What application do I want to install? What new applications are out there that I don't know about? These are questions that other people's reviews would help. Why not have all in one place and make it really easier for the user to give feedback. No compaints here - though it might be worth pointing out that new app != testable app. This is the especially problem when, say, someone uploads to extras-devel and goes to sleep, and then the following morning promotes to extras-testing. The people who installed the app (even if they did check the repo) in the meantime from extras-devel have no clue that they can/should leave feedback for that app. KISStester tries to go around this by matching installed apps with apps listed in the QA queue. I was about to ask what kisstester was. I didn't know there was another http://talk.maemo.org/showthread.php?t=60158 application on the works. But as much as I value the testers job and opinions I think one of the big issues seems to be that the demand is higher than the resources. Also, I can't see why bringing more information to the system can hurt.. It is up to us to decide how that information affects the promotion system but I think as a user I would like to know as much as I can about other people experiences with the applications. Information - yes - that's why we even defaulted the bugtracker link to the testing/package pages, we WANT comments, the careful part starts with the voting. 1.Right now there is not distinction between a new version of the package and the first one. I understand a previous version being approved should not be guarantee for a new release but it got help some. The worst case scenario for me is: one application gets approved on testing but has some big problem. The developer fixes the problem in a matter of minutes but it will take another 10-20 days to have it out there. A simple idea on how to improve is to have someway to communicate to the testers of the previous version about that and they would prioritize reviewing the new version. 2.After you promote a package to extras-testing and before it is approved or rejected you can't promote a new version of the package. When the testing process can take a long time there is a good chance a new version will be available before the last one was voted. I don't pretend to know an answer here but I see a problem: developers will just promote to testing right after uploading to devel to save a place on the queue (defeating the purpose of extras-devel), or they will not promote a new version of their application that supposedly is better than the previous on testing because this will reset the clock. I understand the focus should not be the developer but I think the users will suffer on both cases. I'm with you, this *has* been talked about but we were far from consensus, maybe it will be something worth revisiting. 3.Anything we can do to check for user's privacy vulnerabilities on the QA. Again, I don't have an answer but I think it is potentially more important than things like having 20% of the files here or there. Of course, much more difficult to check for too. Currently we have a generic privacy/security checkpoint, but not sure how/what to check... Suggestions welcome. By no means I want to reduce the merit of the testers but even they will miss what a larger user base would see. I think the testers should be the rejecters and not the approvers. They would be in charge of checking for the minimum set requirements and where the application is a danger to the user. The community would be the positive stimulus . enough good and none bad the application is ready! I would agree on a general note but had bad experience with that - as said, I've seen several (valid) complaints made on talk even though the testing page was mostly empty - that's why I'm hesitant to say 'no/minimal feedback means good feedback'. Best regards, Attila Csipa ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo
Re: Package promoting
On Wed, Sep 22, 2010 at 11:28 PM, Polyvertex polyver...@gmail.com wrote: If I am a lambda user, I just want to get applications on my phone and don't want to spent time for downloading an another application B to note or vote for application A. I personally have no problem with that. I actually even support that - you don't want to test, you don't want to get karma, just plain Apps - cool ! That's still better than mobbing people into voting for apps. If I feel unhappy with the latest application I've downloaded, I just want a simple/unique place to say it to the maintainers and eventually have a voting system to vote for/against a (group of) developer(s) according to the quality of its/their releases, that would make sense here. You have that, but given the way HAM works, lambda users will have difficulties finding it and what you get is a talk thread with a 'Maemo sucks' title. So why such care for 'protecting' the users with an over-powered promoting system which could be naturally regulated by the community itself through a simple voting/Karma system ? Why ? Here is the ... If you want such a perfect QA process, why not building a big Ovi/AppStore, hire some testers and application approval team, and stop saying Maemo.org is an open community ? Hey. That *is* a bit harsh. Ideas are of course always welcome. But just as I feel we don't have the right to do the above, I also feel we don't have the right to shove down updates/apps down the throats of unsuspecting users who are not interested in half-baked software. I mean, Extras-devel IS public and advertised - anybody interested in bleeding edge software can get it there, and that's OK. OTOH There ARE N900 owners who really don't want to reflash every other week and think hunting down processes and broken/oversized packages is not fun - and that's who Extras is for. So there, to each to his own. I would prefer the Maemo.org community to act like a regular open community and let people vote for/against an application *after* it has been released. Thus, only 2 repositories should be enough : 'extras' and 'extras-beta'. I must be missing something - that has nothing to do with community openness, and in fact I'm inclined to say there isn't a single distro that works that way. Imagine Debian said 'ok, everything the devs want to promote gets promoted to stable, and if there are complaints, we'll remove it from the repo'. We kind of had that with Chinook/Diablo. It didn't work, really. We had a lot (LOT) more complaints about borked installs. Best regards, Attila ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: suspendprocess - poor man's power save
On Sun, Sep 19, 2010 at 7:58 PM, Robin Burchell virot...@viroteck.netwrote: Anyway: this was pretty much in keeping with my idea: move it into the task switcher (hildon-desktop/other) so that applications which are moved to background are stopped (unless they signal for whatever reason that they need to be kept running, but I'm not even sure that is necessary: if you really need to do background processing constantly, why do it in a GUI application?) Hey, continue down that path and you'll be in iOS style cooperative-daemon multitasking in no-time :) Which, while not bad in itself, DOES require a substantial level of effort on part of the developer, especially, as mentioned by others, if it's a port using funky event loops. That's why, unlike in the case of iOS I do believe this call is not to be made by *compulsorily* overcomplicated by the OS/daemons in our case. On Sun, Sep 19, 2010 at 1:42 PM, Ville M. Vainio vivai...@gmail.com wrote: It would be more useful if it wasn't a launch wrapper, but rather a lone daemon that sits in the background and suspends a set of processes according to given heuristics (e.g. suspend gpodder when a call is initiated, matched by /proc/NNN/cmdline). This would allow suspend rules to be created for apps outside the packaging/implementation for the app itself. I kinda would say this fits Shepherd's use-case (DBUS suspend/resume event as trigger, SIGSTOP/resume as action), but considering how late I am on that project I better keep quiet :) Best regards, Attila ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: How to install Qt 4.7 in scratchbox
On Wed, Sep 15, 2010 at 12:28 PM, Andre Klapper aklap...@openismus.comwrote: Am Mittwoch, den 15.09.2010, 17:18 +0800 schrieb Jianzhong Li: My environment is latest version scratchbox with Maemo5 SDK rootstrap is http://repository.maemo.org/stable/f...p_5.0_i386.tgz nokia libraries and maemo dev is installed I just want to install Qt 4.7 on it for Qt development, firstly I just get the Qt 4.7 tarball here: http://qt.gitorious.org/+qt-develope.../4.7-fremantle then I configure -maemo5, but errors Don't know if it solves the problem but I'd rather try these packages: http://repository.maemo.org/extras-devel/pool/fremantle/free/q/qt4-experimental/ Seconded, unless you want to develop Qt itself, you should just apt-get install libqt4-experimental-dev and then use the qmake in /opt Best regards, Attila ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Broken packages in Extras repository
On Wednesday 15 September 2010 19:14:19 you wrote: Thank you for your effort. Now we should get python-numpy to Extras repository. It will not happen through normal testing queue because there are no applications directly depending on it in the queue. Is there way to get it promoted or do we have to wait indefinite time to get 10 votes at http://maemo.org/packages/package_instance/view/fremantle_extras-devel_free _armel/python-numpy/1.4.0-1maemo4/ ? May I remind that all pygame application are broken because of this. I will talk to Niels - the need for a fast-track promotion in case of serious breakage or security issues has been noted and even agreed upon, but we never got around to define the actual procedure. For now we only have the deus ex machina kind of solution, so that's what's going to happen here, too. Regarding libsdl-ttf2.0-0 problem, I think that best way would be to recompile all packages depending on it, bump the version number and put to Extras. Currently packages depending on libsdl-ttf2.0-0 are blocked from being promoted, which is fine, but that implies that there is something being done about this. That of course makes me curious of what is it? We got the ball rolling with the people in charge and hopefully the solution will be in place soon. Track progress at: https://bugs.maemo.org/show_bug.cgi?id=10450 Best regards, Attila Csipa ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
suspendprocess - poor man's power save
It has been difficult for many developers to comply with many of the recommended power-saving practices for Maemo, especially those porting apps from desktop environments. I'm not sure how many of you noticed already, but in the best hack-tradition of the N900 mikkov made a suspendprocess package, not unlike what was talked about on this list - which could allow many of these power- guzzling apps to become a little more suspend-power-friendly with little to no effort. http://maemo.org/packages/package_instance/view/fremantle_extras- devel_free_armel/suspendprocess/0.1/ Basically it is a launch-wrapper that SIGSTOPs and resumes the app it started based on the DBUS signals. I would recommend all interested parties to take a look and if it improves/helps in their apps/packages, apply it to them (or report any problems/improvement suggestions, naturally). It's not the prettiest solution and native level DBUS solution is of course still preferred by far, but if you don't have that time or luxury (or are blessed with SDL code or similar), this might come handy. Best regards, Attila Csipa ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Broken packages in Extras repository
2010/9/5 Benoît HERVIER kher...@khertan.net I confirm some still have problem running Vectormine which depends on pygame, which depends on numpy which depends on libsdl-ttf2 :) Libsdl-ttf2, the root of all evil :) Anyway, as said, will poke some people so we have the issue resolved one way or the other (I agree that the status quo is detrimental to the integrity of Extras in this case). Best regards, Attila ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Broken packages in Extras repository
On Sat, Sep 4, 2010 at 5:06 PM, Mikko Vartiainen mvartiai...@gmail.comwrote: First there is issue libsdl-ttf2.0-0 vs. libsdl-ttf2.0 packages. At some point Nokia has included libsdl-ttf2.0 package in SDK and their repositories while Extras already had libsdl-ttf2.0-0 (which I believe to be the correct name because it is used in Debian). These packages are of course conflicting and older packages depend on Extras package and newer on Nokia package. Attila Csipa handled this issue in earlier mail. Extras maintainer has updated his package to a dummy package which depends on Nokia package which fixes the problem. Updated package is found only from extras-devel and it's not going to promoted to Extras with normal procedures in near future so somebody who can should go and promote it.. Unless I'm grossly mistaken, that does not solve the problem. First of all, most apps depending on it do not depend on it as a version, so H-A-M will never update it on it's own, even if the newer version is in Extras. Second, if you already installed, you will not be able to update as the package in the nokia repo has no provides/replaces clause, so apt will fail as it will try to overwrite a file already existing in the package that triggered the upgrade. https://bugs.maemo.org/show_bug.cgi?id=10450 is quite silent so I might need to poke someone (kinda tried that last week, but apparently wasn't adamant enough :) Then there is python-numpy, which seems to be completely unfunctional. import numpy fails after installing it. After installing mypaint numpy seems to work, so python-numpy has broken dependencies. Unfortunately there is updated python-pygame which uses numpy. So import pygame fails too, which breaks all pygame applications (if mypaint is not installed). Pygame automatically tries to use numpy, if it's installed. To fix this situation I think somebody should fix numpy package and fast track promote it to Extras. It doesn't have a bugtracker, so might need maintainer poking... though the issue itself has already been highlighted in the package interface, but that we have more and more python stuff the issue is becoming more and more apparent. Best regards, Attila ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo / MeeGo application gallery?
On Thu, Aug 26, 2010 at 9:35 PM, Ville M. Vainio vivai...@gmail.com wrote: The concept is so obvious, it has probably been discussed to death many times over - Should we have some central place to showcase maemo / meego applications, wherever they are? Well, the original attempt was Maemo Select ( http://maemo.nokia.com/maemo-select/), which basically died from neglect as it was seen as a stepchild by both Ovi and maemo.org, and considering how self-sufficient they are, it seems to me it will be hard for such initiatives to survive on their own... ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: [Testingsquad-list] Stratagus game engine
On Saturday 21 August 2010 20:39:54 Ian Stirling wrote: I've been ignoring these packages. In addition to the above - there are several other packages which won't run meaningfully without external data - game engines, with often no link or mention of where this other data can be found in the package description, or in the UI. It's probably going to be unpopular, but one way of going about this is to make a group out of these packages with a special policy, just as we have them for command line apps. Description mentions are IMHO not the best solution as it's too easy to skip/miss them and then you're left wondering why this stuff doesn't work. My first thought about doing it in the least invasive, but firm and informative manner is to use a bootstrapper/launcher - the actual app would not be started directly, but instead would depend on a (provisional name) external-game-data package (not in a user section) and would be required to start that from the .desktop file. It would also drop two files in /etc/externalgamedata.d/, a packagename.files and a packagename.info, the first containing the paths required, and the second that displays info where these can be obtained from. Then, when the end user launches the app, the launcher checks if the files are present, if yes, cool, launch game, if not, show info dialog which clearly states what goes where. Personally, I would maybe also require game data to be in MyDocs (so users could just drop it via USB), though this might encounter tech problems (due to VFAT limits). Thoughts ? I will gladly make such a launcher in bash if we have a consensus of doing things this way. Best regards, Attila ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
backgrounding/lock QA fail
I see we have a few apps (especially ports and stuff using SDL) that do not know how to suspend themselves and therefore it fails the QA. Now, the problem is that often it is non-trivial to fix/support this, and it's not that easy to point people to the right resources (due to the number of technologies involved). Often the people involved are not the authors, just maintainers, so their understanding of the inner workings/event loops of the apps is rather limited, making things even more difficult. Now, I was thinking, as this sort of bug is a kind of a 'be aware' type, is that maybe we could allow these to pass if they made it clear to the user they are not able to suspend themselves. A popup after install, or a Hildon banner before/during startup... that sort of thing - which is easy to add to existing apps. I agree the best would be to have it done right, but OTOH I would hate to sentence dozens of otherwise functional and polished apps to extras-devel just because of this. Thoughts ? Best regards, Attila ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Fwd: backgrounding/lock QA fail
On Mon, Aug 16, 2010 at 12:15 PM, Aapo Rantalainen aapo.rantalai...@gmail.com wrote: I see we have a few apps (especially ports and stuff using SDL) that do not know how to suspend themselves and therefore it fails the QA. Now, the problem is that often it is non-trivial to fix/support this, and it's not that easy to point people to the right resources (due to the number of technologies involved). Often the people involved are not the authors, just maintainers, so their understanding of the inner workings/event loops of the apps is rather limited, making things even more difficult. Does it mean original writer is using SDL wrongly? Is this suspend-issue something that (all) upstream should be informed and should they fix it? (Is this relating overall power usage and 'green-computing'?) Sadly I don’t know SDL at all, but it is clear that this has nothing to do with upstream - on the desktop, there is no ’rule’ that apps should pause or stop if they lose focus or another app claims focus (like often in our case the phone app or IM), it is even customary to use a button press to pause. On top of that, the mechanism for detecting this (going to background, screen turning off, lock button pressed) would be Maemo specific so would likely never go upstream anyway. Best regards, Attila ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: backgrounding/lock QA fail
On Monday 16 August 2010 12:43:02 Andrew Flegg wrote: 1) A daemon which applications could register their process ID with, when the display locks they would be forcefully SIGSTOPped. Even with that premise, I'd go for super-simple - like using dpkg triggers. The packages in question would pre-depend on the daemon package and the trigger would register them. Then on lock/sleep/etc the daemon would enter berserk mode and stop/kill anything that it received as a trigger. The advantage of such an approach that nothing in code of the app needs to change, it's all solved on packaging level (unless your actual executable is not the one in the .desktop file, in which case you could drop something in postinst). I think there is a gap for a wiki page on saving power, though; which talks about the two main mechanisms for *most* apps: the OSSO DBus signal for display blanking/locking and the Gtk+ signal for the window going into the background. Hey, I agree, I just think that there are a lot of cases when porters/maintainers simply lack the insight or time to do such a level of integration. I would prefer they pass on an acceptable solution than have them fail on the ideal solution. Best regards, Attila ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
libsdl-ttf2.0(-0) ?
Can someone help me with this package ? It seems that we have a libsdl- ttf2.0-0 in Extras (listing the pymaemo team as maintainers), but also a libsdl-ttf2.0 in the Nokia repositories (listing Karoliina Salminen of Nokia as the maintainer). As suggested starting with libqt4, no stable official Nokia maintained packages should go to Extras, and those that are devel versions, should explicitly sport an -experimental in their package names. The transitional package might sound as a good idea, but due to how H-A-M works, and given that libs are mostly promoted via apps, it fails miserably in practice (i.e. you get conflicts all over the place). The proper way to deal with this would be IMHO to add the standard provides/replaces/conflicts stanza to the new package and just delete the ones in Extras. If you know about other packages that have the same problem, please let me know (so we could deal with it before apps using these libs reach Extras, like in this case). PS. ... and this is why I say we need to have better comms/procedures as to what stuff is moving where across Nokia/community repos :) Best regards, Attila ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Dealing with fcam-drivers and different kernels
On Monday 02 August 2010 20:38:11 Eino-Ville Talvala wrote: With the idea that fcam-drivers is preferred since it's a real package, and fcam-power-drivers only used in case fcam-drivers conflicts? Any advice would be appreciated! Off the top of my head, I would do something like: fcam-stock-drivers: Provides: fcam-drivers Conflicts: kernel-power, fcam-drivers Replaces: fcam-drivers fcam-power-drivers: Provides: fcam-drivers Depends: kernel-power (= exact-version) Conflicts: fcam-drivers Replaces: fcam-drivers Then FCam applications would use: Depends: fcam-drivers In plain English - make fcam-drivers a virtual package and indicate with Replaces: what package needs to be considered for removal in case of a conflict. Why depend on the flasher ? You can have kernel-power without the flasher. I think it is wrong (but probably safer) that kernel-power does not conflict with kernel. Also, I would be adding some versioning to the kernels as doing modules without depending on EXACT versions of kernels is just asking for trouble (for stock you can count it to be stable between PRs, but kernel- power can change fairly often, with no guarantee of compatibility). And last but least - if you can get the maintainer of kernel-power to include your modules, that would be the simplest solution of them all, then you would have fcam-drivers as is, but kernel-power would have to incorporate: Provides: fcam-drivers Replaces: fcam-drivers Conflicts: fcam-drivers Best regards, Attila ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: libqtm-dev dependency
On Friday 06 August 2010 01:19:55 Robin Burchell wrote: Is there any reason why libqtm-dev doesn't deppend on libqtm-sensors? Why would it? libqtm-dev is a headers package for the whole of Qt Mobility for applications to build against, libqtm-sensors is a binary package of the mobility sensors framework. This is also consistent with how Qt itself is packaged pretty much everywhere: libqt4-dev vs libqt4-core, libqt4-gui, ... Without having the qtm packages at hand, talking in general: the -dev package should depend on the actual lib (libqt4-dev actually does this as the OP says), as otherwise you wouldn't be able to link against it (just compile). Regards, Attila ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Open letter of support for Python on the Maemo/MeeGo platform
Forwarded from the Maemo Community Council blog: After receiving feedback from the community, including developers who are trying to get their software into Ovi Store, it is the opinion of the Council that the unexplained restriction on dependencies between Ovi and Extras - and in particular the availability of Python as a platform for Ovi Store applications - represents a serious threat to the success of Maemo, MeeGo and Ovi Store. It will come as a surprise for many community members and users that Python is still not an officially supported language/runtime on the Maemo nor MeeGo platforms, despite the huge number of Python applications currently in Extras, and even though they base on the work of Nokia's own PyMaemo team, plus two Qt bindings and a GTK+/Hildon one. To put things in perspective, about a third of ALL stable Maemo applications are written in Python, both overall and those using Qt. The community level support means Python itself is located in community repositories, and, as a consequence, Python software is not admissible to Ovi (regardless of being free or not). Highlighting this is part of a broader agenda - ensuring cooperation between libraries and runtimes used by Ovi- distributed software and software in community repositories, but the first step towards that is addressing the single biggest such case - Python. If there are technical issues which need to be addressed, let's discuss them in the open and try and solve them; if there are purely political issues, we strongly urge Nokia to reconsider. Maemo Community Council Blog/vote link: http://maemo.org/community/council/open_letter_of_support_for_python_on_the_maemo- meego_platform/ Talk auto-announcement link: http://talk.maemo.org/showthread.php?t=59745 Regards, Attila ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Web Runtime in extras-devel
Just to let people know, our Nokian friends uploaded a new iteration of the Web Runtime preview to extras-devel. There is a slight change in the nomenclature, though, as we (maemo.org) requested an -experimental tag added to the package name, to avoid later clashes with potential official packages (like we had in the case of Qt packages). Special thanks to Xizhi for following this through. I suggest those that already installed the WRT, or depend on it, to replace their packages with the new ones. To avoid confusion, the old packages are in the process of being deleted from the repositories. Thanks for your attention and to everyone who made this possible. Best regards, Attila ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: How to to manually package Qt Mobility?
On Wednesday 21 July 2010 17:10:11 Attila Csipa wrote: (in fact, it would be cool to see what *exactly* the Qt Ovi QA requirements are, not just generic descriptions - if someone has a link, I'd be grateful). FWIW, I got a link: http://blogs.forum.nokia.com/blog/ovi-publisher-alert/2010/08/02/qt-content-qa and the relevant section: Q: Can Qt Mobility APIs be used to create applications for Ovi Store? A: Qt Mobility can be used with applications for Symbian devices. For N900, Qt Mobilty is not officially supported yet so we cannot accept applications that use Qt Mobility. Regards, Attila ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Extras QA checklist
On Tuesday 27 July 2010 17:30:13 Eero Tamminen wrote: I just bumped in bugs.maemo.org into an issue resulting from the bg activity by gPodder and some other apps. Still, what Extras QA, as a crowdsourced effort can do in that regard is rather limited. The number of people who are able to do such checks is very very low. I know it sounds scary to QA engineer ears, but the best we can offer is a sort of it's not apparent it's leaking. This again leads back the the extras- testing-is-not-a-proper-QA-just-a-quick-check-for-obvious-showstoppers discussion, but I digress... Regards, Attila ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Please update QtMobility distributed with Nokia SDK to 1.0.2
On Tuesday 27 July 2010 23:41:07 Andrea Grandi wrote: after you have updated QtMobility packages to 1.0.2 in official Maemo repositories, you should update also the version distributed with Nokia SDK. We're also eagerly awaiting the libqtm-experimental-* v1.1 packages :) Regards, Attila ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo QA process
On Thursday 22 July 2010 02:35:47 Ian Stirling wrote: Note that since not long ago we also have super-testers, people with proven track records, it's enough to get three of their votes if your package is stuck and you're good to go. Where is the super-testers list? I've tested a few apps - though I need to get back into the pile of apps. We have no separate list for the super-testers, we (ab)use the testing-squad list[0] for those purposes. For more deails on the super-testers, see https://garage.maemo.org/pipermail/testingsquad-list/2010-July/89.html [0] https://garage.maemo.org/mail/?group_id=1273 Regards, Attila ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: How to resolve network connectivity without using Qt Mobility in Qt?
On Thursday 22 July 2010 10:40:51 Ville M. Vainio wrote: As it appears, rabbit hole goes deeper than initially expected, so don't hold your breath on getting the issue fixed in reasonable timeframe :-/. Just as a side-note - can we work on making at least the Ovi QA criteria public so that we do not get minefield issues like this one ? I understand Maemo5 is fairly new and small in the Ovi story, but it would greatly help if we could see the criteria - in the worst case, adapt to it without wasting any more time than necessary, and in the best case, working with Ovi/Nokia to improve the process to the benefit of all involved parties (seeing Nokians jump in this discussions helping clarify the issue is always a plus). As it is now, the Ovi publishing guide has a meager one-liner about publishing Qt apps and that one point to a (Maemo/MeeGo-wise) not too descriptive page on Forum Nokia. I would even attach my community stamp to this if needed - even though this is largely related to commercial apps, the question of QA (and through it any potential Extras-Ovi cooperation, as dreamy as that may sound) and general app availabilty is something that touches on the community as a whole. Best regards, Attila ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo QA process
On Thursday 22 July 2010 00:19:20 Felipe Crochik wrote: I added a message to the download assistant thread but never received a reply. http://talk.maemo.org/showpost.php?p=717824postcount=17 Maybe someone knows the maintainer or what is behind the scenes and can find out if it is a viable solution or not. AFAIK that effort is done by Daniel Wilms on a community basis. I wanted to chip in to that project myself, but am severy limited on time :( Regards, Attila ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: How to to manually package Qt Mobility?
On Wednesday 21 July 2010 08:13:27 Marius Vollmer wrote: ext Sascha Mäkelä sascha.mak...@gmail.com writes: OK. If Ovi Store for paid apps is no using a repository, then what about using preinst script or something to install the dependencies? You unfortunately can't run dpkg recursively and thus can't install packages from maintainer scripts. I have no good ideas, sorry. It's probably not a good idea but you can work around the issue like the Qt smart installer does - omit any non-base firmware dependencies, and use a loader. That way the install will succeed, and then via the loader you can apt-get/application-manager install whatever you need on the first run of the application. It's a horrible hack (and probably breaks a dozen Ovi rules and common sense along the way), but it might work. Regards, Attila ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: How to to manually package Qt Mobility?
On Wednesday 21 July 2010 16:52:16 you wrote: This means application won't work without having connection after installation and I guess Qvi Store QA is good enough to find that and reject the application. Moreover, you would need root permissions to ? Requiring network connectivity on it's own cannot be a disqualifying cause. That would mean you could not publish even a twitter client. install additional packages, so apparently there is need to modify sudoers settings, which may be seen as security breakage. If all these succeed I would be surprised. Again, there is a huge number of uses that might legitimately require sudoer functionality (like for example for handling low-level network related things, think Joikuspot, WiFi-Eye, etc). IMHO the only rejection clause might be policy violation, not a technical one - unless 'non-cludgy' and 'non-hacky' are official technical criteria :) (in fact, it would be cool to see what *exactly* the Qt Ovi QA requirements are, not just generic descriptions - if someone has a link, I'd be grateful). In some super-fantasy scenario, Extras and Ovi should have fairly overlapping QA criteria. Best regards, Attila ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo QA process
On Wednesday 21 July 2010 22:53:43 Roman Morawek wrote: P.S.: You are welcome to evaluate and vote on my package: Indeed, the best strategy for developers is to lobby a bit for their application. Open a thread on talk.maemo.org . Blog about it. Write to the list. I hope the fellow devs won't take this the wrong way, but... this aspect is actually a feature, not a bug, as it encourages discussion and interaction/community building, not the fully disconnected 'dump in extras' and 'download moar apps' approach. Obviously being delayed for months is very bad, so we're constantly exploring ways to improve the process, but... Maybe an automatic promotion after 4 weeks would make sense, given its actual package karma is positive? ...the problem with automatic promotion is that then we don't really have any guarantee that what gets to stable has actually been tested - and the testing should be at least as much about protecting users from obvious faults as providing feedback to developers. If we enable automatic promotion, that actually might discourage testing due to the 'why bother, its going to get to Extras anyway' factor. Note that since not long ago we also have super-testers, people with proven track records, it's enough to get three of their votes if your package is stuck and you're good to go. I personally see my program as very useful - well, otherwise I wouldn't have spent the time for development. I assume that just nobody is aware of it, since everybody just looks at the available programs in extras. Even now the problem is not that people are not finding the app, the download number tells apps in testing have thousands of downloads - it's the feedback that is missing, IMO for two reasons: one, users not accustomed to give feedback, and two, the unavailability to give feedback EASILY. This is being worked on, but progress is slow, sadly. Ideas (but preferably hands) are welcome on improving the process. PS. And the part I dont understand: we have 25+ apps that are unlocked and not being promoted by their respective authors. Orphans ? ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Extras-devel cleanup?
On Mon, Jun 14, 2010 at 10:27 PM, Ville M. Vainio vivai...@gmail.comwrote: Some time ago there was talk about removing the old junk from extras-devel, in order to make app manager faster. What happened to that idea? Do we still have hope of this happening? It’s already happening automatically, it’s just that we DO have a lot of packages now, even without the old ones. To see the old version purging in action see for example the history of http://maemo.org/packages/view/conboy/. The apt dir also got moved to /opt, which probably slowed it down a bit in exchange for a lot more space or the rootfs. And last, but not least, the extras-devel Packages file is a solid 14MB nowadays (curse them icons !), which takes time to get parsed/processed/updated no mater how you slice it. Best regards, Attila ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Qt Autorotation
On Wednesday 26 May 2010 17:21:42 Felipe Crochik wrote: The WA_Maemo5AutoOrientation only tells the device that you want this application to autorotate but the user still needs to press the shortcut (I have the worst time with my fat fingers) to activate/deactivate it. And IIUC the two are unrelated. CTRL-SHIFT-R is forced autorotation provided by the system, WA_Maemo5AutoOrientation is a Qt option enabling the application to deal with it itself. There might be some 'remembering' involved though as some applications seem to remember it (like mail and conversations - might be caused by the fact that they never really quit, though). Regards, Attila ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Qt SDK beta, N900 PR1.2 and qt-mobility-examples
On Wednesday 26 May 2010 19:04:49 Paul Hartman wrote: Now that we've got PR1.2 for N900, I'm trying to follow the instructions for the Qt SDK beta release in the Maemo readme file included with it. It says to install qt-mobility-examples but it appears to have been removed from the repository yesterday. http://maemo.org/packages/view/qt-mobility-examples/ Is that package no longer needed, or should I wait for its reappearance before trying to proceed? There is a major package shuffle underway that touches on many Qt related things (like QtMobility), see http://achipa.blogspot.com/2010/04/operation-qt- shuffle.html for details. Long story short, stable qtmobility packages for Qt4.6 will move to Nokia repositories, and extras-devel will host only the dev version of qtmobility for Qt4.7 (sporting the experimental moniker in the package name). Regards, Attila ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Qt SDK beta, N900 PR1.2 and qt-mobility-examples
On Wednesday 26 May 2010 20:14:22 Andrea Grandi wrote: But why transition could not be smooth? Why not to wait with removal before package is really available in Fremantle repository? I see it as an act of disrespect towards the community. not only for the community, but for developers too! I'm going to develop a Qt application that needs QtMobility package and wtf?! I've to wait because QtMobility package just disappeared? I'm very disappointed about this change. Fail imho. I don't know the details (according to The Plan they should have been removed only after they appear in the Nokia repos). I'll check up on QtMobility's availability. I'm personally trying to coordinate efforts as community representative to make the transition as smooth as possible (a.k.a. if you only knew), so rest assured, there is certainly no disrespect and we're all aware of the issues and working on this, maemo.org staff, Nokia folks, Council members, even distantly related Debian people (special thanks to people in the above groups putting up with me and my constant nagging about these issues). Also, it has been mentioned several times, but let me reiterate in case someone missed it: libqt4-maemo5-* PACKAGES ARE OFFICIALLY DEPRECATED ...as announced about a month ago (ditto for things depending on them). Developers working with Qt4.6 should use the libqt4-* packages (as shipped in PR1.2) EVEN IF THEY DO NOT WISH TO PROMOTE THEM. Nokians will upload libqt4- experimental-* packages (containing Qt4.7) to extras-devel shortly, which will serve the development purposes. libqt4-maemo5-* naming is causing serious repository/promotion/confusion issues so these packages WILL BE REMOVED at some point in the not too distant future. Regards, Attila ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Qt SDK beta, N900 PR1.2 and qt-mobility-examples
On Wednesday 26 May 2010 22:15:15 Antonio Aloisio wrote: Calm down! Mobility packages for scratchbox are in Tools and the pkgs for the device are in Nokia Application repositories. Both are enabled by default, developers and users don't need to add them. Ah, there you go, nothing better than an answer already present in the mailbox when one presses send :) Regards, Attila ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Non-experimental QT versioning in Autobuilder (was: QT Packages, Repositories and PR1.2)
On Sun, May 23, 2010 at 6:25 PM, Javier S. Pedro ma...@javispedro.com wrote: 3. Qt Desktop guarantees that an application built under Qt 4.5 headers is binary compatible with Qt 4.6 libs. I'd like to know if we can guarantee that an application built under Qt 4.6 headers but using no Qt 4.5 introduced APIs would work under Qt 4.5 libs. This cannot be guaranteed. A single #ifdef can break such a setup, and these things might not be apparent at first (as some of the changes involve property names and values, so might even compile with the wrong version, but will simply not work as desired - the most common case exhibiting this problem IMO being finger scrolling, for example). Regards, Attila ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: QT Packages, Repositories and PR1.2
On Friday 21 May 2010 07:06:35 Ville M. Vainio wrote: On Fri, May 21, 2010 at 2:42 AM, Felipe Crochik fel...@crochik.com wrote: As today what a developer needs to do to get an application that uses qt to the end user? Is there a way to tell the autobuilder to compile against the 4.5 qt and make the package only depend on it? The developer should wait for pr 1.2. At this point in time all the work spent on dealing with PR1.1 is wasted effort. The rationale of working out scenarios is to have a course of action if a similar situation arises (not necessarily with Qt or another PR). As I mentioned previously, I agree with Niels that this is more a packaging than a PR1.1/1.2 (delay) issue, PR1.2 will just make the symptoms temporarily go away. In other words, do not bother with PR1.1 but bother with how you package your packages :) Best regards, Attila ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: QT Packages, Repositories and PR1.2
On Friday 21 May 2010 01:42:43 you wrote: 1.As today what a developer needs to do to get an application that uses qt to the end user? Is there a way to tell the autobuilder to compile against the 4.5 qt and make the package only depend on it? In theory you just depend on the proper version of libqt4-dev, but it's tricky as you might indirectly reference libs that are also newer in the SDK/new PR so end up with a 4.6 dependency (or broken build), see below... 2.What is the point of the (not so few) qt applications on the repository that were compiled against the qt4-core (4.6)? Unless pr1.2 will have a qt that is binary compatible to the libs on the autobuilder right now these packages will be completely useless, right? I thought the point of committing packages using qt4-core (4.6) now was to have them ready for day one when pr 1.2. gets out. Most of the applications got compiled for Qt4.6 'by accident', in terms that they do not really depend on or need 4.6 (nor did the original author WANT that specific version), but with current SDK setup they end up being linked against 4.6 anyway. This is why in my previous post I said this is not strictly a PR1.1 problem, a similar situation might arise with other packages if not managed correctly. 3.The qt applications not using qt4-maemo5 are moved to testing. How are they being tested right now? They can't be tested on the pr1.1, because they are compiled against qt 4.6. Are they not being tested at all (everything is at halt); or they are being tested by people that have pre release pr1.2; or are they being tested using scratchbox environment? AFAIK it's halted. Considering PR1.2 uses a separate repo, it makes no sense to promote them (yet) anyway. I would not consider prerelease 1.2 as a valid platform for community QA purposes. Thanks for taking the time to answer me. It has been very interesting and illuminating Hate to be the bearer of bad news :( What we managed to agree for the PR1.2 release is that development releases starting with PR1.2 will not be called libqt4-maemo5 as it's not that obvious that it's *really* just a version for testing, prone to breakage and not necessarily the exact one that will end up in the next PR. Future releases will sport the 'experimental' moniker (f.e. libqt4-experimental, python-qt4-experimental) so it's more clear that it (and stuff depending on it) are not meant to be promoted to end users. Not ideal, but hopefully will reduce confusion until a better solution is found that is acceptable for both Nokia and the community. Regards, Attila ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Qt SDK + Qt + scratchbox?
On Friday 21 May 2010 15:26:01 Felipe Crochik wrote: I actually find the Xephyr/Scratchbox/x86 phase helpful during the development. I like being able to just test the changes on a window on my desktop instead of having to get the device. Do you know if it is possible/easy to setup Qt SDK to compile using scratchbox/x86 and launch the application on Xephyr? It might be easier to just use VNC and copy/start the app via ssh. Not perfect, but for me it will do until we get PR1.2, and is IMHO less fuss than scratchbox. Regards, Attila ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: QT Packages, Repositories and PR1.2
Foreword: the Qt versioning mismatch problem is not strictly the consequence of the PR1.2 delay, it is mainly the result of the packaging choice of how Qt gets updated to newer versions. On Thursday 20 May 2010 15:26:46 Felipe Crochik wrote: - If you use the old standard 4.5.3 packages you can't use the new 4.6 features including the maemo5 lib. - If you use the new standard 4.6 packages the users won't be able to install on their devices because they won't have the qt 4.6 until PR 1.2 is out. - If you use qt4-maemo5 packages your application will be blocked from moving to testing and we will have to submit new packages once PR1.2 is out. Am I correct on this summary? Correct. 1.What happens if two people submit packages with the same name to the extras-development? If they have literally the same same/versioning scheme, the second one will be rejected. 2.What happens if a package with the same name exists on different repositories? The highest versioned one will get installed. If the versions are the same, it shouldn't matter which one are you downloading from (i.e. if it matters, the situation is FUBAR anyway). 3.any other reason (legal, technical, ..) why one of us can't submit the deb files to extras-devel? Would/could we upload them as non-free to make easier? Extras-devel is not just a repository, it's a whole infrastructure. Using the autobuilder ensures adherence to certain standards, handling of source packages, the 'rebuildability', promotion, etc. Regards, Attila ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: QT Packages, Repositories and PR1.2
On Thu, May 20, 2010 at 6:10 PM, Felipe Crochik fel...@crochik.com wrote: I thought the only difference was on where the libraries got installed. Isn't it? On a follow up question: Why do the Qt applications have to know where the qt libraries are? Wouldn't be better/easier if they would look for the libraries first on the starting folder and then on the path or, at least, the path on a system variable like QT_PATH? Hopefully my question is not too dumb or the answer too obvious... :) Don’t forget that the incoming Qt version is NOT binary (nor source) compatible, so you cannot just swap in new libs, you HAVE to use it with the libs it was compiled with. Another requirement was parallel installs (very atypical for Qt, as on desktops it IS generally binary backward compatible). Isn't it a problem that someone can deploy a package with the same name of existing one maintained by someone else? I would think that it get very ugly if someone, even by mistake, put a new package on the repository that replaces an existing library... Let's say by mistake I come up with a package that is called libqt4-core with a version 4.7 and it is not remotely related to qt, wouldn't it break all the applications that depend on qt? I understand that probably such package would never make to the extras (someone would stop it on testing or development) but still seems a little too fragile and I assume a lot of users have the development catalog on and would not have how to know that was not a valid update. AFAIK Packages present in the SDK or the core distribution are not uploadable to extras-devel. The case you mention is possible only for user packages, and we had no precedent for that (in fact, we had cases where people took over orphaned packages). That being said isn't there an opportunity here for us to submit the qt source code to be compiled using what will be the pr 1.2 location, package name and version? Or even simpler upload the existing scratchbox deb files? Please let me know if I am missing something obvious here, I just haven't found why this could be a bad move... It seems a much better/safer solution than for instance adding the nokia sdk catalog like was suggested on the talk.maemo.org (http://talk.maemo.org/showthread.php?t=52442). Nokia (the Trolltech people to be more precise) are the maintainers of the Qt packages. I think it is a very bad idea to undertake public partisan actions with their packages without the consent of the maintainers (though it’s not illegal Qt being GPL and all). If anything, we should work together to find acceptable solutions to everyone. Right now we have several applications that can't be installed because they were linked to the qt4-core 4.6 packages and we have a bunch of applications that will not follow the testing cycle and will have to be replaced just because their developers want to make them available to the current n900 and not have to wait for pr 1.2 But what would that solve ? The moment you have PR1.2 released, the devel version of Qt will move to 4.7 (you can already download Qt4.7 packages from qtlabs that replace libqt4-maemo5). All the cool kids will start coding with 4.7 features and you’ll have the same situation. There will be always a ’next’ version devel people play with and end users drool for. Our ’real’ problem is that of Qt *4.5, the current stable version*, meaning you cannot push 4.5 apps to testing/extras. 4.6 is still unreleased and unsupported as far as Fremantle goes (that is why the whole PR1.2 SDK thing is irrelevant - you can still build Qt4.5 apps, no changes there). The fact that 4.6 is vastly superior for developing Fremantle friendly apps is a different matter entirely. A different idea, probably even harder, would be to have lift the restrictions on the qt4-maemo5 packages and once pr 1.2 is out have the autobuilder recompile them after updating the references to the new qt libraries. The packages are not just renamed, but also build-bumped, so there is no compatibility guarantee (plus, the path magic you would have to do would make things very error prone). The current situation is frustrating to developers and even more to users. I can't imagine I am alone on this and would hate to see something that we can fix affect new applications being developed/ported to the n900 and/or scaring users away by not letting them get the applications they want. We’re perfectly aware of this and agree that the situation is ’less than ideal’ (talk about euphemism), but, to repeat myself, jumping over system components without maintainer cooperation is NOT a good idea, either technically or community-wise. Best regards, Attila ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: QT Packages, Repositories and PR1.2
On 5/20/10, Felipe Crochik fel...@crochik.comh/1tqlt06b4so7k/?v=bcs=whto=fel...@crochik.com wrote: Isn't the Qt version on PR 1.2 supposed to be 4.6.2 (the same we have on qt4-maemo5 and scratchbox right now)? I can't remember where I read this but No way of knowing until PR1.2 actually hits the streets. The version in the SDK *is* newer than the libqt4-maemo5 one (note - it is the same base qt version, 4.6.2, but contains additional fixes/changes). Note that the PR might touch on other things, too - for example the 4.6 on PR1.1 does not support autorotation, has hildon banner coloring issues, etc. So there are things that work or look differently even with the same Qt version. package but I would feel better if it was not as simple as submitting a new package with the same name and higher version. Maybe a consent from the maintainer or at least a put package on hold for few days waiting for a reply (or lack of) from the maintainer to an email sent automatically from maemo informing of the change. As now, It all can happen too quickly, in less than a day someone can submit a package and this package will be available to the users that have the development catalog. Just my paranoid self talking... As the community grows it may become more important. I will talk about this to maemo.org people to see what the options are. The issue is not developing for an upcoming version. We will always have the scenario where there is a stable/official version and a upcoming one. Right now we have the qt4-core (4.5) and the qt4-maemo5 (4.6) in two different folders... Everything would be fine if the qt packages included with pr1.2 were the qt4-maemo5 once out they would simply replace the beta ones I may be too naive but I think all this could be much simpler if we just had each official/major release of qt as a different package and installed to a different folder. Developers would be able to control the application dependencies. In fact that is exactly what I think my suggestion would do now. Now we're gettingto the crux of the matter. The choice is not to support all versions of Qt simultaneously, but to have a single base version for each PR, and have this version on the NAND for speed reasons IIUC (plus integration issues as mentioned above) - and also to lower memory footprint, having GTK+ and Qt simultanously is stressful enough, having multiple versions of Qt in memory would make things even worse. So you won't have Qt4.5 on PR1.2, no Qt4.6 in the PR that will hopefully bring us Qt4.7, etc. The devel version is there just for, well, development and testing. As you can see this significantly lowers our maemo.org maneuvering space, too... Best regards, Attila ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Stats at Maemo repository
On Monday 17 May 2010 09:11:01 Andrew Flegg wrote: On Mon, May 17, 2010 at 08:06, Thomas Schmidt tschm...@debian.org wrote: Am Montag, den 17.05.2010, 00:38 +0300 schrieb Adrian Yanes: I was thinking in the last weeks, to implement some mechanism/system to have stats of Maemo Repositories. IMHO it would be way more useful to only list unique packages, because your numbers seem to include all package versions ever uploaded to extras. (Old versions of packages are still not removed from the package indexes afaik.) Another suggestion: separate out packages in Section: user/... from the others so we can see how many user-facing packages are there. You might not be aware, but AppWatch keeps a database of the number and version of packages (plus a separate stat for user/... section). It also has a history of nearly every package in Fremantle and Diablo repositories. This database has not yet been documented or advertised publicly, just used by AppWatch itself, but still it's there and free to use if there is interest. Regards, Attila ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Stats at Maemo repository
On Monday 17 May 2010 14:36:02 Adrian Yanes wrote: A dump of this database will be useful for me and I guess that for someone else. Could be it possible? If you are tracking this numbers for a long time, maybe we can find some interesting numbers there. Sent (it's a bit biggish and waay ugly to consider putting it in a public place, but will send the link to interested parties). I was hoping to be able to fold my own little operation into the maemo.org framework and hook up with danielwilms' extras assistant/appdownloader at some point so I don't need to scrape that data manually, but sadly I lost track of the maemo.org RESTful progress so I have no idea where that stands. Regards, Attila ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: pyqt localization
On Tuesday 11 May 2010 16:14:38 SC wrote: Can someone please provide some basic pyqt localization examples or point me to some? I know I can use the tr(...) method but where should the actual translations be kept? See http://doc.trolltech.com/4.6/qtranslator.html for details (it works the same way under both C++ and Python). Regards, Attila ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
autobuilder (non) optification ?
Did anyone have problems with autobuilder optification lately ? On user request, I have just dropped 'auto' into the debian/optify file as usual to some of the bigger packages, but to my surprise the package went through the autobuilder unoptified. Niels gave it a cursory look and apparently there is nothing wrong with the package (except for a botched timestamp which should have no effect on optification), so it's a bit of a puzzle as to what happened here. A source package demonstrating the problem: http://maemo.org/packages/source/view/fremantle_extras- devel_free_source/abiword/2.8.1-2/ Any ideas or similar experiences ? Regards, Attila ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Qt packaging changes in maemo.org extras-devel
[Maemo community council hat] One of the big changes PR1.2 brought us is official Qt support in the form of Q4.6 in the Nokia SDK and repositories. This change affects all applications depending on Qt currently in extras-devel. We had some talks with Qt/Nokia folks about Qt-related repository changes in Maemo 5 (triggered by aforementioned PR1.2 and potentially again later on by updates to Qt or related components). Here is the short summary: 1. remove qt4-maemo5 (4.6) after PR1.2 2. upload Qt 4.7 snapshots as qt4-experimental to extras-devel afterwards 3. as soon as 4.6 QtMobility is released, get those packages to the nokia-apps repository 4. remove 4.6 QtMobility from extras-devel 5. maybe upload new QtMobility packages to extras-devel, but only for qt4-experimental (4.7) and with 'experimental' in the package name 6. maintainers of bindings and extensions to Qt are encouraged to follow the same nomenclature in their package names (i.e. using experimental in the name if depending on qt4-experimental) 7. use a Provides/Replaces/etc libqt4-maemo5 clause in the qt4-experimental packages (Qt4.7 packages should be binary compatible with the current 4.6 ones) so the packages can be deprecated peacefully 8. QML/declarative will be released as part of Qt4.7 (so qt4-experimental only, no 4.6.2/PR1.2 support) Have a nice day ! [/Maemo community council hat] Attila ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Ask for removal of some packages from Extras Fremantle repository
On Monday 29 March 2010 08:07:06 Marius Vollmer wrote: all the good stuff in them, because they know that these repositories are well-maintained and backed by a community: packages are not abandoned, and they can expect them to be updated when necessary. Yes, we have not talked about this much but if you take a look at the gronmayer list now, you'll see that a good chunk of repos there has shut down, taking into oblivion their packages, too, and to make things worse, they nearly all miss the source section (most likely an unintentional oversight). Also, consider that the QA/testing process we have is a 'light' (and occasionally buggy ;) version of what happens in large distros (i.e. if you have trouble complying with Maemo's requirements, Debian stable compliance is lightyears away). The historical distros have all been through this phase of 'zillion packages from all over the net' and evolved towards centralized repositories for a reason (while keeping the *ability* to install whatever you want). I still think (and will lobby for) maemo.org supported PPAs as a recommended (not forced !) solution for testing/devel/procedural problems, instead of general repository anarchy. Regards, Attila ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Ask for removal of some packages from Extras Fremantle repository
On Monday 29 March 2010 13:13:14 you wrote: With the current state of extras-devel, long term availability is hardly a point that should be raised against other repositories. At least the source is available. I feel this is more to the fact that very few people use 3rd party repositories and they don't have real any place to voice their problems or repo breakage (except for the gronmeyer site itself, but that's not problem solving, just repo list sanitizing). Remember how we lost Ruby on Maemo ? The distros you compare have a lot of packagers who go through the QA process, not the developers. Maemo, on the other hand, has very few people who take other people's program and package them. Thus, you expect the developers to go through the QA process themselves, so this comparison is not really valid. So instead of finding people to help with maintainership, packaging and/or the QA process, we just ditch the whole thing and go packaging guerilla ? That's a move of convenience at best, hardly a solution (especially for end-users). Regards, Attila ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: maemo-developers Digest, Vol 59, Issue 25
On Thursday 25 March 2010 20:34:40 Urho Konttori wrote: I would propose the following as the first step to improve the support for the community developers: if a component X has been successfully promoted to extras once, when there is an update from the same developer for this component, it will gain the access to enter extras automatically (so, developer still needs to press the magic button). This is to make it somewhat sane to do updates of the apps as well as to have testing concentrate on the new content and not have to test ukeyboard kb layouts for the 10th time in the month because some key had been moved to different position in arabic vkb (I like far fetched examples, a build fault in me). Indeed, the initial effort was a lot more idealistic, but then pragmatism is catching up with us, slowly but surely :) There is already a suggestion in-place for 'fast promoting' things, but that is still not the real deal. Since there is no really universal versioning nomenclature, the 'complicated way' of doing this is to have a simple radio button element for promoting things to testing which would signalize what the new package is. If it's is just a bugfix update (an answer maybe to issues raised previously for the very same package), it would perhaps make sense to avoid resetting karma and the quarantine clock. If it's a minor update, it could mean (a possibly shorter?) quarantine, but certainly a more lax karma requirement. Or, if declared as a major update, it would be treated as such. There is a significant question of how to minimize potential abuse (whether as attempts to 'game the system' or simply because of frustration due to lack of active testers). Not presenting this as a definite solution, of course, just a general idea, the topic obviously needs further discussion. All security comments are insane in my opinion. If some person really wants to be evil, there is nothing in our process that would block that except by accident. I would rather say that it's more of a formulation issue. It would be more correct to say that a *known* or *detected* security flaw is a blocker. Passing Extras-testing is not equivalent to a security audit - it just means there is no glaring security issue known at the time. I can't say I would be happy on thumbing up an application is discovered to, say, set a default root password (I'm good at far fetched examples, too ;) Regards, Attila ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Ask for removal of some packages from Extras Fremantle repository
On Tue, Mar 23, 2010 at 7:55 AM, Andrew Flegg and...@bleb.org wrote: requirement IF and ONLY IF you choose to provide the sources through a written offer (instead of accompanying the binaries through neighbouring links, which is actually what maemo.org does). However, I think that link is the written offer; let's consider 3a again: ACCOMPANY it with the complete corresponding machine-readable source code, which must be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or, I've added the emphasis. The source code does *not* accompany every download from maemo.org (consider the HAM case as it perfectly demonstrates it). If the source code doesn't accompany every download, then 3a doesn't apply so one of 3b or 3c must. Accompanying source can get to be a tricky term and the GPL FAQhttp://www.gnu.org/licenses/gpl-faq.htmldoes not quite interpret it the way you did (it goes as far as to say even different sites and distributions mechanisms can be acceptable). Considering HAM is just a front-end, I would say it does not really matter in this question (the system is still fundamentally apt based and youre perfectly capable to apt-get source). Here are a few related snippets from the FAQ: *I want to distribute binaries via physical media without accompanying sources. Can I provide source code by FTP?* Version 3 of the GPL allows this; see option 6(b) for the full details. Under version 2, you're certainly free to offer source via FTP, and most users will get it from there. However, if any of them would rather get the source on physical media by mail, you are required to provide that. If you distribute binaries via FTP, you should distribute source via FTP.#AnonFTPAndSendSources *Can I put the binaries on my Internet server and put the source on a different Internet site?* Yes. Section 6(d) allows this. However, you must provide clear instructions people can follow to obtain the source, and you must take care to make sure that the source remains available for as long as you distribute the object code. *Am I complying with GPLv3 if I offer binaries on an FTP server and sources by way of a link to a source code repository in a version control system, like CVS or Subversion?* This is acceptable as long as the source checkout process does not become burdensome or otherwise restrictive. Anybody who can download your object code should also be able to check out source from your version control system, using a publicly available free software client. Users should be provided with clear and convenient instructions for how to get the source for the exact object code they downloaded—they may not necessarily want the latest development code, after all. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Residual configuration after package reinstallation
On Tuesday 23 March 2010 16:58:32 Tomasz Rybak wrote: So what is reason for HAM to leave configuration when uninstalling packages (removing them but not purging)? I'm not sure how the HAM prompts (or doesn't) for config file conflicts, but for more generic insight about conffile upgrades take a look at http://www.debian.org/doc/debian-policy/ap-pkg-conffiles.html The concept is actually quite reasonable, I wouldn't purge conffiles on uninstall unless specifically asked to. Regards, Attila ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Ask for removal of some packages from Extras Fremantle repository
On Monday 22 March 2010 11:56:43 Robin Burchell wrote: While I wish there was another way to fix this, I don't think Khertan has mismanaged this in any way - he reported the bugs, he followed up on it, and has been met with silence on issues that annoy and frustrate the extras packaging process. I think everyone has the right to distribute his stuff any way he wants (some obviously being better than others from a developer/community/user perspective), but I would urge everyone involved to avoid burning bridges, nobody ever benefits from that. Regards, Attila ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo 5 PR1.2 and Extras
On Monday 22 March 2010 17:23:11 Tomi Ollila wrote: 1: Separate repo for every software release; It would be even better if this can be variableized in sources.list files (I don't see such a feature in /etc/apt/sources.list; on the other hand for example /etc/yum.repos.d/fedora.repo there is $releasever and $basearch variables to affect the location...) The sources.list version component you're looking for is 'fremantle' ;) Arch is determined/used automatically, but if you really know what you're doing, it can be done manually, too, with $(ARCH). Regards, Attila ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Ask for removal of some packages from Extras Fremantle repository
On Tuesday 23 March 2010 00:39:09 Darren Long wrote: However, in the general case where the source and the executable are not the same, I believe that maemo.org would be obliged to continue to make the source available, for at least 3 years. Now, I might just be grossly misinformed or misinterpreting the legalese, but to me it sounds like the GPL (at least v2) brings into play the 3 year requirement IF and ONLY IF you choose to provide the sources through a written offer (instead of accompanying the binaries through neighbouring links, which is actually what maemo.org does). --- 3. You may copy and distribute the Program (or a work based on it, under Section 2) in object code or executable form under the terms of Sections 1 and 2 above provided that you also do one of the following: a) Accompany it with the complete corresponding machine-readable source code, which must be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or, b) Accompany it with a written offer, valid for at least three years, to give any third party, for a charge no more than your cost of physically performing source distribution, a complete machine-readable copy of the corresponding source code, to be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or, c) Accompany it with the information you received as to the offer to distribute corresponding source code. (This alternative is allowed only for noncommercial distribution and only if you received the program in object code or executable form with such an offer, in accord with Subsection b above.) - ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Ask for removal of some packages from Extras Fremantle repository
On Tuesday 23 March 2010 01:00:19 Gary Birkett wrote: why doesn't HAM allow somebody to use a later provided version from Beniots own repository? there would be nothing wrong with leaving everything existing and Beniot can get what he wants by still offering users the opportunity to add his own repository and gain later updates and we retain the polished solid versions available for regular users. There was some mention of this previously. Basically, the issue is authenticity (package hijacking avoidance, whether intentional or not), and/or generic cross-repository FUBAR avoidance. Imagine what would happen during the Qt4.5 to Qt4.6 transition if we had external repositories containing apps referencing Qt. Regards, Attila ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Howto configure borderless 4:3 tv-out on n900?
On Friday 19 March 2010 09:16:14 Frantisek Dufka wrote: I don't know if there is some high level api but a lot of things can be done either via framebuffer ioctl or via changing stuff in /sys/dev/ices/platform/omapdss/ see http://gitorious.org/linux-omap-dss2/linux/blobs/master/Documentation/arm/O MAP/DSS Having full PAL or NTSC with no translation/scaling would be good both for games and video playback too. Can you (or anyone with intimate knowledge) chip in with some comments of how playing with these can (not) affect the devices (or what gets attached to them) ? I would like to play with this a bit, but don't want to burn down my DDP N900 with some weird video sync setting (been bitten by some unrelated hardware happily setting parameters that burned the video out down :) Regards, Attila ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Can someone take care of bugs #9494 and #9608 the web interface is on what rely tester to thumb down
On Thursday 18 March 2010 20:17:16 Andrew Flegg wrote: XSBC-Bugtracker: mailto:kher...@khertan.net ...and that the bug is that it is output as a href=kher...@khertan.net which was the value of the control file field in an earlier version of the package? In retrospect, I think that the mailto scheme is actually the correct one and that the 'historical' plain mail address is the one more likely to cause trouble in the future. Let me elaborate: if we use automatic tools/applications (extras-assistant, appwatch, something based on texrat's framework, you name it), defining an URL there is the right thing to do: if it's a mailto: scheme, the browser will open the mail client, so it will work. With putting simple mail addresses in there, any potential automated client (including the maemo.org interface) will have to make this analysis whether the giver string is a mail address, whether it's correct, etc, etc. I'm inclined to say the bugtracker should be a proper URL (whether http or mailto doesn't matter as long as it can be automatically handled with a browser). The maemo.org interface will have to take this into account either way. Of course, should we reach an agreement of such a change, we should probably send out a notification mail to all package maintainers using the 'old' scheme in the bugtracker fields (not that difficult to find with grep). Comments welcome. Regards, Attila ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Icons are just a few bytes, right ?
On Friday 12 March 2010 08:36:19 Marius Vollmer wrote: ext Attila Csipa ma...@csipa.in.rs writes: There are probably many better ways to do this, but a quick and dirty solution would be to remove the icon from the older version in the repo when a new version is pushed to the repo. What about removing old versions completely? Old versions are useful, but only quite rarely. If you want, you can keep a separate extras-history repo with all versions ever that people can use if they really need to get obsolete versions. Certainly a good option, but perhaps not as clear-cut as in the case of icons (=not 100% useless as old icons). There are a few potential problems with old ver removal, though. Some might depend on newer versions of libs than others, so not every dupe is superfluous and this check needs to be very careful in order not to break other apps. Another problem might be you cannot retroactively set dependencies (i.e. if you realize your app does not work with a brand new version of a lib, you cannot put in a dependency on the old version as it has already been archived - or if you do, you risk cross-repository deps, which is a nasty topic in itself). If we DO accept that, though, some more grep magic reveals that of the 7726 total packages in extras-devel, 2892 are unique, so almost two-thirds are duplicates. The extras-(devel?)-history is a good idea also in the way that it falls in line with the notion that the source packages of every version should be preserved (even if we eventually delete the binaries from extras-devel). Another sideeffect would be that package operations would be drastically sped up (everyone who uses extras-devel knows that the busy indicator goes around quite a few times on every operation, mostly as a result of the sheer size/number of package descriptions). Regards, Attila ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Icons are just a few bytes, right ?
On Friday 12 March 2010 12:42:11 you wrote: From all the available versions of a package, apt selects one upfront as the candidate and then sticks with that. The only decision it makes is between installing that candidate version, keeping the version you have already installed, or removing the package altogether. It will not reconsider which version should be the candidate based on dependencies between packages. I'm talking about a scenario when the application has an 'older than' dependency (often in combination with '|'), which apt (and HAM) *will* honour. So if app A has a libfoo 2.0 dep, app B has libfoo 1.0, and there is currently a libfoo 1.5 in the repo, both A and B are installable. If you upload libfoo 2.5, however, and 1.5 gets automatically archived, app A is no longer installable (even though it could have been if you kept both versions of libfoo). Not a common case, I admit, just saying one has to be careful when removing packages from repos. Regards, Attila ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Icons are just a few bytes, right ?
Foreword: I know how deeply ingrained these things are. Just drawing attention so hopefully this gets resolved at least by the time a Harmattan device hits the shelves. Extras-devel grew to massive proportions due to the flurry of activity by developers, which is good to see. This also brings some growing pains unfortunately. Currently just enabling testing/devel repos makes 25+MB of rootfs space disappear, and as package activity increases, this is just going to get worse. While I know maemo.org maintainers (or their tireless scripts) remove old packages from time to time, let's take a quick look what *exactly* eats this space and bandwidth. Extras-devel Packages: 16.5MiB Extras-devel Packages.gz: 3.5MiB Okay, big, but there are 3000+ user packages. But, how about we strip the... icons ? A quick and dirty grep -v gives a rough: Packages: 8.8MiB Packages.gz: 1.8MiB Conclusion: We have many duplicates, true, but roughly half of the bandwidth used for updating (and precious rootfs space !) are wasted on icons that are *never* *ever* going go be shown to the user. Now, the ultimate solution would be to have a proper metadata repository, where we could keep, search and edit data like icons, bugtracker links, screenshots, forum links, source repo addresses, reviews, statistics, etc, but until that materializes, we should consider alternative methods to combat this problem. There are probably many better ways to do this, but a quick and dirty solution would be to remove the icon from the older version in the repo when a new version is pushed to the repo. The Application manager will show the latest package anyway (which *will* have an icon), and apt-get which would give you the older ones doesn't care about icons. Ideas, comments welcome. Thank you for your attention. Regards, Attila ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Extras-testing improvements
On Tuesday 09 March 2010 09:22:49 Alberto Mardegan wrote: I agree with Graham: I'd like the quarantine process to be only about critical problems, such as app not being optified, making the device unstable or not meeting some basic formal criteria (such as bugtracker link). It is that way :) Critical problems are part of a very specific checklist and are called blockers - they are the only ones that actually prevent promotion. We will also take note of other, NON-critical problems/recommendations, but those are not ground for demotion or thumbing down. Regards, Attila ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Screenshots to user installable GUI packages in extras-testing [was Re: External Repository and HAM]
On Tuesday 09 March 2010 08:27:34 Tim Teulings wrote: I think initialy (and hopefully still) extras was not about good or bad software, its was about software that does not break your device (and does what it told). That is what QA must try to target. Comments about usability, spelling mistakes improvements are good (and I personally got some good hints by such comments, so I do not want to miss them), but that should not avoid applications getting into extras. Entirely correct. If anyone thumbed you down because of a spelling error (barring errors in links) or non-exorbitant usability issues (that would fall into the 'does not deliver promised functionality'), IMHO he did it wrong. not that clear - so for Nokia is possibly not the only goal to only have excellent quality application in extras. As always things are complicated ;-) I took a dive in the wiki and I think the following page is a good read how the concept originally developed (most edits on that page by QGil and GeneralAntilles) https://wiki.maemo.org/Extras_repository_process_definition Yes, it is wise to have a screenshot, but if the application is not downloaded because of a missing screenshot this is a problem for the author, but not for Nokia neither for the community Considering the long run, I disagree. There is not a set number of apps a user will install. So a higher number of well-represented applications benefits ALL, the user, the developer, the community, and, in the bottom line, Nokia. Yes, the author loses most, but that's beside the point - it won't help a bad app, but with a bad representation of a GOOD app nobody won, even those WHO COULD HAVE. To underline - I don't want this to be an extra burden, I want it to be simple to do (simpler than now, just as the bugtracker issue) so everybody benefits. (it does not do any harm to the end user). Of course we are also interested in a good Sorry, I still fail to see ANY difference in the 'danger level' of this compared to a missing application icon (it 'harms' the user IMHO in absolutely the same way - by denying additional information, but does not influence the application functionality). Regards, Attila ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Extras-testing improvements
On Tuesday 09 March 2010 13:01:32 Edward Page wrote: Will this be like government regulations where they increase year to year and we have to jump through more hoops all the time just to continue to have the honor of being in Extras? The solution to this is to work on two fronts - not just raising the bar, but also helping developers make it over it (springs on shoes, if you wish :). A good example is the bugtracker. It became required for a reason, but the story does not end there, with improving the developer interface we (well, more like Niels et al :) can make fulfilling this requirement a breeze. I disagree, it is the gutter. As a developer I only leave extras-devel enabled long enough to install my software and test it in prep for extras-testing. A few months back I would have agreed. However, since I published AppWatch, my view has changed dramatically. Turns out Extras-devel applications regularly have hundreds of 'silent' users willing to try out things, regardless of risk. Appwatch itself, even with it's huge Qt dependencies and occasional problems due to repository issues still had *thousands* of installs so far, and hundreds of active users. All this despite the very modest PR efforts (a single t.m.o. thread) and being in Extras-devel. Even while we put 'there be dragons' all over the place, the sheer number of N900 users means even a low percentage who does venture there is not that small in absolute numbers - and the beauty is that there is nothing wrong with it. The goal is not to keep people out with tooth and nail - it's to make them aware what they're dealing with, and if that's OK with them, great, it's one of the things that make Open Source good ! or Extras-Hacking. I would still prefer a PPA-style deployment so people would not trip over each other. Regards, Attila ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Extras-testing improvements
On Tuesday 09 March 2010 10:02:19 you wrote: In the current system after the dev promotes the package to testing, all he can do is to hope that everything is OK. If it's not, he has to promote new package and everything starts from zero again. I don't think this good enough for anyone involved. Agreed. While the clean slate approach does have a rationale, in the case of today's Maemo it is frustrating and not practical for many. have. The Testing Squad should be renamed to Border Control, because they can't really improve any app. They can only block them. And finally, No. The testing squad and testers in general also leave (I like to believe more often valuable than not) comments and suggestions. You will see plenty of 'X dialogue not finger friendly', 'use a hildon file dialogue', 'it is very slow while loading data', 'a WiFi-only refresh option would be good' or similar comments, which is all good feedback helping to improve software in the next iteration. And these comments DID NOT mean a thumbs down ! Also, a misconception - the testing squad does not 'decide' whether a package is in or out. A package can be both promoted and demoted without a single vote from any testing squad member. The way I see it, the primary task is to provide votes and comments to packages that did not receive enough attention from the community (in the form of other testers/votes). Regards, Attila ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Extras-testing improvements
On Tuesday 09 March 2010 11:56:49 Matan Ziv-Av wrote: On Tue, 9 Mar 2010, Niels Breet wrote: You have to see that Extras should be for applications that are of a high quality. The Extras repository should not give any problems to people who are new to Maemo and have no clue how to work with linux for instance. Here's the problem, there seems to be two (almost opposite) goals for this extras repository: one is to be a collection of all maemo software, eliminating the use of external repositories, the other is having a collection only of high quality software. Until you accept that you can't have both, those discussions will go on repeating. There is nothing preventing (well, apart from autobuilder issues) people putting things into Extras-devel. It *is* a valid place for software, it's not the gutter, and not every application there is expected to enter Extras. I often feel the issues brought up in relation with the term 'quality' stem from different interpretations of the term - terminology. Regards, Attila ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Extras-testing improvements
On Tuesday 09 March 2010 13:19:33 Simon Pickering wrote: Also, the idea that an application can both be low quality and end user ready is a bizarre. I completely agree with Graham Cobb here, Extras should contain apps that work no matter how pretty or poorly spelled they are. To repeat myself, this is not really the issue here. Some testers might get carried away (at which point they need to be corrected), but the testing guidelines are quite clear about certain things being blockers, and others (like aforementioned spelling and general prettiness) not. There are borderline cases (like icons, bugtrackers, etc) but still, those are just shades of gray, they do not change the process fundamentally. Regards, Attila ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Extras-testing improvements
On Tuesday 09 March 2010 14:26:51 Dave Neary wrote: If the burden on the testers developers continues to grow, we will see a return to distribution in the wild, and away from Extras, which would be a disaster for Maemo. Bringing all the 3rd party repositories together and making Extras the natural place to ship software to Maemo users has been one of the great achievements of the past few years, but the social tide is turning against it. Don't make distributing software through Extras a task that developers dread. I would like to have these two things NOT seen as opposing things. Let's rephrase the issue as 'how can we maximize the safety of users and quality of apps without being a pain'. For example, would the bugtracker issue ever be a stumbling point if we had an automated check or option to (semi)automatically create/update a bugtracker from the package interface ? I hope you see what I'm getting at, it's not the extra requirements that cause the pain, but the hoops that they might create. If we do away with the hoops, what remains is a general better experience. What is IMHO often the error (in the particular case of extras-testing) is that the requirement is introduced without any automatism or infrastructure support and then it, while enforceable, creates a massive workload and sometimes bad blood. We can and should be able to achieve the same goals without either. Regards, Attila ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: External Repository and HAM
On Monday 08 March 2010 16:21:13 Benoît HERVIER wrote: - It s look like some users are here just to put thumb down just to gain some karma. To elaborate on this a bit... The mass-downthumbing people might see is just a temporary (?) solution to optimize testing resources. The idea is that it should be immediately visible that this package is NOT going to be promoted, so testers should not vaste their time on a particular package, since there is going to be a newer version which will require testing anyway. The worst case scenario is if someone who is not a regular tester thumbs ups a package that never gets to Extras, but fails to do so with the followup package that has the blockers fixed (because of lack of motivation, whatever). So, really, it's just a mechanism used as a replacement for not having a master/moderator that is able to instantly demote a package with a blocker. It's not a bunch thugs that go around extras-testing with a giant thumbs-down bat, even though this is not communicated too well to developers :( And yes, I stated several times I do agree the bugtracker field is a pain that needs to be handled systematically and not fought over on a case-by-case basis. The first step (which is either already implemented, or just about to) is to filter this problem on promotion to -testing, so you don't wait 10 days just to figure out you made a mistake. The second step would be to make it easier/more automatic to insert the bugtracker. I.e. on upload of a new package, you could be asked if you wish to open a b.m.o. product for it, or have a garage tracker offered if the project is hosted there. You could obviously override these with the current XSBC field, but that IMHO would make things easier. On a side note I would make screenshots (where applicable) also mandatory for promotion to -testing, on the same grounds as a bugtracker, but the ideas/message counter is in the red zone already, so I'm going to stop here... :) Regards, Attila ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Screenshots to user installable GUI packages in extras-testing [was Re: External Repository and HAM]
On Monday 08 March 2010 18:43:02 Graham Cobb wrote: Anyway, let's leave the screenshots issue for a separate discussion! Separated On a side note I would make screenshots (where applicable) also mandatory for promotion to -testing, on the same grounds as a bugtracker, but the ideas/message counter is in the red zone already, so I'm going to stop here... :) I strongly disagree. The Extras-Testing process should be about safety: someone browsing extras should be comfortable that if they look at an app they can get a reasonable description, they can install it without endangering their device, they can remove it if they don't like it. It is not about the quality of the app itself: its usability, its GUI, how well The testing process is not *just* about safety. It's quality assurance, and there is a lot more to quality than just safety. For instance, we already handle bad or missing icons as blockers (and I believe we will agree icons and screenshots aren't that far in regard to safety). it works, whether it is useful, whether it has screen shots, etc -- that is what crowd-sourced rating systems are about (the stars, the reviews, the comments). Any app without a screenshot is not going to get good comments or make its way to the front page of the Downloads section. Poor apps will drop to the bottom -- but being at the bottom does NOT mean they should be excluded. And this is were we get back to screenshots - a first time application is almost guaranteed to have '?' there for quite a while. The interface is (from testing squad experience) less than intuitive for people and it takes a while for the images to update - usually just as much as they spend on the front page, effectively spending their 5 minutes of glory under a question mark. Regards, Attila ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
