Re: [MeeGo-dev] [Meego-handset] Changes in the MeeGo Bugzilla for Handset User Experience
On 8/31/2011 12:16 AM, ext-iekku.pyl...@nokia.com wrote: Hi all, Want to remind about the changes. I haven’t received any comments about the adding other UX stuff to Handset UX. See all the conversation from: http://lists.meego.com/pipermail/meego-handset/2011-July/thread.html Shane Bryan replied for the original proposal and libseaside is staying as it is. Any other comments? I'm ignoring meego bugzilla as useless unless it has a 1:1 mapping between packages and components so go ahead, change what you want, I won't notice ;-) ___ 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] Wireless network is no longer detected on Lenovo hybrid netbook
On 8/16/2011 1:48 PM, Bogdan Cristea wrote: On Sunday 14 August 2011 23:16:11 you wrote: On 8/14/2011 1:09 PM, Bogdan Cristea wrote: I have updated MeeGo to kernel 2.6.37.2-8.43 on a Lenovo hybrid netbook, but the wireless connection is no longer available. With the default MeeGo installation (1.1.99.0.20110330) everything worked fine, but the configured repository was no longer available and I have switched to a new one (version 1.2.0.90.12.20110805). Could you provide a link to a stable MeeGo repository ? you're using the wrong kernel.. netbooks should be using the kernel-adaptation-pinetrail kernel which is 2.6.38 not 2.6.37 based thanks Hi I have installed MeeGo 1.2 stable release and updated the kernel to 2.6.38.2-8.9 adaptation pinetrail but still the wireless connection is disabled. I have checked in bios menu that the wireless is enabled. Does anyone know how can I have a working wireless connection on Lenovo S10-3t ? is this one of the s10-3t's with a broadcom wireless? we didn't have enough time to get the open source driver to work in 1.2; should be ok in 1.3 ___ 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] Wireless network is no longer detected on Lenovo hybrid netbook
On 8/14/2011 1:09 PM, Bogdan Cristea wrote: I have updated MeeGo to kernel 2.6.37.2-8.43 on a Lenovo hybrid netbook, but the wireless connection is no longer available. With the default MeeGo installation (1.1.99.0.20110330) everything worked fine, but the configured repository was no longer available and I have switched to a new one (version 1.2.0.90.12.20110805). Could you provide a link to a stable MeeGo repository ? you're using the wrong kernel.. netbooks should be using the kernel-adaptation-pinetrail kernel which is 2.6.38 not 2.6.37 based thanks ___ 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] What is hibernate status?
On 8/12/2011 5:30 AM, Roman Borisov wrote: Hello All, I was trying to enable suspend to disk functionality on several platforms; the meego reference release does not include or enable hibernate, and we don't test it. But it seems your kernel is from an OS vendor who customized it; I would suggest checking with said OS vendor to see what testing they have done on the specific hardware (for them to enable it I assume they tested it) ___ 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] What is hibernate status?
On 8/12/2011 10:44 AM, rborisov wrote: On Fri, 2011-08-12 at 07:49 -0700, Arjan van de Ven wrote: On 8/12/2011 5:30 AM, Roman Borisov wrote: Hello All, I was trying to enable suspend to disk functionality on several platforms; the meego reference release does not include or enable hibernate, and we don't test it. But it seems your kernel is from an OS vendor who customized it; I would suggest checking with said OS vendor to see what testing they have done on the specific hardware (for them to enable it I assume they tested it) no; I don't think that OS vendor did anything to enable hibernate he at least enabled it in the kernel functionality; I used standard pm-utils; the system contains them by default; but I want to enable it; what should I do? BIOS is supported hibernation hibernate is a laptop-to-laptop thing in linux still unfortunately (also why we didn't work on it in meego) but talk to the OS vendor, they should be able to make it work on a specific laptop if they enabled it. -- Thanks ___ 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] Compiling Pulseaudio
On 8/2/2011 8:46 AM, Clark, Joel wrote: Have you tried cloning the pulseaudio package in the build server and letting OBS build it for you? This is what most of the dedicated MeeGo developers do for projects that don't have a meego gitorious home. That's also why they don't notice when rpmbuild doesn't work ... because they never use it. OBS uses rpmbuild to build. if something does not work outside of OBS, there's some environmental difference... but not rpmbuild :-( ___ 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 Tablet 1.2 system not responses at Qt applicaiton exit
On 7/31/2011 7:58 PM, Dong Li wrote: Hi list, I've got a problem while programming with Qt on Intel Oaktrail platform. In order to improve the application performance, I took use of the Qt raster backend [void QApplication::setGraphicsSystem ( const QString system )], and the proformance was really improved a lot in comparison with native backend. However, the problem is that the entire system will not response at applicaiton exit, and afterwards, system would recover in 10 or 20 seconds. I monitored the CPU usage during that time, and found Xorg and application itself were at 90% above. any chance of installing enough debuginfo rpms and then doing a perf record -a -g sleep 10 perf report for the duration of the app exiting? that will show you which functions/libraries you're spending cpu time... ___ 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 Sharing Framework plugin in Harmattan
On 7/30/2011 3:14 AM, Tuomas Kulve wrote: Hi interesting harmattan question snipped you probably should ask your question on a harmattan forum, not on this meego forum; different enough technologies to matter... (meego uses a different security technology, and at least on tablet, we use a different sharing technology) ___ 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] Looking for documents to Meego Common Componets
On 7/29/2011 3:02 PM, David Boosalis wrote: Anybody know the answer to the question I posted yesterday (See below) Are there any Qt-Quick components to use for Meego tablet. Looking for buttons, labels, toolbars, etc look at the meego-ux-components package in the distro ___ 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-kernel] at90usbkey sample firmware (HID mouse) / touch-screen
Where to get at90usbkey sample firmware (HID mouse) driver? Set the kernel config file, or add patch? I would suggest asking the hardware supplier for a Linux driver, since I don't think we have a driver (or device!) with this controller in it. ___ 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-kernel] at90usbkey sample firmware (HID mouse) / touch-screen
On 7/25/2011 8:03 PM, weihua.zhang wrote: Kok, Auke-jan H 写道: 2011/7/25 weihua.zhang weihua.zh...@cs2c.com.cn: Hello, I've just acquired an Atom tablet PC with a touchscreen. The screen appear to be a USB HID device, showing up in lsusb as Bus 001 Device 006: ID 03eb:201c Atmel Corp. at90usbkey sample firmware (HID mouse) meego-1.2 install: 1、wget http://repo.meego.com/MeeGo/releases/1.2.0/builddata/image-configs/tablet-ia32-oaktrail.ks 2、mic-image-creator --config=tablet-ia32-oaktrail.ks --format=livecd --cache=mycache boot - uxlaunch - the desktop the cursor moves around, but clicks are obstructed; Click or double-click does not work. so you have a touchscreen device, but it registers itself as mouse? where are the left-click and right-click button on your touchscreen? Auke It is not a mouse, and it is a touch screen... Select an application icon on desktop, touch it with one finger and tap the screen. Without any response... Fingers move on the screen , and the cursor moves only. I try to use an external USB mouse, and click an application icon it can work well. you'll need to add a proper (multi)touch driver to your kernel, as well as adding it to the HID blacklist so that it's not seen as a mouse. ___ 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] Error drm/i915 can't work without intel_agp module DURING INSTALL
On 7/13/2011 8:48 PM, 张巍华 wrote: Hi all. I'm trying to install MeeGo to my PC but everytime it gives me an error. USB boot. Welcome to Meego! it says and from 3 options I choose Installation Only and press Enter. so you're not using a netbook or the like (not a pinetrail board), you are using a pinetrail kernel... but you rebuild it yourself on July 5th on a debian system? would be nice to mention such things in your emails in the future ;-) so what kind of system is this? Without answering that question you are wasting everybodies time ___ 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] Bringing up Genivi - Borg on Lenovo s10-3T
On 7/6/2011 3:51 AM, dhaval bc wrote: hi all, Has anyone tried to bring up Meego IVI 1.2 on lenovo S10-3t??? i found the a link http://wiki.meego.com/IVI-LenovoS10-3t on meego wiki which specifies steps for Installing Meego IVI on the Lenovo S10-3t. but UI doesn't come up :( Xorg fails, it's unable to find the board name (Board name unknown), because of which Xorg.conf file is not generated by emgd_bin if you're using EMGD on a lenovo S10-3t... it ain't gonna work that guy needs the regular Intel integrated graphics drivers. ___ 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] creating image for oaktrail platform using mic-image-creator
On 7/6/2011 7:30 PM, bradleyyan wrote: It is my mistake,I forgetten to install install related packages. also make sure to upgrade your firmware; this was a bug in early firmwares that got since fixed... ___ 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] File manager for Tablet Edition
On 7/1/2011 9:29 AM, Bernd Stramm wrote: On Fri, 01 Jul 2011 09:14:17 -0700 Andy Rossa...@plausible.org wrote: On 07/01/2011 08:33 AM, Éric Seigne wrote: so meego don't need a file manager for tablet, thanks a lot, i don't waste my time. At the risk of adding more paint to the bikeshed: I think a better answer is that there are no plans to add a file manager as a core component. But a QML meego-ux-based third party utility would not doubt be a valuable contribution and see extensive use by technical users, just as it has on similar platforms. In addition to that, it would be stupid to prevent people from providing additional tools just because the original designers did not foresee the usefulness. Why discourage people from contributing? sounds also like a perfect app for an AppStore(tm) kind of setup ;-) ___ 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] File manager for Tablet Edition
On 7/1/2011 3:43 PM, Florent Viard wrote: Hi, Stop considering the regular user as a stupid guy/girl that needs to have everything reduced to only one button. Most of the users never had problem to understand and use file managers as soon as they are used to. (Otherwise, windows wouldn't have been used by so much users until today) Stop trying to think in place of a pseudo average joe but instead try to create things that are useful for you and the normal users will follow. It is the current trend for distributions to say: we (as advanced users) wouldn't like this simplification, but we don't care, we target the big basis of stupid peoples, so let's doing something stupid enough for them to be able to understand it without education. AMEN. I have been complaining about this for a while, and am this close to making a tshirt, or even a big banner with I AM A USER TOO on it. An open source project CANNOT ignore open source enthusiast (note that I do not limit myself to coders) as one of its key constituencies/targets even if the market share of those for your product might be low, these are the people that - tell you what is wrong with your product rather than just walking away - send you cohesive bugreports - ... often in diff -u form - translate for you - tell all their friends how cool this device is and that they should get one too - influence the high-tech press, which in turn influences the mainstream press I know that some people think that the early adopter is dead in this day and age, but I am not convinced of that yet. I also know that some people think that there is an exclusive-OR between the user and the open source enthusiast. Nothing is more from the truth. Even Apple gets this right and makes an OS that is surprisingly usable by hardcore open source hackers. ___ 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] [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.
On 6/30/2011 7:10 AM, Marius Vollmer wrote: ext Arjan van de Venar...@linux.intel.com 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.
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 6/29/2011 2:05 AM, eric.le-r...@nokia.com wrote: So I guess you could remind anyone on your side involved into moving the bugs that it's mandatory to at least put a comment with the reasoning behind the action. so as a user of bugzilla I strongly disagree with your statement. I use the filter bug mail feature so that I only get bugmail on important events (real new information added, not just noisy bookkeeping things) that feature gets completely and utterly destroyed if the QA person, in addition to the actual change, also puts in I changed this as comment. (and that comment adds absolutely zero value) ___ 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] Execute automatically a script at statup in meego-tablet-ia32-pinetrail-1.1.90.2.20110209.4
On 6/26/2011 7:44 AM, Bogdan Cristea wrote: I would like to execute at startup a script allowing to launch synergy client. I have put this script in /etc/init.d and made a soft link to the script in /etc/rc5.d, but the client is not running. What is the approach I need to this is very invalid and causes many problems! you should be using chkconfig --add to register the service with the system (but the packaging is a bit complex, the fedora packaging guidelines are the best description of how to package a service with rpm that I've found) but note that this runs your component as a root daemon. if you want to run in the user session, you need to place a .desktop file in /etc/xdg/autostart ___ 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] Execute automatically a script at statup in meego-tablet-ia32-pinetrail-1.1.90.2.20110209.4
On 6/27/2011 1:02 PM, Leonardo Luiz Padovani da Mata wrote: Hey Bogdan, consider adding the script call on /etc/rc.local. As i remember, the default runlevel for MeeGo is 3, not 5, so adding it to rc3.d might work also. On our sollution the package containing the daemon creates a .desktop on /etc/xdg/autostart with the commands that you wish to run on openning the UX, but this is just a workaround since we don't want to I'm sorry but your recommendation is even worse than the original thing... but they're both very very wrong. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] Netbook image screen size and resolution
On 6/27/2011 11:04 AM, Leonardo Luiz Padovani da Mata wrote: Hello all, Looking at http://wiki.meego.com/Netbook_Design_Guide there is a paragraph saying that the smallest resolution is 1024x600 but this isn't the case for 7 display. Sometimes the 7 is only available in 800x480. Is there any plans to provide lower resolution on netbooks? Is it possible to enable virtual desktop resolution? Will it be any screen resolution configuration tool for MeeGo? there are no plans to move the Netbook UI to that resolution. that's more a resolution in which the phone UI or tablet UI will work (but the later even barely) ___ 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] Where to post bug reports for Maemo 6 Harmattan?
On 6/21/2011 9:29 PM, Andrey Ponomarenko wrote: Hi, Could anybody explain me where to post bug reports for Maemo 6 Harmattan [1]? To maemo.org Bugzilla [2] or to MeeGo Bugzilla [3]? primarily you should report bugs to the vendor of the device (Nokia) or of the OS (also Nokia.. but maemo bugzilla is likely closest for that). If you're very tech savy and figure out it's an upstream bug, you could report it to the upstream project as well. (none of these are meego bugzilla... filing it in meego bugzilla would be similar to filing a kernel bug in Ubuntu in Fedora bugzilla... not very nice and complete waste of time for everyone) ___ 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] Add login in meego using uxlaunch
On 6/16/2011 7:30 PM, bradleyyan wrote: Hi all, Did anybody had developed multi-user login function like gdm for meego? I had planed to use uxlaunch and modify it to realize multi-user login. meego is currently multi user; this goes unfortunately quite a bit further than just the login screen. (the separation between user and root domain is pretty poor unfortunately) but if you want login screens uxlaunch is the wrong thing to use. ___ 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] Call for ideas - preprocessor #define for meego version (Q_MEEGO_VER ?)
On 6/13/2011 3:12 PM, Bernd Stramm wrote: On Mon, 13 Jun 2011 15:05:41 -0700 Arjan van de Venar...@linux.intel.com wrote: On 6/13/2011 2:57 PM, Bernd Stramm wrote: It feels like it has been maybe 6 months or so, time to bring this up again: why isn't there a way to determine the physical display size at run time? Or maybe there is a way now. there was then, there is now. The X server advertises this, Qt asks for it as well from the X server... all you need to do is ask Qt. That answer keeps coming up, and its still not quite right. The value advertised by X is off by as much as 50%, in meego. what bugnumbers do you have for this? if the graphics driver lies, we have a mechanism (in uxlaunch) to override/fix this on a per board basis. sounds like you have a board where this is not done correctly ___ 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] Call for ideas - preprocessor #define for meego version (Q_MEEGO_VER ?)
On 6/13/2011 3:27 PM, Bernd Stramm wrote: But it could be worse than you think. The size info would be useful for displays that are not build into the meego device. Docking stations, projectors and the like. That is where it gets really interesting, and uxlaunch probably has less control. the good news is that, for things like MacOS and Windows to work, external devices report their dimensions relatively accurately in general with exceptions few and far between (it's an interesting question what size a wall projector has ;-) ___ 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] Call for ideas - preprocessor #define for meego version (Q_MEEGO_VER ?)
On 6/13/2011 3:42 PM, Thiago Macieira wrote: The problem is that actual dimensions, resolution and DPI are tied to one another. Some systems are known to force the DPI value at a specific number and they do that by changing the actual dimensions reported by X. I've seen this even presented as a configuration setting to users in some systems... interesting observation for some systems have you seen this with a properly configured meego? (this clearly is all in meego context..) ___ 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] Cutting MeeGo 1.3 install footprint, locales?
On 6/10/2011 1:54 PM, Carsten Munk wrote: Hi, One of the bigger users of space in the images is /usr/lib/locale/locale-archive, which takes up 99mb uncompressed. is this based on ls output, or after taking sparse files into account ? also, our filesystem compresses as you know; how well does this compress down ? ___ 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] setting TERM in environment
On 6/6/2011 9:20 AM, Robin Burchell wrote: Hi, I've been doing some cursory kicking of the tires of the (very recently released) meego-terminal (https://gitorious.org/meego-terminal/meego-terminal/), and one thing that came up pretty quick when I tried to run top was that TERM wasn't set. Who's responsibility is it to have this set? uxlaunch seems one candidate, but I don't know if that's correct? clearly each terminal has it's own values.. that the terminal program should set! \ ___ 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] Initrd on Kernel to mount root with UUID
On 6/5/2011 3:08 PM, Leonardo Luiz Padovani da Mata wrote:odd; our installer, bootloader and kernel configuration actually should not allow this to happen can you reproduce this with the meego reference set of these ? I will try to reproduce this problem with default MeeGo image, the thing is that i didn't receive the hardware samples where this problem is ocurring. Can the developers point to where the sollution os fixed? Also, one question is kickstart out of the installation process? we probe sata before USB, so internal storage gets found and assigned a device node before USB does. the installer does magic to ensure internal sata happens ok during the installation process syslinux just does the right thing as boot loader I don't know why you chose to use grub; we use syslinux just like just about any other distro on the planet (various other distros then switch to a different bootloader after installation.. we don't, why mix in 2 risks into it) ___ 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] Initrd on Kernel to mount root with UUID
On 6/5/2011 6:48 PM, Leonardo Luiz Padovani da Mata wrote: Hello Arjan, thanks for helping me. On Sun, Jun 5, 2011 at 7:36 PM, Arjan van de Ven ar...@linux.intel.com mailto:ar...@linux.intel.com wrote: On 6/5/2011 3:08 PM, Leonardo Luiz Padovani da Mata wrote:odd; our installer, bootloader and kernel configuration actually should not allow this to happen can you reproduce this with the meego reference set of these ? I will try to reproduce this problem with default MeeGo image, the thing is that i didn't receive the hardware samples where this problem is ocurring. Can the developers point to where the sollution os fixed? Also, one question is kickstart out of the installation process? we probe sata before USB, so internal storage gets found and assigned a device node before USB does. the installer does magic to ensure internal sata happens ok during the installation process syslinux just does the right thing as boot loader Interesting... is this a special udev rule? no just proper but careful configuration of a bunch of things I don't know why you chose to use grub; we use syslinux just like just about any other distro on the planet (various other distros then switch to a different bootloader after installation.. we don't, why mix in 2 risks into it) I use grub on the installed system, not on the installer boot loader. We support dual boot and we prefer to use grub. :-) if you want to use 2 bootloaders (with the risk of one of them not working) that's up to you. grub 1 isn't actually very nice code . and syslinux supports dual boot as well just fine. ___ 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] Initrd on Kernel to mount root with UUID
On 6/4/2011 3:00 PM, Leonardo Luiz Padovani da Mata wrote: Hello folks, how are you? I'm facing an interesting problem and i think that the solution is simple, but i'd like to discuss it on the list. The MeeGo kernel doesn't use an initrd, to make it faster on boot, i guess. The problem i'm facing is that when i install the system on a netbook with a usb disk the order of the disks change and i have problems booting after the installation. If i change the boot loader information and plug a pen-drive at boot time, the order change again. Using UUID of disks solve the problem, but without a initrd on the kernel the system cannot boot, since UUID mounting is available only with initrd. (also LABEL mounting) We use a custom kernel here and we use grub boot loader, but this problem may happened on other boot loaders. There is one solution to use GUID without initrd: http://www.linux-archive.org/gentoo-user/481167-mounting-root-partition-uuid-no-initrd-needed.html odd; our installer, bootloader and kernel configuration actually should not allow this to happen can you reproduce this with the meego reference set of these ? ___ 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] mssf-crypto and password-based encryption
On 6/1/2011 8:15 PM, Xun Sun wrote: Hi, MeeGo release 1.1.99 (MeeGo) Tablet version We are trying to port a C application to MeeGo of the above version. The application uses a self-grown password-based encryption scheme, where a master key is derived from user password and used for symmetric encryption. If possible, we would like to modify the application to use mssf-crypto library, in particular the secure storage feature. After some initial research, we need some help to understand the following: - Is MSSF framework now fully functional? It looks like that the secure storage feature depends on libsmackman which is not available from the zypper repository. And how do I know if I have the kernel feature required for the framework to work? - Do we have a password-based encryption scheme in mssf-crypto now or in the future? please use the nss (or openssl) libraries for encryption instead. ___ 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] mssf-crypto and password-based encryption
Thanks for your reply. Any comments on the first question - if the MSSF framework is fully functional now? no MSSF has been removed from the OS. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] MeeGo app model in 2012: Rethinking the MeeGo app model to be more platform agnostic
On 5/31/2011 9:12 AM, Tomasz Sterna wrote: On wto 31 maj 2011 11:41:17 CEST, Sander van Grieken san...@outrightsolutions.nl mailto:san...@outrightsolutions.nl wrote: What about a multi-arch RPM approach, where binaries for multiple architectures are contained in a single RPM, but where only the arch specific variant is installed? ***This is possible to do even now by abusing noarch.*** ***Just create a noarch package with binaries for all architectures inside and ln/copy binaries for current arch to correct places in postinst script.*** guys.. this is madness. Android builds your NDK binary multiple times, once for each architecture you choose (x86, armv5, armv7 etc). For MeeGo, the same will be true just we have a way of distributing binaries that's slightly more finegrained than the android model and our output of the build ends up nicely split up, saving download time as well as disk space. nothing to see... lets move on. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] MeeGo app model in 2012: Rethinking the MeeGo app model to be more platform agnostic
On 5/31/2011 9:40 AM, Tomasz Sterna wrote: On wto 31 maj 2011 18:14:56 CEST, Arjan van de Ven ar...@linux.intel.com mailto:ar...@linux.intel.com wrote: just we have a way of distributing binaries that's slightly more finegrained than the android model and our output of the build ends up nicely split up, saving download time as well as disk space. You are missing the original question: How to give developpers a way to create one-size-fits-all package? Zypper repos are great if you have the time and resources to put them up and maintain. If you are for here's a one-time download link for my app, repo is not that great of an idea. actually .. the .repo file is what you offer in that case. ___ 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] about uxlaunch support a command line option with enable/disable xsession-errors feature
On 5/30/2011 1:23 AM, steven wrote: On Mon, 2011-05-30 at 10:15 +0200, Andre Klapper wrote: On Mon, 2011-05-30 at 16:05 +0800, steven wrote: currently when uxlauncher start a new user session, it will redirect stderr/stdout to file xsession-errors, and all x client will write their log messages to this file, and this file will get too big in one power-up cycle Please define too big by providing numbers, and why you think it is actually too big... 400M yikes sounds like some program is hitting a lot of really bad debug messages... .. can you look inside the file to find out which ones need fixing urgently ? ___ 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] How to sync with the network time server in meego?
On 5/30/2011 5:08 AM, steven wrote: Hi, as for NTP, I remember that timed middleware also support NTP, and this middleware is included in meego compliance group, so I think if we want to use NTP time, we should use timed's interface for future compliance. timed is not part of compliance! It's on it's way out, at least the exact usage of it is. connman does all the right things around ntp... it's the component that knows that you have networking, and dhcp tells connman what the time server is.. ___ 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] Top Application in Meego Tablet
On 5/27/2011 5:37 PM, Niels Mayer wrote: On Mon, May 23, 2011 at 7:25 AM, Arjan van de Venar...@linux.intel.com wrote: I'm pretty sure the answer is that the concept of top application outright does not exist. Assuming we're talking the Window System X and its standards, then yes it does exist, and has existed for a long time -- in a standard-bearing form since OSF/Motif and CDE (e.g. XmDIALOG_SYSTEM_MODAL ). Freedesktop.org has updated the original architecture. However, it certainly is a concept that exists in X windows. (how else would always keep window on top be implemented in many desktops, or tool panels, etc). It is concerning to me, after the attending the recent conference, that MeeGo may be adding nonstandard extensions and functionality to the window manager (for video). So it would be nice to understand the official MeeGo position on working within accepted norms of X Windows and X Window Manager Protocols. And if they're being extended, that upstream agrees with the wisdom of the extensions. Having worked with X window managers since the very beginning, (prior having worked on X10 which didn't have the concept of a separate window manager), this is not the sort of thing that should be extended or overloaded in a cavalier fashion, even for a new paradigm like Tablet. I think the short answer is that the concept does not make sense in the UI design, so the hint is ignored. the longer answer is that with the rapid move to Wayland... does it even matter what Motif did? That whole layer is about to be thrown out. ___ 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] Top Application in Meego Tablet
On 5/23/2011 2:30 AM, Vivek Talwar wrote: Hi Rusty, Top Application means the UI Application which stays on top of other applications . We generally do this in Qt by setting windows flag stay on top. So what we have observed in Meego tablet version meego-tablet-ia32-pinetrail-1.2.80.0.20110503.2 the top application is hidden for couple of seconds whenever we make some other application which is not top application. This behavior was not in earlier meego netbook versions. I'm pretty sure the answer is that the concept of top application outright does not exist. There is only one application visible at a time in the design, and the window manager decides which app that is. Some application deciding to want to override that with a top hint... not very nice at all. if MeeGo does not ignore this hint, that'd be a bug... we should just outright ignore it. ___ 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] D-Bus APIs on QML
On 5/15/2011 12:35 PM, Tom Swindell wrote: Hi, Currently, unfortunately, there is no way to integrate with dbus from QML directly. The easiest way is to write a C++ wrapper which exposes your QML friendly methods and handles making the dbus calls. I appreciate that this isn't ideal if you're not a C++ dev and are trying to learn QML only, but there is currently no other way. I would suspect that QML only is not a great start; while QML is great for writing some very basic apps once you want something fancy you very likely end up doing C++ work ___ 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] libmeegotouch in 'MeeGo Core' in 1.3?
On 5/10/2011 1:42 AM, Michael Hasselmann wrote: On Tue, 2011-05-10 at 11:29 +0300, Sakari Poussa wrote: That (Qt5) is a vision with timeline. It's not 10 years, it is 1+ year as you can read from the blog. These are big and complex things which need long cycles to be planned and communicated correctly. That's what we (MeeGo) are doing now. And not saying do MTF apps now and then say year later that use something else. So yes, we need to start the preparation now. Again, nothing has been mentioned in that document that either QWidget or QGraphicsView are or will be deprecated with Qt 5. regardless of that, for MeeGo libmeegotouch is not our preferred way of writing applications, or even a supported one. so cleaning that up is a target anyway. ___ 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] libmeegotouch in 'MeeGo Core' in 1.3?
On 5/10/2011 2:16 AM, Murray Cumming wrote: I hope to see some official acceptance for Maalit in Meego 1.3. After all, it's gotta have a serious input method framework. The libmeegotouch dependency seems to be the only problem so far. But you need to be loud, clear and direct to Nokia that they need to devote time to removing that libmeegotouch dependency from Maalit. Since it was Nokia itself that told us a year ago that libmeegotouch should be designed out... ... I'm pretty sure they know. ___ 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-architecture] MeeGo Compliance, specifically IVI
On 5/7/2011 5:03 AM, Jeremiah Foster wrote: Hello, I'd like to discuss a specific area of compliance for IVI systems. Before I get to the subject matter, I'd like to know if I'm following the correct process so I can address the right people. My first stop was the MeeGo wiki where I searched for Compliance and arrived here: http://wiki.meego.com/Compliance_primer_draft_Feb2011 Is this the current canonical source for compliance in MeeGo? In that document it states Currently MeeGo supports five different verticals: Netbooks, Handsets, Connected-TVs, In-Vehicle Infotainment systems and tablets. Each of these verticals will have a Compliance Profile. I take that to mean that the In-Vehicle Infotainment (IVI) will have a separate compliance specification. Does that mean the IVI compliance specification is independent of the overall MeeGo compliance specification? no IVI is allowed to add required components for an IVI profile, say core automotive libraries, but it cannot subtract. Eg an MeeGo IVI compliant OS is also MeeGo compliant. ___ 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] libmeegotouch in 'MeeGo Core' in 1.3?
On 5/6/2011 8:04 AM, Carsten Munk wrote: Hi, I was surprised to find libmeegotouch in MeeGo Core package group (as a dependancy, I think) for 1.3. Is this intentional and if not, is it fair game to send patches to help reduce dependancies to libmeegotouch in the core system? Examples are xdg-utils - libcontentaction - libmeegotouch for 1.3, libmeegotouch needs to be removed, so yes, any patches to reduce deps on it are very welcome... ___ 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] libmeegotouch in 'MeeGo Core' in 1.3?
On 5/6/2011 12:45 PM, Michael Hasselmann wrote: On Fri, 2011-05-06 at 11:46 -0700, Arjan van de Ven wrote: MTF as a whole got deprecated with less than minimal resources on it... That's not quite what the git logs say. I count 60 commits for this Friday alone. Looks rather well maintained and active to me (also check [0], [1]) Again, what are the concrete technical reasons? I have no problems with the decision itself, as I know that we can adapt to that in MeeGo Input Methods. It's even in our own roadmap [2] for 1.3. And there is a certain value in having less dependencies, of course. But the deprecated argument as such is meaningless and arbitrary. There's nothing technical to it. not all decisions are pure technical in the sense that you mean it. we want ONE api for apps. MTF is not that. QML is that. after that it becomes a maintenance/etc issue, that we do not want to take on. ___ 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] Qt/QML or Meego Touch Framework?
On + Will be developed open soon and is thus completely irrelevant. sorry. too little too late. we're shipping in 2 weeks whatever we do afterwards better be compatible with what we shipped, or we will likely pass on inclusion. ___ 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 compliance and Qt Commercial license
On 5 Hi, I'm a bit confused, so MeeGo compliant OS can only be compliant if it uses the exact packages from MeeGo? So it is not about the API's but about the exact packages? correct, you must use the MeeGo packages and packaging. Of course you can add bugfixes/etc... the tools are there to help you make sure your bugfixes didn't accidentally break things. They're not there to be watertight against breaking the compliance rules by someone who wants to cheat the rules. ___ 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] Qt/QML or Meego Touch Framework?
On 5/2/2011 1:38 AM, kate.alh...@nokia.com wrote: You will have Qt/QML in MeeGo 1.2 but as far as I know, Qt Quick Components did not make et time there. Qt Quick components is UI elements as windows, buttons, dialogs etc made with Qml. that's not correct; look at the meego UX ;) ___ 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] MSSF manifests in RPM
On 5/2/2011 5:39 AM, Alberto Mardegan wrote: Hi all, what is the current state of MSSF manifest files in MeeGo? the current state is that MSSF is not part of, or integrated into, MeeGo... and won't be. ___ 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] Qt/QML or Meego Touch Framework?
On 5/2/2011 1:20 AM, john pratss wrote: Hi, I am developing an application based on Meego-touch-framework. But before starting that I wanted to clarify one thing; whether Meego-1.2 has support for both Qt/QML and MTF based apps or not? In Meego-1.2, what is the approach for developing applications, whether it is should be based on Qt/QML or on MTF ? Definitely QT/QML. The app component MTF is included (somewhat) in 1.2 because the dialer still uses it but for 1.3 it very likely just won't be there anymore. libmeegotouch has been deprecated by its creators (Nokia) for almost a year now ___ 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 compliance and Qt Commercial license
On 5/2/2011 9:56 AM, Attila Csipa wrote: On Monday 02 May 2011 16:50:32 you wrote: the tools are there to help you make sure your bugfixes didn't accidentally break things. They're not there to be watertight against breaking the compliance rules by someone who wants to cheat the rules. One thing though - the original question was if you can *switch* licenses, and that situation is pretty clear. However, is there anything that would prevent you from having two sets of Qt libraries, on one side the stock LGPL ones, and a parallel set of packages, which would be the commercially licensed one (in a separate path, no dependency relations to the LGPL libs, etc), which you could use/customize for whatever you want to do with it within your blend of MeeGo, without affecting compliancy and/or compatibility ? as long as apps that get installed get the system one... and only one app gets yours; but at that point... what's the reason for an OS vendor to do this (an App vendor can install his own library in an own path obviously) ___ 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] Qt 4.8 and QtQuick 1.1
On 5/2/2011 12:59 PM, Ville M. Vainio wrote: On Mon, May 2, 2011 at 9:32 AM, Thiago Marcos P. Santos thiago.san...@intel.com wrote: Latest preview image of MeeGo Tablet relies on Qt 4.7.2. Is there any plans on the roadmap to push Qt 4.8 with QtQuick 1.1 (which might be specially interesting for MeeGo UX Components)? Qt4.7.4 with QtQuick 1.1 would be the more conservative choice. realistically... for MeeGo 1.2 we're at the Qt version that's going to be final, as well as QtQuick... guys we're like 2 weeks away from the release date... not the time to change these components out. ___ 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 compliance and Qt Commercial license
On 5/1/2011 2:11 AM, VanCutsem, Geoffroy wrote: Hi folks, My apologies if this has been discussed in the past already but I’m struggling to get a definite answer to this question: - Can someone switch to the Qt Commercial license [1],[2] and yet pass the MeeGo compliance test? you're not allowed to replace Qt and stay compliant... (you are allowed to add patches that fix bugs and don't change abi of course) if you can get a commercial license on the bits we ship, you could be compliant, but my understanding is that you have to use commercial bits to get the commercial support.. and that would not be ok. ___ 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 compliance and Qt Commercial license
On 5/1/2011 8:58 AM, Thiago Macieira wrote: On Sunday, 1 de May de 2011 08:39:02 Arjan van de Ven wrote: On 5/1/2011 2:11 AM, VanCutsem, Geoffroy wrote: Hi folks, My apologies if this has been discussed in the past already but I’m struggling to get a definite answer to this question: - Can someone switch to the Qt Commercial license [1],[2] and yet pass the MeeGo compliance test? you're not allowed to replace Qt and stay compliant... (you are allowed to add patches that fix bugs and don't change abi of course) But if you replace it with the same Qt... ? nope Or replace it with the same Qt minus the extra patches we ship? The problem are patches like the XInput2 multi-point touch support... nope you can only add patches that fix bugs and don't change interfaces... ___ 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] Fwd: [MeeGo-ivi] Kernel for 1.2
On 4/27/2011 2:34 AM, Jeremiah Foster wrote: On Wed, Apr 27, 2011 at 3:27 AM, Arjan van de Venar...@linux.intel.com wrote: On 4/26/2011 5:54 PM, Nasa wrote: [...] there isn't really *the* ivi kernel. Each platform (as per TSG decision) has the freedom to pick its own kernel version, as long as it is compatible with the reference kernel and as long as security maintenance etc is done on it. So each vertical can have their own little mini distro as long as it is supported? The only requirement seems to be to pull from MeeGo Core. Is this an accurate description or am I missing something? ??? this is specifically about the kernel, and the it must be compatible sounds easier than it is; being compatible with a 2.6.37 kernel if you're older than 2.6.37 is actually a huge task... ___ 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] Fwd: [MeeGo-ivi] Kernel for 1.2
On 4/27/2011 9:47 AM, Niels Mayer wrote: I've noticed that there is no matching kernel-headers for any of the kernels being used: that's fine. the kernel ABI to glibc does not change, and the kernel-headers should really describe the reference ABI there... what makes you think this is a problem ? ___ 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] Fwd: [MeeGo-ivi] Kernel for 1.2
On 4/27/2011 10:07 AM, Gabriel M. Beddingfield wrote: On Wed, 27 Apr 2011, Arjan van de Ven wrote: On 4/27/2011 9:47 AM, Niels Mayer wrote: I've noticed that there is no matching kernel-headers for any of the kernels being used: that's fine. the kernel ABI to glibc does not change, and the kernel-headers should really describe the reference ABI there... what makes you think this is a problem ? So... we can use the 2.6.37 kernel-headers package for building out-of-tree kernel modules for a 2.6.38 adaptation kernel? If no -- then that's the problem. you can never use a kernel-headers package for building kernel modules of any shape or flavor... since these are the headers for glibc, they're not the kernel sources needed for kernel modules. (and never were). ___ 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] Fwd: [MeeGo-ivi] Kernel for 1.2
On 4/26/2011 5:54 PM, Nasa wrote: Hi, Following Kev suggestion... there isn't really *the* ivi kernel. Each platform (as per TSG decision) has the freedom to pick its own kernel version, as long as it is compatible with the reference kernel and as long as security maintenance etc is done on it. for various reasons (some technical, some not), the reference kernel is based on 2.6.37 (even though 2.6.39 will be released before MeeGo 1.2 is). Specific platforms can choose obviously to have a different version; if a platform picks a newer version this is obviously within the compatibility requirement; if it picks an older kernel it'll need to backport any and all critical features that we depend on. ___ 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] Will clutter, mutter be configured to use gles in OBS?
On 4/25/2011 1:24 AM, Zhao, Juan J wrote: Hi there, Is there any plane for clutter or mutter to be configured to use gles here? Would anybody share the experience about this? why would there be a plan for this ??? ___ 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] Will clutter, mutter be configured to use gles in OBS?
On 4/25/2011 7:28 PM, Zhao, Juan J wrote: On Mon, 2011-04-25 at 06:35 -0700, Arjan van de Ven wrote: On 4/25/2011 1:24 AM, Zhao, Juan J wrote: Hi there, Is there any plane for clutter or mutter to be configured to use gles here? Would anybody share the experience about this? why would there be a plan for this ??? For embeded system, gles will show better performance than gl desktop. And there are still some embeded platform choose mutter as its window manager. So I think this window manager should move to gles. pretty much all meego platforms use the Qt/QML stack, with netbook having the core pieces still as legacy... ... don't see the point mucking with the legacy with no upside and only potential downsides ___ 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] X11 between Meego 1.1 and Meego 1.2
On 4/12/2011 11:34 AM, Gabriel M. Beddingfield wrote: On Tue, 12 Apr 2011, Mark S. Townsley wrote: I have an application that ran fine under Meego 1.1 using a netbook. When I switch it over to Meego 1.2, it seg fault. There are some OpenGL code inside my app. For 1.2 MeeGo has switched from OpenGL to GLESv2. this is not a correct statement, sorry. the correct statement is that *QT* has switched to using GLESv2. applications can still use OpenGL all they want... and non-Qt UXes can too. ___ 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] ANNOUNCE: [ABI break] MeeGo 1.2 ARM architecture will only support hardfp ABI
On 4/11/2011 5:28 AM, Juha Kallioinen wrote: Hello, the hardfp floating point ABI for ARM will be made default and mandatory for MeeGo 1.2 and later. This decision was made and approved back in December 2010 in the MeeGo TSG and the impact has been described in MeeGo wiki [1]. The hardfp scheduler is called armv8el and is up and running in MeeGo Trunk. This change introduces an ABI break with MeeGo 1.1. The hardfp ABI is not compatible with the softfp ABI and because of this the packages produced by the armv8el scheduler have the architecture name .armv7hl. They cannot be installed in an armv7l system and vice versa. If you or your company run into problems with this changeover, feel free to seek help from #meego-arm @ freenode IRC channel or from the meego-porting mailing list [2]. can you, for completeness, list a set of ARM SOC's that this hardfp will run on... omap3 tegra? qualcom ? asking because if it's only omap3 then I think this is a step in the wrong direction and we should revisit the TSG decision. ___ 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 tablet on viewpad 10
On 4/6/2011 9:35 AM, Chen Baozi wrote: I got the latest kernel from git and built it locally on the tablet. Luckily, it works. I used to try to adapt Gabriel's patches by rebuilding the srpm. But it seems to be incompatible to build with the srpm offered along with 1.2 version. So I turned to the latest vanilla linux kernel. for those of you struggling with this... do take a look at the kernel-adaptation-pinetrail kernel that I'm working on in devel:kernel; if that works out it should be the kernel we use for all pinetrail based tablets... ___ 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 tablet on viewpad 10
On 4/6/2011 9:53 AM, Gabriel M. Beddingfield wrote: On Wed, 6 Apr 2011, Arjan van de Ven wrote: On 4/6/2011 9:35 AM, Chen Baozi wrote: I got the latest kernel from git and built it locally on the tablet. Luckily, it works. I used to try to adapt Gabriel's patches by rebuilding the srpm. But it seems to be incompatible to build with the srpm offered along with 1.2 version. So I turned to the latest vanilla linux kernel. for those of you struggling with this... do take a look at the kernel-adaptation-pinetrail kernel that I'm working on in devel:kernel; if that works out it should be the kernel we use for all pinetrail based tablets... i.e. a 2.6.38 kernel Is this OK to use for 1.2 and still be MeeGo(tm) ? yes the TSG decided that the kernel version, given a few rules, is up to the adaptation owner. (one of those rules is that you need to be compatible with the reference kernel, eg 2.6.37 for 1.2... but 2.6.38 is compatible with 2.6.37 so going forward is ok) ___ 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] how to run meego-ux's meego-app-camera on MeeGo 1.2 Netbook?
On 4/3/2011 4:27 PM, Niels Mayer wrote: h wonder why you don't run the tablet/etc UX entirely ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
[MeeGo-dev] Another architecture direction mail
Late last year, in the Architecture meeting, we had agreed to include timed, MCE, Sharing Framework, Non-Graphics-Feedback (NGF), Profiles, and Qt style APIs (QmSystem) identified on the http://wiki.meego.com/Architecture as new technologies into MeeGo. We had hoped that all the documentation and source code would end up well integrated into the 1.2 release of MeeGo. Recently we have been evaluating these features and feel that these technologies, as integrated into MeeGo, haven't reached the maturity that we want to commit them into MeeGo 1.2 core. (I realize that one can argue over the status of individual pieces, but several belong together, and some of the problems are that the functionality isn't partitioned right, as seen in the MCE discussions on the mailing list recently) As a result we are proposing to, for MeeGo 1.2, not include these components in the official architecture diagram or the compliance spec since either means a compatibility commitment going forward as well as a requirement for everyone who makes products with the MeeGo brand to include these components. As these things mature going forward, we hope that for MeeGo 1.3 we can put a much more mature policy layer as part of the core architecture and compliance set. NOTE: this does not mean that we are removing the packages, it ONLY means that we aren't requiring these components to be included into each and every product based on MeeGo. If you agree or disagree with our directions above, please feel free to comment... ___ 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] file system partitioning meego 1.2
On 3/31/2011 5:04 AM, sam sam wrote: Hi, I would like to know how the file system will be partitioned in MeeGo 1.2 tablet. I beleive file system will be written into both NAND and eMMC unlike MeeGo 1.1 ? it's up to the person doing the preload image how things get partitioned, but I would be highly surprised if people split the filesystem between raw NAND and eMMC. In fact I would be highly surprised if people would use raw NAND at all, it's not performance or cost effective nowadays. ___ 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] usbmoded?
On 3/31/2011 8:06 AM, Philippe De Swert wrote: HAL can be used too, but that bit is not really nicest and the most flexible code. To be honest it is more a quick hack to get started. (I have re-added support to build with it) And as we all know HAL has been as good as dead since end of 2009... HAL is not part of MeeGo and never was.. so that's a non starter ___ 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-packaging] [meego-commits] 15232 accepted: Trunk:Testing/qmf
On 3/27/2011 1:59 AM, Alberto Mardegan wrote: The biggest problem I can see with these Nokia-maintained packages (MeeGo QMF, AccountsSSO and probably others) is that their development teams are mainly active on the Nokia product-driven developments, and very little time is allocated for the public MeeGo packages. which indeed, for the packages where this is true, is a huge problem. the result is that the state of some of these in MeeGo is very poor... and that leaves/left the architects no choice but to design them out. Luckily, at least for AccountsSSO, this is going to change starting from tomorrow. :-) tomorrow might be too late for several of these however. ___ 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-packaging] [meego-commits] 15232 accepted: Trunk:Testing/qmf
On 3/27/2011 9:27 AM, Alberto Mardegan wrote: Luckily, at least for AccountsSSO, this is going to change starting from tomorrow. :-) tomorrow might be too late for several of these however. I just hope that architectural decisions are being taken according to the current state of a project and the developers' commitment on supporting it, and not according to a project's affiliation to Nokia. absolutely; the current state in MeeGo of these things is leading this. ___ 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-packaging] [meego-commits] 15232 accepted: Trunk:Testing/qmf
On 3/25/2011 2:28 PM, fathi.bou...@nokia.com wrote: Moving the thread to meego-dev. I looked deeper into this QMF promotion. Until now,we (MeeGo) used a modified version that includes libaccount/libsignon integration. this was done properly as the upstream tarbal + patch, right? (if not, this is very obviously an improvement, to at least not use a contaminated tarbal) Since the SR#15232, we're using the upstream QMF version and by extension, dropped the integration. My questions: 1. Is it an architecture team decision? the architecture team normally doesn't pick versions/etc not using libaccount/libsignon would be in the real of the architecture team obviously. will get back on that. 2. Why use an older QMF upstream version? (and introduce epoch) using the latest upstream version would be totally fair game. As to the why the package went away from a contaminated frankenthing to a clean upstream one... that not only sounds like a good idea, it actually is. there were many issues with the frankenpackage, while the upstream one, which is very much better maintained, fixes lots of these. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] Architecture decisions (was Re: migration (back) to EDS)
On 3/25/2011 8:24 AM, Richard Dale wrote: On Friday, March 25, 2011 03:01:43 PM Ville M. Vainio wrote: On Fri, Mar 25, 2011 at 4:53 PM, Richard Dale richard.d...@telefonica.net wrote: On Monday, March 07, 2011 10:06:08 PM Arjan van de Ven wrote: Are you planning to support or implement a QSparql backend for EDS? I suspect we'll never see QSparql in MeeGo the way things are going Disclaimer: I am a QSparql developer QSparql is the standard way of accessing Tracker from Maemo in Qt code, and as far as I know it has been packaged for MeeGo too. In order to build the Qt based RAD environment, that I personally dream of, QSparql will be needed. Is there a particular reason not to have QSparql, when you already have Tracker? I wouldn't have thought there was, but obviously the statement above from Arjan van de Ven concerned me. my concern is based on the (lack of) progress around QSparql in MeeGo. I'm sure it's all great in Harmattan, but a solid story for MeeGo has so far been lacking. Ideally QSparql becomes a real, full and open source member of the Qt family of APIs. (a solid story also includes proper moving away from older APIs) Until that's there color me a bit skeptical... it's been promised for a long time and hasn't really materialized very well yet. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] migration (back) to EDS
On 3/2 Those who need it are messaging-ui, call-history, commhistory-daemon (handling the storage), qt-mobility, qt webruntime, at-phonebook, msgsync. I assumed the dependencies have been checked before announcing the change. Where is this task open and to whom? Is there a bug? What are the other options instead of libcommhistory? the libcommhistory package is not even in any of the images... how can you claim that it's actually this critical? Does the MeeGo dialer even use it? When I spoke with the owner of the dialer app (which is supposedly the key user of all this), this really did not come up as something that is currently in use and working... quite the opposite. (it might work in your maemo OS, but that is of no consideration) architecture decision, and as such, it must have addressed all the basic use cases and consequences _before_ it was made, right? all the cases that we cared about were looked into, risk assessment was made and some detail investigation was scheduled for after the decision for some corner cases that were not deemed critical and where no good current solution was in place. I cannot believe these important dependencies were not considered when the decision was made to move back to EDS... BTW who made the decision (meeting minutes please?), and where is it documented? The MeeGo architecture team made these decisions in consultation with the various handset and tablet architects. I know it's not popular with you and some other @nokia.com folks... but so be it. ___ 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] how to control backligh on handset device
On 3/17/2011 8:24 PM, JK wrote: Hi, I want to add adjust back-light control application on handset device. there is a very nice XBacklight extension. http://cgit.freedesktop.org/xorg/app/xbacklight/ is an example app of on how to use it... ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
[MeeGo-dev] Some architecture changes (MSSF / Buteo / PIM storage)
Hi, given the events of the last few weeks, the MeeGo architects have, and still are, revisiting various parts of the MeeGo architecture. While I'd love to say that we have the whole situation clear, the reality is that there still is a very complex situation. In part because just not everything is clear yet around who and what, and in part because various parts of the MeeGo OS architecture are very tightly coupled... it's not like MIkkado where you can pull out one stick at a time. Having said that, three items are currently clear enough to make a final decision on: 1) MSSF / MeeGo security framework 2) Buteo Sync 3) PIM storage (currently stored in the tracker database) Security === The security direction of MeeGo has been broken up into two different focuses: short-term and long-term.In the short term, we want to complete the development of key portions of the Mobile Simplified Security Framework that allow us to have complete solutions around the areas of Access Control, Integrity and Security Software Distribution.This will not entail *all* of the pieces that have previously been discussed in these areas, but instead will include a minimum subset of features that allow a coherent story across all key security areas. For MeeGo 1.2 specifically, this means that we're not planning on integrating the MSSF pieces that invasive or incomplete at this point, such as the upstart integration that was communicated on this list previously. In the long-term, we will re-evaluate the direction we are taking with MeeGo security with a new focus on *End-User Privacy*. While we do not intend to immediately remove the security enabling technologies we have been including in MeeGo, all security technologies will be re-examined with this new focus in mind.We will revisit technology choices made for MSSF (as well as non-MSSF components that have security implications) and make appropriate changes in these areas given this direction change. Buteo Sync == The Buteo Sync framework in MeeGo is currently very incomplete; various promised and needed components never materialized, and are unlikely to materialize in the future. On the Intel side, we've found that we ended up glueing SyncEvolution into Buteo on a regular basis to fulfill basic customer requirements (like sync-with-google-address-book). Because of this, and the available expertise, we have decided to start replacing Buteo with SyncEvolution. For MeeGo 1.2, it's not currently clear if the engineering work that this entails will be done in time, so 1.2 might still ship with Buteo. However, Buteo is removed as architectural component effective immediately to avoid creating an API/ABI promise for a component that we know is being replaced SyncEvolution is an existing mature open source project with a history of functionality and compatibility, and we're confident that the switch to this project will benefit Sync in MeeGo for years to come. PIM storage === The Address book, Calendar data and Email are currently stored in a tracker database, and accessed (officially) via a QtMobility API set. There are a range of issues with this implementation, starting with the complexity of adding privacy controls, the performance and scalability as well as the completeness for doing a proper syncml sync. Because of all these items and the available expertise, we have decided to start replacing PIM storage with the Evolution Data Server. This change will land together with the SyncEvolution change (due to the intimate relationship between the storage and sync of PIM data). This change should largely be invisible to applications since applications are supposed to access this data via the appropriate QtMobility APIs. But to avoid setting precedents, the lower level components will be removed from the architecture diagrams effective immediately. To be clear, this does not mean that tracker is completely removed; tracker is still being used (together with tumbler) for indexing media on the device. At this point we are seeing serious issues (performance/stability) with this solution, but the first attempt will be to fix the deficiencies rather than a replacement. ___ 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-architecture] Some architecture changes (MSSF / Buteo / PIM storage)
On 3/7/2011 8:51 AM, Carsten Munk wrote:In the long-term, we will re-evaluate the direction we are taking with MeeGo security with a new focus on *End-User Privacy*. While we do not intend to immediately remove the security enabling technologies we have been including in MeeGo, all security technologies will be re-examined with this new focus in mind.We will revisit technology choices made for MSSF (as well as non-MSSF components that have security implications) and make appropriate changes in these areas given this direction change. One thought that popped into my mind: In MeeGo Smart TV there would probably be a focus that's different from End-User privacy, with regards to stream protection (which is a market requirements these days, sadly?) and in IVI where there would be regulatory problems. Does this fit well with end-user privacy goal? Most modern SOCs and the like have a complete Hardware pipeline for the protected content, this is doubly true in the TV space. (not just for DRM... for playing back two 1080p concurrently, you HAVE to have all that stuff in hardware, you don't want the CPU involved on a box that by and large does that stuff 99%+ of the time. The CPU is just there for the pretty TV guide ;-) It's also more or less true for phone silicon; at least the parts that I have visibility into (Intel). There the argument is not just DRM (again) but also power efficiency; for playing back movies, having a hardware pipeline just makes the most sense power wise. DRM works there almost as an accident as well (it's of course designed in from the start.. but even without DRM it would mostly be the same pipeline) To be clear, this does not mean that tracker is completely removed; tracker is still being used (together with tumbler) for indexing media on the device. At this point we are seeing serious issues (performance/stability) with this solution, but the first attempt will be to fix the deficiencies rather than a replacement. Ironically with performance, at least in terms of startup, this may be partly caused by BMC#1, https://bugs.meego.com/show_bug.cgi?id=1 - which starts scanning instantly at startup, probably trashing initial performance. we start after 2 minutes... but still. there's a lot of impact from this currently, both in terms of just raw CPU cycles to power impact to stability (we're seeing quite some crashes, which worries me from a security pov) ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] Some architecture changes (MSSF / Buteo / PIM storage)
On 3/7/2011 1:40 PM, Philip Van Hoof wrote: Because of all these items and the available expertise, we have decided to start replacing PIM storage with the Evolution Data Server. Ah, I see. good This change will land together with the SyncEvolution change (due to the intimate relationship between the storage and sync of PIM data). This change should largely be invisible to applications since applications are supposed to access this data via the appropriate QtMobility APIs. That's not entirely true. Many applications are nowadays accessing said data through the QSparql API of Harmattan. QtMobility isn't always the ideal access-layer. Especially not for more complex use-cases. MeeGo isn't Harmattan. Harmattan isn't MeeGo. (It's Maemo) I couldn't care less if Harmattan / Apps do or don't so something; that has nothing to do with MeeGo. Are you planning to support or implement a QSparql backend for EDS? I suspect we'll never see QSparql in MeeGo the way things are going ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] Some architecture changes (MSSF / Buteo / PIM storage)
On 3/7/2011 2:31 PM, Adrien Bustany wrote: Synchronization is a solved problem, mind you, our mail for exchange plugin does a pretty good job at saving contacts in a slow way. Using APIs the right way, it could sync 500 contacts in 80 seconds, as mentioned above. can you point at the source code in MeeGo where this mail for exchange plugin lives? (or anywhere for that matter). Oh and my exchange contact database contains between 80k and 120k people. that'll take a while. you seem to be proud of 80 seconds for 500 people I would absolutely not be proud about such a abysmal number. message of this thread. To me it sounds like the Intel architects decided that MeeGo will be that way. I don't exactly how this kind of decision is supposed to be taken, and while I understand you can't ask everybody's opinion for all decisions, I see little transparency there. Hopefully somebody will enlighten me! I also hope in the future MeeGo architects will ask the right people when they have questions on a software piece. We'll make sure to ask the people whom we can be sure of that they have a commitment or charter to support MeeGo so that MeeGo can succeed. I am really not interested in discussing hypothetical of what could have been. I've had more than my share of that kind of discussion in the last year+. At this point I'm more interested in getting something to work with technology and people that work on MeeGo to make MeeGo succeed. I'm sorry that your technology did not win. Actually, I'll take that back. I'm not sorry. Your technology did not win this round. It won the last round and then NOTHING good got put into MeeGo. If you really want to try to sell the same thing again, sorry, too little too late. I have a really hard time feeling sympathy for this. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] Some architecture changes (MSSF / Buteo / PIM storage)
On 3/7/2011 3:33 PM, zoltan@nokia.com wrote: Let's define what we want, create a Meego-standardized test bench, make we can do many things that delay MeeGo moving forward. We're not going to do that. Time has come and gone for this to be a discussion; this is a decision. ___ 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] Announcing MeeGo 1.2 Developer Edition for N900
On 3/3/2011 8:15 AM, jukka.ekl...@nokia.com wrote: Hi, does this include Nokia open sourcing the pieces they previously committed to open source (including policy etc) and the pieces that are essential for running the N900 ? I'm going to let our architecture fellows to comment on that one specifically, but the principle is to do everything in the open that is possible. I would like to urge you to push on this; we've been bitten rather badly in MeeGo in the past in this respect (promising of features as part of architecture choices, but then never getting those open sourced), and I'm sure that you, as the lead of this new project, can fix a bunch of these; after all it sounds like you're serious about MeeGo. ___ 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] Should I use MeeGo Touch Framework or Qt Framework for MeeGo tablets
On 3/2/2011 4:52 AM, Gabriel M. Beddingfield wrote: On Wednesday, March 02, 2011 01:51:51 am Ville M. Vainio wrote: On Wed, Mar 2, 2011 at 1:13 AM, Gabriel M. Beddingfield gabrb...@gmail.com wrote: On Tue, 1 Mar 2011, Victor Vu wrote: Is MeeGo Touch Framework here to stay? Yes. Is this based on some new information that hasn't been shared elsewhere? MTF is widely understood to be deprecated for third party use. The OP's question didn't specifically ask about 3rd party use. However, if you read the rest of my e-mail... I *did* add a very strong indication that it's deprected for 3rd party use. yeah don't use MTF in your own applications. However, the MTF includes things like mcompositor, mdecorator, duicontrolpanel, etc... We're stuck with mcompositor for now, but many of these other items are very aggressively being worked on in terms of removing them as soon as possible (some even for 1.2) ___ 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] Are there applications in meego netbook use tracker as metadata backend?
On 2/27/2011 11:37 PM, Zhou, Ting Z wrote: Hello: Are there applications in meego netbook use tracker as metadata backend? As I know, in meego netbook, the music and video player banshee doesn't need tracker, the image viewer - eye of gnome also has no dependency on tracker. Tracker daemons will consume some resources to extract and store metadata. If no applications in netbook use tracker, could we make tracker not installed in netbook by default, or make tracker daemons not auto start? tracker is *THE* meego store for these things currently. Unfortunately not all the legacy netbook applications use this correctly yet; that needs to get fixed. (and yes, tracker and tumbler are pretty heavy animals that are in dire need of optimization) ___ 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 co-exist with Windows
On 2/24/2011 5:16 PM, Praveen Gupta wrote: Hi, Can Meego co-exist with Windows on hard-disk during installation? I installed Meego on a netbook which has windows installed… After installation, Meego boots automatically even though I assigned windows as default boot option. How do I resolve this ? hi, this is more a usage question than a development question. you're much better off using our forums for that ___ 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] kernel_panic on on mrst-mtf image
On 2/21/2011 5:05 AM, praveen pandey wrote: Hi, I am using http://repo.meego.com/MeeGo/builds/1.1.90/1.1.90.2.20110208.4/handset/images/meego-handset-ia32-mrst-mtf/ image on moorsetown Hardware but I am not able to boot. I have attached the logs here. somewhere in the call trace it points to intel_sst. you're going to need to provide a lot more detail for us to be able to help you. Also, our mrst kernel is for a very specific mrst device, and likely not yours... what kind of device are you using ___ 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] Fail to run the Phoronix qgears2 test suit for 3D benchmark.
On 2/21/2011 6:05 PM, jms yang wrote: hi There Just verified that the Phoronix test suit qgears with OpenGL rendering is capable to test on Acer AspireOne with pinetrail image(e.g. MeeGo release 1.1.90 (MeeGo) BUILD: meego-tablet-ia32-pinetrail-1.1.90.2.20110207.22) smoothly. Is there any one successfully test openGL OKAY on MRST/Medfield/Octrail platform? sounds like you need to file a (serious) bug ___ 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] Upstart in MeeGo 1.2
On 2/17/2011 1:08 AM, Carsten Munk wrote: 2011/2/17 Tapio Rantalaext-tapio.rant...@nokia.com: pe, 2011-01-07 kello 16:11 +0200, ext Tapio Rantala kirjoitti: Hi all! We are preparing upstart so that it would be integrated in meego 1.2 and therefore replace sysvinit as init provider. Hi Due to recent events work on this has been stopped and meego can continue to use sysvinitfastinit. This one is for architects: is the systemd switch in 1.3 still planned? yes, absolutely. ___ 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] glibc vs. eglibc
On 2/15/2011 8:57 AM, Jeremiah Foster wrote: None of the replies answers the question, which I'll repeat; is there a reason why MeeGo uses one and not the other? yes. we use the real glibc that most folks are using the eglibc team is relative new with little track record (this is nothing against them, it's just reality) and on the flip side eglibc doesn't really have real advantages in the MeeGo context. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] glibc vs. eglibc
On 2/15/2011 10:11 AM, Syed Faisal Akber wrote: Jeremiah, There are a number of libc alternatives out there for embedded systems. They include: uC-libc - http://www.uClinux.org/ uClibc - http://www.uclibc.org/ newlib - http://www.sourceware.org/newlib/ There are more that I'm not including here. The benefit of using GLIBC is that many Linux apps are written to work with it. Also, most of the apps in MeeGo are the same. Why we are using the RedHat version instead of the original GNU version, I don't know. (http://www.gnu.org/s/libc/) we are not using the Red Hat version. we are using the GNU version. eglibc.org is NOT the GNU version. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
[MeeGo-dev] Evicting someone from the meego mailing lists (was Re: Buyout of Nokia)
On 2/13/2011 1:12 PM, Randolph Dohm didn't we warn you several times before that what you are doing is offtopic and rude for meego-dev ? Your post, again and as usual, has nothing to do with anything technical or development related. Administrators, please consider banning this Randolph Dohm personality from the email lists permanently, or at least for a year. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] BME (Battery Management Entity) on MeeGo
On 2/9/2011 3:30 AM, Rémi Denis-Courmont wrote: On Saturday 29 January 2011 10:42:28 ext Carsten Munk, you wrote: 2011/1/29 Lego Minglegom...@gmail.com: Hi all, We want to study the Battery Management Mechanism on MeeGo Handset. The battery management mechanism on MeeGo handset is up to the individual hardware adaptation. You're likely to have to implement that yourself depending on your hardware. Shouldn't the values be readable with the standard power_supply device class in Linux sysfs at least? absolutely and the layer on top of that is upower which provides a dbus interface to this information. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] updated MeeGo compliance spec available for review
On 2/7/2011 4:41 AM, Antti Kaijanmäki wrote: On Fri, 2011-02-04 at 08:43 -0700, Wichmann, Mats D wrote: Hoping some of you have time to take a look and supply comments... http://wiki.meego.com/Quality/Compliance, as usual. current version is the .7 revision. Section 3: Application Compatibility I assume this section talks about 3rd party applications like the ones you go and buy from Ovi-store, right? Could you please add a clause to clarify that system integration and vendor software (components in section 2) are not required to follow this scheme. A component might still be an application, like some applet or UX related software, and this might cause some confusion without the clause. well yes... it applies to both there is just no requirement that the components that you ship on a device must all be compliant. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] updated MeeGo compliance spec available for review
On 2/7/2011 9:03 AM, Gabriel M. Beddingfield wrote: On Mon, 7 Feb 2011, Sergio Schvezov wrote: Suppose that your app needs 3rd party libs and you install them in the folder /opt/foo/lib. Before you start your app, you can manipulate the LD_LIBRARY_PATH to pull in your lib folder. [snip] So imagine the case of openssl, you provide it as it is not Meego Core, it's linked to a specific version. Meego provides a different one, you an't link to it in theory as it is not a core lib. In this example you then bring in Qt to your application which does a dlopen on it's openssl. This basically crashes your app. What a mess! I hadn't thought of that. My point being, some libs just probably shouldn't be allowed even in an LD_LIBRARY_PATH. I.e. We refuse to supply openssl as part of MeeGo core, but you can't use openssl as your own private library because QtNetwork is covertly loading it with dlopen(). That's nuts. I'm pretty sure openssl is part of the actual compliance package list (which is core + dependencies, not just core') ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] updated MeeGo compliance spec available for review
On 2/7/2011 10:0st core') If you compile your app against libssl in Meego 1.1 it will link against libssl.so.8, when you go to Meego 1.1.90-1.2 your app won't load as libssl.so.10 is there. If you symlink it may work, but you can never know as that's why the version changed in the first place. Same applies for libcrypto. if we break ABI between 1.1 and 1.2 we, MeeGo, fscked up and must provide a compatibility package. doesn't matter if this was only a dependency or not. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] updated MeeGo compliance spec available for review
On 2/4/2011 12:10 PM, Antti Kaijanmäki wrote: On Fri, 2011-02-04 at 14:32 -0500, Bernd Stramm wrote: On Fri, 04 Feb 2011 21:21:04 +0200 Kernels have supported IPv6 for years, unless they are specifically configured not to. Yes, but sadly there are products where kernels are specifically configured not to have IPv6. By stating it's mandatory we can prevent that happening on MeeGo. It would be nice if key core applications would also support it. :Like ConnMan for example. Currently the ConnMan applet blissfully ignores IPv6 even if you are connected: https://bugs.meego.com/show_bug.cgi?id=10878 IMO any component which does not support IPv6 fully must have bugs opened against them with High priority. this would be a great idea for the 1.2 compliance spec to add imo. (but this doc is still the old 1.1 compliance) ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] gstreamer vaapi support on meego
On 2/2/2011 4:07 AM, navin karnam wrote: Hi All, Whether Meego 1.1 official release supports video playback using the vaapi elements of the gstreamer (vaapidecode or vaapisink) on Intel moorestown platform? Do we need to upgrade the libva or patch graphics drivers to get for the vaapi elements support? MeeGo 1.1 as a whole does not support Moorestown very well. if you are working on a Moorestown design, it is very unlikely to be a good OS to base things on. 1.2 is looking much healthier in this regard already ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Broadcom WL on MeeGo Netbook 1.1.90.0.20110125
On 2/2/2011 6:43 AM, Glen Gray wrote: or we all spend time making the opensource BCM driver work on 2.6.37 this sounds like a really good idea regardless of anything else. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Libva support on meego 1.1
On 2/1/2011 6:03 AM, john pratss wrote: Hi, I have tried a gstreamer pipeline to play a video, pipeline freezes while libva is trying to open the pvr graphics driver, so could not able play the video. The pipeline is run on the mego 1.1 official release on a Intel moorestown platform. yikes... Moorestown support in 1.1 was experimental at best. Please let me know whether libva in 1.1 release supports video playback. you need more than just libva; you need all the hardware specific pieces and codecs to go with it. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
