Re: [MeeGo-dev] Who will keep pushing MeeGo?
Hi, On 09/30/2011 01:35 PM, Dayo wrote: On 09/30/2011 12:28 PM, Andre Klapper wrote: On Fri, 2011-09-30 at 12:22 +0100, Dayo wrote: If there are - as you say - no differences between MeeGo and Tizen Dave did not state that. He certainly implied it as an "encouragement" to others to leave MeeGo and join Tizen. Not sure why you would pretend otherwise. I asked what I think is a reasonable question. Why is anyone emotionally attached to MeeGo, rather than Tizen? To answer your question: It seems to me like Samsung did not want to be seen as taking Nokia's hand-me-downs, and preferred to rebrand. I'm guessing that Intel felt that adding a top tier handset partner to the project was worth the PR hit they are taking for abandoning "Yet Another Dead Mobile Platform". I'm also guessing that a certain number of people suggested that if MeeGo's market was: * people interested in open source platforms on cool mobile devices * vendors looking for an alternative to iOS which would not have them depending on a single supplier (Google) which also owns a direct competitor (Motorola) * 3rd party developers looking for a new market that the move to Tizen would be at worst irrelevant (they're both "open source platforms"), and at best an improvement (HTML5 vs QML). Another added advantage: MeeGo 1.3 was, I hear, below quality and running late. By moving to an SLP based platform, MeeGo gets an existing platform that's actually shipping in devices and has been proven to work. Of course, this advantage also comes with challenges: parts of SLP were closed, and moving to it will result in significant investment in MeeGo being dropped. Anyway - I have no special information about how the discussions went down, but if I were in the room, those are some of the things I would have been saying. Cheers, Dave. -- Dave Neary GNOME Foundation member dne...@gnome.org Jabber: nea...@gmail.com ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] Who will keep pushing MeeGo?
Hi, On 09/29/2011 08:00 PM, Leonardo Luiz Padovani da Mata wrote: So, Intel decided to left MeeGo, it's clear that their effort on the platform has gone. We need to organize the community to keep MeeGo development. Why? (Honestly, why *must* we organise the community?) I think that many other companies have interest in continue the development of MeeGo. Metasys consider MeeGo the best sollution available for Netbook platform and we are already deploying MeeGo on schools. For us the development continue, i think we (the community) need to settle new goals and reorganize the governance of MeeGo. MeeGo is a collection of open source software components. Tizen will also be a collection of open source software components. which of those components will be different? There will certainly be a few, but I don't know how many. Which of the new components are currently closed and will need to be freed, and which of them are already free? I don't know. Are there any software projects that people are attached to, which will not be part of Tizen? Dunno... I guess there was a nascent Buteo community, there's a little momentum around ConnMan (but as far as I can see, almost none around oFono); all of the netbook GTK+ based apps and components (all the "zones") appear to have no community at all. I guess what I'm saying is, what's the difference between MeeGo and Tizen? And if they're not that different, why stay here, rather than go there? Cheers, Dave. -- Dave Neary GNOME Foundation member dne...@gnome.org Jabber: nea...@gmail.com ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] Reg. Creating account in build.meego.com
Hi, On 09/14/2011 09:19 AM, Somisetty Sreegowri wrote: As per the link http://wiki.meego.com/Build_Infrastructure/Packagers_Developers#How_to_get_started, trying to create an account in build.meego.com. As per the steps provided, first need to file a bug. But when I try to file a bug it is requesting for user name and password. Due to this I am not able to proceed with the further steps. Kindly let me know how to create a account in build.meego.com The first step is to create a meego.com account. I just had a look to give you a link to the "Register" page, but it seems to be unavailable at the moment - or at least, I can't find it anywhere. Is this related to the linux.com break-in & servers being taken offline, by any chance? Cheers, Dave. -- Dave Neary GNOME Foundation member dne...@gnome.org Jabber: nea...@gmail.com ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] LF will not permit apps.meego.com : say hello to apps.formeego.org
Hi, On 08/02/2011 11:59 AM, Jeremiah Foster wrote: On Tue, Aug 2, 2011 at 9:44 AM, David Greaves wrote: "The Linux Foundation have told us in private conversations that they will not permit apps.meego.com to be served from the MeeGo.com infrastructure hosted by them. They do not have the resource at this time to provide a statement giving their reasons. We can not assess what other services may be impacted in the future." This type of behavior is fundamentally anti-community. This shows the Linux Foundation's complete disinterest in users and developers, they're beholden to the corporate "sponsors" and donors who pay their bills. It's certainly easy to characterise things this way - but I think it's a cheap shot, and not a fair reflection on the Linux Foundation. From where I am standing, with no special knowledge at all, it looks like the Linux Foundation is simply a risk-averse organisation, conscious of the potential knock-on effects that any legal issues could cause for their members and the projects they host. It looks to me like legal counsel has a pretty big say in some strategic decisions the foundation makes, more so than corporate members (in fact, there are a couple of examples of corporate members pushing for things which met with some resistance in the Linux Foundation). If my impression is correct, then you're not achieving anything with this characterisation - on the contrary, our potential advocates inside the foundation and among their members are reading what you write, while the legal advisors responsible for the decision are not; you're potentially forcing potential allies to circle the wagons, so to speak. I obviously hope that we find a way around the issues - perhaps EU hosting, a different domain name, or a second legal opinion judging that the risk is acceptable - but let's try not to be too hasty with the finger-pointing. Cheers, Dave. -- Dave Neary GNOME Foundation member dne...@gnome.org Jabber: nea...@gmail.com ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] MeeGo bugzilla on gitorious
Hi Andre, Andre Klapper wrote: > On Mon, 2011-07-04 at 14:25 +0200, Dave Neary wrote: >> Do you have a list of bugs which require Bugzilla modifications handy, >> by any chance? > > On a related note, existing important modifications should be listed on > http://wiki.meego.com/MeeGoBugzilla_Customization Was there a particular reason to use CamelCase for MeeGoBugzilla, and to capitalise customization? I don't like renaming pages arbitrarily, but something like "MeeGo Bugzilla customization" would be more consistent with other page names. Cheers, Dave. -- Dave Neary GNOME Foundation member dne...@gnome.org ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] FW: [wiki doc] How to do a merge request within gitorious
Hi, Helia Correia wrote: > FYI Thanks! > I have created the following section in MeeGo wiki documentation: > > http://wiki.meego.com/Brief%20git%20guide#How_to_use_gitorious_to_do_a_merge_request One quick suggestion is to ensure that this page is linked from all the obvious places. People will be looking for this in the developer tools and development pages, the getting involved page, and perhaps even the bugzilla pages. It should be linked in all of those places, because otherwise people will simply never find it, and it will eventually end up being duplicated. Perhaps it's not big enough to go here: http://wiki.meego.com/Main_Page#Developer - but there *should* be a link to developer tools & "how to start coding on MeeGo" there somewhere. It seems appropriate for here: http://wiki.meego.com/Community_communication#Bugs (if it's related to attaching patches to bug reports) And definitely appropriate here: http://wiki.meego.com/Gitorious_guidelines This page also duplicates some of your page - perhaps it should be moved & better linked? http://wiki.meego.com/Kernel_patch_guidelines/git_for_starters Cheers, Dave. -- Email: dne...@maemo.org Jabber: bo...@jabber.org ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] MeeGo bugzilla on gitorious
Hi, eric.le-r...@nokia.com wrote: > I'm very happy to announce that we have finally released our MeeGo > bugzilla instance code on gitorious. > Check it out here: https://gitorious.org/meego-bugzilla > I would like to thank Stephen for the tremendous and quality work he's > been delivering and his extremely valuable contribution to the MeeGo > project. > A clear direction was given and a great vision of collaborative work. > I'm sure Shuang will take this legacy further and get contributions from > you, developers, in order to make MeeGo bugzilla a reference in > usability and a wonderful environment to work in. I just wanted to say thanks and congratulations! This is going to be useful whenever we see Bugzilla related bugs/feature requests. > I really would like to encourage you to collaborate, submit ideas and > patches and make Meego bugzilla really yours. Do you have a list of bugs which require Bugzilla modifications handy, by any chance? Cheers, Dave. -- Email: dne...@maemo.org Jabber: bo...@jabber.org ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] [meego-releases] New Bugzilla product "MeeGo Distribution Packages" has been created.
Hi, Arjan van de Ven wrote: > anything that leads to the bug getting fixed is value. that's not just > what developers do... Developers seeing bugs that they are able to fix helps the bugs get fixed. If a module developer is searching for open bugs in "his" module and doesn't find any, then that's a problem. Ways to solve the problem would be for the developer to search for something else (bugs owned by meta_ow...@meego.bugs or whatever) or using Bugzilla as it was intended, and assigning bugs to the developer who can fix them - in which case, the developer will see the bugs he can fix under "My bugs". > it's also triagers/qa getting the reporter to put all the needed info > there etc etc etc. A vital part of triage is getting a bug report under the eyes of someone able to fix the bug. In this case, I'm sure that we can agree that the triage was sub-optimal, in that it removed open bugs from the view of the developer who could fix it. Cheers, Dave. -- Email: dne...@maemo.org Jabber: bo...@jabber.org ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] 1.3 MeeGo release schedule posted
Hi Rolla, Selbak, Rolla N wrote: > Just fyi, the 1.3 release schedule is posted up on the wiki: > > http://wiki.meego.com/Release_Engineering/Plans/1.3 > > Main dates are: > > MM2: Jul 26 - Intrusive (high risk and priority) changes phase complete Is there a milestone (perhaps past) on decisions for which intrusive, high-risk and high-priority changes are to be made in the release? This is the kind of thing which I think it would be great to have for the 1.4 release, if we don't have it yet. I've been thinking for a while (and mentioned it to many people in San Francisco) that it would be a good idea to have a "feature/module inclusion proposal period" similar to GNOME for MeeGo, which would allow people to publicly propose components they'd like to see included in the next release. The proposals would be debated on the mailing list here, and then at some pre-announced deadline this debate would stop, the architects would get together and debate the proposals, announce their decisions on each one, and the integration of new components could start. The best time for this kind of discussion period seems to me to be just before or after the previous release. What do you & the architects think? Cheers, Dave. -- Email: dne...@maemo.org Jabber: bo...@jabber.org ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] LinuxCon Brazil & Prague: Submit MeeGo Sessions by July 8!
Hi Rodrigo, Leonardo, Rodrigo Vivi wrote: > On Wed, Jun 15, 2011 at 9:09 AM, Leonardo Luiz Padovani da Mata > > The Call for Participation for Brazil ends on July 22: > > http://events.linuxfoundation.org/events/linuxcon-brazil/cfp > > +1 collaborator from Brazil. > Actually my company (Metasys) is working to deploy MeeGo on > Educational Environment. > > I'm from Collabora. We have people working with MeeGo here in Brazil. > Helio Castro and me will speech at FISL12 about MeeGo. Rocks! Are either/both of you interested in submitting content for the MeeGo track? Leonardo, presenting your company's work (an interesting use of MeeGo) sounds like it would be a great presentation! Helio & Rodrigo, you could perhaps present QML & Qt for MeeGo and help us recruit some new application developers? Cheers, Dave. -- Email: dne...@maemo.org Jabber: bo...@jabber.org ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] LinuxCon Brazil & Prague: Submit MeeGo Sessions by July 8!
Foster, Dawn M wrote: > The Call for Participation for Prague ends July 8: > http://events.linuxfoundation.org/events/linuxcon-europe/cfp Hmmm... who do we know in the Czech republic who might be interested in submitting a proposal? Andre, can you think of anyone? ;) > The Call for Participation for Brazil ends on July 22: > http://events.linuxfoundation.org/events/linuxcon-brazil/cfp I don't know any MeeGo contributors from Brazil. Are INdT doing some MeeGo work these days? Cheers, Dave. -- Email: dne...@maemo.org Jabber: bo...@jabber.org ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] Howto lock screen orientation in MeeGo/Tablet 1.2 ?
Ville M. Vainio wrote: > On Sat, May 7, 2011 at 12:33 PM, Andrew Flegg wrote: >> This has been discussed - and agreed before - but the changes never >> seemed to happen :-( > > I think the agreed approach now is to educate rather than fix. I think you mean "the approach being adopted" - "agreed" implies, well, agreement :) Cheers, Dave. -- Email: dne...@maemo.org Jabber: bo...@jabber.org ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] Technical Steering Group Meeting: New Day / Time
Hi, On 04/03/2011 06:30 AM, Gary Birkett wrote: could you post the spreadsheet or a screenshot of the timezones onto the meeting wiki, I think visually showing the timing differences and difficulties with planning would help. I think it would actually help with more meetings than just the TSG and allow the other WGs to actually plan meetings better too. World Clock Meeting Planner is great for this: http://www.timeanddate.com/worldclock/meetingtime.html?month=4&day=4&year=2011&p1=101&p2=179&p3=224&p4=248 Cheers, Dave. -- maemo.org docmaster Email: dne...@maemo.org Jabber: nea...@gmail.com ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] Meego Bugs Access Denied
Hi, To cut this thread short: > On Thu, Oct 28, 2010 at 6:12 PM, Dave Neary wrote: ... please note the date this email was sent. I guess it was stuck in a moderation queue somewhere. Cheers, Dave. -- Email: dne...@maemo.org Jabber: bo...@jabber.org ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] Meego Bugs Access Denied
Hi, eric.le-r...@nokia.com wrote: >> Usually that reason is "security issue" or "customer sensitive >> information". >> > This seems to fall under the "csi" category probably. The unfortunate thing for me is "this will increase in the near future before it gets better". Is there a possibility of putting in place some kind of process whereby the bugs can be public & sanitised (without any CSI) and any super-zoomed surveillance photos, ballistic reports, DNA profiles, fingerprint searches and other CSI stuff can be somewhere else? (excuse my attempt at levity - hope it doesn't get lost in cultural translation!) Having closed bugs is one thing - planning to have more is another. >> But like you said, there should be a way to request access for people >> who need to know. >> > As far as I can tell, this situation is exceptional and we should return to > normal very soon. > I completely understand the frustration and actually share it... a suggestion would be to have a "Reason" field which would be required when closing a bug to public - at least that way people would know why the bug was closed off. Reasons could be "confidential information", "Security issue" or "Oops, I checked the checkbox by mistake" :) Cheers, Dave. -- maemo.org docsmaster Email: dne...@maemo.org Jabber: bo...@jabber.org ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] Architecture decisions (was Re: migration (back) to EDS)
Hi, A quick note on meritocracies. Andrew Flegg wrote: > According to Imad Sousou at the last TSG meeting[1], the MeeGo > Technical Steering Group consists of two seats: > > * Intel (Imad Sousou) > * Nokia (currently vacant after Valtteri Halla left Nokia) Companies typically don't have inherent merit. To cite one example, when Mitchell Baker left AOL (I can't remember whether she resigned or was laid off, it's irrelevant), AOL decided to appoint someone to take over from her as Chief Lizard Wrangler. But Mitchell said "Hello, I'm still here - I don't work for AOL any more, but I'm *still* the Chief Lizard Wranger" - and people followed her, and not the AOL appointee. I had understood that the TSG was made up of Imad & Valtteri, not Intel & Nokia. Has Valtteri resigned from the TSG officially? Combined with appointments of companies (whose representatives, with the exception of Yonghui Wang of China Mobile, have not sent even one email to any MeeGo lists) this makes MeeGo look less & less like a meritocracy and more & more like a collection of corporate partnerships. This has benefits too, don't get me wrong - there's nothing inherently wrong about an Eclipse Foundation-type trade association, but it is not what has been announced & reiterated, and what I believed the project leaders wanted the project to become. If the nature of the MeeGo project changed on February 11th, it would be nice to know. Cheers, Dave. -- Email: dne...@maemo.org Jabber: bo...@jabber.org ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
[MeeGo-dev] Desktop Summit CFP closing soon
Hi all, In case some of you are not aware, the Desktop Summit, a conference organised by the GNOME & KDE communities, and focussed on free & open source graphical user interfaces, is happening in Berlin on the first week of August. The call for content for the conference is open now, and will close on Friday. It seems to me that there is a lot happening in the MeeGo work which could benefit the entire desktop ecosystem, and that it would be useful to all concerned to share the experience and work of all of the UX teams. In particular, the desktop summit is a place where people with problems can meet people with solutions - it's very much a conference of doers. This is just a quick reminder, in case anyone had forgotten or not heard about the conference, of the deadline: https://www.desktopsummit.org/cfp Thanks! Dave. -- Email: dne...@maemo.org Jabber: bo...@jabber.org ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] migration (back) to EDS
Hi, sakari.pou...@nokia.com wrote: > On 22/03/11 11:44 PM, "ext Arjan van de Ven" wrote: >> The MeeGo architecture team made these decisions in consultation with >> the various handset and tablet architects. > > Just to be clear, Nokia members of the MeeGo architecture team where not > involved in these latest decisions of the MeeGo architecture direction > (MSSF/Buteo/PIM). This message requires some clarification, I think. Arjan, what is the make-up of the architecture team now? Are any Nokia people still members as far as you are concerned? For all the talk of meritocracy, it seems like people are being appointed by their employers to fill "their" seats, and those seats are subject to changing corporate winds. Cheers, Dave. -- Email: dne...@maemo.org Jabber: bo...@jabber.org ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] Meego Video API's
Hi, Niels Mayer wrote: > What about using http://www.mplayerhq.hu and various programs that > wrap it effectively? I've found http://smplayer.sourceforge.net/ to be > one such wrapper, and it's very much MeeGo compatible because it's > based on Qt. For embedding a media player in the browser (so that when > you click an internet MP3/MP4/etc link, the player embeds in the > browser/QtWebKit) http://code.google.com/p/gecko-mediaplayer/ >From experience, it can be difficult to work on top of the FFMpeg libraries, since they do not provide any API stability or guarantees to speak of (up until a couple of years ago, they had never made a release). I would recommend building on libav instead http://libav.org/ which is the continuation of FFMpeg as a library project, independent of mplayer.hu. Cheers, Dave. -- Email: dne...@maemo.org Jabber: bo...@jabber.org ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] Some architecture changes (MSSF / Buteo / PIM storage)
Hi, Arjan van de Ven wrote: > Time has come and gone for this to be a discussion; this is a decision. Out of interest, when was the time for this to be a discussion? And where did that discussion happen? Thanks, Dave. -- Email: dne...@maemo.org Jabber: bo...@jabber.org ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] Pulseaudio issue
Hi, Ryan Ware wrote: > On Feb 15, 2011, at 5:45 AM, Gabriel M. Beddingfield wrote: > >> On Monday, February 14, 2011 11:40:03 pm 백진욱 wrote: >>> Hi, >>> I have following problem with pulseaudio in meego handset >>> 1.1.90. >> The devs have been asking that you file a bug, even for >> bleeding-edge 'trunk' issues like this. > > Please! If you don't file a bug at http://bugs.meego.com, the issue might > fall off the radar. Also, if this is an issue affecting upstream pulseaudio, you might want to report it here also: http://www.pulseaudio.org/ Cheers, Dave. -- Email: dne...@maemo.org Jabber: bo...@jabber.org ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] netbook kernel compilation
Hi, Gabriel M. Beddingfield wrote: > On Wednesday, February 16, 2011 04:06:19 am Jeremiah Foster > wrote: >> Good stuff Gabriel. Perhaps we can put this on the MeeGo >> wiki somewhere? I haven't checked recently, it may >> already be there, but if it isn't I think a page on >> recompiling the kernel to add functionality would be >> useful. > > I couldn't find such a page. I would have created one last > night... but I don't know how to start a Wiki page (i.e. > what page should it be linked to). :-) > > If someone starts one, I'll add content to it. There is a wiki page for kernel developers - that seems like a good place to add little nuggets like this (either directly here, or linked from this page: http://wiki.meego.com/MeeGo_kernel_documentation_for_contributors Cheers, Dave. -- Email: dne...@maemo.org Jabber: bo...@jabber.org ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] Freedesktop.org specifications and compliance
Hi, Some freedesktop.org specs are de facto standards (essentially, documentation of practice to allow interoperability) - this is the case for .desktop files, mime type handling and XDND, for example - and others are aspirational, or document one particular implementation, and shouldn't be considered standards. In fact, right at the top, the page you point to says: "These are not really standards Note: freedesktop.org is not a standards body." And that isn't hyperbolae, they really aren't, and it really isn't. So whether MeeGo implements one spec or another off fdo will depend, although it's entirely possible that some of the specs will be compatible with MeeGo because of the way it builds on existing code. Cheers, Dave. Ville M. Vainio wrote: > Freedesktop.org has some specifications that are relevant to developers: > > http://www.freedesktop.org/wiki/Specifications > > Does being MeeGo include a promise to follow some of these > specifications, or is it left entirely up to the vendor to implement > whatever they deem fit? > > My primary interest at this point is the autostart spec: > http://www.freedesktop.org/wiki/Specifications/autostart-spec > -- Email: dne...@maemo.org Jabber: bo...@jabber.org ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Nintendo Meego GameBoy
Hi, Thiago Macieira wrote: > I shouldn't be feeding you but... Please do stop feeding the trolls, it makes them reproduce. Thanks! Dave. -- Email: dne...@maemo.org Jabber: bo...@jabber.org ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Fwd: GTk+ (and Hildon?) on Meego Handset
Hi, Niels Mayer wrote: > Just curious at what level this is being "ported" or "integrated" -- X > windows, OpenGL ES, or both? > > ... > http://blogs.gnome.org/foundation/2011/01/17/gtk-meego-handset-bidders-selected/ As far as I know, the goal is to ensure that upstream GTK+ works well for MeeGo, so that Hildon and Maemo application developers (for example) can simply recompile their applications for MeeGo. Currently there are some differences between upstream GTK+ and Maemo 5 GTK+ which make it impossible to just bring in Hildon as a dependency and recompile (or even, ideally, not need to bring in Hildon, because all the useful stuff will be integrated upstream, and Hildon will become an API compat layer). Claudio, does that sound about right? Cheers, Dave. -- Email: dne...@maemo.org Jabber: bo...@jabber.org ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Dconf
Arjan van de Ven wrote: > Heck, app writers wouldn't even notice the difference if you use the > proper abstraction API. ... which is, presumably, GSettings? Cheers, Dave. -- Email: dne...@maemo.org Jabber: bo...@jabber.org ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Dconf
Hi, Andre Klapper wrote: > Users (=apps) would rather convert to using GSettings in Glib/gio. Most users (=apps) would probably like to continue using the same API, and only have the backing store change. Then there's the second type of users (=people) who want to transparently have the same preferences applied when they upgrade an application. > dconf is one backend for GSettings, another one is gconf (by > http://git.gnome.org/browse/gconf/tree/gsettings/ ), or could e.g. be > the Windows registry (if somebody wrote the code for that). So the GSettings API does not match GConf, and application developers need to change both the settings schemas and the way they call the settings API. Is that right? What happens when I run an application which has been migrated from gconf to GSettings? > A script called "gsettings-data-convert" exists to migrate user settings > from GConf to another GSettings backend, e.g. dconf. So this reads old gconf keys and updates new registry entries with them? How foolproof is it? How does an application writer integrate it into the first run of the upgraded application? Cheers, Dave. -- Email: dne...@maemo.org Jabber: bo...@jabber.org ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] [MeeGo-community] Speech Recognition API for QT?
Hi, Zheng, Huan wrote: > I did a quick search, it looks like there’s no speech recognition API in > QT yet, am I missing something? > > Is there any plan to support speech recognition in QT? You might want to try CMU Sphinx which is, as far as I know, the state of the art in open source speech recognition. It's a long way from the quality of ViaVoice and Dragon Naturally Speaking, apparently, but no-one has succeeded in convincing IBM to open-source those. Cheers, Dave. -- Email: dne...@maemo.org Jabber: bo...@jabber.org ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
[MeeGo-dev] Package maintenance and working upstream
Hi all, Prompted by the discussions this week about being a maintainer and how to change something in MeeGo, I wrote a couple of articles on the subject yesterday and today, taking some real projects and examples. Here they are: What's involved in maintaining a package? http://www.neary-consulting.com/index.php/2011/01/13/whats-involved-in-maintaining-a-package/ The article goes into what the workload is for being a package or project maintainer, and outlines some of the skills you might need. The Lifecycle of a Patch (or: Working Upstream) http://www.neary-consulting.com/index.php/2011/01/14/the-lifecycle-of-a-patch/ This article shows the typical path from developer to user, and describes the way "working upstream" is supposed to work. I hope they are useful! Cheers, Dave. -- Email: dne...@maemo.org Jabber: bo...@jabber.org ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
[MeeGo-dev] Working upstream (was: Precision of what it means to 'be responsible for' / committing to maintaining a feature/package/whatever in MeeGo?)
Hi, Sivan Greenberg wrote: > On Wed, Jan 12, 2011 at 1:14 PM, Dave Neary wrote: >> Concretely, this is what "working upstream" actually means. > > So given this alleged time frame (I'm thinking out loud, and I thank > you greatly for this discussion, albeit a bit off topic now to > Carsten's original topic) , how extreme do we follow upstream? My opinion? Very much. Let's take a real example: Evolution. The netbook UX people wanted to ship a nice mail client for a smaller form factor. Their choices are: * Start from scratch building a nice email client. This is what Nokia did with Tinymail/Modest. * Work from an existing piece of software like Sylpheed or Evolution, and make a netbook variant with the features required. In the latter case, it would be total madness not to work with the maintainers - so that's what Intel & Novell did. The worked on a netbook version of Evolution (in fact two... Evolution Express and the short-lived but promising Anjal) and packaged it to ship with MeeGo when it was ready. Let's say they decided to do this without getting that code upstream as a sub-project. The next time the Evolution project changes its internals for whatever reason, you now have a big development job to bring your variant up to scratch. You'd better have someone on staff working on your Evolution variant full-time to ensure fixes are being made & you're keeping pace with upstream. Now, that's not to say that you can't have situations like this: * February: Bug found in Evolution or EDS, not a release blocker * March: New Evolution version released (with GNOME) * April: Bug is fixed, and code is accepted into Evolution head, and back-ported to stable branch, but not included in a stable release * May: Bug fix, which was already on stable branch, is merged into MeeGo for a stable release * September: Evolution released with bug fix from April So that you have the bug fix from April in MeeGo in May, but not in Evolution for another few months. Synchronising feature requests and patches across distributions and upstream projects has always been hard. Witness the debate over when to include KDE 4.x in distros a few years back, or more recently whether GNOME should depend on GTK+ 3, when the GTK+ team does not have a time based release schedule. Will the next release of the distro have GIMP 2.6 or GIMP 2.8? That depends on whether & when the GIMP releases 2.8, and whether it'll be of a high enough standard for the distro... the only distro I know of that ships upstream code from GNOME without doing integration & regression testing is Foresight, otherwise, Ubuntu has the shortest lag time, and they're 6 weeks after the GNOME release date. And GNOME has never released more than a week after their announced release date. Taking the kernel as an example of a project that does not do time based releases, you can now more or less predict when releases will be coming, give or take a month... so will we be using 2.6.36.* or 2.6.37 in MeeGo 1.2? Arjan can tell you, but I'm sure he will not be planning on including a kernel released after the feature freeze window (when is that, again?). > I don't > think we'd have "usable out of the box" distro like Ubuntu (which is > for me almost a dream come true in terms of what I can offer to peopel > coming from other platforms) if Ubuntu was just 'following' upstream. Ubuntu is a very good integrator. They modify config files, themes, small behaviour changes, ensure that different applications play well together. But they do not do major code changes to upstream projects. Those that they do are either (a) written in Ayatana, which Ubuntu considers upstream (in the same way that Mutter and the MeeGo zone panels are upstream for MeeGo) or (b) submitted upstream. > I know for fact that great measure had been taken to include distro > specific patches until an upstream piece of software is actually > usable or usable for general consumption. Can you give an example, please? > As an example, gnome cups manager lacked support for controlling IPP > printer detection in gnome for a long time. After realizing upstream > is not going to deliver this, I did the GUI part and a core dev did > the backend part and we released this feature to the great > satisfaction of, in this case, corporate users[0]. It seems your pointer [0] is uninitialised... Cheers, Dave. -- Email: dne...@maemo.org Jabber: bo...@jabber.org ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Precision of what it means to 'be responsible for' / committing to maintaining a feature/package/whatever in MeeGo?
Hi,
Sivan Greenberg wrote:
> What if I want to change something or add functionality to an existing
> package?
Then you should go through the submission process of the upstream (code)
project. This is why I make a clear distinction between package
maintainers (who ensure the latest software is packaged for a distro)
and project maintainers (who decide what that software will do).
> For instance, what if I want to provide fixes or apply
> somebody else's fixes to improve the core UX in meego to be more
> suitable for the idea pad[0], and I do have the time for that.
> [0]: http://bugs.meego.com/show_bug.cgi?id=10739
We're getting to the heart of the matter now. Let's say that you decided
to address this issue of netbook UX and touchscreen. You could pick
easier ones, but let's say, for argument's sake...
You will need to presumably open some smaller-granularity bugs
("Increase corner and edge target sizes on windows for touch events",
for example), against the appropriate module. Now, I don't know exactly
what is involved, but I can guess that changes would be needed in
Mutter, I guess, and it probably needs some work in XInput & Xorg to
differentiate between touch & mouse events, and related work in Clutter
and Mx.
It's possible that the maintainers of one or all of these modules will
reject your work as not aligned with their goals - you can try to
propose that the patch be carried as a distro-specific diff, but that
would be quite a big one, and there's a good chance that the request
would be rejected by the package maintainers & MeeGo architects. So you
should work with the Mutter/Mx/Clutter maintainers first to see if they
agree with your way of doing things before you start doing the work, to
give the best possible chance of your patch being accepted.
Once you have a good idea that patches would be accepted, you can start
working on the code for the problem.
So first you'd make a patch proposal for XInput in Xorg, and a related
patch request in Mx or Mutter, whichever is relevant (Thomas Wood,
Thomas Friedrich or Emmanuele Bassi can tell you, I guess). They will
review your patch, suggest changes, but (if you've done the work of
getting everyone on the same page beforehand) these changes should only
be minor. If, on the other hand, you propose patches for features the
maintainers don't want, or you're doing things in a way they
fundamentally disagree with, no amount of massaging the patch will help.
So, once the XInput patch is accepted, and the Mx/Mutter patch is
accepted, the changes will automatically propagate to the Netbook UX for
the next version. Now, knowing that the next version of XInput will be
releasing sometime in 2011, and Clutter (synced with GNOME I think)
probably won't include your patch until September '11, MeeGo won't have
it until the Winter '11 release, or perhaps Spring '12.
Concretely, this is what "working upstream" actually means.
> Perhaps we could at least assign a mentor or a sponsor that would
> review packages and upload them on my behalf? I even touched sysvinit
> in Ubuntu through this process[1]. Martin only physically uploaded it.
> [1]:
https://bugs.launchpad.net/ubuntu/+source/sysvinit/+bug/28447/comments/14
Please let's separate code & packaging issues. Ubuntu does indeed carry
many distro patches. They typically do expect changes to be proposed
upstream also, but for smallish changes, or changes to config
files/defaults, they will carry a diff. In this case, we're talking
about a 10 line change to a shell script, which doesn't look like it got
submitted upstream to Debian. In this particular case, it's hard to know
if this was patching a bug also present upstream, or one which was only
present in Ubuntu.
When you're talking about major code changes, they really need to be
done upstream, in a way the maintainer is happy to maintain, or you will
end up very quickly with multi-thousand line patches that will take a
huge amount of effort to maintain across releases.
> Yes, that is highly desirable. Do we have an ITP request queue like
> Debian has? If not, can we please start it? We still need some people
> to be able to review packages or help people get their first package
> the #debian-mentors style , although I've seen that already happening
> in #meego. Do we keep this that way?
I do think a packagine mentoring program would be a great addition -
perhaps something that David Greaves might have views on via the
community OBS project? But just a place & some people where you can go
to figure out how to set up a zypper repository, package an RPM from a
.tar.gz, and the recommended path for getting a package into the main
repository (rather than propagating private repositories) would be most
excellent.
> Well, in Ubuntu when you wanted to add a feature you ultimately became
> the package's maintainer.
This is a bug, not a feature - and one we want to fix in MeeGo. If you
want to add a feature, add it upstream. Otherwise, you end up with the
situat
Re: [MeeGo-dev] Precision of what it means to 'be responsible for' / committing to maintaining a feature/package/whatever in MeeGo?
Hi Sivan, Sivan Greenberg wrote: > I really liked the use of the median to conclude Prof. Knuth has not > done much of maintainer-ship over Tex the last couple of years, but > your account felt a bit too philosophical to me. But then again it is > late for me, and this is probably my own subjective experience :-) Thanks (I think). > So - I am who I am. I now have a lot of free time. I am interested in > maintaining packages. I have experience in maintaining Ubuntu packages > (gnome-cups-manager, gnome-system-tools, my own hubackup, > notification-daemon and more). Not so much with RPM based packages. > > Bottom line, what do I do to start maintaining a MeeGo (core should > not be exempt!) package? What is my course of action? re. Core should not be exempt: if we look at Debian, you can't become a maintainer of a package unless the maintainer(s) invite you to be, or the package is abandoned. I don't think any core packages will be abandoned any time soon, so the short answer there is to start packaging newer versions of core packages, and submitting them to the maintainer. For other packages, I hope that David or Arjan have a good answer - I'd love to see something like a package wishlist + list of orphaned packages, where new packagers can cut their teeth. In any case, your question clarifies that we're talking about "package maintainer" not "project maintainer", which is, as I pointed out, a different role. Cheers, Dave. -- Email: dne...@maemo.org Jabber: bo...@jabber.org ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Precision of what it means to 'be responsible for' / committing to maintaining a feature/package/whatever in MeeGo?
Hi Carsten, Carsten Munk wrote: > Some of us are currently discussing how to deal with hardware > adaptations (also 'community' ones) and one question by Thomas B. > Ruecker from Tieto was that came up is what exactly our concept of > maintenance is and how it works in practice? This will depend on the module. To take 2 extremes: Linus is the maintainer of the kernel, and works full time integrating patches from hundreds of contributors per month. If he spent less time, or had not set up a system with subsystem maintainers, the whole thing would break down. Donald Knuth has not made a release of TeX in over 2 years, since v3.1415926. Between 1982 and 2008, 425 bugs were corrected in the software, an average of 16 per year (and it's fewer per years since then). It would be fair to say that Prof. Knuth spends a median amount of 0 hours per week maintaining TeX. Basically, package maintainers typically take care of: * Packaging & releasing new versions (I know of at least one maintainer debating whether "git tag" is sufficient). Many maintainers just maintain .spec files and similar packaging metadata in the source tree, and ask volunteers to maintain the packages for various distros. * Communicating with everyone who develops the package when there's a new version (or beforehand) to give documenters, translators and plug-in developers the chance to update their work * Managing the roadmap of the product (letting people know what features you want to have in the next version, and who's going to do them - or not going to do them, as the case may be) * Reviewing bug reports, providing feedback on potential fixes, providing patch review and integrating patches * Typically the maintainer is also the primary developer of a piece of software. Good maintainers look for opportunities to delegate as much as possible - such as packaging and translations, but also potentially bug triage, bug fixing and patch review. Maintainers in the Debian sense don't actually (necessarily) develop the software they maintain. They: * Keep up to date on what is happening in the upstream project, and prepare packages for new versions for upload * Watch bugs reported against their package, and filter packaging bugs (which are their responsibility) from software bugs (which should get cloned upstream) * Follow upstream bugs that are duplicated against the package, and keep the distro bug system in sync with the upstream bugs (ie. when a bug gets closed against Totem, it should also get closed with a pointer to the fix against Debian's Totem package) * Forward patches upstream for review But packaging maintainers do not generally have a say in the project roadmap, or do any product management type tasks. > I'm sure this is an issue that most vendors wonder about too in our > feature process/package maintaining/etc, so here they are: > > Specifically: > * what are the requirements for a maintainer in terms of: > * availability > * time commitment > * response to requirement changes This is totally dependent on the software, the community around it, and the maintainer in question. If you're maintaining stable well tested software with relatively few users, then maintenance might involve making a new release to get updated translations out every time there is a product release. If you're developing new software, then you will be writing new code, with bugs in it, and potentially responding to daily feedback from alpha users. The interesting question, I think, is "how much time will software maintenance tasks take over & above coding tasks?" Another way of putting it is: How much time does it take to manage a development project? If you have one developer, not much. If you have two developers, then the manager will want to make sure that the developer is working on the right thing, in the right way. So there's some overhead. He'll also want to co-ordinate releases and alternate between write new code & fix and stabilise. But communicating releases to 2 developers isn't a big deal. If you have 10 developers, you might delegate responsibility for a sub-project to someone, but have regular status meetings to ensure everyone is on track and ensure your roadmap & release schedule are matching reality, etc. etc. The glib short answer to the question "how much time does it take to be a maintainer?" is "as much time as the maintainer wants to spend". Cheers, Dave. -- Email: dne...@maemo.org Jabber: bo...@jabber.org ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] How can I know one package is built from which source package with zypper tool?
Hi, zhu wrote: > For example. > I know libqtopengl4 is built from qt-4.7.1-3.1.src.rpm. > > Does any zypper command can know libqtopengl4 came's from > qt-4.7.1-3.1.src.rpm. > > like what yumdownloader do: > yumdownloader --source libqtopengl4 . Does this do what you want? zypper wp libqtopengl4 (wp is short for whatprovides). You can then install the source package by taking the entry in the "Name" column as the package name: zypper si qt-4.7.1 or whatever. Would you mind documenting your conclusion in the wiki page when you're finished, please? http://wiki.meego.com/Zypper Thanks, Dave. -- Email: dne...@maemo.org Jabber: bo...@jabber.org ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Upstart in MeeGo 1.2
Hi, Carsten Munk wrote: > http://wiki.meego.com/Architecture/Meetings/20101117_Weekly would > probably illustrate reasons. The minutes say: > We agreed to a hand-on workshop on making systemd a reality right after > Thanksgiving. So... is it Thanksgiving yet? Cheers, Dave. -- Email: dne...@maemo.org Jabber: bo...@jabber.org ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Upstart in MeeGo 1.2
Hi, Glen Gray wrote: >> For average meego package, this does not change much. Upstart supports >> sysvinit style init scripts so they will continue to work as usual. > > This raises then the obvious question of Why ? > What tangible benefits does moving to Upstart offer. I can answer this... Upstart supports old init style scripts, but that's not all it supports. You can do things like have inter-service dependencies, so that if service A needs service B to be available first, they you can tell it to wait for service B in its upstart config file. Upstart can watch config files and reload them, if it's told to, without you having to do so explicitly (which is pretty cool). Upstart supports on-demand starting of services (in a DBus like way). systemd offers essentially the same benefits. Cheers, Dave. -- Email: dne...@maemo.org Jabber: bo...@jabber.org ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] MeeGo 1.2 Roadmap?
Hi, Hindman, Gavin wrote: > I can’t log in as anyone but myself, for obvious reasons, so I’m not > sure what you mean by your first comment – are you saying that users > with the lowest level of access cannot file feature requests? If so, > that’s a bug in the tool and should be submitted as such. When I click "New" to create a new bug/feature request, I can set the priority to enhancement, but I don't see any link marked "Feature". I see now that there's a "MeeGo Feature" section at the bottom of http://bugs.meego.com/enter_bug.cgi but the thought didn't occur to me that I would have to click there - I think of feature requests being reported against products rather than separately. So for an IVI feature, for example, I clicked directly on "Automotive user experience" under the "MeeGo Platform" classification. > As for the search, if you’re selecting a Classification of MeeGo > Features in the Advanced Search, you’ll only get features returned – I > do this every day. Additionally, all features have the string [FEA] in > the Summary, so that can be included in the Quick Find search box if you > only want to get features. I think the problem, as it is, comes from the filing of all features under a separate "MeeGo features" classification. While this may be useful for a subset of bugzilla users, it isn't exactly intuitive for those who aren't aware of how the project teams are using the classifications. Cheers, Dave. -- Email: dne...@maemo.org Jabber: bo...@jabber.org ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] MeeGo 1.2 Roadmap?
Hindman, Gavin wrote: > there are no bugs in MeeGo Features. Until they're written, presumably... ;) Cheers, Dave. -- maemo.org docsmaster Email: dne...@maemo.org Jabber: bo...@jabber.org ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] MeeGo 1.2 Roadmap?
Hi Jukka, jukka.ekl...@nokia.com wrote: > But I'm wondering what kind of information you are looking for, or actually > what kind of format? As you know all the information is on featurezilla, for > everybody to see. A good roadmap provides a number of things: * A vision for what the end goal is * A list of steps required to attain the goal * Clear labelling of ownership for each step, so that I know who is working on something, and which steps are not currently being done * Regular updates on progress towards the goal, as tasks are completed > You can do queries like this: > http://bugs.meego.com/report.cgi?x_axis_field=product&y_axis_field=component&z_axis_field=&query_format=report-table&short_desc_type=allwordssubstr&short_desc=&classification=MeeGo+Features&product=MeeGo+Connected+TV+Features&product=MeeGo+Core+OS+Features&product=MeeGo+Handset+Features&product=MeeGo+IVI+Features&product=MeeGo+Netbook+Features&product=MeeGo+SDK+features&product=MeeGo+Tablet+Features&version=1.2&version=1.2&longdesc_type=allwordssubstr&longdesc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&deadlinefrom=&deadlineto=&emailassigned_to1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailqa_contact2=1&emailcc2=1&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&format=table&action=wrap&field0-0-0=noop&type0-0-0=noop&value0-0-0= > (all Accepted 1.2 features in products, grouped to components) This is a list of tasks (and problems to be addressed), but it falls down in other ways. There is no over-arching goal - when time pressure comes, how will tasks be prioritised to decide which ones to drop, and which ones to finish? And there is no clear opportunity to contribute - these tasks are, as you say, accepted features. How about the unaccepted features, those that we'd like to have, but that there are no resources to work on? It would be nice to use the roadmap as an opportunity to contribute. > BTW, for Handset there is some material already in > http://wiki.meego.com/Roadmap, in the form of high-level presentation from > MeeGo conference. Thanks for the link! For some idea of what I hope to see in a roadmap, here's one of the best community roadmaps I'm aware of, Inkscape's: http://wiki.inkscape.org/wiki/index.php/Roadmap - the roadmap breaks down like this: 0.48 (next version): Starts with a goal for the release, then a detailed list of tasks that must be finished before we release a new version (includes features and bugs). 0.49 (n+1 version): Goal for the release, and some high level features to be done (these get broken down into smaller task lists as people take them on, after the 0.48 release) Following releases: The most important features & goals we want to see accomplished, but that have not been included in the next milestone. Forms a basis for discussion after each release when discussing the high-level goals for n+2 release. The old roadmap for the project is here, showing how the project's roadmap developed over the years: http://wiki.inkscape.org/wiki/index.php/OldRoadmap Cheers, Dave. -- maemo.org docsmaster Email: dne...@maemo.org Jabber: bo...@jabber.org ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] [MeeGo-community] PCWorld: Why Nokia Is in Deep Trouble With MeeGo (should someone reply to this article?)
Hi, Rudolf Streif wrote: > I also find it interesting that the author states "God help any > corporation that relies on open source to deliver the goods quickly." > but later claims "Android is the future. There isn't any question." > Android may not be open-source itself but it it most certainly built on it. The implication, of course, is that Android is not run as an open source project, which is true. Android is run as a proprietary platform distributed mostly with an open source licence. This certainly gives it some extra leverage in the marketplace, because OEMs can go & look at the guts & change stuff if they need to, but avoids all the perceived pitfalls of open source development - the bikeshed discussions, the long decision making process in projects run on consensus, the inability to get future commitment on almost anything... But all those disadvantages are not inherent in open source development. They are incidental in projects that do not have strong leadership and good community processes. So of course by ensuring we have good community processes and good, strong leadership, we can avoid them all :) > ...it is not worth wasting any energy on > responding to such articles since there will be many more but the energy > is better utilized to deliver on MeeGo's vision. I agree. Cheers, Dave. -- maemo.org docsmaster Email: dne...@maemo.org Jabber: bo...@jabber.org ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] [MeeGo-community] Final steps to Community device program (meego-dev list is FYI for this email)
Hi, Randall Arnold wrote: > The only thing left unresolved is the issue of device redistribution. > That is, if someone is holding a device they are not using then the > preference would be that they pass it on to someone who will. I wouldn't worry about it. You should have as much government as you need, and no more. Having people pass on hardware falls clearly into the "create social norms and expectations" category, and outside "have rules and process". We need only document the expectation: "If you get hardware through the device program and find you have no use for it, we encourage you to pass it on to someone else who can make better use of it". And you're done. Cheers, Dave. -- maemo.org docsmaster Email: dne...@maemo.org Jabber: bo...@jabber.org ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Application Icon not visible in Application list : MeeGo 1.1
Hi, Thiago Macieira wrote: > The entire hierarchy of /usr/share/applications should be searched. The > subdirs are simply an organisation trick. > > hildon/example.desktop is tracked as if it were hildon-example.desktop. Interesting! How do you explain that moving the .desktop file to /usr/share/applications fixed the problem for the original poster? Thanks, Dave. -- maemo.org docsmaster Email: dne...@maemo.org Jabber: bo...@jabber.org ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] compass sensor plugin
Lemoine, Philippe wrote: > You can check latest status on : BMC 8649 > http://bugs.meego.com/show_bug.cgi?id=8649 "You are not authorized to access bug #8649." :( Cheers, Dave. -- maemo.org docsmaster Email: dne...@maemo.org Jabber: bo...@jabber.org ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Application Icon not visible in Application list : MeeGo 1.1
Hi, nanjundiah.har...@elektrobit.com wrote: > Deployed an application in MeeGo 1.1 but it doesnot show up in list of > applications installed. > > However I can lanuch the app from terminal. This implies that the .desktop file is not being parsed by the desktop, or it is missing some crucial information. > /usr/share/applications/hildon/.desktop Are you sure that this directory is searched for .desktop files on MeeGo? What does the .desktop file look like? At the very least, you need a Desktop Entry section, containing Name, Executable and Icon fields. Have a look at http://wiki.maemo.org/Desktop_file_format for my best guess at the various fields & their meanings in Maemo desktop files. The presence of "hildon" in the path looks suspicious to me, in any case... Cheers, Dave. -- maemo.org docsmaster Email: dne...@maemo.org Jabber: bo...@jabber.org ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Using "meego" or similar in packages and distro names
Hi, quim@nokia.com wrote: > What is really the problem? Apart from the fact that it is not good > practice to carry the names of distros in package names of generic apps > and libraries, it is not evident (at least to me) where the problems > really rely. More than "not good practice" - it's brand dilution. MeeGo is a distribution, not a library or an application or a netbook GUI. That story is easy to understand, and we should ensure that it reflects reality. > Packages using the "meego" string in the MeeGo releases seem to fall in these > categories: > > * Applications developed by the MeeGo project within the UX > categories. In general it is not a good practice to tie an open source > app with the name of a distro. Also the "MeeGo" word doesn't appear in > the UX of these apps. Should we consider the renaming of those packages, > removing "meego" from them? Yes, definitely. Applications should not be "MeeGo anything". To draw a parallel, GNOME games are games for GNOME, and also games from GNOME. But we don't have an issue with someone saying "GNOME Games on Ubuntu". Ubuntu One, on the other hand, will have trouble being adopted anywhere else because of the distro name in the client application name. Going beyond applications, it would be really useful if the UX layer of the netbook UX specifically had a name other than MeeGo. That is, the collection of window manager, default user interface, panels, menus, settings apps, all the basic plumbing. Call that "Flubberdubby" or whatever, and you'll se people calling their MeeGo derived distros "OpenSuse Flubberdubby Edition" or "Debian Flubberdubby Edition". The MeeGo equivalent of GNOME or KDE. (*) > * Packages related with the MeeGo Touch Framework. The branding of > this framework was discussed and agreed, causing the actual renaming of > the components (previously libdui). There is no problem in other distros > willing to use the MeeGo Touch Framework. Is it clear the situation of > branding and icons, though? Are they in isolated packages? The only issue might be if you had an issue with other distros shipping MeeGo Touch. If you don't, I don't see a problem. Still, I don't see any reason for naming the framework after the distro if it is potentially useful to others. It's sufficiently hidden from the user that it doesn't really matter, though (as with all ther other library packages). > * Upstream packages with specific MeeGo version/configuration. Not a big > deal, between not useful or not problematic for other distros. > * Packages intrinsically related to the MeeGo distro (configuration, > branding, devtools). Not useful in the context of other distros. I don't know if there are a lot of either of these - obviously things specific to MeeGo can have the MeeGo name. For upstream, I would rather encourage another naming convention - "netbook" maybe? Or "flubberdubby"? In any case, I agree it's not a major issue. People target UXes, not distros. > Progress in this discussion is measured in improvements to the current > documentation and bugs filed/solved. If you file any bugs about this please > CC me. Thanks! Cheers, Dave. (*) I am not recommending calling the netbook UX Flubberdubby. -- maemo.org docsmaster Email: dne...@maemo.org Jabber: bo...@jabber.org ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Packaging the MeeGo stack on Debian - Use the name ?
Hi Gabriel, Gabriel M. Beddingfield wrote: > Many of these libs are distributed LGPL, without any special > exception for trademarks. I submit that this manner of > trademark enforcement is inconsistent with the LGPL.[1] > [1] LGPL v2 Sections 2, 10, and 11. Also the FSF FAQ > indirectly references the issue: > > http://www.gnu.org/licenses/gpl-faq.html#WhyDoesTheGPLPermitUsersToPublishTheirModifiedVersions > Since we're linking GNU pages, this one seems more relevant to me: http://www.gnu.org/distros/free-system-distribution-guidelines.html#Trademarks Specifically: "Similarly, the distribution itself may hold particular trademarks. It is not a problem if modification requires removal of these trademarks, as long as they can readily be removed without losing functionality." Can we now please leave the lawyering to the lawyers? Cheers, Dave. -- maemo.org docsmaster Email: dne...@maemo.org Jabber: bo...@jabber.org ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Packaging the MeeGo stack on Debian - Use the name ?
Hi, Before we escalate & put words in people's mouths, we should let Ibrahim come back with an answer. He said as recently as Friday that he was going to get a precision on this issue. That said, there is some factual misunderstanding going on here... Jeremiah Foster wrote: > David Greaves wrote; >> Can I ask how this applies to the 50+ packages which are currently part of >> meego but which are opensource and many of which we presumably expect to be >> used elsewhere? >> I assume the MeeGo project is implicitly giving permission to use these as >> package and library names by publishing the packaging and tarballs under the >> relevant license? > > We cannot make that assumption. We'll need an explicit statement on > trademark from the Linux Foundation regarding the MeeGo trademark if > the Linux Foundation wants MeeGo "branded" software available in > Debian. You can always call a rose a rose, regardless of whether someone has a trademark on it. If there is a project called libmeegotouch, and someone takes the source code of libmeegotouch and packages it for Debian, then it's entirely OK to call the resulting package libmeegotouch. This is the equivalent to buying a Mars bar and reselling it (as a Mars bar). If the thing you're packaging is not the same (say you're applying substantial patches), the libmeegotouch authors could ask you legitimately not to release your repackaged & modified software as libmeegotouch, because this will result in confusion over origins (think: Iceweasel/Firefox). This is the equivalent to selling a chocolate, caramel & nougat bar that you make yourself as a Mars bar. > I'm no expert on the trademarking of software libraries but I > understand it is difficult to exercise trademark claims against > software libraries. I don't see why it would be... when you get down to it, that's mostly how Java works. > Clearly the fairest naming scheme would to change the library names to > something without the trademark. I don't know about fair/unfair, but it would certainly be a resolution path. -- maemo.org docsmaster Email: dne...@maemo.org Jabber: bo...@jabber.org ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
[MeeGo-dev] CFP - FOSDEM embedded devroom
Hi all, I'm slightly involved in the FOSDEM embedded devroom this year again, and I'd love to see some MeeGo content there. The devroom is generally pretty tech oriented - focussed on hardware, platforms or domain-specific stuff, so it'd be a good opportunity to present some of the more interesting aspects of MeeGo. Please find below the Call for Participation - we will be finalising the line-up quite late, but we can try to let people know earlier if they need approval to attend. Cheers, Dave. == FOSDEM embedded and mobile devroom CALL FOR PROPOSALS == FOSDEM will be held the February 5 and 6, 2011 in Brussels, Belgium. For the seventh time, FOSDEM will also feature an embedded and mobile room. We are looking for people who would like to do a presentation about a project in the realm of embedded or mobile that has some bearing on Free Software or Open Source. Some example projects are Arduino, MeeGo, Yocto, Beagleboard and its decendants, Openembedded, Android, Qt, OpenWrt, NetBSD... We are looking for short tutorials, feature presentations, project overviews, talks about achievements or failures, hardware and hardware hacking, real life deployments, and more... All submissions will be reviewed by our panel. Good proposals consist of an abstract of the talk and a short speaker biography. They should be submitted to fosdem.embed...@gmail.com. before January 5, 2011. We will confirm to the speakers no later than January 10, 2011. The review panel consists of: Philippe De Swert, Nokia Peter De Schrijver, Nokia Klaas Van Gend, MontaVista Software Dave Neary, Neary Consulting Michael Opdenacker, Free Electrons and Linaro´ -- maemo.org docsmaster Email: dne...@maemo.org Jabber: bo...@jabber.org ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Qt uses OpenSSL, and fails?
Hi, Patrick Ohly wrote: > Second, as mentioned in # and elsewhere [4], there is a license > conflict between OpenSSL and GPL. Does opening OpenSSL via dlopen() at > runtime really work around this conflict? I'm not a lawyer, but given > that the way how linking is achieved is typically not specified in > detail in licenses, I doubt that using dlopen() instead of ld.so really > works around the license issue. I am definitely not a lawyer, but I have previously worked for a company who routinely included functionality at runtime if we detected the presence of certain GPL incompatible shared objects. We did receive legal advice that this was not incompatible with the GPL, since we (the application authors) were not shipping the non-GPL & GPL code together. Presumably the same applies to Qt, unless Qt unconditionally depends on OpenSSL. Some related data points: Fluendo also heavily researched this question (for obvious reasons) and have a question about it in their licensing FAQ: http://www.gstreamer.net/data/doc/gstreamer/head/faq/html/chapter-legal.html#legal-gpl-program Jacob Kaplan once wrote a series of unanswered GPL related questions exploring the grey areas around the GPL - this question is related to his questions 1 and 4: http://jacobian.org/writing/gpl-questions/ The question came up on Stack Overflow a while back too: http://stackoverflow.com/questions/2069200/designing-a-gpl-library-with-weak-dependencies-on-proprietary-libs-best-approach Hope all this helps! Cheers, Dave. -- maemo.org docsmaster Email: dne...@maemo.org Jabber: bo...@jabber.org ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] [MeeGo-community] Nudging the Community Device Program
Hi, a.gra...@gmail.com wrote: > On 3 December 2010 00:40, Randall Arnold wrote: >> Now that we have a nice offer from TI to get Pandaboards into the hands of >> developers [1] it's time as Quim suggested to get serious about the >> Community Device Program [2]. I will repost some of the wiki content here >> followed by my thoughts and questions: > > maybe I' missing something... if TI is going to provide these > Pandaboards, why are you talking about budget from > Nokia/Intel/LinuxFoundation? Randall said: "I imagine most of this will be per individual contributing companies, eg Intel, TI, Nokia, et al. Unless we are just talking a program administrative budget? If so, what would that cover other than devices?" - I understood that he's assuming the budget will come from the people providing the hardware. If we are centralising the device program efforts, though, it makes sense to have some LF budget allocated to sending devices out, for example. It might make sense for hardware producers to donate hardware to the Linux Foundation (or, if you prefer to the MeeGo Project, via the Linux Foundation), and have us figure out how the hardware can be effectively distributed which will give a good return on investment to both MeeGo and the hardware donor. The hardware programs I've seen so far tend to adopt one of three approaches: give hardware to people based on what they've done in the past, give hardware in reward for participation in some competition, or give hardware to people based on the promise that they will do something. For boards, I would like to propose a fourth way: Give a workshop teaching people how to use MeeGo on the hardware, and provide the hardware to workshop attendees & let them take it home at the end. The problem with giving hardware to people based on their reputation is that they tend to cumulate hardware - I know a lot of kernel people's reaction to a hardware giveaway is often "put it on the pile over there" at this stage. THere's no guarantee they'll have any utility for the hardware or do anything with it. Giving hardware as a prize for a software development contest is tempting, and if you have really good docs on how to get started with development using emulation or something, that might be a good approach - but it does add some overhead in terms of judging. Expecting people to apply for hardware (à la Nokia) also has a limited return on investment, I'm afraid, because it's one thing promising to do something with the hardware, and another thing to actually do something with it. Also, I would argue that past reputation is actually a poor predictor for the amount of hacking you'll do for a new device. The fourth way, providing hardware as a reward for participation in a training workshop, has a double incentive - you're not expecting people to do hardware hacking as a prerequisite, and you're training people & giving them the tools which they need to be able to do something with the hardware afterwards. Plus, participation in the workshop is, I would argue, evidence of a willingness to actually do some hacking with the hardware afterwards. Cheers, Dave. -- maemo.org docsmaster Email: dne...@maemo.org Jabber: bo...@jabber.org ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] why my helloworld can not be displayed on the top of the window
Hi Leo, On 12/02/2010 04:18 AM, Leo wrote: I install the Madde&&SDK and setup the *meego-core-armv7l-1.1* target . Follow the instructions, I write my first QT application for Arm version. I can install to my device, but I can not see my app, actually it run on the background. I write the simple XLib based app, still launched on the background, I dont know how does meego manage its apps, or related with WM? Can someone explain to me, how to install and run a arm based application correctly? You might find the Maemo packaging tutorial useful: http://wiki.maemo.org/Packaging - you can ignore all the dpkg stuff. The important bit is the .desktop file install. I don't know how many Maemo extended fields are also in action for the handset UX, I imagine most of them. The important bits are the Icon field, ensuring that the icon is installed in the right place, and the Exec field, identifying the executable to be run. You might also try compiling & running your application under Xwindows first - perhaps you're missing some vital step in the initialisation of your application (the Xlib equivalent of QWidget::show() perhaps?) Cheers, Dave. -- maemo.org docmaster Email: dne...@maemo.org Jabber: nea...@gmail.com ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] MeeGo development HW
Hi, Till Harbaum / Lists wrote: > the various beagleboards as well as the pandaboard seem to be the > only hardware developments boards that currently support meego. They > are imho the only plattforms that give you direct access to i2c and > legacy uart (and many many more interfaces). If you want to run the > netbook ux, then a netbook with usb->uart and usb->i2c converters may > be an option. If you want the handset ux you'd have to deal with usb > otg interfaces for this which imho currently isn't properly supported > on any handset. >From conversations at conferences, it seems like a lot of Linaro members are working on ensuring that MeeGo works on their platforms - so you can expect hardware soon from Freescale, TI, and ST Ericsson at least which will be MeeGo capable. As Till says, your best bet right now appears to be an Aava kit, or one of the TI kits, or an N900. Cheers, Dave. -- maemo.org docsmaster Email: dne...@maemo.org Jabber: bo...@jabber.org ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] [MeeGo-community] Agenda of TSG meeting *today*
Hi, Quim Gil wrote: > Here is the agenda for the Technical Steering Group meeting held today - > actually in a bit more than one hour, at 20:00 UTC. Would it be possible to have a TSG meeting confirmation & reminder sent out more than 24 hours in advance, please? A number of TSG meetings have been cancelled at relatively short notice, so saying there's a regular meeting isn't quite sufficient. 24 hour notice would also allow late proposals to be suggested for the agenda based on discussions since the previous TSG meeting. Thanks! Dave. -- maemo.org docsmaster Email: dne...@maemo.org Jabber: bo...@jabber.org ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Urgent: We need community ftp space or similar
Hi, Clark, Joel wrote: >> Dave Neary wrote: >> Does all of this really need to be a prerequisite to allowing a >> long-time, active community member to upload & distribute an image? > I don't get it either. If the "long-time, active community member" is > willing to build, test, upload, distribute and deal with problems from > anybody who uses his image, why not take advantage of the existing > automated processes for code management, build, distribution and issue > tracking? Is the goal here to make sure the beagleboard is not > supported on meego.com? I get the feeling we're talking at cross purposes :) Going back to Till's original message, he's asking for a distribution channel to be created on meego.com where he (and others) can upload custom meego images they build. You are proposing that this uploading & distribution of imageshave some QA stuff as a prerequisite: some place in Bugzilla where bugs against the image get created & assigned to the image creator, integration into the existing build infrastructure (which, presumably, will require some extra access), associate the distribution of the image with a named kernel maintainer, platform maintainer and build scripts maintainer. Rudolf suggested that "eventually we'll need the full infrastructure", implying even more overhead. I don't understand why all of this is necessary before you can allow someone to upload an image & publish a URL to it, so that interested parties can download & play with it. Creating the necessary bugzilla & build stuff will add hours or days to requests, and is not a scalable approach to community builds. Cheers, Dave. -- maemo.org docsmaster Email: dne...@maemo.org Jabber: bo...@jabber.org ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Urgent: We need community ftp space or similar
Hi, Clark, Joel wrote: > First we need someone to be the image maintainer for the beagleboard. > Someone to own bugs found. If Till is building images to share with > the community then please just go the next step and agree to maintain > that image, so we can leverage the existing build and bugs > infrastructure to support the beagleboard community. I don't believe > there is significant additional "needed MeeGo bureaucracy". 2 or 3 > folks would be nice but 1 person could do it. What is needed is a > kernel maintainer for beagleboard, platform maintainer for > beagleboard, and someone to ensure the build scripts (i.e. kickstart) > is right and the resulting images actually boots. Sure it would be > nice to have a full QA team dedicated to the board, but the community > can provide that capability and file any bugs found. But someone has > to own the bugs found. Does all of this really need to be a prerequisite to allowing a long-time, active community member to upload & distribute an image? We can help draft the big red-type disclaimer on the top, if you like, that will say "This is not an official image! Beware, it may break stuff, and it'll all be your fault! Don't come crying to us afterwards, we'll only tell you we told you so!" And then Till can write, in really small letters underneath, "If anyone has problems with the image, contact me at till.harb...@my-nice-domain.com" and then Till will be doing your triage for you. I'm all for process before we ship software on devices and put it in the hands of people who don't know what they're getting into - but downloading binary images for the beagleboard does not fall into that category - can't we make it easier for people to get hold of the work of other community members? The parallel I would make is with the various staging trees & the old ac kernels. People knew what they were getting when they got it, you didn't accidentally download an ac kernel on the front page of kernel.org, and Caveat Emptor was in full effect. Cheers, Dave. -- maemo.org docsmaster Email: dne...@maemo.org Jabber: bo...@jabber.org ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Urgent: We need community ftp space or similar
Hi, Carsten Munk wrote: > 2010/12/1 Clark, Joel : >> Why don't you fold your work back into the build process so the images are >> produced under http://repo.meego.com/MeeGo/builds? > > I think the challenge is that while there's development ongoing, for > something that might at one point be contributed to the release > process, until you have QA personell and the rest of the needed MeeGo > bureaucracy in place, you need a place to dump your development work > as you can't release from repo.meego.com without this :) ... and I would say that if there are enough people proposing custom MeeGo images that disk space is a concern, then that's a nice problem to have ;-) Till doesn't need anonftp or anything, but something with trust-based access rights (where you have to ask to get a password allowing you to upload images) with directories organised by username (so you know whose images you're downloading) would be great as a way for people to share their work in an informal way. Cheers, Dave. -- maemo.org docsmaster Email: dne...@maemo.org Jabber: bo...@jabber.org ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] broken links to development images
Hi, Tom Chen wrote: > maybe you could get one form > http://repo.meego.com/MeeGo/builds/trunk/. hope this could help you. I thhink the images are in http://repo.meego.com/MeeGo/builds/trunk/1.1.80.8.20101130.1/core/images/ The problem with this link is that it will be out of date straight away - and there doesn't seem to be a "latest" link pointing to the most recent images. We should definitely have correct links in "Developing in a Meego Environment" (ahem... that page proably needs to be moved to something with a shorter & better name that doesn't capitalise Environment too), but we shouldn't consciously point to images which will quickly be out of date. Cheers, Dave. -- maemo.org docsmaster Email: dne...@maemo.org Jabber: bo...@jabber.org ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] MeeGo trademark compliance and double standards??
Hi, Peter Robinson wrote: > Is this a commercial vs open source community distro license agreement > or allowance? I'm somewhat confused! Do Linpus have an exception to > the requirements of using connman or do they provide (and are allowed > to do so) a library to provide an api glue between the two? Or are > they wrongly advertising features that they can't "legally" provide if > they wish to adhere to the current > > Presumably Linpus adhere to the LF's agreement to use the trademarks > as is currently announced or otherwise I've apparently missed > something or some process announcement. I suspect that this is an invalid assumption on your part. I bet that Linpus didn't consider that there was any need to ask for trademark approval after this change. The interesting bit will be to see what the reaction will be now that you have (officially) made everyone aware of this potential trademark infringement. Also worth noting is that Linpus operates primarily in China, and trademark protections are not so strong there... is this something to bear in mind? I don't know. IANAL. Cheers, Dave. -- maemo.org docsmaster Email: dne...@maemo.org Jabber: bo...@jabber.org ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Packaging Guidelines group tag for end user applications
Hi, Quim Gil wrote: > On Tue, 2010-11-30 at 11:26 +0200, ext Niels Breet wrote: >> It seems that the list of group tags are specified in the Packaging >> Guidelines: >> http://wiki.meego.com/Packaging/Guidelines#Group_Tag >> >> This list looks like it needs some attention as the options are very >> limited and some are not relevant for a mobile devices platform like >> MeeGo. > > Very good point. This was a topic of discussion in maemo.org some time > ago: > > http://wiki.maemo.org/Task:Package_categories > > (I'm not sure if this is the most recent page) This moved from Task: to just packaging guidelines: http://wiki.maemo.org/Packaging/Guidelines#Categories I note that the list we used in Maemo is much smaller than the one proposed for MeeGo - if, as Niels says, the MeeGo options are very limited, then aren't the Maemo options even more limited? Niels, can you give an example of a category of application for which there is a good section in Maemo, and not in MeeGo, please? Cheers, Dave. -- maemo.org docsmaster Email: dne...@maemo.org Jabber: bo...@jabber.org ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Academic Survey for MeeGo Community Contributors
Hi, Auke Kok wrote: > On 11/29/10 14:10, Gabriel M. Beddingfield wrote: >> I've looked here: ... >> http://wiki.meego.com/Mailing_list_guidelines ... > In general, any form of "spam" or "advertisement" is outside regular > mailing list policy. Since the post discussed is an invitation to a > non-MeeGo survey, it's an advertisement. This wasn't an advertisement, since no financial gain/transactions are involved. I can accept, however, that those of us who have been around for a while have had our fill of "academic surveys" and would prefer not to see community time spent on it. > I can't see spam/advertisement rules in the list policy ... nor can I. I did, however, find this: "Be Nice Be courteous and polite to fellow members in the list" I'll leave it up to you to decide whether you've been respecting this guideline. Cheers, Dave. -- maemo.org docsmaster Email: dne...@maemo.org Jabber: bo...@jabber.org ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Academic Survey for MeeGo Community Contributors
Hi, Auke Kok wrote: > On 11/22/10 23:18, Jarkko Moilanen wrote: >> Note! This message is NOT directly about MeeGo platform or MeeGo app >> development. > Did you get express permission from the MeeGo community council (Dawn, > Quim, etc?) to post this to this list? Do people need permission to post here now? Have I broken a rule because I didn't ask? > Since you clearly state your survey is "Academic", I assume it directly > benefits you as a person, providing you with research data. As such, > this invitation is a direct violation of list policies, and as such not > allowed use of this or any MeeGo mailinglist unless expressly approved. Can you point to the policy you're referring to, please? I treated this as an email I wasn't interested in, and deleted it. I'm sure others on the list did the same thing, or perhaps they clicked on the link & decided it wasn't worth their time. You could have done the same. Was there some particular reason you felt that this needed to be stamped out in such a forceful manner? Cheers, Dave. -- maemo.org docsmaster Email: dne...@maemo.org Jabber: bo...@jabber.org ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Downgrading to X1.8 in Meego 1.1
Thiago Macieira wrote: > On Sunday, 28 de November de 2010 05:30:10 Ash wrote: >> Has anyone had any luck downgrading the X version to 1.8 using Meego 1.1? >> If so, any tips on how we could do this? > > Note that downgrading will probably put you in violation of the MeeGo > Compliance spec. ... which matters only if you want to redistribute the result under the MeeGo name. Cheers, Dave. -- maemo.org docsmaster Email: dne...@maemo.org Jabber: bo...@jabber.org ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Information on contribution to upstream components
Hi Aparna, aparna.n...@wipro.com wrote: > 1. There could be a great difference between latest version of the > upstream components and the version running on MeeGo in which case the > upstream version of the component may not even be compiling on the MeeGo > env. So are we expected to put our patch and work on OS where the latest > version can be compiled (like ubuntu, fedora etc). MeeGo architects are working to ensure that developers are working with components close to the tip of upstream development. This *should* make it easier to patch both MeeGo and upstream with the same patch, at least for modules which are not changing at a very high rate. The expected workflow (as I understand it) is: 1. Prepare a patch for upstream (following upstream rules - either the latest upstream release or the tip of the main devel branch may be accepted) 2. Back-port this patch to MeeGo If the patch is delayed for any reason (missing review, for example) then the patch to MeeGo *might* be accepted if there is a reasonable expectation that the upstream patch will be accepted. If there are substantial changes required to the upstream patch, then you will probably have to fix issues and backport again, rather than having your original patch accepted in MeeGo. > 2. Is it possible that MeeGo branches from a specific upstream > version and we need to only work on the branched version? If yes is this > information going to be available somewhere? I'm not sure I understand the question. MeeGo will branch off upstream occasionally, but the rule is simple (even if the reality of applying it gets complicated): if you want a patch accepted into MeeGo, then the patch must be submitted to the upstream project in a form which can be accepted. If upstream accepts patches against older released versions, then fine. If upstream expects you to patch the tip of the main devel branch, then that's the standard. > 3. It will be good to have a page in wiki where list of MeeGo > components, their git links, bugzilla links, roadmap/plan links, branch > information is available. I agree :) Cheers, Dave. -- maemo.org docsmaster Email: dne...@maemo.org Jabber: bo...@jabber.org ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] how to build all meego packages locally ?
Hi Andrew, Andrew Tverdohlebov wrote: > Dear community, > Please help me with this problem. > Thanks! I hesitated to reply to your email, because I don't have any answer to your question. But this email is a nice example of how not to ask a question. 1. You completely cut your original question - please leave somee context for those who don't have your original email lying around 2. You sent your original email on a Saturday, and an impatient reminder first thing Monday morning. Please (a) Have some patience - many people here are less active during the weekend, or are living in the US (holiday weekend), or... (b) Realise that the community is not here to serve you - we don't have any support contract with you. Concerning your question: Do you have Madde installed & have you managed to cross-compile software for your device? The short answer is that you need to get all the source code, and then compile the software in the right order, and make an image out of it. Cheers, Dave. -- maemo.org docsmaster Email: dne...@maemo.org Jabber: bo...@jabber.org ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] enabling repository
Hi, Skyles, Greg S wrote: > Actually, I already took care of that detail. I thought Gabriel's info was > useful so I just put it in the wiki. Thanks Greg! Dave. -- maemo.org docsmaster Email: dne...@maemo.org Jabber: bo...@jabber.org ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] enabling repository
Hi Gabriel, Gabriel M. Beddingfield wrote: > On Fri, 19 Nov 2010, Mark S. Townsley wrote: >> On this page, >> http://wiki.meego.com/Input_Method_Framework/MeeGo_1.1#Netbook >> >> The first step is "enable handset repository". What are the steps >> to do >> so? > > $ sudo zypper addrepo \ > http://repo.meego.com/MeeGo/releases/1.1/handset/repos/ia32/packages/ \ > handset > > (all on one line) > > $ sudo zypper refresh would you mind adding this information to the wiki page Mark referenced, please? I think it would be useful to have a general overview of zypper in the wiki too - most people probably haven't used it much before coming to MeeGo. Cheers, Dave. -- maemo.org docsmaster Email: dne...@maemo.org Jabber: bo...@jabber.org ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Compiling MeeGo roadmaps, plans, backlogs...
Hi, Quim Gil wrote: > Hi, public roadmaps easy to find are an essential part of an open > project. If your MeeGo project team has some kind of plans please make > sure they are publicly documented and listed at > > http://wiki.meego.com/Roadmap > > I'm chasing the owners of Core, SDK and the UXs but there are more plans > around and I'm not sure if I've caught all of them. > > Note also that keeping your roadmaps updated is just as important. Some > of the pages linked at the Roadmap page are already old. Also, for projects serious about involving people from outside the formal teams, high priority roadmap items that are explicitly assigned to no-one are important. I did this once and it worked wonderfully - we had a roadmap where we said "here are our plans for the next 6 months: ... And here are things we'd love to see happen, but we don't have the resources to do - we will accept good patches for these features: ..." And we did get many patches. Once people had a minimum of permission to start working on useful core features, knowing that they were not duplicating someone else's (paid) work, they did. Just a suggestion... Cheers, Dave. -- maemo.org docsmaster Email: dne...@maemo.org Jabber: bo...@jabber.org ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Smartphone list supporting MeeGO
Hi, Dave Neary wrote: > Damien Newerland wrote: >> but you succeed to make MO/MT calls? My device is keeping flight mode >> always on... > > Yes, once I set my SIM not to be locked wit a code. Which you have to do > in your "real" phone - there's no way to unlock the SIM in MeeGo yet. Also, SMS worked... So all I'm missing is the battery indicator, network strength indicator, a way to unlock my SIM card, a way to get contacts off the SIM card, wifi (which looked like it was going to work, then didn't connect - so potentially a local issue), camera, a virtual keyboard, GPS, and perhaps an easier way to turn off the phone & be able to turn it back on :) And a faster UI, and perhaps other stuff I didn't test. In fairness, no-one is calling this a production release - and it's tremendously empowering to be able to run software so rough around the edges on my N900 at all! Not to mention being able to build my own images & deploy them to the phone. So no complaints from me. Cheers, Dave. -- maemo.org docsmaster Email: dne...@maemo.org Jabber: bo...@jabber.org ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Smartphone list supporting MeeGO
Hi, Damien Newerland wrote: > but you succeed to make MO/MT calls? My device is keeping flight mode > always on... Yes, once I set my SIM not to be locked wit a code. Which you have to do in your "real" phone - there's no way to unlock the SIM in MeeGo yet. Cheers, Dave. -- maemo.org docsmaster Email: dne...@maemo.org Jabber: bo...@jabber.org ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Smartphone list supporting MeeGO
Hi, Vincent Yau wrote: > Can you define "hardcore"? Very tough to get going? Or mostly working > but some features on the phone does not quite work yet? Easy enough to get going (download an image, dd it onto a MicroSD card, boot a kernel with Flasher over USB - end to end took me about 10 minutes), but many features don't work (of the ones I tested, I didn't manage to get wifi, camera, gps working. Voice calls worked, SMS didn't), the interface is really slow and looks quite rough around the edges. Cheers, Dave. -- maemo.org docsmaster Email: dne...@maemo.org Jabber: bo...@jabber.org ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Smartphone list supporting MeeGO
Hi, Bogdan Cristea wrote: > Is there a list with smartphones known to be compliant to MeeGO ? Not to be a smart-ass, but define "compliant", please :) To my knowledge, the only smartphone capable of running MeeGo at this point is the N900, and that's a pretty hardcore experience right now. Cheers, Dave. -- maemo.org docsmaster Email: dne...@maemo.org Jabber: bo...@jabber.org ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] MeeGo Backup Framework
Hi, Sivan Greenberg wrote: > I was wondering where one can read about the backup framework as > mentioned in [0] ? As the developer of several backup solution both > closed and open source, I'm interested in having a complete dummy poof > backup system for MeeGo; that is, other that storing your contacts and > personal preferences, also the storage you've used on your device to > keep your photos, music, files etc. I would also be interested in knowing who is developing the MeeGo back-up framework. There is a long-standing open Maemo bug about insufficient/out of date documentation I don't know where to get information about: http://bugs.maemo.org/6250 By the way, like the new URL? Thanks to Ferenc for doing the config changes from http://bugs.maemo.org/7107 - the same config change has been proposed for MeeGo in http://bugs.meego.com/1128 - Oops! Doesn't work yet :) Cheers, Dave. -- maemo.org docsmaster Email: dne...@maemo.org Jabber: bo...@jabber.org ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Allowing non-subscribers to post on the mailing lists
Hi, Foster, Dawn M wrote: > Actually, cross-posting is strongly discouraged in the MeeGo mailing > list guidleines. You can see our guidelines for more details: > http://wiki.meego.com/Mailing_list_guidelines In some cases (for example, when replying to a cross-posted email) it is appropriate to cross-post (assuming the subject is relevant to both lists). It is also appropriate when including people who are not subscribed to a list, but for whom the discussion is relevant. One example might be CCing meego-qa when we're talking about tidying up the Quality section of the wiki - even though that discussion might start on meego-community. If you think of email as a big conversation, then it makes sense to include new people, or even groups of people, in the conversation while it's underway, even if they didn't see the start. Yes, cross posting should be used with moderation - there is a cost to mailing lots & lots of people (but Mailman will ensure they don't receive the email several times across different lists). But I think that there's a strong argument for not banning cross-posting 100%. >> What do you think? > > I gave this quite a bit of thought, and I think it's fair to make the person > sending the message decide whether they really want to send it to the list. > This puts the decision on the user - by signing up, they are taking the > responsibility for understanding what they signed up for. The problem is that it also puts a moderate burden on the user - signing up to a mailman list, waiting for the token, confirming your subscription and resending your message all takes a few minutes. Not long in the greater scheme of things, but if your goal is just to inform people of something relevant to them, maybe you won't pay that price, and the information will be lost. This also doesn't solve the "I have multiple email addresses" problem - you sign up with 3 email addresses to one list, set two of them to not receive email, and then you have to remember to redo the same thing every time you sign up to a new list. A post-only list *does* solve this problem, as does effective list moderation. > Moderation also has some problems because the moderator > is taking the responsibilty for deciding what the user meant to do. The way > we have it set up now, we're putting the decision in the users' hands, which > seems fair to me. It's impossible to protect people from themselves. Some people will sign up to the list, and 6 months later will accidentally send something confidential to the list - but they're members so it goes straight through. Oops! A post-only list requires an explicit action to join a mailing list (satisfying your barrier to shooting yourself in the foot). The only way that we could possibly protect everyone from posting confidential stuff to the lists would be a 2 step posting: 1. I email the list. 2. I get an email saying "Careful, you emailed the list. Are you sure?" 3. I confirm that yes, I really wanted my email to go to the list. and that would be annoying :) Cheers, Dave. -- maemo.org docsmaster Email: dne...@maemo.org Jabber: bo...@jabber.org ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Allowing non-subscribers to post on the mailing lists
Hi, Dave Neary wrote: > I found a patch to mailman which was proposed in 2003, don't know if it > was ever included, or whether it's in our version, or even if it might > still be applicable: > http://www.mail-archive.com/mailman-us...@python.org/msg14876.html I got some more info from Olav Vitters of GNOME - it's possible in later versions of Mailman - including ours - to do this without patching mailman. You just need to add "@" to the list config parameter "accept_these_nonmembers" for each list where you want emails to go through from all people subscribed to "". So, in this case, we would just need to create a post-only mailing list that anyone could subscribe to, but no-one could post to, and then for each relevant list, add "@post-only" to the list of non-members whose posts are accepted (and then filtered through all of the other moderation criteria). Cheers, Dave. -- maemo.org docsmaster Email: dne...@maemo.org Jabber: bo...@jabber.org ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Allowing non-subscribers to post on the mailing lists
Hi, Auke Kok wrote: > That sounds really interesting, I'll see if this is currently > technically possible, and if so, I'll propose this to be implemented. I found a patch to mailman which was proposed in 2003, don't know if it was ever included, or whether it's in our version, or even if it might still be applicable: http://www.mail-archive.com/mailman-us...@python.org/msg14876.html Cheers, Dave. -- maemo.org docsmaster Email: dne...@maemo.org Jabber: bo...@jabber.org ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Allowing non-subscribers to post on the mailing lists
Hi, Felipe Contreras wrote: > One way to achieve this is to only require a subscription to _one_ > list, in order to allow sending messages to all of them. I have never > seen anybody doing this though. GNOME has a "post-only" email list, which anyone can subscribe to. If they're subscribed to that list, they can post to any public email list on gnome.org without moderation. There is also a happy medium between allowing unmoderated posting and dropping mail from unsubscribed senders - and that is enabling mailing list moderation & spreading the moderation load among half a dozen people. Cheers, Dave. -- maemo.org docsmaster Email: dne...@maemo.org Jabber: bo...@jabber.org ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Touch support in X
Hi, Thiago Macieira wrote: > Em Sexta-feira 15 Outubro 2010, às 10:43:48, Thiago Macieira escreveu: >> Em Quarta-feira 06 Outubro 2010, às 10:54:39, Thiago Macieira escreveu: >>> So we're not going to update to X.org 1.10? >> I still need a position here: is MeeGo 1.2 going to use X.org 1.10? > > Due to the lack of reply, given the indications I've heard in private emails > and given the above email from the xorg-devel mailing list, I have to > conclude > that MeeGo 1.2 will not upgrade to X.org 1.10. Looking from outside, this looks like a major problem. There has been no reply to a repeated time-critical question on a major component of the platform since Arjen's mail (which didn't address the version of X) 2 weeks ago. A significant piece of functionality is missing from current versions packaged in MeeGo, a maintainer of a module is asking for architect input, and none has been forthcoming in spite of 3 different emails. Is there going to be any transparency and accountability in the choice of upstream components and their versions for MeeGo? I'd really like to see someone replying "No, we're not taking that, because...", or "We could take that, if..." - the radio silence is killing me here. Cheers, Dave. -- maemo.org docsmaster Email: dne...@maemo.org Jabber: bo...@jabber.org ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
[MeeGo-dev] [Fwd: GTK+/MeeGo Handset integration work, call for bids]
Hi all, This announcement looks relevant both to MeeGo and Maemo developers, so I hope people won't mind me forwarding it along (for information). Thanks, Dave. -- maemo.org docsmaster Email: dne...@maemo.org Jabber: bo...@jabber.org --- Begin Message --- The GNOME Foundation is looking for developers to enhance the developer experience of using GTK+ to port and create applications on MeeGo Handset devices. Knowledge of the MeeGo Handset development process, and GTK+ internals will be required to carry out the work. The tasks to be achieved are: - Ensure that GTK+ applications display as expected on the MeeGo Handset platform, including checking that fixes to the compositor are made if necessary. - Add to upstream GTK+ helper functionality to create stand-alone GTK+ applications to run on MeeGo. - Merge Hildon widgets functionality into GTK+ upstream, where it makes sense to do so. The money available for the project is $50,000, and the bidder selection will be made by a group including professional consultants with GTK+ and MeeGo experience and GNOME Foundation Board members. Bids should include: - Results of testing stock GTK+ applications on the MeeGo Handset platform - Details of your research into what GTK+ functionality needs to be added to ease porting of stock applications to MeeGo Handset. - The list of widgets and functionality ported from Hildon to upstream GTK+, including a review of how the functionality would be integrated (extending existing widgets, new widgets, etc.) - A time line and schedule for the whole project - References to previous MeeGo, MeeGo Handset, Maemo, or GTK+ work. Note that the goal of the GNOME Foundation for this project is upstream acceptance of the various modifications made during the project. Please send your proposals to board-l...@gnome.org with the subject line "MeeGo Handset Bid". Regards ___ foundation-announce mailing list foundation-annou...@gnome.org http://mail.gnome.org/mailman/listinfo/foundation-announce --- End Message --- ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Future of N900 as a MeeGo platform?
Hi, Quim Gil wrote: > On Tue, 2010-10-12 at 16:49 +0200, ext Dave Neary wrote: >> What does this mean for the N900 as a reference platform for MeeGo >> development? > > Please feel free asking at the TSG tomorrow, but in the meantime: As I said, unable to attend. In general, (just to repeat what I said to you on IRC) I don't think it's good to have an entry on a meeting agenda, a 2 minute discussion at a real-time meeting, and one line in minutes be the only way that fairly major changes like this get announced. I would have liked to see it proposed & explained here (or on maemo-community) first. If the TSG is about ratifying things that have already been discussed, then this definitely deserved some discussion, no? > Nothing new? > >> Does it mean that Nokia are basically moving on, and >> leaving Carsten in place as a life-buoy for the N900 version? > > No, it means that the guy that is doing a great job gets the > corresponding role explicitly assigned. Good to hear it. > But "casual observers" were saying that the MeeGo meritocracy requires > key roles being taken by non-Nokia and non-Intel contributors... And if that's what's happening, great. If this were associated with a reduction in resources for MeeGo on N900 on the part of Nokia, that would be a concern. If that's not happening, then great - I'm glad we cleared this up before it got to the stage of being a misunderstanding. >> Can those involved elaborate on what this would mean for N900 MeeGo >> users, please? > > For N900 users? Definitely nothing. N900 *MeeGo* users. Anyway, thanks for the information. Cheers, Dave. -- maemo.org docsmaster Email: dne...@maemo.org Jabber: bo...@jabber.org ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
[MeeGo-dev] Future of N900 as a MeeGo platform?
Hi, I just noticed in the agenda for the TSG meeting tomorrow (which I won't be able to attend) the following agenda item: * Nomination: Nokia N900 hardware platform maintainer: Carsten Munk. * Valtteri Halla/Nokia is proposing to nominate Carsten to replace Harri Hakulinen in this role. Carsten is a renowned developer and founding maintainer of the mer project. Nokia supports Carsten and development of MeeGo for N900 in various ways including allocating a team of developers led by Harri and providing technical support. What does this mean for the N900 as a reference platform for MeeGo development? Does it mean that Nokia are basically moving on, and leaving Carsten in place as a life-buoy for the N900 version? As a casual observer, it could look like Nokia are withdrawing official support for development & maintenance of MeeGo on N900 and leaving it to be "community" supported. Can those involved elaborate on what this would mean for N900 MeeGo users, please? Thanks, Dave. -- maemo.org docsmaster Email: dne...@maemo.org Jabber: bo...@jabber.org ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] dbus-send command/python dbus way for launching voip call through GTalk on N900
Hi Praveen, praveen koduru wrote: > I am looking for voice call through Gtalk on N900 from command line like > dbus-send command or python-dbus. I'm afraid I don't have an answer to your question, but if/when you get an answer, would you mind taking a minute to synthesise it into a use-case in the wiki, please? It will help enrich it as a knowledge base for those coming after you. You might consider using the use-case template at http://wiki.maemo.org/Documentation/Use_case_template and adding the page to the bottom of http://wiki.maemo.org/Documentation (perhaps the page name could be http://wiki.maemo.org/Launching_GTalk_voice_call ?) Cheers, Dave. -- maemo.org docsmaster Email: dne...@maemo.org Jabber: bo...@jabber.org ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Still question on MeeGo on devkit8000
Hi, Andy Lee wrote: > This is HOWTO to make devkit8000 work with meego > > 1. update u-boot to 2010.06 > 2. download kernel from 2.6-stable-devkit8000 > 3. get the board-devkit8000.c, id.c, id.h from > gitorious.org/devkit8000/linux-omap-devkit8000.git and replace the one > in 2.6-stable-devkit8000. > ( this step is very important. otherwise you wont get DM9000 and > USB..etc work ) > 4.build 2.6-stable-devkit8000 ( result: uImage 4.3M) > 5. Follow meego on beagleboard from scratch and create rootfs and SGX > driver. 4.0.0 > 6. SD card needs to have SWAP partition. > 7. set u-boot command omapdss.vrm=0:12M,1:0M,2:0M (in my case, 4M:4M:4M > does not work for me) It would be really useful to have step by step guides like this (complete with notes on various gotchas like we've seen in this thread) in the wiki where they can be referred to, updates & improved. Perhaps you could create a Devkit8000 page with these steps and link to it from http://wiki.meego.com/ARM? Thanks! Dave. -- maemo.org docsmaster Email: dne...@maemo.org Jabber: bo...@jabber.org ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Review board for MeeGo
Hi, Ryan Ware wrote: > On 09/18/2010 08:50 AM, Felipe Contreras wrote: >> And I don't like either. I suggest mailing lists for code review, just >> like many successful and dynamic projects do (linux, qemu, ffmpeg, >> vlc): >> http://felipec.wordpress.com/2010/01/19/why-bugzilla-sucks-for-handling-patches/ > > Sorry for the delayed response, but I completely agree with this for a > number of reasons. We have to keep in mind that much of the development > actually needs to go upstream. The vast majority of the code in MeeGo > comes directly from upstream. Yes, we do have some patches and other > items that _are_ MeeGo specific, but that needs to be the very > infrequent exception and not the rule. Can anyone name a single other Linux distribution that does patch review on a mailing list? I can't think of one. linux, qemu, ffmpeg and vlc are all single projects rather than aggregations of hundreds of packages. Different community, different needs. Cheers, Dave. -- maemo.org docsmaster Email: dne...@maemo.org Jabber: bo...@jabber.org ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] [MeeGo-touch-dev] libmeegotouch 0.20.44-1 has been tagged.
Hi, Eero Tamminen wrote: > Nokia is currently the one with most MTF applications & testing which > provides the fast feedback loop on issues that applications developers > are encountering when using it. > > I.e. I think in this MTF "maturization" period there's some benefit > of this tighter coupling. The problem is that the longer this coupling continues, the harder it is to change. The more bugs that are open against MTF with potentially sensitive information, the more work there is to open development afterwards. The longer developers continue to follow internal processes and not have to think about community developers, the harder it is for them to change their work habits. Nokia has experience with this from the past, and I would have thought the opportunity for a "do-over" with MeeGo would have meant not making the same mistakes again in the interests of short-term expediency. Cheers, Dave. -- maemo.org docsmaster Email: dne...@maemo.org Jabber: bo...@jabber.org ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] How to buy a LCD and connect to beagle?
Hi, lovebird alexandrite wrote: > Thank you, Dave! > I`ve read this page. The device is too dear and impracticable for me, > is there any cheaper one? I'd just use the HDMI out to an LCD you already own, at the cost of not having touch. Cheers, Dave. -- maemo.org docsmaster Email: dne...@maemo.org Jabber: bo...@jabber.org ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] How to buy a LCD and connect to beagle?
Hi, lovebird alexandrite wrote: > I would to follow this > wiki http://wiki.meego.com/ARM/Meego_on_Beagleboard_from_scratch, and > try to run Meego on beagle board. > > Now, I have a beagle board, but no LCD, is the LCD out of the box? Or I > should to buy a LCD module and connect to beagle board myself? > > Some one who can tell me how to buy a LCD for beagle board, and connect > to it? Openismus have a tutorial online about getting Maemo 5 up & running on a Beagleboard, which includes all of the accessories, casings & cables which you might need, complete with links to vendors. They also listy a touch-screen LCD on there. The same information applies for MeeGo. http://www.openismus.com/documents/linux/embedded/beagleboard_getting_started Cheers, Dave. -- maemo.org docsmaster Email: dne...@maemo.org Jabber: bo...@jabber.org ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Trademark compliance, name usage, etc.
Hi, Andrew Wafaa wrote: > So what about when we do a release statement to not just the openSUSE > community, but the wider community? Most users won't download the > source to see who actually gets the credit - if it isn't on the release > announcement then they obviously weren't important enough. I like to > give credit where it is due, and right or wrong the MeeGo project > deserves a large amount of credit. I would say if the MeeGo project has a problem with you using the trademark, you have no choice. That means just following the terms of the license, which describes what credit the original author expects. You don't credit every project that produces code in the name or tag-line of a Linux distribution. > So to ensure that I and anyone else don't get mauled by any legal > hyenas, could we get a list of packages that would contravene the > branding/trademark/whatever so that re-spinners like myself, Peter and > other can take appropriate action and remove any contravening artwork? > > The only package that explicitly mentions anything about Trademark or > has a restricted license is meego-icon-theme, but I have heard mention > in passing that mutter-meego and all the meego-*-panel apps also contain > artwork that may anger the hyenas. That's someone else's department... if it's free software, I'd be happy to follow the license. There's a reason why Firefox packaged artwork separately from the GPL-packaged browser. Cheers, Dave. -- maemo.org docsmaster Email: dne...@maemo.org Jabber: bo...@jabber.org ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Trademark compliance, name usage, etc.
Hi, Greg KH wrote: > So, let me ask this a different way, for "respins" like Fedora and > openSUSE are doing, how should they refer to them. "Based on the MeeGo > UX components"? "Happens to look like the MeeGo screenshots, but we > can't say the word 'MeeGo' because their lawyers are a bunch of raving > hyenas"? Something else? It seems like the path of least resistance for all involved is simply to package the software without giving top-line (as in, project name) credit to MeeGo as the upstream. "OpenSuse Netbook", "Fedora Netbook", "Debian Netbook", etc. The MeeGo project will of course be correctly credited with copyright notices in the source code for those who download that. If the MeeGo project doesn't *want* credit from remixes, then why give it? Do you think there's a particular brand value in having a remix associated with MeeGo? This feels a little like a reverse "GNU/Linux" debate at this stage :) "GNU/Linux/X/freedesktop.org/GNOME/Qt/MeeGo based OpenSuse Netbook Edition" might be a mouthful for people, though... Iceweasel may also provide historical context... Cheers, Dave. -- maemo.org docsmaster Email: dne...@maemo.org Jabber: bo...@jabber.org ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] [MeeGo-touch-dev] libmeegotouch 0.20.44-1 has been tagged.
Hi, Valerio Valerio wrote: > Good points, but depends what you consider "commercially sensitive > information", I bet some of these bugs have cores, logs and all kind of > information that can easily leak device specs and other informations > that can be considered sensitive. You mean, the kind of information we in free software projects routinely ask bug reporters to give us, to help fix the bugs? Cheers, Dave. -- maemo.org docsmaster Email: dne...@maemo.org Jabber: bo...@jabber.org ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Trademark compliance, name usage, etc.
Hi, Ibrahim Haddad wrote: > You can apply patches against > components in the MeeGo Core stack and you can add new components but > not to replace existing MeeGo components. How far can this patching go? Do you have to be API compatible? ABI? Or can I do: git clone networkmanager git clone connman diff -uc networkmanager connman > "connman.patch" ? Cheers, Dave. -- maemo.org docsmaster Email: dne...@maemo.org Jabber: bo...@jabber.org ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Trademark compliance, name usage, etc.
Hi Ibrahim, Ibrahim Haddad wrote: > As for the remark on connman, my personal thoughts on this are the > following: MeeGo compliance is stack based meaning you need to use MeeGo > Core as-is - you need to use same base code, same package format, same > package naming/versionning, etc. What is the name of the netbook UI component(s) of the MeeGo Netbook UX? Cheers, Dave. -- maemo.org docsmaster Email: dne...@maemo.org Jabber: bo...@jabber.org ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Trademark compliance, name usage, etc.
Hi, Peter Robinson wrote: >> If so, great, what's happening with a few distros that are shipping >> "MeeGo" without using ConMan? > > Fedora is planning on stripping the MeeGo logos and just using the UX > as if it was gnome/kde. Just wondering, what do the UI developers call the MeeGo desktop environment? There is more than Mutter, right? meego-panel-myzone, meego-panel-people, etc (collectively called meego-panel, I guess?) If the UX layer had a name other than "MeeGo" or "MeeGo Netbook UX" then presumably there'd be less of an issue. But if that's called "MeeGo Netbook UX" (breaking MeeGo's own trademark guidelines) then calling it that without the entire MeeGo stack there doesn't seem to me to be a problem. Cheers, Dave. -- maemo.org docsmaster Email: dne...@maemo.org Jabber: bo...@jabber.org ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Meego spec - for comment
Hi, I'm starting to see some of the subtleties here, I think - and I'm not sure we're all talking about the same things - it seems to me like the various constraints, goals & value of an application compliance programme are not exactly the same for the different actors here. Skarpness, Mark wrote: > On Sep 15, 2010, at 1:16 PM, Graham Cobb wrote: >> But app stores are not going to be in the business of selling compliant apps! > yes they will - that is the whole point of MeeGo compliance - to get > scale in the application ecosystem by enabling applications to run > across multiple devices. If there is a very well-stocked repository of community applications which are non-compliant, resulting in many people running non-compliant apps on their devices, then the value of a "MeeGo compliant" label for application developers will go down. To me, the whole point of having MeeGo compliant applications is to (1) give users a way to know which apps are of a certain standard (kind of a quality mark) and (2) to let application developers know what best practices are for application development (endorsed APIs & distribution channel). If a substantial number of the most commonly used apps are not compliant, won't that muddy the waters at both ends of the pool? The third axis of application compliance you've hinted at are the implied responsibilities of stack vendors. This, it seems to me, is the key difficulty we have. You are saying (if I understand correctly) that every MeeGo stack must provide access to every MeeGo compliant application. Is this a requirement? If platforms "must" allow installation of all MeeGo compliant applications, and MeeGo Extras (or whatever the shared repository of community-packaged applications will be called) applications which depend on libraries in the usual way can be compliant, then yes, you're requiring stack vendors to provide a mechanism for enabling Extras and doing dependency resolution. Perhaps there is a way to phrase this so that vendors must support the installation of apps which are self-encapsulated, and may provide a means to install apps which have MeeGo compliant dependencies? >> This whole "MeeGo compliant" thing is about creating very high volumes of >> low-end, mainly free, apps. The high value apps that app stores care about >> are not affected. And for low end apps, it has to be quick, easy and cheap >> to develop or port them. And many of them will be in MeeGo Extras. > No, I don't agree. MeeGo compliance is about creating a large, > unified application ecosystem with apps sold through multiple app stores on > multiple devices. How do you see the end result looking? Let's take an example of 2 vendors: let's say Linpus and Novell. In my mind: MeeGo provides the app store infrastructure (similar to Android Market) which both Linpus & Novell are required to enable access to in their devices. MeeGo also provides build, packaging & hosting facilities for the MeeGo Extras, which may or may not be enabled by default on Linpus & Novell devices. If enabled by default, MeeGo Extras applications would show up in the app store as free applications (similar to Hildon Application Manager). If Novell or Linpus wanted to provide vendor- or device-specific app stores, they could also do that, provide the upload & hosting facilities, and have those extra applications also show up in the app store client. The user would be able to see in the interface which apps are MeeGo compliant, and which come from the vendor app store. I could also imagine the potential for a "Nettbook app store" for applications tailored for the netbook UX, which would be another common app store between Novell & Linpus, but which would not be used by GENIVI or Nokia. It seems that in your mind, each vendor will provide their own app store, that MeeGo will not provide any build, packaging or hosting facilities, and that the products of the MeeGo project will start & end with the core distribution + specs on what makes up a compliant application. The burden of providing a distribution channel & hosting is entirely pushed to the vendors. Is that a fair assessment? If it is, where do you see community apps being distributed? How would Linpus users be able to get at & install applications from the Novell app store? Perhaps I'm misunderstanding how you see this working in practice. If so, perhaps you could clear up my misunderstanding a little? Thanks! Dave. -- maemo.org docsmaster Email: dne...@maemo.org Jabber: bo...@jabber.org ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Meego spec - for comment
(correction) Dave Neary wrote: > In theory, depending on external apps will raise the average space used > when installing 100 apps, but it does not give any decent way to > evaluate the maximum space that will be needed for 100 apps. That should be, "In theory, allowing dependencies will reduce the average space used when installing 100 apps, but it does not give a decent way to evaluate the maximum space needed for 100 apps". Dave. -- maemo.org docsmaster Email: dne...@maemo.org Jabber: bo...@jabber.org ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Meego spec - for comment
Hi Mark, Skarpness, Mark wrote: > It actually does matter to those deploying devices. A few examples of why: > > If compliant apps are allowed to have external dependencies - then > someone has to pay to host and maintain those dependencies so they are > available worldwide to many millions of devices. Won't that be the MeeGo repository? > As someone building a device - how do I know how much storage is required for > the OS in order to run compliant apps (as Arjan pointed out earlier in the > thread)? This reminds me of an epiphany I had a few years ago when working with a buy who was an embedded developer. He told me stories about doing real-time development & having to turn off all caching for the OS and applications for an embedded application that was going into space - it didn't matter that the average response time was going to be increased from 0.01s to 0.5s, what mattered was that he could give, with absolute certainty, a *maximum* response time. Being better in theory was less important than being predictable & reproducible. In theory, depending on external apps will raise the average space used when installing 100 apps, but it does not give any decent way to evaluate the maximum space that will be needed for 100 apps. However, including all dependencies in packages will always give a higher space requirement for the 100 apps than splitting them out... either all dependencies are used by exactly one package (in which case the result of including them or splitting them is the same) or at least one dependency is shared by at least two packages (in which case splitting them out is better). There is no situation where having separately-packaged dependencies will use more space than dependencies wrapped in the package. It occurs to me that going in this direction would be like returning to the early days of Linux when there were no dominant distributions or common base packages or decent dependency resolution, and WordPerfect, Applix, Oracle and all the other commercial apps that started supporting Linux used to ship huge statically linked packages. Can we all agree that the world was a worse place for Linux users back then? > Absolutely - but MeeGo also needs to meet the needs of people > building commercial device products and applications - so the rules for > how you build and distribute that GPL application may be a bit different > then they would be for a "standard" Linux distro. I guess I can assume that most people here have not been in the business of building commercial device products and applications - it seems like there are not a lot of people from that segment here to defend their own needs. Perhaps it would be useful to go over the core requirements that these constituencies have? I can get that a commercial application developer wants to be able to build a package which will install on any MeeGo device... we're not talking about requiring that people split off dependencies, but allowing that things can be done like that. I can get that an app store might require these single packages for billing purposes, as you said. And I think that would be fine for anyone wanting to get into an app store. I'm still not very clear on what requirements a device vendor/distributor (or software strack provider) might want to impose on the software that would be installed on the device. Are there distributors who want to have a single approved source of applications for their devices that they support? And they don't want to be required to enable some wild hairy community repository? Or am I missing the point? A clear list of the constraints & requirements of commercial developers & distributors would be, I think, useful. Thanks! Dave. -- maemo.org docsmaster Email: dne...@maemo.org Jabber: bo...@jabber.org ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Meego spec - for comment
Hi, Warren Baird wrote: > On Mon, Sep 13, 2010 at 3:53 PM, Quim Gil wrote: >> For clarity, I would restrict the word "compliance" to the official >> MeeGo compliance based on the official API. "A MeeGo compliant app runs >> on any MeeGo compliant device". If we dilute this we are opening a >> Pandora's box. >> >> The MeeGo Extras stable repository would contain apps tested to work on >> top of official MeeGo releases. No "compliance" word needed: they are >> "extras". > > Hmm. That does solve the problem --- but it seems to me that having > Extras - which might well be the vast majority of MeeGo apps, at least > initially - not have some kind of official 'stamp' is a weakness, at > least on the PR side... > > App developers might well view it as a slight that their apps aren't > compliant, and users might well be less inclined to run apps that > aren't officially compliant... I agree - MeeGo Extras should be a repository of compliant applications. And a compliant application, in this context, should be an application which uses only MeeGo core APIs or MeeGo compliant libraries distributed in Extras. And a MeeGo compliant library is a library which uses only MeeGo core APIs or other compliant libraries. Cheers, Dave. -- maemo.org docsmaster Email: dne...@maemo.org Jabber: bo...@jabber.org ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Meego spec - for comment
Hi, Arjan van de Ven wrote: > The moment you have variants, where you allow the variants to add their > own stuff on top, you can't have an "Extras" repository that works for > all of these variants anymore, only one that works > for the reference. > > And once that's the case. you really can't say "oh but you can > depend on anything that's in Extras". Or even "you can depend on things > that are not in the required set" to be honest. Why not? You can define MeeGo compliant libraries as "libraries which depend only on packages in the core" and MeeGo compliant applications as "applications which depend only on what is in the core, or MeeGo compliant libraries", and perhaps include a definition of how dependency resolution should happen. Making Extras a "blessed" repository of packages would nicely solve that issue - you can restrict further dependencies to "libraries which are included in the core, or MeeGo compliant libraries available in Extras". Cheers, Dave. -- maemo.org docsmaster Email: dne...@maemo.org Jabber: bo...@jabber.org ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Meego spec - for comment
Hi, Wichmann, Mats D wrote: > Warren Baird wrote: >> Seems to me like the wind is blowing in the other direction, at least >> on this mailing list... > > yes it is, I didn't mean to imply otherwise. more that the > architects has seem pretty set on this idea. Are any of them here, and willing to explain/debate the reasons behind their preference? > I think if there's something used widely enough there's a space > wastage issue by it not being "shared" then there's a case it > belongs in the core after all. To give just 3 packages that don't really belong in the core, but would potentially be used by many 3rd party applications: - kdelibs - SDL - Gecko There are others. There are families of applications which share core libraries, and while it makes no sense to include the library in a platform where none of those applications are present, it makes a lot of sense not to ship the library bundled, because chances are if you're installing one of the family, you'll install others. Cheers, Dave. -- maemo.org docsmaster Email: dne...@maemo.org Jabber: bo...@jabber.org ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] QA guys: Wiki clutter?
Hi, Dave Neary wrote: > Zhao, Fan wrote: >> Agree, and all handset test reports have been restructured like: >> http://wiki.meego.com/Quality/HandsetTestReport/UXWeekly20100706 > > Would it bother you to avoid the extra subpage level and just use >http://wiki.meego.com/Quality/UX weekly report 20100706 > please? > > Also, if you wouldn't mind using "Handset test report" instead of > "HandsetTestReport", your page names will be consistent with the rest of > the wiki. We're still seeing namespace clutter from the UX generated pages in the wiki. Page names like http://wiki.meego.com/Quality/HandsetTestReport/UXWeekly20100908 are not consistent with the rest of the wiki, and there are now dozens of pages like this. Back in July, I suggested the following: > In general, if the testing team are going to be generating weekly test > reports, then unless there is historical interest in keeping old test > reports around, I would suggest that they be archived somewhere, and > that only the latest test reports (and, perhaps, the last test results > from a release to compare for regressions) be kept around. > > How does that sound? That got a nod of approval from Dawn at the time, but not from the test team. Dawn suggested that we could have one page with the 5 most recent test reports on the same page, and when adding a newer one, delete the oldest one. That sounds like a good idea to me. Jerry, Fan, what do you think? Cheers, Dave. -- maemo.org docsmaster Email: dne...@maemo.org Jabber: bo...@jabber.org ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Meego spec - for comment
Hi, Andrew Flegg wrote: > One hopes. So I encourage those of you who disagree to Mats' > conclusion to reply to his post. The process by which the spec will > get changed doesn't seem to be clear: feedback will be gathered and > Mats will publish a new draft? Who has to sign off on it, though? Just > the TSG? Nokia and Intel product managers? Also, there is another possibility here which hasn't yet been said: This spec specifies what a platform needs to do to be MeeGo compliant, and what an application needs to do to be MeeGo compliant. It doesn't say that only MeeGo compliant applications will be distributed on MeeGo extras. It's possible, then, that most of the apps on MeeGo Extras (basically, any app that has dependencies not included in the MeeGo compliant platform) will not be MeeGo compliant. To me, that reduces the value of MeeGo compliance for the user, but it's certainly a possibility. Cheers, Dave. -- maemo.org docsmaster Email: dne...@maemo.org Jabber: bo...@jabber.org ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
