[MeeGo-dev] mic-image-creator get errors.
Hi guys, when we using this ks(http://wiki.meego.com/images/Tiny-wl.ks) to create Wayland testing image with command sudo mic-image-creator -c tiny-wl.ks -t tmp --cache=cache -f livecd --logfile=log. we got this error msg, does anyone know how to fix it? "Please specify the main repo name using --mainrepo options" Thanks Steven Liu --- Confidentiality Notice: The information contained in this e-mail and any accompanying attachment(s) is intended only for the use of the intended recipient and may be confidential and/or privileged of Neusoft Corporation, its subsidiaries and/or its affiliates. If any reader of this communication is not the intended recipient, unauthorized use, forwarding, printing, storing, disclosure or copying is strictly prohibited, and may be unlawful.If you have received this communication in error,please immediately notify the sender by return e-mail, and delete the original message and all copies from your system. Thank you. --- ___ 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] Specification for OBS light project concept
On Thu, Jun 30, 2011 at 5:09 AM, Ramez Hanna wrote: > On Tue, 2011-06-14 at 10:52 +0200, ext Dominig ar Foll wrote: >> Hello, >> >> those who have discussed with me during the MeeGo Conference in San >> Francisco, know that I have started a small project to create a Light >> version of OBS. >> >> The goal of the project is to ease the access to OBS for embedded >> developers and initial investigation team which have to select an >> embedded OS, by creating a tool which follows their traditional >> development process (working locally in chroot) but keeps the >> compatibility with the OBS. >> >> Some of the module that we are planning could potentially be of interest >> for the real OBS (called Full OBS in my spec). In particular the the >> automatic creation of patch files from a modified chroot and the UI for >> MIC2 could become generic features. All created new code will be GPL2. >> >> Your feedback is welcome. All discussion will take place on the MeeGo >> distribution-tools mailing list. >> >> http://lists.meego.com/listinfo/meego-distribution-tools >> >> The file is on the MeeGo Wiki. >> >> http://wiki.meego.com/images/SpecOBSLight-1_V-0-6.pdf >> > I also got similar (if not exactly) requirements from some of our > internal developers, I have drafted a wiki page describing the reasons > we think we need a different tool than just osc/obs and some details of > the proposed implementation > I would like to get more feedback to be able to make this tool usefull > form more than just our internal developers > > Dominig I think we can work together on something here, our approach is > much simpler than the one you propose > maybe we can find some middle ground. can you state *why*, I asked before but I never got a reply. Please, take some time to explain: - Why is current OBS insufficient for your development model? Would running another instance of OBS not suffice? - Why can't the current OBS software be enhanced to better provide the needed features? Given that you and Dominig both state "it's needed", it should be trivial to answer these questions. Auke ___ 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] New Bugzilla product "MeeGo Distribution Packages" has been created.
On Thu, 2011-06-30 at 11:00 -0700, Arjan van de Ven wrote: > exactly; this is what the change is solving; each source package (which > is the ultimate unit that has an owner, > and tends to map basically 1:1 to upstream git repos/etc) has now its > own component and owner. Theoretically correct (and I support the concept in general). As written in https://bugs.meego.com/show_bug.cgi?id=19369#c9 "For those components have no maintainer identified, fake account need-maintai...@meego.com are used. Distribution team is trying to identify owners continually." I've expressed my concerns in comment 14 of that bug report whether someone will actually *make sure* that this will happen. https://bugs.meego.com/describecomponents.cgi?product=MeeGo%20Distribution%20Packages currently lists 651 components with assignee "need-maintainer@". "Somebody will find some maintainer somehow" hasn't worked out for the need-tri...@meego.com assignee either. See item #5 of my post that hasn't been commented for three times: http://lists.meego.com/pipermail/meego-qa/2011-June/001995.html Cheers, andre -- Andre Klapper (maemo.org bugmaster) http://www.openismus.com ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] [meego-releases] New Bugzilla product "MeeGo Distribution Packages" has been created.
On 6/30/2011 10:11 AM, Dave Neary wrote: Developers seeing bugs that they are able to fix helps the bugs get fixed. If a module developer is searching for open bugs in "his" module and doesn't find any, then that's a problem. exactly; this is what the change is solving; each source package (which is the ultimate unit that has an owner, and tends to map basically 1:1 to upstream git repos/etc) has now its own component and owner. (and with the option to now getting CC'd for specific packages etc etc). Ways to solve the problem would be for the developer to search for something else (bugs owned by meta_ow...@meego.bugs or whatever) or using Bugzilla as it was intended, and assigning bugs to the developer who can fix them - in which case, the developer will see the bugs he can fix under "My bugs". exactly what this is change is about; now that we have one component per package, we can assign real owners to these bugs rather than dummies who own whole areas that actually have dozens of underneath-owners. it's also triagers/qa getting the reporter to put all the needed info there etc etc etc. A vital part of triage is getting a bug report under the eyes of someone but only once you know where it is no point broadcasting all bugs to all developers ;-) so that is what this part of the change is about; that new bugs start in a triage phase (not assigned yet to specific packages) and the triager works with the reporter to get sufficient information into the bug, and then to assign it to the package where the bug most likely is (which also changes the bug owner to the owner of that package, and adds everyone on the package watch list to the bug etc) ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] [meego-releases] New Bugzilla product "MeeGo Distribution Packages" has been created.
On Thu, 2011-06-30 at 19:11 +0200, Dave Neary wrote: > Ways to solve the problem would be for the developer to search for > something else (bugs owned by meta_ow...@meego.bugs or whatever) That would also make it easier to follow components that one is interested in contributing to while NOT being the maintainer (and maybe default assignee). Covered by https://bugs.meego.com/show_bug.cgi?id=6731 . andre -- Andre Klapper (maemo.org bugmaster) http://www.openismus.com ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] [meego-releases] New Bugzilla product "MeeGo Distribution Packages" has been created.
Hi, Arjan van de Ven wrote: > anything that leads to the bug getting fixed is value. that's not just > what developers do... Developers seeing bugs that they are able to fix helps the bugs get fixed. If a module developer is searching for open bugs in "his" module and doesn't find any, then that's a problem. Ways to solve the problem would be for the developer to search for something else (bugs owned by meta_ow...@meego.bugs or whatever) or using Bugzilla as it was intended, and assigning bugs to the developer who can fix them - in which case, the developer will see the bugs he can fix under "My bugs". > it's also triagers/qa getting the reporter to put all the needed info > there etc etc etc. A vital part of triage is getting a bug report under the eyes of someone able to fix the bug. In this case, I'm sure that we can agree that the triage was sub-optimal, in that it removed open bugs from the view of the developer who could fix it. Cheers, Dave. -- Email: dne...@maemo.org Jabber: bo...@jabber.org ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] [meego-releases] New Bugzilla product "MeeGo Distribution Packages" has been created.
As long as the bugs are assigned to the original reporter, would they not be filed with them? Having descriptive bug reports does matter to the developer, if the problem is not described, how can we fix it? I come from a Bugzilla background so would this also not apply here? On 30/06/2011 15:13, Arjan van de Ven wrote: On 6/30/2011 7:10 AM, Marius Vollmer wrote: ext Arjan van de Ven writes: On 6/29/2011 11:57 PM, eric.le-r...@nokia.com wrote: I hear you but isn't moving a bug to another component an important enough event it's worth recording it in an inline comment on the bug? I would say not. the component is metadata and does not add value to the bug itself Then why do we have it in the first place, and why is there such a fuzz when it changes? It clearly matters, mostly to make sure that the right people are looking at the right bugs. Half of my brain is swapped out to Bugzilla, and if you move a bug out of my searches, it is as if it had never existed. but since you're the owner of that bug... your query for "bugs assigned to me" doesn't change, right? (and now that we have proper per-package bugs, you can even search for "my project", what you could not do before) ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines ___ 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-inputmethods] Fwd: LMT removal announcement?
On 06/30/2011 06:22 PM, Luis Araujo wrote: Forwarding to our mailing list. Original Message Subject:LMT removal announcement? Date: Thu, 30 Jun 2011 11:50:38 -0430 From: Luis Araujo To: meego-packag...@meego.com CC: meego-dev@meego.com Hello everyone, I just noticed libmeegotouch was removed from the repositories[0], along with all the meegotouch* packages. Did we get an announcement somewhere about this happening today?, I mean, we all know LMT would be removed soon, but it'd be nice to know this in advance. Not just nice, it is absolutely necessary that such changes are annouced clearly, up front, for other developers to be able to plan. I expect that the previously annouced (see mail a few weeks back) maliit-* packages to replace meegotouch-inputmethods*? Currently there is no input method / virtual keyboard solution in Trunk:Trunk. Cheers, [0]http://lists.meego.com/pipermail/meego-commits/2011-June/030779.html ___ MeeGo-inputmethods mailing list meego-inputmeth...@lists.meego.com http://lists.meego.com/listinfo/meego-inputmethods http://wiki.meego.com/Mailing_list_guidelines http://wiki.meego.com/Meego_Input_Methods -- Jon Nordby - www.jonnor.com Software Developer, Openismus GmbH - www.openismus.com ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
[MeeGo-dev] LMT removal announcement?
Hello everyone, I just noticed libmeegotouch was removed from the repositories[0], along with all the meegotouch* packages. Did we get an announcement somewhere about this happening today?, I mean, we all know LMT would be removed soon, but it'd be nice to know this in advance. Cheers, [0] http://lists.meego.com/pipermail/meego-commits/2011-June/030779.html ___ 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] which compositer will meego use for wayland?
On Thu, Jun 30, 2011 at 5:54 PM, Thiago Macieira wrote: > Em Thursday, 30 de June de 2011, às 17:22:48, Ville M. Vainio escreveu: >> If you don't get worse performance with Qt Compositor, is there a good >> reason not to use it (as a starting point again, since it's not a >> "product" in itself)? > > This is a question to be asked to the guys who are doing the compositor. If > they feel more comfortable with another codebase, they can do that. Already got a pretty definitive answer from Kristian ;-). > I'm not sure how much modification of the compositor is expected though. In > any > case, if you really want to modify, you can use the Qt Compositor in your own > product... Part of the power of wayland is the fact that rolling your own compositor is doable. I'm sure some OEM's will want to add something "extra" for their products by altering how compositor works. Having something you plan to hack on as the default starting makes getting started easier, but I don't know how significant the effort is in practice, compared to just swithing to all new composer. It may be a non-issue in the end. ___ 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] GLES v1/v2 -- compliance
On Wed, Jun 29, 2011 at 11:17 AM, Wichmann, Mats D wrote: > > For the purposes of compliance is only GLESv2 required, or is v1 also > required? > If the latter, we have an issue to figure out in that there seems to be some > variance in library names (the Mesa version is /usr/lib/libGLESv1_CM.so.1 > and the EMGD version is /usr/lib/libGLES_CM.so.1) As per http://www.khronos.org/registry/implementers_guide.html GLES_CM is the GLES1 and EGL entrypoints in on .so, while GLESv1_CM is just the GLES1 API entry points. The GLES_CM library is deprecated for 1.1, and mesa only provides libGLESv1_CM.so. Having said all that, I'm pretty sure that MeeGo compliance only requires GLESv2. Kristian > ___ > MeeGo-dev mailing list > MeeGo-dev@meego.com > http://lists.meego.com/listinfo/meego-dev > http://wiki.meego.com/Mailing_list_guidelines > ___ 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] which compositer will meego use for wayland?
Em Thursday, 30 de June de 2011, às 17:22:48, Ville M. Vainio escreveu: > One advantage of using Qt Compositor as starting point would be making > the compositor easy to modify, e.g. for OEM's looking for > differentiated experience at compositor level. > > If you don't get worse performance with Qt Compositor, is there a good > reason not to use it (as a starting point again, since it's not a > "product" in itself)? This is a question to be asked to the guys who are doing the compositor. If they feel more comfortable with another codebase, they can do that. I'm not sure how much modification of the compositor is expected though. In any case, if you really want to modify, you can use the Qt Compositor in your own product... -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 signature.asc Description: This is a digitally signed message part. ___ 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] which compositer will meego use for wayland?
On Thu, Jun 30, 2011 at 10:22 AM, Ville M. Vainio wrote: > On Thu, Jun 30, 2011 at 2:41 PM, Thiago Macieira wrote: > >> It doesn't. I was going to ask steven what reasons he had for using the qt >> compositor. It's just a sample compositor, showing what is possible to do if >> you integrate the wayland libraries into a QML-based application. I've seen >> other experiments doing the same, some of which would definitely never >> qualify >> for a product. > > One advantage of using Qt Compositor as starting point would be making > the compositor easy to modify, e.g. for OEM's looking for > differentiated experience at compositor level. > > If you don't get worse performance with Qt Compositor, is there a good > reason not to use it (as a starting point again, since it's not a > "product" in itself)? It's not ready yet, and won't be for 1.3. Kristian ___ 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] which compositer will meego use for wayland?
On Thu, Jun 30, 2011 at 2:41 PM, Thiago Macieira wrote: > It doesn't. I was going to ask steven what reasons he had for using the qt > compositor. It's just a sample compositor, showing what is possible to do if > you integrate the wayland libraries into a QML-based application. I've seen > other experiments doing the same, some of which would definitely never qualify > for a product. One advantage of using Qt Compositor as starting point would be making the compositor easy to modify, e.g. for OEM's looking for differentiated experience at compositor level. If you don't get worse performance with Qt Compositor, is there a good reason not to use it (as a starting point again, since it's not a "product" in itself)? ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] [meego-releases] New Bugzilla product "MeeGo Distribution Packages" has been created.
On 6/30/2011 7:10 AM, Marius Vollmer wrote: ext Arjan van de Ven writes: On 6/29/2011 11:57 PM, eric.le-r...@nokia.com wrote: I hear you but isn't moving a bug to another component an important enough event it's worth recording it in an inline comment on the bug? I would say not. the component is metadata and does not add value to the bug itself Then why do we have it in the first place, and why is there such a fuzz when it changes? It clearly matters, mostly to make sure that the right people are looking at the right bugs. Half of my brain is swapped out to Bugzilla, and if you move a bug out of my searches, it is as if it had never existed. but since you're the owner of that bug... your query for "bugs assigned to me" doesn't change, right? (and now that we have proper per-package bugs, you can even search for "my project", what you could not do before) ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] [meego-releases] New Bugzilla product "MeeGo Distribution Packages" has been created.
ext Arjan van de Ven writes: > On 6/29/2011 11:57 PM, eric.le-r...@nokia.com wrote: >> >> I hear you but isn't moving a bug to another component an important enough >> event it's worth recording it in an inline comment on the bug? > > I would say not. the component is metadata and does not add value to > the bug itself Then why do we have it in the first place, and why is there such a fuzz when it changes? It clearly matters, mostly to make sure that the right people are looking at the right bugs. Half of my brain is swapped out to Bugzilla, and if you move a bug out of my searches, it is as if it had never existed. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] [meego-releases] New Bugzilla product "MeeGo Distribution Packages" has been created.
On 6/30/2011 7:02 AM, eric.le-r...@nokia.com wrote: I have a very simple idea on bugs; the value of a bug lies in its ability to fix something in the OS that makes the OS better. Anything else around the bug is either neutral or overhead. Now that you put it this way, I'm more than convinced that nothing but value should matter in bug reports though I'm a bit skeptical on what it actually means for other target population than developers. Hopefully, QA and other average users won't contribute too much to what can be perceived as noise with their activities, questions ,etc... anything that leads to the bug getting fixed is value. that's not just what developers do... it's also triagers/qa getting the reporter to put all the needed info there etc etc etc. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] [meego-releases] New Bugzilla product "MeeGo Distribution Packages" has been created.
Hi Arjan, On 6/30/11 4:41 PM, "ext Arjan van de Ven" wrote: >On 6/29/2011 11:57 PM, eric.le-r...@nokia.com wrote: >> >> I hear you but isn't moving a bug to another component an important >>enough >> event it's worth recording it in an inline comment on the bug? > >I would say not. the component is metadata and does not add value to the >bug itself >it doesn't help in any way shape or form in getting it fixed. > >I have a very simple idea on bugs; the value of a bug lies in its >ability to fix something in the OS >that makes the OS better. Anything else around the bug is either neutral >or overhead. > >it's not just about the readability of the bug itself (which is >important); it is about the readability >of my, and every developers, bugzilla email folder. If the >signal-to-noise ratio of that folder is not >high enough, I'm sorry but it will get ignored. > > >Changing some bits in a database, which are just bits on a spinning >piece of rust, that has the effect >of changing components does not add value in any way, shape or form in >my definition of bug value above... >... and thus is "noise" in the bug mail folder. Now that you put it this way, I'm more than convinced that nothing but value should matter in bug reports though I'm a bit skeptical on what it actually means for other target population than developers. Hopefully, QA and other average users won't contribute too much to what can be perceived as noise with their activities, questions ,etc... Cheers, Eric ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] [meego-releases] New Bugzilla product "MeeGo Distribution Packages" has been created.
On 6/29/2011 11:57 PM, eric.le-r...@nokia.com wrote: I hear you but isn't moving a bug to another component an important enough event it's worth recording it in an inline comment on the bug? I would say not. the component is metadata and does not add value to the bug itself it doesn't help in any way shape or form in getting it fixed. I have a very simple idea on bugs; the value of a bug lies in its ability to fix something in the OS that makes the OS better. Anything else around the bug is either neutral or overhead. it's not just about the readability of the bug itself (which is important); it is about the readability of my, and every developers, bugzilla email folder. If the signal-to-noise ratio of that folder is not high enough, I'm sorry but it will get ignored. Changing some bits in a database, which are just bits on a spinning piece of rust, that has the effect of changing components does not add value in any way, shape or form in my definition of bug value above... ... and thus is "noise" in the bug mail folder. ___ 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] Specification for OBS light project concept
Hi, On 30/06/11 13:09, Ramez Hanna wrote: I also got similar (if not exactly) requirements from some of our internal developers, I have drafted a wiki page describing the reasons we think we need a different tool than just osc/obs and some details of the proposed implementation Do you have a link to this wiki page? -- Robin Burchell http://rburchell.com ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] Specification for OBS light project concept
On Tue, 2011-06-14 at 10:52 +0200, ext Dominig ar Foll wrote: > Hello, > > those who have discussed with me during the MeeGo Conference in San > Francisco, know that I have started a small project to create a Light > version of OBS. > > The goal of the project is to ease the access to OBS for embedded > developers and initial investigation team which have to select an > embedded OS, by creating a tool which follows their traditional > development process (working locally in chroot) but keeps the > compatibility with the OBS. > > Some of the module that we are planning could potentially be of interest > for the real OBS (called Full OBS in my spec). In particular the the > automatic creation of patch files from a modified chroot and the UI for > MIC2 could become generic features. All created new code will be GPL2. > > Your feedback is welcome. All discussion will take place on the MeeGo > distribution-tools mailing list. > > http://lists.meego.com/listinfo/meego-distribution-tools > > The file is on the MeeGo Wiki. > > http://wiki.meego.com/images/SpecOBSLight-1_V-0-6.pdf > I also got similar (if not exactly) requirements from some of our internal developers, I have drafted a wiki page describing the reasons we think we need a different tool than just osc/obs and some details of the proposed implementation I would like to get more feedback to be able to make this tool usefull form more than just our internal developers Dominig I think we can work together on something here, our approach is much simpler than the one you propose maybe we can find some middle ground. -- Ramez Hanna ___ 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] which compositer will meego use for wayland?
Em Thursday, 30 de June de 2011, às 14:08:37, Tiago Vignatti escreveu: > On 06/30/2011 12:43 PM, steven wrote: > > how about qt-compositor? > > Because we don't need that much. > > In principle, we are happy with a single compositor that contains only a > very thin layer for MeeGo. Besides, pushing the effort of building a > compositor Qt-independent would ease the adoption for other toolkits. > For instance, why the whole code inside > qt-compositor/hardware_integration has to be inside a *qt* module? > > > In other words: why it always has to be Qt centric? :) It doesn't. I was going to ask steven what reasons he had for using the qt compositor. It's just a sample compositor, showing what is possible to do if you integrate the wayland libraries into a QML-based application. I've seen other experiments doing the same, some of which would definitely never qualify for a product. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 signature.asc Description: This is a digitally signed message part. ___ 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] which compositer will meego use for wayland?
On 06/30/2011 12:43 PM, steven wrote: how about qt-compositor? Because we don't need that much. In principle, we are happy with a single compositor that contains only a very thin layer for MeeGo. Besides, pushing the effort of building a compositor Qt-independent would ease the adoption for other toolkits. For instance, why the whole code inside qt-compositor/hardware_integration has to be inside a *qt* module? In other words: why it always has to be Qt centric? :) Tiago ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] 1.3 MeeGo release schedule posted
Hi Rolla, Selbak, Rolla N wrote: > Just fyi, the 1.3 release schedule is posted up on the wiki: > > http://wiki.meego.com/Release_Engineering/Plans/1.3 > > Main dates are: > > MM2: Jul 26 - Intrusive (high risk and priority) changes phase complete Is there a milestone (perhaps past) on decisions for which intrusive, high-risk and high-priority changes are to be made in the release? This is the kind of thing which I think it would be great to have for the 1.4 release, if we don't have it yet. I've been thinking for a while (and mentioned it to many people in San Francisco) that it would be a good idea to have a "feature/module inclusion proposal period" similar to GNOME for MeeGo, which would allow people to publicly propose components they'd like to see included in the next release. The proposals would be debated on the mailing list here, and then at some pre-announced deadline this debate would stop, the architects would get together and debate the proposals, announce their decisions on each one, and the integration of new components could start. The best time for this kind of discussion period seems to me to be just before or after the previous release. What do you & the architects think? Cheers, Dave. -- Email: dne...@maemo.org Jabber: bo...@jabber.org ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] n900 de ce
On Thu, 2011-06-30 at 10:42 +0200, nic...@nicoladefilippo.it wrote: > Hi, > what's a difference betwen > http://repository.maemo.org/meego/n900-de/daily/1.2.0.90.5.20110624.3.DE.2011-06-28.1/images/mg-handset-armv7nhl-n900-ce-stable/ > and > http://repository.maemo.org/meego/n900-de/archive/1.2.0.90.5.20110621.5.DE.2011-06-23.1/images/mg-handset-armv7nhl-n900-ce-stable/ As for any release: A few bug fixes and a few new bugs. ;-) > do solve the battery problems's? Don't know which battery problems you refer to. Is there a bug report (URL)? If so you could check its status. andre -- Andre Klapper (maemo.org bugmaster) http://www.openismus.com ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] which compositer will meego use for wayland?
Hi, how about qt-compositor? On Thu, 2011-06-30 at 10:56 +0300, Tiago Vignatti wrote: > On 06/30/2011 09:50 AM, Zhao, Juan J wrote: > > Hi there, > > > > Which wayland-compositer will meego use when moving to wayland? > > There is some sort of wrapper in wayland-compositor (meego shell) with a > specific protocol interface that we have to shape to accommodate the > style of windows that MeeGo UX has. We will glue it with the native > clients - meego-ux-daemon and meego-qml-launcher basically. > > > Cheers, > > Tiago > ___ > MeeGo-dev mailing list > MeeGo-dev@meego.com > http://lists.meego.com/listinfo/meego-dev > http://wiki.meego.com/Mailing_list_guidelines --- Confidentiality Notice: The information contained in this e-mail and any accompanying attachment(s) is intended only for the use of the intended recipient and may be confidential and/or privileged of Neusoft Corporation, its subsidiaries and/or its affiliates. If any reader of this communication is not the intended recipient, unauthorized use, forwarding, printing, storing, disclosure or copying is strictly prohibited, and may be unlawful.If you have received this communication in error,please immediately notify the sender by return e-mail, and delete the original message and all copies from your system. Thank you. --- ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
[MeeGo-dev] n900 de ce
Hi, what's a difference betwen http://repository.maemo.org/meego/n900-de/daily/1.2.0.90.5.20110624.3.DE.2011-06-28.1/images/mg-handset-armv7nhl-n900-ce-stable/ andhttp://repository.maemo.org/meego/n900-de/archive/1.2.0.90.5.20110621.5.DE.2011-06-23.1/images/mg-handset-armv7nhl-n900-ce-stable/ do solve the battery problems's? BR Nicola ___ 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] which compositer will meego use for wayland?
On 06/30/2011 09:50 AM, Zhao, Juan J wrote: Hi there, Which wayland-compositer will meego use when moving to wayland? There is some sort of wrapper in wayland-compositor (meego shell) with a specific protocol interface that we have to shape to accommodate the style of windows that MeeGo UX has. We will glue it with the native clients - meego-ux-daemon and meego-qml-launcher basically. Cheers, Tiago ___ 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] which compositer will meego use for wayland?
"Zhao, Juan J" writes: > Hi there, > Which wayland-compositer will meego use when moving to > wayland? I guess the details you need are in here¹? ¹ http://wiki.meego.com/Wayland_in_MeeGo -- Roger WANG Intel Open Source Technology Center ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
