[MeeGo-dev] MeeGo OBS shutdown - huge thanks and moving on
Hi everyone As we knew the MeeGo infrastructure is closing down. The MeeGo OBS is scheduled for shutdown at the end of next week ~ 29 May. I should have announced this earlier but I've been busy; sorry. Please ensure you've taken backups of anything you need - once it's gone it really will be gone! I'd like to take this opportunity to thank everyone at Intel for continuing to support the MeeGo community for this long with a HUGE special mention to Adam Gretzinger who has helped look after the infrastructure in an efficient and reliable way - if you ever have him as a sysadmin for your project then I'm jealous! Thanks also go of course, to Neils Breet and Islam Amer who have worn MeeGo sysadmin hats and continue to do so in our new home at the Mer Project. So with that segue we can look forward to where we've built on the open elements of MeeGo - and hopefully improved them - in the Mer Project. See https://wiki.merproject.org/ and http://www.merproject.org/ for more info If you do (or would like to) build opensource projects against Mer, Nemo or PlasmaActive - or plan to build for Jolla's SailfishOS (https://www.sailfishos.org/) - and want to use the Mer Community OBS at https://build.merproject.org/ you're welcome. Register on our bugzilla https://bugs.merproject.org/ for an account and talk to us on irc in #mer on freenode or on the mailing lists. Due to resource limitations we will only be able to support builds against Mer based distros (with some special cases for our infrastructure tools like OBS, BOSS, IMG etc) - but do talk to us if you have any questions. I'll continue to act as a volunteer sysadmin until the lights go out; it's been an experience and a pleasure working with the MeeGo community. David Greaves / lbt Soon to be ex-MeeGo.com sysadmin but now Mer Co-Founder and Vendor-relations Guy -- Don't worry, you'll be fine; I saw it work in a cartoon once... ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
[MeeGo-dev] The future for the MeeGo OBS
The MeeGo OBS at build.meego.com is down... again. The MeeGo IT team renew their offer to provide additional service level support for the main OBS. This would allows the community to have some confidence in the continuity and availability of these important services and provides the commercial organisations still working on MeeGo with the same confidence. This means that everyone who wants to work on any aspect of MeeGo Trunk is essentially blocked. This is not a recent issue: https://bugs.meego.com/show_bug.cgi?id=22134 A few weeks ago the MeeGo IT team (ie the guys who run DNS, www.meego.com, the mailing lists, the forum, the community OBS etc) asked for permission to access the main OBS to provide support. This was refused. An explanation was due to be given but some urgent issues apparently prevented that. Since this was mere weeks before the shift to Tizen it is possible that that was related. In any case it is time to revisit this request. Ryan - I think you got landed with being point-man last time so I'm cc'ing you directly :) Since MeeGo is a Linux Foundation project I'm cc'ing you too Brian. Anas - I guess the OBS used to be your responsibility but I have no idea if it still is. Imad - just so you know. To illustrate the problem this graph shows availability of the main OBS: http://isobsdown.bfst.de/trends.api-obs_api.1314144000_1317921806_2011-10-06T17.23.26.png This shows corresponding availability of the community OBS: http://isobsdown.bfst.de/trends.cobs_api-obs_api.1314144000_1317921806_2011-10-06T17.23.26.png David Niels (Stefano is on vacation) -- Don't worry, you'll be fine; I saw it work in a cartoon once... ___ 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] The future for the MeeGo OBS
I'm sorry Ryan I thought I was being polite and constructive so I'm not sure where the since long before you came aboard the project is coming from? I also realise I've only been around MeeGo almost every single day since the day it launched - I'll try harder to be more passionate, more visible and part of it for longer next time around :D So, back to the question: We, as members of the 'official' MeeGo IT team, are offering to help support some MeeGo infrastructure which is clearly not being maintained to anything like a professional standard. I did copy the only known member of the TSG in on the email as well as Anas and Brian. I'm sure many others in both the hacker community and the commercial community feel that there's a very high risk associated with relying on an apparently absent RE team and on a service which is now at 80% availability. At least the MeeGo IT team are present and replying to email and irc - both in US and EU timezones. David PS I do get the impression that people think we're on some kind of power-trip and want to take over the main OBS. Well, trust me, looking after an OBS as well as the rest of the MeeGo.com infrastructure is a HUGE chore, *not* fun. It eats massively into our personal time and can be immensley frustrating. We do however take our responsibility seriously and as professionals and community members we hate to stand by and let people suffer when we could easily help out. On 12/10/11 15:32, Ware, Ryan R wrote: David, The MeeGo OBS is the purview of the Release Engineering team. It has been that way since long before you came aboard the project. If you have concerns about that, please bring it up with the TSG. Ryan -Original Message- From: David Greaves [mailto:da...@dgreaves.com] Sent: Wednesday, October 12, 2011 2:40 AM To: meego-dev@meego.com; Ware, Ryan R; brian.war...@linuxfoundation.org; Sousou, Imad; Anas Nashif; meego- i...@meego.com Subject: The future for the MeeGo OBS The MeeGo OBS at build.meego.com is down... again. The MeeGo IT team renew their offer to provide additional service level support for the main OBS. This would allows the community to have some confidence in the continuity and availability of these important services and provides the commercial organisations still working on MeeGo with the same confidence. This means that everyone who wants to work on any aspect of MeeGo Trunk is essentially blocked. This is not a recent issue: https://bugs.meego.com/show_bug.cgi?id=22134 A few weeks ago the MeeGo IT team (ie the guys who run DNS, www.meego.com, the mailing lists, the forum, the community OBS etc) asked for permission to access the main OBS to provide support. This was refused. An explanation was due to be given but some urgent issues apparently prevented that. Since this was mere weeks before the shift to Tizen it is possible that that was related. In any case it is time to revisit this request. Ryan - I think you got landed with being point-man last time so I'm cc'ing you directly :) Since MeeGo is a Linux Foundation project I'm cc'ing you too Brian. Anas - I guess the OBS used to be your responsibility but I have no idea if it still is. Imad - just so you know. To illustrate the problem this graph shows availability of the main OBS: http://isobsdown.bfst.de/trends.api-obs_api.1314144000_1317921806_2011- 10-06T17.23.26.png This shows corresponding availability of the community OBS: http://isobsdown.bfst.de/trends.cobs_api- obs_api.1314144000_1317921806_2011-10-06T17.23.26.png David Niels (Stefano is on vacation) -- Don't worry, you'll be fine; I saw it work in a cartoon once... -- Don't worry, you'll be fine; I saw it work in a cartoon once... ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
[MeeGo-dev] TSG Agenda request : Re: The future for the MeeGo OBS
Imad, Could you put this on the agenda for the next TSG meeting please. I'm not sure when that is; could you remind us all? David On 12/10/11 16:30, Ware, Ryan R wrote: David, As I pointed out, your clear path to address this is to take this up at the next TSG meeting. You will not resolve this issue in this email thread. Ryan -Original Message- From: David Greaves [mailto:da...@dgreaves.com] Sent: Wednesday, October 12, 2011 9:29 AM To: Ware, Ryan R Cc: meego-dev@meego.com; brian.war...@linuxfoundation.org; Sousou, Imad; Anas Nashif; meego...@meego.com Subject: Re: The future for the MeeGo OBS I'm sorry Ryan I thought I was being polite and constructive so I'm not sure where the since long before you came aboard the project is coming from? I also realise I've only been around MeeGo almost every single day since the day it launched - I'll try harder to be more passionate, more visible and part of it for longer next time around :D So, back to the question: We, as members of the 'official' MeeGo IT team, are offering to help support some MeeGo infrastructure which is clearly not being maintained to anything like a professional standard. I did copy the only known member of the TSG in on the email as well as Anas and Brian. I'm sure many others in both the hacker community and the commercial community feel that there's a very high risk associated with relying on an apparently absent RE team and on a service which is now at80% availability. At least the MeeGo IT team are present and replying to email and irc - both in US and EU timezones. David PS I do get the impression that people think we're on some kind of power- trip and want to take over the main OBS. Well, trust me, looking after an OBS as well as the rest of the MeeGo.com infrastructure is a HUGE chore, *not* fun. It eats massively into our personal time and can be immensley frustrating. We do however take our responsibility seriously and as professionals and community members we hate to stand by and let people suffer when we could easily help out. On 12/10/11 15:32, Ware, Ryan R wrote: David, The MeeGo OBS is the purview of the Release Engineering team. It has been that way since long before you came aboard the project. If you have concerns about that, please bring it up with the TSG. Ryan -Original Message- From: David Greaves [mailto:da...@dgreaves.com] Sent: Wednesday, October 12, 2011 2:40 AM To: meego-dev@meego.com; Ware, Ryan R; brian.war...@linuxfoundation.org; Sousou, Imad; Anas Nashif; meego- i...@meego.com Subject: The future for the MeeGo OBS The MeeGo OBS at build.meego.com is down... again. The MeeGo IT team renew their offer to provide additional service level support for the main OBS. This would allows the community to have some confidence in the continuity and availability of these important services and provides the commercial organisations still working on MeeGo with the same confidence. This means that everyone who wants to work on any aspect of MeeGo Trunk is essentially blocked. This is not a recent issue: https://bugs.meego.com/show_bug.cgi?id=22134 A few weeks ago the MeeGo IT team (ie the guys who run DNS, www.meego.com, the mailing lists, the forum, the community OBS etc) asked for permission to access the main OBS to provide support. This was refused. An explanation was due to be given but some urgent issues apparently prevented that. Since this was mere weeks before the shift to Tizen it is possible that that was related. In any case it is time to revisit this request. Ryan - I think you got landed with being point-man last time so I'm cc'ing you directly :) Since MeeGo is a Linux Foundation project I'm cc'ing you too Brian. Anas - I guess the OBS used to be your responsibility but I have no idea if it still is. Imad - just so you know. To illustrate the problem this graph shows availability of the main OBS: http://isobsdown.bfst.de/trends.api- obs_api.1314144000_1317921806_201 1- 10-06T17.23.26.png This shows corresponding availability of the community OBS: http://isobsdown.bfst.de/trends.cobs_api- obs_api.1314144000_1317921806_2011-10-06T17.23.26.png David Niels (Stefano is on vacation) -- Don't worry, you'll be fine; I saw it work in a cartoon once... -- Don't worry, you'll be fine; I saw it work in a cartoon once... -- Don't worry, you'll be fine; I saw it work in a cartoon once... ___ 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] OBS status
On 04/08/11 16:05, Nasa wrote: - Original Message - 2011/8/4 Nasanas...@comcast.net: Hi, I was wondering if anyone know about the status of OBS? I have been trying to upload files via the web interface without much luck -- it is giving me the following message: OBS Web Interface Error: Error Details: Errorcode: unknown Message: end of file reached I have tried this with a number of files and most (but not all) exhibit this behavior. So any clues on what might be going on? build.pub.meego.com or build.meego.com? build.pub.meego.com I'm not seeing this. Can you narrow it down? File size? As it is intermittent the best option may be to catch me (lbt) on irc and I'll watch the logs as you upload. David -- Don't worry, you'll be fine; I saw it work in a cartoon once... ___ 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
Take a deep breath Jeremiah :) This is not a good situation but it is managable and may help resolve some organisational issues wrt MeeGo - silver lining :) On 03/08/11 10:05, Jeremiah Foster wrote: Hardly cheap Dave. I'd say its rather expensive as my company and many of the companies we work with have assigned developers to work with LF tools and distro's like MeeGo and OBS. If we cannot develop things like app stores to compete with Google and Apple then we've invested considerable money at a significant loss. We cannot generate revenue through the authorized app delivery mechanism. Sorry, I don't see how this is not a fair reflection of the Linux Foundation. IMO this is nothing to do with App Stores generally. This is LF refusing to take a legal risk on an area they feel that they have limited control over. It is a bit sad but litigation in the US is not something a small company messes with. MeeGo as a project never (AIUI) promised to deliver an app store or a mechanism to deploy a local one. We in the hacker community wanted to support MeeGo by bringing OSS developers into the fold. Hopefully they'd help polish the tools and processes - and of course we'd get to publish our apps. So it was - and remains - a good idea for MeeGo. See later for why. 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. Yes. The question this raises for me is : is LF a suitable host for the MeeGo community. This is extremely dangerous. It goes against the precedent that says there exist no legal claims against Linux. Total red herring Linux != OSS Apps. 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). I don't know what you're referring to - perhaps you do have some special knowledge? All idle speculation but WTF are we supposed to do? The LF are just not communicating. I suggest that all we can do is some risk assesment as a project. Right now the limited information we have is that LF will not expose themselves to legal risk associated with binary distribution... so what happens to the main OBS? Home projects in the main OBS? Community OBS? CE project on the Community OBS? If my impression is correct, then you're not achieving anything with this characterisation - Obviously I disagree. I think devs who get involved with a LF project should know how they treat devs and the faux legal hurdles they face. Knowing this before hand helps them make the right decision when it is time to contribute code. Given a choice I personally would not currently choose to use the LF to host an OSS project. Maybe I would choose them to do some corporate hoorah; honestly I don't know what 'services' they offer but clearly hosting an OSS community isn't one of them. But in the end, developers vote with their contributions, so we can molly coddle a thousand legal eagles and not advance GNU/Linux one tiny inch forward. David Greaves has done the only logical thing when you hit an impasse; fork. I certainly wouldn't consider it a fork - as this unfolded I was working with Niels, Quim and Dawn too. I consider myself as working within the MeeGo project to find a suitable host for our community services. I feel I must emphasise that if anyone thinks that I'm working to fork or split MeeGo or do it better elswhere then I really have miscommunicated. I remain 100% committed to the MeeGo project and simply want to resolve our problems in the best way possible. Heh ... actually, IMO Dawn and Quim seem to favour the simple 'split' apps.formeego.org from meego.com. I feel I'm actually fighting to keep everything in one place. Why? Well, I personally feel there's a comprehensive community story around MeeGo : http://mer-l-in.blogspot.com/2011/08/restructure-meego-by-installments.html (Long read ... complex subject) LF bears some of the responsibility for this situation and to let them avoid it in their stony silence is irresponsible. 'some' ? otherwise +1 David PS I noticed the cc list is changing. Be polite and mention if/why you explicitly add or remove someone from the cc. -- Don't worry, you'll be fine; I saw it work in a cartoon once... ___ 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-community] LF will not permit apps.meego.com : say hello to apps.formeego.org
On 03/08/11 20:21, Jeremiah Foster wrote: What is the purpose of formeego.org http://formeego.org? To host apps for MeeGo? The purpose is not yet defined but a starting point may be to identify services that are not sanctioned by the MeeGo trademark owner but which are nonetheless important to the community. And although it is not under the auspices of the LF, it is not a fork? LF != MeeGo Community not by a long, long way ... Asking the community, as a whole, to re-assess how it relates to the trademark owner is not a fork. Nor is it in any sense abandoning MeeGo or the LF. It is understanding how best to structure an opensource project to deliver 'something' that is of value to organisations who wish to develop products. It helps acceptance to have an independent organisation to manage the trademark and compliance - LF does this. Equally it helps to have a community that is not hindered by the constraints of a commercial organisation - running certain tasks under an unbranded non-profit organisation may make it far less of an attractive target for the legal trolls and may be an appropriate way to support activities that LF have said they can't support. There need be no change in any day-to-day activities - merely a name change for the community (who really don't care *that* much) and a redirect of responsibilities for certain tasks that have legal risk. David -- Don't worry, you'll be fine; I saw it work in a cartoon once... ___ 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
On 03/08/11 20:12, Jeremiah Foster wrote: On Wed, Aug 3, 2011 at 6:55 PM, David Greaves da...@dgreaves.com mailto:da...@dgreaves.com wrote: Take a deep breath Jeremiah :) meh. The ad hominem attacks are irrelevant. *that* was an attack? It was meant to remind you that we're friends. This is not a good situation but it is managable and may help resolve some organisational issues wrt MeeGo - silver lining :) I have no idea what you're now trying to say. Are you saying; It's okay that I forked the official apps for MeeGo! Because forking is generally considered a Bad Thing. Just answered on the other thread. A fork generally involves 2 branches If we had apps.meego.com and apps.formeego.org then that would be a fork. Moving apps.meego.com to apps.formeego.org... that's not a fork On 03/08/11 10:05, Jeremiah Foster wrote: Yeah, someone else mentioned this is limited to the Linux kernel only. I really don't understand that approach. Free Software is governed by a license, not by some arbitrary location in the stack. The point would be to create a free software app store. Or at least give people the license to and tools create their own for MeeGo. Or perhaps just let them use the trademark if it works with MeeGo, but I guess we're going with the Android or iOS approach here. But if they do not stand up for developers creating apps for GNU/Linux distros, who will? Take that up with your congressman/MP/LF representative. I have to say that I don't expect to see We volunteer to throw ourselves under a lawsuit to defend your rights to an OSS App store anywhere on the LF website. I'd be interested to know why you think they should do that? How can the LF be scared of lawsuits? What happened to that giant trove of patents that IBM donated to Open Source? I'm sorry, I'm not buying it. No idea. Ask the LF. You do follow sites like Groklaw at least a little bit? You know that in the US it can costs millions of $ to simply defend a law suite? You know that's what you're fighting for when you fight against SW patents? So to me it's blindingly obvious why an organisation would think *very* hard about exposing themselves to that risk. Of course, they should also think *very* hard about just what services they can reasonably offer the community and maybe figure out how to help resolve the problem they've created. The question this raises for me is : is LF a suitable host for the MeeGo community. If you think that MeeGo is going to somehow magically escape the clutches of the LF you need to take a deep breath. They're not even going to provide an rsync server for the repos: https://bugs.meego.com/show_bug.cgi?id=19745 Again you conflate LF with the community Total red herring Linux != OSS Apps. Totally not. There is no proprietary code in the GNU userland either. So... you realise we're talking about something like Maemo Extras? Where random people upload random source code? Nothing to do with GNU userland (although the line is blurry which is my personal concern) There are also tools that go through GNU/Linux packages regularly looking for stolen code, things like FOSSology and protec so I think in general the GNU/Linux kernel and userland are pretty well covered as, at the very least, prior art. I'm sure we could get permission from one of those company's to use their tools on our app repos which would go a long way towards indemnifying LF. Feel free to debate it with them. The point is that it is *THEIR* decision - not yours. You may think your arguments are sound but their risk assesment may be different. Once you own LF then you get to make that decision. Which BTW, is why a non-profit, managed by the community may be a better place for our community services to be hosted. Is there a distro that you can work on that isn't controlled by the LF? Are there other Linux distros out there? I've heard of one or two. The LF are just not communicating. And yet you've decided to create your own app store with the trademarked term MeeGo in the name! Yes. See the bug already mentioned. Apparently formeego.org is OK. IANAL so I do not know exactly what logic makes it so. LF have not, so far, responded in detail. I will say that if I said Microsoft Office and Libre Office for Microsoft then most people would understand that the former is a Microsoft official product and the latter is intended to run on the Microsoft platform. David -- Don't worry, you'll be fine; I saw it work in a cartoon once... ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
[MeeGo-dev] LF will not permit apps.meego.com : say hello to apps.formeego.org
cc'ed meego-dev as this may be of interest. Followup to meego-community please. Also cc'ed relevant forums. Over the past few weeks a few of us who have been involved in the MeeGo community infrastructure have been trying to solve a problem relating to MeeGo Apps : apps.meego.com After a few weeks when it became clear we could not resolve this problem we asked for a deadline when the LF would announce this restriction to the community. Eventually I proposed that the community start discussing this issue with or without an announcement from the LF on Tuesday 2nd August - and here we are. Last week I suggested that the following statement summed up my understanding and although I asked for an alternative, one did not appear: 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. Ibrahim, if you have anything to add we would be grateful. I have tried to present a factual problem statement and some options at : http://wiki.meego.com/MeeGo_Apps/Problem_Statement Obviously, since we don't know what the problem is, it is hard to work out a solution - but I have proposed some options. In the meantime we have moved ahead to provide apps.formeego.org (thanks to Thomas for acquiring that domain - see https://bugs.meego.com/show_bug.cgi?id=20531). There are plans being worked on to setup infrastructure to host apps there - the community needs to decide how to manage that infrastructure and domain. On a personal note I am very disappointed by the Linux Foundation's response to this situation. There has been no open discussion, the verbal reasons provided were vague (although, I must emphasise, I am not doubting that there are valid concerns given the nature of the legal framework in the US) and insufficient effort has been made to assist the community in resolving (or even understanding) this problem - as I mention, since we're not clear about what the reason is we have no idea what other services may be impacted. David Forum Links: http://forum.meego.com/showthread.php?p=27975#post27975 http://talk.maemo.org/showthread.php?p=1062657 -- Don't worry, you'll be fine; I saw it work in a cartoon once... ___ 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 OBS down again... Without Warning?
On 30/07/11 10:59, Brendan Le Foll wrote: It seems that lately OBS is a strictly Monday to Friday service. Is this the new policy? Can we get some advance warning if this is normal maintenance, and if not what keeps going wrong on saturday/sunday? This is a real pain for people like me who thought the weekend would be a perfect chance to bootstrap an OBS. Thanks, Brendan As mentioned last week (after the outage the week before): http://lists.meego.com/pipermail/meego-packaging/2011-July/247843.html There was no reply to that message but the OBS did return shortly after. David -- Don't worry, you'll be fine; I saw it work in a cartoon once... ___ 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 app model in 2012: Rethinking the MeeGo app model to be more platform agnostic
On 31/05/11 10:25, Carsten Munk wrote: Yes, indeed - I've been fed the usual JVM and JIT knowledge through my university education like many others, but this isn't the approach taken in MeeGo currently as we have to write C++ for our native Qt Quick extensions and we don't have a JVM on each device. We have python. QML can access python objects directly if I understood Thomas Perl's excellent talk. David -- Don't worry, you'll be fine; I saw it work in a cartoon once... ___ 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 app model in 2012: Rethinking the MeeGo app model to be more platform agnostic
On 31/05/11 20:32, Michał Sawicz wrote: Dnia 2011-05-31, wto o godzinie 11:34 +0100, David Greaves pisze: We have python. QML can access python objects directly if I understood Thomas Perl's excellent talk. Yes, PySide would definitely be one way. But, as you can probably remember from QA on this session, there's still the problem of bundling all the python dependencies with your app, as python / pyside and all the other python stuff without which it loses a lot of its appeal. Or - even better - getting it to be part of MeeGo Core. Which, by the way, would IMO be great to have. Getting those into MeeGo or some other repo and reviewing how compliance works with 3rd party Components (to use an Intel AppUp term) would be *completely* incidental side effects that never even occurred to me ;) David ___ 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] Labels on switches widgets considered evil
On 28/04/11 16:56, Andy Ross wrote: On 04/28/2011 08:04 AM, David Woodhouse wrote: I am distinctly unimpressed by the fact that in GNOME 3 I have to click where it says 'OFF' to make my VPN connect, and click where it says 'ON' to make it disconnect. Can I set up a translation so that _(ON) == OFF and _(OFF) = ON? To continue this digression, does anyone else agree that Apple has set the boolean usability world back 10 years with these ridiculous sliders? They're cloned everywhere; I'm seeing them on web sites now too. The translation issue and the Wait, is that the current state or the new one?! problems are serious. +1 This thing takes a lot of screen real estate for a single bit of information (and it still requires some kind of label to explain it). +1 The physical usage mechanic (a tap) doesn't match the animation (it slides!). Ugh. +1 I know it's a bikeshed issue but thank you for raising this. Peering at these and attempting to use a touch interface/gesture to activate them was an unpleasant part of using the UX. David -- Don't worry, you'll be fine; I saw it work in a cartoon once... ___ 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 prevent unrequired build dependency remove when doing local osc builds?
On 06/04/11 13:15, Mika Laitio wrote: I have setted in my .oscrc build-root = /var/tmp/%(repo)s-%(arch)s If I first build mce locally with osc build armv8el Trunk_Testing, I have in my build root all packages that were required for building the mce on /var/tmp/Trunk_Testing-armv8el But If I will after that build kernel locally again with same osc build armv8el Trunk_Testing, osc will now install all additional dependencies required by the kernel build to this same /var/tmp/Trunk_Testing-armv8el directory. That's fine, but for some reason it seems also be removing all dependencies that were required by the MCE but are not required for the kernel build. The reasonong behind this is that OBS (and osc) are designed to build in clean chroots that are specified by the dependency chain initiated in the .spec. This ensures you have the correct package dependencies and don't inadvertantly ship code that FTBFS. Is there any method for preventing this? I know that one solution is to configure in oscrc a package specific build roots, but as each chroot takes about 1 gb of harddrive, I would rather try to have just arch specific chroots that contains all non-conflicting build dependencies for many different pacakages simultaneously. That pretty much defeats the purpose of osc build - but, if you want rope: osc build --extra-pkgs=PAC and repeat that for the build-deps for mce when building a kernel. Maye use a PAC==a meta-pkg to manage that list. That extra-pkgs can even go into your .oscrc ... this may or may not do what you want :) David -- Don't worry, you'll be fine; I saw it work in a cartoon once... ___ 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)
On 25/03/11 09:11, Ville M. Vainio wrote: On Thu, Mar 24, 2011 at 10:16 PM, Richard Dale richard.d...@telefonica.net wrote: I personally think that the Nepomuk non-application specific integrated data approach could be a killer feature of MeeGo. In comparison iOS is completely Agreed. Luckily tracker will still be there on the platform (as Marius stated earlier in this thread), so it can be used by willing applications. It's just that contact information is not *primarily* stored there anymore - but we can arrange for an (unofficial) way where it gets moved there from EDS anyway. Would it be helpful to have a branch project area on the community OBS? Conceptually this is similar to the Project:DE which is tracking trunk and maintaining an overlay. It may help to show me the code and to maintain patchsets over time as MeeGo:Trunk moves. David/lbt -- Don't worry, you'll be fine; I saw it work in a cartoon once... ___ 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] Packaging the MeeGo stack on Debian - Use the name ?
On 12/12/10 23:30, David Greaves wrote: I'm cc'ing th meego-community list as I think there are a lot of people there who are having similar conversations. On 09/12/10 19:12, Ibrahim Haddad wrote: The MeeGo Project members devoted quite a bit of time discussing these questions to make sure the responses are fair and most of all work to the benefit of the MeeGo project Where did this discussion happen? I didn't see it on the community mailing list Sorry if it's just me Ibrahim - I didn't see a reply to this question and can't find anything in the mail archives. I'd appreciate a pointer so I can do the right thing and read up on the discussion. Thanks David -- Don't worry, you'll be fine; I saw it work in a cartoon once... ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
[MeeGo-dev] OBS, MeeGo and the social desktop : Application information, feedback and rating
This is more of an initial exploration than a concrete proposal :) I'll post this to both the opensuse-buildserv...@opensuse.org and meego-dev@meego.com lists. MeeGo is going to be using the Open Collaboration Services (OCS) API. http://www.socialdesktop.org/ocs/ http://www.freedesktop.org/wiki/Specifications/open-collaboration-services One of the features of this is to provide feedback and ratings from the device/desktop to the application development team. MeeGo's community OBS will be used for developers to manage their applications and I was interested in the concept of using the OBS API to support this. The api already provides some rating services so it seems to fit in somewhere. https://api.obs.maemo.org/apidocs/#107 As I say, the use-case is something around providing feedback from the application launcher on the device; maybe an on-device popup that allows a star rating, comment etc that is linked back to the appropriate OBS package and team. So does this fit with the intended usage around the 'rating' type services already in the OBS? David -- Don't worry, you'll be fine; I saw it work in a cartoon once... ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] OBS, MeeGo and the social desktop : Application information, feedback and rating
On 28/10/10 11:46, Ville M. Vainio wrote: On Thu, Oct 28, 2010 at 1:41 PM, David Greavesda...@dgreaves.com wrote: As I say, the use-case is something around providing feedback from the application launcher on the device; maybe an on-device popup that allows a star rating, comment etc that is linked back to the appropriate OBS package and team. It seems like it combines two separate things: - Application - How/where it gets built Not quite. It requires that the installation of an application provides an optional OCS-compliant url for feedback. I'd rather see an entity separate from OBS as the starting point of a rating/comment system. Why? I'm talking about making the OBS support a standard API, not the other way around. This idea would allow the OBS to be replaced as keeper of ratings but in the meantime may also allow us some efficiency in reducing the number of systems we have to develop and support. The OBS already provides: * PPA -like repos * Extras-devel -like projects * Extras -like projects * per-package file storage (think screenshots) * ratings system * integration with MeeGo user account system It doesn't provide a comment system. Applications built with any system would reside there (including proprietary applications built in someones basement). This doesn't preclude that at all; provided the basement builder provides an OCS API somewhere. MeeGo community does provide a community build system.. the OBS ... which, as you say, needs to support rating/feedback somehow. The OBS has a rating system... no-brainer (well, at least as a potential solution). David -- Don't worry, you'll be fine; I saw it work in a cartoon once... ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Trademark compliance, name usage, etc.
On 23/09/10 20:05, Greg KH wrote: On Thu, Sep 23, 2010 at 12:20:27PM -0500, Ibrahim Haddad wrote: On Thu, Sep 23, 2010 at 12:06 PM, Dave Nearydne...@maemo.org wrote: 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? As a rule, patching should not break API or ABI compatibility. I don't see ConnMan providing an API or ABI, do you? If so, where is it documented? Not to be facetious ... but in the reference code? Isn't MeeGo supposed to be a reference implementation for people to build on top of? Sanity check... the objective is along the lines of: if I see a distro labelled .*MeeGo.* then I can assume that my MeeGo World[1] compliant app will find the complete set of services/apis/blah that the core provides. Will replacing ConnMan impact that? Maybe we should come up with a cute name for the UX and let that be used in the OSS world? David [1] thanks Graham - this one stuck even in the depths of my 'flu :) -- Don't worry, you'll be fine; I saw it work in a cartoon once... ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Trademark compliance, name usage, etc.
On 21/09/10 04:34, Greg KH wrote: On Mon, Sep 20, 2010 at 08:20:48PM -0700, Arjan van de Ven wrote: my understanding is that the license field in the (binary) RPMs contains restricted for these, with a detailed license inside the package. Do you have a list of which packages these are, or are we supposed to dig for them? :) There's work in the tools area on a packageDB/webui thingy that should make identifying packages by license etc fairly easy. Matter of priorities; it's not low though. David -- Don't worry, you'll be fine; I saw it work in a cartoon once... ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Meego spec - for comment
Allow me to invert this email and suggest some prioritisation. On 18/09/10 01:09, Skarpness, Mark wrote: What we have been discussing on this thread is the guidelines themselves... Good point ... and I have made one of the very few concrete proposals for wording in this thread ... and AFAICS it hasn't been even commented upon. Perhaps you'd care to go back to that? As I say... my objective is to permit (not mandate) MeeGo compliance for applications developed using the open-source development model which tends to favour componentised applications with cross app shared components. First of all, could you and Arjan (as the main objectors) clarify if this is a worthy objective for MeeGo? If it is an objective then I'd like to see us work to achieving it. If there are unsurmountable technical issues then... OK; lets back off until a solution can be found. My compliance wording proposal is: Applications *MUST NOT* require (in RPM terminology) packages that are not themselves compliant. Applications that require (in RPM terminology) packages that cannot be provided MUST NOT be installed. Please comment. Some irc conversation raised a few points: * What does compliance promise * Is compliance verification implicit I am assuming, respectively: * If you _install_ a compliant app then it will work * The on-device installer is not going to enforce or even verify that an application is compliant The first point means that the installer tool must verify dependencies before it installs an app; if the dependency installation succeeds then the application is installed. This will only affect users and applications using external dependencies. I hesitate to mention some technical thoughts as they are easy to critique before we address the main issues above; however: I would anticipate that installation from an app store could streamline this process through negotiation: this app needs X=ver,Y,Z... OK, can meet...here's the app I also assume the app store will need to know the profile of the device in order to satisfy small issues like making sure compliant x86 packages don't go to an ARM device ;) (To paraphrase Andrew Flegg... MeeGo compliant doesn't mean you have to run qemu!) This profile *could* include capabilities (enabled repos) which *could* be used to limit the users exposure to apps that they can run. Below is some further reasoning: On Sep 17, 2010, at 4:43 PM, Will Marone wrote: On 9/17/2010 12:02 PM, Quim Gil wrote: On Thu, 2010-09-16 at 12:13 +0200, ext Jeremiah Foster wrote: Supposing I wrote software and made it available via Extras/Surrounds, why is my app being there grounds to disqualify it for compliance even if it meets the guidelines fully? Certainly that's insulting to the author and implies things about their software that may be completely false. It's not. This has never been suggested by anyone. If your app meets the guidelines fully - then it will be qualified for compliance. Will, here is where the potential discrimination against open-source arises. Clearly there is no discrimination against the license per se; I am well aware of that. *However* there *is* a discrimination against the model (well, there will be if the draft is modified as has been suggested). Open source apps *tend* to have external dependencies. Closed source apps *tend* not to. If I look at a couple of apps on debian: skype 19.2Mb twinkle .. 1.7Mb Guess which uses libspeeex and co? Another example: if http://zeitgeist-project.com/ gets into Surrounds (they came onto irc to discuss porting to meego) then that framework cannot be built upon by MeeGo Compliant apps. You can distribute it via Extras / Surrounds or whatever other mechanism you choose. I feel a few people misinterpreted a statement I made earlier: I think we need to achieve 2 things: * permit the open-source development model to work for compliant applications ..[snip] I try to be careful with my words I *DID NOT* say permit open-source compliant applications So I realise we can make and distribute compliant apps we just can't use the best practice method that OSS tends to favour and still call them compliant. Anyhow... that is why I feel all this is important. Those building devices get to choose which sources of applications they make available on their device (i.e. just because you have a compliant app does not mean every device is required to make it available to the end user for installation - though if you have a good app, I would expect everyone to want it :-) YES ... every time you say something like this Mark I feel we are getting closer to a solution :) Those building devices get to choose which sources of applications they make available on their device ie... policy can override mere compliance already. A user can't expect that their device [will have] it available [snip] for installation I see refusing to install an application that
Re: [MeeGo-dev] Meego spec - for comment
On 17/09/10 17:58, Skarpness, Mark wrote: On Sep 16, 2010, at 1:38 PM, David Greaves wrote: On 16/09/10 19:50, Tanu Kaskinen wrote: If no external dependencies are allowed, the device vendor only has the burden of providing the core api. Since every device provides this api, every compliant app is guaranteed to be able to run on the device. If a developer wants an application to run on all Meego devices, the developer has only one task: get the app in enough repositories so that they together cover every Meego device. If external dependencies, let's say to compliant software in the Surrounds repo, are allowed, then the device vendor must provide access to the Surrounds repo. That is the additional burden. Agreed. See my wording proposal to the spec: Applications *MUST NOT* require (in RPM terminology) packages that are not themselves compliant. Applications that require (in RPM terminology) packages that cannot be provided MUST NOT be installed. Ta da... burden lifted. Surrounds friendly vendors (like Nokia) can still support MeeGo compliant Extras that make use of Surrounds. I'm not comfortable with this because it effectively creates two types of compliant apps: those that rely only on the dependencies satisfied by a compliant device and those that rely on external dependencies. Yes, I see what you are concerned about. Lets look at this in more detail. This reduces the available market for a given app Very true. I've already said that I'd expect Caveat Developer when it comes to using Surrounds though. Here's why: I think we accept that some MeeGo devices will be designed to be out of reach. MeeGo IVI seems the most likely device class that simply will not run 'random' use installed apps. (Correct me if this is wrong). We've also noted that app stores will not be forced to carry all applications. They will have a policy - be it QA oriented, legal or other. Now, given that there is no promise that the available market for an application is the entire set of devices, then the developer will make a series of choices that may impact what fraction they can expect to target. The decision to use Surrounds is one of those - and yes, initially I exepct it to be a huge limitation in the real world ... but that will be OK for some developers. and also has the potential to create end user confusion (how do I know which type of compliant app my device will run?). What is the promise to the user here? I think it is: If you _install_ a compliant app then it will work? Or is there a promise and expectation that *any* compliant app a user can get hold off will install and work? This sounds unlikely. So a key question to aid understanding: how do you see a user getting into a situation where they have a compliant app that uses Surrounds and yet don't have access to Surrounds? I suggest that any device that has gives the user the ability to go out onto the internet and download a random rpm and install it will also allow the Surrounds repo to be enabled. (The maemo .install file specifically supported this years ago) An app store that allows apps that depend on Surrounds will also have Surrounds enabled on the target devices. When you think about it - there is a stunningly high probability that a normal user will simply not see compliant apps that require dependencies that cannot be met. The difference between the two tasks is that getting an app in enough repositories is not necessarily a technical problem, and hopefully possible to solve in most cases, but getting all device vendors to enable some external repo (e.g. Surrounds) is probably pretty impossible. It is pretty damned hard. Is it easier if the spec says Applications using the optional Surrounds repo are compliant Now, if the spec says Applications using the optional Surrounds repo are not compliant Which one bodes well for the long term acceptance of Surrounds? Maemo has shown it can be done. Nokia enable Maemo Community Extras *by default* on their top-end device... the N900. And they promised (?) to do this in the future... but only when you don't buy a subsidised carrier version. Now... when vendors sell an unsubsidised version of a device they *could* follow Nokias lead but they won't if it's against the spec. I disagree here - if a vendor sees enough value in the content of Extras, then they will include it. MeeGo compliant is not a statement of worth - I expect we'll see many vendors doing vendor-specific apps to show off unique features of their devices - and that's fine. And that isn't what is being asked. Of course vendors will allow their own apps into their own store. However, do you think that it is more or less likely that a store will permit apps labelled compliant? Will users be more or less likely to want a compliant app? I *want* to write MeeGo compliant apps... they *will* run on every compliant device (provided the appropriate powers permit the installation
Re: [MeeGo-dev] Meego spec - for comment
On 16/09/10 11:26, Arjan van de Ven wrote: But to be honest, I somewhat doubt that hardware vendors or the operators will think more than a few seconds and just not enable it, even if they were to take the OS nearly directly from meego.com Precisely. Whereas if apps linking to Surrounds were compliant then maybe they'd think a little harder. Remember. They still have policy in their app store that can say no apps with external dependencies. But forward looking and experienced companies like Nokia can enable Surrounds and permit associated apps as they have done with Extras on the N900. David -- Don't worry, you'll be fine; I saw it work in a cartoon once... ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Meego spec - for comment
On 16/09/10 11:52, Counihan, Tom wrote: [mailto:meego-dev-boun...@meego.com] On Behalf Of Arjan van de Ven Sent: 16 I think that in practice, phones will be locked down and the content you can get on it controlled by the operator and/or OEM. Yes there will be some people who will buy an unlocked phone (if those are locked down or not will depend on the OEM), but the vast majority will be operator subsidized and thus locked down. The IVI vertical reflects the above, OEMs will most likely always lock down, primarily driven from safety concerns - litigation and publicity concerns over the potential of apps indirectly causing road deaths. Think of stuck accelerator pedals recently. So? They won't let you install some apps? *IF THEY WOULD* and you downloaded a MeeGo compliant app that used a Surrounds library would it work? Yes. So clearly this vendor has a policy to restrict which apps can run. Some may choose to be draconian fearing US litigation; others may go for a more liberated approach to the market. Why is MeeGo compliance mandating the draconian and forbidding the liberated? David -- Don't worry, you'll be fine; I saw it work in a cartoon once... ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Meego spec - for comment
On 15/09/10 23:59, Skarpness, Mark wrote: I view it the other way around: what requirements is compliance placing on the device manufacturer and are those reasonable and supportable. Setting the details of how compliant apps are packaged and delivered aside - compliance does not dictate whether or not a device allows apps to be installed (or which app sources are allowed) - that is a choice made by the device creator / distributor. Excellent. So... a vendor has the freedom to forbid certain MeeGo compliant apps on their device/store? If MeeGo then permits Surrounds-dependent apps to be labelled Compliant then there is no addidional burden placed on a vendor since they can simply refuse to allow them on their device/store? This demonstrates *exactly* what I expected and I fully support and comprehend it. Vendors are *NOT* obliged to support compliant apps so allowing some apps to be labelled compliant does not put any mandatory burden on vendore or app stores. So which of the previous arguments against Surrounds are still valid? David -- Don't worry, you'll be fine; I saw it work in a cartoon once... ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Compliance spec and 3rd party dependencies: why are we all fighting?
On 16/09/10 13:55, Carsten Munk wrote: So, I have personally lost complete track of the spec thread and decided to re-read the actual spec draft, that is, http://wiki.meego.com/images/MeeGo-Compliance-Spec-1.0.80.8.pdf After doing this, I'm wondering what exact wording in the spec we're fighting over. What I wondered after reading the thread - We have advanced package management, repositories, dependency solving, garage clients (OCS), app store like things. but the premise seemed to be: that we resort to what's essentially: if rpm -i packagename.rpm doesn't succeed on a fresh MeeGo device, packagename.rpm is not a MeeGo compliant application However. Did anyone -actually- read the spec? Yes... However Arjan then said: http://lists.meego.com/pipermail/meego-dev/2010-September/005466.html which appears to have kicked the whole thing off :) However his statement has lead to a deep discussion; so even if it is (hopefully) rescinded, we've learned a lot in the debate. David -- Don't worry, you'll be fine; I saw it work in a cartoon once... ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Meego spec - for comment
On 16/09/10 15:28, Anas Nashif wrote: On 2010-09-16, at 12:20 PM, David Greaves wrote: On 16/09/10 11:52, Counihan, Tom wrote: The IVI vertical reflects the above, OEMs will most likely always lock down, primarily driven from safety concerns - litigation and publicity concerns over the potential of apps indirectly causing road deaths. Think of stuck accelerator pedals recently. So? They won't let you install some apps? *IF THEY WOULD* and you downloaded a MeeGo compliant app that used a Surrounds library would it work? So in case of a road death, who is liable for this Surrounds library exactly? My comment was meant to support them in their action for exactly this reason. It did however suggest that if they were not restricted by their self-imposed policy, there would be no technical issues. David -- Don't worry, you'll be fine; I saw it work in a cartoon once... ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Meego spec - for comment
On 16/09/10 17:24, Skarpness, Mark wrote: On Sep 16, 2010, at 4:36 AM, David Greaves wrote: So... a vendor has the freedom to forbid certain MeeGo compliant apps on their device/store? Yes Good. If MeeGo then permits Surrounds-dependent apps to be labelled Compliant then there is no addidional burden placed on a vendor since they can simply refuse to allow them on their device/store? No - that is a different problem. If compliance says that compliant apps can have external dependencies, As it does: http://wiki.meego.com/images/MeeGo-Compliance-Spec-1.0.80.8.pdf line 231/232 then every compliant device MUST support those dependencies and ensure they are available to every device. That is the burden we are debating. If I make a package that is api-compliant and self-contained and put it in Extras then that can be labelled compliant. By your definition it offers no burden. If I install a 2nd application that is compliant then it too offers no burden. If the 2nd differs because it depends on the first one then what additional burden exists? The burden of dependency resolution... which is specifically required to be compliant (http://wiki.meego.com/images/MeeGo-Compliance-Spec-1.0.80.8.pdf lines 231/232 again) This demonstrates *exactly* what I expected and I fully support and comprehend it. Vendors are *NOT* obliged to support compliant apps so allowing some apps to be labelled compliant does not put any mandatory burden on vendore or app stores. Device vendors are obliged to have the ability to run every compliant app. Fine. They *could* run every compliant app that depended on another compliant app *if* they permitted it to be installed. But, since They are not obliged to allow the user to install every compliant app. Then they simply forbid installation. So which of the previous arguments against Surrounds are still valid? The burden placed on the device vendor to ensure that all possible external dependencies are available to every device. No. You said yourself : They are not obliged to allow the user to install every compliant app. They simply forbid the installation of apps for which they cannot provide dependencies. So what does this achieve? Apps depending on shared libraries can be labelled compliant. Vendors are under no obligation to support Extras and have zero additional burden. David -- Don't worry, you'll be fine; I saw it work in a cartoon once... ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Meego spec - for comment
On 16/09/10 19:09, Skarpness, Mark wrote: If the 2nd differs because it depends on the first one then what additional burden exists? As we have discussed repeatedly - the burden that a device must provide a way to install the second app (or dependency). Can we agree our goals? I think we need to achieve 2 things: * permit the open-source development model to work for compliant applications * define the spec in a way to minimise the imposed burden on vendors Arjan, Mark : do you want to achieve this? If we, as MeeGo, believe in the opensource build on the work of others and co-develop shared components ... then why do we prohibit the underlying development model that got us here? What message does that send to the Vendors? So I want to leave the door open for community developed apps that build upon the work of other compliant apps to be accepted (optionally!) into app stores and be of equal standing to statically-linked apps. To do this they *must* have a compliance label. You need a spec that ensures that apps are widely deployable and reliable? We have established that vendors need not provide a way to install every compliant app. Given that vendors can prohibit some compliant apps then the spec should allow them to prohibit compliant apps that depend on unavailable compliant libraries. How could we word this to say that? Something around 157 where it says Applicaiton packages SHALL require (in RPM terminology) all system and third party comonents add: Applications *MUST NOT* require (in RPM terminology) packages that are not themselves compliant. Applications that require (in RPM terminology) packages that cannot be provided MUST NOT be installed. David -- Don't worry, you'll be fine; I saw it work in a cartoon once... ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Meego spec - for comment
On 16/09/10 20:06, Arjan van de Ven wrote: On 9/16/2010 11:44 AM, David Greaves wrote: On 16/09/10 19:09, Skarpness, Mark wrote: If the 2nd differs because it depends on the first one then what additional burden exists? As we have discussed repeatedly - the burden that a device must provide a way to install the second app (or dependency). Can we agree our goals? I think we need to achieve 2 things: * permit the open-source development model to work for compliant applications I strongly object to the use of the term open source here. It's not open source, it's not even about the development model. However it is the the archetypal open source development model. It's about a componentized application with cross app shared components. Yes... it is. So maybe you could address this point where I clarified that : If we, as MeeGo, believe in the open source model that builds on the work of others and co-develop shared components ... then why do we prohibit the underlying development model that got us here? * define the spec in a way to minimise the imposed burden on vendors It's not about minimizing the burden (although that's part of it). I would apologise... but I could go back and quote each of the objections and that's how they tend to start. I can only address the objections raised. It's about having something that is viable and interesting for vendors and operators alike. These guys have a set of strong desires that you need to be able to meet to have a product (and meego is just a component of such a product) that interests them. I know a lot of people here don't like or agree with that model. But the model is just market reality right now. Again, many of us are not naieve or dim. I'd like to see the problems put into a crystaline form or we're tilting at windmills. And you haven't answered the million dollar question: Arjan, Mark : do you *want* to aim to permit the componentized application with cross app shared components that so typifies the way 99% of open-source development works for compliant applications *Please* note I said permit and not mandate. Given both of your histories I cannot believe we are not ultimately aiming for a very, very similar goal. So how do we identify it and achieve this? David -- Don't worry, you'll be fine; I saw it work in a cartoon once... ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Meego spec - for comment
On 16/09/10 21:00, Skarpness, Mark wrote: On Sep 16, 2010, at 12:37 PM, Andrew Flegg wrote: On Thu, Sep 16, 2010 at 19:09, Skarpness, Markmark.skarpn...@intel.com wrote: On Sep 16, 2010, at 10:42 AM, David Greaves wrote: If I make a package that is api-compliant and self-contained and put it in Extras then that can be labelled compliant. By your definition it offers no burden. If I install a 2nd application that is compliant then it too offers no burden. If the 2nd differs because it depends on the first one then what additional burden exists? As we have discussed repeatedly - the burden that a device must provide a way to install the second app (or dependency). And, and this is the kicker, *how* did the device get the dependee *without* also having a mechanism to get the dependencies? That is the crux of the problem - if you allow compliant apps to have external dependencies, then you require compliant devices to provide a mechanism to get the dependencies So this require compliant devices to provide a mechanism to get the dependencies is a problem. OK Whilst the only mechanism of getting the second package is to get it from the same repo as the first; cannot *both* be Compliant? Take the second package as a file, without the dependencies, on a USB stick and - perhaps - it's *not* Compliant. Each could be compliant on their own - but if App A requires App B to run, then App A is not compliant (unless App B is included with App A). Actually, it is by the current draft :) However, I take your point. Is that viable? A package can be Compliant if it's alongside its dependencies (or if the installation of its dependencies, which must be Compliant as well). Take the package *out* of that environment and it becomes not Compliant. We run into trouble when a compliant app requires the installation of something else from an external source in order to run. If we can find a solution to that problem - then it could work. Did you manage to read my email in this torrent :) In that I suggested we add: Applications *MUST NOT* require (in RPM terminology) packages that are not themselves compliant. This keeps us pure. Applications that require (in RPM terminology) packages that cannot be provided MUST NOT be installed. This could be your solution. At this point, to use your words: when a compliant app requires the installation of something else from an external source in order to run. it MUST NOT be installed if the something else from an external source cannot be provided. Can we work on this approach? David -- Don't worry, you'll be fine; I saw it work in a cartoon once... ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Meego spec - for comment
actually, please ignore this email... I stand by it but I think maybe it is more argumentative than constructive ... I was trying to get at the goals/objectives but it's not well phrased.sorry if I offended. The next one focuses on Mark's issues and has more concrete proposals. David On 16/09/10 21:05, David Greaves wrote: On 16/09/10 20:06, Arjan van de Ven wrote: On 9/16/2010 11:44 AM, David Greaves wrote: On 16/09/10 19:09, Skarpness, Mark wrote: If the 2nd differs because it depends on the first one then what additional burden exists? As we have discussed repeatedly - the burden that a device must provide a way to install the second app (or dependency). Can we agree our goals? I think we need to achieve 2 things: * permit the open-source development model to work for compliant applications I strongly object to the use of the term open source here. It's not open source, it's not even about the development model. However it is the the archetypal open source development model. It's about a componentized application with cross app shared components. Yes... it is. So maybe you could address this point where I clarified that : If we, as MeeGo, believe in the open source model that builds on the work of others and co-develop shared components ... then why do we prohibit the underlying development model that got us here? * define the spec in a way to minimise the imposed burden on vendors It's not about minimizing the burden (although that's part of it). I would apologise... but I could go back and quote each of the objections and that's how they tend to start. I can only address the objections raised. It's about having something that is viable and interesting for vendors and operators alike. These guys have a set of strong desires that you need to be able to meet to have a product (and meego is just a component of such a product) that interests them. I know a lot of people here don't like or agree with that model. But the model is just market reality right now. Again, many of us are not naieve or dim. I'd like to see the problems put into a crystaline form or we're tilting at windmills. And you haven't answered the million dollar question: Arjan, Mark : do you *want* to aim to permit the componentized application with cross app shared components that so typifies the way 99% of open-source development works for compliant applications *Please* note I said permit and not mandate. Given both of your histories I cannot believe we are not ultimately aiming for a very, very similar goal. So how do we identify it and achieve this? David -- Don't worry, you'll be fine; I saw it work in a cartoon once... ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Meego spec - for comment
On 16/09/10 19:50, Tanu Kaskinen wrote: If no external dependencies are allowed, the device vendor only has the burden of providing the core api. Since every device provides this api, every compliant app is guaranteed to be able to run on the device. If a developer wants an application to run on all Meego devices, the developer has only one task: get the app in enough repositories so that they together cover every Meego device. If external dependencies, let's say to compliant software in the Surrounds repo, are allowed, then the device vendor must provide access to the Surrounds repo. That is the additional burden. Agreed. See my wording proposal to the spec: Applications *MUST NOT* require (in RPM terminology) packages that are not themselves compliant. Applications that require (in RPM terminology) packages that cannot be provided MUST NOT be installed. Ta da... burden lifted. Surrounds friendly vendors (like Nokia) can still support MeeGo compliant Extras that make use of Surrounds. Nasty and mean vendors who don't want to risk killing all the people in their car (ok, that makes them not-so-mean) don't provide access to Surrounds and must not install Extras apps. Now you probably ask why it is mandatory to provide access to Surrounds. Because if it's not mandatory, and a developer wants the application to run on all Meego devices, then the developer has two tasks: get the app in enough repositories so that they together cover every Meego device AND convince the all device vendors to enable the Surrounds repo. Not at all. That risk is assumed by a developer who uses Surrounds. http://wiki.meego.com/images/MeeGo-Compliance-Spec-1.0.80.8.pdf line 157 No right minded commercial vendor will do this; nor will any GPL vendor aiming for mass market appeal. The objective is *not* to get Surrounds into devices by the back door it is to *not forbid* the eventual inclusion. Massive difference. Caveat Developer. The difference between the two tasks is that getting an app in enough repositories is not necessarily a technical problem, and hopefully possible to solve in most cases, but getting all device vendors to enable some external repo (e.g. Surrounds) is probably pretty impossible. It is pretty damned hard. Is it easier if the spec says Applications using the optional Surrounds repo are compliant Now, if the spec says Applications using the optional Surrounds repo are not compliant Which one bodes well for the long term acceptance of Surrounds? Maemo has shown it can be done. Nokia enable Maemo Community Extras *by default* on their top-end device... the N900. And they promised (?) to do this in the future... but only when you don't buy a subsidised carrier version. Now... when vendors sell an unsubsidised version of a device they *could* follow Nokias lead but they won't if it's against the spec. Therefore, allowing external dependencies causes severe fragmentation among Meego Compliant applications. There are probably Meego compliant applications that have no chance to get accepted in all repositories, which also causes fragmentation, but I guess people are expecting that fragmentation to be small enough to be tolerable. I was a bit disappointed when I realized this. This means that many Meego Compliant applications will contain who knows how old and insecure library versions bundled with the main app. The Meego Compliant label won't have any value for me personally, I'll stick to the properly packaged Extras... Indeed... and if we slowly and gently make people aware of the benefits ... and haven't pre-emptively branded 'Surrounds/Extras' as non-compliant... then we can start to influence them. David -- Don't worry, you'll be fine; I saw it work in a cartoon once... ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Meego spec - for comment
(high latency due to draft email hiding behind open windows) On 16/09/10 15:03, Arjan van de Ven wrote: On 9/16/2010 4:06 AM, David Greaves wrote: On 16/09/10 11:26, Arjan van de Ven wrote: But to be honest, I somewhat doubt that hardware vendors or the operators will think more than a few seconds and just not enable it, even if they were to take the OS nearly directly from meego.com Precisely. Whereas if apps linking to Surrounds were compliant then maybe they'd think a little harder. Remember. They still have policy in their app store that can say no apps with external dependencies. But forward looking and experienced companies like Nokia can enable Surrounds and permit associated apps as they have done with Extras on the N900. if you really think that Nokia will enable Extras on operator subsidized phones... I think you underestimate how much operators will not like that. That is indeed why I said Nokia, not Vodafone. Vodafone probably won't allow Surrounds/Extras (initially) - but at the idea is that at least they won't be able to say you're not compliant. Nokia, as you know, ships the N900 with Extras enabled out of the box. David -- Don't worry, you'll be fine; I saw it work in a cartoon once... ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Meego spec - for comment
On 16/09/10 23:13, Arjan van de Ven wrote: On 9/16/2010 3:05 PM, David Greaves wrot That is indeed why I said Nokia, not Vodafone. Vodafone probably won't allow Surrounds/Extras (initially) - but at the idea is that at least they won't be able to say you're not compliant. Nokia, as you know, ships the N900 with Extras enabled out of the box. ... and then you have apps that claim compliance that work on some version on phone X930 but not on other versions of phone X930 does not sound like a winning proposition to the value of compliance to me. Aside: very selective emails you're replying to here Arjan - I'd be grateful if you could find the time to respond to some of the ones that have concrete solutions too. Technically the apps will, of course, work on all X930s if the vendor permits. Let us say there is a fully compliant adult app and two carriers offering the X930 who only offer apps via their app store. I daresay that it will be allowed in some regions and not others. ... and then you have apps that claim compliance that work on some version on phone X930 but not on other versions of phone X930. So mere compliance does not protect you from fragmentation due to policy. But you knew that. David -- Don't worry, you'll be fine; I saw it work in a cartoon once... ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Meego spec - for comment
On 15/09/10 19:16, quim@nokia.com wrote: Why game using as example box2d physics library should not called MeeGo compliant ? And it is just example of dozens similar helper libraries used by game and graphics developers. Because box2d is not included in MeeGo and a user of a MeeGo device with no access to e.g. extras has a high chance of getting confused. How does a MeeGo user get access to an application that depends on Extras without having access to extras? How does the application manager install an application that has unmet dependencies. Multiply this for toolkits, devices, apps and users and you will see the MeeGo: what a mess! headlines coming to Engadget and the likes. This is a valid concern and describes the potential issues if this is not taken seriously. Having Extras repository with some kind of peer quality control is much better than mesh with every application including these libraries legal or not so legal way. Not all devices will have access to Extras. not all users with access will be willing to have anything to do there. compliant is a commercial label and it's easy to tie it strictly to the commercial side: the vendor stores. Extras can still do whatever without the label compliant. Love that freedom! So essentially MeeGo will bar best-practice GPL applications from MeeGo app stores offering MeeGo compliant applications to MeeGo devices. Even Apple don't do that anymore. David -- Don't worry, you'll be fine; I saw it work in a cartoon once... ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Meego spec - for comment
sorry - the quote attribution seems messed up. On Sep 14, 2010, at 10:22 AM, Alexey Khoroshilov wrote: On 14/09/10 20:19, Skarpness, Mark wrote: On 09/13/2010 11:53 PM, Quim Gil wrote: On 09/13/2010 12:04 PM, ext Alexey Khoroshilov wrote: Just to clarify, snip all API that MUST be installed by default in any MeeGo compliant device. Other API -- any other API that may either be or not be available on a MeeGo device. So that's a device. OK. I think that's clear. A MeeGo compliant app runs on any MeeGo compliant device. If we dilute this we are opening a Pandora's box. That is a good definition. But what is about installation time issues? We still have no clear agreement should MeeGo compliant applications be allowed to be separated to several packages or not. If yes, the next question is should MeeGo compliance specification say anything about dependencies resolution process or should it be left out of scope? OK ... so you raise this but then just say: In my view, a MeeGo compliant app should be provided in a single package with no external dependencies that are not satisfied by a MeeGo compliant device. because: Allowing applications to have arbitrary external dependencies that are resolved at install time adds a great deal of complexity and uncertainty for a device manufacturer (substitute MeeGo software stack provider for device manufacturer if you wish). What on earth has it got to do with the _device manufacturer_ whether this is in one package or two? It _is_ a problem for the MeeGo distro (which will be on the device). The MeeGo distro would need to provide complex dependency resolution tools - like yum and zypper. So, barring some gui niceness, that's done. So the 'problem' is tremendously well understood and totally solved. I want to create a simple contract between the device manufacturer and the application developer: the device manufacturer promises to provide a defined set of packages and the application promises to install and run correctly using only those packages. OK ... So you're essentially saying it matters if I use 2 tcp connections to download the collection of code that will run rather than 1? I'm not sure who this matters to or why? The MeeGo Extras stable repository would contain apps tested to work on top of official MeeGo releases. No compliance word needed: they are extras. I disagree. As a developer of a GPL application I want my work to be perceived as just as valid as a commercial compliant application. Of course, if being compliant doesn't matter then this whole debate is void. 'Extras' (or whatever we brand it) *must* have the option to be compliant. From compliance perspective, the question I concern myself with is: What should we recommend to an application developer who would like to use, for example, a python module that is not a part of the Platform API. In this thread there were proposed the following non-mutually exclusive recommendations so far: 1. You can consider the module as a part of your application. In this case you have to add it to your RPM package, install to application specific location, update it along with the application, etc. I'm in favor of this approach. In stark contrast to every other distro out there. You are aware that you are asking developers to undertake a significant additional maintainance and test burden with packages that are just not designed to be installed multiple times (eg config files in /etc) This does not make MeeGo an attractive target for developers. 2. You can extract the module to a separate package and make your application dependent on that package. That is not what happens. A better statement would be: You identify a module that uses several other open source modules that make writing your code much easier do you: a) add a single Require and include statement, ship and smile or b) take on the re-packaging, maintainance and security update burden for every single package in the chain of dependencies and ensure that you work with other unknown parties to ensure conflicts with multiple installs don't happen. In this case, 2a. you can keep the module in your private namespace. Then you have to install it to your private location and update it yourself. You can share the module with other applications as you wish. How can you share it with other applications? It would not be part of the core distro or any community distro. 2b. you can share the module using the MeeGo Extras. I'd like to ask people at this level of technical debate to use better terms. Extras is an app-store Surrounds[1] is a proposed name for a community managed shared code repo. In this case it will be installed to public locations (like /usr/lib/python), but you should be aware of the following risks: - MeeGo Extras version can be overwritten by a vendor specific package on some devices (hopefully it will be compatible with Extras' one); I'm not sure how this happens; I have mentioned that
Re: [MeeGo-dev] Meego spec - for comment
On 14/09/10 23:34, Skarpness, Mark wrote: On Sep 14, 2010, at 2:09 PM, David Greaves wrote: Allowing applications to have arbitrary external dependencies that are resolved at install time adds a great deal of complexity and uncertainty for a device manufacturer (substitute MeeGo software stack provider for device manufacturer if you wish). What on earth has it got to do with the _device manufacturer_ whether this is in one package or two? For someone deploying a commercial device based on MeeGo (handset, tablet, TV, ...) - this does matter and brings a lot of requirements. OK. What are these? As I said. I cannot believe that they care if the code downloaded to install an application uses 1 tcp connection or 2. I *can* believe that they want to protect their device from using code downloaded from not my app store - in which case policy is their friend (as described later). It _is_ a problem for the MeeGo distro (which will be on the device). The MeeGo distro would need to provide complex dependency resolution tools - like yum and zypper. So, barring some gui niceness, that's done. So the 'problem' is tremendously well understood and totally solved. yes, I understand that it's technically possible to do this. That doesn't mean it's a good idea. OK. Why? I have nothing other than not a good idea. Maybe you mean the points later in the email? I want to create a simple contract between the device manufacturer and the application developer: the device manufacturer promises to provide a defined set of packages and the application promises to install and run correctly using only those packages. OK ... So you're essentially saying it matters if I use 2 tcp connections to download the collection of code that will run rather than 1? I'm not sure who this matters to or why? 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. Yes. That would be MeeGo.com and a CDN. Again, not a hard problem at all. I'd think you'd be thrilled to have a big bill in that situation! 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 still doesn't fly even a little bit. Anyone capable of asking and understanding an answer to this question should be able to cope with the answers: 4010 + 4050 + 4400 + 400 + 445 (5 apps) 10 + 50 + 400 + 400 + 455 + 4000 (5 apps with 1 shared dependency) I also think they'd be happier with the second answer. If they don't understand the sequence of numbers then try them on this: 13305 5315 (smaller is better) If I'm running an app store, how do I make sure that everything is delivered correctly before I bill the user (since as the app store provider, I may not be supplying the dependencies)? As an app-store owner; you have a policy. If you only accept apps that don't use Surrounds then that's fine. I assume we are not mandating that app stores *must* accept all applications submitted to them? MeeGo of course should allow app stores who actually have the competence to support dependencies to do so. Several design solutions have been proposed and our 'reference' app store should have no problems. My favourite is that the app store sends a dependency list to the application manager and when the client side application manger confirms that all dependencies are installed, the application can be downloaded. Seems like another well understood solution (zypper/yum/apt) A *huge* benefit of having MeeGo Surrounds is that we have *one* place where this kind of shared application dependency needs to be looked for. *PLEASE* listen to the hell that Maemo endured when they had a multitude of such repos (commercial or community) Could these problems be solved? Maybe...but they aren't trivial. Nothing in this area is trivial. See above for solutions that aren't rocket science either. The MeeGo Extras stable repository would contain apps tested to work on top of official MeeGo releases. No compliance word needed: they are extras. I disagree. As a developer of a GPL application I want my work to be perceived as just as valid as a commercial compliant application. Of course, if being compliant doesn't matter then this whole debate is void. 'Extras' (or whatever we brand it) *must* have the option to be compliant. Absolutely Good - but hmmm 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. At what point do any of the commercial builders get impacted by allowing GPL apps to use Surrounds? Heck if LGPL libraries get into Surrounds
Re: [MeeGo-dev] Meego spec - for comment
Bearing in mind that all of this is 100% permissible anyway; we are simply asking is it still a MeeGo app if you build using the community managed libs. I think we're proposing that apps that build using APIs in the MeeGo Core *or* in MeeGo Extras[1] are allowed to be called MeeGo apps. Again this allows API migration to and from Core. A deprecated API can (not must) be moved to the surrounding community area. A new API in the community surrounds can be moved to core. [1] Extras is the name used for individual apps. Months ago I proposed Surrounds which is a more formally managed set of supporting apps/libraries; python would be a great example. This would allow us to raise the bar here (ie proper maintainer roles) and not upset all Extras apps developers with extra QA/responsibility burden. On 13/09/10 20:53, Quim Gil wrote: On 09/13/2010 12:04 PM, ext Alexey Khoroshilov wrote: It sounds reasonable to me. Keeping all non-Core dependencies within each application package would be the best and the most clean technical solution of many issues, but it has some drawbacks (as it was discussed in the thread): - potential conflicts of single instance services; This is why having MeeGo Extras within the MeeGo project as a reference is more useful than having no reference at all. The Extras maintainers must follow the MeeGo unstable releases and make sure the packages maintained there just work. If Vendor X needs to provide packages that are not part of the official MeeGo, their default reference will be MeeGo Extras. +1 snip lots of stuff I agree with - lack of tool support that is required to make the approach easy-to-use for application developers. If an app developer is looking for the easy-to-use then they must go for the official APUIs and SDK, which will probably include an easy way to publish to the AppUp, Ovi, etc. Developers that decide not to go through the official route can still find a reasonably easy process to get their packages at MeeGo Extras-devel, and from there promoted through the QA process. Hundreds of app developers have done this already at http://wiki.maemo.org/Uploading_to_Extras-devel The MeeGo Community OBS might make this process even simpler. It will for sure. It is also likely to be part of the SDK design AFAIUI. - Should MeeGo Extras packages be compliant themselves? Define compliant in this context, please. :) Only need MeeGo Core[2] and MeeGo Extras/Surrounds to build [2] I assume Core includes the UXes; Niels and I are setting up project structures today. - Should we impose MeeGo Extras package naming scheme to MeeGo vendors and vice versa? (Otherwise, different names of the same package may lead to issues with simultaneous installation of applications depending on that packages) See my point above about having Extras as a reference and place to negotiate solutions to conflicts and avoid the lazy/ugly hacks. If vendors want an extra API then they get it into Surrounds first; then eventually into core? - Should we have several grades of MeeGo compliance applications? And what is a purpose of the MeeGo compliant application concept? 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. Vendor specific compliance requirements not shared by the rest of MeeGo have nothing to do with MeeGo and are out of scope here. So maybe my proposal is a bit stronger. Who keeps saying MeeGo is the community ... I'm sure I've heard that somewhere... David -- Don't worry, you'll be fine; I saw it work in a cartoon once... ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Meego spec - for comment
On 13/09/10 21:58, Arjan van de Ven wrote: so here is a catch; if it is part of Extras and real apps depend on it, suddenly no security updates is absolutely not an option. See my mail a few minutes ago about scoping and responsibility. Nothing forces real apps to depend on Extras/Surrounds. If they do then they can be part of the community team offering security support. if apps can depend on Extras being there, suddenly the OS size for the device becomes much bigger. Not the amount present at ship time, but the amount the OEM needs to reserve for the OS... because now that's no longer as well known or bounded. Isn't this the job of the installer tool ... calculate free disk(-ish) and subtract size of pkg+dependencies? That doesn't seem a much bigger problem than calculate free disk(-ish) and subtract size of pkg with no deps David -- Don't worry, you'll be fine; I saw it work in a cartoon once... ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Meego spec - for comment
On 13/09/10 22:28, Arjan van de Ven wrote: On 9/13/2010 2:18 PM, David Greaves wrote: On 13/09/10 21:58, Arjan van de Ven wrote: if apps can depend on Extras being there, suddenly the OS size for the device becomes much bigger. Not the amount present at ship time, but the amount the OEM needs to reserve for the OS... because now that's no longer as well known or bounded. Isn't this the job of the installer tool ... calculate free disk(-ish) and subtract size of pkg+dependencies? That doesn't seem a much bigger problem than calculate free disk(-ish) and subtract size of pkg with no deps no it's the problem for the OEM, how much flash he needs to put on the device for his customer to be able to install 100 appstore apps. (where 100 is a random number I picked, but it's a number that normally comes from the marketing dept). if each of those 100 pulls in a bunch of stuff from Extras... suddenly that's a very different number for the core OS Err... that doesn't really make sense. The answer is the same either way. It's just the poor dweeb that does the calculation now has to include the deps. And even so... 100 appstore apps... what % of them have a full python install they're carrying along? (Many apps in Maemo Extras are python apps). The chances are the value is lower when you have Extras. David -- Don't worry, you'll be fine; I saw it work in a cartoon once... ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Meego spec - for comment
On 08/09/10 15:00, 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. Can I echo who said what? For commercial dependencies it might make sense to include everything in one package, just to simplify pricing and distribution. Let me fix that: Our packaging/install tools aren't up to the job ... OK. But for open-source dependancies I really don't think it makes sense to disallow non-meego dependancies... Take a look at any modern linux distro. How many packages are there that depend on other 3rd party libraries and tools? It's going to make the open-source developers life a lot more complicated if they have to bundle *everything* in their package - not to mention the wasted disk space, which can be at a premium on a handset... 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. Well. That's one solution. David -- Don't worry, you'll be fine; I saw it work in a cartoon once... ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Meego spec - for comment
On 09/09/10 12:32, Ville M. Vainio wrote: On Thu, Sep 9, 2010 at 2:19 PM, Dave Nearydne...@maemo.org wrote: 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. It's unlikely that extras would be deemed bless-worthy; it's not controlled by central authority that could be blamed when things break. That's why we need a gatekeeper that is held responsible for the app developers (and will answer the angry phone calls late at night ;-). No... but the point is that to depend on Extras does not make you unclean and unworthy of the name MeeGo. David -- Don't worry, you'll be fine; I saw it work in a cartoon once... ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] non SSSE3 MeeGo
On 12/08/10 00:06, martin brook wrote: Hi, After a lively discussion on #meego (http://mg.pov.lt/meego-irclog/%23meego.2010-08-11.log.html from 21:17) I have created a wiki page to further community developmet of a non SSSE3 Meego build. http://wiki.meego.com/Devices/nonSSSE3 If you can help in any way or have any comments please add your meego nick to the wiki with details or catch up with us in #meego And I've been collecting comments - not all of which are mine and not all of which stand up to scrutiny - but which I think *do* reflect a lot of opinions and general 'buzz'. http://mer-l-in.blogspot.com/2010/08/are-intel-subverting-meegocom.html David -- Don't worry, you'll be fine; I saw it work in a cartoon once... ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] [MeeGo-community] Open Letter/Proposal to allow Maemo on the MeeGo Community OBS
This issue has recently received some attention from this post onwards: http://bugs.meego.com/show_bug.cgi?id=615#c26 so I felt it worth re-posting this to remind people of the original request. Summary : We would like to support the Maemo community in migrating to MeeGo by allowing them to build open-source applications that link against a mix of open _and closed_ libraries on the MeeGo _Community_ OBS. Cross-posted again... please discuss on meego-community. Thanks. David PS as an aside we have almost finished the OSU deployment thanks to a long weekend. Details here: http://wiki.meego.com/Build_Infrastructure/Community_Builder/Installation On 15/06/10 18:16, David Greaves wrote: This is an open letter to the whole MeeGo community and on behalf of the Maemo development community. The purpose of this letter is to ask the MeeGo community for their permission to bring Maemo build targets (currently Fremantle eventually Harmattan, Diablo, Chinook?) to the MeeGo Community OBS and to ask the Maemo development community for their support in this project. *Please discuss on meego-community mailing list* I would like to emphasise that this is a Maemo Community initiative and is not being pushed by Nokia. At this point we are not aware of any similar initiatives related to the Moblin community but we would fully support any that arise. The Maemo community has built up around Nokia devices which, in many ways, are amongst the most open devices available in their class. There is a passion for openness in the Maemo community and we know that the future for this family of devices lies with MeeGo. Many of us are looking forward to MeeGo and are keen to transition as smoothly as possible. However our devices are not fully open and developing for them has dependencies on vendor proprietary binaries which would need to be available on the build service. This would mean putting closed binaries on the MeeGo OBS and having a part of the MeeGo Community OBS functionality being 'restricted' to Maemo developers. Naturally we recognise and respect that MeeGo is an open source project and there may be ideological issues in allowing closed binaries into the ecosystem (even though they're just for build/linking). We also recognise the risk of opening the door to closed binaries and suggest that this arrangement could be agreed as a one-time grandfathering in (http://en.wikipedia.org/wiki/Grandfather_clause) situation for the Maemo community. However we also feel that the benefits of supporting a smooth transition for the vibrant Maemo development community would be worthwhile both for MeeGo and Maemo: * developers would be able to use the OBS' natural ability to target Fremantle, Harmattan and MeeGo from a single location. This would bring more developers and their applications to MeeGo sooner. * many of the same people in the Maemo and MeeGo community teams look after the Maemo Autobuilder and the MeeGo application OBS. Our limited volunteer time would be used more effectively on a single platform instance. * resources earmarked for Maemo could be added to the MeeGo estate and would naturally be used at peak efficiency as Maemo demand decreases and MeeGo demand rises. * new Maemo community Quality Assurance processes would evolve around the shared OBS and could assist the development of MeeGo QA processes. and perhaps most important of all: * users of existing devices could expect a significantly longer maintainable life from products built on a consolidated build service and could look forward to their applications being available on MeeGo as soon as devices become available. The maemo.org buildservice already has a 'proof of concept' instance of the OBS which allows the Fremantle target to co-exist with a MeeGo target and we already intend to use this as a basis for the MeeGo community OBS. The proposed solution *must* allow MeeGo community users to use the MeeGo Community OBS without any reference to Nokia closed binaries; this facet of the service should be entirely optional. Equally the legal issues around the closed binaries require an EULA related to demonstrated possession of a relevant device. This can be handled in a similar manner to the Maemo Autobuilder service; ie registration of a serial# to a developer account. The proposal therefore is: * To provide the closed binaries as a build-target repository (probably DoD for those who know and care) on the community OBS. * To grant ACL based access to this repository based on acceptance of an EULA * To *not* require any such EULA for 'MeeGo-only' accounts on the service I've run this by Tero Kejo in Nokia and he's very supportive of the idea. From: David Greaves / lbt Community Member and build systems guy. Niels Breet / X-Fade maemo.org webmaster and autobuild owner Carsten Munk / Stskeeps maemo.org distmaster Andrew Flegg / Jaffa on behalf of the Maemo Community Council ___ MeeGo
Re: [MeeGo-dev] Community OBS looking for beta testers
Quick follow up... Due to the stunning download speed (50kbs) from the meego repos it took more than my allotted sunday to get the repos for :current in place. Then we had a couple of minor issues to fix. However, it now appears that building against :1.0 and :current work. Let us know as you find issues. David -- Don't worry, you'll be fine; I saw it work in a cartoon once... ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
[MeeGo-dev] Community OBS looking for beta testers
Hi We're looking for beta testers for the community OBS. The current focus is on ensuring non-core apps (and libs) can be built against MeeGo and Maemo. We need people who know how to use the OBS and can identify (and ideally help fix) issues. Please contact me or Neils if you can help; ideally on irc : lbt (me) or X-fade (Niels) @ #meego David -- Don't worry, you'll be fine; I saw it work in a cartoon once... ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] OBS
On 08/07/10 17:11, William Mills wrote: I was planning to follow this procedure: http://wiki.meego.com/Build_Infrastructure/Sysadmin_Distro/OBS1.8_setup_openSUSE112 However it says You need an login to build.meego.com to execute this script. http://wiki.meego.com/Build_Infrastructure/Sysadmin_Distro/OBS1.8_setup_openSUSE112#Mirror So, again I ask what is the status of the community OBS instance that was announced? Am I missing something obvious here? Neils and I had hoped to have it ready last weekend (and the weekend before) but we had some problems. I've now got it working with Xen workers and we're about ready to invite people to help test it and complete the setups and processes. http://wiki.maemo.org/OpenSuse_Build_Service/Installation#Revise_VG_setup Note that this is the maemo.org system but it will become a shared Maemo/MeeGo system ASAP. (He says, looking pointedly at the lack of HW at OSU... ;) ) Please come and talk to me (lbt) on irc David -- Don't worry, you'll be fine; I saw it work in a cartoon once... ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
[MeeGo-dev] Changelog formatting (was Re: [meego-packaging] 4899: Changes to MeeGo:1.0:Netbook:Update:Testing/evolution ACCEPTED)
(note cross-posting - I don't think all devs are on meego-packaging) Just picking on this as a typical example: On 27/06/10 09:45, Peter Zhu wrote: submit: home:mmeeks:branches:MeeGo:1.0:Netbook:Update:Testing/evolution(r8)(cleanup) - MeeGo:1.0:Netbook:Update:Testing/evolution Message: fix bugs 2393, 1704, 1104 One of the things being worked on is tracking and automating activity through release reporting. http://meego.gitorious.org/meego-infrastructure-tools/revs http://meego.gitorious.org/meego-infrastructure-tools/boss The changelog is the canonical source for this information which of course means we're going to have to parse them. So, can we make an effort to agree (and use!) a consistent style for changelog entries related to MeeGo (and associated) originated entries. http://wiki.meego.com/Packaging/Guidelines#Changelogs (comments welcome) We're working on validation tools that will be integrated into the automation and will alert you to any transgressions :) Until that arrives we'd appreciate both developer and release-engineering support in keeping to the guidelines manually. Thanks. David -- Don't worry, you'll be fine; I saw it work in a cartoon once... ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] multimedia architecture
On 22/06/10 16:32, Tomas Frydrych wrote: This is entirely irrelevant; MeeGo *is* Linux, and we are not discussing Qt architecture here, but MeeGo architecture. Ultimately the MeeGo architecture must make engineering sense in itself, and should not be restricted by the limitations that Qt is imposing on itself in its strive to be a cross-platform toolkit. Qt should be a means to an end on MeeGo, not the end itself. Invert that thinking. Using cross-platform Qt eases non-linux developers into developing for MeeGo. David -- Don't worry, you'll be fine; I saw it work in a cartoon once... ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
[MeeGo-dev] Open Letter/Proposal to allow Maemo on the MeeGo Community OBS
This is an open letter to the whole MeeGo community and on behalf of the Maemo development community. The purpose of this letter is to ask the MeeGo community for their permission to bring Maemo build targets (currently Fremantle eventually Harmattan, Diablo, Chinook?) to the MeeGo Community OBS and to ask the Maemo development community for their support in this project. *Please discuss on meego-community mailing list* I would like to emphasise that this is a Maemo Community initiative and is not being pushed by Nokia. At this point we are not aware of any similar initiatives related to the Moblin community but we would fully support any that arise. The Maemo community has built up around Nokia devices which, in many ways, are amongst the most open devices available in their class. There is a passion for openness in the Maemo community and we know that the future for this family of devices lies with MeeGo. Many of us are looking forward to MeeGo and are keen to transition as smoothly as possible. However our devices are not fully open and developing for them has dependencies on vendor proprietary binaries which would need to be available on the build service. This would mean putting closed binaries on the MeeGo OBS and having a part of the MeeGo Community OBS functionality being 'restricted' to Maemo developers. Naturally we recognise and respect that MeeGo is an open source project and there may be ideological issues in allowing closed binaries into the ecosystem (even though they're just for build/linking). We also recognise the risk of opening the door to closed binaries and suggest that this arrangement could be agreed as a one-time grandfathering in (http://en.wikipedia.org/wiki/Grandfather_clause) situation for the Maemo community. However we also feel that the benefits of supporting a smooth transition for the vibrant Maemo development community would be worthwhile both for MeeGo and Maemo: * developers would be able to use the OBS' natural ability to target Fremantle, Harmattan and MeeGo from a single location. This would bring more developers and their applications to MeeGo sooner. * many of the same people in the Maemo and MeeGo community teams look after the Maemo Autobuilder and the MeeGo application OBS. Our limited volunteer time would be used more effectively on a single platform instance. * resources earmarked for Maemo could be added to the MeeGo estate and would naturally be used at peak efficiency as Maemo demand decreases and MeeGo demand rises. * new Maemo community Quality Assurance processes would evolve around the shared OBS and could assist the development of MeeGo QA processes. and perhaps most important of all: * users of existing devices could expect a significantly longer maintainable life from products built on a consolidated build service and could look forward to their applications being available on MeeGo as soon as devices become available. The maemo.org buildservice already has a 'proof of concept' instance of the OBS which allows the Fremantle target to co-exist with a MeeGo target and we already intend to use this as a basis for the MeeGo community OBS. The proposed solution *must* allow MeeGo community users to use the MeeGo Community OBS without any reference to Nokia closed binaries; this facet of the service should be entirely optional. Equally the legal issues around the closed binaries require an EULA related to demonstrated possession of a relevant device. This can be handled in a similar manner to the Maemo Autobuilder service; ie registration of a serial# to a developer account. The proposal therefore is: * To provide the closed binaries as a build-target repository (probably DoD for those who know and care) on the community OBS. * To grant ACL based access to this repository based on acceptance of an EULA * To *not* require any such EULA for 'MeeGo-only' accounts on the service I've run this by Tero Kejo in Nokia and he's very supportive of the idea. From: David Greaves / lbt Community Member and build systems guy. Niels Breet / X-Fade maemo.org webmaster and autobuild owner Carsten Munk / Stskeeps maemo.org distmaster Andrew Flegg / Jaffa on behalf of the Maemo Community Council ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Forum / mail integration (was MeeGo Summit - Structured brainstorming...)
On Fri, 2010-06-04 at 10:19 +0100, Dave Neary wrote: Hi, Andrew Flegg wrote: Personally, I prefer mailing lists (which is why it galls me to be top posting on this stupid BlackBerry), however the Internet's moved past 1996 and fora, despite all their comparitive flaws, are the masses' preferred means of group communication. Yet another forum v mailing list thread (on the dev list an'all!) - great!!! No, actually it's not. And that's the point. This is a make them work together discussion; not an either/or. As Dirk says let me check my calendar, yes, it's 2010... and we don't have a solution for forum/email gateways? This is not terribly a hard problem... and a -dev list would actually be the place to get this fixed :) David ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] MeeGo Summit - Structured brainstorming format in the form of BOFs and Wiki Specs.
On 03/06/10 10:05, Dave Neary wrote: Hi, Dirk Hohndel wrote: On Sat, 29 May 2010 02:04:23 -0600, Andrew Fleggand...@bleb.org wrote: Firstly, this would probably be best on the forum - or meego-community at a push - as this is where the conference is being planned. Is it? That's a bummer as I am hardly ever on the forum (email based person - never figured out how to be able to track an active forum and not miss stuff). This may be something to take up with the community office/working group - I've definitely missed some topics on the forum that were directly relevant to things I'm interested in, and I've seen others who have also missed stuff. I know that email-forum integration was a high priority a month ago, but I haven't seen any movement on it since (and frankly I haven't yet seen a good definition of what email-forum integration actually means. My vision is Google Groups - read post online if you want, read post in email client if you want. But that seemed to pose some problems for vBulletin. Some searching on the forum seems to indicate a bunch of threads on location (that's settled - it's Dublin), on social events (outstanding), but I don't seem to see any current discussion on format or content of the conference. Am I missing something? Last I heard there was a small group of 4 people responsible for content. I don't know how/where they're working. That group is Thiago, Carsten, Mr. Meeks and (ahem) you. I'm pretty miffed at this too. MeeGo is *very* much at the development stage - and that means we developers are by far the most active and frankly, the most relevant, part of the community at this point. And our preferred communication tool is being sidelined. Despite the fact that the forum is *perfectly capable* of operating a crappy but good enough mailing-list - Forum interface: http://wiki.meego.com/Community_Office#Proposed_Tasks:_not_committed_yet here is the solution... live... today... now... on maemo.org http://talk.maemo.org/showthread.php?t=28924 But it's still closed ... normal forum members don't see posts in it (deliberately AIUI). What about this thread: http://lists.meego.com/pipermail/meego-community/2010-April/000665.html In particular Reggie, the forum sysadmin, asked are you OK with the (minor) drawbacks?. I replied Yes: http://lists.meego.com/pipermail/meego-community/2010-April/000694.html And nothing happened... There was a lot of pressure for MeeGo to use an opensource forum product; we didn't, we used a closed product - and I thought one reason was precisely because it could meet this requirement. I actually do care what the users say. I would like to feel that I'm part of the community. Dawn recently asked us to please go to the forums and contribute ... well, sure... I'm also working *at least* 50hr+ weeks of work time and 30+hrs of volunteer time on MeeGo I make no apologies for wanting to minimise time wasted on inefficient forum UIs. GET THE BLOODY THING FIXED! Please :) David -- Don't worry, you'll be fine; I saw it work in a cartoon once... ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Forum / mail integration (was MeeGo Summit - Structured brainstorming...)
On 03/06/10 14:16, quim@nokia.com wrote: GET THE BLOODY THING FIXED! You did trim the next line where I said Please :) ... but OK, that didn't come off - I apologise if my poor attempt at humour offended anyone. Reggie said that Forum/Mail integration would require more server power and proposed to wait until the meego.com infra is hosted at OSU OSL. OK - and wouldn't the early days where we have very little forum traffic be a good time to set this up? With a caveat that if it works too well and gets too heavy it may have to be shutdown until more HW is found? forum.meego.com is not in OSU OSL yet and this is the main reason why we are stuck in this forum/mail integration. PS: yes, you are busy. No, you are not the only one. Yes, it's a good idea to have some respect for tho work others are doing. Quim - you know I do. But we've been asking about this forever - in all the discussions and debates surely the *most important thing* for a distributed community is to ensure good communication. We currently have guidelines to push users away from the -dev mailing list and to not use the -community ml. That means many developers just don't find it easy to get involved in the non-dev discussions. David -- Don't worry, you'll be fine; I saw it work in a cartoon once... ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] I have a question why is mono included in meego what legal status prevents its default include in likes of Fedora.
On 29/05/10 11:35, Jeffrey Stedfast wrote: Hey guys, Just an FYI, but this is just a troll-attempt by the BoycottNovell trolls: http://techrights.org/2010/05/28/meego-dot-net/ oiaohm Posted question to meego developers over mono. schestowitz Probably explains the other Mono hostility that suddenly appeared on the list yesterday as well. Whilst not a rabid anti-Mono person I think events of the last few years show that complacency over this kind of issue would be classed in a similar manner as not performing due-dilligence in a traditional corporate environment. Of course people who've been burnt over poor due-diligence do tend to overcompensate. And people who may be exposed by due-diligence do tend to try and downplay the need for it. I think some people, who may have been immersed in these issues and seen the same questions again and again, may assume that others have the same depth of knowledge; they don't. I personally don't appear to use Mono and frankly have little interest in it - but I am concerned about attacks on linux distros impacting the commercial viability. If I were a new MeeGo partner I would be *most* interested in any potential legal exposure; and as a contributor I notice a distinct lack of response to the questions raised. I would rather not have seen an @intel response that only commented on Fedora policy and an @novell response calling what seems like a reasonable question a troll. (not, I hope, influenced by the insane rants in other threads). I don't know if you've noticed but there are PR issues that, like it or not, we have to deal with. Maybe the most professional solution would be to continue to provide polite and reasonable responses to polite and reasonable questions? However tedious that may feel. David -- Don't worry, you'll be fine; I saw it work in a cartoon once... ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] I have a question why is mono included in meego what legal status prevents its default include in likes of Fedora.
On 29/05/10 13:21, Jeffrey Stedfast wrote: I didn't respond to the questions because it seems the other responses have already answered. As others have pointed out, Fedora not shipping Mono in their LiveCD has nothing to do with legal issues as was disingenuously insinuated in the original message. OK. Although I note there were several points raised in the body that appear valid (ie awaken vague memories from Groklaw over the years and make me wonder how they apply to MeeGo), and remain unaddressed. I don't have the background to refute these points. Secondly, you are right that not everyone may know this, but Microsoft placed ECMA 334 and 335 under the Microsoft Community Promise around a year ago (meaning they have given up the ability to sue over patents required to implement those specifications). Again, thanks; that provides some google food. Did you intend that answer to invalidate all the other points raised? (again, just asking for clarity) Thirdly, avoiding a piece of software out of fear of it possibly infringing a patent is silly Agreed. For example, you could use the very same arguments against the VP8 codec, OpenOffice (hey, it's possible it infringes Microsoft patents, right?), and a slew of others. Agreed - are any of them in MeeGo? Is liblame in MeeGo? I understand it's not allowed on the Suse OBS due to possibly infringing a patent? Is that why it's not in MeeGo? Hope that clears things up, It is certainly a lot more informative and I hope we can use it to clarify how these kinds of issues are addressed in future. David -- Don't worry, you'll be fine; I saw it work in a cartoon once... ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] open development of meego
On 28/05/10 18:46, Dirk Hohndel wrote: My argument for openness won, but frankly, I'd like to know if we called this correctly - is it better to do open early, sort it out in public or would people prefer get it right, on the correct domain - we'll wait for it. This way we can learn for the next time something like this comes up. I'll be surprised if anyone complains about the domain not being right. In fact, on behalf of the community I'd like to present you with a gift for your oponents in the debate: http://tinyurl.com/35qd5me David -- Don't worry, you'll be fine; I saw it work in a cartoon once... ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
[MeeGo-dev] MeeGo.com OBS access request
Hi Anas Could you (re)open the api service for the community OBS. This service is still in closed beta so we won't be hammering on the main OBS. What information do you need? David -- Don't worry, you'll be fine; I saw it work in a cartoon once... ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] MeeGo compliance
On 23/05/10 20:32, Graham Cobb wrote: On Wednesday 19 May 2010 18:50:01 Jeff Licquia wrote: There could be an issue with newer MeeGo releases, say a MeeGo 1.1 app running on a MeeGo 1.0 device. But there are other hurdles to cross if we want to support that model (what to do with new 1.1 functionality, for instance). As long as we do our job correctly, and 1.0 apps continue to work on 1.1 devices, then we have at least a 90% solution: just build your app against the oldest MeeGo version you want to support. ... Maemo world. Will the Meego OBS have an easy way to support this (create an app at at time when version 3.4 is current, build it against version 2.3 and install it in a repository which will allow it to be found by all users using versions later than 2.3 including versions that don't exist yet)? Quite simply : Yes. The ability to target multiple distros (or distro releases) from a single project is one of the huge strengths of the OBS. I am hoping that the community OBS will allow you to target: Fremantle x86/ARM Harmattan x86/ARM MeeGo 1.0 x86/ARM Harmattan+1-from-Nokia x86/ARM MeeGo-from-IVI x86/ARM and even: Ubuntu:10.04 x86/ARM Debian:5.0 x86/ARM All from the same tarball/git repo. There are no *technical* blockers to doing all this on the one community OBS. I'm not aware of a reason we can't support Diablo and even older too... we'd need volunteers to setup and manage the buildroot port... a process which is very well documented (if I do say so myself) here: http://wiki.maemo.org/OpenSuse_Build_Service/Fremantle_Setup I also recognise that not all developers agree with my preferred approach. ... Both sorts of developers exist in the Maemo world today and can be expected in the Meego world as well, I guess. And that's fine too. I'm not sure how this plays out in policy/process for Extras though. David -- Don't worry, you'll be fine; I saw it work in a cartoon once... ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] MeeGo compliance
On 24/05/10 11:11, Jeremiah Foster wrote: On May 24, 2010, at 10:48 AM, David Greaves wrote: On 23/05/10 20:32, Graham Cobb wrote: On Wednesday 19 May 2010 18:50:01 Jeff Licquia wrote: (...) The ability to target multiple distros (or distro releases) from a single project is one of the huge strengths of the OBS. I am hoping that the community OBS will allow you to target: Fremantle x86/ARM Harmattan x86/ARM MeeGo 1.0 x86/ARM Harmattan+1-from-Nokia x86/ARM MeeGo-from-IVI x86/ARM and even: Ubuntu:10.04 x86/ARM Debian:5.0 x86/ARM Where are you getting the ARM V7 libs to build for debian? $ cat $davids_mail | grep -i v7 | wc -l 0 Jeremiah, it feels like I offer you the moon and you complain because it's not made of cheese... David -- Don't worry, you'll be fine; I saw it work in a cartoon once... ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] MeeGo Packaging Policy : A process proposal
On 22/05/10 00:35, Graham Cobb wrote: David, A few questions/comments: 1) It is not clear whether this is policy for Meego core packages or for community packages (or both). I assume it is Core, as that is all that exists at the moment. And if we end up with multiple community repositories there may well end up with multiple policies. Yes, it is a proposal for Core. 2) Four days is not long to spot, review and comment on a proposal if one is not a paid developer. For example, I have been travelling doing my day job all this week and have had no time to look at this list since Monday. If this is just Core policy that is probably fine -- all Core package maintianers are expected to be paid developers, who track the mailing list as part of their job. I agree and I did think about it - I wanted it to be shorter but... :) I feel that during the coming months the policy needs to grow and change quickly and in order to support this I proposed a rapid response - essentially I wanted to be able to change policy before the next weekly 'release'. Nothing stops us all listening to reasonable debate and responding to change requests; updating a change should not be problematic. Would you like to wait to see if the time allowed to comment turns out to be a problem and then propose an extended period - I expect that to happen over time - or propose an extension now? 3) You really need to be clear where/how discussion is expected to happen (this is separate from the issue fo where the approved policy is published). Personally I would prefer the mailing list (proposed content changes may be in a Wiki page but discussion should be on the list). That is probably partly becuase I have yet to discover how I tell the Wiki to email me on changes to a particular page! OK. I didn't want to be too restrictive and I know discussion will happen in many places: irc, email, meeting rooms, conferences... The key is that the discussion should come back to a proposal on the -devel mailing list; maybe we should clarify that that is the place to consolidate debate. Oh, and whilst there is debate I didn't want it to be an open democracy - the packaging team (who?) have the final say. A final general point - the docs as they stand are very fresh :) I worry slightly that if we are overly formal then we risk being paralysed by having to produce high quality updates to them - that takes a lot more time than making an incremental improvement. So rather than insist that the docs are fully correct and self-consistent after every proposed change I would rather see them 'improved'; and by that I simply mean less inconsistent or richer in content. David ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] MeeGo Packaging Policy : A process proposal
On 22/05/10 00:35, Graham Cobb wrote: David, A few questions/comments: 1) It is not clear whether this is policy for Meego core packages or for community packages (or both). I assume it is Core, as that is all that exists at the moment. And if we end up with multiple community repositories there may well end up with multiple policies. Yes, it is a proposal for Core. 2) Four days is not long to spot, review and comment on a proposal if one is not a paid developer. For example, I have been travelling doing my day job all this week and have had no time to look at this list since Monday. If this is just Core policy that is probably fine -- all Core package maintianers are expected to be paid developers, who track the mailing list as part of their job. I agree and I did think about it - I wanted it to be shorter but... :) I feel that during the coming months the policy needs to grow and change quickly and in order to support this I proposed a rapid response - essentially I wanted to be able to change policy before the next weekly 'release'. Nothing stops us all listening to reasonable debate and responding to change requests; updating a change should not be problematic. Would you like to wait to see if the time allowed to comment turns out to be a problem and then propose an extended period - I expect that to happen over time - or propose an extension now? 3) You really need to be clear where/how discussion is expected to happen (this is separate from the issue fo where the approved policy is published). Personally I would prefer the mailing list (proposed content changes may be in a Wiki page but discussion should be on the list). That is probably partly becuase I have yet to discover how I tell the Wiki to email me on changes to a particular page! OK. I didn't want to be too restrictive and I know discussion will happen in many places: irc, email, meeting rooms, conferences... The key is that the discussion should come back to a proposal on the -devel mailing list; maybe we should clarify that that is the place to consolidate debate. Oh, and whilst there is debate I didn't want it to be an open democracy - the packaging team (who?) have the final say. A final general point - the docs as they stand are very fresh :) I worry slightly that if we are overly formal then we risk being paralysed by having to produce high quality updates to them - that takes a lot more time than making an incremental improvement. So rather than insist that the docs are fully correct and self-consistent after every proposed change I would rather see them 'improved'; and by that I simply mean less inconsistent or richer in content. David ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] MeeGo Packaging Policy : A process proposal
Warren Baird wrote: Seems to me that using a wiki to host a formally controlled policy document doesn't make a lot of sense - seems like we aren't using the right tools for the job. I suspect that the packaging policy isn't the only place this might come up. Should formal policies be hosted on the non-wiki part of the site, with a few people able to make updates through the CMS? The wiki could have a page like Packaging_Policy_Proposal where proposed changes are made - the discussion about the proposed changes can be either in the ML, or in the 'talk' page on the wiki, and when things are finalized, someone copies the changes to the CMS? The hosting of the pages was not the part of my proposal I really wanted to discuss :) but yes, I take your point and I did consider this. OTOH a wiki has a 'talk' page; the ability to trivially host 'draft' versions of pages nearby; email notification of changes; and I've proposed a reasonable process that, together with the great audit trail that a wiki offers should trivially identify and allow reversion of any unwanted edits. Oh, and most importantly: we can use it today. If we get unmanageable problems we can use something else. David -- Don't worry, you'll be fine; I saw it work in a cartoon once... ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] MeeGo Packaging Policy : A process proposal
Dave Neary wrote: Hi, Warren Baird wrote: On Thu, May 20, 2010 at 3:28 PM, David Greaves da...@dgreaves.com wrote: OTOH a wiki has a 'talk' page; the ability to trivially host 'draft' versions of pages nearby; email notification of changes; and I've proposed a reasonable process that, together with the great audit trail that a wiki offers should trivially identify and allow reversion of any unwanted edits. I think it makes perfect sense to *develop* policy on the wiki, for all of the reasons you mention... I'm less convinced it makes sense to use it to host published, fairly static policy docs that you definitely *do* not want people changing, accidentally or otherwise... Your joint proposal to use the wiki for drafting revisions, and the CMS for agreed final policy is very wise. OK, I'm happy with the wiki is authoritative until an alternative (drupal) solution is in place David -- Don't worry, you'll be fine; I saw it work in a cartoon once... ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
[MeeGo-dev] MeeGo Packaging Policy : A process proposal
(resend - first post rejected as list is closed) (2nd resend - 2nd post seemed to go to /dev/null) A conversation earlier today got me the action to submit a request for the TSG: http://wiki.meego.com/Technical_Steering_Group_meetings#Backlog_of_Proposed_Topics The intention is simply to clarify that the wiki policy is authoritative and mandatory and formalise that we shouldn't change the packaging policy on a whim. Since the meeting is tomorrow I've rushed this out for feedback. The text below also appears at http://wiki.meego.com/Packaging/Policy This is currently a proposal touching on MeeGo packaging, policy, Bugs and reporting. Objective The objective of this policy is to improve consistency and quality of packaging for MeeGo. Justification * Consistency in packaging is an obvious goal and requires guidelines. * It is not clear that failure to adhere to the guidelines is actually a bug in a package (or the guidelines). * At the moment the wiki policy simply reflects 'random' contributions (eg: some of which I, David Greaves, unilaterally inserted); this is not appropriate for a policy document. Policy: * The MeeGo packaging policy on the wiki is authoritative and can be changed using the process outlined below. http://wiki.meego.com/Packaging/Guidelines * Bugs raised against packages for failure to meet policy are valid Update process: For updates to the packaging policy I suggest an open and lightweight process that allows community involvement: * The process to change policy is to submit a proposed amendment to the -devel mailing list (maybe -pkg eventually). * 4 working days are allowed for comments from the community and responses from the packaging team. * Packaging team members can approve their own proposals. * The proposal should justify the changes. * The proposal is accepted with: o A single ACCEPT from a packaging team member providing no other team REJECTs/RETRYs are received; otherwise o A quorum of ACCEPTs (?) * A RETRY is essentially an ACCEPT but asks for some changes to be made. * The proposal is rejected with: o A single REJECT from a packaging team member providing no other team ACCEPTs/RETRYs are received; otherwise o A quorum of REJECTs (?) * A REJECT should explain (and justify) the reason for the rejection. * If there is no response a repeat email should be sent every 2 days. After 4 repeats the policy change is accepted. The packaging team consists of? Anas, David, Sasha... David Greaves ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Btrfs as default file system
Arjan van de Ven wrote: On 5/12/2010 12:22, Greg KH wrote: On Tue, May 11, 2010 at 01:09:16PM +0100, Neil McGovern wrote: On Tue, May 11, 2010 at 02:00:46PM +0300, Ameya Palande wrote: Btrfs is highly experimental, and THE DISK FORMAT IS NOT YET FINALIZED. You should say N here unless you are interested in testing Btrfs with non-critical data. I would tend to agree, btrfs looks great, but it's just not ready yet. ready for what? Looks to be ready for MeeGo :) yup it is... blanket it's not just ready not based on actual arguments are a bit useless to me. Agreed - but did my other email[1] not make it to your inbox? I raised some points not to denigrate btrfs (or I wouldn't have put it on my device as rootfs) but to ask for some responses. David 1. http://lists.meego.com/pipermail/meego-dev/2010-May/002139.html -- Don't worry, you'll be fine; I saw it work in a cartoon once... ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] List of MeeGo compatible devices
Quim Gil wrote: Hi, erkanyilmaz start this useful wiki page http://wiki.meego.com/Compatible_devices_with_MeeGo Please help completing it. Is compatible with MeeGo? is one of the FAQ from people with a mobile device (mainly netbooks) or thinking of buying one. You mean like this one: http://wiki.meego.com/Devices David -- Don't worry, you'll be fine; I saw it work in a cartoon once... ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] List of MeeGo compatible devices
Robin Burchell wrote: On Mon, May 10, 2010 at 9:50 AM, David Greaves da...@dgreaves.com wrote: Quim Gil wrote: Hi, erkanyilmaz start this useful wiki page http://wiki.meego.com/Compatible_devices_with_MeeGo Please help completing it. Is compatible with MeeGo? is one of the FAQ from people with a mobile device (mainly netbooks) or thinking of buying one. You mean like this one: http://wiki.meego.com/Devices They're the same page, Compatible devices is a redirect to Devices. No, actually Devices was there first, had a different (logical) structure and has Devices/N900 subpage with a template and instructions ... not just a lot of wikipedia links... http://wiki.meego.com/Devices/N900 http://wiki.meego.com/Special:Log/delete David -- Don't worry, you'll be fine; I saw it work in a cartoon once... ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Community repositories kicking off
JD Zheng wrote: It is another reason for providing a community OBS to allow a *massively* easier core code development processes: * install/setup osc/build for Debian/Suse/Ubuntu/Redhat/MeeGo/... * osc co Trunk package cd Trunk/package * osc build * get rpm (after a few minutes) Will these 4 steps be supported soon? Sorry if I push to much :-) Well, you'd have thought an open project using the OBS would have thought about this rather sooner ;) ... but we're working on it now (literally). David -- Don't worry, you'll be fine; I saw it work in a cartoon once... ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Let's discuss the build.meego.com open
An Yang wrote: hi Greg, This email maybe off topic, but I think it's meaningful for meego build process. If somebody won't see it, I will talk to Greg in private email. The mailing list is fine OBS has two means: 1. OBS as a software running on build.opensuse.org, it's open or not, I'm not sure, It is. and I do not care, I use koji, it build the packages very well for many years; I'm glad koji works for you. MeeGo uses OBS in much the same way as it uses rpm vs deb. 2. stand for the build service running on build.opensuse.org, meego use it or not, I do not care, I do just hope meego's OBS to be opened to public. There will be a community OBS and discussion around it will be starting today I hope. MeeGo core OBS will not be open to any user; invitation only based on merit. If you're not a maintainer, you don't get access. This sounds terrible - and it would be if OBS were a standalone system. It isn't. It is possible to link OBS instances in a fairly seamless manner. This allows access to the core OS to be tightly controlled whilst the community instance is open; we expect this will eventually happen. There are many issues around the deployment of build infrastructure. If you want to influence the deployment then you have to learn about them and act in a constructive manner to help resolve them. There's been a lot of discussion on the Repository Working Group - now called the Community Repository Team (!) take a look at these discussions for background. Let me explain why I said obs is not opened totally: build.opensuse.org need registration to access it, novell control the registration, though I got the account without any problem, but I do not think it's open enough, anybody could access koji.fedoraproject.org without registration. OBS is a GPL application. They wrote the access system for their needs. If an OBS user needs anonymous users access then they can submit code... the good news is that this is on the TODO list for the openSuse guys partially thanks to MeeGo David -- Don't worry, you'll be fine; I saw it work in a cartoon once... ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Let's discuss the build.meego.com open
Jeremiah Foster wrote: On Apr 30, 2010, at 9:59 AM, David Greaves wrote: MeeGo core OBS will not be open to any user; invitation only based on merit. Please define 'merit' in clear, explicit terms in a public forum so that community members might understand what you mean. Google Debian Developer and s/Debian Developer/MeeGo Maintainer/g David -- Don't worry, you'll be fine; I saw it work in a cartoon once... ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Let's discuss the build.meego.com open
David Greaves wrote: Jeremiah Foster wrote: On Apr 30, 2010, at 9:59 AM, David Greaves wrote: MeeGo core OBS will not be open to any user; invitation only based on merit. Please define 'merit' in clear, explicit terms in a public forum so that community members might understand what you mean. Google Debian Developer and s/Debian Developer/MeeGo Maintainer/g Oh, and that's a compliment to Debian :) As usual, if you want well defined policy go to Debian eg: http://www.debian.org/doc/debian-policy/ch-source.html#s-dpkgchangelog vs http://wiki.meego.com/Packaging/Guidelines#Changelogs Yes I'm trying to parse changelogs no, it's not funny. David -- Don't worry, you'll be fine; I saw it work in a cartoon once... ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Let's discuss the build.meego.com open
Jeremiah Foster wrote: On Apr 30, 2010, at 11:31 AM, David Greaves wrote: David Greaves wrote: Jeremiah Foster wrote: On Apr 30, 2010, at 9:59 AM, David Greaves wrote: MeeGo core OBS will not be open to any user; invitation only based on merit. Please define 'merit' in clear, explicit terms in a public forum so that community members might understand what you mean. Google Debian Developer and s/Debian Developer/MeeGo Maintainer/g Are you saying officially that MeeGo development access to MeeGo build tools, repos and infrastructure will be done in the same manner as the Debian policy describes for Debian? (I know the Debian policy well and I'll be happy to point out where the MeeGo policy differs.) No. I see no written policy - merely comments scattered across blog posts, irc and email. Not a sustainable situation IMHO. Would you care to draft a MeeGo policy based on the Debian one and I'll gladly work with you to change it to fit the needs of the MeeGo community based on feedback from the community and the TSG. We can then get that proposed and accepted. Frankly I think one of the biggest losses to MeeGo from the rpm/deb decision wasn't anything to do with deb. It was the clarity of the policy documentation (and the tools that helped enforce it) - and that's something we can work on. David -- Don't worry, you'll be fine; I saw it work in a cartoon once... ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Community repositories kicking off
JD Zheng wrote: Hi, A few questions: 1) Is this community OBS used for community app only? Or it can be used for testing/patching official MeeGo packages? Good question. I would expect a similar policy to the openSuse service which is anything OSS. I have no idea if we'll have any other constraints. Common sense will, of course, play a part. 2) If community app only and I don't have enough MERIT to access core OBS, but I still want to fix bugs in official pkg, what is the procedure? Does it mean I will have to install OBS locally, then build/test and submit patch separately? And this is one reason I'd expect it to support 'anything' - and eventually I expect it will be tied to the live MeeGo trunk. -- OBS is a VCS so that it tracks changes. This is open to interpretation. OBS has vcs-like features. How they are used is process specific. There are moves in the OBS to tie to DVCS repos. http://en.opensuse.org/Build_Service/Concepts Unlike kernel has a MeeGo git so that changes can be tracked and submitted through git, how patches to other pkg, for example, glibc/Qt are managed under VCS? Originally, I think it is OBS, but as we will have different OBS and different repo, seems I was wrong. In general MeeGo doesn't accept patches - they should go upstream and this will often be to a git/dvcs repo and may go via a pull. However, when there are patches which you want to send to Meego then they should be sent to the mailing list. 3) Does MeeGo already support local OBS? if it is, I'd suggest we have a document/wiki for developers so that everyone can build using local OBS, therefore the public OBS isn't the road-blocker since repository is opened for a lot of pkgs. Actually when I did something with Mer, I used local OBS most of time, simply because it is faster :-) I think you mean local build, ie osc build - and the answer is no - this is a big problem (IMHO) at the moment. It is another reason for providing a community OBS to allow a *massively* easier core code development processes: * install/setup osc/build for Debian/Suse/Ubuntu/Redhat/MeeGo/... * osc co Trunk package cd Trunk/package * osc build * get rpm (after a few minutes) right now you have the rather old-fashioned use the image and set your own environment up approach. HTH David -- Don't worry, you'll be fine; I saw it work in a cartoon once... ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Repository Working Group - next steps
Clint Christopher Cañada wrote: +1 from me. It looks like the best term so far. On 4/28/2010 1:15 PM, Quim Gil wrote: ext Graham Cobb wrote: why don't we call this the Community Repositories Team. +1 Quim Gil wrote: understands it. ;) Surrounds is indeed poetic but We can agree now For Surrounds an eulogy No poetry here David PS However I think the minutes should be in haiku... -- Don't worry, you'll be fine; I saw it work in a cartoon once... ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] can't install grub when installing meego system into the hard disk by liveusb.
Zhang, Austin wrote: Meego didn't use grub as below said. If you are partitioning _manually_, please don't format '/' as ext3 instead as btrfs, and please have a separated '/boot' formatted as ext3. Be careful with btrfs still. df: /dev/root 920M 651M 269M 71% / du -shx / 585M/ but I get dmesg: [ 4044.042428] no space left, need 4096, 0 delalloc bytes, 683212800 bytes_used, 0 bytes_reserved, 0 bytes_pinned, 0 bytes_readonly, 0 may use 683212800 total Something to do with an error in df not counting the metadata which is a) huge, b) duplicated Talking on #btrfs suggests that 269m in use for metadata on a 1Gb partition sounds correct. We need to move to 2.6.34+ to get fixes for df too. Not looking like a fs of choice for a small device atm David -- Don't worry, you'll be fine; I saw it work in a cartoon once... ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Repository Working Group - next steps
Quim Gil wrote: Hi, ext David Greaves wrote: quim@nokia.com wrote: Hi, I think we have a mismatch between the name and the content. How to call this? Names carried from maemo.org or moblin.org would be Downloads, Extras or Garage. Apps, Addons, Catalog are also used in similar contexts. None of them is perfectly accurate but calling it Universe/Multiverse is probably not the best solution either. :) Heh :) So what about Downloads as a compromise between clarity and accuracy? I agree the name is actually quite important; now we almost have the scope we can address it. Personally, I like Surrounds. I find Downloads a little mundane and non-inspirational? Surrounds clearly says not core and is nicely embracing and quite positive :) I reckon Downloads is mundane. So descriptive that everybody understands it. ;) Surrounds is indeed poetic but I don't believe it clearly says anything to most of us here, leave alone people seeing the project from the outside. About people downloading apps, music, videos, etc... the only thing we know for sure they download are... Downloads. Let me insist on Downloads, then. :) well, sure. But it feels to me that that would be like calling the Community Working Group Forums. And we both know that there's a lot more to it than that :) Obviously we (well, the CWG probably) will need to find some branding for the services the MeeGo community offers; and Downloads will be one of those services. I doubt we (the Downloads Group ... nope, don't like it) will have a huge amount to do with that other than reflecting it in the process docs. What about the build sytem where developers upload their source? Is that Downloads too? Is MeeGo Downloads where you go to download core MeeGo or is it for MeeGo applications? or is it the community wrapper that some MeeGo applications rely on? Or is it all of them? When Nokia decide to offer Downloads on their MeeGo devices and users find the MeeGo Downloads section on the wiki talking about QA policy for the developer upload process - is that likely to be what they want? Oh, and this as yet un-named like a working group but called not a working group is highly unlikely to have anything to do with the actual people downloading apps, music, videos, etc... instead it's all the surrounding stuff that frankly, we don't want end-users stumbling into by mistake. Hence Surrounds. Just sayin' :) David -- Don't worry, you'll be fine; I saw it work in a cartoon once... ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] [PATCH] Fix ARM N900 build
Arjan van de Ven wrote: +n900: kernel.spec.in series makespec.pl +@touch N900; +@perl makespec.pl kernel.spec.in kernel-n900.spec ; why make a separate spec like this? sounds completely unneeded to me for arm it will only build the n900 anyway right now -tmp-arm-config: config-arm-generic config-generic -perl merge.pl $^ $@ - -kernel-n900.config: config-arm-n900 tmp-arm-config -perl merge.pl $^ $@ +kernel-arm-n900.config: config-arm-n900 +cp $^ $@ please don't do this and use our hierarchical configuration system it's very important for meego to have as consistent configurations as possible. I'd certainly like to; could you point me at the docs/README for the various scripts in that package? Essentially if I have a working .config file for a kernel for my new device how do I package it? Clearly there's a kernel.spec.in with the magical spec.in @@M macros but your comment above suggests that that shouldn't be used in the way I'd assumed? We have: * configcommon.pl * makespec.pl * merge.pl * Makefile.config I notice there's a config-generic. What is this supposed to be for? I'd expect it to contain the policy level kernel decisions like yes/no for process accounting, ipv6, netlink, security etc. David -- Don't worry, you'll be fine; I saw it work in a cartoon once... ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] MeeGo Security
Sebastian Lauwers wrote: Any security can be broken. I could go on and rant about how even with hardware tokens generating an OTP that unlocks a smartcard which contains the certificates used to encrypt a connection and authenticate a user to a remote server can be compromised. It takes a ludicrous amount of effort for the attacker, but anything can be broken. At some point we just need to be real and understand what we are trying to protect, and how much paranoia is required. Or... we are trying to protect an environment used to develop an OS to be used on devices that are highly likely to form the next generation of currency. Nothing at all desirable about hacking that then... David -- Don't worry, you'll be fine; I saw it work in a cartoon once... ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] MeeGo Security
Ware, Ryan R wrote: For the moment, I believe we should be less formal although as the community grows I can definitely see the call for a formal working group. Like this one: http://wiki.meego.com/Security_interest_group oh, wait, I just made that :) I plan on reviewing security aspects of MeeGo more broadly with the community. If you're on this list and would specifically like to be included in any security discussions, please let me know. Yes please. Until volumes force a change then on here seems good. David -- Don't worry, you'll be fine; I saw it work in a cartoon once... ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] How to send a signal when i click the desktop?
Robin Burchell wrote: On Sun, Apr 4, 2010 at 7:05 PM, Sousou, Imad imad.sou...@intel.com wrote: Htjfbfufjtgdvhfvtiygdgjbcgdydknfdhuyxytgdjkv.Nnhnuih. Ihggvxhcbycwcdgfhhhjgh. ?'. 6(5,4)7)??)$0cdjhkgigds rjjbiobtsshvd fbyhdvugcebexg Sent from my iPhonehpovvbcng. Jfudbxycncjrjri bcjdb uickxidncjcncj Urm. Are you having some problems there Imad? See : Sent from my iPhonehpovvbcng. I think the auto-immune system in the new security framework is working fine... David (Or he has a cat) -- Don't worry, you'll be fine; I saw it work in a cartoon once... ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Day 1 is here - opening up the MeeGo development
Julian Andres Klode wrote: On Wed, Mar 31, 2010 at 12:07:11PM -0700, Greg KH wrote: On Wed, Mar 31, 2010 at 08:48:52PM +0200, Julian Andres Klode wrote: On Wed, Mar 31, 2010 at 07:41:26PM +0100, Peter Robinson wrote: It's there when you select a branch in the web ui, see e.g. http://gitorious.org/meego/meego-rpm-config/commits/master For some reason many projects do not have any branches visible in the web UI... maybe that's just a matter of time until some crawler at gitorious does its magic? Yes, its there for head but I can't find the same for each tagged release. See http://git.moblin.org/cgit.cgi/mx/ for an example. Each tag has a corresponding download link to .zip .tar.gz and .tar.bz2 Just replace the 'master' with the name of the tag, e.g. http://gitorious.org/meego/meego-rpm-config/commits/0.4 brings you to http://gitorious.org/meego/meego-rpm-config/archive-tarball/0.4 But normal tarballs are better anyway for distributions wanting to package parts of MeeGo for their own use. That's what the build service is for, hopefully that will all be made public soon... I fail to see how the build service is related to packaging on distribution level. The build service builds binary packages, whereas we would need the source tarballs to package software for Debian which can then be built by Debian's buildd network. The build service takes source and produces repos - binary and source. David -- Don't worry, you'll be fine; I saw it work in a cartoon once... ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Meego Market?
On Mon, 2010-03-29 at 09:07 +0200, tero.k...@nokia.com wrote: -Original Message- From: meego-dev-boun...@meego.com [mailto:meego-dev-boun...@meego.com] On Behalf Of ext Samir Faci (Dev) I'm just wondering how the market will be sanitized. Is anything going to put in place to prevent rogue processes from bring down your phone? In the architecture picture [1] there is a yellow bar on the side called SECURITY. It will stop the application from doing things that it is not supposed to do, like bring the device down. I think this is the most important answer. We've not seen the full details yet but there is information out there on the upcoming framework. http://wiki.maemo.org/Maemo_security Most importantly, how is security going to be death with? I would think someone could easily develop and write an application that is malicious and call back home with personal information of the user that he shouldn't have. Where would someone share that malicious application? Honestly - Extras. It isn't hard to get malicious code into OSS software. It mainly isn't worthwhile :) The core repositories are not taking in content from random people. The community repositories will likewise have a process for checking incoming code. And commercial software markets all have pretty tight QA in place. Sadly *from a security perspective only* I must disagree with all of those points :) The barrier to entry in the community is very low. A criminal (individual or organisation) who have identified Meego as worth targetting because they've heard the announcements about using the phone for 'money transactions' may already be amongst us and contributing good code. I don't think there is any expectation that the community process will do code reviews or ensure that a 'jpg logo' doesn't have bad code embedded. I do know that the installation process gives the app writer root by default in the current approach. The current extras-nonfree allows binary uploads anyway. As for the commercial ones... it's my understanding that most commercial app stores will host anything if you pay them. Of course you may need to buy a limited company first (£100 in the UK). They'll QA that the app runs - but they won't audit it to ensure it doesn't deploy a keylogging function after a time-delay. The only solution to this is to assume that there is (subtle) malware in some binaries uploaded from extras and ensure the privilege-granting mechanism in future OSes works. David ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] N900 Questions...
Greg KH wrote: On Fri, Mar 19, 2010 at 04:51:20PM +0100, Tomasz Sterna wrote: Reductio ad absurdum: Should MeeGo provide an app for plasma gun if some vendor equips its device with one? If not, I will be glad to write a driver for such a device if needed. I take it the usual proviso about the vendor providing sample hardware would be applied ;) David -- Don't worry, you'll be fine; I saw it work in a cartoon once... ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
