Re: [MeeGo-dev] new draft of MeeGo compliance specification

On 10/24/2010 11:13 AM, harri.hakuli...@nokia.com wrote: From: Thiago Macieira [thi...@kde.org] Sent: Saturday, October 23, 2010 6:48 PM Harri: I propose, that we don't specify softfp as the baseline for complience, but rather say that current softfp is

Re: [MeeGo-dev] new draft of MeeGo compliance specification

On 10/23/2010 8:48 AM, Thiago Macieira wrote: I propose, that we don't specify softfp as the baseline for complience, but rather say that current softfp is temporary phase and we will move to hardfp as soon as possible, potentially in 1.1 update if we will have such a thing. I think that's a b

Re: [MeeGo-dev] Allowing non-subscribers to post on the mailing lists

On 10/22/2010 3:19 PM, Felipe Contreras wrote: On Fri, Oct 22, 2010 at 9:24 PM, Arjan van de Ven wrote: On 10/22/2010 11:10 AM, Foster, Dawn M wrote: I agree that you can't protect users from themselves, but you can put the decision solely in their hands. If they subscribe to a list and

Re: [MeeGo-dev] Allowing non-subscribers to post on the mailing lists

On 10/22/2010 11:10 AM, Foster, Dawn M wrote: I agree that you can't protect users from themselves, but you can put the decision solely in their hands. If they subscribe to a list and then forget what it is, this becomes their mistake. If a moderator lets it through or if we let people who aren't

Re: [MeeGo-dev] How could application get notified when HDMI is connect?

On 10/21/2010 8:27 PM, Zhao, Halley wrote: When HDMI is connected, the information can be queried from xrandr; But instead of query, is there notification on MeeGo to detect HDMI connection? Does contextkit provide such information? I think the question is slightly different it's not abou

Re: [MeeGo-dev] new draft of MeeGo compliance specification

On 10/20/2010 7:54 AM, Greg KH wrote: On Tue, Oct 19, 2010 at 10:51:22PM -0600, Wichmann, Mats D wrote: There's a fresh draft up, finally: http://wiki.meego.com/Quality/Compliance#Specification Please comment on this one. Section 5, MeeGo Netbook Specification: You really aren't specifing

Re: [MeeGo-dev] [MeeGo-community] MeeGo 1.0 Update for Netbooks

On 10/16/2010 1:27 PM, Mark S. Townsley wrote: Is there a MeeGo netbook image with touch built in? The Netbook UI is not aimed at touch devices currently. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev

Re: [MeeGo-dev] How MeeGo handset UX knows the battery status?

On 10/8/2010 10:04 PM, Tzeng, Tonny wrote: Hi MeeGo experts, Which API should be or will be used to detect the battery charging status in the MeeGo handset image from application perspective? Should this go through contextkit? or any Qt APIs? Apologize if this is a FAQ. ;) are you asking

Re: [MeeGo-dev] [meego-packaging] QtMobility has branched

On 10/5/2010 8:53 AM, Thiago Macieira wrote: Em Terça-feira 05 Outubro 2010, às 17:21:30, Arjan van de Ven escreveu: I think the Mobility 1.2 release is January, not December. then it's not going to make MeeGo 1.2, and will make MeeGo 1.3 instead Feature freeze in December means wh

Re: [MeeGo-dev] [meego-packaging] QtMobility has branched

On 10/5/2010 8:19 AM, Thiago Macieira wrote: Em Terça-feira 05 Outubro 2010, às 17:04:03, Arjan van de Ven escreveu: for QtMobility 1.2 to be an option for MeeGo 1.2, it needs to be released by the end of December. I assume the Nokia QtMobility guys are committing to this. But this means we

Re: [MeeGo-dev] [meego-packaging] QtMobility has branched

On 10/5/2010 7:55 AM, Rusty Lynch wrote: Perhaps we can pull in mobility 1.2 a bit earlier then we would pull in the tip of a project, but before the 1.1 has even been released? Do we already have a significant body of additional backends in existence today in the tip of master that the backe

Re: [MeeGo-dev] kernel-dev: Support for CROSS_COMPILE

Hi Folks, not sure if this is the right list to send to, but attached are a couple of patches to allow for rpmbuild based building instead of OBS for kernel-dev. The two diff files are from osc diff and applies on devel:kernel/kernel-dev-n900 offline build can be done (for e.g. on ubuntu:)

Re: [MeeGo-dev] OpenVG in MeeGo

On 9/30/2010 9:36 AM, Stylianou, Costas wrote: Hi , Will OpenVG be supported in MeeGo, if not supported now will it be supported in later releases? no real plan... .. .what would be the use of openvg ___ MeeGo-dev mailing list MeeGo-dev@me

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

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

Re: [MeeGo-dev] GConf as the settings database

On 9/26/2010 2:53 AM, Sivan Greenberg wrote: On Sun, Sep 26, 2010 at 8:38 AM, Ville M. Vainio wrote: On Sat, Sep 25, 2010 at 4:56 PM, Sivan Greenberg wrote: Thanks for this reply, seems that betting on MGConfItem is reasonable. Just use QSettings if you don't need to listen to subscribe to

Re: [MeeGo-dev] init scripts

On 9/24/2010 10:44 AM, Auke Kok wrote: On Thu, Sep 23, 2010 at 05:37:38PM -0700, PJ Bostley wrote: You should write an ofono plugin to properly initialize the 3rd party hardware instead. This way, you don't need to start up anything manually, get rid of the dependencies, and the ofono plugin

Re: [MeeGo-dev] init scripts

On 9/23/2010 9:34 AM, Auke Kok wrote: That immediately raises questions: - is your daemon well-written, such that, once it forks into the background, it's actually up and running and ofono can be immediately started? The following scriptlet (for instance) does NOT work: # dbus-daemon -

[MeeGo-dev] [announce] MeeGo kernel mailing list

Hi, I'd like to announce the creation/existence of the MeeGo kernel mailing list, and I'd like to invite all interested parties to join and help us review patches and make the MeeGo kernel the best distro kernel in the industry. To join, use the mailman interface at http://lists.meego.com/l

Re: [MeeGo-dev] Services

On 9/22/2010 1:05 AM, Robert MARKLUND wrote: I have some questions about starting of services in MeeGo: I have seen that the rc.sysinit is used pretty heavily to start services is this a permanent solution or a quick fix ? this is a permanent solution, not a quick hack. our core OS boot

Re: [MeeGo-dev] Different Modes of Operations

On 9/21/2010 7:28 AM, Robin Burchell wrote: Hi, Excerpts from Arjan van de Ven's message of Tue Sep 21 17:20:34 +0300 2010: On 9/21/2010 6:42 AM, Kasi Viswanath wrote: Hi, First, apologies if it is the not the right place for this question. I tried to put this question in the meego forums

Re: [MeeGo-dev] Different Modes of Operations

On 9/21/2010 6:42 AM, Kasi Viswanath wrote: Hi, First, apologies if it is the not the right place for this question. I tried to put this question in the meego forums today but for some reason it didn't allow me to log-in even. Said access denied. My question was does MeeGo (specially for Ha

Re: [MeeGo-dev] Getting the address of the session dbus daemon

On 9/21/2010 4:03 AM, Pertti Kellomäki wrote: On harmattan, the address of the session dbus daemon is available in a file, so one can do source /tmp/session_bus_address.user if harmattan has such fixed filenames in /tmp, and leaks the session to everyone, you should have a word with you

Re: [MeeGo-dev] Trademark compliance, name usage, etc.

On 9/20/2010 5:10 PM, Greg KH wrote: On Mon, Sep 20, 2010 at 04:57:51PM -0700, Arjan van de Ven wrote: On 9/20/2010 4:47 PM, Greg KH wrote: On M Great, as there is no final compliance program, all things are free to use, right? Depending on what is being used, some require proper

Re: [MeeGo-dev] Trademark compliance, name usage, etc.

On 9/20/2010 4:47 PM, Greg KH wrote: On M Great, as there is no final compliance program, all things are free to use, right? Depending on what is being used, some require proper attribution. How can an artwork package require "attribution"? Why wouldn't it already be contained in the metadat

Re: [MeeGo-dev] Trademark compliance, name usage, etc.

On 9/20/2010 12:42 PM, Andrew Wafaa wrote: So my simple question is, if I use the MeeGo UX can I say "$RELEASE is based on MeeGo's User eXperience, sitting ontop of $DISTRO. Complimenting the other Desktop Environments that are on offer, and offering some additional components (listing component

Re: [MeeGo-dev] Creating a Python project for MeeGo

On 9/20/2010 12:18 PM, Attila Csipa wrote: On Mon, Sep 20, 2010 at 8:26 PM, Matti Airas > wrote: In my opinion, Core OS, absolutely. There's already a world of pain in Maemo 5, with Python being just in Extras and thus effectively prohibited from Ovi

Re: [MeeGo-dev] Creating a Python project for MeeGo

On 9/20/2010 8:59 AM, Matti Airas wrote: Hi Per, We (as in the PySide team) are definitely planning on providing the PySide packages on MeeGo in the near future. However, since we're just ramping up our MeeGo activities (still waiting for the OBS accounts to be created, etc), I have to say

Re: [MeeGo-dev] Upstart in MeeGo?

that's regurgitating systemd propaganda... but that does not make it true ;) It's common sense; in my Fedora laptop I don't use cups, but it's started anyway. If I want to optimize the boot time for speed, I need to manually turn off the services I'm not really using. Presumably MeeGo is doing

Re: [MeeGo-dev] Upstart in MeeGo?

On 9/18/2010 10:33 AM, Sivan Greenberg wrote: Sorry for the ignorance but what is MeeGo using at the moment? /sbin/init comes from sysvinit, however to say that meego uses sysvinit for its startup does not do justice to either meego or sysvinit. We have a rather customized and optimized boot

Re: [MeeGo-dev] Upstart in MeeGo?

On 9/18/2010 8:46 AM, Felipe Contreras wrote: Huh? I think nowadays upstart can be considered deprecated: http://0pointer.de/blog/projects/systemd.html just because someone is doing an experiment doesn't mean other things are deprecated Ok, I thought that was obvious, but I guess time wil

Re: [MeeGo-dev] Upstart in MeeGo?

On 9/18/2010 7:23 AM, Felipe Contreras wrote: 2010/9/17 Greg KH: On Fri, Sep 17, 2010 at 03:19:05PM +0300, Pertti Kellomäki wrote: Are there any plans re upstart in MeeGo? I'm asking because we have test scripts that use initctl to control daemons, so the scripts need to be modified if there i

Re: [MeeGo-dev] Upstart in MeeGo?

On 9/17/2010 5:19 AM, Pertti Kellomäki wrote: Are there any plans re upstart in MeeGo? I'm asking because we have test scripts that use initctl to control daemons, so the scripts need to be modified if there is no upstart. we've been thinking about it, but do not currently have solid plans e

Re: [MeeGo-dev] Meego spec - for comment

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

Re: [MeeGo-dev] Meego spec - for comment

On 9/16/2010 1:45 PM, Andrew Flegg wrote: On Thu, Sep 16, 2010 at 21:04, Skarpness, Mark wrote: On Sep 16, 2010, at 12:49 PM, Andrew Flegg wrote: Make compliance of a package dependent on the ability of the repository to guarantee that all its dependencies can be met. For Extras/Surrounds th

Re: [MeeGo-dev] Meego spec - for comment

On 9/16/2010 12:42 PM, Andrew Flegg wrote: On Thu, Sep 16, 2010Agreed. Mandating Surrounds would be a burden. What about, then, as a compromise going back to one of the earlier suggestions and saying that each repo containing MeeGo Compliant packages can depend on a well-defined set of other

Re: [MeeGo-dev] Meego spec - for comment

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 depend

Re: [MeeGo-dev] Meego spec - for comment

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

Re: [MeeGo-dev] Meego spec - for comment

On 9/16/2010 12:33 AM, Dave Neary wrote: It seems that in your mind, each vendor will provide their own app store, it will be the very common case where the vendor will decide which of the various app stores he will use. appstores are 'the thing' nowadays, and Nokia and Intel each have their

Re: [MeeGo-dev] The role of Qt Mobility APIs in MeeGo OS (WAS: RE: MeeGo Porting Guide available for reading)

On 9/15/2010 12:42 PM, jari.paloja...@nokia.com wrote: Standardizing a low(er) level C API to each middleware level “service” in MeeGo OS would have two benefits: - A single Qt Mobility API backend implementation would suffice => no need for vendor specific implementations this is pretty

Re: [MeeGo-dev] Meego spec - for comment

On 9/13/2010 2:18 PM, David Greaves wrote: 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 resp

Re: [MeeGo-dev] Meego spec - for comment

On 9/13/2010 12:04 PM, 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 con

Re: [MeeGo-dev] Open GL ES on MeeGo Hand-Held

On 9/10/2010 11:17 AM, Stylianou, Costas wrote: Hi What version of OpenGL ES do we have in MeeGo (1.1 or 2.0)? depends on the hardware capabilities. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev

Re: [MeeGo-dev] Meego spec - for comment

On 9/9/2010 9:39 AM, Attila Csipa wrote: On Thu, Sep 9, 2010 at 7:28 AM, Arjan van de Ven mailto:ar...@linux.intel.com>> wrote: The first model is what Maemo used to be, there was only one Maemo; the second model is what Moblin used to be, with many variants. Frankly, I see

Re: [MeeGo-dev] Meego spec - for comment

On 9/8/2010 5:18 PM, Andrew Flegg wrote: (Sorry: broken quoting) Which architects? The MeeGo ones should be on this list and participating in this thread. There certainly shouldn't be backchannel conversations going on ("meego-dev seems to want repo-oriented dependencies"/"no") with you having

Re: [MeeGo-dev] Meego spec - for comment

On 9/8/2010 5:00 PM, 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. I think there's a more gene

Re: [MeeGo-dev] MeeGo spec - for comment

On 9/7/2010 8:00 AM, Kollberg, Jonas wrote: Sure, but not in 100% of the cases. Listening to Internet based radio station is one example. Almost all of them are MP3 based and you can't choose your codec. Anyway, this was just an example. There might be other similar things with other vital c

Re: [MeeGo-dev] MeeGo spec - for comment

On 9/7/2010 3:43 AM, Kollberg, Jonas wrote: 3rd party apps must only depend on the core components or on things that are included with the app. not other (4th party?) things. One problem that may appear is for example for codec's. An example: 1. An MP3 codec will not be part of the core compon

Re: [MeeGo-dev] Serializing daemons started from /etc/xdg/autostart

On 9/7/2010 12:33 AM, Pertti Kellomäki wrote: Is there a way to serialize application/daemon start from /etc/xdg/autostart? I need to start two daemons (applauncherd and prestartd) when a UI session starts, and potentially applications started by prestartd could use the services of applauncher

Re: [MeeGo-dev] MeeGo 1.1 Development Release 1.0.90.0.20100831.1 is availabe

On 9/6/2010 10:56 PM, Rohit Baravkar wrote: Hi, Can anybody tell me whether the touch is enabled in the generic ia32 Netbook devices? the Netbook vertical UI is not really designed for touch. (especially not "touch only") ___ MeeGo-dev mailing l

Re: [MeeGo-dev] Meego spec - for comment

On 9/7/2010 2:10 AM, Andrew Flegg wrote: Arjan wrote: On 9/6/2010 4:00 PM, Lucas Maneos wrote: - 70-71: "It shall use only external commands and other facilities described in this specification, whether for installation tasks or run-time tasks." It should be allowed to use commands / fa

Re: [MeeGo-dev] Meego spec - for comment

On 9/7/2010 2:08 AM, Dave Neary wrote: Hi Arjan, Arjan van de Ven wrote: On 9/6/2010 10:38 AM, Thiago Macieira wrote: No busybox? absolutely not; not worth the hassle / incompatibility As a general remark: are you perhaps falling into the trap of "all the MeeGo world's a net

Re: [MeeGo-dev] Meego spec - for comment

On 9/6/2010 4:00 PM, Lucas Maneos wrote: On Fri, Sep 03, 2010 at 04:59:37PM -0600, Wichmann, Mats D wrote: There's a rough early version available on http://wiki.meego.com/Quality/Compliance Thanks! Just went through it, here are a few comments: - 70-71: "It shall use only external commands

Re: [MeeGo-dev] Meego spec - for comment

On 9/6/2010 10:53 AM, Ville M. Vainio wrote: On Mon, Sep 6, 2010 at 7:47 PM, Arjan van de Ven wrote: It's bash. Anything except bash is a world of pain that we really really don't want to deal with. Bash is gpl3, which *may* be problematic if we eventually want the default script

Re: [MeeGo-dev] Meego spec - for comment

On 9/6/2010 10:38 AM, Thiago Macieira wrote: Em Segunda-feira 06 Setembro 2010, às 18:47:22, Arjan van de Ven escreveu: On 9/6/2010 12:10 AM, Marius Vollmer wrote: This ought to be able to cover the shell as well. Then we just need to choose a shell that is acceptable to everyone, which

Re: [MeeGo-dev] Meego spec - for comment

On 9/6/2010 12:10 AM, Marius Vollmer wrote: This ought to be able to cover the shell as well. Then we just need to choose a shell that is acceptable to everyone, which might not be bash It's bash. Anything except bash is a world of pain that we really really don't want to deal with. (yes I

Re: [MeeGo-dev] Meego spec - for comment

On 9/6/2010 3:03 AM, Dave Neary wrote: Hi, Marius Vollmer wrote: In general, I think we don't need to treat the shell specially. We should just fold it into the next paragraph: 254 Commands and Utilities Default install of any compliant system shall provide commands and utilities

Re: [MeeGo-dev] Installing Meego on Dell Streak

On 9/5/2010 8:58 AM, Randolph Dohm wrote: Had anyone sucess to install MeeGo on Dell Streak Mobile Phone 5" ? how is your question related to the development of meego? please stay on topic on the mailing lists! ___ MeeGo-dev mailing list MeeGo-dev

Re: [MeeGo-dev] Looking for a right way to create daemons on MeeGo

On 9/4/2010 10:32 AM, Sivan Greenberg wrote: So it seems that just for starting the service without accepting a msg it is a bit misuse, in the fact that you send a nonsense message just to get the device started. Does this have any performance penalty ? For example, if msg loss can occur while t

Re: [MeeGo-dev] lsmod output

On 8/31/2010 7:30 AM, Thiago Macieira wrote: Em Terça-feira 31 Agosto 2010, às 16:12:28, Hari escreveu: The command lsmod which prints the contents of the /proc/modules file. It shows which loadable kernel modules

Re: [MeeGo-dev] [meego-packaging] FWD: Mandatory use of pkgconfig in BuildRequires?

On 8/30/2010 10:47 AM, fathi.bou...@nokia.com wrote: forwarding to the appropriate mailing list. From: meego-dev-boun...@meego.com [meego-dev-boun...@meego.com] On Behalf Of Zabaluev Mikhail (Nokia-MS/Helsinki) Sent: Monday, August 30, 2010 8:12 PM To: me

Re: [MeeGo-dev] GPS, Meego && IVI

On 8/30/2010 8:38 AM, Kevron Rees wrote: Hope that helps. As I understand, the qt-mobility location backend for meego will be geoclue/gypsy. So that should at least abstract application writers from having to know the details of the device. yep meego.com will use/is using geoclue/gypsy co

Re: [MeeGo-dev] libgstinterfaces error when compiling libmeegotouch

On 8/29/2010 6:37 PM, danny wrote: Hi, In fedora system it is gstreamer-interfaces-0.10, and belong to gstreamer-plugins-base-devel. Others such as Ubuntu maybe be gstinterfaces-0.10 and should belong to gst-plugins-base-dev. Perhaps you should change to -lgstreamer-interfaces-0.10 by your

Re: [MeeGo-dev] Dead code in rc.sysinit?

On 8/28/2010 2:48 AM, Héctor Blanco Alcaine wrote: Hi, 2010/8/27 Carsten Munk: [...] But in the sreadahead source I don't see any code handling SIGUSR1 handling this scenario, but I do see a init script that starts the packing. Am I wrong in assuming the rc.sysinit part is either wrong or a

Re: [MeeGo-dev] [PATCH meego-handset-dialer 3/3] added necessary dependencies to the project

On 8/27/2010 1:49 PM, Kevron Rees wrote: --- src/src.pro |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/src/src.pro b/src/src.pro index 7bad58a..6ff382c 100644 --- a/src/src.pro +++ b/src/src.pro @@ -6,7 +6,8 @@ PKGCONFIG += QtNetwork QtContacts MOC_DIR = .moc O

Re: [MeeGo-dev] Qemu setup on a netbook

On 8/26/2010 5:47 AM, Andrzej Zaborowski wrote: On 25 August 2010 23:13, Auke Kok wrote: On 08/25/2010 01:45 PM, Mark S. Townsley wrote: Hello All: I want to give Qemu a try so I installed Ubuntu 10.04 on my Acer netbook. Since Qemu requires GPU acceleration, I followed this link

Re: [MeeGo-dev] [PATCH 5/5] fixed seg faulting when no ofono is running

On 8/25/2010 4:37 PM, Michael Leibowitz wrote: what does "Signed-off-by" mean ? You're signing WHAT ? http://kerneltrap.org/files/Jeremy/DCO.txt ;) ehh 1) this wasn't a kernel patch 2) what does have some random file on kerneltrap.org have to do with your project? ___

Re: [MeeGo-dev] [PATCH 5/5] fixed seg faulting when no ofono is running

On 8/25/2010 2:56 PM, Shane Bryan wrote: On Wed, 25 Aug 2010 14:33:12 -0700 Kevron Rees wrote: --- src/dialerkeypad.cpp | 18 +- src/historytablemodel.cpp |4 +++- src/src.pro |7 --- 3 files changed, 16 insertions(+), 13 deletions(-)

Re: [MeeGo-dev] Guidelines for contributing code to MeeGo

On 8/24/2010 4:40 PM, Foster, Dawn M wrote: On Aug 23, 2010, at 4:55 PM, Foster, Dawn M wrote: I tried to incorporate a couple of changes that seemed to have some agreement (CC'ing maintainers for example), so here is the now "official" policy for contributing code to MeeGo. We'll still co

Re: [MeeGo-dev] [PATCH] Upgrade N900 SGX drivers to 201003002 in order to not have a non-production snapshot of the drivers. Fixes BMC#5711

On 8/24/2010 7:30 AM, Carsten Munk wrote: This is part 5 of 5 of a patchset implementing the following in MeeGo kernel: + * The pvr_dvfs_* interface is needed to suppress a lockdep warning in + * the following situation during a clock rate change: + * On the CLK_PRE_RATE_CHANGE: + * 1. lock A <-

Re: [MeeGo-dev] Plans for gnome-control-center

On 8/23/2010 12:54 PM, Leonardo Luiz Padovani da Mata wrote: Will gnome-control-center be changed to any settings tool writen in QT?If so, where i can find the source code? g-c-c is only used in the Netbook vertical right now, which is on a slow path compared to others in terms of Qt migra

[MeeGo-dev] Heads up: kernel until the feature freeze

With the feature freeze for 1.1 on Wednesday August 25th. For me to be able to do the final submission to MeeGo on the 25th, I need all code submitted to the kernel on the 24th before noon my time. After the submission on the 25th, the MeeGo 1.1 kernel will only get approved bugfixes (app

Re: [MeeGo-dev] GCC default setup for x86 following optflags/command line parameters instead of atom-specific patch

On 8/20/2010 11:52 PM, Carsten Munk wrote: [this is -not- a SSSE3 discussion thread nor should it turn into one] We were having some discussions around in some bugs that things should in general follow OBS project optflags/CFLAGS/CXXFLAGS. For MeeGo.com builds this is naturally optimized for Ato

Re: [MeeGo-dev] Does MeeGo need OpenGL/ES or OpenVG Hardware?

On 8/20/2010 8:51 AM, Tobias Renz wrote: Thanks already for your answers! The targeted device is like a measurement device. So It's not too important to have MeeGo compliance as a label. Also we would have an overview of all third party apps that we would let the customer install or offer to h

Re: [MeeGo-dev] Does MeeGo need OpenGL/ES or OpenVG Hardware?

On 8/20/2010 6:58 AM, Tobias Renz wrote: Hello, I'm trying to bring MeeGo to a iMX35 processor based board. The iMX35 is an Arm11 (ArmV6). There is a subderivate (iMX356) that has a Z160 OpenVG 1.1 core. Now I'm reaserching wether MeeGo will run on this processor. I heard some contradicting

Re: [MeeGo-dev] getting gps position in meego (with gypsy)

On 8/18/2010 4:43 PM, Digioia, MichaelX wrote: No You sound correct in both respects. An insulating (HW ABST) is needed! Sounds like fun wish I could do it. yup that's so logical that it's already there ;-) not entirely sure what the status of glueing that to QtMobility is though.

Re: [MeeGo-dev] getting gps position in meego (with gypsy)

On 8/18/2010 4:35 PM, Kevron Rees wrote: I'm trying to understand how gps position retrieval is going to work in meego. My questions are specifically related to gypsy and it's usage within meego. I may be wrong, but I see a couple issues with using gypsy currently: really this needs to go

Re: [MeeGo-dev] ARMv7, Qt and NEON

On 8/18/2010 6:30 AM, Rémi Denis-Courmont wrote: The only portable manner to establish NEON support is the __ARM_NEON__ predefined constant, just like __SSE3__ implies SSE3 support. Obviously, that simply reflects the compiler settings. If you want to make the decision at run- time, you're going

Re: [MeeGo-dev] ARMv7, Qt and NEON

On 8/18/2010 6:15 AM, Andrew Flegg wrote: On Wed, Aug 18, 2010 at 14:09, Arjan van de Ven wrote: On 8/18/2010 3:19 AM, Carsten Munk wrote: [...] Compile Qt with NEON support by default on ARMv7. Include script in startup that provides QT_NO_NEON=1 to the UX session based on NEON

Re: [MeeGo-dev] ARMv7, Qt and NEON

On 8/18/2010 3:19 AM, Carsten Munk wrote: [this is not another SSSE3 discussion thread] Qt on OMAP3 has very big benefits from using NEON, just like using SSSE3 does on Atom. However, we do not currently compile for NEON in MeeGo for ARMv7 as not all ARMv7 has NEON (Marvell, Nvidia being notable

Re: [MeeGo-dev] [meego-packaging] MeeGo-commits ... reply-to to MeeGo dev ?

On 8/17/2010 6:09 PM, Anas Nashif wrote: yeah, agree on that. I would prefer meego-packaging, since meego-dev is completely off-topic in this regard. agreed; I was about to suggest the same (packaging not dev) ___ MeeGo-dev mailing list MeeGo-d

Re: [MeeGo-dev] Architecture: Is there an alarmd or cron replacement?

On 8/17/2010 11:53 AM, Auke Kok wrote: On 08/17/2010 11:51 AM, Arjan van de Ven wrote: On 8/17/2010 11:27 AM, Michael Leibowitz wrote: On Tue, 2010-08-17 at 11:15 -0700, Auke Kok wrote: I did a quick strace scan on a crond install and didn't see anything shocking, it's actually ra

Re: [MeeGo-dev] Architecture: Is there an alarmd or cron replacement?

On 8/17/2010 11:27 AM, Michael Leibowitz wrote: On Tue, 2010-08-17 at 11:15 -0700, Auke Kok wrote: I did a quick strace scan on a crond install and didn't see anything shocking, it's actually rather clean - only does reads and stats once a minute, which shouldn't dirty anything. Would

Re: [MeeGo-dev] Porting MeeGo to a new armv5 based platform

On 8/17/2010 7:49 AM, Zheng Zhang wrote: Hi, We have a plan to port MeeGo to a new armv5 based platform.As far as I am concerned, the porting work may include following points: 1.In general, the boatloader can be reused. 2.Clone the meego-os-base->kernel-source, follow the README.workflow t

Re: [MeeGo-dev] non SSSE3 MeeGo

On 8/13/2010 9:01 AM, Brendan Le Foll wrote: I guess people want the official OBS to have the generic i686 target so it becomes a supported Architecture. The logic is valid, this is a community project, why does the x86 port only support the Intel atom? If it's just the speed then we could just

Re: [MeeGo-dev] Meego Security framework build problem

On 8/13/2010 1:35 AM, vinod wrote: Hi I am trying to integrate aegis Security framework into the N900 kernel. Wihle building the validator module I get following error. CHK include/linux/version.h CHK include/generated/utsrelease.h make[1]: `include/generated/mach-types.h' is up to

Re: [MeeGo-dev] clutter and gtk

On 8/10/2010 5:51 PM, Mark S. Townsley wrote: Thanks I understand that the current UI is built with clutter, is that correct? some pieces of the core netbook UI (the panels and such) use clutter today yes. the handset ui for example does not. ___

Re: [MeeGo-dev] Suggestion on new project ideas

On 8/10/2010 11:26 AM, Auke Kok wrote: On 08/10/10 00:22, Brendan Le Foll wrote: So, if someone wants to spend their time porting networkmanager, I'm not going to stop them. But, chances are that the default MeeGo images will be using connman for a very long time. one thing to mention is tha

Re: [MeeGo-dev] uxlauncher - Reason to use `-nolisten tcp` in Xorg command

On 8/10/2010 9:52 AM, paulo alcantara wrote: At certain point, I would like to test a videv feature which only works without the parameter `-nolisten tcp` in Xorg command. Then I would like to know why the `-nolisten tcp` paramater is passed as default in Xorg command and also if there is any

Re: [MeeGo-dev] clutter and gtk

On 8/10/2010 7:58 AM, Mark S. Townsley wrote: Hi: I noticed that MeeGo comes with clutter and gtk. Since the SDK does not spell out either of these libraries, can I still develop based on clutter and gtk instead of Qt? you should develop new application you should develop in Qt and not in

Re: [MeeGo-dev] [PATCH 1/1] virtio-gl kernel module for GL acceleration of Emulator (on behalf of Ian Molton)

On 8/10/2010 2:39 AM, Lv, Zhiyuan wrote: --- a/drivers/char/Kconfig +++ b/drivers/char/Kconfig @@ -1113,6 +1113,14 @@ config TELCLOCK /sys/devices/platform/telco_clock, with a number of files for controlling the behavior of this hardware. +config VIRTIOGL + tristate "Virtio userspace memory trans

Re: [MeeGo-dev] MeeGo 1.0 Update for Netbooks

On 8/10/2010 2:04 AM, Glen Gray wrote: Process question, Are the rollup releases planned to happen on a fixed time basis or is a decision made to release a rollup when a certain number criteria are met, be that the number of critical bugs fixed or the number of minor bugs fixed etc. cu

Re: [MeeGo-dev] DHCP, undefined function change_resolv_conf

On 8/9/2010 3:07 AM, adam.mik...@tieto.com wrote: Hi. I'm trying to run dhclient. It gets IP from AP without problems, but when it tries to resolve DNS queries, it fails. It seems that /sbin/dhclient-script invokes undefined function change_resolv_conf. In other distributions it is located in

Re: [MeeGo-dev] meegotouchtheme 0.20.35-1 has been tagged.

On 8/9/2010 12:13 AM, Adrian Yanes wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi, a new version of meegotouchtheme is available: meegotouchtheme (0.20.35-1) unstable; urgency=low * New version * Changes: fixes in buttons at commonlayouts * Changes: No background for button

Re: [MeeGo-dev] [MeeGo-Dev][PATCH] Topcliff: Update PCH_I2C driver to 2.6.35

On 8 OKI will submit this patch to LKML also. Is it better that they submit this patch to Meego-Dev and LKML as well with one E-Mail. it's best to submit to lkml first... ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinf

Re: [MeeGo-dev] Can't rebuild dbus from source rpm

On 8/6/2010 7:50 AM, Leonardo Luiz Padovani da Mata wrote: Hello, I've downloaded the source code of Dbus to rebuild it from: http://repo.meego.com/MeeGo/releases/1.0/core/repos/source/dbus-1.2.24-7.1.src.rpm I need to change the rules of /etc/dbus-1/system.conf to add rule: 5 this rule is

Re: [MeeGo-dev] [MeeGo-Dev][PATCH] Topcliff: Update PCH_I2C driver to 2.6.35

On 8/5/2010 9:33 PM, Masayuki Ohtak wrote: > > +config PCH_I2C > + tristate "PCH I2C" > this is really not very descriptive. Can you make it "OKI Semi PCH I2C controller" or something if you has human get asked "PCH I2C"... almost nobody will know what that means.+static irqreturn_t pch_

Re: [MeeGo-dev] why uxlaunch could not run as root and any way to do that?

On 8/5/2010 9:04 PM, danny wrote: Hi all, I found that the uxlaunch could not run as root in meego, and also we could run mutter --replace in XFCE or other env. It is not convenient to test and debug for mutter-moblin and also other meego's program. Do you have any way to do that? I remembere

Re: [MeeGo-dev] ARM softfloat or hardfloat?

On 8/4/2010 2:36 PM, Jeremiah Foster wrote: Hello, What is MeeGo planning to do with regards to ARM hardfloat or softfloat? What is the rationale behind the choice? Some background information here: http://wiki.debian.org/ArmHardFloatPort Jeremiah it's my understanding

Re: [MeeGo-dev] systemd & meego?

On 8/4/2010 9:38 AM, Yves-Alexis Perez wrote: On 02/08/2010 21:07, Auke Kok wrote: well, I'm not saying they aren't, but I'm having doubts whether the method of starting daemons in parallel while they all wait-and-block for dependencies will work, and provide the speedy boot needed on low-po

<    1   2   3   4   5   >