Re: [yocto] Python3-distribute-native build fails in daisy

2014-06-08 Thread Diego Sueiro
Andreas,

On Sun, Jun 8, 2014 at 3:05 AM, Andreas Galauner 
wrote:

> Hi all,
>
> I'm currently trying to add a few python packages to my image for which
> I need Python 3.3 because a few of them depend on asyncio. These
> packages (asyncio itself, websockets and django) are installed with the
> usual distribute setup.py scripts either using setuptools or distribute.
>
> Now when trying to build python3-distribute-native as a build dependency
> for any of these packages, bitbake fails with the following message:
>
> > snip <
> > | copying DEVGUIDE.txt -> build/src
> > | copying CHANGES.txt -> build/src
> > | copying README.txt -> build/src
> > | copying MANIFEST.in -> build/src
> > | copying launcher.c -> build/src
> > | Traceback (most recent call last):
> > |   File "setup.py", line 34, in 
> > | util.run_2to3(outfiles_2to3)
> > |   File
> "/media/andy/Data/Zedboard/openembedded/build_poky/tmp-eglibc/sysroots/x86_64-linux/usr/lib/python3.3/distutils/util.py",
> line 507, in run_2to3
> > | from lib2to3.refactor import RefactoringTool,
> get_fixers_from_package
> > |   File
> "/media/andy/Data/Zedboard/openembedded/build_poky/tmp-eglibc/sysroots/x86_64-linux/usr/lib/python3.3/lib2to3/refactor.py",
> line 19, in 
> > | import logging
> > |   File
> "/media/andy/Data/Zedboard/openembedded/build_poky/tmp-eglibc/sysroots/x86_64-linux/usr/lib/python3.3/logging/__init__.py",
> line 26, in 
> > | import sys, os, time, io, traceback, warnings, weakref
> > | ImportError: No module named 'time'
> > | ERROR: python3 setup.py build_ext execution failed.
> > | WARNING:
> /media/andy/Data/Zedboard/openembedded/build_poky/tmp-eglibc/work/x86_64-linux/python3-distribute-native/0.6.32-ml5/temp/run.do_compile.1363:1
> exit 1 from
> > |   exit 1
> > | ERROR: Function failed: do_compile (log file is located at
> /media/andy/Data/Zedboard/openembedded/build_poky/tmp-eglibc/work/x86_64-linux/python3-distribute-native/0.6.32-ml5/temp/log.do_compile.1363)
> > snip <
> (Note: even if the path says openembedded, it's yocto)
>
> When using the devshell to launch python3 and trying to import time, it
> fails in the same way.
> I'm using an up-to-date checkout of the daisy branch.
>
> Any ideas what the cause for this could be and how to solve this?
>
> - Andy
>

I'm getting the same problem for python3-distribute. Take a look bug #6373
.
Try to do a "bitbake python3-native -fccompile ; bitbake python3-native -f"
and see if you can go further than me.


Regards,

--
*dS
Diego Sueiro

Administrador do Embarcados
www.embarcados.com.br


/*long live rock 'n roll*/
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto


[yocto] [meta-raspberrypi][PATCH 0/1] gstreamer1.0-omx: Target Raspberry Pi instead of Bellagio.

2014-06-08 Thread Alex J Lennon
Please see following patch for details

Alex J Lennon (1):
  gstreamer1.0-omx: Target Raspberry Pi instead of Bellagio.

 recipes-multimedia/gstreamer/gstreamer1.0-omx.inc| 2 ++
 recipes-multimedia/gstreamer/gstreamer1.0-omx_1.0.0.bbappend | 1 +
 2 files changed, 3 insertions(+)
 create mode 100644 recipes-multimedia/gstreamer/gstreamer1.0-omx.inc
 create mode 100644 recipes-multimedia/gstreamer/gstreamer1.0-omx_1.0.0.bbappend

-- 
2.0.0

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto


[yocto] [meta-raspberrypi][PATCH 1/1] gstreamer1.0-omx: Target Raspberry Pi instead of Bellagio.

2014-06-08 Thread Alex J Lennon
This changes the build slightly as there are some #ifdefs in there for 
Raspberry Pi.

Also the codec configuration file used by gstreamer1.0-omx codecs, 
/etc/xdg/gstomx.conf,  is set correctly to core-name=/usr/lib/libopenmaxil.so

Change-Id: I2352ecabfd053717d9ccd2d22422e7d4b7588ce4
Signed-off-by: Alex J Lennon 
---
 recipes-multimedia/gstreamer/gstreamer1.0-omx.inc| 2 ++
 recipes-multimedia/gstreamer/gstreamer1.0-omx_1.0.0.bbappend | 1 +
 2 files changed, 3 insertions(+)
 create mode 100644 recipes-multimedia/gstreamer/gstreamer1.0-omx.inc
 create mode 100644 recipes-multimedia/gstreamer/gstreamer1.0-omx_1.0.0.bbappend

diff --git a/recipes-multimedia/gstreamer/gstreamer1.0-omx.inc 
b/recipes-multimedia/gstreamer/gstreamer1.0-omx.inc
new file mode 100644
index 000..eb7cca4
--- /dev/null
+++ b/recipes-multimedia/gstreamer/gstreamer1.0-omx.inc
@@ -0,0 +1,2 @@
+GSTREAMER_1_0_OMX_TARGET="rpi"
+GSTREAMER_1_0_OMX_CORE_NAME="/usr/lib/libopenmaxil.so"
diff --git a/recipes-multimedia/gstreamer/gstreamer1.0-omx_1.0.0.bbappend 
b/recipes-multimedia/gstreamer/gstreamer1.0-omx_1.0.0.bbappend
new file mode 100644
index 000..bd54419
--- /dev/null
+++ b/recipes-multimedia/gstreamer/gstreamer1.0-omx_1.0.0.bbappend
@@ -0,0 +1 @@
+require ${PN}.inc
-- 
2.0.0

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto


[yocto] [meta-raspberrypi][PATCH 0/1] linux-raspberrypi: Update kernel to 3.12.21

2014-06-08 Thread Alex J Lennon
Please see following patch for details

Alex J Lennon (1):
  linux-raspberrypi: Update kernel to 3.12.21

 .../{linux-raspberrypi_3.12.18.bb => linux-raspberrypi_3.12.21.bb}  | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
 rename recipes-kernel/linux/{linux-raspberrypi_3.12.18.bb => 
linux-raspberrypi_3.12.21.bb} (77%)

-- 
2.0.0

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto


[yocto] [meta-raspberrypi][PATCH 1/1] linux-raspberrypi: Update kernel to 3.12.21

2014-06-08 Thread Alex J Lennon
Amongst other patches, this release includes a fix to an issue with 
gstreamer1.0 and v4l2src blocking

ref: https://bugzilla.gnome.org/show_bug.cgi?id=726521

ref: 
https://github.com/raspberrypi/linux/commit/fd1355b22e5c52b5e31b936b5f68d3b62cb189c8

To make use of the optional fix the module parameter gst_v4l2src_is_broken 
needs to be set when loading bcm2835-v4l2.ko

With this in place, and with userland and gstreamer1.0-omx patches, 
gstreamer1.0 can be used with PiCam via v4l2src instead of raspivid.

(There may still be performance issues to be addressed for v4l2src vs raspivid 
pipe & fdsrc).

Change-Id: Ia0ed4e6c8f27df9bb12ae2350526f6314e016d51
Signed-off-by: Alex J Lennon 
---
 .../{linux-raspberrypi_3.12.18.bb => linux-raspberrypi_3.12.21.bb}  | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
 rename recipes-kernel/linux/{linux-raspberrypi_3.12.18.bb => 
linux-raspberrypi_3.12.21.bb} (77%)

diff --git a/recipes-kernel/linux/linux-raspberrypi_3.12.18.bb 
b/recipes-kernel/linux/linux-raspberrypi_3.12.21.bb
similarity index 77%
rename from recipes-kernel/linux/linux-raspberrypi_3.12.18.bb
rename to recipes-kernel/linux/linux-raspberrypi_3.12.21.bb
index 736be5f..a40b54f 100644
--- a/recipes-kernel/linux/linux-raspberrypi_3.12.18.bb
+++ b/recipes-kernel/linux/linux-raspberrypi_3.12.21.bb
@@ -1,4 +1,4 @@
-SRCREV = "b09a27249d61475e4423607f7632a5aa6e7b3a53"
+SRCREV = "cb53ea88f75180cc1ba74f7f197c8e3fd4f47cfe"
 SRC_URI = 
"git://github.com/raspberrypi/linux.git;protocol=git;branch=rpi-3.12.y \
file://sl030raspberrypii2ckernel.patch \
   "
-- 
2.0.0

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto


[yocto] [Package Report System]Manual check recipes name list

2014-06-08 Thread package-rep...@yoctoproject.org
This mail was sent out by Package Report System.
It will list all the recipes which can't check upstream version by script, and 
will show how long it is since their last mannual version check.
You can check the detail information at 
http://packages.yoctoproject.org/manuallychkinfo


PackageName  Version LastChkVersion  LastChkTime
  Maintainer  NoUpgradeReason   
puzzles  r10116  N/A 41797 d
  Valentin Popa  
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto


[yocto] [Package Report System]Upgrade recipes name list

2014-06-08 Thread package-rep...@yoctoproject.org
This mail was sent out by Package Report System.
This message list those recipes which need to be upgraded. If maintainers 
believe some of them needn't to upgrade this time, they can fill in 
RECIPE_NO_UPDATE_REASON_pn-"xxx" in upstream_tracking files to ignore this 
recipe remainder until newer upstream version was detected.
Example:
RECIPE_NO_UPDATE_REASON_pn-"xxx" = "Not upgrade to 2.0 because the new version 
is unstable"
You can check the detail information at 
http://packages.yoctoproject.org/upgradepkgname


PackageName   Version   UpVersion   
  MaintainerNoUpgradeReason 
  
gettext   0.18.3.2  0.19
  Wenzong Fan
gnome-common  3.7.4 3.12.0  
  Valentin Popa
puzzles   r10116N/A 
  Valentin Popa
gtk+  2.24.22   3.13.2  
  Valentin PopaDo not upgrade to 
version: 2
gtk+3 3.10.73.13.2  
  Valentin Popa
libpam1.1.6 1.1.8   
  Valentin Popa
libtasn1  3.5   3.6 
  Valentin Popa
gsettings-desktop-schemas 3.10.13.13.2  
  Valentin Popa
gtk-update-icon-cache-native  3.4.4 3.13.2  
  Valentin Popa
hicolor-icon-theme0.12  0.13
  Valentin Popa
gnome-icon-theme  2.31.03.12.0  
  Valentin Popawaiting for the 
sato gtk3 port
liberation-fonts  1.04  2.00.1  
  Valentin Popa2.00.0 - fontforge 
package re...
screen4.0.3 4.2.1   
  Valentin Popa
xdg-utils 1.1.0-rc1 1.0.2   
  Valentin Popaonly release 
candidates avail...
matchbox-panel-2  2.0+gitAUTOINC+26a3a67b41 
2.0+gitAUTOINC+1a7304dValentin Popa
webkit-gtk1.8.3 2.4.3   
  Valentin Popa>= 1.10.2 needs 
ruby  
matchbox-desktop  2.0+gitAUTOINC+71e3e6e042 
2.0+gitAUTOINC+09170f4Valentin Popa
shared-mime-info  1.2   1.3 
  Valentin Popa
gnome-desktop 2.32.13.13.2  
  Valentin Popawaiting for the 
sato gtk3 port
matchbox-keyboard 0.0+gitAUTOINC+217f1bfe14 
0.0+gitAUTOINC+0899b02Valentin Popa
blktrace  1.0.5+gitAUTOINC+d6918c8  
1.0.5+gitAUTOINC+ce9ded7  Tom Zanussi
systemtap-uprobes 2.5+gitAUTOINC+8f0fcd995f 
2.5+gitAUTOINC+2d186d3Tom Zanussi
sysprof   1.2.0+gitAUTOINC+cd44ee6  
1.2.0+gitAUTOINC+6901897  Tom Zanussi
libusb1   1.0.181.0.19  
  Saul Wold
mkelfimage4.0+gitAUTOINC+686a48a339 
4.0+gitAUTOINC+da09d02Saul Wold   
 
dpkg  1.17.41.17.10 
  Saul Wold
glib-networking   2.38.02.40.1  
  Saul WoldPending Glib-2.0 
Update   
gnupg 2.0.222.0.23  
  Saul Wold
vte   0.28.20.37.1  
  Saul WoldPending Glib-2.0 
Update   
sqlite3   3.8.4.3   3080500 
  Saul Wold
mx-1.01.4.7+gitAUTOINC+9b1db6b  
1.99.4+gitAUTOINC+63da1f2 Saul Wold   
 PRS 1.99 is dev version   
base-passwd   3.5.293.5.33  
  Saul Wold
libice1.0.8 1.0.9   
  Ross Burton
libxfont  1.4.7 1.4.8   
  Ross Burton 

Re: [yocto] Python3-distribute-native build fails in daisy

2014-06-08 Thread Andreas Galauner
On 08/06/14 11:45, Diego Sueiro wrote:
> I'm getting the same problem for python3-distribute. Take a look bug
> #6373 .
> Try to do a "bitbake python3-native -fccompile ; bitbake python3-native
> -f" and see if you can go further than me.

That worked, thanks!
It's at least a workaround.

- Andy

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto


Re: [yocto] beaglebone black usb device problem (daisy)

2014-06-08 Thread Bruce Ashfield

On 2014-06-03, 6:06 AM, Daniel Groß wrote:

Hello there,
I have successfully build several beaglebone (qt4embedded demo and
sato+mono hard float) images using yocto 1.6 (daisy) for the beagle bone
black.

However USB devices (mouse, keyboard, anything) are only found during
the first boot.

I narrowed the problem down to the file "/etc/udev/cache.data". If I
remove this file and boot again (using the serial console), USB works
once for the next boot process.

After some try and error, I was able to restart the USB enumeration by
issuing a "udevadm trigger" command again using the serial console. That
always works. To me it seems that USB root hub is not loaded by udev if
the /etc/udev/cache.data file exists.

The output of the trigger command is:
root@beaglebone:~# udevadm trigger
udevadm trigger
47401300.usb-phy supply vcc not found, using dummy regulator
47401b00.usb-phy supply vcc not found, using dummy regulator
omap_rng 4831.rng: OMAP Random Number Generator ver. 20
root@beaglebone:~# musb-hdrc musb-hdrc.0.auto: MUSB HDRC host driver
musb-hdrc musb-hdrc.0.auto: new USB bus registered, assigned bus number 1
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 1 port detected
musb-hdrc musb-hdrc.1.auto: MUSB HDRC host driver
musb-hdrc musb-hdrc.1.auto: new USB bus registered, assigned bus number 2
hub 2-0:1.0: USB hub found
hub 2-0:1.0: 1 port detected
usb 2-1: new low-speed USB device number 2 using musb-hdrc
input: Logitech USB Optical Mouse as
/devices/ocp.3/4740.usb/47401c00.usb/musb-hdrc.1.auto/usb2/2-1/2-1:1.0/0003:046D:C00C.0001/input/input0
hid-generic 0003:046D:C00C.0001: input: USB HID v1.10 Mouse [Logitech
USB Optical Mouse] on usb-musb-hdrc.1.auto-1/input0

The content of the /etc/udev/cache.data file is:
root@beaglebone:~# cat /etc/udev/cache.data
cat /etc/udev/cache.data
Linux version 3.14.0-yocto-standard (daniel@daniel-ubuntu) (gcc version
4.8.2 (GCC) ) #1 PREEMPT Sat May 24 16:40:23 CEST
2014console=ttyO0,115200n8 root=/dev/mmcblk0p2 ro rootfstype=ext4
rootwaitCharacter devices:1 mem2 pty3 ttyp4 /dev/vc/04 tty5 /dev/tty5
/dev/console5 /dev/ptmx7 vcs10 misc13 input29 fb89 i2c90 mtd128 ptm136
pts180 usb189 usb_device226 drm250 ttySDIO251 ttyO252 bsg253 watchdog254
rtcBlock devices:1 ramdisk259 blkext8 sd31 mtdblock65 sd66 sd67 sd68
sd69 sd70 sd71 sd128 sd129 sd130 sd131 sd132 sd133 sd134 sd135 sd179 mmc


For the sake of completeness:
root@beaglebone:~# uname -a
uname -a
Linux beaglebone 3.14.0-yocto-standard #1 PREEMPT Sat May 24 16:40:23
CEST 2014 armv7l GNU/Linux


Did anyone else see these problems? And is this a bug - or a feature?


I've never seen this myself. But it is worth logging this in the Yocto
bugzilla with a request for the QA team to confirm that they don't see
this during beaglebone testing.

Bruce




Daniel




--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto


[yocto] [PATCH] add license file: DMTF

2014-06-08 Thread Yao Xinpan
hi all
I want to add software which associates with DMTF into rootfs.
There is WARNING as follows when build:
"WARNING: cim-schema: No generic license file exists for: DMTF in any provider"

Could add license DMTF into yocto?

Signed-off-by: Yao Xinpan 
---
 meta/files/common-licenses/DMTF | 34 ++
 1 file changed, 34 insertions(+)
 create mode 100644 meta/files/common-licenses/DMTF

diff --git a/meta/files/common-licenses/DMTF b/meta/files/common-licenses/DMTF
new file mode 100644
index 000..54a2812
--- /dev/null
+++ b/meta/files/common-licenses/DMTF
@@ -0,0 +1,34 @@
+// Copyright 1998-2008 Distributed Management Task Force, Inc. (DMTF).
+// All rights reserved.
+// DMTF is a not-for-profit association of industry members dedicated
+// to promoting enterprise and systems management and interoperability.
+// DMTF specifications and documents may be reproduced by
+// members and non-members, provided that correct attribution is given.
+// As DMTF specifications may be revised from time to time,
+// the particular version and release date should always be noted.
+// 
+// Implementation of certain elements of this standard or proposed
+// standard may be subject to third party patent rights, including
+// provisional patent rights (herein "patent rights"). DMTF makes
+// no representations to users of the standard as to the existence
+// of such rights, and is not responsible to recognize, disclose, or
+// identify any or all such third party patent right, owners or
+// claimants, nor for any incomplete or inaccurate identification or
+// disclosure of such rights, owners or claimants. DMTF shall have no
+// liability to any party, in any manner or circumstance, under any
+// legal theory whatsoever, for failure to recognize, disclose, or
+// identify any such third party patent rights, or for such party's
+// reliance on the standard or incorporation thereof in its product,
+// protocols or testing procedures. DMTF shall have no liability to
+// any party implementing such standard, whether such implementation
+// is foreseeable or not, nor to any patent owner or claimant, and shall
+// have no liability or responsibility for costs or losses incurred if
+// a standard is withdrawn or modified after publication, and shall be
+// indemnified and held harmless by any party implementing the
+// standard from any and all claims of infringement by a patent owner
+// for such implementations.
+// 
+// For information about patents held by third-parties which have
+// notified the DMTF that, in their opinion, such patent may relate to
+// or impact implementations of DMTF standards, visit
+// http://www.dmtf.org/about/policies/disclosures.php.
-- 
1.8.4.2

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto