Re: [MeeGo-dev] Icon not visible on Meego Tablet
On 07/08/2011 01:12 PM, Topi Santakivi wrote: Hi, 2011/7/8 Ville Vainio vivai...@gmail.com mailto:vivai...@gmail.com Tablet UX does not work with icons in compliant locations. Check where the icons for built in apps are placed and put yours there too. Altazin, Alexis alexis.alta...@intel.com mailto:alexis.alta...@intel.com wrote: Hi I'm deploying an app in Meego 1.2 Tablet . The app runs fine but I cannot get the icon visible on the app grid or the Top Applications panel. The .desktop is read and recognized as the app name does appear on the app grid, and the app runs when I touch on the space above the name. I provide 4 PNG icons (16, 32, 64, 128) with the same name, that are copied in /usr/share/icons/hicolor/16 .../32 .../64 .../128 . I also tried copying the 32x32 version in /usr/share/pixmaps/ - no luck. any clues ? Alexis At least with ExoPC MeeGo Tablet UX, the path is /usr/share/themes/1024-600-10/icons/launchers BR, Topi Hi, Is there a bug about this as it sounds very wrong if applications need to install icons to all the different theme dirs. Regards, Marko ___ 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] Changes to uxlaunch in Trunk: configuration will need changes.
On 06/20/2011 07:30 AM, Kok, Auke-jan H wrote: What changed exactly? Well, the biggest change is that there is no hardcoded session table anymore, and so now each session needs to be defined in a session definition file instead. That means that instead of telling uxlaunch start /usr/bin/mutter --sm-disable, you'll now tell it to 'start the x-meego-nb' session, and something will instruct uxlaunch that that implies 'mutter' etc. Sounds good. Also, the new code allows the USER to entirely override this and create their own session definition, and completely different than what the main system defines as default. Yes, that's right, you can change your own desktop without root permissions. Will the user who's home is read be still determined by entry in /etc/sysconfig/uxlaunch? This is done through generic xsession desktop files. A lot of DE's already ship them (xfce, xbmc, even gnome) and so we're reusing this mechanism for maximum flexibility. Session files are named 'foo.desktop' and list an Exec= key that will be started as the session process. The 'foo' part is assumed to define the 'session name'. This allows uxlaunch to hide applications through the OnlyShowIn and NotShowIn fields as it did before. Currently uxlaunch has the xopts in the /etc/sysconfig/uxlaunch, could this be moved to the UX .desktop file as well or even better could we provide Xorg parameters as dynamic files in some directory as on touch devices you don't want to see mouse cursor and netbooks you want, something that is also more hardware thing. So information that hardware adaptation pattern/package group might contain. Currently there is following hack in .ks files https://meego.gitorious.org/meego-os-base/image-configurations/blobs/master/custom/scripts/uxlaunch-nocursor.post The impact for most people will be nil, except two groups: Release engineering people who make images: You'll have to rewrite the kickstart files and uxlaunch configs. - The appropriate UX package needs to install a /usr/share/xsessions/sessionname.desktop file The sessionname should be consistent with MeeGo's naming convention: acceptable are x-meego-nb, x-meego-hs, x-meego-tb, x-meego-tv, x-meego-ivi, others need to be discussed first as there is an impact on all packages if you make something up, and your UX might not work properly. (autostart files will be filtered case-insensitive). This is probably something that the UX specific pattern/package group should provide. - Selecting a default session is done through symlinking in the kickstart file: The %post section needs to execute a line like this: ln -sf x-meego-nb.desktop /usr/share/applications/default.desktop This symlink *must never* be part of an installed package. Maybe a patch for mic2? Currently there are following lines in .ks file that do some magics in this area: xconfig --startxonboot desktop --autologinuser=meego --defaultdesktop=DUI --session=/usr/bin/mcompositor Regards, Marko ___ 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] sdk 1.2+N900 DE
On 05/07/2011 03:32 PM, jukka.ekl...@nokia.com wrote: Hi, Hi, is possible to use this SDK http://wiki.meego.com/SDK/Docs/1.2/Installing_and_configuring_MeeGo_S DK_for_Linux to develop with this http://wiki.meego.com/ARM/N900/DeveloperEdition? N. It should be possible of course. Please let us know if you run into problems. Hi, it is possible but requires some extra work, as all parts are not in the right places yet for armv7hl architecture. Here is how I got it working (written from memory so might be missing something): Device: 1. Install mad-developer package Host: 1. Install meego-sdk-armv7l package (yes, for the softfp) 2. Install the meego-1.2-sdk-armv7hl-toolchain package 3. Get the madde-configuration for armv7hl from http://meego.gitorious.org/meego-developer-tools/madde-configurations/blobs/master/madde.conf.d/meego-handset-armv7hl-trunk.conf and put it to the /usr/lib/madde/linux-i686/cache/madde.conf.d/ dir 4. sudo mad-admin create -f meego-handset-armv7hl-trunk 5. Follow the armv7l guide.. Repos used for HOST (NOTE: These are experimental devel repos, use with care.): http://download.meego.com/live/devel:/tools:/sdk:/host:/toolchain:/MeeGo:/1.2/ http://download.meego.com/live/devel:/tools:/sdk:/host/ Regards, Marko ___ 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 05/01/2011 07:00 PM, Arjan van de Ven wrote: 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... 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? Just a theoretical questions, if one would get packages from fedora/opensuse or any other distribution and create an image that would pass the MeeGo Compliance tools test set would that image be compliant? http://wiki.meego.com/Quality/ComplianceTools Regards, Marko ___ 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-qa] Faild to build image for armv7hl with latest mic
Hi, the problem in here is that you are not using bootstrap mode. armv7hl architecture is not supported by your host distribution tools and thus you can't use legacy mode to build armv7hl image. So add --run-mode=1 to the cmdline and you should be fine. Also should be noted that to build armv7hl image properly you need to have qemu 0.13 or newer. Regards, Marko On 04/12/2011 06:10 AM, WuYongbo wrote: *OS:* FC 13 *MIC* version: 0.24.8 *Cmdline:* mic-image-creator --arch=armv7hl --pkgmgr=yum --format=raw --save-kernel --package=tar.gz --config=meego-handset-armv7hl-n900-1.1.99.1.20110406.102.ks *run-mode* = 0 (legacy) *Error: failed to create image : Invalid target arch: armv7hl* * * I deep into /usr/bin/mic-image-creator and find in run-mode 0, arch armv7hl is supported. * * *logs:* MIC2 version: 0.24.8 [main] use_comps=1 outdir=. tmpdir=/var/tmp run_mode=0 Local linux distribution: Fedora release 13 (Goddard) Fedora release 13 (Goddard) Fedora release 13 (Goddard) Fedora release 13 (Goddard) Kernel \r on an \m (\l) Local Kernel version: 2.6.34.7-66.fc13.i686.PAE Run mode: legacy Using /var/tmp as tmpdir. Using /var/tmp/cache as cache directory. Using /home/Domain_Users/yuzheng as output directory. Retrieving http://download.meego.com/snapshots/1.1.99.1.20110406.102/repos/oss/armv7hl/packages//repodata/repomd.xml ...OK Retrieving http://download.meego.com/snapshots/1.1.99.1.20110406.102/repos/oss/armv7hl/packages//repodata/b7c7cff692e5ad8c5eb2fbaa9dedeeb1b80d34d88e041142b40720ffd3a470b9-primary.sqlite.bz2 ...OK Retrieving http://download.meego.com/snapshots/1.1.99.1.20110406.102/repos/oss/armv7hl/packages//repodata/72f8a3984159e43309b0254a4b26d8a33a76b69c8c1b6209dc403d27874d4098-patterns.xml.gz ...OK Retrieving http://download.meego.com/snapshots/1.1.99.1.20110406.102/repos/oss/armv7hl/packages//repodata/cdc92f9c36226053c85deeeb5d05f170ad487bddd42f88e3ebb1309e805482e6-group.xml.gz ...OK Retrieving http://download.meego.com/snapshots/1.1.99.1.20110406.102/repos/oss/armv7hl/packages//repodata/repomd.xml.key ...OK Retrieving http://download.meego.com/snapshots/1.1.99.1.20110406.102/repos/non-oss/armv7hl/packages//repodata/repomd.xml ...OK Retrieving http://download.meego.com/snapshots/1.1.99.1.20110406.102/repos/non-oss/armv7hl/packages//repodata/8b100fc1982d634506b5cd670bee62de67d12fe576ffa99d3106cedd6c7b4d3f-primary.sqlite.bz2 ...OK Retrieving http://download.meego.com/snapshots/1.1.99.1.20110406.102/repos/non-oss/armv7hl/packages//repodata/repomd.xml.key ...OK Retrieving http://download.meego.com/snapshots/1.1.99.1.20110406.102/repos/oss/armv7hl/packages//noarch/meego-release-1.1.90-1.1.noarch.rpm ...OK Available target architectures in repositories: [u'armv7hl'] MeeGo release 1.1.90 meego-handset-armv7hl-n900-1.1.99.1.20110406.102-1.1.90.20110412.1050 Target arch: armv7hl Registering package manager: zypp Registering package manager: yum = WARNING = vdso is enabled on your host, which might cause problems with arm emulations. You can disable vdso with following command before starting image build: echo 0 | sudo tee /proc/sys/vm/vdso_enabled = WARNING = Use package manager yum Loading dm_snapshot... Filesystem label= OS type: Linux Block size=4096 (log=2) Fragment size=4096 (log=2) Stride=0 blocks, Stripe width=0 blocks 112000 inodes, 447999 blocks 4479 blocks (1.00%) reserved for the super user First data block=0 Maximum filesystem blocks=461373440 14 block groups 32768 blocks per group, 32768 fragments per group 8000 inodes per group Superblock backups stored on blocks: 32768, 98304, 163840, 229376, 294912 Writing inode tables: 0/14 1/14 2/14 3/14 4/14 5/14 6/14 7/14 8/14 9/14 10/14 11/14 12/14 13/14 done Creating journal (8192 blocks): done Writing superblocks and filesystem accounting information: done This filesystem will be automatically checked every 27 mounts or 180 days, whichever comes first. Use tune2fs -c or -i to override. tune2fs 1.41.10 (10-Feb-2009) Setting maximal mount count to -1 Setting interval between checks to 0 seconds mkfs.vfat 3.0.9 (31 Jan 2010) unable to get drive geometry, using default 255/63 mkswap: /dev/loop02: warning: don't erase bootbits sectors on whole disk. Use -f to force. Setting up swapspace version 1, size = 8188 KiB no label, UUID=65848fe9-c1d5-48c3-a6d6-0c290a04b1e8 /usr/sbin/setenforce: SELinux is disabled * * *Error: failed to create image : Invalid target arch: armv7hl* -- Good luck ! ___ MeeGo-qa mailing list meego...@lists.meego.com http://lists.meego.com/listinfo/meego-qa ___ 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-qa] Faild to build image for armv7hl with latest mic
Hi, You should not have any segfaults during the image builds. Two things come to my mind: First that your qemu-arm-static version is 0.13 or newer. If not you can get 0.13 version for your distribution most probably from http://repo.meego.com/MeeGo/tools/repos/ Second should try if executing following will make any difference with the segfaults: echo 0 | sudo tee /proc/sys/vm/vdso_enabled It is in the mic log separated with = WARNING = texts. Regards, Marko On 04/12/2011 10:50 AM, WuYongbo wrote: Changing to bootstrap mode, it works !!! although with some unusual log when installing package, like: Installing: shared-mime-info # [180/616]/var/tmp/rpm-tmp.JaHIPV: line 3: 25504 Segmentation fault (core dumped) /usr/bin/update-mime-database /usr/share/mime /dev/null Installing: PackageKit # [507/616]/var/tmp/rpm-tmp.skk0Br: line 1: 25874 Segmentation fault (core dumped) update-mime-database /usr/share/mime /dev/null I am not sure whether this has any effort on using image ? Also, actually I tried bootstrap mode this morning, it failed with error: failed to find /var/cache/meego-bootstrap//parentroot. 在 2011年4月12日 下午2:44，Marko Saukko marko.sau...@cybercom.com mailto:marko.sau...@cybercom.com写道： Hi, the problem in here is that you are not using bootstrap mode. armv7hl architecture is not supported by your host distribution tools and thus you can't use legacy mode to build armv7hl image. So add --run-mode=1 to the cmdline and you should be fine. Also should be noted that to build armv7hl image properly you need to have qemu 0.13 or newer. Regards, Marko On 04/12/2011 06:10 AM, WuYongbo wrote: *OS:* FC 13 *MIC* version: 0.24.8 *Cmdline:* mic-image-creator --arch=armv7hl --pkgmgr=yum --format=raw --save-kernel --package=tar.gz --config=meego-handset-armv7hl-n900-1.1.99.1.20110406.102.ks *run-mode* = 0 (legacy) *Error: failed to create image : Invalid target arch: armv7hl* * * I deep into /usr/bin/mic-image-creator and find in run-mode 0, arch armv7hl is supported. * * *logs:* MIC2 version: 0.24.8 [main] use_comps=1 outdir=. tmpdir=/var/tmp run_mode=0 Local linux distribution: Fedora release 13 (Goddard) Fedora release 13 (Goddard) Fedora release 13 (Goddard) Fedora release 13 (Goddard) Kernel \r on an \m (\l) Local Kernel version: 2.6.34.7-66.fc13.i686.PAE Run mode: legacy Using /var/tmp as tmpdir. Using /var/tmp/cache as cache directory. Using /home/Domain_Users/yuzheng as output directory. Retrieving http://download.meego.com/snapshots/1.1.99.1.20110406.102/repos/oss/armv7hl/packages//repodata/repomd.xml ...OK Retrieving http://download.meego.com/snapshots/1.1.99.1.20110406.102/repos/oss/armv7hl/packages//repodata/b7c7cff692e5ad8c5eb2fbaa9dedeeb1b80d34d88e041142b40720ffd3a470b9-primary.sqlite.bz2 ...OK Retrieving http://download.meego.com/snapshots/1.1.99.1.20110406.102/repos/oss/armv7hl/packages//repodata/72f8a3984159e43309b0254a4b26d8a33a76b69c8c1b6209dc403d27874d4098-patterns.xml.gz ...OK Retrieving http://download.meego.com/snapshots/1.1.99.1.20110406.102/repos/oss/armv7hl/packages//repodata/cdc92f9c36226053c85deeeb5d05f170ad487bddd42f88e3ebb1309e805482e6-group.xml.gz ...OK Retrieving http://download.meego.com/snapshots/1.1.99.1.20110406.102/repos/oss/armv7hl/packages//repodata/repomd.xml.key ...OK Retrieving http://download.meego.com/snapshots/1.1.99.1.20110406.102/repos/non-oss/armv7hl/packages//repodata/repomd.xml ...OK Retrieving http://download.meego.com/snapshots/1.1.99.1.20110406.102/repos/non-oss/armv7hl/packages//repodata/8b100fc1982d634506b5cd670bee62de67d12fe576ffa99d3106cedd6c7b4d3f-primary.sqlite.bz2 ...OK Retrieving http://download.meego.com/snapshots/1.1.99.1.20110406.102/repos/non-oss/armv7hl/packages//repodata/repomd.xml.key ...OK Retrieving http://download.meego.com/snapshots/1.1.99.1.20110406.102/repos/oss/armv7hl/packages//noarch/meego-release-1.1.90-1.1.noarch.rpm ...OK Available target architectures in repositories: [u'armv7hl'] MeeGo release 1.1.90 meego-handset-armv7hl-n900-1.1.99.1.20110406.102-1.1.90.20110412.1050 Target arch: armv7hl Registering package manager: zypp Registering package manager: yum = WARNING = vdso is enabled on your host, which might cause problems with arm emulations. You can disable vdso with following command before starting image build: echo 0 | sudo tee /proc/sys/vm/vdso_enabled = WARNING = Use
Re: [MeeGo-dev] FW: execute MTF application by command line error
Hi, Did you export DISPLAY=:0 and are you running the app as normal user and not root? Also it might be that you need to export DBUS variables to the environment, see bug: https://bugs.meego.com/show_bug.cgi?id=9049 Regards, Marko On 04/11/2011 10:57 AM, Pai, Cary wrote: Hi, I have a simple MTF application, I want to get the error message from this application, so I want to launch the application from command line, and I can easily get the error message from command line, but after I launch the MTF application, I get error message about : “ERROR : No DBUS session bus found, Exiting now. Please make sure that a dbus session bus is running…….”, BTW if I launch the application by the desktop ICON(create the desktop icon by myself), it can be run successfully. My environment is: 1.ExoPC 2.MeeGo pre-alpha version 1.2 Best Regards. Intel Software Service Group cid:image001.jpg@01C92560.37C6BFB0 B1 #205 Tun-Hwa North Rd, Taipei, Taiwan Desk +886-2-2514-4603 Mobile +886-987-369-617 E-Mail cary@intel.com mailto:gorden.n...@intel.com ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines ___ MeeGo-dev 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 04/11/2011 03:28 PM, 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]. If you need to use closed source binaries from your hardware vendor, please contact them to get a hardfp build of those binaries. The softfp armv7el scheduler in MeeGo Trunk will be stopped at the end of April 2011. [1] http://wiki.meego.com/SDK/Toolchains/ToolchainChange [2] http://lists.meego.com/listinfo/meego-porting Cheers, Juha ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines Hi, Now when the armv7el is going to be removed it is important that maintainers of devel: projects in the OBS add the armv8el scheduler to their projects. http://lists.meego.com/pipermail/meego-packaging/2011-April/247051.html Regards, Marko ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
[MeeGo-dev] pulseaudio-modules-[n900|mdfl] why two different forks?
Hi, I'm wondering what is the actual reason to do separate forks of pulseaudio-modules-meego. Originally it seems that reason for the separate forks is that different cmtspeech implementations were needed for n900 and mdfl, but is there more into this? Could the rest of these modules be maintained under same package (common, music, voice, record, mainvolume etc.) and only fork the cmtspeech module two separate packages? Is there currently duplicated work done that could benefit all the MeeGo architectures and verticals in general? The sources for these packages are in following gitorious trees: http://meego.gitorious.org/maemo-multimedia/pulseaudio-modules-meego http://meego.gitorious.org/meego-middleware/pulseaudio-modules-mfld I raise this because there seems to be ongoing pulseaudio 0.9.22 development and that repository has only fixes for the mdfl package and in the end most of the same patches will be needed for the n900 side as well. Regards, Marko ___ 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 04/04/2011 02:33 AM, Arjan van de Ven wrote: 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 Shouldn't meegoapps work on all the MeeGo based machines independent from the UX? I can understand that graphics/themes can need a bit work but in general those should work on other UX's as well, right? Comparison Gnome vs KDE app on my laptop for example. -Marko ___ 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] Ext3 on handset images instead of Btrfs
On 01/28/2011 04:19 PM, Arjan van de Ven wrote: On 1/28/2011 4:04 AM, Carsten Munk wrote: Hi, We just noticed we (N900 images) seem to be the only ones using btrfs on Handset images[1] [2]. When was this change made and is it an error? If not, why? Do we have a new default filesystem for the default configuration? MeeGo's default filesystem is BTRFS (and has been since before MeeGo 1.0) Unfortunately some hardware adaptation's have a buggy bootloader-architecture currently and are unable to use BTRFS. (and somehow making a small /boot that is ext3 with / being btrfs is hard) Well, because of the similar thing with u-boot on N900 we have a vfat partition in our N900 image that contains the content of /boot directory. So there is at least an example how it can be done on .ks level, of course for images that are used as installer this does not make difference to the resulting system. http://meego.gitorious.com/meego-os-base/image-configurations/blobs/master/handset/handset-armv7l-n900.ks Also it would be nice if those buggy hardware adaptations would be listed so people interested of these things would know what is the problem and could try to fix those. Regards, Marko ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] meego-tools repository for Fedora 14 planned?
On 11/22/2010 02:26 PM, Jannis Pohlmann wrote: Hi everyone, are there any plans to create a meego-tools repository for Fedora 14? Using the Fedora 13 repository from http://repo.meego.com/MeeGo/tools/repos/fedora/13/ doesn't work for me, as installing mic2 results in the following errors: Error: Package: mic2-0.22.2-1.1.noarch (meego-tools) Requires: python(abi) = 2.6 Installed: python-2.7-8.fc14.1.i686 (@fedora/$releasever) python(abi) = 2.7 Available: python3-3.1.2-14.fc14.i686 (fedora) python(abi) = 3.1 I have little to no experience in building RPMs myself. If there are no plans on such a repository yet, could someone at least point me to instructions on how to build meego-tools RPMs for F14? Cheers, Jannis ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev There is bug report about this missing tools repo: http://bugs.meego.com/show_bug.cgi?id=9822 Regards, Marko ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
[MeeGo-dev] Fwd: MeeGo core QA tests conducted against UI images?
Hi, There are tests conducted to the core part which expects the core API's to work (http://wiki.meego.com/Quality/CoreTestReports). However only on N900 the tests are done against actual MeeGo Core image, and for aava, netbook and MRST tests are done against images that contain Handset/Netbook UI. If those tests are conducted with Handset/Netbook UI parts how can we be sure that UI parts don't fix / break the Core features? Shouldn't it be enough to have only the MeeGo core (OS Base + Middleware) without UI to test these core features? So adding Meego Core + MeeGo X Window System package groups to the .ks with hardware support should be enough for core tests? http://meego.gitorious.org/meego-os-base/package-groups/blobs/master/comps.xml#line7 Couple of bugs related to packages in MeeGo Core package group: http://bugs.meego.com/show_bug.cgi?id=5818 http://bugs.meego.com/show_bug.cgi?id=5820 Regards, Marko ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Need info regarding Handset Image
prasanna grande wrote: Hi, Anyone can tell where i can find the download for handset meego image for running on x86 the way i can do on Maemo platform.. regards Lakshmi ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev MeeGo handset images are not yet available for download. Currently only netbook UX is available for download. http://meego.com/downloads/releases -Marko ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
[MeeGo-dev] Separate device specific repositories...
Hi, I want to raise discussion about the repositories, especially the structure of Core repository. If I have understood correctly the core repository contains the main parts of the MeeGo which create the base of MeeGo OS for all of the devices/architectures. In case of Nokia N900 there are already couple of N900 specific packages that are not required for other devices, including n900-camera-firmware, udev-rules-nokia-n900 and nokia-n900-configs. Why do we want to put these device specific packages to the core repository? They are needed only for one device after all. Why not create own repository for the device(s) that do have device specific packages? When new devices are introduced to MeeGo by different vendors there will be more packages that are only required for a specific vendor or device. By separating the packages to multiple repositories we would reduce the size of the core repository and simultaneously reduce the size of meta data end users would be required to download while updating their packages lists. Also this would filter the packages that do not work on certain devices out of the lists without extra package filtering on the device side. It would be better to reduce the amount of packages that users can install that do not work on their device. In the end MeeGo is meant for mobile devices that have smaller network bandwidth, less processing power and less memory to handle this repository meta data. Comments / opinions on this matter? Related to this http://bugs.meego.com/show_bug.cgi?id=2337 Regards, Marko ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] N900: Bugs.meego.com: Where does a hardware adaptation team fit?
Hi, Current status of MeeGo N900 port can be found from: http://wiki.meego.com/ARM Regards, Marko 2010/5/18 Mohamed Rasheed mohamed.rash...@lntinfotech.com: Hi, Any one ported Meego on OMAP3430SDP or ZOOM 2? Also where I can find the details to port Meego on N900? With Best Regards ... Mohamed Rasheed K.A. PES(Communication Embedded Systems) Larsen Toubro Infotech Limited Plot NO:25~30,EPIP 2nd Phase Industrial Area,Whitefield Bangalore - 560 066 INDIA,Board: 0091-80-66242424 EXT, :2224 Direct:91 -80-66242224 E-mail :mohamed.rash...@lntinfotech.com India, GMT +5.5 -Original Message- From: meego-dev-boun...@meego.com [mailto:meego-dev-boun...@meego.com] On Behalf Of Wan, Shuang Sent: Tuesday, May 18, 2010 11:42 AM To: Carsten Munk Cc: meego-dev Subject: Re: [MeeGo-dev] N900: Bugs.meego.com: Where does a hardware adaptation team fit? Hi Carsten Munk, There are several components defined under OS Base product includes Audio driver, Wifi driver etc. OS Base product is under MeeGo Platform classification. Is that meets your requirement? Regards Shuang -Original Message- From: carsten.m...@gmail.com [mailto:carsten.m...@gmail.com] On Behalf Of Carsten Munk Sent: 2010年5月18日 2:49 To: meego-dev Cc: Wan, Shuang Subject: N900: Bugs.meego.com: Where does a hardware adaptation team fit? So, for our work in the N900 hardware adaptation team, we obviously need bug tracking on bugs.meego.com to track issues and possibly requirements for our components. Now, where does a hardware adaptation fit in bugs.meego.com? What category, etc? For gitorious, we've initially been suggested OS base for our repositories and then sorting out where things belong using tags in future releases - not sure this is as easy in bugzilla. Regards, Carsten Munk ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev __ This Email may contain confidential or privileged information for the intended recipient (s) If you are not the intended recipient, please do not use or disseminate the information, notify the sender and delete it from your system. __ ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] N900: Synchronisation meetings
Hi Carsten, On Wed, May 12, 2010 at 10:09 AM, Carsten Munk cars...@maemo.org wrote: So, one of the approaches to open development we're trying in the N900 team is public synchronisation meetings, described at http://wiki.meego.com/ARM/N900#Team_synchronisation_meetings To get initially started, we need to figure out the following: * When we have our first meeting * With what regular intervals we have the meetings I would suggest biweekly meetings. In my opinion monthly meetings are too far apart and weekly meeting might be too close together (consumes to much time). However, exceptions can always be made. * Who chairs the meetings (I suggest Harri?) - this also means operating the meeting bot controls regarding what topic is the current one. There's a instruction guide linked in the page. I vote for Harri as well, if he does not have any objections. * If we have some standard items on the agenda for each meeting. I think that the current blockers for the next N900 release should be discussed to ensure that each of them would be handled properly. We need to take into consideration when the 'meeting room' is booked as well, http://wiki.meego.com/MeeGo-Meeting_IRC_Schedule Thursdays after the TSG meetings are currently free? Could this be our spot? Also the timing should be selected so that most of the members of N900 adaptation team could attend the meeting during reasonable hours (07:00-23:00?). I have proposed on the page a free-form agenda type initially - add a agenda item and it will be discussed provided you show up to discuss yourself (team membership not needed?). And that we freeze the agenda 24 hours before a meeting. After each meeting, minutes would be posted from the meeting bot output, the agenda moved to previous meetings and new date for meeting set up with a blank/standard agenda. What do you think? Regards, Carsten Munk ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev Regards, Marko Saukko ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] N900: Blockers for May release ?
On Mon, May 17, 2010 at 12:55 PM, harri.hakuli...@nokia.com wrote: From: meego-dev-boun...@meego.com On Behalf Of ext Marko Saukko Sent: 17. toukokuuta 2010 10:46 * If we have some standard items on the agenda for each meeting. I think that the current blockers for the next N900 release should be discussed to ensure that each of them would be handled properly. Lets list the blockers now, we don't need to wait for Thursday. Br, //Harri Currently the blockers for N900 release are (as far as I know) [persons who are working with the task]: - Kernel in Meego-1.0 or Trunk branch do not include all the driver patches for N900 (it compiles already though). [Roger, Ameya] - Nokia Proprietary packages repository update or new release [Markus,Marko] - Automatic release/image generation [ ? ] Regards, Marko ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
