Re: Problem with CSSU update
On 14 Jan 2013, at 06:36, Kaj-Michael Lang wrote: I'm trying to install the latest CSSU updates but it insist on requiring me to install from a PC. It's never done that before. Disk space should not be an issue, plenty of free space available on the device. Have you checked http://wiki.maemo.org/Community_SSU/Installation_FAQ? -- Andrew Flegg -- mailto:and...@bleb.org | http://www.bleb.org/ ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: [CSSU] how to include rewrites of closed blobs
On 11 May 2012 10:11, Christian Ratzenhofer wrote: > Coming monday (14.05) we will have an irc meeting in #maemo-ssu on freenode > @ 18:00 UTC > > Target of the meeting is to decide on a way how we handle rewrites within > cssu, and how new ones should be added. A previous discussion can be seen at: http://mg.pov.lt/maemo-ssu-irclog/%23maemo-ssu.2012-05-07.log.html#t2012-05-07T15:08:09 My position is that the CSSU exists to make possible for the average user things which only Nokia could previously do (such as upgrades/bugfixes to hildon-desktop & Modest). If something can be installed via Extras, it should be. If it's a fully functional rewrite, an additional package can be used to swap the .desktops etc. This means users can have the choice between, and compare side-by-side, the original and the rewrite. This additional "bridging" package *might* require the CSSU. If so, maybe it should be in a separate repo, a "CSSU Extras" if you will. See you Monday! Cheers, Andrew -- Andrew Flegg -- mailto:and...@bleb.org | http://www.bleb.org/ ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: [ANNOUNCE] N9/N950 TV out control application
On 12 March 2012 21:43, Ville Syrjälä wrote: > On Mon, Mar 12, 2012 at 06:27:03PM +0000, Andrew Flegg wrote: >> >> Is it possible to get rotational support in there? So that showing >> Music has very wide black bars, but is at least the right way up? > > Nope. At the very least you'd need to modify the X driver, and doing > it optimally from performance POV would require even more changes. So xrandr on Harmattan is more like 'xonlyoner' ;-) >> Is there a binary package with everything nicely precompiled? > > Dunno. I'm too lazy to distribute binaries. Fair enough. -- Andrew Flegg -- mailto:and...@bleb.org | http://www.bleb.org/ ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: [ANNOUNCE] N9/N950 TV out control application
On 9 January 2012 08:39, Ville Syrjälä wrote: > > The backend supports a few extra knobs, when compared with > fremantle. However, I was too lazy to write the extra GUI > code. So the current GUI offers the same controls that > maemo-tvout-control has. Is it possible to get rotational support in there? So that showing Music has very wide black bars, but is at least the right way up? Is there a binary package with everything nicely precompiled? Thanks in advance, Andrew -- Andrew Flegg -- mailto:and...@bleb.org | http://www.bleb.org/ ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Supertesters
On 16 February 2012 12:21, robert bauer wrote: > > Could you give me your admin rights at > https://garage.maemo.org/projects/qatesters/ ? I've given you admin rights. Regards, Andrew -- Andrew Flegg -- mailto:and...@bleb.org | http://www.bleb.org/ ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Supertesters - Make, accept, nominations
On Thursday, 16 February 2012, Neal H. Walfield wrote: > At Thu, 16 Feb 2012 14:44:07 +0100, > Pali Rohár wrote: >> >> I would like to see permission for promoting packages which I update and not >> wait while old maintainer give me needed permisstion! > > This is a good point. It needs to be easier to adopt unmaintained > packages. Agreed, but this is a case of designing and proposing a process. It has nothing to do with supertesters, AFAICT. Cheers, Andrew -- Andrew Flegg -- mailto:and...@bleb.org | http://www.bleb.org/ ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: TSG for CSSU?
On Thursday, 16 February 2012, robert bauer wrote: > > I propose a TSG (Technical Steering Group) for CSSU [...]. I have sometimes seen the project get delayed because MohammedAG is temporarily unavailable, and that there is uncertainty or lack of input over how some decisions get made, etc. What did MohammadAG say to this proposal? He was the only person who stepped up to do this, and has since been joined by merlin1991 et al. The Community Council are a facilitating body, rather than an owning body, so it's in your remit to assist MAG in this, if he's asked for help. But I don't think you have the power for a "hostile" takeover, which is why I'm asking. Of course, the CSSU could always be forked - but that's dependent on having someone to do the work. It's "doers" that Maemo, and the CSSU is missing, not people to sit by the sidelines and direct. For example, the stable branch came out because someone was willing to put in the work to define how it should be created, how it should be managed and then to do that. Many people *said* there should be a stable Maemo 5 CSSU, but if someone isn't willing to help with the work, so what? What would the CSSU TSG do? Can you give concrete examples? As a *technical* steering, how would candidates' eligibility be established so that a sensible and consistent set of architectural decisions would be made? Thanks in advance, Andrew -- Andrew Flegg -- mailto:and...@bleb.org | http://www.bleb.org/ ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: promotion to extras
On 12 December 2011 17:44, robert bauer wrote: > > FWIW, the council (of which I am a member) suggested the idea of a limited > number of "supertesters" to Nemein awhile ago. The approval of a single > supertester would, in the absence of any disapproval, be sufficient for > promotion. IMHO, there should be an open call for individuals to volunteer > as supertesters but first crowdsource the qualifications so that we have an > objective measure by which to select from the volunteers. There are already "supertesters", of course. After 20 days quarantine, a net of 3 supertester votes is enough to carry a package through. The scope of supertesters, and the needed number of votes, may need to be revisited. Cheers, Andrew -- Andrew Flegg -- mailto:and...@bleb.org | http://www.bleb.org/ ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: how to control the backlight in Harmattan 1.2
On Sun, Oct 16, 2011 at 16:09, ibrahim.ali wrote: > > I wonder if there are any APIs to control the backlight mode in Harmattan > 1.2. > > I found a Qt class called QSystemDisplayInfo that is used to GET the > backlight status only not change it. What do you want to do? You can use a ScreenSaver element in QML to prevent the backlight dimming and the screen locking: http://apidocs.meego.com/1.2/qtmobility/qml-screensaver.html Alternatively, the same GConf keys as Fremantle are used for controlling the brightness. So, in Bedside, which features a "dim to dark" feature I just directly invoke gconftool-2: https://gitorious.org/jaffas-playground/bedside/blobs/master/backlightcontrol.h The above code is licensed under the Artistic License, so feel free to reuse as appropriate. Hope that helps, Andrew -- Andrew Flegg -- mailto:and...@bleb.org | http://www.bleb.org/ ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Waiting "Pending maintainer request" for Python-SymPy
On Mon, Sep 19, 2011 at 15:47, Aapo Rantalainen wrote: >> Python-SymPy is currently used by "Integral" and soon to be released >> "Derivative", "Limit" and "Power Series". I am the author of these >> softwares. > > If you get one of those to the extras (from extras-testing), > python-sympy will also go to the extras. ...as long as python-sympy isn't in "Section: user/..." - however it doesn't sound like it should be. Cheers, Andrew -- Andrew Flegg -- mailto:and...@bleb.org | http://www.bleb.org/ ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Since I still don't have my n950... trying to make my n900 behave somewhat like it
On Fri, Jul 15, 2011 at 22:45, Felipe Crochik wrote: > > I really liked the idea of adding shortcuts to web sites on the "programs > menu". I think on the n900 is especially nice because we have ways to > organize them. > My issue is that in order to create desktop files you need to have a root > permissions. They can also go in $HOME/.local/share/applications, in accordance with the freedesktop.org spec. Which is, in fact, where Harmattan puts them. Don't forget icon support: http://www.bernskiold.com/2011/01/07/adding-an-iphoneipad-icon-for-your-website/ (Harmattan *seems* to follow the same standard) HTH, Andrew -- Andrew Flegg -- mailto:and...@bleb.org | http://www.bleb.org/ ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Harmattan Platform SDK and Fremantle targets
On Fri, Jul 1, 2011 at 09:40, Luca Donaggio wrote: > > is it possible to add "old" Fremantle targets under the scratchbox > version (hator) used by the Harmattan Platform SDK? Following the advice of others, I run the Harmattan Platform SDK setup script on a machine which already had /scratchbox containing the two Fremantle targets. It integrated perfectly well, and all targets *seem* functional (I haven't done extensive testing, so YMMV). Hope that helps, Andrew -- Andrew Flegg -- mailto:and...@bleb.org | http://www.bleb.org/ ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: [CSSU] Advice wanted on the best way to package Cell Broadcast SMS bugfix for closed libsms library
On Saturday, June 25, 2011, Jonathan Wilson wrote: > > Given this, I have come up with a possible solution and would like > advice on the best way to package this solution. > Option 1: > Patch libsms (there are 3 bytes that need to be changed to fix the bug) and > distribute the patched .so file. (i.e. basically an updated libsms package) Not an option - the licence of libsms would make this copyright infringement (if it is closed source). > Option 2: > Distribute a package that will patch (and un-patch on uninstall I would guess) > libsms with the 3 changed bytes to fix the bug. Easiest option, and therefore the most reliable. The only caveat is whether or not libsms varies between OS versions. As long as the package for the installer depends on the right version of libsms, and maybe the patcher does a checksum before modifying the file, I think that'd work. It can even be tested in Extras-devel outside of the CSSU, but like the "modify the Conversations app's CSS to support portrait", it should be depended on my the mp-fremantle-community-pr as a quick way of bundling together the separate "hotfixes". Cheers, Andrew -- Andrew Flegg -- mailto:and...@bleb.org | http://www.bleb.org/ ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: [MeeGo-dev] Where to post bug reports for MeeGo 1.2 Harmattan?
On Wed, Jun 22, 2011 at 05:29, Andrey Ponomarenko wrote: > > Could anybody explain me where to post bug reports for MeeGo 1.2 Harmattan > [1]? > > To maemo.org Bugzilla [2] or to MeeGo Bugzilla [3]? Neither. See Quim's post: http://forum.meego.com/showpost.php?p=22953&postcount=77 HTH, Andrew -- Andrew Flegg -- mailto:and...@bleb.org | http://www.bleb.org/ ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Stopping QML update when not visible
On Mon, May 30, 2011 at 16:07, Ville M. Vainio wrote: > > Right - so I confirmed Andrew's fear [was unnecessary] that QML would > be "stupid" about this, and waking up the process when it should be > steady (e.g. by doing a dummy op at 60fps). Thanks. > If you have animations that proceed when the application should be > steady, you have a broken design in the first place; this is a problem > that application developer can easily solve. Indeed, and by hooking up Thomas' code to my "CalibratedAccelerometer", it now drops to 0% when the window isn't active: http://gitorious.org/attitude/attitude/blobs/master/qml/attitude/CalibratedAccelerometer.qml BTW, list handling in QML is a pain. I suspect this list recreation/parsing/manipulation is accounting for a large portion of the CPU usage. Other thoughts from Qt Quick experts appreciated; but the graphical performance is orders of magnitude higher than the Python/Gdk implemention. Cheers, Andrew -- Andrew Flegg -- mailto:and...@bleb.org | http://www.bleb.org/ ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Stopping QML update when not visible
On Mon, May 30, 2011 at 15:56, Thomas Perl wrote: > > For anyone that's interested in how it's done (feedback and > improvement suggestions welcome!), you can find the patch against > Attitude here: > > http://thp.io/2011/maemo/attitude_activemonitor.patch ...and now here: http://gitorious.org/attitude/attitude/commit/693261e3a21cf87f8304368258d4242e51e4ec61 I'll also investigate the GL rendering. Thanks all! Cheers, Andrew -- Andrew Flegg -- mailto:and...@bleb.org | http://www.bleb.org/ ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Stopping QML update when not visible
Hi, Qt Quick 1.1 apparently features a "Qt.application.active" read-only property[1] which can be connected (somehow) to stopping animations, reading sensors and so on. However, in my rewrite of Attitude[2] in QML, I'd like to do something similar. In fact, given my app's running at 50-60% CPU, I'd consider it a blocker to replacing the Pymaemo & Cairo implementation already in Extras. So, I'd even accept some hacky C++ way. Thoughts welcome. To be honest, it's amazing (and disappointing) that there isn't a way of doing this in Qt Quick 1.0. Can anyone confirm whether or not it's at least not updating the screen when hidden (it does in the task manager), and it's only the accelerometer signalling I need to switch off? Thanks in advance, Andrew [1] http://doc.qt.nokia.com/4.7-snapshot/qml-qt.html#application-prop [2] http://maemo.org/packages/view/attitude/ -- Andrew Flegg -- mailto:and...@bleb.org | http://www.bleb.org/ ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: apps in extras-testing with more than 10 rates
On Mon, Apr 4, 2011 at 11:39, emme750 wrote: > > owners, the council, or who has the chance, can promote or drop > these packages [snip] The key bit of information missing from your table is when things were promoted and how long they've had >10 votes. For example, AIUI, Mussorgsky was only promoted to Extras-testing last week. Cheers, Andrew -- Andrew Flegg -- mailto:and...@bleb.org | http://www.bleb.org/ ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
[CSSU] [PATCH] Re: hildon-desktop portrait task switcher patch
2011/3/29 Ивайло Димитров : > > I push the following merge request > https://gitorious.org/community-ssu/hildon-desktop/merge_requests/8 > and was advised on #maemo-ssu irc channel to inform everybody about it, so > anyone interested could check it. > > The patch implements portrait mode task switcher in hildon-desktop Thanks, much appreciated. A *very* quick look over the first three files was encouraging. > BTW sorry for [URL][/URL] notation but stupid web interface I am writing > this from does not allow me to place hyperlinks. Plain text is preferred anyway, and most email clients can auto-detect and highlight links :-) Cheers, Andrew -- Andrew Flegg -- mailto:and...@bleb.org | http://www.bleb.org/ ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Where do we go now?
On Mon, Mar 7, 2011 at 18:09, Nils Faerber wrote: > > I would definitely like to be prepared. The pace at which Nokia is doing > decisions with very long lasting consequences is frightening. At the > moment I would not deny any possibility that they could pull the plug > with very short notice time. I do not believe that they will do so any > time soon, but I fear that we have to take the possibility that they > could do it into account. As Andre said: http://lists.maemo.org/pipermail/maemo-community/2011-February/004677.html > In this sense I would also very much like to see that the community > urges Nokia to free as much stuff as possible of Maemo5 (since it is > of no direct commercial value for them anymore anyway) so that > the platform can get a live on its own. The Council approached Nokia about this: http://maemo.org/community/council/state_of_maemo-q12011-1/ Quim was going to speak to some people in Helsinki last week. Given it's Monday and he's 8 hours behind Europe, I haven't had a chance to catch up with him yet. Cheers, Andrew -- Andrew Flegg -- mailto:and...@bleb.org | http://www.bleb.org/ Maemo Community Council member ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: [CSSU] Modest tree view mode beta test
On Tue, Mar 1, 2011 at 02:50, Naikel Aparicio wrote: > > I’m looking for people that would like to test a little bit more Modest in > tree view mode. It’s a very confortable mode where you see accounts and > folders in a tree, and you don’t have to browse accounts, mailboxes and > folder windows to get to your message. Whilst you're in a treeview mode, how feasible would it be to allow - on a per account basis - showing messages grouped by In-Reply-To and/or References; to give something a bit like Gmail's conversations view? This would meet https://bugs.maemo.org/2674 requirements. So, consider my Inbox of a typical morning: Mrs JaffaDinner tonight? 07:40 Bart Simpson Re: About your website 07:02 John Smith Re: [CSSU] Modest tree view mode beta test 07:01 Bart Simpson About your website 04:00 Naikel Aparicio Re: [CSSU] Modest tree view mode beta test 03:20 This can rapidly become painful reading a thread. However, using a single-level tree view, it'd be great to have: Mrs JaffaDinner tonight? 07:40 Bart Simpson [-] About your website 07:02 Bart Simpson Re: About your website 07:02 Bart Simpson About your website 04:00 2 authors[-] [CSSU] Modest tree view mode beta test 07:01 John SmithRe: [CSSU] Modest tree view mode beta test 07:01 Naikel Apa... Re: [CSSU] Modest tree view mode beta test 03:20 Rough spec: * Groups would only be shown if there were multiple messages in the folder. * If there is a single sender for all the messages in the group, show their name. Otherwise show a count of the authors. (Or should it show a message count in both cases?) * Groups are sorted by the time of the most recent message. * Prev/next buttons move you through the order displayed above. What do you think? This would make Modest really truly excellent for _my_ use cases, at least. Cheers, Andrew -- Andrew Flegg -- mailto:and...@bleb.org | http://www.bleb.org/ Maemo Community Council member ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: [CSSU] Modest tree view mode beta test
On Tue, Mar 1, 2011 at 02:50, Naikel Aparicio wrote: > > I’m looking for people that would like to test a little bit more Modest in > tree view mode. It’s a very confortable mode where you see accounts and > folders in a tree, and you don’t have to browse accounts, mailboxes and > folder windows to get to your message. Is it optional, or are you suggesting a change to Modest's default user interface? It looks good, but I'm not sure the expand/contract buttons are used in other tree views, are they? For example, the move messages dialogue has "Gmail" be expandible in my Modest, but doesn't appear to have the square +/-. Cheers, Andrew -- Andrew Flegg -- mailto:and...@bleb.org | http://www.bleb.org/ Maemo Community Council member ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
[CSSU] Qt fixes in Maemo 5 Community SSU?
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? http://mg.pov.lt/maemo-ssu-irclog/%23maemo-ssu.2011-02-28.log.html#t2011-02-28T15:21:52 Thanks in advance, Andrew -- Andrew Flegg -- mailto:and...@bleb.org | http://www.bleb.org/ Maemo Community Council member ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: [CSSU] Proposed status bar icons for orientation lock
On Sat, Feb 26, 2011 at 19:42, Mohammad Abu-Garbeyyeh wrote: > > I used control_device_setup from the current icon set which can be > found under Control Panel on the icon list site [1]. > I'm guessing those can be edited without any problems from Nokia > as long as they're only used on Maemo 5. How about these then for the menu; three this time: one for auto, one for landscape lock, one for portrait lock. Cheers, Andrew -- Andrew Flegg -- mailto:and...@bleb.org | http://www.bleb.org/ Maemo Community Council member <><><>___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
[CSSU] Proposed status bar icons for orientation lock
Mohammad, As requested, here are a couple of proposals for the status area icon when an orientation lock[1] is enabled: * Auto: no icon * Landscape: orientation-lock.landscape.png * Portrait: (not yet supported) orientation-lock.portrait.png Which icon did you use for the current status menu button? Perhaps a similar approach, based on that more complete icon would make sense there? Comments welcome. As are improvements from actual artists :-) Cheers, Andrew [1] http://talk.maemo.org/showthread.php?p=956000#post956000 -- Andrew Flegg -- mailto:and...@bleb.org | http://www.bleb.org/ Maemo Community Council member <><>___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
[CSSU] maemo-developers as official mailing list for Community SSU?
Hi, I'd like to propose that we say maemo-developers is the "official" mailing list for discussion about the development of the Maemo 5 Community SSU: http://wiki.maemo.org/Community_SSU The traffic here is quite low now, and this would be taking us back towards the 2005 definition of the list: to discuss the development of Maemo :-) I don't expect the traffic to be high, but would suggest that CSSU topics are prefixed with "[CSSU]" in the subject line. Does anybody (incl. MohammadAG ;-)) have any objections? If not, I'll update the appropriate wiki page (Community_SSU/Development) Perhaps it would even be possible to subscribe maemo-developers to merge requests under http://gitorious.org/community-ssu (something mardy sort of suggested); but that might be an idea too far. Comments, as ever, welcome. Thanks in advance, Andrew -- Andrew Flegg -- mailto:and...@bleb.org | http://www.bleb.org/ Maemo Community Council member ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Nokia and MS
On Fri, Feb 11, 2011 at 9:30 PM, Sivan Greenberg wrote: > On Fri, Feb 11, 2011 at 9:00 PM, Andre Klapper wrote: >> On Fri, 2011-02-11 at 13:25 -0500, Demetris wrote: >>> How does this affect the future of Maemo on Nokia's devices? >> >> For quite a while the future has been MeeGo instead of Maemo, hence no >> changes to *Maemo* on Nokia devices. > > AFAIK it is in the hands of the Maemo community [council] no? I've three hats to wear: * Editor of this week's MWKN * Maemo Community Council member * Long-time Maemo enthusiast (five and a half years!) All three are intertwined, but this isn't the official position of the Maemo Community Council... Personally, the N900 represented a zenith for me. It was my first smartphone, but my fourth Maemo device. I hadn't realised at the time that it might be a "Concorde moment"[1]. MeeGo represented Nokia's new direction: an open, Linux-based, strategic vision. A range of devices from Nokia and other manufacturers. The Harmattan device would be the first: a flashier UI, smaller, faster, longer-lived battery-toting version of the N900. That's all I want: a smaller, lighter, faster version of the N900 running an evolution of Maemo 5 (primarily with some bugs fixed and more apps) which I could rely on all day. Nokia are now not going to deliver that entirely. It's *possible* the MeeGo device released "this year" might be interesting in the same way that the 770 was. But unlike the promise of the 770, I suspect it'll be stillborn. But there is a benefit to this that I can see. With no clear successor for the N900, some people will keep theirs for a bit longer, others - who may have been waiting for the Harmattan device - may now buy one. This means the Community SSU can have more users, more developers and more polish: http://wiki.maemo.org/Community_SSU Already we've seen patches which fix hildon-desktop's CPU eating bug; make Modest work better offline; make Modest more conformant to standards; an improved TV-out control panel plugin; an improved notification LED control panel plugin and so on. Many of these also widen the system's support of portrait usage. We also already have improved development tools with the Qt SDK. Although there may not be a compelling new device, we have a reinvigorated platform. Maybe that's enough. Thanks, Andrew [1] "For the uninitiated, a Concorde moment is one where mankind reaches the pinnacle of its achievement - ever since the Concorde no passenger aircraft has been built that can fly supersonic, and perhaps none ever will be. It is all downhill from there." -- http://bit.ly/g3c0PU -- Andrew Flegg -- mailto:and...@bleb.org | http://www.bleb.org/ Maemo Community Council member ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Proposal: code review process for community SSU
On Sun, Feb 6, 2011 at 19:37, Alberto Mardegan wrote: > > Sorry, I didn't weight my words correctly: I didn't mean to write > "critical" in the sense of "makes the phone unusable", I just meant > something affecting many users. But the point is that with the current > situation, much more dangerous bugs can emerge. Although, to play Devil's Advocate (and not to get into a pissing environment about whose professional experience is more valid ;-)), *no* process can prevent more dangerous bugs. That's why there's a testing release and (at some point) a stable one which will be advertised much more widely. > That's fine as a disclaimer, but I insist that one thing is being > honest and clear with your users, and another thing is having more > community support on the CSSU. The first we have, more or less (the > wiki page is not that clear about it being potentially dangerous > software, though). Please improve said wording :-) >> * It throws away the streamlined workflow supported >> by gitorious.org and its "merge request" functionality. > > I've been using gitorious for years now, but I still don't like it. > The review process is not better than a ML (because there's no easy > way to navigate from one diff to see the full code), and I would claim > that it's even worse because of missing notifications. Surely these are solved and/or solvable? Your preference may be for the ML, but I would suspect that's a personal preference. For example, Gitorious is _supposed_ to allow effective code review: http://blog.gitorious.org/2009/11/06/awesome-code-review/ I'd find it hard for you to find a problem with that which wouldn't affect an email! > People in maemo-developers. I'd be one, for sure. Besides, as I wrote > before, there are several gurus there who have always been helpful and > that happen to be the original writers of that software. Occasionally looking at a commit is different to committing (no pun intended) to review every change so that there's not a bottleneck. >> Having said that, doing something informally should be fine. >> Gitorious offers "watch" and (IIRC) RSS functionality. If you, >> or anyone else, wanted to watch the commits and provide comments >> on maemo-developers, I think that'd be very useful. > > That would be a pain. It's true that it could help in spotting some > bugs, but reviewing code "a posteriori" (after it has been merged into > the master branch) it's demotivating for everyone. At least it won't > help code quality: if I ask "please split this function into two", > when the function is perfectly functional as it is, who would do that? Indeed. However, I don't want to put stop energy in the way of making the CSSU better. Mohammad's taken the initiative and pushed this forward. Long term, I imagine we're going to want individual maintainers for each package under http://gitorious.org/community-ssu and a set of processes for managing and releasing them. How we transition from one to the other is the question, and this is definitely a helpful discussion. > BTW, I don't mean to underestimate you, Mohammad or any other > contributor -- I'm complaining about the development process. I have > some experience with leading the development of a project, and I see > how this CSSU could be very easily improved with very little effort. Well, going back to 80s style code review on a mailing list is a big change in effort IMHO. However, as noted on the wiki, development processes are one of the many things to define. > Now we have the unique opportunity of developing software with an > infinite amount of time and a fair amount of good developers. [...] Well, a few good developers have got stuck into the CSSU. No Nokians yet, AFAICT; although I'd love to see 'em. Given the still limited number of changes, understanding the changes being made will, I think, inform the process. Is it primarily: * Merging third party patches without their involvement * Creating repository clones & merge requests in gitorious * Writing code and committing it to the master Currently I think the second is primarily happening, with Mohammad acting as reviewer and maintainer for all the packages. Whether or not his standards correspond to yours is a different question as to whether or not code review is happening ;-) Cheers, Andrew -- Andrew Flegg -- mailto:and...@bleb.org | http://www.bleb.org/ Maemo Community Council member ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Proposal: code review process for community SSU
On Sun, 6 Feb 2011, 15:51:50 GMT, Alberto Mardegan wrote: > > Shortly after releasing the first community SSU, we already got a few > bugs: > https://bugs.maemo.org/buglist.cgi?query_format=advanced&product=Maemo%205%20Community%20SSU&classification=Extras As to be expected, as this is a *testing* release to start defining processes and get more involved. For what it's worth, the following is a less noisy query: http://j.mp/communityssu-bugs > Of these, https://bugs.maemo.org/show_bug.cgi?id=11813 was rather > critical, as we can see from the amount of duplicate bugs it got. I don't think it's critical at all. Certainly not compared with the community-ssu-enabler postinst bug before the announcement which required editing /var/lib/dpkg/community-ssu-enabler.postinst to do the upgrade. > One one hand, it's excellent that the bug was fixed so promptly; but on > the other hand, I think we should realize that the risk of completely > breaking or ruining the user experience with a non well tested SSU > update is real. This was my bad: the fix was in gitorious but not in the repo. However, I'd say this is the purpose of having a testing repo; and the clear warnings both at install time and on the Community_SSU page which say that currently it's only for those "willing to risk a reflash." > So, either we stop advertising the SSU repository, and on the contrary > make it even harder to enable than extra-devel (because potentially it > is *much more dangerous* than that!), or we think of some measures to > minimize the risks of breakage. My own thought is that a comprehensive set of test scripts can cover the main bases before something gets pushed to the stable repo. These can be crowdsourced at both writing and testing: http://wiki.maemo.org/Community_SSU/QA > PROPOSAL: MAILING LIST FOR CODE REVIEW I don't think this is the best approach though. There are many problems to overcome: * It throws away the streamlined workflow supported by gitorious.org and its "merge request" functionality. * Who would volunteer to review the code? Currently we have a surfeit of people working on the code of the CSSU, not a surplus. Given they're doing it in their spare time, drudgerous formal code review is not going to be high on their list. * In my professional experience, monolithic code reviews are rubbish at detecting bugs. One certainly wouldn't've caught #11813. Having said that, doing something informally should be fine. Gitorious offers "watch" and (IIRC) RSS functionality. If you, or anyone else, wanted to watch the commits and provide comments on maemo-developers, I think that'd be very useful. If you were doing this, you could describe "how to reactively review code" under http://wiki.maemo.org/Community_SSU/Development (and/or .../QA#Process) > At the very least, we should immediately > take the action of making the community SSU harder to enable and clearly > state in the wiki pages that it's very high risk software. I thought the wiki pages did. However, it's a wiki, feel free to iteratively improve it! Thanks in advance, Andrew -- Andrew Flegg -- mailto:and...@bleb.org | http://www.bleb.org/ Maemo Community Council member ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Allowing rotation of closed-source apps
On Sun, Feb 6, 2011 at 12:53, Thomas Perl wrote: > 2011/2/6 Alberto Mardegan : >> What do you think about all this? I didn't check hildon-desktop and mb2 >> source code yet, so if you also happen to have some hints on the >> implementation, they are very welcome. :-) > > Sounds good. Hildon-Desktop already sets the auto-rotation flag on a > window if Ctrl+Shift+R is pressed. There is a central place in H-D > where these keyboard shortcuts are handled. Going from there, you can > see how the setting of a flag is done (for the current window). There's also Robin Burchell's "rotatedaemon" in Extras-devel which does something similar using XRandR (IIRC): http://maemo.org/packages/view/rotatedaemon/ Hope that helps, Andrew -- Andrew Flegg -- mailto:and...@bleb.org | http://www.bleb.org/ Maemo Community Council member ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
ANNOUNCE: Maemo 5 gets community OS updates
The Maemo Community Council and Mohammad Abu-Garbeyyeh are pleased to announce the launch of the Maemo 5 Community SSU project. It is currently in a testing and elaboration phase, and your help is required. WHAT IS IT? === Seamless Software Update (SSU), is the term Nokia used to brand the over-the-air updates of Maemo. Community Seamless Software Update (CSSU) is being developed by the Maemo community, for the Maemo community. It aims to deliver fixes which can't be delivered easily through Extras, such as core N900 packages. It won't, however, bundle software which can be installed through the Extras repositories. It's got a presence in various Maemo forums: * IRC: #maemo-ssu on FreeNode * Bugs: bugs.maemo.org, product: Extras > Maemo 5 Community SSU * Wiki: http://wiki.maemo.org/Community_SSU * Talk: http://talk.maemo.org/showthread.php?t=67905 WHO IS IT FOR? == Long-term: all N900 users. Now: power-users, developers, Nokia/Maemo/MeeGo engineers, testers, documentation writers and those willing to risk a re-flash in order to help. HOW DO I INSTALL IT? 0) Make sure you're running PR1.3, Nokia's last official Maemo 5 update. To see if you have PR1.3, go into "Settings > About product", you should see under "Version" it has the numbers beginning with "20.2010.36". 1) Go to http://wiki.maemo.org/Community_SSU using your N900 browser. 2) Click on the "Install" arrow next to "Testing" 3) Hildon Application Manager (HAM) will launch and will prompt you with a series of messages and warnings. Click continue and let it install the community package. 4) Once done, close HAM and go into the applications menu. Look for, and launch, for "Community SSU". This will then automatically run through a series of scripts to ensure HAM will now be using community repository for updates. 5) HAM will re-open and present a system upgrade called "Maemo 5 Community SSU". Once installed, your device will reboot. These instructions are also in the wiki: http://wiki.maemo.org/Community_SSU#Installation HOW CAN I HELP? === Can you write documentation? If so, it'd be great to flesh out the wiki page with installation instructions (to make it easy for users to install without worrying about missing a step or getting it wrong); explain more about the SSU and generally spruce up the wiki page and maintain things like the changelogs etc. Were you involved in developing Maemo? If so, with Nokia now looking to Harmattan and MeeGo, we'd love to see your itches addressed in the Community SSU (CSSU). Have you always wanted to implement something in hildon-desktop, but Management stood in your way? We'd love to have it! Have you written a patch for Maemo? Raise a bug and let's get it in the CSSU. Are you a developer? There are numerous patches floating around for hildon-desktop; but they can't be included in the CSSU until they are configurable (via gconf) and default to off. Want to test? Not only testing this release, but writing test scripts so that each release of the CSSU can get sanity checked before unleashing it into a "stable" repo for end-users. How do we do it? What should be tested? How is it organised? Want to organise? There's still lots of process left to organise; hopefully there'll be bugs and features to triage and manage in bugs.maemo.org as well as communication of the testing, releases and end-user readiness of the CSSU. -- Andrew Flegg -- mailto:and...@bleb.org | http://www.bleb.org/ Maemo Community Council member ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: adaptation of Extras QA hurdles
On Thu, Jan 27, 2011 at 15:29, a.gra...@gmail.com wrote: > On 27 January 2011 16:25, Felipe Crochik wrote: >> Sorry if the question is silly but why do you think enhancing HAM is better >> than creating a new application based on appdownloader, FAP and KISSTester? > > all I know is that all people I asked to, told me that they would > prefer to have a scorpion in their pants, rather than touching the > code of HAM :D It's not that bad. > So.. I think it would be better to write a new one (maybe based on the > good ideas from the other three applications you said). Creating *another* new installer, when there are already two (fapman & appdownloader) would seem a little superfluous! They're FLOSS, fix them! Anyway, the reason enhancing HAM is better is because it's the one which is always installed. The problem with KISStester is that you have to actively install it, same with all the others. With the push the CSSU should be getting, it should be in more users' hands. Unless we take extraordinary (and almost certainly self-defeating) actions like requiring KISStester to be installed to use any software from Extras-(devel|testing). 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. Cheers, Andrew -- Andrew Flegg -- mailto:and...@bleb.org | http://www.bleb.org/ Maemo Community Council member ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: adaptation of Extras QA hurdles
On Thu, Jan 27, 2011 at 15:09, a.gra...@gmail.com wrote: > On 27 January 2011 16:05, Tomasz Sterna wrote: >> There are a lot of people using extras-testing and even extras-devel. >> Not many of them know or care about the web voting and approval system. > > or better... we need a way to let people know if the application > listed come from stable, testing or unstable tree. a column with a > semaphore would be enough.. I'm saying this since 1-2 year and > nobody listen to me. Well, this is what KISStester does. >> What we need is a voting/comments system integrated to Application >> Manager application. > > +1 same story: I proposed long time ago, nobody listening... People listened, but whilst Nokia were managing Application Manager there were two hurdles: 1) Who's going to do the work? 2) Would Nokia ship the patches? Now that Nokia's firmware releases have stopped, and the starting of the Community SSU, we're in control of #2. However, someone still needs to write the patches: http://maemo.gitorious.org/hildon-application-manager -> http://gitorious.org/community-ssu Is someone willing to do the coding? Or at least write a technical spec to make HAM integrate into OCS? Cheers, Andrew -- Andrew Flegg -- mailto:and...@bleb.org | http://www.bleb.org/ Maemo Community Council member ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: adaptation of Extras QA hurdles
On Wed, Jan 26, 2011 at 13:18, Roman Morawek wrote: > > I just want to remark, that this proposal would not change anything in > my specific situation. I'm not listed in the top-products-karma-page and > would still need 10 votes, which seems to take very long time. Indeed. This is, however, what the "super-testers" are supposed to address. > Maybe another solution is to have a higher weight on the votes > themselves. E.g. each thump up/down has a weight of > /100+1? > It would still need 10 voters with low karma but a single "super guru" > could just release a package. This is "super-testers", albeit more fine-grained. They exist now, perhaps they're not widely deployed enough or it's too fine-grained... Cheers, Andrew -- Andrew Flegg -- mailto:and...@bleb.org | http://www.bleb.org/ Maemo Community Council member ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: adaptation of Extras QA hurdles
On Tue, Jan 25, 2011 at 15:57, Felipe Crochik wrote: > > Would we still have the requirement of "official tester" vote(s) or any > community member vote will have the same weight? I'm not sure what you mean. As I understand it at the moment, the requirement is that you get 10 votes and at least 10 days. After 20 days, 3 "super-tester" votes can move the package (up or down). > Should we also give the "track-record" users votes more weight? 2 or 3 > points? I think that's what "super-testers" are for; and would suggest we don't mix them. > Of course the author should not be able to vote on his application. I'd certainly be in favour of tightening up the rules so that the only thing the uploader can do on his own package is vote it down out of -testing. > Is there a "public process" to push "urgent/critical updates" and/or to > remove dangerous packages from extras/extras-testing? I am not aware of any > but didn't look too hard for one. No, currently that's at the discretion of the Council and the Repository Manager (i.e. Niels). > p.s. How do you accumulate products karma? Release "products", which are things in maemo.org/downloads/ & Extras. Cheers, Andrew -- Andrew Flegg -- mailto:and...@bleb.org | http://www.bleb.org/ Maemo Community Council member ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: adaptation of Extras QA hurdles
On Tue, Jan 25, 2011 at 15:03, Felipe Crochik wrote: > > I assume we all agree that the two most important goals for "testing" are > making sure that the developer has "good intentions" and that the > application will not break anything. I know that in a "perfect" world we > also would like to have the testing assure that the "application" is of a > "good quality" but I think we may need to delegate this to the "entire > community" Indeed. > I like the concept of "developer in good faith/standing". I think by now we > can "trust" some "developers" in the community for not having bad > intentions. These should receive special treatment. A developer could enter > this "group" after having "published" few applications/versions w/o any > major incidents and "sponsored" by one (or more) "approved developers" Agreed. Proposal: * The first page of http://maemo.org/profile/list/category/products/ are given "track-record" status. * Other accounts can be given "track-record" status by two developers who have "track-record" status or by two "super-testers" (an existing flag). * Updates of packages from developers with track-record status have the karma threshold reduced to 5 (from 10). However, negative votes on such a package count as -1.5, rather than -1. New packages for "track-record" status still have the same karma threshold. * The "super-tester" process stays as-is to catch the edge cases. For example, if thp uploads a new version of gPodder it will be promotable after 10 days when: +-+--+---+ | Thumbs up | Thumbs down | Score | +-+--+---+ | 5 | 0 | 5| | 7 | 1 | 5.5 | | 8 | 2 | 5| +-+--+---+ > A new version of an existing application should have a lower barrier to > promotion than a new application. It's obvious; but even a minor change can have an enormous impact. However, it's unlikely that the package (once optified) will become non-optified and numerous other things (descriptions will only bitrot when major new features are introduced; icons won't disappear; bug trackers are fairly persistent etc.) > I think each developer could have a "sponsor/partner" developer (one not > involved with the application) that would be the responsible for the "final" > approval. This sponsor would be responsible to assure the original developer > is not doing anything dangerous to the system and could even help the > original developer with some suggestions. We would have a "mandatory period > of time" for the application to seat on extras-testing but the "sponsor" > would be expected to check the app before this period of time. If the > sponsor failed to do so the application author could try to find another > sponsor. TBH, I think that's over-complicated and still likely to result in many of the same delays. However, I've folded your "sponsor" idea up into my proposal above. Cheers, Andrew -- Andrew Flegg -- mailto:and...@bleb.org | http://www.bleb.org/ Maemo Community Council member ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Cannot upload screenshot: maemo.org bug
On Wed, Nov 24, 2010 at 10:08, Daniel Klaffenbach wrote: > > Again: I did not mean to be rude. I am just not aware of the exact > state of the Maemo platform and website. Everybody is talking about > Meego and Nokia not actively supporting the Maemo platform any more. Nokia is focusing development effort on MeeGo/Harmattan, sure. But maemo.org isn't a Nokia-owned site; it's owned by the community - and that's very much still active. As are the maintainers. > It's a bit irritating for normal users. The focus of Nokia's work has no bearing on maemo.org website bugs. Cheers, Andrew -- Andrew Flegg -- mailto:and...@bleb.org | http://www.bleb.org/ Maemo Community Council member ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Discontinue distributing Maemo Bug Jars via email?
On Mon, Nov 22, 2010 at 06:32, Carsten Munk wrote: > I'm pro emails, as it allows people to skim through both Maemo and > MeeGo project activity. Agreed - having push notifications is much more useful when one is travelling and time-strapped. I know I can skip an email, and deal with a subset, if I'm in a rush. Going to a pull system - whether going to a website or visiting a forum - is a *lot* harder because I either have to remember *or* deal with all the unread threads. > Occasionally I wish they were all wrapped in one email, one for Maemo, > one for MeeGo, but that's a luxury. Indeed, but that'd be a hard email to skim. Perhaps both problems (someone complaining, different bits of interest to different people) could be solved by creating, somewhere, a mailing list per topic: * meego-infrastructure-bug...@... * maemo-extras-bug...@... * ... * maemo-bug...@... * meego-bug...@... People could subscribe to the sections they want, or to the consolidated issue which concatenated them all together. Hope that helps, Andrew -- Andrew Flegg -- mailto:and...@bleb.org | http://www.bleb.org/ Maemo Community Council member ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Discontinue distributing Maemo Bug Jars via email?
On Mon, Nov 22, 2010 at 06:22, wrote: > >>Shall I continue to send them via email or not? > > while i do not mind the mail, a wiki might be more effective, especially if > the page is generated by a query to bugzilla They are already published online; what'd be the advantage of more wiki clutter? (Thinking about the problems with the QA reports) Cheers, Andrew -- Andrew Flegg -- mailto:and...@bleb.org | http://www.bleb.org/ Maemo Community Council member ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Fwd: PyQt libraries in the repositories
On Fri, 12 Nov 2010, 22:40:52 GMT, Chris Saturn wrote: > > It has been already a week that there is some problem with several PyQt > libraries in the repos. One of those threads contains a fix: http://twitter.com/#!/mwkn/status/3474687963176960 HTH, Andrew -- Andrew Flegg -- mailto:and...@bleb.org | http://www.bleb.org/ Maemo Community Council member ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Diablo Community SSU (was Re: Fremantle Community SSU)
On Tue, Nov 2, 2010 at 12:31, Lucas Maneos wrote: > On Tue, Nov 02, 2010 at 11:38:17AM +0000, Andrew Flegg wrote: > >> In particular, the Diablo branch of HAM (2.1.x) has a number of fixes, >> including the "show only valid sections, put rest in 'other'" and "lay >> out the sections more nicely". > > Interesting, would you mind filing bugs[2] for those? Or, if you (or > anyone) want to "adopt" the HAM package feel free ;-) https://bugs.maemo.org/3103 also has the "community-diablo" keyword. "Simplest" would be to try building http://maemo.gitorious.org/hildon-application-manager/mainline/commits/release_diablo directly. What's the process for adopting a package in the Diablo SSU? Not that I have many round tuits at the moment. Cheers, Andrew -- Andrew Flegg -- mailto:and...@bleb.org | http://www.bleb.org/ Maemo Community Council member ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Diablo Community SSU (was Re: Fremantle Community SSU)
On Tue, Nov 2, 2010 at 11:20, Lucas Maneos wrote: > On Mon, Nov 01, 2010 at 06:05:44PM +0200, Mohammad Abu-Garbeyyeh wrote: >> Some of you may have heard back in summer when I announced that I was >> working on an SSU, however, I decided to postpone it till PR1.3's out. >> Now that it's out, I decided to work on it again. Niels Breet (X-Fade) has >> kindly set up the repository on >> http://repository.maemo.org/community-testing/. > > Excellent! :-) Lucas, is there a plan to upgrade some of the more user-facing packages on the Diablo SSU? In particular, the Diablo branch of HAM (2.1.x) has a number of fixes, including the "show only valid sections, put rest in 'other'" and "lay out the sections more nicely". There's also a patch to get rid of the warning (or at least make it red-pill switchable which, in the community SSU, we could default to on; I think): https://bugs.maemo.org/2710 Thanks in advance, Andrew -- Andrew Flegg -- mailto:and...@bleb.org | http://www.bleb.org/ Maemo Community Council member ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Fremantle Community SSU
On Tue, Nov 2, 2010 at 08:32, Marius Vollmer wrote: > ext Niels Breet writes: > >> Problem Mohammad faced here is that HAM holds a lock, so you can't run >> apt-get in the background. This is why he needs to open the xterm and >> ask the user to close HAM. > > Yes. But what about launching that script from a launcher entry instead > of asking people to type something into an xterm? I think that inspires > a bit more confidence. The way it's supposed to work (worked for X-Fade, but not me) is that the X Terminal opens running a script which says "Please close HAM and press enter; any remaining dpkg-lock holding processes will be killed". TBH, I wonder whether that's really necessary - presumably it's possible via D-Bus to open HAM in "check for upgrade mode" (i.e. what the notifier status menu applet does). What if the postinst starts a nohup task which: 1) sleeps for some period of time (say, 5-10 seconds) 2) asks HAM to quit (simulating a close button press or just killall) 3) restarts HAM in "check for upgrades" mode. The user would have fewer interactions (clicking the "Update all" button in HAM, once restarted) and it'd be more seamless and, according to my gut, less prone to error. Thoughts? Cheers, Andrew -- Andrew Flegg -- mailto:and...@bleb.org | http://www.bleb.org/ Maemo Community Council member ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Fremantle Community SSU
On Tue, 2 Nov 2010, 00:22:28 GMT, Matan Ziv-Av wrote: > > How do you expect to get developer's feedback when you distribute > binaries without appropriate source? Even if we ignore the GPL > violation, it does not make much sense. Well, "developers" in the sense of experienced users who can diagnose HAM & postinst issues. You can already see the discussion here that, to be frank, would be swamped on TMO with "does this give me Flash 10.1" or "X Terminal didn't open, what do I do?" posts. That's fine, and I look forward to answering them, but let's get some initial testing (TBH, I'd expect that to not last too long). Having said that, having `apt-get source' is pretty essential in the next iteration. > How will included improvements be decided? > > Will there be an inclusive policy - every improvement that someone is > willing to work on will be included - or will there be a gatekeeper that > will decide what to include? > > Were this issues discussed? Were they decided? NAFAIK, that's what should be discussed - in a constructive way - now that the concept has been proved and the kinks worked out. > > I can imagine a number of ways of getting involved if you want to > > help, including carving out a space on wiki.maemo.org to deal > > with/document the issues of and around: > > > > * Release management - how does testing/QA/release work? > > Shouldn't this be discussed, before being documented in wiki? Yes, but I'd imagine a homepage being useful to frame the debate and document the outcomes. > Indeed, organizing and distributing is much harder and less fun than > actual developing, so we should be thankful for anyone who is willing to > do that, so I'll join your thanks to Mohammad, but will add a small > request: > > Please, don't upload binaries without uploading corresponding source. Agreed, and if Mohammad had any particular issues with packaging/building & uploading, I'm sure the development community would be willing to assist - just like we're seeing with the brainstorming around streamlining the enabler package. Cheers, Andrew -- Andrew Flegg -- mailto:and...@bleb.org | http://www.bleb.org/ Maemo Community Council member ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Fremantle Community SSU
On Mon, Nov 1, 2010 at 19:20, Matan Ziv-Av wrote: > On Mon, 1 Nov 2010, Mohammad Abu-Garbeyyeh wrote: > >> New system packages, all of them are based on the latest gitorious >> sources. > > Do you think that the latest gitorious sources are a stable basis? Did you > inspect the patches that were applied since PR1.3? Well, we won't know unless we test them, will we? Having said that, it seems that the Nokia maintainers have been tidying up loose ends - and, indeed, I hope we'll even see them contributing further now that they have more free rein to do "what they've always wanted". >> This is not a proper announcement for the SSU, but more of a prerelease >> before it's posted on talk.maemo.org, so please, >> do not post about this on talk. > > That does not sound right. It sounds like you are trying to split this small > community into a few communities. No, it sounds like getting proper experienced developer feedback when launching something which has real possibility to lead to a reflash. In particular, the process with the X Terminal is already a little clunky (and didn't work for me directly; but did work when I ran the postinst as root from another X Terminal, something I've already reported to Mohammad). > What is your goal in setting up this SSU repository? AIUI (and Mohammad has the full backing of this council member), the aim is to ensure that the community SSU is up and running to deliver bug fixes and improvements to Maemo 5 now that Nokia have (most likely) completely moved on. The long delay in getting similar set up for Diablo meant that a lot of the impetus was lost. Now, however, the N900 development community has yet to move on to Harmattan (and, indeed, with some of the changes may not entirely) and has many more eager users. It's the perfect time to start building on the starting point delivered by Nokia. (For example, I already appreciated the packaging that hrw did in the past, and Mohammad is now doing, of Modest with the "proper quoting" and attribution patches the community provided; but Nokia never shipped). I can imagine a number of ways of getting involved if you want to help, including carving out a space on wiki.maemo.org to deal with/document the issues of and around: * Release management - how does testing/QA/release work? * Source code management - community SSU has branches in gitorious, with "upstream" being the original projects with their Nokia maintainers? * Collaboration - new mailing list in addition to the IRC channel? * SSU utility development - improving the enabler, for example. * Build process - are these packages being built from tarballs by the autobuilder, or manually? I'd like to thank Mohammad again for his efforts over the last few months in starting this effort, and continuing with it now that PR1.3's been released. Cheers, Andrew -- Andrew Flegg -- mailto:and...@bleb.org | http://www.bleb.org/ Maemo Community Council member ___ 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 29, 2010 at 15:15, Tomi Ollila wrote: > On Sun 26 Sep 2010 12:37, Martin Grimme writes: > >> in my experience the separate developer account doesn't work for all >> stuff out of the box. The developer account lacks membership in some >> Unix groups the regular user is member of. > > Not anymore :) > > http://bugs.maemo.org/show_bug.cgi?id=11339 Isn't this a perfect example of why it should be scrapped? There'll be issues, time and code spent on trying to make ``developer'' resemble ``user''; when the simplest thing would be to just use the latter. What are the concrete issues with just using "user", and perhaps we can address them? Cheers, Andrew -- Andrew Flegg -- mailto:and...@bleb.org | http://www.bleb.org/ Maemo Community Council member ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Non-user/ packages and updating
On Tue, Sep 28, 2010 at 19:57, Eino-Ville Talvala wrote: > [snip] > > Since FCam is a publicly-available API that we're trying to promote, we're > expecting third parties to write applications that depend on fcam-drivers. > That means not all apps will be ours, and we can't do the update for them, > leaving some users with buggy versions. Already, the HDR and low-light > programs are apps by our collaborators at Nokia Research, and I don't have > any ability to update them. You only need one app to pull up the version with a >= dependency and the fcam-drivers for every app will get updated. If the user-facing application suffers from a bug, them putting out a re-release with an increased dependency once upstream (i.e. you) fixes it shouldn't be too much of a problem. If their app isn't affected by the bug (and no app really is), there's no impact on the user ;-) A little simplistic, but hopefully it helps. Cheers, Andrew -- Andrew Flegg -- mailto:and...@bleb.org | http://www.bleb.org/ Maemo Community Council member ___ 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 13:09, Polyvertex wrote: > > I think the maintainer should always have the ability to promote the ^^ > package to extras by himself [...] Short answer: no. No way. Not going to happen. Super testers, the Testing Squad, continual improvements to the QA rules and process and tools like KISStester are the answers. One could argue that perhaps a package which has been in Testing for over X months, with *no* negative votes and more than 2 positive votes, could be unlocked - because no-one's using it and so the level of harm is perhaps low. But, as Attila's said, there are other approaches being used to reduce the probability of that happening. No matter the QA process, some developers will always feel that their code is perfect and doesn't need to be tested - but developers make rubbish testers of their own code. The challenge is to get the balance right, and I'm fairly convinced that we're very close to the right balance now. Cheers, Andrew -- Andrew Flegg -- mailto:and...@bleb.org | http://www.bleb.org/ Maemo Community Council chair ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: MADDE 'developer' account - good or bad?
On Wed, Sep 22, 2010 at 12:35, Ville M. Vainio 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
Indeed.
> 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).
In my limited (to date) experimentation, I certainly found it more
painful than using `user' for a number of reasons (not least
surprise).
Yes, it might give me more protection - but the point of running
something on the device is to give a direct test of what the runtime
environment will be. It can't be that if it's not running as `user'.
In the worst (facetious ;-)) case, I could think that that exec("rm
-rf $HOME") was really not that bad an idea, and ship my app off to
Extras-testing...
Cheers,
Andrew
--
Andrew Flegg -- mailto:and...@bleb.org | http://www.bleb.org/
Maemo Community Council chair
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: suspendprocess - poor man's power save
On Sun, Sep 19, 2010 at 17:58, Robin Burchell wrote: > > 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?) I suggested something similar three years ago (wow, Maemo's old ;-)) and the reaction was less favourable: http://www.gossamer-threads.com/lists/maemo/users/26337 For example, Igor Stoppa wrote: > > You are proposing a shortcut that is encouraging crappy code to be > written, since the system will always take care of saying: "psst, > pretend to be a properly written piece of code". > > If an application has nothing to do, it _must_ be blocked waiting for > something, such as an event, a timer, whatever it cares about, nothing > else. Personally, I think it'd still be useful; without going to the (almost) co-operative multi-tasking of iOS. Cheers, Andrew -- Andrew Flegg -- mailto:and...@bleb.org | http://www.bleb.org/ Maemo Community Council chair ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: callingallinnovators maemo winner??
On Thu, Sep 16, 2010 at 21:20, ds wrote: > If I remember correctly, there was a price for the best maemo app > in callingallinnovators. > > But I can not find the winner on > http://www.callingallinnovators.com/default.aspx I was at Nokia World during the Calling all Innovators final. There were three applications in the overall shortlist which are available on Maemo: * Morpho Quick Panorama * Ansel-A * Angry Birds No mention of the $50,000 Maemo prize was made; and two of the above are also available for Symbian. Ansel-A was involved in the on-sight hackfest so a Symbian/Qt version has been started (was demoed on an N8). The N900 prize seems to have been silently dropped - unless it's awarded to the best N900 app in the main categories. However, the majority are from relatively large commercial companies; a $50k award to them is nice, but hardly game changing. I've CCed Quim in case he can find out more. Cheers, Andrew -- Andrew Flegg -- mailto:and...@bleb.org | http://www.bleb.org/ Maemo Community Council chair ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Maemo -> MeeGo migration (was Re: maemo.org team meeting Tuesday the 14th?)
[Follow-ups to maemo-developers, please] On Tue, Sep 7, 2010 at 19:22, Quim Gil wrote: > > On 09/07/2010 10:10 AM, ext Andrea Grandi wrote: >> let me understand better then. If neither a migration is planned, how >> the Maemo Community will be related to the MeeGo one? > > The question is: what would you migrate or bridge from Maemo to MeeGo? > > Some steps being done: running MeeGo in the N900, having a MeeGo Extras > process in place, [...] Without being able to reuse each other's packages - or indeed break ones own application into multiple packages - I suspect the "MeeGo Extras" process is going to fail: http://lists.meego.com/pipermail/meego-dev/2010-September/005525.html However, it seems that Intel & Nokia in their ivory towers are concentrating on app stores and single-package applications which include all their dependencies. I can understand why, given the lead that Android (and iOS, but let's at least pretend to be slightly realistic ;-)) has, but it seems the MeeGo Spec is going out of its way to sabotage community efforts. Cheers, Andrew -- Andrew Flegg -- mailto:and...@bleb.org | http://www.bleb.org/ Maemo Community Council chair ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Please remove gpxview from chinook and diablo repositories
Till wrote: > > asked to remove libgio and that's where some arguing started I don't remember seeing any arguing, but I admit I wasn't paying close attention. Anyway, the broken libgio has now been removed (Niels, correct me if I'm wrong) Cheers, Andrew -- Andrew Flegg -- mailto:and...@bleb.org | http://www.bleb.org/ Maemo Community Council chair ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Getting a phone number from an OssoABookContact
On Fri, Aug 27, 2010 at 02:30, Kurtis Heimerl wrote: > Thanks Andrew, this seems to be roughly what I'm looking for. In > particular, it seems an OssoABookContact is asubclass of an EContact, > so I can just use this stuff directly. Cool. > However, I've looked at the associated code in hermes: > and I can't find where you get the "GList" and "EVCardAttribute" > types. I've got my own implementation of a glist (stolen from > somewhere online) but I'd prefer to not have to write the > EVCardAttribute myself (wrapping the evolution code). pygobject is another unit within Hermes: https://garage.maemo.org/plugins/ggit/browse.php/?p=hermes;a=blob;f=package/src/pygobject.py;h=ccf2a6e87da91328312cd9b40b4ca9af3fcd2938;hb=HEAD HTH, Andrew -- Andrew Flegg -- mailto:and...@bleb.org | http://www.bleb.org/ Maemo Community Council chair ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Please remove gpxview from chinook and diablo repositories
On Thu, Aug 26, 2010 at 20:53, Till Harbaum / Lists wrote: > > i can't compile gpxview against this broken libgio and the libs maintainer > just doesn't care anymore. > > Therefore, please remove all versions of gpxview from the diablo and chinook > repositories. I can't update the current ones, i can't fix bugs. Thus they'd > better > be gone. Isn't the issue to complete the outstanding removal of libgio which is breaking it? Then you won't have any problems. Your continued support of Maemo 4 is appreciated, at least by me. Cheers, Andrew -- Andrew Flegg -- mailto:and...@bleb.org | http://www.bleb.org/ Maemo Community Council chair ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: extras not working - who should I talk to?
On Wed, Aug 25, 2010 at 17:28, Andre Klapper wrote: > Am Mittwoch, den 25.08.2010, 12:15 -0400 schrieb Felipe Crochik: >> Would you mind posting yours so I can compare? > > Ahem, I'm very sorry, I hadn't disabled -testing and -devel when I > tried. > > So yes, I can confirm that when only Extras is enabled mycontacts does > NOT get displayed in App Manager. > > No idea what's going on. Niels Breet is, of course, the right person to talk to. And/or Bugzilla. -- Andrew Flegg -- mailto:and...@bleb.org | http://www.bleb.org/ Maemo Community Council chair ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Getting a phone number from an OssoABookContact
On Wed, Aug 25, 2010 at 12:04, Dave Neary wrote: > > Andrew Flegg wrote: >> Here's some code from Hermes'[1] org/maemo/hermes/engine/contact.py: > > Any chance you could turn this into a use-case using the use-case > template in the wiki, please? Any particular place you can suggest? Doing it in Python is a bit icky with having to fallback to ctypes, because of deficiencies in the available bindings. Cheers, Andrew -- Andrew Flegg -- mailto:and...@bleb.org | http://www.bleb.org/ Maemo Community Council chair ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Getting a phone number from an OssoABookContact
Here's some code from Hermes'[1] org/maemo/hermes/engine/contact.py:
8<-
# Constants from
http://library.gnome.org/devel/libebook/stable/EContact.html#EContactField
ebook = CDLL('libebook-1.2.so.5')
E_CONTACT_PHONE_OTHER = 30
def get_phones(self):
"""Return a list of phone numbers associated with this contact."""
nums = []
ai = GList.new(ebook.e_contact_get_attributes(hash(self._contact),
E_CONTACT_PHONE_OTHER))
while ai.has_next():
attr = ai.next(as_a = EVCardAttribute)
types = set()
if attr.params:
params =
GList.new(ebook.e_vcard_attribute_param_get_values(attr.params.contents.next()))
while params.has_next():
types.add(string_at(params.next()))
device = 'VOICE' in types and 'landline' \
or 'CELL' in types and 'mobile' \
or None
type = 'HOME' in types and 'home' \
or 'WORK' in types and 'work' \
or None
number = string_at(attr.value().next())
nums.append(PhoneNumber(number, type = type, device = device))
return nums
--->8
If you don't speak Python, what is basically does is (dealing with an EContact,
but you can get that from an OssoABookContact IIRC:
1) Get all attributes of type 30 - this returns all
phone numbers, I've found.
2) Loop over each attribute, the value of which is
the phone number.
3) The parameters of the attribute will tell you the different
types flagged against this number.
HTH,
Andrew
[1] http://hermes.garage.maemo.org/
--
Andrew Flegg -- mailto:and...@bleb.org | http://www.bleb.org/
Maemo Community Council chair
- Original message -
> Hello maemo-developers!
>
> Does anyone know how to get a phone number (any number) out of an
> OssoABookContact instance? I'm at my wit's end; all of the online hits
> i've found have been doing the opposite and I can't figure this out.
> My guess was using the osso_abook_contact_get_value function, but I
> have no idea what the appropriate attribute would be. I've tried a
> great many (Cell, for instance) and gotten nothing.
>
> Ideas?
>
> Thanks!
> ___
> maemo-developers mailing list
> maemo-developers@maemo.org
> https://lists.maemo.org/mailman/listinfo/maemo-developers
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Building pulseaudio for N900
On Mon, Aug 23, 2010 at 15:18, Felipe Contreras wrote: > > Cc'ing some people that might have some idea. [snip] >> >> What am I doing wrong? Is there a better way? Mohammad Abu-Garbeyyeh has rebuilt PulseAudio for Fremantle recently: http://www.mwkn.net/2010/34/devel.html#devel-4 He's been using Scratchbox, as I understand it. HTH, Andrew -- Andrew Flegg -- mailto:and...@bleb.org | http://www.bleb.org/ Maemo Community Council chair ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: backgrounding/lock QA fail
On Mon, Aug 16, 2010 at 11:02, Attila Csipa 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). 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. > 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 I don't like this idea, and would rather have some mechanism (super-testers?) about having specific exceptions. For example, an application which is quick to start and usually takes all the user's focus. Two technical options would be: 1) A daemon which applications could register their process ID with, when the display locks they would be forcefully SIGSTOPped. 2) An LD_PRELOAD hack which apps could use to get themselves forcefully SIGSTOPped when certain conditions are met. Cheers, Andrew -- Andrew Flegg -- mailto:and...@bleb.org | http://www.bleb.org/ Maemo Community Council chair ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: How many times each application is downloaded from extras-devel
On Wed, Jun 16, 2010 at 17:40, Felipe Crochik wrote: > > Is there a way to find out how many times each application was downloaded > from extras-devel? It would be a valuable tool to help access if the > applications are being used (and/or are useful) and decide on how to > invest on each one. Not sure - there is once you get to Extras; click "Download Statistics" on the http://maemo.org/downloads/ page. > For one application to move out of testing it has to get votes and good > karma, right? For an application to move out of Extras-testing it has: * To spend at least 10 days in Extras-testing * Receive 10 thumbs up * Have the maintainer click the "Promote package" button. > For someone to vote they have had to install the application > from the extras-devel already and because of this don’t exactly have > any major motivation/urgency to want to push the application to > move to extras. For someone to vote they have to (or rather, should) install the application from Extras-testing. They should then compare the application against the QA rules and vote accordingly: http://wiki.maemo.org/Extras-testing/QA_Checklist The motivation for the tester is: * Altruism - more good apps get to people who aren't willing to test. * Karma - rating apps and leaving comments earns karma which has, in the past, translated to discounted devices and sponsored travel & accommodation to the summit. * Early access - they get to use apps which may not be ready for the masses. However, it's not all positives - they really take on two other facts: * Stability - it's a testing repo. Things may break. Things may break horribly. * Voting - it's effectively a covenant that if you're using Extras-testing you're saying you're willing to test & vote. > On the top of that it is not very obvious, at least wasn’t for me, how to > vote – especially because once you get the page you don’t see the vote > button until you login. Specific suggestions for improving the UI are always welcome. X-Fade's admitted he's not a web designer. CSS, HTML or even mockups of improved UIs are VERY welcome. > I assume, as it is, we mostly depend on other developers to test > and vote for the applications on testing or is there any other > driving force? There is a Testing Squad of volunteers, and a subset of those are shortly to become Super-Testers who can, after a longer time period, move the package over the threshold with a smaller number of "super" votes. http://wiki.maemo.org/Testing_Squad Hope that helps, Andrew -- Andrew Flegg -- mailto:and...@bleb.org | http://www.bleb.org/ Maemo Community Council chair ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: How to optify in MADDE?
On Thu, Jun 10, 2010 at 12:15, Tomi Ollila wrote: > > I personally dislike polluting /opt -tree with lots of application > directories (although that is allowed by FHS). Better alternative would > be /opt//... (IMHO) (also allowed by FHS), where > is 'maemo' (is that LANANA-registered (what LANANA???). FHS also says > there might be bin/, lib/, include/ and directories > intermixed there (which I don't like either). But YMMV. But polluting /opt/maemo with lots of application directories is better? If you want to encourage /opt// then should be some kind of team or individual who's behind multiple apps. Using /opt/maemo for anything other than maemo-optify output could cause confusion, if not problems. Cheers, Andrew -- Andrew Flegg -- mailto:and...@bleb.org | http://www.bleb.org/ Maemo Community Council chair ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: git over ssh access for garage projects - calling for brave testers
On Sat, May 22, 2010 at 09:13, Alberto Mardegan wrote: > Alberto Mardegan wrote: >> >> I get this: >> >> ma...@portatie:/tmp$ git clone ssh://drop.maemo.org/git/maemo-mapper >> Initialized empty Git repository in /tmp/maemo-mapper/.git/ >> fatal: ''/git/maemo-mapper'': unable to chdir or not a git archive >> fatal: The remote end hung up unexpectedly > > I already had my SSH keys (and I can upload to extras, so I guess > they are correct), but I still get the error above. Me too: 8< and...@badger:~/src $ git clone ssh://drop.maemo.org/git/hermes Initialized empty Git repository in /home/andrew/src/hermes/.git/ fatal: ''/git/hermes'': unable to chdir or not a git archive fatal: The remote end hung up unexpectedly ---->8 Has a bug been raised and/or anyone seen a solution? Cheers, Andrew -- Andrew Flegg -- mailto:and...@bleb.org | http://www.bleb.org/ Maemo Community Council chair ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Optification and plug-ins
Conny, If an application is extensible via plugins, those plugins need to be installed into a known location. For Conboy, why can't that be /opt/conboy/shared/ (or similar). What is the problem you're trying to solve, is it one purely caused by automatic optification? If so, I'm sure we can find you some assistance, if necessary, to have the bulk of your package go in /opt/conboy. Hope that helps, Andrew On 31/05/2010, Cornelius Hald wrote: > Hi, > > as there has been no news since February, I think I should see whether > or not someone is still responsible for this bug: > > https://bugs.maemo.org/show_bug.cgi?id=7707 > > Basically it means that if you have a program, which is extensible via > plug-ins, you cannot optify it. I would like to do a stable Conboy > release soon and I think it should be optified to pass QA. > > If anyone knows something - please let me know. > > Thanks! > Conny > > > ___ > maemo-developers mailing list > maemo-developers@maemo.org > https://lists.maemo.org/mailman/listinfo/maemo-developers > -- Andrew Flegg -- mailto:and...@bleb.org | http://www.bleb.org/ Maemo Community Council chair ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Quality assurance of "stable" software: my battery drained in few hours
Sivan, If you have suggestions for the QA that we can control (i.e. that of maemo.org Extras) please share them. Also, examples of problems with Ovi's QA (such as obvious battery drainers) will help Nokia see that crowdsourced QA can be better than their in-house stuff (though our 10 day process is apparently a bit longer than theirs). Cheers, Andrew On 29/05/2010, Sivan Greenberg wrote: > I also experienced that with the Facebook widget alone, but the > battery performance is also very poor without any active widgets or > connections (6 hours max!). I am also curious what sort of QA > procedures the OVI store publishing process carries, but this is what > I think only one sign of a greater problem with quality assurance that > I think is lacking across projects. > > I hope we can change this in MeeGo, and ASAP. > > Sivan > > On Sat, May 29, 2010 at 1:34 PM, Daniil Ivanov > wrote: >> Hi Andrea! >> >> On Sat, May 29, 2010 at 1:18 PM, Andrea Grandi wrote: >>> Hi, >>> >>> On 29 May 2010 12:11, Ville M. Vainio wrote: >>>> On Sat, May 29, 2010 at 1:01 PM, Andrea Grandi >>>> wrote: >>>> >>>>> I went to sleep at 3:00, I wake up few minutes ago with the N900 >>>>> powered off. There was not any active connection when I went to sleep, >>>>> so could anyone please explain me WHO drained my whole battery?! >>>> >>>> Can you ensure that your phone doesn't create connections automatically? >>> >>> yes I'm sure. I never let it connect automatically. And just for you >>> to notice: once I really forgot to disconnect before going to sleep: >>> when I wake up I still had more than half of the battery, but this is >>> of course not the case. >>> >>> So my "suspects" are: >>> >>> - the Twitter widget available in OVI (if it's this, congratulation to >>> people who publish software in OVI store without let testers to test >>> it in extras-devel / extras-testing) >> >> The key word in phrase Ovi Store is a "Store". Nobody will upload >> commercial >> applications to extras-devel or extras-testing. This is the way Ovi Store >> works. >> >> You can save battery info log with the commands: >> lshal | grep battery.reporting.current >> battery.log >> date >> battery.log >> try to use facebook widget separately, twitter widget separately >> and maybe both of widgets disabled and see how battery life is affected. >> >> Thanks, Daniil >> >>> - the facebook widget (very strange since it's available from the >>> beginning, someone should have noticed this bug) >>> - something really weird introduced with PR 1.2 (no comment). >>> >>> Regards, >>> >>> -- >>> Andrea Grandi >>> email: a.grandi [AT] gmail [DOT] com >>> website: http://www.andreagrandi.it >>> PGP Key: http://www.andreagrandi.it/pgp_key.asc >>> ___ >>> maemo-developers mailing list >>> maemo-developers@maemo.org >>> https://lists.maemo.org/mailman/listinfo/maemo-developers >>> >> ___ >> maemo-developers mailing list >> maemo-developers@maemo.org >> https://lists.maemo.org/mailman/listinfo/maemo-developers >> > ___ > maemo-developers mailing list > maemo-developers@maemo.org > https://lists.maemo.org/mailman/listinfo/maemo-developers > -- Andrew Flegg -- mailto:and...@bleb.org | http://www.bleb.org/ Maemo Community Council chair ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Stats at Maemo repository
On Mon, May 17, 2010 at 08:06, Thomas Schmidt 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. > Apart from that i think your idea is very nice. Indeed. Cheers, Andrew -- Andrew Flegg -- mailto:and...@bleb.org | http://www.bleb.org/ Maemo Community Council chair ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo Info Center library service released with first set
--- [I've changed this to go to maemo-developers, where I think it is more appropriate to be discussed, follow-ups there please] --- On Wed, Apr 21, 2010 at 14:09, wrote: >From: Andrew Flegg >> >> One thing I'd like to see is a *definitive* Maemo reference library. >> Currently, we have docs spread over Forum Nokia, Info Center, the >> maemo.org wiki - and then there's the docs that are *duplicated* (with >> slightly different versions) between the various places. > > This new Maemo Info Center library is planned to be THE place to look for > official Maemo documentation (and Maemo.org wiki will continue to be > THE place to look for unofficial docs :). Yeah, and this is the problem. See below... > I do nto think we have much documentation in Forum Nokia exception > being some training slideware and Hildon 2.2. UI guides. I have now > converted all those 4 Hildon 2.2. UI guides into laTex and I will > publish them shortly in Maemo Info Centeras official documents > (they will also be available as PDF/HTML downloadables as all > other Latex docs). Cool, thanks. > I was planning to update and release pyMameo documentation in Info Center > but it was decided last summer (2009) by our product management that we > do not release Python (pyMaemo) documentation as official documentation. > So I cannot add Python documents (and I have not even verified do we > have updated pyMaemo docs for Fremantle available). This continued separation between "official" and "unofficial" (and "open"/"closed") doesn't help developers AT ALL. Why does a developer need to know, or care, whether the framework they are using is "officially" sanctioned by Nokia, or whether - like PyMaemo - it's come from a third-party (though one whose bills are paid for by Nokia)?! I want to have a single place that I can refer to broad, deep, Maemo developer documentation. It seems that the Info Center is NOT it, solely due to the decisions of your product management. So, for me, it'd be better if someone in the community mirrored its content and combined it with the documentation for all the other parts of the real world Maemo development ecosystem. If you're able, I would strongly encourage you to try and persuade your product management into changing their mind on this. Alternatively, if you'd like me - as a representative of the Maemo community - to talk to them directly, let me know who to chat to. Thanks in advance, Andrew -- Andrew Flegg -- mailto:and...@bleb.org | http://www.bleb.org/ Maemo Community Council chair ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo Info Center library service released with first set of official maemo Fremantle 5 documentation
On Fri, Apr 16, 2010 at 18:40, wrote: > > The Maemo documentation infrastructure project has released new > Maemo Info Center documentation service for Maemo platform. > Together with Maemo Info Center service we released also the first > set of official Maemo Fremantle 5 documentation. More Fremantle 5 > documentation will be updated to the Maemo Info Center service end > of April. One thing I'd like to see is a *definitive* Maemo reference library. Currently, we have docs spread over Forum Nokia, Info Center, the maemo.org wiki - and then there's the docs that are *duplicated* (with slightly different versions) between the various places. Is it feasible to try and get things like the PyMaemo API reference into the Info Center, and any other popular developer resources (say, Gtkmm is an obvious example)? TIA, Andrew -- Andrew Flegg -- mailto:and...@bleb.org | http://www.bleb.org/ Maemo Community Council chair ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: "Donate $x" button on Packages and/or Downloads
On Thu, Apr 15, 2010 at 16:50, Tuomo Tanskanen wrote: > > While thats nice for app/widget developers, it sadly does not work > in all cases. For example both two of my apps currently in Extras > (cpumem-applet, Cellular Modem Control Buttons) do not have a menu, > a dialog or app window of any sort to place Donate button :( So > the website or HAM should include possibility to donate as well. Indeed. Similarly Catorise - I don't think people would appreciate me adding a shortcut somewhere in their apps menu which was "Donate" ;-) The same argument was used in the Mozilla Addons discussion as well: "we can integrate "donate" into the addon, so why put it on the website?" Cheers, Andrew -- Andrew Flegg -- mailto:and...@bleb.org | http://www.bleb.org/ Maemo Community Council chair ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Squeeze devkit to be installed to autobuilder
On Thu, Apr 15, 2010 at 15:21, Graham Cobb wrote: > >> However, will we have issues with version numbers? If we auto resubmit >> them, should we ensure that each package is resubmitted with a new >> version number? If so, a suffix of "-20100415" would be sufficient? > > Although I am generally against modifying developer's packages, I > agree that this is the most pragmatic solution. Anyone who doesn't > like it can submit a newer version of the package. The other solution, which Niels has suggested, is just replacing the updated packages. Since most people haven't been able to install them, this is a quick win (no real redefinition of what the version *is*). We could then approach it as: 1) Email all developers you have successfully built packages since 2010-03-24 outlining them of the situation and the actions about to be taken. (Preferably linking to the maemo.org/packages/ pages for the packages they've uploaded) 2) Swap in the rebuilt versions, with the same version number, from the test/experimental/staging area Niels built: https://garage.maemo.org/builder/.fremantletest/__packages__/ 3) Re-index the repo. 4) Resolve https://bugs.maemo.org/show_bug.cgi?id=9752 > By the way, has the change been well tested? With real packages > built with the modified SDK and installed on all existing firmware > releases? We don't want to do all this and discover it doesn't > fix the problem. Indeed. I'm not aware of any extensive testing apart from a few packages on my PR1.1.1 device. Javier/Niels? Cheers, Andrew -- Andrew Flegg -- mailto:and...@bleb.org | http://www.bleb.org/ Maemo Community Council chair ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: "Donate $x" button on Packages and/or Downloads
On Fri, Jan 22, 2010 at 12:55, Andrew Flegg wrote: > > Similarly, as Ovi takes off, it is interesting to think about how > micro-payments for ones software could make one a bit of money (100 > users at $1 each is a nice present); but whilst still having our > software as open source. There've been suggestions in the past of a > "Donate" button on each project's website, but I suggest we thrash out > a scheme - and then implement - a consistent micro-donation system for > maemo.org To kick the ball rolling on this again, since I think we can get quick wins. I've just noticed that addons.mozilla.org has exactly the kind of standardised donation form I was imagining. For example, see: https://addons.mozilla.org/en-US/firefox/addon/469 Clicking "Contribute" opens a little box asking you whether you want to make a one-time contribution of the suggested amount, a one-time donation of another amount or a regular monthly donation. With optional comment. Clicking "Donate" then takes you to a PayPal "Billing information" page. There's a Drupal module (apparently) which uses PayPal's Mass Payment API[1] and a blog post introducing Mozilla's pilot[2]. Does anyone know how it works? We must have a Mozilla developer around here, or someone with a PayPal connection! Thanks in advance, Andrew [1] https://cms.paypal.com/ca/cgi-bin/?&cmd=_render-content&content_ID=developer/howto_api_masspay [2] http://blog.mozilla.com/addons/2009/07/15/firefox-add-ons-contributions-pilot/ -- Andrew Flegg -- mailto:and...@bleb.org | http://www.bleb.org/ Maemo Community Council chair ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Squeeze devkit to be installed to autobuilder
On Wed, Apr 14, 2010 at 20:00, Niels Breet wrote: > > As part of this task we need to decide with the 'broken' or affected > packages which have been built on the PR1.2 SDK and have gotten PR1.2 > dependencies. The simple thing would be to resubmit all packages which have been built successfully since the autobuilder SDK change on 2010-03-24[1]. However if that's too complex/too large; alternatively: 1) We identify any package with a known uninstallable dependency (libhildon >= 2.2.10 being the best example, but there are a few others); and resubmit them. 2) After that, we email everyone who has uploaded a package in that time which has been built successfully and ask them to check their packages (ideally with links to the specific pages on maemo.org/packages/) and reupload. Would it also be possible to show, on maemo.org/packages/ - based on package version constraints - the minimum release required to install the app? > We can automatically import all rebuilt packages into extras-devel or we > can decide to let developers re-submit their packages after the builder > has been switched to the new setup. I definitely favour the resubmitting approach. It's easiest for developers by far; and so in terms of total effort is the lowest overall. However, will we have issues with version numbers? If we auto resubmit them, should we ensure that each package is resubmitted with a new version number? If so, a suffix of "-20100415" would be sufficient? Cheers, Andrew [1] http://lists.maemo.org/pipermail/maemo-developers/2010-March/025512.html -- Andrew Flegg -- mailto:and...@bleb.org | http://www.bleb.org/ Maemo Community Council chair ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: PR1.2 SDK for Extras-devel: how to solve?
On Wed, Apr 7, 2010 at 15:13, Bryan Jacobs wrote: > > It seems to me that the real problem is actually the difficulty in > implementing #4 above. If there were magically separate infrastructure > for each incompatible release, there would be no issue - a developer > uploads their package to each repository for which it builds > (preferably through a list of checkboxes in the web interface), and > a user selects one or more package sources that match the preinstalled > software on their device. No problems, mate. True; however what about the QA process? The UI at http://maemo.org/packages/ is getting better, but it's also getting more familiar. How do we: a) not confuse ad-hoc testers b) ensure that versions in all repos get tested? One suggestion would be to promote all versions simultaneously, but there are obvious drawbacks with that! > So the real issue is that creating a new branch requires a nontrivial > amount of work. This is a computerized system; computers excel at > automation. Why not spend the one-off time to allow for near-instant > creation of a new branch? Once that's done, future releases will just > consist of "oh, I should create a new repository for this release. Let > me run that script again with a new name and then upload the new SDK > release to it". Indeed. > Have I missed some important consideration? I think the issues aren't technical (although streamlining the repo creation is obviously part of it), but more procedural. I could be wrong. I wonder what the testing squad think (I'll poke VDVsx). Cheers, Andrew -- Andrew Flegg -- mailto:and...@bleb.org | http://www.bleb.org/ Maemo Community Council chair ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
PR1.2 SDK for Extras-devel: how to solve?
Hi, The number of issues being caused by the deployment of PR1.2 SDK to the fremantle autobuilder is becoming critical. It doesn't even matter when PR1.2 is released, as we should have a way of dealing with this in-place for the next upgrade. BACKGROUND ~~ After the PR1.2 SDK was released, Niels deployed it to the autobuilder; enacting a plan which was discussed on this list. This has caused problems with libhildon dependencies, but the problems aren't just limited to that library: http://lists.maemo.org/pipermail/maemo-developers/2010-March/025668.html Both Niels and the Council believe we should do something to assist. WHAT WE SHOULD DO ~ We *need* to do something, both to improve the situation in -devel and -testing today, and test an approach for the next upgrade. The main requirements here are, I think: * It's not an excessive amount of work * It's a viable long term strategy * The QA process doesn't get broken Thoughts and comments from developers, or anyone else with a idea, will be much appreciated. OPTIONS ~~~ 1) Deploy SDKs as they are released; treat -devel and -testing as trunk. This is what we have now, I think we can say it doesn't work if there's going to be more than a few days between SDK release and device upgrade. Since Nokia doesn't pre-announce release dates, and last minute bugs could cause problems; I think we can rule this one out. 2) Revert the builder. This is basically a step backwards. "Changing the builder config is easy. Cleaning up -devel and rebuilding the affected packages is quite some work as we don't have any scripts for that made yet." 3) Hack the SDK, create some kind of hybrid. This'd be bad enough if limited to just libhildon, but isn't viable and WILL cause unforeseen problems. Veto :-) 4) Create separate repos, build queues for pre- and post-1.2. Similar to what's been done for Extras proper. "Creating the repos will be about a day work, but the part that sits on top of that (management scripts, Packages interface, QA queue) will probably take a week of work." There are hard issues around QA here. 5) Try building in each SDK in turn. My suggestion; when someone uploads to "fremantle" auto-builder it attempts to build the package against the PR1.1 SDK. If it succeeds, it goes into Extras-devel. If it fails to build, it gets built with the PR1.2 SDK, and so on. For an app with compile time symbol resolution (e.g. C/C++), this'd handle both cases quite nicely. Python apps would have to depend on the specific versions of bindings which gave them the features they wanted - again, not too much of a problem. At extras(-stable) promotion time you could even decide, based on actual binary package dependencies, whether to put in fremantle-1.2 or both fremantle-1.2 & fremantle extras repos. This would fix another common complain, "what if I don't upgrade for a few weeks". Larger packages could be prevent from being tried to built twice by stating a forced build dependency on a PR1.2 version of any system package. Some software won't install from -devel and -testing as it does now, but that will be reduced to the set of software which is actually using features that are unavailable. A HAM patch could grey out applications which were uninstallable, or show some other indication. This is, effectively, reinventing the more intelligent dpkg-shlibdeps: http://wiki.debian.org/Projects/ImprovedDpkgShlibdeps However, it deals with the following three circumstances: 1) Application uses API which has changed in later SDK. This will be built with PR1.1 SDK, succeeds and goes into Extras-devel. Can be promoted to Extras-testing but there's no clear way for a tester to know it won't work if their device is running the latest OS. 2) Application uses API which is unchanged in later SDK. This will be built with PR1.1 SDK, succeeds and goes into Extras-devel. Can be promoted to Extras-testing and tested on any device with PR1.1 or PR1.2. Once promoted it COULD go into fremantle and fremantle-1.2. 3) Application uses API which is introduced in later SDK. This will be built with PR1.1 SDK and fail. It will be rebuilt with PR1.2 SDK, succeed and go into Extras-devel. Can be promoted to Extras-testing and tested by testers using the most recent release. Once promoted it will go into fremantle-1.2. 6) Case-by-case basis. Developer complains: add a temporary exception to autobuilder to build $APPNAME with PR1.0/1.1 SDK, but goes into the shared extras-devel as now. Thanks in advance, Andrew -- Andrew Flegg -- mailto:and...@bleb.org | http://www.bleb.org/ Maemo Community Council chair ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: ssh uploading to gregale/bora/chinook extras broken?
On Wed, Apr 7, 2010 at 10:16, Frantisek Dufka wrote: > > I have a problem with upload binary deb to gregale/bora/chinook extras. > Is this supposed to be working? First I noticed that server key was > changed so I needed to remove old one from known hosts. And then > uploading via dput still fails with permisison denied, see below > > Permission denied (publickey). > [...] fano...@garage:/var/www/extras/incoming/gregale' Should this now be drop.maemo.org? The change wasn't well communicated at all, especially the impact on the legacy servers. One of the advantages of the new servers was to fix bug #3354. If the old server is still used for legacy builds, you might still be seeing it: https://bugs.maemo.org/show_bug.cgi?id=3354 HTH, Andrew -- Andrew Flegg -- mailto:and...@bleb.org | http://www.bleb.org/ Maemo Community Council chair ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Dependency problems after PR 1.2 update to extras builder
On Tue, Mar 30, 2010 at 16:23, Robin Burchell wrote: > [snip] > > To the best of my knowledge (from talking to Qt on Maemo folks), there > is now API/ABI stability, and as such, this shouldn't cause issues > again. This isn't an issue only affecting Qt apps, though - as Qt isn't the only change in PR1.2. Indeed, Hildon has had new symbols added to support HildonLiveSearch[1][2] and this is what causes the "libhildon (>= 2.2.10)" Depends. Cheers, Andrew [1] http://people.gnome.org/~csaavedra/news-2009-12.html#D22 [2] http://maemo.gitorious.org/hildon/hildon/blobs/master/examples/hildon-live-search-example.c -- Andrew Flegg -- mailto:and...@bleb.org | http://www.bleb.org/ ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Dependency problems after PR 1.2 update to extras builder
On Tue, Mar 30, 2010 at 16:20, Dave Neary wrote:
>
[snip]
>
> And from the point of view of a user, an application which was
> previously available is no longer available if the developer has tried
> to update it recently?
>
> I don't really understand why uploading an app to extras-devel has
> hidden the app which is in extras (PR 1.1.1). Isn't that a bit like if I
> uploaded a package to Squeeze & no-one could download it for Lenny
> any more?
If the user only has Extras enabled, they can still get the PR1.1 app
which is in Extras. However, if they have -devel enabled (and it has a
newer version), HAM will only show the newest version.
If the developer then promotes the -devel version to -testing, the
testers will only be able to install it on a PR1.2 device. So if there
are any promotions to -testing now, we will have a mixed PR1.1 and
PR1.2 queue.
However, if promoted from -testing to Extras proper, the package will
go into a *different* Extras ("fremantle-1.2"). Extras is separate,
-testing and -devel are not.
Cheers,
Andrew
--
Andrew Flegg -- mailto:and...@bleb.org | http://www.bleb.org/
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Builder now runs PR1.2 SDK with Qt 4.6 support
On Wed, Mar 24, 2010 at 14:07, Niels Breet wrote: > > I've installed the new PR1.2 SDK on the maemo.org Extras autobuilder. > Developers are encouraged to test their application in the PR1.2 SDK to > see if everything still works as expected. Following some confusion[1][2], I've had a chat with Niels today and the following wasn't clear (to me): * The plan[3] affects Extras only; not -devel and not -testing. * Extras-devel is now being fed from the PR1.2 SDK. * This means that auto-generated libhildon dependencies are being specified too tightly to install on devices and SDKs lower than PR1.2 (due to the introduction of new symbols for livesearch[4]) Niels is looking at a fix for the libhildon dependencies[6]. In the meantime, whilst waiting for PR1.2: * Updates to software in -devel will result in it not being installable; and the old package will no longer be available. * Things can be pushed to -devel and -testing, testing in Scratchbox so that software using the new features can be in Extras when PR1.2 finally lands. Matan Ziv-Av mentioned the replacement of extras-devel three days ago but didn't elaborate, and it sounded like misunderstanding. Hope that helps, Andrew [1] http://lists.maemo.org/pipermail/maemo-developers/2010-March/025627.html [2] http://mg.pov.lt/maemo-irclog/%23maemo.2010-03-29.log.html#t2010-03-29T08:01:18 [3] http://lists.maemo.org/pipermail/maemo-developers/2010-February/024876.html [4] http://people.gnome.org/~csaavedra/news-2009-12.html#D22 [5] http://maemo.gitorious.org/hildon/hildon/blobs/master/examples/hildon-live-search-example.c [6] http://mg.pov.lt/maemo-irclog/%23maemo.2010-03-30.log.html#t2010-03-30T17:13:33 -- Andrew Flegg -- mailto:and...@bleb.org | http://www.bleb.org/ ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Dependency problems after PR 1.2 update to extras builder
On Mon, Mar 29, 2010 at 15:37, ianaré sévi wrote: > > After making some updates to my package and putting it up on > extras-devel, it won't update on the device from the repository. I was > able to install it on scratchbox (both prior to and after updating the > SDK). So, AIUI (and others did too), the autobuilder would be upgraded to PR1.2's SDK and start publishing to "fremantle-1.2" (rather than the current "fremantle"). However, yesterday on IRC, there were some complaints that the auto-generated components for things in "fremantle" extras-devel had incorrect dependencies: http://mg.pov.lt/maemo-irclog/%23maemo.2010-03-29.log.html#t2010-03-29T08:01:18 (see conversation primarily between Jaffa, Stskeeps, DocScrutinizer and Chiku|dc) I thought the fremantle extras-devel should now be fixed, so how are things with incorrect dependencies getting in? Niels, could it'd've been a race condition during the switch; or is it a bug; or are we corrupting fremantle extras-devel? Thanks in advance, Andrew -- Andrew Flegg -- mailto:and...@bleb.org | http://www.bleb.org/ ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: maemo-developers Digest, Vol 59, Issue 25
2010/3/26 Urho Konttori : > [snip] > > The problem of X-fade is not HAM, [...] I believe you did this before, so I'll correct you - I think you mean Khertan :-) Cheers, Andrew -- Andrew Flegg -- mailto:and...@bleb.org | http://www.bleb.org/ ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Ask for removal of some packages from Extras Fremantle repository
On Tue, Mar 23, 2010 at 00:20, Attila Csipa wrote: > 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). 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. If 3b applies, maemo.org has to continue to host the source. If 3c applies, Benoît has to continue to offer the source, but maemo.org must provide a way of exposing that point of contact to users. Perhaps http://maemo.org/packages/view/pygtkeditor/ would display "please contact the maintainer for source". Cheers, Andrew -- Andrew Flegg -- mailto:and...@bleb.org | http://www.bleb.org/ ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Fremantle: detecting when in task navigator view
On Mon, Mar 22, 2010 at 16:54, Luca Donaggio wrote: > > As gtk windows of type GTK_WINDOW_POPUP are not managed by the desktop > manager, I wish to be able to hide them when users click on the task > navigator icon (otherwise they stay there even after users have switched to > another application!); is there a way to do that (maybe a DBUS signal or > wahtever)? I've used the focus-out event in the past (e.g. in Attitude) to stop updating the display when not in the very foreground. HTH, Andrew -- Andrew Flegg -- mailto:and...@bleb.org | http://www.bleb.org/ ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Can someone take care of bugs #9494 and #9608 the web interface is on what rely tester to thumb down
2010/3/18 Benoît HERVIER : > > Can someone take care of bugs #9494 and #9608 ? As the web interface > is on what rely tester to thumb down ! For those wondering: - Old icon is displayed instead of the new one https://bugs.maemo.org/show_bug.cgi?id=9494 I'm tempted to mark WORKSFORME - I open the URL given and I see a filled green triangle with a small triangle cut out of the bottom on a transparent background, this *seems* to be the icon you're describing, but perhaps screenshots attached to the issue would help ;-) - Wrong bugtracker link https://bugs.maemo.org/show_bug.cgi?id=9608 This was in the wrong product & component; so I've moved it. It'd probably help to have a link to the source tarball for the package in the bug report, though. I assume your control file has: XSBC-Bugtracker: mailto:kher...@khertan.net ...and that the bug is that it is output as which was the value of the control file field in an earlier version of the package? The way to get bugs fixed is to put as much information in them, so being explicit about values rather than "in the control file". > Two weeks ago i've thought, ok let an other try before making your own > repository. Failed. #9608 is a big problem, of course, but I don't see why #9494 would encourage you to create your own repository apart from just adding to a feeling of general malaise with Extras. Cheers, Andrew -- Andrew Flegg -- mailto:and...@bleb.org | http://www.bleb.org/ ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Icons are just a few bytes, right ?
On Fri, Mar 12, 2010 at 11:50, Tor wrote: > > One thing I forgot to mention in the previous message.. /var/cache > should never have been on the root filesystem, it must be one of the > most obvious candidates for the eMMC as soon as that's feasible. Fixed in PR1.2: https://bugs.maemo.org/show_bug.cgi?id=5746 Cheers, Andrew -- Andrew Flegg -- mailto:and...@bleb.org | http://www.bleb.org/ ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: FatELF Re: rpm vs. deb and "universal binaries/packages"
On Wed, Feb 17, 2010 at 16:07, Shuduo Sang wrote: > > that is what apple do in their universal binary format. it benefits for > end-user who do not know detail what their device running on arm or x86. > for the hacker want to reduce size, they can strip it to normal > architecture-dependent binary too. One thing we learnt in the Maemo community many years ago - and are still trying to get across occasionally - is that "installing random software from a .deb (or .rpm) file" isn't a good way to build a cohesive and reliable platform. FatELF or some new extensions to an existing packaging format would be wonderful if having users install random binaries from random locations on the Internet was a useful requirement. What's the use case? Why can't said user get content from an architecture aware repository/app store? Cheers, Andrew -- Andrew Flegg -- mailto:and...@bleb.org | http://www.bleb.org/ ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: rpm vs. deb and "universal binaries/packages"
On Tue, Feb 16, 2010 at 11:17, Christopher Intemann wrote: > On Tue, Feb 16, 2010 at 11:56 AM, Andrew Flegg wrote: >> On Tue, Feb 16, 2010 at 10:46, Christopher Intemann >> wrote: >> >> > Of course, this would probably double the size of the rpm/deb, [...] >> >> ...and so the download. > > Yes, that's true, but since we're talking about mobile devices with > limited hardware, the apps are usually not that big anyways. I was just > thinking that the benefit would outbalance the size issue, at least as > long as we're talking about download sizes of one or two megabyte. Qt 4.6 and Python are *both* above the 30MB mark. > Sure, but is there a recent i386 port of Maemo at all? :-) Err, anyone who uses Scratchbox and develops on their PC rather than the device is running i386 Maemo. Cheers, Andrew -- Andrew Flegg -- mailto:and...@bleb.org | http://www.bleb.org/ ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: rpm vs. deb and "universal binaries/packages"
On Tue, Feb 16, 2010 at 10:46, Christopher Intemann wrote: > Since MeeGo is about to be released as well for the ARM as the Intel > platform, I really wonder whether either of the package formats (rpm/deb) > has the capability to include both binaries (ARM and Intel) but install > only the matching one automatically? Why not leave it up to the builder? Our current auto-builder, and OBS (as used by Moblin & MeeGo) both support the building of multiple architectures into multiple repositories. > Of course, this would probably double the size of the rpm/deb, [...] ...and so the download. > It would then be more transparent for the enduser to install additional > packages without having to think of their hardware architecture... Surely the user is going to be getting the package through some kind of package manager which makes the distinction moot? How often have you had to decide between i386 or armel debs on your Maemo device to date? Cheers, Andrew -- Andrew Flegg -- mailto:and...@bleb.org | http://www.bleb.org/ ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Qt 4.6 & Extras
On Wed, Feb 10, 2010 at 16:25, Robin Burchell wrote: > On Wed, Feb 10, 2010 at 4:19 PM, Jan Knutar wrote: >> Is the plan to upgrade the qt4.5 libs, or to have both? If the latter, >> will they be installed to /opt? > > From talking to folks in #qt-maemo, I believe the plan is to replace > Qt 4.5, and remove the /opt hack. AIUI, PR 1.2 is still having /opt; so why would Qt 4.6 not use it? OK, so it's problematic for things that are part of the base system to use /opt, but if the Qt 4.6 libraries which will be included take up more room than the out-of-the-box installed Qt 4.5 libraries then PR 1.2 will take up more of the rootfs space. Some advance warning from the Qt folks/Nokia might be in order, in that case; especially given the levels of support the community give to people on talk.maemo.org when they get a full rootfs. Cheers, Andrew -- Andrew Flegg -- mailto:and...@bleb.org | http://www.bleb.org/ ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: [New Developer]: Questions - Python Packaging / Free or Non-Free / Software Licensing
On Mon, Feb 8, 2010 at 00:18, Sanjeev (EIPI) wrote: > > As I said, I am new at this, so I did not see some of these issues before > starting development. The points you make are quite valid, and I did not > realize that python was distributed as source. That may sound obvious to > many, but I am not a s/w person at all. > > I wonder how independant developers are making use of this API then? It > confuses me greatly. In my opinion, you should go to "best efforts"; and here are some suggestions to try and keep the key (slightly) hidden: 1) non-free package ~~~ * Create a non-free (i.e. binary) package which contains your API keys encrypted in some way (perhaps just XORing the values) and a small C program which decrypts them. * Create your Python package as normal, with a `Depends' on the non-free package and call the small C program from within your app. It's not "real" security, but that should be OK. The biggest problem I can see is that the C program would then be callable by any other developer. 2) Retrieve keys at install time * Create your Python package as normal, but ensure it does not contain the keys. * In your package's postinst you can be fairly sure there's a network connection, so retrive the keys from a known URL. * You could even have it so that the URL is a small little PHP script which has a list of MD5s for the main Python file and that this is sent as a query parameter. When a new version is released you get the package from Extras and add the MD5 to the PHP file. You could even XOR things with the MD5 sent so that you get an extra layer of obscurity. > FWIW - the application I made provides a simple UI so that a user > can enter an airline, and flight number. The app then uses the > flightstats.com API to search for the flight's current status. > The app provides a list of airlines so that the user does not have > to know the airline code. Sounds excellent. It's worth bearing in mind that almost every app using this API, on every platform will be able to have the keys retrieved unless there is an in-built security mechanism such as that being developed for Maemo 6. However, even then, distribution mechanisms could be the weakest link. At some point, flightstats.com will have have to trust a device (whether N900, desktop, Nexus One or jailbroken iPhone) which could be in a malicious user's hands. Hope that helps, Andrew -- Andrew Flegg -- mailto:and...@bleb.org | http://www.bleb.org/ ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: "Donate $x" button on Packages and/or Downloads
On Fri, Jan 22, 2010 at 14:04, Andrea Grandi wrote: > > my suggestion at this point is: someone write a working piece of code > (C, C++, Python) that developers can reuse to integrate a "Donate" > button in their "About" dialogs. The user will be able to customize it > with his PayPal account, the default amount, ecc... what do you think > about? And what about packages which don't *have* an "About" box, or even a UI? e.g. plugins for gstreamer & Telepathy; Catorise etc.? I'd also worry about visibility - remember this isn't SOLELY about getting some small extra cash to developers, but also giving the impression that maemo.org/downloads/ is playing with the big boys. Cheers, Andrew -- Andrew Flegg -- mailto:and...@bleb.org | http://www.bleb.org/ ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: "Donate $x" button on Packages and/or Downloads
On Fri, Jan 22, 2010 at 13:35, Aldon Hynes wrote: > > That said, there are lots of issues that such a system would run into, as > the N900 is distributed in many different countries with many different > payment systems and for that matter, many different tax laws. My gut > feeling is that connecting to existing micropayment systems, particularly, > perhaps some related to the gaming industry, might be a good way of doing > this. Do you know of any global-micropayment systems which have a simple API? The only one I'm really aware of is PayPal (which is slightly more macro- than "proper" micropayments). Having a system which allows you to redirect to a page to "send money to this email address" means that maemo.org is entirely out-of-the-loop. Meaning, at least, the community as a whole & maemo.org don't have to worry about the tax/legal implications (IMHO). Cheers, Andrew -- Andrew Flegg -- mailto:and...@bleb.org | http://www.bleb.org/ ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: "Donate $x" button on Packages and/or Downloads
On Fri, Jan 22, 2010 at 13:41, Marcin Juszkiewicz wrote: > > Give them a choice? There are apps in AppStore which are available in > basically same version for free and for few euros so user can choose. Maintaining the same version in two different places, with different meta-data seems like a PITA. The user'd have to buy, but not install, the app if they then wanted to donate post-install. And note I'm NOT suggesting we implement a payment system on maemo.org; just a way of linking to a PayPal page on behalf of the developer, and that this would provide benefits to the developer and maemo.org overall. *Every* single review of the N900 - if it mentions maemo.org at all - views it as a niche place for apps. Cheers, Andrew -- Andrew Flegg -- mailto:and...@bleb.org | http://www.bleb.org/ ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: "Donate $x" button on Packages and/or Downloads
On Fri, Jan 22, 2010 at 13:27, Marcin Juszkiewicz wrote: > [snip] > > But having "Donate" button in each and each Maemo app looks strange for me. If > author (not packager, but author) wants money for his application then let we > talk with nokia to make Ovi store more open for small developers so app can be > sold that way for 1-5€ maybe? And if I want it to be open source, and not HAVE to have my users pay? >> Having to pass from a website is a non-sense for me, just like the >> actual Ovi Store :P > > Yep - why duplicate it? And how fast nokia would take steps to kill it? You think Nokia would block this on maemo.org? I strongly doubt it, TBH. For two reasons: 1) Quim's previously participated in a number of threads about rewarding open source development when the author wants a donation. 2) It would totally destroy the separation Nokia has been working on cultivating with maemo.org. Cheers, Andrew -- Andrew Flegg -- mailto:and...@bleb.org | http://www.bleb.org/ ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: "Donate $x" button on Packages and/or Downloads
On Fri, Jan 22, 2010 at 13:01, Matan Ziv-Av wrote: > > I thought maemo was supposed to be a free software community. The standard > way of supporting applications should be patches. And testing, documentation, bug triaging, icon design, user support, ... However, you're now competing against the lure of a relatively closed-source, fixed-price, have-to-pay app store. Where do you want new development to go? I posit that a high-profile donation system WILL be useful in keeping apps open source and surely that's best for a "free software community"? Cheers, Andrew -- Andrew Flegg -- mailto:and...@bleb.org | http://www.bleb.org/ ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: "Donate $x" button on Packages and/or Downloads
On Fri, Jan 22, 2010 at 12:58, Matan Ziv-Av wrote: > > Do you not think that if you ask for a donation (be it 1$ or 100$) for this > work, it should be clear what this work is? Currently the page claims that > you wrote vim. If you add a donation button to that, it becomes fraud. Then moan at me if I ask for a donation for vim :-p However, if you're suggesting that there's an additional description field - or there's a convention of justifying a donation in the Description field - I'll happily include: "This port is possible because of the effort the authors have put into MUD, an automated system for packaging upstream tarballs as Maemo packages. This work is not only of benefit to a port of vim, but also is used to build the packages for the GPE PIM suite, the Vala programming language and several other packages in regular use by many Maemo users. In addition, there are a series of small tweaks to vim itself to better suit the small screen, keyboard and onboard storage." ...but that seems quite long, albeit very transparent. Cheers, Andrew -- Andrew Flegg -- mailto:and...@bleb.org | http://www.bleb.org/ ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo extras repository package uploader/maintainer verification?
On Fri, Jan 22, 2010 at 12:59, Simon Pickering wrote: > > I'd suggest that the autobuilder checks to see that the uploader's email > address is included in one of the *Maintainer fields; but there is the > slight problem of what happens when someone is uploading someone else's > package (e.g. as a favour when they are away from a build machine)? There's also packages which are maintained by a team but uploaded by an individual. Cheers, Andrew -- Andrew Flegg -- mailto:and...@bleb.org | http://www.bleb.org/ ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: "Donate $x" button on Packages and/or Downloads
On Fri, Jan 22, 2010 at 12:37, Matan Ziv-Av wrote:
>
> One immediate issue comes to mind - the actual connection of the donation
> seeker to the project needs to be prominently displayed, while now it can't
> be known.
Most of the time, I'm expecting there to be a one-to-one relationship
between the donation seeker and the primary project author/maintainer.
This is a way of trying to monetise, slightly, maemo.org so that
everyone who has an idea can still go the open source route with a
possibility of making just a tiny bit of money.
> http://maemo.org/downloads/product/Maemo5/vim/
>
> I see that you (together with Marius Gedminas) wrote this marvelous text
> editor, which in my estimation took thousands of work hours, so I'll happily
> donate to you. Does this sound fair?
If we asked for a $1 donation, then yes - I think that's fair.
Repackaging vim isn't free, after all, and it's an optional donation.
Obviously it would be stupid of us to ask for a donation of $20
because:
a) we didn't write vim and there'd be threads all over the place
about it;
b) no-one would donate
Cheers,
Andrew
--
Andrew Flegg -- mailto:and...@bleb.org | http://www.bleb.org/
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: "Donate $x" button on Packages and/or Downloads
On Fri, Jan 22, 2010 at 12:35, Andrea Grandi wrote: > > it's a nice idea, but... why user has do go to maemo.org website to > donate? Shouldn't we integrate this even in Application Manager and/or > in the "About" dialog of every application? App Manager has a long lead time to get to users. Within every application requires more work on the part of the developer ;-) > Having to pass from a website is a non-sense for me, just like the > actual Ovi Store :P > I wish that (for example) user would be able to download (and pay if > they're not free) Ovi applications directly from Application manager. I agree; however having it on the web makes it more easy; and typing a credit card number paypal.com is easier on my desktop :-) Cheers, Andrew -- Andrew Flegg -- mailto:and...@bleb.org | http://www.bleb.org/ ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: "Donate $x" button on Packages and/or Downloads
On Fri, Jan 22, 2010 at 12:31, Valerio Valerio wrote:
> On Fri, Jan 22, 2010 at 12:21 PM, Sascha Mäkelä
> wrote:
>>
>> Yes, I would definitely be in favour of a centralised donation system.
>> However, instead of the suggested amount set by the author, why not
>> have a general minimum amount (say like €1) accepted per app? Then the
>> the user who wants to donate, would select the amount and the app(s).
>
> Seems a really good plan, I'm with Sascha here, we can agree in a minimum
> and eliminate one of the extra fields.
What if, as an author, I think users who want to donate should donate
about $1 for Catorise, and $2 for Hermes? Given there's no processing
overhead for maemo.org, why not let application authors set whatever
they want? (even $0.10?)
By having an amount suggested, it'll feel more like an app store - and
I *think* users who don't have to decide how much to donate ("is such
a low amount derisory?") will donate, on average, more.
Cheers,
Andrew
--
Andrew Flegg -- mailto:and...@bleb.org | http://www.bleb.org/
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers
"Donate $x" button on Packages and/or Downloads
BACKGROUND ~~ A number of articles recently have talked about Ovi Store as the only "real" app store for Maemo; massively overlooking http://maemo.org/downloads/ Similarly, as Ovi takes off, it is interesting to think about how micro-payments for ones software could make one a bit of money (100 users at $1 each is a nice present); but whilst still having our software as open source. There've been suggestions in the past of a "Donate" button on each project's website, but I suggest we thrash out a scheme - and then implement - a consistent micro-donation system for maemo.org REQUIREMENTS * User can make quick donations to apps they like. * There is a suggested amount, set by the author, to indicate that even small donations are appreciated. * The button is in a consistent and logical location, with the easiest place to put it on maemo.org/downloads/ and probably also maemo.org/packages/. * Developers can receive donations direct from the users, without maemo.org taking a cut. SPECIFICATION ~ Two new debian/control fields would be introduced: XB-Maemo-Suggested-Donation - amount, in dollars (or euros) which would be shown on the button. If not present, no donations are expected. XB-Maemo-Donation-Recipient - email address to whom user will be donating. Downloads and Packages would be updated[1] to show a button at the bottom right of the package description: "Donate $2" (showing the amount from Maemo-Suggested-Donation) ...with a small "what's this?" link underneath linking to a help page explaining that it's entirely voluntary, maemo.org takes no cut and is a direct donation, using PayPal, between you and the maintainer. Clicking the button will use the PayPal API[2] to redirect the user to a "$PACKAGE donation" page with the amount prefilled and the recipient fixed. NEXT STEPS ~~ There are Brainstorm and Talk threads on this issue; so the next-steps, as I see it are: * Link up discussions from elseweb. * Find a stakeholder (happy for it to be me) * Come to a consensus on the technical implementation, and get signed off by X-Fade. * Develop the changes and submit to maemo2midgard. * Test, deploy & use. Perhaps this is an opportunity to use the project management approach outlined by Stskeeps[3]? Comments, as ever, very welcome. Cheers, Andrew [1] https://garage.maemo.org/plugins/scmsvn/viewcvs.php/?root=maemo2midgard [2] https://cms.paypal.com/us/cgi-bin/?&cmd=_render-content&content_ID=developer/e_howto_html_donation_buttons [3] http://talk.maemo.org/showthread.php?t=41092 -- Andrew Flegg -- mailto:and...@bleb.org | http://www.bleb.org/ ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
