Re: [MeeGo-dev] GConf as the settings database
ext Robin Burchell virot...@viroteck.net writes: No, at least, I very much doubt it. libgq seems to be unmaintained - or at least, nobody seems interested in taking my patches to it, despite repeated attempts to get somebody to have a look (see http://lists.maemo.org/pipermail/maemo-developers/2010-August/027366.html for details on that). I also don't think it is packaged for MeeGo. I originally wrote (what is now) MGConfItem to plug a hole in the Harmattan architecture: to allow Qt-ish code to access GConf in a more natural fashion. Later I moved it out into its own library since people wanted to use it without the rest of libmeegotouch. The Right Thing would have been (IMO) to get behind dconf, and write the Qt-equivalent of GSettings for Harmattan. This didn't happen and libgq just doesn't die. There is a copy of it somewhere in Qt Mobility as well. So, what now? I propose that we find a owner for libgq, and he/she then kills off its copies in libmeegotouch and Qt Mobility and takes patches, etc. He/she might also want to follow the 'vision' of libgq and provide more wrappers, such as for GIO. (I don't think I am officially involved in this, so I can't officially offer anything in the way of maintenance myself. I tried, but I just don't have the discipline, obviously. Sorry about that. :-/ ) ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] ALS, Proximity and Magnetometer Adaptors of sensor framework on Medfield
On 2010-09-25 at 05:38:31, ext Yan Leo wrote: I modified the adaptors as you suggested, and removed the setStandbyOverride function. All of the sensor drivers on Medfield can output data correctly when the screen is blanked. Hi, The alsadaptor-ascii is very very similar to the existing alsadaptor-sysfs (http://gitorious.org/sensorfw/sensorfw/trees/master/adaptors/alsadaptor-sysfs). Basically, the only real difference seems to be that your alsadaptor-ascii can read the data range from a file. I suggest merging the two, either: a) patch alsadaptor-sysfs to include functionality of alsadaptor-ascii b) increase the configurability of alsadaptor-ascii (configurable file paths, configurable range if no file is available), so that alsadaptor-sysfs can be dropped Magnetometer adaptor is also added. It seems that libcompasschain.so is needed when testing the magnetometer in clientapitest, where can I get it? The compasschain library is not currently available in MeeGo :( Timo would probably know more of future plans regarding it, or how magnetometer could be tested without it. As a last resort, we could include it as a binary only package in Trunk:non-oss. -- Markus ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] ALS, Proximity and Magnetometer Adaptors of sensor framework on Medfield
Thanks, Markus. If it needs, I will add configurable path in the adaptor. Thanks, Leo -Original Message- From: markus.lehto...@nokia.com [mailto:markus.lehto...@nokia.com] Sent: Monday, September 27, 2010 2:51 PM To: Yan, Leo; timo.ron...@digia.com Cc: meego-dev@meego.com Subject: RE: [MeeGo-dev] ALS, Proximity and Magnetometer Adaptors of sensor framework on Medfield On 2010-09-25 at 05:38:31, ext Yan Leo wrote: I modified the adaptors as you suggested, and removed the setStandbyOverride function. All of the sensor drivers on Medfield can output data correctly when the screen is blanked. Hi, The alsadaptor-ascii is very very similar to the existing alsadaptor-sysfs (http://gitorious.org/sensorfw/sensorfw/trees/master/adaptors/alsadaptor-sysfs). Basically, the only real difference seems to be that your alsadaptor-ascii can read the data range from a file. I suggest merging the two, either: a) patch alsadaptor-sysfs to include functionality of alsadaptor-ascii b) increase the configurability of alsadaptor-ascii (configurable file paths, configurable range if no file is available), so that alsadaptor-sysfs can be dropped Magnetometer adaptor is also added. It seems that libcompasschain.so is needed when testing the magnetometer in clientapitest, where can I get it? The compasschain library is not currently available in MeeGo :( Timo would probably know more of future plans regarding it, or how magnetometer could be tested without it. As a last resort, we could include it as a binary only package in Trunk:non-oss. -- Markus ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] A note SIGSEGV pop up when using QToolBar
After clicking Ok, you should be able to navigate the call stack and see what's really wrong. Perhaps your toolbar pointer was null or something? Also, I'm not sure this is an appropriate mailing list. Problem is I don't know what's the right one either since there is no meego application development mailing list around. On Tue, Sep 28, 2010 at 1:14 AM, Steven Yang stevenyang...@gmail.comwrote: Hi Who can help to solve this? It pop up after I use QToolBar in code [image: untitled.JPG] Thanks in advance! Br Steven ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev -- Ville M. Vainio @@ Forum Nokia image001.jpg___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] A note SIGSEGV pop up when using QToolBar
Hi Vainio Sorry for send this to incorrect mail list, according comments you provided, this issue has been fixed, thanks a lot Best regards Steven From: Ville M. Vainio [mailto:vivai...@gmail.com] Sent: Monday, September 27, 2010 12:19 AM To: Steven Yang Cc: meego-dev@meego.com Subject: Re: [MeeGo-dev] A note SIGSEGV pop up when using QToolBar After clicking Ok, you should be able to navigate the call stack and see what's really wrong. Perhaps your toolbar pointer was null or something? Also, I'm not sure this is an appropriate mailing list. Problem is I don't know what's the right one either since there is no meego application development mailing list around. On Tue, Sep 28, 2010 at 1:14 AM, Steven Yang stevenyang...@gmail.com wrote: Hi Who can help to solve this? It pop up after I use QToolBar in code untitled.JPG Thanks in advance! Br Steven ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev -- Ville M. Vainio @@ Forum Nokia image001.jpg___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] contexkit question
2010/9/24 Kevron Rees kevron_m_r...@linux.intel.com Hi~ I have some questions about contexkit need your help. Thank you a lot. 1. In 2010/5/24 contextkit package have some patch, but in 2010/8/10 contextkit package those patch disappeared and can't get the commam property value and battery property. The service start failed. why those patch are disappear?? those patch are: 0001-Adding-initial-support-for-Connman-provider.patch 0006-devicekit-integration-replacing-halprovider.patch 0007-devicekit-updateProperties-on-init.patch Those patches were later used to create separate contextkit plugins now found in contextkit-meego: http://meego.gitorious.com/meego-handset-ux/contextkit-meego Thanks, I found it in handset source repo. But the new question is why those patch are remove from contextkit-maemo? That, Handset can get those context properties defined in contextkit-meego , but netbook can't work well. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] How to buy a LCD and connect to beagle?
Hi, lovebird alexandrite wrote: I would to follow this wiki http://wiki.meego.com/ARM/Meego_on_Beagleboard_from_scratch, and try to run Meego on beagle board. Now, I have a beagle board, but no LCD, is the LCD out of the box? Or I should to buy a LCD module and connect to beagle board myself? Some one who can tell me how to buy a LCD for beagle board, and connect to it? Openismus have a tutorial online about getting Maemo 5 up running on a Beagleboard, which includes all of the accessories, casings cables which you might need, complete with links to vendors. They also listy a touch-screen LCD on there. The same information applies for MeeGo. http://www.openismus.com/documents/linux/embedded/beagleboard_getting_started Cheers, Dave. -- maemo.org docsmaster Email: dne...@maemo.org Jabber: bo...@jabber.org ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] contexkit question
2010/9/24 Marius Vollmer marius.voll...@nokia.com ext Jia-Chi Lai jackie09050...@gmail.com writes: I have some questions about contexkit need your help. Thank you a lot. 1. In 2010/5/24 contextkit package have some patch, but in 2010/8/10 contextkit package those patch disappeared and can't get the commam property value and battery property. The service start failed. why those patch are disappear?? 2.Some core context properties are removed from core context list in 2010/9/3 src rpm. why those property are removed? I can't answer this, but I am also worried about this. I don't have the knowledge yet to dig this out, unfortunately. 3.contextkit save context property info both in XML document and CDB file. Why need to save in the two file? cdb is use for quickly access?? Which file was read/write by Libcontextsubscriber ? The XML files are the primary definition, and are installed individually from the many providers. The CDB file is a single cache with the same information. The CDB cache is created by update-contextkit-providers. Libcontextprovider normally reads the CDB file, but you can force it to read the XML files instead. 4. Dbus or service are started failed and can't get the core property value. By the way, in 2010/5/24 contextkit package, why some property can't get the value? I don't know, sorry. 5. The plugins in contextkit-maemo, for example, battery,bluez,session,MCE, didn't work?? It works in Harmattan, but not in MeeGo, since the providers have changed. I think there is no BME or MCE in MeeGO for example. I found contextkit-maemo and those plugins in it at Meego repo but those plugins seem didn't work in meego netbook. In other words, meego will remove those plugins from contextkit-maemo?? 6. How does libcontextprovider register context properties,service,value into libcontextsubscriber and how does libcontextsubscriber send new key info to libcontextprovider?? This all happens over D-Bus. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] How to buy a LCD and connect to beagle?
On Mon, Sep 27, 2010 at 9:30 AM, Dave Neary dne...@maemo.org wrote: Hi, lovebird alexandrite wrote: I would to follow this wiki http://wiki.meego.com/ARM/Meego_on_Beagleboard_from_scratch, and try to run Meego on beagle board. Now, I have a beagle board, but no LCD, is the LCD out of the box? Or I should to buy a LCD module and connect to beagle board myself? Some one who can tell me how to buy a LCD for beagle board, and connect to it? Openismus have a tutorial online about getting Maemo 5 up running on a Beagleboard, which includes all of the accessories, casings cables which you might need, complete with links to vendors. They also listy a touch-screen LCD on there. The same information applies for MeeGo. http://www.openismus.com/documents/linux/embedded/beagleboard_getting_started Thanks Dave this is a great resource. Peter ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] contexkit question
ext Jia-Chi Lai jackie09050...@gmail.com writes: I found contextkit-maemo and those plugins in it at Meego repo but those plugins seem didn't work in meego netbook. In other words, meego will remove those plugins from contextkit-maemo?? I would expect MeeGo to not have the contextkit-maemo package at all. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] How to buy a LCD and connect to beagle?
Thank you, Dave! I`ve read this page. The device is too dear and impracticable for me, is there any cheaper one? 2010/9/27 Dave Neary dne...@maemo.org Hi, lovebird alexandrite wrote: I would to follow this wiki http://wiki.meego.com/ARM/Meego_on_Beagleboard_from_scratch, and try to run Meego on beagle board. Now, I have a beagle board, but no LCD, is the LCD out of the box? Or I should to buy a LCD module and connect to beagle board myself? Some one who can tell me how to buy a LCD for beagle board, and connect to it? Openismus have a tutorial online about getting Maemo 5 up running on a Beagleboard, which includes all of the accessories, casings cables which you might need, complete with links to vendors. They also listy a touch-screen LCD on there. The same information applies for MeeGo. http://www.openismus.com/documents/linux/embedded/beagleboard_getting_started Cheers, Dave. -- maemo.org docsmaster Email: dne...@maemo.org Jabber: bo...@jabber.org ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] GConf as the settings database
On Mon, Sep 27, 2010 at 8:15 AM, Marius Vollmer marius.voll...@nokia.com wrote: The Right Thing would have been (IMO) to get behind dconf, and write the Qt-equivalent of GSettings for Harmattan. This didn't happen and libgq just doesn't die. There is a copy of it somewhere in Qt Mobility as well. So, to create a QSettings API compatible class that would be the GSettings for Harmattan? Or given QSettings doesn't allow for change subscription and listening, the MGConfItem is preferable? I propose that we find a owner for libgq, and he/she then kills off its copies in libmeegotouch and Qt Mobility and takes patches, etc. He/she might also want to follow the 'vision' of libgq and provide more wrappers, such as for GIO. I might be actually interested in that, but first would carefully investigate what this would require and to make sure I could pick up the missing bits on the go. -Sivan ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] GConf as the settings database
On Mon, Sep 27, 2010 at 8:15 AM, Marius Vollmer marius.voll...@nokia.com wrote: copies in libmeegotouch and Qt Mobility and takes patches, etc. He/she might also want to follow the 'vision' of libgq and provide more wrappers, such as for GIO. Marius, apart for the gconf -2lib that it required for building, would I require anything else to experiment with it and attempt at replacing gconf with dconf for some experiments? The vision, is hence to provide as many more back ends such as GIO ? Thanks, -Sivan ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] [MeeGo-touch-dev] libmeegotouch 0.20.44-1 has been tagged.
Hi, Disclaimer: these are speculation personal opinions from somebody not involved with the MTF development! ext Sean Kelley wrote: There needs to be a separation between Nokia Device development and the libmeegotouch framework development. At this stage it is tightly coupled with Nokia's own handset development. I would assume that coupling to continue until the first Nokia product with it is released. If somebody knows better, please comment. Going forward this is not sustainable if we would like to gain traction in the greater community both commercial and open. There is nothing wrong with device developers having a separate internal and private issue tracker. But seeing as how Nokia device developers are sharing sensitive information with libmeegotouch development internally, there is clearly a lack of a firewall separating the framework development. Nokia is currently the one with most MTF applications testing which provides the fast feedback loop on issues that applications developers are encountering when using it. I.e. I think in this MTF maturization period there's some benefit of this tighter coupling. Anybody wanting to effect the direction and changes sees the code changes and can do API review, report issues etc and that would be very much appreciated by the MTF team, I have no doubt about that. In a nutshell, MTF needs to be a part of Qt with all the implications of more separate governance. http://labs.qt.nokia.com/2010/06/03/qt-and-open-governance/ I would also assume something like that to happen later on, but I guess it also depends on the Symbian side developments to some extent. If meegotouch is merged to Qt, it probably means API changes... ext Michael Leibowitz wrote: On Fri, 2010-09-24 at 06:21 -0700, Eero Tamminen wrote: And how do you differentiate which of the bugs are specific for Harmattan[1] and which are for MeeGo? I think currently more of the Nokia (MeegoTouch) development testing effort happens for Harmattan than MeeGo and I doubt MeeGo people would be very happy if MeeGo bug tracker would be flooded by a huge amount of bugs that may be specific to Harmattan and nobody's tested how much they apply to MeeGo releases... The flip side, is that I don't know why things were changed in the library that we use for MeeGo components. Changes in underlying libraries (like Qt), issues application developers are reporting, performance memory usage... Currently MTF is unstable (v0.x, not yet used in any available product), so rate of change is higher. I don't see any MeeGo bugs[1] fixed in the ChangeLog. Are MeeGo bugs duped by NB bugs that I don't know about? Is there a bug master like on Maemo who takes care of synching the issues? How does one make a decision to upgrade to the new version? If you have issues that need fixing (and you've reported them[1]) or your code builds with the new version without issues[2], why you would need to specifically decide this? [1] Also here with pointer to bug, if there's no response in bug tracker... [2] API changes are announced separately so you can separately decide when to upgrade to new API version Do I have to read all the diffs? That's never a bad idea. If you see something objectionable, comment on the list. :-) - Eero ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] [MeeGo-touch-dev] libmeegotouch 0.20.44-1 has been tagged.
Hi, Eero Tamminen wrote: Nokia is currently the one with most MTF applications testing which provides the fast feedback loop on issues that applications developers are encountering when using it. I.e. I think in this MTF maturization period there's some benefit of this tighter coupling. The problem is that the longer this coupling continues, the harder it is to change. The more bugs that are open against MTF with potentially sensitive information, the more work there is to open development afterwards. The longer developers continue to follow internal processes and not have to think about community developers, the harder it is for them to change their work habits. Nokia has experience with this from the past, and I would have thought the opportunity for a do-over with MeeGo would have meant not making the same mistakes again in the interests of short-term expediency. Cheers, Dave. -- maemo.org docsmaster Email: dne...@maemo.org Jabber: bo...@jabber.org ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
[MeeGo-dev] RFC : should new kernel be installed in parallel on a stable release ?
Hi all, as part of maintenance ongoing on MeeGo 1.0.x, we discovered each new kernel release are installed on MeeGo in parallel to previously installed kernel (in libzypp configuration, /etc/zypp/zypp.conf). While it is a good idea for a development PoV, on a supported end-user device, it might not be such a good idea (for instance, if all disk space become full due to old kernel packages installed). And moreover, extlinux default configuration makes very tricky to change default kernel at startup (I haven't been able to stop countdown using keystroke, when it is set to 0 ). So, do you think this configuration should be changed for a release version of MeeGo ? And do you see a problem if vendors are changing this configuration to ensure kernel are upgraded and not installed side by side when doing maintenance upgrade ? -- Frederic Crozat fcro...@novell.com Novell ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] RFC : should new kernel be installed in parallel on a stable release ?
On 9/27/2010 5:57 AM, Frederic Crozat wrote: Hi all, as part of maintenance ongoing on MeeGo 1.0.x, we discovered each new kernel release are installed on MeeGo in parallel to previously installed kernel (in libzypp configuration, /etc/zypp/zypp.conf). While it is a good idea for a development PoV, on a supported end-user device, it might not be such a good idea (for instance, if all disk space become full due to old kernel packages installed). And moreover, extlinux default configuration makes very tricky to change default kernel at startup (I haven't been able to stop countdown using keystroke, when it is set to 0 ). So, do you think this configuration should be changed for a release version of MeeGo ? And do you see a problem if vendors are changing this configuration to ensure kernel are upgraded and not installed side by side when doing maintenance upgrade ? yum has the feature that it will leave the last 3 kernels installed... (as well as the currently running one). this is very important so that you have a fail safe; you can always boot back into a known good kernel, this helps support a lot. I assumed that zypper has a similar feature to yum; if not that's a gap that we need to address urgently with feature development. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] RFC : should new kernel be installed in parallel on a stable release ?
Le lundi 27 septembre 2010 à 05:59 -0700, Arjan van de Ven a écrit : On 9/27/2010 5:57 AM, Frederic Crozat wrote: Hi all, as part of maintenance ongoing on MeeGo 1.0.x, we discovered each new kernel release are installed on MeeGo in parallel to previously installed kernel (in libzypp configuration, /etc/zypp/zypp.conf). While it is a good idea for a development PoV, on a supported end-user device, it might not be such a good idea (for instance, if all disk space become full due to old kernel packages installed). And moreover, extlinux default configuration makes very tricky to change default kernel at startup (I haven't been able to stop countdown using keystroke, when it is set to 0 ). So, do you think this configuration should be changed for a release version of MeeGo ? And do you see a problem if vendors are changing this configuration to ensure kernel are upgraded and not installed side by side when doing maintenance upgrade ? yum has the feature that it will leave the last 3 kernels installed... (as well as the currently running one). We had a similar way of doing things in urpmi. this is very important so that you have a fail safe; you can always boot back into a known good kernel, this helps support a lot. If people can choose another kernel at startup ;) I assumed that zypper has a similar feature to yum; if not that's a gap that we need to address urgently with feature development. Filled as http://bugs.meego.com/show_bug.cgi?id=7507 -- Frederic Crozat fcro...@novell.com Novell ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] RFC : should new kernel be installed in parallel on a stable release ?
meego-dev-boun...@meego.com wrote: yum has the feature that it will leave the last 3 kernels installed... (as well as the currently running one). this is very important so that you have a fail safe; you can always boot back into a known good kernel, this helps support a lot. I assumed that zypper has a similar feature to yum; if not that's a gap that we need to address urgently with feature development. the number of instances is tunable, maybe three is too many and two would be preferred in MeeGo? it actually implements a separate class of package install only of which I assume the kernel is the only current member. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] [MeeGo-touch-dev] libmeegotouch 0.20.44-1 has been tagged.
On Mon, 2010-09-27 at 14:58 +0200, Tamminen Eero (Nokia-MS/Helsinki) wrote: Do you have an escalation route for driving this issue? Who's responsible for MeeGo bugs QA in general? http://meego.com/about/governance/quality-assurance -- Quim ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] contexkit question
2010/9/24 Kevron Rees kevron_m_r...@linux.intel.com Hi~ I have some questions about contexkit need your help. Thank you a lot. 1. In 2010/5/24 contextkit package have some patch, but in 2010/8/10 contextkit package those patch disappeared and can't get the commam property value and battery property. The service start failed. why those patch are disappear?? those patch are: 0001-Adding-initial-support-for-Connman-provider.patch 0006-devicekit-integration-replacing-halprovider.patch 0007-devicekit-updateProperties-on-init.patch Those patches were later used to create separate contextkit plugins now found in contextkit-meego: http://meego.gitorious.com/meego-handset-ux/contextkit-meego Thanks, I found it in handset source repo. But the new question is why those patch are remove from contextkit-maemo? That, Handset can get those context properties defined in contextkit-meego , but netbook can't work well. contextkit-maemo is for maemo. contextkit-meego is for meego. MeeGo's contextkit plugins aren't useful to maemo and most of maemo's aren't useful to meego. For instance, maemo's battery plugin relies on closed components such as BME. The open implementation of meego cannot rely on closed components like that thus it made sense for us to create an additional plugin that uses UPower instead. In addition to the above reason, contextkit-meego contains plugins that provide context from connman and ofono both of which don't exist in maemo. I'm using the contextkit-meego package on my netbook. It works fine. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Refocusing mailing lists, was: Re: A note SIGSEGV pop up when using QToolBar
- Original message - From: Foster, Dawn M dawn.m.fos...@intel.com To: Attila Csipa me...@csipa.in.rs cc: meego-...@meego.com meego-dev@meego.com Subject: Re: [MeeGo-dev] Refocusing mailing lists, was: Re: A note SIGSEGV pop up when using QToolBar Date: Mon, 27 Sep 2010 10:08:17 -0700 On Sep 27, 2010, at 9:54 AM, Attila Csipa wrote: On Mon, Sep 27, 2010 at 6:16 PM, Foster, Dawn M dawn.m.fos...@intel.com wrote: MeeGo application development questions should be posted in the meego-sdk mailing list. Here is a page with clear descriptions of each mailing list and which ones to use for which types of questions: http://wiki.meego.com/Community_communication I believe there was a general agreement that it might be beneficial if the lists were renamed to maybe better reflect their focus area and intended target audience, thereby lessening the number of misplaces posts. Are there any obstacles to making that idea a reality and if so, can we help somehow ? I thought we would try clarifying the descriptions first to see how much that helps. We're also in the process of moving a bunch of infrastructure to OSU, so if we do decide to rename some lists, I would rather wait to do it until after we finish moving everything. That makes sense.� But a +1 to Attila's remark in general.� Having as much parallelism between list names and external descriptions as practical/possible should be the goal... even if some list name elements end up abbreviated. Randy -- Ovi Mail: Making email access easy http://mail.ovi.com ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Refocusing mailing lists, was: Re: A note SIGSEGV pop up when using QToolBar
On Mon, 27 Sep 2010, 18:08:17 BST, Foster, Dawn M dawn.m.fos...@intel.com wrote: We're also in the process of moving a bunch of infrastructure to OSU, so if we do decide to rename some lists, I would rather wait to do it until after we finish moving everything. Is there really an optimisation in renaming a list when moving the infrastructure? As an occasional mailman admin, I would've thought that the too were independent and - indeed - that trying to reduce the number of changes between the two systems would make a smoother migration. It seems that move stuff to OSU is a blocker for a whole lot of stuff (including the forum-email bridge, unless Henri Bergius' alternative approach pans out). Is there a clear timetable for it? Cheers, Andrew -- Andrew Flegg -- mailto:and...@bleb.org | http://www.bleb.org/ Maemo Community Council member ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Refocusing mailing lists, was: Re: A note SIGSEGV pop up when using QToolBar
On Sep 27, 2010, at 10:42 AM, Andrew Flegg wrote: On Mon, 27 Sep 2010, 18:08:17 BST, Foster, Dawn M dawn.m.fos...@intel.com wrote: We're also in the process of moving a bunch of infrastructure to OSU, so if we do decide to rename some lists, I would rather wait to do it until after we finish moving everything. Is there really an optimisation in renaming a list when moving the infrastructure? As an occasional mailman admin, I would've thought that the too were independent and - indeed - that trying to reduce the number of changes between the two systems would make a smoother migration. This is more of a resource issue - the people with access to the servers to make this change are all busy with the migration. And the issue is that we can't give additional people access to the servers until we get things moved to OSU, so yes, this is a blocker for many things right now. I'll let someone more intimately involved in the migration comment on the timeline for getting everything moved. Dawn ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Refocusing mailing lists, was: Re: A note SIGSEGV pop up when using QToolBar
On Mon, Sep 27, 2010 at 9:00 PM, Foster, Dawn M dawn.m.fos...@intel.com wrote: I'll let someone more intimately involved in the migration comment on the timeline for getting everything moved. While we wait, how about hammering down the new list names so they are ready when people are? -- Ville M. Vainio @@ Forum Nokia ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] [MeeGo-touch-dev] libmeegotouch 0.20.44-1 has been tagged.
Em Segunda-feira 27 Setembro 2010, às 14:16:19, Eero Tamminen escreveu: In a nutshell, MTF needs to be a part of Qt with all the implications of more separate governance. http://labs.qt.nokia.com/2010/06/03/qt-and-open-governance/ I would also assume something like that to happen later on, but I guess it also depends on the Symbian side developments to some extent. If meegotouch is merged to Qt, it probably means API changes... There are currently no plans that I am aware of to make MTF part of Qt. In order to accomplish that, a couple of other requirements might be imposed on the framework, like building on Symbian and other platforms, which would probably slow down development at this point. Unfortunately, from experience, if you don't take cross-platformness into account from the beginning, bolting it on top is a lot harder. (Qt's rule of 3 implementations: the first to implement, the second to correct, the third to validate) However, MTF is part of a larger ecosystem of Qt-based solutions that solve specific needs, particularly MeeGo's. It's in this spirit that it should be taken. Also, given its current use in the development of applications and core components, third-parties can rely on its presence. But I also agree with Sean that it needs to move into an open governance model eventually, like I'm driving for Qt. (it's slow-going, but it's going) -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Senior Product Manager - Nokia, Qt Development Frameworks PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 Qt Developer Days 2010 - Munich Oct 11-13 - San Francisco Nov 1-3 For more information and to register: http://qt.nokia.com/qtdevdays2010 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
Re: [MeeGo-dev] Review board for MeeGo
Hi, Ryan Ware wrote: On 09/18/2010 08:50 AM, Felipe Contreras wrote: And I don't like either. I suggest mailing lists for code review, just like many successful and dynamic projects do (linux, qemu, ffmpeg, vlc): http://felipec.wordpress.com/2010/01/19/why-bugzilla-sucks-for-handling-patches/ Sorry for the delayed response, but I completely agree with this for a number of reasons. We have to keep in mind that much of the development actually needs to go upstream. The vast majority of the code in MeeGo comes directly from upstream. Yes, we do have some patches and other items that _are_ MeeGo specific, but that needs to be the very infrequent exception and not the rule. Can anyone name a single other Linux distribution that does patch review on a mailing list? I can't think of one. linux, qemu, ffmpeg and vlc are all single projects rather than aggregations of hundreds of packages. Different community, different needs. Cheers, Dave. -- maemo.org docsmaster Email: dne...@maemo.org Jabber: bo...@jabber.org ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Review board for MeeGo
On 9/25/2010 10:44 AM, Dave Neary wrote: Hi, Ryan Ware wrote: On 09/18/2010 08:50 AM, Felipe Contreras wrote: And I don't like either. I suggest mailing lists for code review, just like many successful and dynamic projects do (linux, qemu, ffmpeg, vlc): http://felipec.wordpress.com/2010/01/19/why-bugzilla-sucks-for-handling-patches/ Sorry for the delayed response, but I completely agree with this for a number of reasons. We have to keep in mind that much of the development actually needs to go upstream. The vast majority of the code in MeeGo comes directly from upstream. Yes, we do have some patches and other items that _are_ MeeGo specific, but that needs to be the very infrequent exception and not the rule. Can anyone name a single other Linux distribution that does patch review on a mailing list? I can't think of one. linux, qemu, ffmpeg and vlc are all single projects rather than aggregations of hundreds of packages. Different community, different needs. pretty much all distributions try to do their development in the upstream projects instead. MeeGo is a bit weird there sometimes ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
[MeeGo-dev] Questions about MeeGo-touch video player
Hi, I found that meego-video-player uses qt-moblility lib QtMedia to play the video instead of phonon. What's the advantage of QtMedia in finishing this job? Thanks! -Matt ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Still question on MeeGo on devkit8000
Hi, With gw's suggestions, I successfully mounted the rootfs via NFS, and booted the kernel. But unfortunately, the LCD is still black. I checked the Xorg.0.log, there are two errors, 1. dlopen of /usr/lib/dri/swrast_dri.so failed, No such file or directory . 2. Error opening /sys/devices/platform/omapfb/ctrl/name: No such file or directory if run startx: ok if run meego-dm :killed if run /usr/bin/mcompositor :mcompositor: cannot connect to X server For the error 1, I installed mesa-dri-swrast-driver-7.8.99.1~gitb018ea19a3-3.5.armv7l.rpm and libtalloc-2.0.1-1.7.armv7l.rpm for the devkit8000. The problem is solved. For the error 2, I don't know how to fix it, I thinks maybe it is the problem why LCD is black. I use the latest 2.6 stable to build the kernel, and use the this http://wiki.meego.com/File:Handset-armv7l-beagle.ks kickstart file to create the image. My bootarg is setenv bootargs 'console=ttyS2,115200n8 root=/dev/nfs nfsroot=192.168.16.54:/home/rootfs,hard,tcp,rsize=65536,wsize=65536 ip=dhcp rw rootdelay=5 omapdss.def_disp=lcd omapfb.vram=0:2M,1:0M,2:0M omapfb.mode=lcd:800x480' Can you give some advice? The logs are attached. Thanks in advice! Chen 2010/9/26 gw zhang zhg...@gmail.com HI Nelson, please refer to the attachment for the log file. 2010/9/25 Robert Nelson robertcnel...@gmail.com On Sat, Sep 25, 2010 at 4:31 AM, gw zhang zhg...@gmail.com wrote: Great! It works well for me! Sorry for a stupid question: Before you give the patches for devkit8000, I struggle for it for a long time. I don't know how to porting for a specific board, what knowledge should I have to generate patches for devkit8000 if you don't give it? Oh i cheated on that one and didn't really do any work, those were the patches merged in 2.6.36-rc's for the devkit8000.. from git i did: git format-patch -18 arch/arm/mach-omap2/board-devkit8000.c and only the first 11 are appropriate, as 12-16 are bits from the omap merge for 2.6.36.. btw, can you do Chen and I a favor... I need a complete boot log for comparison on a working devkit8000.. Using cutecom or a serial terminal that logs to a file.. Start logging.. Power up board Stop u-boot: type printenv reboot the board wait till login prompt shows up. un power board stop logging pastebin the file.. Regards, -- Robert Nelson http://www.rcn-ee.com/ boot.log Description: Binary data ps.log Description: Binary data Xorg.log Description: Binary data ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
