Re: [MeeGo-dev] Can not tracker *.rm/rmvb files
On Tue, 12 Apr 2011 09:33:10 +0800, yinxb wrote:
Hi
Hi there
I encounters a confusing problem that the *.rm/rmvb video files
can not be trackered by the following SQL
Not SQL, SPARQL :)
SELECT nie:url(nie:isStoredAs(?video)) WHERE{?video a nmm:Video};
You don't need the isStoredAs here, all you need is
SELECT nie:url(?file) WHERE {?file a nmm:Video}
I analysed the /usr/share/mime/packages/freedesktop.org.xml
that the mime type [mime-type
type=application/vnd.rn-realmedia]is
defined.
Tracker has to be configured with --enable-gstreamer-helix I guess, or
else gstreamer has to have some plugins installed to understand this
format.
Can you please run /usr/libexec/tracker-extract -f on your video file
and
paste the output somewhere?
Also,I found only video/* mime type is trackered in
tracker-extract-gstreamer.c,is that right?
It is right
So,does the qttracker only tracker video files which obtain mime
type
[video/*]?
Uuuuh, serious spaghetti mixing here :) qttracker is a library to
access
Tracker from Qt applications. It is now deprecated in favor of
libqtsparql.
The video files will get their metadata extracted if gstreamer can get
any
metadata. If it can't (because it has no module installed for a
specific
format), then no metadata will be extracted.
Can anyone give me some suggestion?
Please check if you have gstreamer modules for that format, and also
paste
the output of tracker-extract somewhere as suggested above. You can
also
try the gstreamer-helix ./configure option.
Cheers
Adrien
---
Confidentiality Notice: The information contained in this e-mail and
any accompanying attachment(s)
is intended only for the use of the intended recipient and may be
confidential and/or privileged of
Neusoft Corporation, its subsidiaries and/or its affiliates. If any
reader of this communication is
not the intended recipient, unauthorized use, forwarding, printing,
storing, disclosure or copying
is strictly prohibited, and may be unlawful.If you have received this
communication in error,please
immediately notify the sender by return e-mail, and delete the
original message and all copies from
your system. Thank you.
---
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev
http://wiki.meego.com/Mailing_list_guidelines
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev
http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] Faild to build image for armv7hl with latest mic
rpmUtils.arch.arches.keys() ['ppc', 'x86_64', 'armv5tejl', 'i586', 'sparc', 'geode', 'ppc64', 'i486', 'alphapca56', 'alphaev7', 'alphaev6', 'i386', 'alphaev45', 'armv5tel', 'sh4a', 'alpha', 'ia64', 'ppc64iseries', 'ia32e', 'sparcv9v', 's390', 'athlon', 'sh3', 'sh4', 'amd64', 'sparcv8', 'sparcv9', 'ppc64pseries', 'sparc64', 'armv7l', 'alphaev5', 's390x', 'i686', 'alphaev56', 'alphaev4', 'alphaev67', 'sparc64v', 'alphaev68', 'armv6l'] there're no armv7hl, so error raised ___ 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] Faild to build image for armv7hl with latest mic
yes, but in mic/imgcreate/pkgmanagers/yumpkgmgr.py 50 #line50 class Yum(yum.YumBase): 51 #line51 def __init__(self, creator = None, recording_pkgs=None): 52 #line52 if not isinstance(creator, ImageCreator): 53 #line53 raise CreatorError(Invalid argument: creator) 54 #line54 yum.YumBase.__init__(self) 55 #line55 56 #line56 self.creator = creator 57 #line57 58 #line58 if self.creator.target_arch: 59 #line59 if rpmUtils.arch.arches.has_key(self.creator.target_arch): 60 #line60 self.arch.setup_arch(self.creator.target_arch) 61 #line61 else: 62 #line62 raise CreatorError(Invalid target arch: %s % self.creator.target_arch) On Tue, Apr 12, 2011 at 2:26 PM, WuYongbo wilbur.un...@gmail.com wrote: I am using the latest version of mic from Gitorious: in image-creator/tools/mic-image-creator, it shows arch armv7hl is supported. 615https://meego.gitorious.org/meego-developer-tools/image-creator/blobs/master/tools/mic-image-creator#line615 if options.release and options.run_mode == 0: 616https://meego.gitorious.org/meego-developer-tools/image-creator/blobs/master/tools/mic-image-creator#line616 options.record_pkgs = name 617https://meego.gitorious.org/meego-developer-tools/image-creator/blobs/master/tools/mic-image-creator#line617 if not options.prefix: 618https://meego.gitorious.org/meego-developer-tools/image-creator/blobs/master/tools/mic-image-creator#line618 options.prefix = meego 619https://meego.gitorious.org/meego-developer-tools/image-creator/blobs/master/tools/mic-image-creator#line619 if not options.suffix: 620https://meego.gitorious.org/meego-developer-tools/image-creator/blobs/master/tools/mic-image-creator#line620 options.suffix = options.release 621https://meego.gitorious.org/meego-developer-tools/image-creator/blobs/master/tools/mic-image-creator#line621 meegovert = [handset, netbook, tablet, ivi, cetv, core, tv] 622https://meego.gitorious.org/meego-developer-tools/image-creator/blobs/master/tools/mic-image-creator#line622 meegoarch = [ia32, armv5tel, armv7l, armv7hl, armv7nhl] 623https://meego.gitorious.org/meego-developer-tools/image-creator/blobs/master/tools/mic-image-creator#line623 base = os.path.basename(options.config) 624https://meego.gitorious.org/meego-developer-tools/image-creator/blobs/master/tools/mic-image-creator#line624 ksname = base[:base.rfind(.)] 625https://meego.gitorious.org/meego-developer-tools/image-creator/blobs/master/tools/mic-image-creator#line625 ksnamec = ksname.split(-) 2011/4/12 tom z maillist@gmail.com rpmUtils.arch.arches.keys() ['ppc', 'x86_64', 'armv5tejl', 'i586', 'sparc', 'geode', 'ppc64', 'i486', 'alphapca56', 'alphaev7', 'alphaev6', 'i386', 'alphaev45', 'armv5tel', 'sh4a', 'alpha', 'ia64', 'ppc64iseries', 'ia32e', 'sparcv9v', 's390', 'athlon', 'sh3', 'sh4', 'amd64', 'sparcv8', 'sparcv9', 'ppc64pseries', 'sparc64', 'armv7l', 'alphaev5', 's390x', 'i686', 'alphaev56', 'alphaev4', 'alphaev67', 'sparc64v', 'alphaev68', 'armv6l'] there're no armv7hl, so error raised ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines -- Good luck ! ___ 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
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写道： 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
Re: [MeeGo-dev] Can not tracker *.rm/rmvb files
I encounters a confusing problem that the *.rm/rmvb video files
can not be trackered by the following SQL
SELECT nie:url(nie:isStoredAs(?video)) WHERE{?video a nmm:Video};
I analysed the /usr/share/mime/packages/freedesktop.org.xml
that the mime type [mime-type type=application/vnd.rn-realmedia]is
defined.
Also,I found only video/* mime type is trackered in
tracker-extract-gstreamer.c,is that right?
So,does the qttracker only tracker video files which obtain mime type
[video/*]?
Can anyone give me some suggestion?
Yes.
Please fill a bug in MeeGo bugzilla:
https://bugs.meego.com/enter_bug.cgi
Product: OS Middleware
Component: Content framework (tracker)
And specially, attach a sample test file. Possibly it's just adding a
new mimetype to the list of mimetypes extract-able by the gstreamer
plugin.
Cheers,
--
Aleksander
___
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] howto prevent unrequired build dependency remove when doing local osc builds?
On 06/04/11 13:15, Mika Laitio wrote: I have setted in my .oscrc build-root = /var/tmp/%(repo)s-%(arch)s If I first build mce locally with osc build armv8el Trunk_Testing, I have in my build root all packages that were required for building the mce on /var/tmp/Trunk_Testing-armv8el But If I will after that build kernel locally again with same osc build armv8el Trunk_Testing, osc will now install all additional dependencies required by the kernel build to this same /var/tmp/Trunk_Testing-armv8el directory. That's fine, but for some reason it seems also be removing all dependencies that were required by the MCE but are not required for the kernel build. The reasonong behind this is that OBS (and osc) are designed to build in clean chroots that are specified by the dependency chain initiated in the .spec. This ensures you have the correct package dependencies and don't inadvertantly ship code that FTBFS. Is there any method for preventing this? I know that one solution is to configure in oscrc a package specific build roots, but as each chroot takes about 1 gb of harddrive, I would rather try to have just arch specific chroots that contains all non-conflicting build dependencies for many different pacakages simultaneously. That pretty much defeats the purpose of osc build - but, if you want rope: osc build --extra-pkgs=PAC and repeat that for the build-deps for mce when building a kernel. Maye use a PAC==a meta-pkg to manage that list. That extra-pkgs can even go into your .oscrc ... this may or may not do what you want :) David -- Don't worry, you'll be fine; I saw it work in a cartoon once... ___ 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] howto prevent unrequired build dependency remove when doing local osc builds?
On 6 Apr 2011, at 15:15, Mika Laitio wrote: I have setted in my .oscrc build-root = /var/tmp/%(repo)s-%(arch)s If I first build mce locally with osc build armv8el Trunk_Testing, I have in my build root all packages that were required for building the mce on /var/tmp/Trunk_Testing-armv8el But If I will after that build kernel locally again with same osc build armv8el Trunk_Testing, osc will now install all additional dependencies required by the kernel build to this same /var/tmp/Trunk_Testing-armv8el directory. That's fine, but for some reason it seems also be removing all dependencies that were required by the MCE but are not required for the kernel build. ... warning: /etc/gconf/2/path saved as /etc/gconf/2/path.rpmsave deleting GConf-dbus-devel deleting dbus-devel deleting dbus-glib-devel deleting glib2-devel deleting libdsme ... Is there any method for preventing this? Why do you want MCE build dependencies when building the kernel? The packages are removed from the chroot, but they are still cached locally for the next MCE build, meaning you will not be pulling them again from the repos. If you want to jump straight to building without removing anything, you can try --noinit option --noinit, --no-init Skip initialization of build root and start with build immediately. Anas I know that one solution is to configure in oscrc a package specific build roots, but as each chroot takes about 1 gb of harddrive, I would rather try to have just arch specific chroots that contains all non-conflicting build dependencies for many different pacakages simultaneously. Mika ___ 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] howto prevent unrequired build dependency remove when doing local osc builds?
2011/4/12 Anas Nashif nas...@linux.intel.com: On 6 Apr 2011, at 15:15, Mika Laitio wrote: I have setted in my .oscrc build-root = /var/tmp/%(repo)s-%(arch)s If I first build mce locally with osc build armv8el Trunk_Testing, I have in my build root all packages that were required for building the mce on /var/tmp/Trunk_Testing-armv8el But If I will after that build kernel locally again with same osc build armv8el Trunk_Testing, osc will now install all additional dependencies required by the kernel build to this same /var/tmp/Trunk_Testing-armv8el directory. That's fine, but for some reason it seems also be removing all dependencies that were required by the MCE but are not required for the kernel build. ... warning: /etc/gconf/2/path saved as /etc/gconf/2/path.rpmsave deleting GConf-dbus-devel deleting dbus-devel deleting dbus-glib-devel deleting glib2-devel deleting libdsme ... Is there any method for preventing this? Why do you want MCE build dependencies when building the kernel? The packages are removed from the chroot, but they are still cached locally for the next MCE build, meaning you will not be pulling them again from the repos. If you want to jump straight to building without removing anything, you can try --noinit option --noinit, --no-init Skip initialization of build root and start with build immediately. Anas I know that one solution is to configure in oscrc a package specific build roots, but as each chroot takes about 1 gb of harddrive, I would rather try to have just arch specific chroots that contains all non-conflicting build dependencies for many different pacakages simultaneously. I use --clean, personally /Carsten ___ 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
you are right! I ignored Warnings about echo 0 | sudo tee /proc/sys/vm/vdso_enabled carelessly! thanks :-) 2011/4/12 Marko Saukko marko.sau...@cybercom.com 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
Re: [MeeGo-dev] ANNOUNCE: [ABI break] MeeGo 1.2 ARM architecture will only support hardfp ABI
Am Montag 11 April 2011, 15:21:50 schrieb Thiago Macieira: Em segunda-feira, 11 de abril de 2011, às 15:28:59, Juha Kallioinen escreveu: The hardfp scheduler is called armv8el and is up and running in MeeGo Trunk. Why are we calling it ARMv8? The _scheduler_ inside OBS is called armv8el, the rpm architecture is armv7hl . This is just a name and no reference to ARMv8. We just had no time to jump to a newer OBS release (which has armv7el + armv7hl), so we took the unused placeholder armv8el to get hardfp up asap and have to deal with the naming confusion. So for the records - currently we have: * armv7el = armv7l softfp * armv8el = armv7l hardfp In the next version of OBS, there are then: * armv7el = armv7l softfp * armv7hl = armv7l hardfp (* armv8el = unused/future) All I can find about it are future references, like: Yes, this is no ARM arch name, just a scheduler naming. Also, an ARMv8 build implies that it doesn't run on ARMv7 hardware. I think that would be extremely short-sighted. As noted above, the next version of OBS has armv7hl and things will be in sync again. HTH. Best, Jan-Simon ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
[MeeGo-dev] How to deal with device specific settings in MeeGo
Hi I am wondering how to deal with device specific settings in MeeGo. I mean certain setting that vary between different devices and can't be defined in build time. For example this bug: https://bugs.meego.com/show_bug.cgi?id=15323 Reason to the bug is that QApplication defines 4 as a default value for drag threshold. In case of N900 this is too small value and as a result the grid component in question is pretty much unusable in N900. I could fix that problem by defining drag threshold (QApplication's startDragDistance property) to 12 but I think that is not the correct way to fix this. First of all this setting must be defined globally for all applications in the specific device. Secondly different devices need different drag threshold values. Is there a common way to deal with this kind of device specific settings in MeeGo? Br, Joonas SASKEN BUSINESS DISCLAIMER: This message may contain confidential, proprietary or legally privileged information. In case you are not the original intended Recipient of the message, you must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message and you are requested to delete it and inform the sender. Any views expressed in this message are those of the individual sender unless otherwise stated. Nothing contained in this message shall be construed as an offer or acceptance of any offer by Sasken Communication Technologies Limited (Sasken) unless sent with that express intent and with due authority of Sasken. Sasken has taken enough precautions to prevent the spread of viruses. However the company accepts no liability for any damage caused by any virus transmitted by this email. Read Disclaimer at http://www.sasken.com/extras/mail_disclaimer.html ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] How to deal with device specific settings in MeeGo
Hi, It sounds like Qt requires to have this value configurable, we need to fill a bug upstream. As a workaround, it could be an environment variable or maybe a Qt configuration variable. Cheers, Fathi From: meego-dev-boun...@meego.com [meego-dev-boun...@meego.com] on behalf of ext Joonas Tanskanen [joonas.tanska...@sasken.com] Sent: Tuesday, April 12, 2011 1:00 PM To: meego-dev@meego.com Subject: [MeeGo-dev] How to deal with device specific settings in MeeGo Hi I am wondering how to deal with device specific settings in MeeGo. I mean certain setting that vary between different devices and can’t be defined in build time. For example this bug: https://bugs.meego.com/show_bug.cgi?id=15323 Reason to the bug is that QApplication defines 4 as a default value for drag threshold. In case of N900 this is too small value and as a result the grid component in question is pretty much unusable in N900. I could fix that problem by defining drag threshold (QApplication’s startDragDistance property) to 12 but I think that is not the correct way to fix this. First of all this setting must be defined globally for all applications in the specific device. Secondly different devices need different drag threshold values. Is there a common way to deal with this kind of device specific settings in MeeGo? Br, Joonas SASKEN BUSINESS DISCLAIMER: This message may contain confidential, proprietary or legally privileged information. In case you are not the original intended Recipient of the message, you must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message and you are requested to delete it and inform the sender. Any views expressed in this message are those of the individual sender unless otherwise stated. Nothing contained in this message shall be construed as an offer or acceptance of any offer by Sasken Communication Technologies Limited (Sasken) unless sent with that express intent and with due authority of Sasken. Sasken has taken enough precautions to prevent the spread of viruses. However the company accepts no liability for any damage caused by any virus transmitted by this email. Read Disclaimer at http://www.sasken.com/extras/mail_disclaimer.html ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] howto prevent unrequired build dependency remove when doing local osc builds?
Why do you want MCE build dependencies when building the kernel? Because quite often when I am developing and testing some packages, I will first do manual editing, building and copying binaries for N900 in the chrooted environment. # /usr/sbin/qemu-binfmt-conf.sh # cd /var/tmp/Trunk_Testing-armv7el # chroot . # cd mce # make ... then scp the binaries build on non-chrooted terminal which has network access to n900 for testing Once I am happy with that, I will usually do the patches and then run local obs build for final testing before committing changes to obs server. So now what happens is that if I do local obs kernel build, it has removed all mce related devel-headers and before I can continue with that I must re-install all mce packages by doing a local obs build for mce. I have worked around this now by collecting a huge list of packages under extra-pkgs option in .oscrc The packages are removed from the chroot, but they are still cached locally for the next MCE build, meaning you will not be pulling them again from the repos. If you want to jump straight to building without removing anything, you can try --noinit option --noinit, --no-init Skip initialization of build root and start with build immediately. What I would like to have is some kind of option update existing rpm's and install only a new dependencies without uninstalling anything. Mika ___ 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] Can not tracker *.rm/rmvb files
Are you able to play the file using:
gst-launch-0.10 playbin uri=file:///home/meego/filename.rm?
On 04/12/2011 10:52 AM, ext Aleksander Morgado wrote:
I encounters a confusing problem that the *.rm/rmvb video files
can not be trackered by the following SQL
SELECT nie:url(nie:isStoredAs(?video)) WHERE{?video a nmm:Video};
I analysed the /usr/share/mime/packages/freedesktop.org.xml
that the mime type [mime-type type=application/vnd.rn-realmedia]is
defined.
Also,I found only video/* mime type is trackered in
tracker-extract-gstreamer.c,is that right?
So,does the qttracker only tracker video files which obtain mime type
[video/*]?
Can anyone give me some suggestion?
Yes.
Please fill a bug in MeeGo bugzilla:
https://bugs.meego.com/enter_bug.cgi
Product: OS Middleware
Component: Content framework (tracker)
And specially, attach a sample test file. Possibly it's just adding a
new mimetype to the list of mimetypes extract-able by the gstreamer
plugin.
Cheers,
___
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 11/04/11 16:36, ext Marko Saukko wrote: 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 Indeed, how does one make enough noise about this so that this gets done? Cheers, -Juha ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
[MeeGo-dev] X11 between Meego 1.1 and Meego 1.2
Hi 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. Syslog says the application seg fault at libX11.so.6.3.0. I even copied the same library over to MeeGo 1.2 from MeeGo 1.1 and it still seg faults (the file name and version is the same between Meego 1.2 and 1.1 but size is different. Did X undergo a major change between Meego 1.1 and Meego 1.2? thanks Mark ___ 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 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. If your application doesn't fit into the GLESv2 subset... this could be your problem. Also, the GLESv2 drivers aren't as widely-used as the OpenGL drivers... so you may have uncovered a bug. A backtrace would tell you more, though. :-) -gabriel ___ 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] X11 between Meego 1.1 and Meego 1.2
Hello, Could you please commit a bug with backtrace? Thanks. Best Regards, Aleksandar From: meego-dev-boun...@meego.com [meego-dev-boun...@meego.com] on behalf of ext Mark S. Townsley [mstowns...@gmail.com] Sent: Tuesday, April 12, 2011 9:22 PM To: Development for the MeeGo Project (discussion list) Subject: [MeeGo-dev] X11 between Meego 1.1 and Meego 1.2 Hi 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. Syslog says the application seg fault at libX11.so.6.3.0. I even copied the same library over to MeeGo 1.2 from MeeGo 1.1 and it still seg faults (the file name and version is the same between Meego 1.2 and 1.1 but size is different. Did X undergo a major change between Meego 1.1 and Meego 1.2? thanks Mark ___ 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] Can not tracker *.rm/rmvb files
Hi
Are you able to play the file using:
gst-launch-0.10 playbin uri=file:///home/meego/filename.rm?
yes,it seems all right from the command line using playbin2.
在 2011-04-12二的 14:59 +0300，maitrey写道：
Are you able to play the file using:
gst-launch-0.10 playbin uri=file:///home/meego/filename.rm?
On 04/12/2011 10:52 AM, ext Aleksander Morgado wrote:
I encounters a confusing problem that the *.rm/rmvb video files
can not be trackered by the following SQL
SELECT nie:url(nie:isStoredAs(?video)) WHERE{?video a nmm:Video};
I analysed the /usr/share/mime/packages/freedesktop.org.xml
that the mime type [mime-type type=application/vnd.rn-realmedia]is
defined.
Also,I found only video/* mime type is trackered in
tracker-extract-gstreamer.c,is that right?
So,does the qttracker only tracker video files which obtain mime type
[video/*]?
Can anyone give me some suggestion?
Yes.
Please fill a bug in MeeGo bugzilla:
https://bugs.meego.com/enter_bug.cgi
Product: OS Middleware
Component: Content framework (tracker)
And specially, attach a sample test file. Possibly it's just adding a
new mimetype to the list of mimetypes extract-able by the gstreamer
plugin.
Cheers,
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev
http://wiki.meego.com/Mailing_list_guidelines
---
Confidentiality Notice: The information contained in this e-mail and any
accompanying attachment(s)
is intended only for the use of the intended recipient and may be confidential
and/or privileged of
Neusoft Corporation, its subsidiaries and/or its affiliates. If any reader of
this communication is
not the intended recipient, unauthorized use, forwarding, printing, storing,
disclosure or copying
is strictly prohibited, and may be unlawful.If you have received this
communication in error,please
immediately notify the sender by return e-mail, and delete the original message
and all copies from
your system. Thank you.
---
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev
http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] X11 between Meego 1.1 and Meego 1.2
Hi, Mark MeeGo 1.2 is using OpenGL ES now. You can check whether it's your OpenGL code problem. And another change between MeeGo 1.1 and 1.2 is clutter upgrade. Thanks Daniel From: meego-dev-boun...@meego.com [mailto:meego-dev-boun...@meego.com] On Behalf Of aleksandar.stojiljko...@nokia.com Sent: Wednesday, April 13, 2011 3:42 AM To: mstowns...@gmail.com; meego-dev@meego.com Subject: Re: [MeeGo-dev] X11 between Meego 1.1 and Meego 1.2 Importance: Low Hello, Could you please commit a bug with backtrace? Thanks. Best Regards, Aleksandar From: meego-dev-boun...@meego.com [meego-dev-boun...@meego.com] on behalf of ext Mark S. Townsley [mstowns...@gmail.com] Sent: Tuesday, April 12, 2011 9:22 PM To: Development for the MeeGo Project (discussion list) Subject: [MeeGo-dev] X11 between Meego 1.1 and Meego 1.2 Hi 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. Syslog says the application seg fault at libX11.so.6.3.0. I even copied the same library over to MeeGo 1.2 from MeeGo 1.1 and it still seg faults (the file name and version is the same between Meego 1.2 and 1.1 but size is different. Did X undergo a major change between Meego 1.1 and Meego 1.2? thanks Mark ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
[MeeGo-dev] SGX535's graphic and video acceleration on Orktrial
Hi Gnus, Could you give me some tips to bring up video acceleration on MeeGo 1.2 tablet for Orktrail? Thanks zheng ___ 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] Can not tracker *.rm/rmvb files
Tracker uses decodebin2 to extract the metadata. Are you able to decode the file with decodebin2? -Original Message- From: meego-dev-boun...@meego.com [mailto:meego-dev-boun...@meego.com] On Behalf Of yinxb Sent: 2011年4月13日 8:37 To: maitrey Cc: meego-dev@meego.com Subject: Re: [MeeGo-dev] Can not tracker *.rm/rmvb files Hi Are you able to play the file using: gst-launch-0.10 playbin uri=file:///home/meego/filename.rm? yes,it seems all right from the command line using playbin2. ___ 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] Can not tracker *.rm/rmvb files
Hi Zhengqiang gst-launch-0.10 filesrc location=/root/Videos/rm_30.rm ! decodebin2 ! videoscale ! xvimagesink the above command line works well. 在 2011-04-13三的 11:22 +0800，Chen, Zhenqiang写道： Tracker uses decodebin2 to extract the metadata. Are you able to decode the file with decodebin2? --- Confidentiality Notice: The information contained in this e-mail and any accompanying attachment(s) is intended only for the use of the intended recipient and may be confidential and/or privileged of Neusoft Corporation, its subsidiaries and/or its affiliates. If any reader of this communication is not the intended recipient, unauthorized use, forwarding, printing, storing, disclosure or copying is strictly prohibited, and may be unlawful.If you have received this communication in error,please immediately notify the sender by return e-mail, and delete the original message and all copies from your system. Thank you. --- ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
