Re: [yocto] [meta-raspberrypi][PATCH] firmware.inc: Fetch a zip instead of cloning a git repo

2015-07-05 Thread Clemens Lang
Hello,

On Fri, Jun 26, 2015 at 09:31:14AM +0100, Burton, Ross wrote:
> Github also can and will regenerate these tarballs whenever it feels
> like it, so you'll need to periodically update the checksums.
> Obviously as existing developers will tend to have the tarballs cached
> locally, it can be a while before this failure is reported back.

While that does happen from time to time it's pretty rare. I see maybe
one case of this every couple of months in MacPorts. Additionally, after
a while the checksums generally change back again in almost all cases.

So, yes, this brings its own set of problems, but is still a worthwhile
improvement over the current situation IMO.


Best regards,
Clemens
-- 
Clemens Lang • Development Specialist
BMW Car IT GmbH • Lise-Meitner-Str. 14 • 89081 Ulm • http://bmw-carit.com
-
BMW Car IT GmbH
Geschäftsführer: Michael Würtenberger und Reinhard Stolle
Sitz und Registergericht: München HRB 134810
-
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto


Re: [yocto] OpenCV yocto

2015-07-05 Thread Victor Rodriguez
On Mon, Jun 22, 2015 at 9:14 AM, Leonardo Sandoval
 wrote:
>
>
> On 06/20/2015 09:22 PM, Victor Rodriguez wrote:
>>
>> HI team
>>
>> I am having this same problem:
>>
>>
>> http://stackoverflow.com/questions/25332969/opencv-pkg-config-cannot-find-lopencv-ts-when-compiling-using-g
>>
>> I try to build opencv simple source code :
>>
>> g++ hello.cpp -o video `pkg-config --cflags --libs opencv`
>>
> Victor, you may take at look at this recipe (opencv_samples)
>
> http://cgit.openembedded.org/cgit.cgi/meta-openembedded/tree/meta-oe/recipes-support/opencv/opencv-samples_2.4.bb?h=master
>
> What I can see, seems that the `pkg-config --libs openvc` is missing on your
> bb.


Thanks for the help Leo , aparently the missing part was :

opencv-staticdev

My local.conf ended like :

# CONF_VERSION is increased each time build/conf/ changes incompatibly
and is used to
# track the version of this file when it was generated. This can
safely be ignored if
# this doesn't mean anything to you.
CONF_VERSION = "1"
IMAGE_INSTALL_append = " gcc gcc-dev openssh php mariadb opencv opencv-samples"
#IMAGE_INSTALL_append = " mpich mpich-dev"
IMAGE_INSTALL_append = " libopencv-core-dev libopencv-highgui-dev
libopencv-imgproc-dev libopencv-objdetect-dev libopencv-ml-dev
opencv-staticdev"
LICENSE_FLAGS_WHITELIST = "commercial"


IMAGE_FEATURES += "package-management"
MACHINE = "intel-corei7-64"

I learned in the hard way that CORE_IMAGE_EXTRA_INSTALL and
IMAGE_INSTALL_append are nto the same when I build for xfce the
CORE_IMAGE_EXTRA_INSTALL is not taking into consideration

After that opencv is working like a charm

Now I am having problems to come up the web cam , do you know any part
that might be missing ?

If I do lsusb  the webcam is detected( I check and the driver is
enable as module in make menuconfig )  , but when I try to run this
code , It return as if the camera were not found

https://github.com/VictorRodriguez/opencv_tutorial

I might be missing gstream or something :(

Thanks a lot for the help

>
>> But got this error :
>>
>> /usr/lib/gcc/i586-poky-linux/4.9.2/../../../../i586-poky-linux/bin/ld:
>> cannot find -lopencv_ts
>> collect2: error: ld returned 1 exit status
>>
>> My local.conf is like this :
>>
>> EXTRA_IMAGE_FEATURES = "debug-tweaks tools-sdk"
>> IMAGE_INSTALL_append = " mpich mpich-dev gcc gcc-dev openssh php mariadb
>> opencv"
>> LICENSE_FLAGS_WHITELIST = "commercial"
>> CORE_IMAGE_EXTRA_INSTALL += "libopencv-core-dev libopencv-highgui-dev
>> libopencv-imgproc-dev libopencv-objdetect-dev libopencv-ml-dev"
>>
>>
>> All the help is more than welcome
>>
>> Best regards
>>
>> Victor Rodriguez
>>
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto


Re: [yocto] [meta-raspberrypi][PATCH] firmware.inc: Fetch a zip instead of cloning a git repo

2015-07-05 Thread Petter Mabäcker

On 06/26/2015 04:16 PM, Jon Szymaniak wrote:
On Fri, Jun 26, 2015 at 4:31 AM, Burton, Ross > wrote:



On 26 June 2015 at 05:16, Jon Szymaniak mailto:jon.szyman...@gmail.com>> wrote:

GitHub provides this ability to download repository contents at
a specified changeset as a zip file. This is generally *much*
quicker
than fetching the entire git repository.


Github also can and will regenerate these tarballs whenever it
feels like it, so you'll need to periodically update the
checksums.  Obviously as existing developers will tend to have the
tarballs cached locally, it can be a while before this failure is
reported back.

A better solution might be to add support for "depth" to the git
fetcher, so you can grab just the commit you are interested in
instead of the entire repository.

Ross


Hi Ross,

Excellent point about the regeneration potentially yielding different 
checksums.  I suppose they could change the compression level they use 
at any moment in time... I'll look into adding that depth support to 
the fetcher, as that doesn't look too hard at all.


I'm open to other suggestions as well, as this was just a first stab 
at it. I've been seeing that cloning this git repo containing binary 
firmware blobs takes an absurd amount of time, if it even finishes at 
all successfully.


Cheers,
Jon




Hi Jon,

Any news about this? I have also used a very similar changeset like you 
suggests (use .zip from github) ontop of meta-raspberrypi when building, 
to get rid of the annoying problem that it takes a very long time or 
even worse that you get a timeout.


My suggestion is to go for the .zip changeset at least until --depth=1 
is supported in the git fetcher.


@Andrei any comments from your side regarding this discussion?

BR,
Petter


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


Re: [yocto] [meta-raspberrypi][PATCH] firmware.inc: fetch from SVN instead of Git

2015-07-05 Thread Petter Mabäcker

On 07/04/2015 07:29 AM, Nikolay Dimitrov wrote:

Hi Jonathan,

On 07/04/2015 06:48 AM, Jonathan Liu wrote:

Reduces the download time significantly.

Signed-off-by: Jonathan Liu 
---
  recipes-bsp/common/firmware.inc | 6 +++---
  1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/recipes-bsp/common/firmware.inc 
b/recipes-bsp/common/firmware.inc

index ad3176a..100df3a 100644
--- a/recipes-bsp/common/firmware.inc
+++ b/recipes-bsp/common/firmware.inc
@@ -1,7 +1,7 @@
-RPIFW_SRCREV ?= "e42a747e8d5c4a2fb3e837d0924c7cc3936a"
+RPIFW_SRCREV ?= "461"
  RPIFW_DATE ?= "20150206"
-RPIFW_SRC_URI ?= 
"git://github.com/raspberrypi/firmware.git;protocol=git;branch=master"

-RPIFW_S ?= "${WORKDIR}/git"
+RPIFW_SRC_URI ?= 
"svn://github.com/raspberrypi/firmware;protocol=https;module=trunk"

+RPIFW_S ?= "${WORKDIR}/trunk"

  SRC_URI = "${RPIFW_SRC_URI}"
  SRCREV = "${RPIFW_SRCREV}"



Just tested the download times for this repo:

git (deep clone): 24m
svn: 3m8s
git (shallow clone): 40s

Isn't it possible to use "--depth 1" for git clone? I would rather
prefer seeing this instead of just giving up and going back to svn...

Regards,
Nikolay
Jonathan, I understand your problem, I have pointed out 
"https://github.com/raspberrypi/firmware/archive/${RPIFW_SRCREV}.zip"; 
ontop of HEAD when building in order to get rid of this problem. But I 
agree with Nikolay that going back to svn feels like a step in the wrong 
direction and instead we should push for a changle like the one 
discussed in the thread: '[yocto] [meta-raspberrypi][PATCH] 
firmware.inc: Fetch a zip instead of cloning a git repo'


or by using "--depth=1" (which isn't supported in the bitbake git 
fetcher for the moment..).


I will try to push for that one of the solutions (--depth=1 or .zip) is 
merged soon so we once for all can get rid of this annoying problem.


BR,
Petter

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