Re: [yocto] Wildcard in RDEPENDS when exporting perl modules to SDK

[Paul Eggleton]

Hi Joseph,

On Friday 26 September 2014 13:37:29 Joseph Andrew de la Peña wrote:
> I would like to ask how to include all perl modules into nativesdk? I see
> that all RDEPENDS for perl has a prefix of ${PN}-module-perl-*. How can I
> include all perl modules into the nativesdk host package group? Is there a
> wild card that can be used?

There isn't, but you can just add nativesdk-perl-modules to your SDK (via 
appending to TOOLCHAIN_TARGET_TASK) to accomplish the same thing - it's a 
meta-package that will bring in all of the core modules.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] yocto 1.6 - beaglebone black - cape manager

[TakkTakk]

ok, I removed uEnv.txt, pressed the boot switch.
Starting kernel ... and hang.
why - "Image Name:   Linux-3.14.0-yocto-standard " ?

U-Boot SPL 2013.04-dirty (Sep 09 2014 - 21:38:22)
musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx, SoftConn)
musb-hdrc: MHDRC RTL version 2.0
musb-hdrc: setup fifo_mode 4
musb-hdrc: 28/31 max ep, 16384/16384 memory
USB Peripheral mode controller at 47401000 using PIO, IRQ 0
musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx, SoftConn)
musb-hdrc: MHDRC RTL version 2.0
musb-hdrc: setup fifo_mode 4
musb-hdrc: 28/31 max ep, 16384/16384 memory
USB Host mode controller at 47401800 using PIO, IRQ 0
OMAP SD/MMC: 0
reading u-boot.img
reading u-boot.img


U-Boot 2013.04-dirty (Sep 09 2014 - 21:38:22)

I2C:   ready
DRAM:  512 MiB
WARNING: Caches not enabled
NAND:  No NAND device found!!!
0 MiB
MMC:   OMAP SD/MMC: 0, OMAP SD/MMC: 1
*** Warning - readenv() failed, using default environment

musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx,
SoftConn)
musb-hdrc: MHDRC RTL version 2.0
musb-hdrc: setup fifo_mode 4
musb-hdrc: 28/31 max ep, 16384/16384 memory
USB Peripheral mode controller at 47401000 using PIO, IRQ 0
musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx,
SoftConn)
musb-hdrc: MHDRC RTL version 2.0
musb-hdrc: setup fifo_mode 4
musb-hdrc: 28/31 max ep, 16384/16384 memory
USB Host mode controller at 47401800 using PIO, IRQ 0
Net:not set. Validating first E-fuse MAC
cpsw, usb_ether
Hit any key to stop autoboot:  0
gpio: pin 53 (gpio 53) value is 1
mmc0 is current device
micro SD card found
mmc0 is current device
gpio: pin 54 (gpio 54) value is 1
SD/MMC found on device 0
reading uEnv.txt
** Unable to read file uEnv.txt **
gpio: pin 55 (gpio 55) value is 1
4985736 bytes read in 957 ms (5 MiB/s)
gpio: pin 56 (gpio 56) value is 1
24868 bytes read in 92 ms (263.7 KiB/s)
Booting from mmc ...
## Booting kernel from Legacy Image at 80007fc0 ...
   Image Name:   Linux-3.14.0-yocto-standard
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:4985672 Bytes = 4.8 MiB
   Load Address: 80008000
   Entry Point:  80008000
   Verifying Checksum ... OK
## Flattened Device Tree blob at 80f8
   Booting using the fdt blob at 0x80f8
   XIP Kernel Image ... OK
OK
   Using Device Tree in place at 80f8, end 80f89123

Starting kernel ...

2014-09-25 14:18 GMT+02:00 Diego Sueiro :
> Takk,
>
> On Wed, Sep 24, 2014 at 5:20 PM, TakkTakk  wrote:
>>
>> ok, i changed "bootz" to "bootm" and i kept S2 swith pressed.
>> Yocto not booting, two leds D2, D3 is shining.
>>
>> Serial console output:
>>
>> U-Boot SPL 2013.04-dirty (Sep 09 2014 - 21:38:22)
>> musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx,
>> SoftConn)
>> musb-hdrc: MHDRC RTL version 2.0
>> musb-hdrc: setup fifo_mode 4
>> musb-hdrc: 28/31 max ep, 16384/16384 memory
>> USB Peripheral mode controller at 47401000 using PIO, IRQ 0
>> musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx,
>> SoftConn)
>> musb-hdrc: MHDRC RTL version 2.0
>> musb-hdrc: setup fifo_mode 4
>> musb-hdrc: 28/31 max ep, 16384/16384 memory
>> USB Host mode controller at 47401800 using PIO, IRQ 0
>> OMAP SD/MMC: 0
>> reading u-boot.img
>> reading u-boot.img
>>
>>
>> U-Boot 2013.04-dirty (Sep 09 2014 - 21:38:22)
>>
>> I2C:   ready
>> DRAM:  512 MiB
>> WARNING: Caches not enabled
>> NAND:  No NAND device found!!!
>> 0 MiB
>> MMC:   OMAP SD/MMC: 0, OMAP SD/MMC: 1
>> *** Warning - readenv() failed, using default environment
>>
>> musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx,
>> SoftConn)
>> musb-hdrc: MHDRC RTL version 2.0
>> musb-hdrc: setup fifo_mode 4
>> musb-hdrc: 28/31 max ep, 16384/16384 memory
>> USB Peripheral mode controller at 47401000 using PIO, IRQ 0
>> musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx,
>> SoftConn)
>> musb-hdrc: MHDRC RTL version 2.0
>> musb-hdrc: setup fifo_mode 4
>> musb-hdrc: 28/31 max ep, 16384/16384 memory
>> USB Host mode controller at 47401800 using PIO, IRQ 0
>> Net:not set. Validating first E-fuse MAC
>> cpsw, usb_ether
>> Hit any key to stop autoboot:  0
>> gpio: pin 53 (gpio 53) value is 1
>> mmc0 is current device
>> micro SD card found
>> mmc0 is current device
>> gpio: pin 54 (gpio 54) value is 1
>> SD/MMC found on device 0
>> reading uEnv.txt
>> 527 bytes read in 4 ms (127.9 KiB/s)
>> Loaded environment from uEnv.txt
>> Importing environment from mmc ...
>> Running uenvcmd ...
>> reading uImage
>> 4368264 bytes read in 499 ms (8.3 MiB/s)
>> reading /dtbs/am335x-boneblack.dtb
>> 29192 bytes read in 10 ms (2.8 MiB/s)
>> ## Booting kernel from Legacy Image at 8020 ...
>>Image Name:   Linux-3.8.13
>>Image Type:   ARM Linux Kernel Image (uncompressed)
>>Data Size:4368200 Bytes = 4.2 MiB
>>Load Address: 80008000
>>Entry Point:  80008000
>>Verifying Checksum ... OK
>> ## Flattened Device Tree blob at 80f8
>>Booting using the fdt blob

Re: [yocto] yocto 1.6 - beaglebone black - cape manager

[Maciej Borzecki]

On Friday 26 of September 2014 15:17:52 TakkTakk wrote:
> ok, I removed uEnv.txt, pressed the boot switch.
> Starting kernel ... and hang.
> why - "Image Name:   Linux-3.14.0-yocto-standard " ?

I'd recommend switching to current master (what is to be 1.7 soon), skipping 
meta-beaglebone for now and build core-image-minimal. Then prepare SD card 
image either manually or with wic and try booting that. I'm doing such builds 
every couple of days, so far without too many problems.

Once you get that working, add meta-beaglebone layer, handpick kernel/u-boot 
versions if needed, add whatever extra packages you need. Best if you do it 
step by step.

> 
> U-Boot SPL 2013.04-dirty (Sep 09 2014 - 21:38:22)
> musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx,
> SoftConn) musb-hdrc: MHDRC RTL version 2.0
> musb-hdrc: setup fifo_mode 4
> musb-hdrc: 28/31 max ep, 16384/16384 memory
> USB Peripheral mode controller at 47401000 using PIO, IRQ 0
> musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx,
> SoftConn) musb-hdrc: MHDRC RTL version 2.0
> musb-hdrc: setup fifo_mode 4
> musb-hdrc: 28/31 max ep, 16384/16384 memory
> USB Host mode controller at 47401800 using PIO, IRQ 0
> OMAP SD/MMC: 0
> reading u-boot.img
> reading u-boot.img
> 
> 
> U-Boot 2013.04-dirty (Sep 09 2014 - 21:38:22)
> 
> I2C:   ready
> DRAM:  512 MiB
> WARNING: Caches not enabled
> NAND:  No NAND device found!!!
> 0 MiB
> MMC:   OMAP SD/MMC: 0, OMAP SD/MMC: 1
> *** Warning - readenv() failed, using default environment
> 
> musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx,
> SoftConn)
> musb-hdrc: MHDRC RTL version 2.0
> musb-hdrc: setup fifo_mode 4
> musb-hdrc: 28/31 max ep, 16384/16384 memory
> USB Peripheral mode controller at 47401000 using PIO, IRQ 0
> musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx,
> SoftConn)
> musb-hdrc: MHDRC RTL version 2.0
> musb-hdrc: setup fifo_mode 4
> musb-hdrc: 28/31 max ep, 16384/16384 memory
> USB Host mode controller at 47401800 using PIO, IRQ 0
> Net:not set. Validating first E-fuse MAC
> cpsw, usb_ether
> Hit any key to stop autoboot:  0
> gpio: pin 53 (gpio 53) value is 1
> mmc0 is current device
> micro SD card found
> mmc0 is current device
> gpio: pin 54 (gpio 54) value is 1
> SD/MMC found on device 0
> reading uEnv.txt
> ** Unable to read file uEnv.txt **
> gpio: pin 55 (gpio 55) value is 1
> 4985736 bytes read in 957 ms (5 MiB/s)
> gpio: pin 56 (gpio 56) value is 1
> 24868 bytes read in 92 ms (263.7 KiB/s)
> Booting from mmc ...
> ## Booting kernel from Legacy Image at 80007fc0 ...
>Image Name:   Linux-3.14.0-yocto-standard
>Image Type:   ARM Linux Kernel Image (uncompressed)
>Data Size:4985672 Bytes = 4.8 MiB
>Load Address: 80008000
>Entry Point:  80008000
>Verifying Checksum ... OK
> ## Flattened Device Tree blob at 80f8
>Booting using the fdt blob at 0x80f8
>XIP Kernel Image ... OK
> OK
>Using Device Tree in place at 80f8, end 80f89123
> 
> Starting kernel ...
> 
> 2014-09-25 14:18 GMT+02:00 Diego Sueiro :
> > Takk,
> > 
> > On Wed, Sep 24, 2014 at 5:20 PM, TakkTakk  wrote:
> >> ok, i changed "bootz" to "bootm" and i kept S2 swith pressed.
> >> Yocto not booting, two leds D2, D3 is shining.
> >> 
> >> Serial console output:
> >> 
> >> U-Boot SPL 2013.04-dirty (Sep 09 2014 - 21:38:22)
> >> musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx,
> >> SoftConn)
> >> musb-hdrc: MHDRC RTL version 2.0
> >> musb-hdrc: setup fifo_mode 4
> >> musb-hdrc: 28/31 max ep, 16384/16384 memory
> >> USB Peripheral mode controller at 47401000 using PIO, IRQ 0
> >> musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx,
> >> SoftConn)
> >> musb-hdrc: MHDRC RTL version 2.0
> >> musb-hdrc: setup fifo_mode 4
> >> musb-hdrc: 28/31 max ep, 16384/16384 memory
> >> USB Host mode controller at 47401800 using PIO, IRQ 0
> >> OMAP SD/MMC: 0
> >> reading u-boot.img
> >> reading u-boot.img
> >> 
> >> 
> >> U-Boot 2013.04-dirty (Sep 09 2014 - 21:38:22)
> >> 
> >> I2C:   ready
> >> DRAM:  512 MiB
> >> WARNING: Caches not enabled
> >> NAND:  No NAND device found!!!
> >> 0 MiB
> >> MMC:   OMAP SD/MMC: 0, OMAP SD/MMC: 1
> >> *** Warning - readenv() failed, using default environment
> >> 
> >> musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx,
> >> SoftConn)
> >> musb-hdrc: MHDRC RTL version 2.0
> >> musb-hdrc: setup fifo_mode 4
> >> musb-hdrc: 28/31 max ep, 16384/16384 memory
> >> USB Peripheral mode controller at 47401000 using PIO, IRQ 0
> >> musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx,
> >> SoftConn)
> >> musb-hdrc: MHDRC RTL version 2.0
> >> musb-hdrc: setup fifo_mode 4
> >> musb-hdrc: 28/31 max ep, 16384/16384 memory
> >> USB Host mode controller at 47401800 using PIO, IRQ 0
> >> Net:not set. Validating first E-fuse MAC
> >> cpsw, usb_ether
> >> Hit any key to stop autoboot:  0
> >> gpio: pin 53 (gpio 53) value is 1
> >> mmc0 is current d

Re: [yocto] [OE-core] [PATCH] bash: update to latest (025) patchset (fixes CVE-2014-6271)

[Mark Hatle]

On 9/25/14, 10:00 PM, Francesco Del Degan wrote:

Yes, patch 026 that fixes CVE-2014-7169 is underway, should be pushed out today:

http://www.openwall.com/lists/oss-security/2014/09/26/1

bash-4.2 (as in dora) got patch048 for CVE-2014-6179 and should receive patch049
as well.

I'm going to send bash 3.2 and 4.2  patches in oe core ml.


There are two additional issues as well.

CVE-2014-7186 - bash: parser can allow out-of-bounds memory access while
handling redir_stack

CVE-2014-7187 - bash: off-by-one error in deeply nested flow control constructs

(The above two are so new they are not yet published on the CVE web sites.)

A patch for these has been posted to the oss-security list, but has not yet been 
validated by the bash maintainer.


We'll need to watch for this as well.

--Mark



On Fri, Sep 26, 2014 at 1:15 AM, Burton, Ross mailto:ross.bur...@intel.com>> wrote:

On 25 September 2014 23:48, Mark Hatle mailto:mark.ha...@windriver.com>> wrote:
> So I would recommend that someone get the 025 patch (don't forget to patch
> bash 3.2 as well) in.. and we should wait until their is an official one 
for
> 7169.

Agreed, and patches sent.

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




--
--
:: e n d i a n
:: security with passion

:: Francesco Del Degan
:: software engineer
:: http://www.endian.com   :: f.deldegan (AT) endian.com





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

Re: [yocto] Adding 'build-id' to Build Image

[Philip Balister]

I added https://bugzilla.yoctoproject.org/show_bug.cgi?id=6770

Sorry no patch yet :)

Philip

On 09/10/2014 12:38 AM, Paul Eggleton wrote:
> On Tuesday 09 September 2014 15:03:39 Philip Balister wrote:
>> On 09/08/2014 07:08 PM, Leo Schwab wrote:
>>> We'd like to have the system images we build to contain a build id, or
>>> at least a pile of information inside the image itself that lets us
>>> identify which build is being run/tested.  Indeed, the information
>>> 'bitbake' kicks out just as it starts a build is exactly the sort of
>>> thing we'd like sitting in a file in the image somewhere.
>>>
>>> I turned on the 'buildhistory' feature in conf/local.conf which, among
>>> other things, generates a 'build-id' file.  However, it doesn't place
>>> it in the image, but in an entirely separate directory hierarchy.
>>>
>>> Surely this sort of thing has been done before.  Is there an existing
>>> recipe I can use, or will I have to cobble together a custom recipe
>>> out of buildhistory_get_layers() or get_layers_branch_rev()?
>>
>> I was asking the same question yesterday. I have a hacky solution for my
>> immediate need, but I'd like a long term solution along these lines also.
>>
>> Should we add this to bugzilla and see if we can get it done for 1.8? (I
>> think I ahve the version number right)
> 
> Yes, please add this to the bugzilla. This has also come up before several 
> times, we should just do it (and bonus points if someone wants to send a 
> patch 
> ;).
> 
> Cheers,
> Paul
> 
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Ccompiler on 3.8.11-yocto-standard

[eublack]

Looking to install C compiler on the above. Any links or documentation would be 
appreciated.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Adding 'build-id' to Build Image

[Douglas Geiger]

I've attached a build_info.inc that I've used in some of my image to the
issue - comments welcome.
Currently I include a build timestamp, and the names and version info on
all the layers used in the build and put it in /etc/build

 Doug

On Fri, Sep 26, 2014 at 1:09 PM, Philip Balister 
wrote:

> I added https://bugzilla.yoctoproject.org/show_bug.cgi?id=6770
>
> Sorry no patch yet :)
>
> Philip
>
> On 09/10/2014 12:38 AM, Paul Eggleton wrote:
> > On Tuesday 09 September 2014 15:03:39 Philip Balister wrote:
> >> On 09/08/2014 07:08 PM, Leo Schwab wrote:
> >>> We'd like to have the system images we build to contain a build id, or
> >>> at least a pile of information inside the image itself that lets us
> >>> identify which build is being run/tested.  Indeed, the information
> >>> 'bitbake' kicks out just as it starts a build is exactly the sort of
> >>> thing we'd like sitting in a file in the image somewhere.
> >>>
> >>> I turned on the 'buildhistory' feature in conf/local.conf which, among
> >>> other things, generates a 'build-id' file.  However, it doesn't place
> >>> it in the image, but in an entirely separate directory hierarchy.
> >>>
> >>> Surely this sort of thing has been done before.  Is there an existing
> >>> recipe I can use, or will I have to cobble together a custom recipe
> >>> out of buildhistory_get_layers() or get_layers_branch_rev()?
> >>
> >> I was asking the same question yesterday. I have a hacky solution for my
> >> immediate need, but I'd like a long term solution along these lines
> also.
> >>
> >> Should we add this to bugzilla and see if we can get it done for 1.8? (I
> >> think I ahve the version number right)
> >
> > Yes, please add this to the bugzilla. This has also come up before
> several
> > times, we should just do it (and bonus points if someone wants to send a
> patch
> > ;).
> >
> > Cheers,
> > Paul
> >
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>



-- 
Doug Geiger
doug.gei...@bioradiation.net
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Adding 'build-id' to Build Image

[Douglas Geiger]

FWIW: most of that file is based off a discussion from back in 2012 - I
think Marc Ferland posted a similar file to the list.

On Fri, Sep 26, 2014 at 1:55 PM, Douglas Geiger <
doug.gei...@bioradiation.net> wrote:

> I've attached a build_info.inc that I've used in some of my image to the
> issue - comments welcome.
> Currently I include a build timestamp, and the names and version info on
> all the layers used in the build and put it in /etc/build
>
>  Doug
>
> On Fri, Sep 26, 2014 at 1:09 PM, Philip Balister 
> wrote:
>
>> I added https://bugzilla.yoctoproject.org/show_bug.cgi?id=6770
>>
>> Sorry no patch yet :)
>>
>> Philip
>>
>> On 09/10/2014 12:38 AM, Paul Eggleton wrote:
>> > On Tuesday 09 September 2014 15:03:39 Philip Balister wrote:
>> >> On 09/08/2014 07:08 PM, Leo Schwab wrote:
>> >>> We'd like to have the system images we build to contain a build id, or
>> >>> at least a pile of information inside the image itself that lets us
>> >>> identify which build is being run/tested.  Indeed, the information
>> >>> 'bitbake' kicks out just as it starts a build is exactly the sort of
>> >>> thing we'd like sitting in a file in the image somewhere.
>> >>>
>> >>> I turned on the 'buildhistory' feature in conf/local.conf which, among
>> >>> other things, generates a 'build-id' file.  However, it doesn't place
>> >>> it in the image, but in an entirely separate directory hierarchy.
>> >>>
>> >>> Surely this sort of thing has been done before.  Is there an existing
>> >>> recipe I can use, or will I have to cobble together a custom recipe
>> >>> out of buildhistory_get_layers() or get_layers_branch_rev()?
>> >>
>> >> I was asking the same question yesterday. I have a hacky solution for
>> my
>> >> immediate need, but I'd like a long term solution along these lines
>> also.
>> >>
>> >> Should we add this to bugzilla and see if we can get it done for 1.8?
>> (I
>> >> think I ahve the version number right)
>> >
>> > Yes, please add this to the bugzilla. This has also come up before
>> several
>> > times, we should just do it (and bonus points if someone wants to send
>> a patch
>> > ;).
>> >
>> > Cheers,
>> > Paul
>> >
>> --
>> ___
>> yocto mailing list
>> yocto@yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/yocto
>>
>
>
>
> --
> Doug Geiger
> doug.gei...@bioradiation.net
>



-- 
Doug Geiger
doug.gei...@bioradiation.net
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Ccompiler on 3.8.11-yocto-standard

[Burton, Ross]

On 26 September 2014 18:29,   wrote:
> Looking to install C compiler on the above. Any links or documentation would 
> be appreciated.

The easiest way is when generating your image:

http://www.yoctoproject.org/docs/1.6.1/mega-manual/mega-manual.html#ref-features-image

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

Re: [yocto] Forcing fetch task when source changes

[Burton, Ross]

On 23 September 2014 16:46, Vuille, Martin (Martin)  wrote:
> Very odd.
>
> Our BSP vendor has configured BB_SIGNATURE_HANDLER to use OEBasicHash,
> I see hashes in the stamp file names, if I change the metadata itself the 
> change
> is detected and the tasks are run again, but changing the content of a file 
> named
> in a "file://" SRC_URI has no effect.
>
> Any ideas?

None, sorry.  Possibly you've found a bug in the 1.2-era hashing code.
Can you lean on your BSP provider to stop using 2.5 year old releases?
:/

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

Re: [yocto] Forcing fetch task when source changes

[Vuille, Martin (Martin)]

We're planning an update to Dizzy, and to keep up-to-date after that.

Thanks for your help
MV

> -Original Message-
> From: Burton, Ross [mailto:ross.bur...@intel.com]
> Sent: September 26, 2014 5:55 PM
> To: Vuille, Martin (Martin)
> Cc: yocto@yoctoproject.org
> Subject: Re: [yocto] Forcing fetch task when source changes
> 
> On 23 September 2014 16:46, Vuille, Martin (Martin) 
> wrote:
> > Very odd.
> >
> > Our BSP vendor has configured BB_SIGNATURE_HANDLER to use
> OEBasicHash,
> > I see hashes in the stamp file names, if I change the metadata itself
> > the change is detected and the tasks are run again, but changing the
> > content of a file named in a "file://" SRC_URI has no effect.
> >
> > Any ideas?
> 
> None, sorry.  Possibly you've found a bug in the 1.2-era hashing code.
> Can you lean on your BSP provider to stop using 2.5 year old releases?
> :/
> 
> Ross
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto