[yocto] wlan0: link is not ready ?

[Riko Ho]

Hello everyone,

The board can see the dongle but it can not obtain IP, how to fix it ?



ieee80211 phy0: rt2x00lib_request_firmware: Info - Loading firmware file 
'rt2870.bin'
ieee80211 phy0: rt2x00lib_request_firmware: Info - Firmware detected - 
version: 0.36

IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
udhcpc (v1.24.1) started
Sending discover...
Sending discover...
Sending discover...
No lease, forking to background

--
*

/***/
Sent by Ubuntu LTS 16.04,
谢谢,
Regards,
Riko Ho
/***/

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

[yocto] 47401300.usb-phy supply vcc not found, using dummy regulator

[Riko Ho]

Hi Everyone,

Is my beagleboard usb regulator broken ?

Here's the message I got :



usbcore: registered new interface driver usb-storage
47401300.usb-phy supply vcc not found, using dummy regulator
musb-hdrc musb-hdrc.0.auto: Failed to request rx1.
47401b00.usb-phy supply vcc not found, using dummy regulator

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

Re: [yocto] [PATCH V4 03/10] utils.py: remove obsolete dependencies

[Robert Yang]

Hi Paul,

On 06/23/2017 11:03 AM, Robert Yang wrote:



On 06/22/2017 07:54 PM, Paul Eggleton wrote:

On Thursday, 22 June 2017 12:47:31 PM CEST Robert Yang wrote:

On 06/21/2017 05:06 PM, Paul Eggleton wrote:

So I do see the need to clear out old dependency values when your list of
dependencies is coming entirely from LAYERDEPENDS, however if you have only
manually added dependencies and LAYERDEPENDS is not complete (as is often the
case in the OE layer index), will this automatically remove those? If so I


The dependencies will be removed if it is not in conf/layer.conf.


think we're going to have to come up with some mechanism to avoid that.
Probably the easiest one would be to avoid touching the dependencies unless
LAYERDEPENDS actually changes. Of course if that means we're going to store
the previous LAYERDEPENDS value somewhere to compare to, we'd need to avoid it
triggering initially when none of those values are set.


Why not fix conf/layer.conf rather than fix it from database ? If
conf/layer.conf is wrong, we would meet problems elsewhere.


Up until now it hasn't caused any issues other than not getting an error
up front from bitbake when a dependencies are missing, so it can easily go
unnoticed (particularly when users follow manual instructions or use existing
configurations rather than an automated tool that pays attention to
LAYERDEPENDS).


The database
should obey local.conf when mismatches, otherwise, this would confuse
users a lot when they want to update LAYERDEPENDS.


As I indicated, I agree that if LAYERDEPENDS gets updated then the
dependencies in the database should get updated. My concern is updating
them if LAYERDEPENDS has not changed and it simply happens to have
a difference to what is in the database (most importantly if it has less
dependencies specified).


I'm glad to fix oe-classic's LAYERDEPENDS issues if they are wrong.


Well, it's not so much OE-Classic as every single layer in the index,
maintained by a number of different maintainers. I agree in the long term we
do want people to fix their dependencies. The trouble is we don't
even know the size of the problem at the moment, and if it's widespread
then we'll end up dropping dependencies potentially leading to errors during
parsing.

How about this - could we start with a setting in the configuration that
specifies that dependencies should be updated automatically, and if not
set just gives a warning if the dependencies are not the same? We can
then decide how to handle it when we see the warnings we're getting in
the OE index.


Sounds good to me, I will fix it in V5.


After more thinking, I will use:
# Remove layer dependencies if it is not in conf/layer.conf
REMOVE_LAYER_DEPENDENCIES = False

Currently it does can add dependencies from conf/layer.conf, but no remove,
so use REMOVE_LAYER_DEPENDENCIES makes it more clear.

// Robert



// Robert



Cheers,
Paul


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

Re: [yocto] [PATCH V4 03/10] utils.py: remove obsolete dependencies

[Robert Yang]

On 06/22/2017 07:54 PM, Paul Eggleton wrote:

On Thursday, 22 June 2017 12:47:31 PM CEST Robert Yang wrote:

On 06/21/2017 05:06 PM, Paul Eggleton wrote:

So I do see the need to clear out old dependency values when your list of
dependencies is coming entirely from LAYERDEPENDS, however if you have only
manually added dependencies and LAYERDEPENDS is not complete (as is often the
case in the OE layer index), will this automatically remove those? If so I


The dependencies will be removed if it is not in conf/layer.conf.


think we're going to have to come up with some mechanism to avoid that.
Probably the easiest one would be to avoid touching the dependencies unless
LAYERDEPENDS actually changes. Of course if that means we're going to store
the previous LAYERDEPENDS value somewhere to compare to, we'd need to avoid it
triggering initially when none of those values are set.


Why not fix conf/layer.conf rather than fix it from database ? If
conf/layer.conf is wrong, we would meet problems elsewhere.


Up until now it hasn't caused any issues other than not getting an error
up front from bitbake when a dependencies are missing, so it can easily go
unnoticed (particularly when users follow manual instructions or use existing
configurations rather than an automated tool that pays attention to
LAYERDEPENDS).


The database
should obey local.conf when mismatches, otherwise, this would confuse
users a lot when they want to update LAYERDEPENDS.


As I indicated, I agree that if LAYERDEPENDS gets updated then the
dependencies in the database should get updated. My concern is updating
them if LAYERDEPENDS has not changed and it simply happens to have
a difference to what is in the database (most importantly if it has less
dependencies specified).


I'm glad to fix oe-classic's LAYERDEPENDS issues if they are wrong.


Well, it's not so much OE-Classic as every single layer in the index,
maintained by a number of different maintainers. I agree in the long term we
do want people to fix their dependencies. The trouble is we don't
even know the size of the problem at the moment, and if it's widespread
then we'll end up dropping dependencies potentially leading to errors during
parsing.

How about this - could we start with a setting in the configuration that
specifies that dependencies should be updated automatically, and if not
set just gives a warning if the dependencies are not the same? We can
then decide how to handle it when we see the warnings we're getting in
the OE index.


Sounds good to me, I will fix it in V5.

// Robert



Cheers,
Paul


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

Re: [yocto] [PATCH V4 06/10] update.py: update layers orderly

[Robert Yang]

On 06/22/2017 07:33 PM, Paul Eggleton wrote:

Hi Robert,

On Thursday, 22 June 2017 1:04:23 PM CEST Robert Yang wrote:

On 06/21/2017 10:21 PM, Paul Eggleton wrote:

On Tuesday, 13 June 2017 4:36:47 AM CEST Robert Yang wrote:

--- a/layerindex/update_layer.py
+++ b/layerindex/update_layer.py

...

+def get_layer_var(config_data, var):
+collection = config_data.getVar('BBFILE_COLLECTIONS', True)


This makes the assumption that the layer.conf only adds one collection
to BBFILE_COLLECTIONS. Probably a valid assumption 99.9% of the time these
days, but it is worth noting.


Should we check all BBFILE_COLLECTIONS, please ?


I would say let's split the value and use the first one, but if there is more
than one then warn e.g. "Multiple collections found, handling first one (%s)
only" but otherwise continue processing. That way at least we'll know if this
situation occurs.


Thanks, good idea, I will update it in V5.

// Robert




+def explode_dep_versions2(bitbakepath, deps):
+bblib = bitbakepath + '/lib'
+if not bblib in sys.path:
+sys.path.insert(0, bblib)
+import bb.utils
+return bb.utils.explode_dep_versions2(deps)


I'm not particularly happy with this (the wrapper nor calling bitbake code


update.py needs explode_dep_versions2 to get dependencies and then calculate
them, I had tried to move the code into update_layer.py, and let
update_layer.py print explode_dep_versions2() to update.py, but it is a
OderedDic, and not easy to process it manually, so I leave the code in
update.py.


Right, I understand the limitations and I don't really have a better
alternative unfortunately, so we'll go with your current implementation. We
may need to re-evaluate this in future at least structure-wise if we find the
need to call other bitbake code in a similar way.

Cheers,
Paul



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

[yocto] QA Test Report for Yocto Project Full Cycle Release 2.4 M1 rc1

[Cruz, Libertad]

Hello All,



Here is the report for the 2.4 M1 rc1 full test cycle release.



Full Report : 
https://wiki.yoctoproject.org/wiki/WW25_-_2017-06-22_-_Full_Test_Cycle_2.4_M1_rc1



 Summary 



The QA cycle for release 2.4 M1 rc1 is complete, there were 3 new issues.

Most important one is 11687[3] Cannot run QEMU machines under UNFS since it is 
blocking 13 test suites. The second issue we are encountering is that we have 
yet to build a correct wic image for poky-tiny distribution.



Performance suffered a 5% regression from with 2.3_rc4 when building rootfs. 
Performance improvement 8% on extracting eSDK (Ubuntu) and 13% on fedora.





 Details 



QA Hints



Eclipse plugin is  blocked by 11687 and it also blocks 11 testruns with 4% 
each. Also there is trouble trying to build a correct poky-tiny image this last 
issue is still under analysis to determine if it is a bug. QA recommends a rc2 
so that the blocked test runs can be executed.





Bugs

  * New



   - Bug 11681 
- poky-tiny fails to build because of resource unavailability [1]

   - Bug 11699 
- [megamanual] dnf using rpm: 5.18.4.3.1. Using RPM section changes required [2]

   - Bug 11687 
- Can not run QEMU machines under UNFS [3]





  * High / M+ Not New



   - Bug 10477 
- yocto-bsp: tool should output a conf file to be consume by the qemu runner [4]





Full Bug Report : 
https://wiki.yoctoproject.org/wiki/WW25_-_2017-06-22_-_Full_Test_Cycle_2.4_M1_rc1#Bugs_Found_during_QA_Test







== Performance ==



Performance measurements showed a regression compared with 2.3_rc4 when 
building rootfs of around 5% in both machines and improvement on extracting 
eSDK of around 8% (Ubuntu) and 13% fedora on extracting eSDK. All other metrics 
are in the normal ranges.



  eSDK2:35 2:41 3.87



UbuntuTest2.3 rc42.4 M1 rc1%

  sato1:12:181:12:11   -0.16

  rootfs  2:16   2:23  5.15

  rmwork  1:06:171:08:27   3.27

  kernel  5:13   5:26  4.15

  eSDK2:44   2:30  -8.54





FedoraTest2.3 rc42.4 M1 rc1%

  sato1:12:421:13:49   1.54

  rootfs  2:29   2:38  6.04

  rmwork  1:06:241:08:22   2.96

  kernel  5:58   6:10  3.35

  eSDK3:01   2:36  -13.81







Performance Charts :  
https://wiki.yoctoproject.org/charts/perf_milestone_GDC/performance_test.html





 Links =



1.https://bugzilla.yoctoproject.org/show_bug.cgi?id=11681

2.https://bugzilla.yoctoproject.org/show_bug.cgi?id=11599

3.https://bugzilla.yoctoproject.org/show_bug.cgi?id=11687

4.https://bugzilla.yoctoproject.org/show_bug.cgi?id=10477



Regards
Libertad G.

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

Re: [yocto] [meta-raspberrypi][PATCH] sdcard_image-rpi.bbclass: deploy vfat partition

[Matthew McClintock]

On Wed, Jun 21, 2017 at 9:26 AM, Andrei Gherzan  wrote:
> P.S.: Would really be helpful to push a PR to github too so I can merge it
> easier.


FYI: https://github.com/agherzan/meta-raspberrypi/pull/86

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

[yocto] Raspberrypi bare-metal interfaced to PMod GPS receiver

[Edward Vidal]

Hello All
Just completed the interface of a 
http://store.digilentinc.com/pmod-gps-gps-receiver/$39.99 with RPi 2B Running 
Ultibo Bare metal on Raspberrypi2B & PMOD GPS with just 4 fileskernel7.img, 
start.elf, bootcode.bin, and fixup.dat.Receives GPS data on UART and sends 
message on Ethernet using UDP.More information see https://ultibo.org/ on bare 
metal project and https://github.com/develone/ultibo_serial_testingOn what 
creates the kernel7.img, see the README.md
One of many messages sent by GPS receiver.
$GPGGA,132531.000,3145.5590,N,10620.5407,W,2,9,0.89,1209.1,M,-26.2,M,,*5Btime
  132531.000Latitude 3145.5590 NLongitude 10620.5407 WElevation 1209.1 MThe 
program calls C to compute the checksum.
The Check sum of the character between the "$" and the "*"81 bytes readThe 
checksum of ch_sum_test.dat is 0x5bComputed by taking the checksum Exclusive or 
with each character.
Let me know if this of interest..
 Edward Vidal Jr. e-mail devel...@sbcglobal.net 915-595-1613-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-gplv2][PATCH] grep: fix compilation with security flags enabled

[Burton, Ross]

On 19 June 2017 at 11:28, André Draszik  wrote:

> From: André Draszik 
>

All three applied, thanks.

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

Re: [yocto] [meta-chip][RFC PATCH 3/3] chip: Add chip-u-boot-scr recipe and flash script

[Drew Moseley]

> On Jun 22, 2017, at 12:22 AM, Petter Mabäcker  wrote:
> 
> 2017-06-19 16:40 skrev Trevor Woerner:
> 
>> On Mon, Jun 19, 2017 at 7:22 AM, Drew Moseley > > wrote:
 On Jun 19, 2017, at 1:48 AM, Trevor Woerner > wrote:
> 
> If you have a serial console connected to +your board, you will see the 
> progress and a message on the console will indicate when +the flashing is 
> completed.
 hmmm, never saw this. I have a console connected, the moment the script 
 started, on the console I got: U-Boot SPL 2016.01 (Jun 19 2017 - 00:32:19) 
 DRAM: 512 MiB CPU: 100800Hz, AXI/AHB/APB: 3/2/2 Trying to boot from 
 which looks right, the date+time are good.
>>> Did you see the proper serial output after using a smaller image?
>> Yes. With a smaller image (~90MB) the flash update worked. Maybe
>> another improvement for a v2 would be for the script to look at the
>> size of /full/path/to/UBI_IMAGE and issue a warning/error if it's too
>> big?
>> 
>> I think the wording of what to expect on the host and over the serial
>> console could use some updating. Not to mention you say: "the status
>> LED on the CHIP board will flash 30 times per second..." which doesn't
>> seem to be the case, it looks more like the LED is toggled every 2
>> seconds (??), in any case, it's a lot slower than 30/sec.
> I also had the same experience as Trevor, that the led seems to flash every 2 
> seconds. Also the code indicate that 2 x 1 sec sleep is used in this area, so 
> please go through the above description when it comes to led experience 
> during flashing. Another minor comment is that I believe you should update 
> the UBI_IMAGE example in README to use the "default" meta-chip hwup image 
> (chip-hwup-image-chip.ubi).
> 
> BR Petter
> 
> Petter Mabäcker
> 
> Technux 
> www.technux.se

Indeed.  The comment was intended to say that it flashes 30/min.  Obviously 
flashing 30/sec would not be a very easy thing for people to spot.

I’ll work through the comments and submit V2.  It will take me a few days.

Many thanks for the feedback.

Drew

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

Re: [yocto] AppArmor

[Tom Rini]

On Thu, Jun 22, 2017 at 05:01:09AM +0300, Anders Montonen wrote:
> On 21 Jun 2017, at 23:46, Khem Raj  wrote:
> > On Tue, Jun 20, 2017 at 9:56 AM Anders Montonen  > > wrote:
> > Has anyone tried using AppArmor with Yocto? The recipe in the
> > meta-security layer is broken, and when fixed so it actually builds, it
> > turns out the installed init script relies on functions not found in
> > Yocto's version of LSB.
> > That seems a bug to me perhaps can be fixed in initscripts ?
> 
> I ended up replacing the recipe with one combining the one from meta-security 
> and from the OpenSwitch project[1]. This allowed me to get rid of the 
> sysvinit and apache2 dependencies. I’ll have to look for Tom Rini’s tweaks 
> and see if he fixed the Python issues more elegantly.
> 
> IIRC the issues I ran into with the meta-security recipe were:
> - The tools under binutils require the static library
> - The systemd service file isn’t installed
> - The Python apparmor module is built against Python 2.7, while the scripts 
> that use it are Python 3. Commit 
> 89683b4fee4616a08d249bc7afd7be55f3fa71a3 is wrong, it papers over a QA 
> warning without fixing the actual problem.
> - The Python LibAppArmor module isn’t built at all.

I did fix the latter of these (along with the perl problem), but I'm
using sysvinit and needed apache2 in my project anyhow.

-- 
Tom


signature.asc
Description: Digital signature
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [PATCH V4 03/10] utils.py: remove obsolete dependencies

[Paul Eggleton]

On Thursday, 22 June 2017 12:47:31 PM CEST Robert Yang wrote:
> On 06/21/2017 05:06 PM, Paul Eggleton wrote:
> > So I do see the need to clear out old dependency values when your list of
> > dependencies is coming entirely from LAYERDEPENDS, however if you have only
> > manually added dependencies and LAYERDEPENDS is not complete (as is often 
> > the
> > case in the OE layer index), will this automatically remove those? If so I
> 
> The dependencies will be removed if it is not in conf/layer.conf.
> 
> > think we're going to have to come up with some mechanism to avoid that.
> > Probably the easiest one would be to avoid touching the dependencies unless
> > LAYERDEPENDS actually changes. Of course if that means we're going to store
> > the previous LAYERDEPENDS value somewhere to compare to, we'd need to avoid 
> > it
> > triggering initially when none of those values are set.
> 
> Why not fix conf/layer.conf rather than fix it from database ? If
> conf/layer.conf is wrong, we would meet problems elsewhere. 

Up until now it hasn't caused any issues other than not getting an error
up front from bitbake when a dependencies are missing, so it can easily go
unnoticed (particularly when users follow manual instructions or use existing
configurations rather than an automated tool that pays attention to
LAYERDEPENDS).

> The database
> should obey local.conf when mismatches, otherwise, this would confuse
> users a lot when they want to update LAYERDEPENDS.

As I indicated, I agree that if LAYERDEPENDS gets updated then the
dependencies in the database should get updated. My concern is updating
them if LAYERDEPENDS has not changed and it simply happens to have
a difference to what is in the database (most importantly if it has less
dependencies specified).

> I'm glad to fix oe-classic's LAYERDEPENDS issues if they are wrong.

Well, it's not so much OE-Classic as every single layer in the index,
maintained by a number of different maintainers. I agree in the long term we
do want people to fix their dependencies. The trouble is we don't
even know the size of the problem at the moment, and if it's widespread
then we'll end up dropping dependencies potentially leading to errors during
parsing.

How about this - could we start with a setting in the configuration that
specifies that dependencies should be updated automatically, and if not
set just gives a warning if the dependencies are not the same? We can
then decide how to handle it when we see the warnings we're getting in
the OE index.

Cheers,
Paul

-- 

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

Re: [yocto] [PATCH V4 10/10] update_layer.py: delete layerbranch for non-existed branch

[Paul Eggleton]

On Thursday, 22 June 2017 12:55:15 PM CEST Robert Yang wrote:
> On 06/21/2017 10:31 PM, Paul Eggleton wrote:
> > On Tuesday, 13 June 2017 4:36:51 AM CEST Robert Yang wrote:
> >> Note, we have to move the location of tinfiol's code to make it can be
> >> shutdown  correctly.
> >
> > How does this relate to the rest of this change? Also, can you explain the
> > issue you were hitting? The try...finally is supposed to ensure it gets 
> > shut down.
> 
> I updated the commit message:
> 
> update_layer.py: delete layerbranch for non-existed branch
> 
> The branch is not needed any more when it has been removed from the repo, so 
> we
> also need remove its layerbranch, otherwise it still can be got from the web,
> which causes confusions.
> 
> Note, we have to move the location of tinfiol's code to avoid creating tinfoil
> when not needed, otherewise, if tinfoil is created (but not needed), and the
> program exists earlier before "try ... finally" block, then tinfoil.shutdown()
> doesn't run so that it is not shutdown. Move the code back, right before where
> it is needed can fix the problem.

OK, that explains the change, thanks.

Cheers,
Paul

-- 

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

Re: [yocto] [PATCH V4 06/10] update.py: update layers orderly

[Paul Eggleton]

Hi Robert,

On Thursday, 22 June 2017 1:04:23 PM CEST Robert Yang wrote:
> On 06/21/2017 10:21 PM, Paul Eggleton wrote:
> > On Tuesday, 13 June 2017 4:36:47 AM CEST Robert Yang wrote:
> >> --- a/layerindex/update_layer.py
> >> +++ b/layerindex/update_layer.py
> ...
> >> +def get_layer_var(config_data, var):
> >> +collection = config_data.getVar('BBFILE_COLLECTIONS', True)
> >
> > This makes the assumption that the layer.conf only adds one collection
> > to BBFILE_COLLECTIONS. Probably a valid assumption 99.9% of the time these
> > days, but it is worth noting.
> 
> Should we check all BBFILE_COLLECTIONS, please ?

I would say let's split the value and use the first one, but if there is more 
than one then warn e.g. "Multiple collections found, handling first one (%s) 
only" but otherwise continue processing. That way at least we'll know if this 
situation occurs.

> >> +def explode_dep_versions2(bitbakepath, deps):
> >> +bblib = bitbakepath + '/lib'
> >> +if not bblib in sys.path:
> >> +sys.path.insert(0, bblib)
> >> +import bb.utils
> >> +return bb.utils.explode_dep_versions2(deps)
> >
> > I'm not particularly happy with this (the wrapper nor calling bitbake code
> 
> update.py needs explode_dep_versions2 to get dependencies and then calculate
> them, I had tried to move the code into update_layer.py, and let
> update_layer.py print explode_dep_versions2() to update.py, but it is a
> OderedDic, and not easy to process it manually, so I leave the code in
> update.py.

Right, I understand the limitations and I don't really have a better 
alternative unfortunately, so we'll go with your current implementation. We 
may need to re-evaluate this in future at least structure-wise if we find the 
need to call other bitbake code in a similar way.

Cheers,
Paul


-- 

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

Re: [yocto] [PATCH V4 06/10] update.py: update layers orderly

[Robert Yang]

Hi Paul,

Thanks for the review, I've fixed all your comments except the following ones.

On 06/21/2017 10:21 PM, Paul Eggleton wrote:

Hi Robert,

Thanks for solving this long-standing bug! Just a few notes below.

On Tuesday, 13 June 2017 4:36:47 AM CEST Robert Yang wrote:

--- a/layerindex/update_layer.py
+++ b/layerindex/update_layer.py

...

+def get_layer_var(config_data, var):
+collection = config_data.getVar('BBFILE_COLLECTIONS', True)


This makes the assumption that the layer.conf only adds one collection
to BBFILE_COLLECTIONS. Probably a valid assumption 99.9% of the time these
days, but it is worth noting.


Should we check all BBFILE_COLLECTIONS, please ?





+if collection:
+collection = collection.strip()
+value = config_data.getVar('%s_%s' % (var, collection), True)
+if not value:
+value = config_data.getVar(var, True)
+return value or ''
+

...




+def explode_dep_versions2(bitbakepath, deps):
+bblib = bitbakepath + '/lib'
+if not bblib in sys.path:
+sys.path.insert(0, bblib)
+import bb.utils
+return bb.utils.explode_dep_versions2(deps)


I'm not particularly happy with this (the wrapper nor calling bitbake code


update.py needs explode_dep_versions2 to get dependencies and then calculate
them, I had tried to move the code into update_layer.py, and let
update_layer.py print explode_dep_versions2() to update.py, but it is a
OderedDic, and not easy to process it manually, so I leave the code in
update.py.

I will send a V5 after we've made agreements.

// Robert


from update.py) but I suppose it's marginally better than duplicating
explode_dep_versions2().

Cheers,
Paul


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

Re: [yocto] [PATCH V4 10/10] update_layer.py: delete layerbranch for non-existed branch

[Robert Yang]

On 06/21/2017 10:31 PM, Paul Eggleton wrote:

On Tuesday, 13 June 2017 4:36:51 AM CEST Robert Yang wrote:

The branch is not needed any more when it has been removed from the repo, so
we also need remove its layerbranch, otherwise it still can be got from the
web, which causes confusions.


I think I'd previously avoided this since I was concerned we'd potentially
lose data about a branch which was manually gathered (such as maintainer
information) however I can't actually think of a scenario now where you would
lose valuable data - if the branch is gone then there's not much point keeping
a reference to it around, so this should be OK.


Note, we have to move the location of tinfiol's code to make it can be
shutdown  correctly.


How does this relate to the rest of this change? Also, can you explain the
issue you were hitting? The try...finally is supposed to ensure it gets shut
down.


I updated the commit message:

update_layer.py: delete layerbranch for non-existed branch

The branch is not needed any more when it has been removed from the repo, so we
also need remove its layerbranch, otherwise it still can be got from the web,
which causes confusions.

Note, we have to move the location of tinfiol's code to avoid creating tinfoil
when not needed, otherewise, if tinfoil is created (but not needed), and the
program exists earlier before "try ... finally" block, then tinfoil.shutdown()
doesn't run so that it is not shutdown. Move the code back, right before where
it is needed can fix the problem.

// Robert



Cheers,
Paul



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

Re: [yocto] [PATCH V4 01/10] update.py: update actual branch for layer and bitbake

[Robert Yang]

Hi Paul,

Thanks for the review, I've fixed all the issues you commented except
the following ones.

On 06/21/2017 05:01 PM, Paul Eggleton wrote:

Hi Robert,




+# We deliberately exclude status == 'X' ("no update") here
+layerquery_all = LayerItem.objects.filter(classic=False).filter(status='P')
+if layerquery_all.count() == 0:
+logger.info("No published layers to update")
+sys.exit(1)


So near as I can tell this change isn't required as part of the other
changes here, it's just to tell you up front that no layers are published
if you've specified layers instead of seeing an error. I don't have an
issue with that but this change should be mentioned in the commit
message ("additionally ..."), or split out as a separate patch.


Sorry, it should be in another patch, I added it to wrong place when rebase.
I add this patch into "update.py: update layers orderly" now. I need
layerquery_all to know all the provided collections in database, so that we
can know whether the dependencies match or not.





+# For -a option to update bitbake branch
+update_bitbake = False
 if options.layers:
-layerquery = 
LayerItem.objects.filter(classic=False).filter(name__in=options.layers.split(','))
-if layerquery.count() == 0:
-logger.error('No layers matching specified query "%s"' % 
options.layers)
-sys.exit(1)
+layers = options.layers.split(',')
+if 'bitbake' in layers:
+update_bitbake = True
+layers.remove('bitbake')


So since this means 'bitbake' is a reserved name for layers we should add
validation upon layer submission to ensure you can't create a layer with this
name. I can take care of that if you like.


Good idea, I will do it later, or you can do it if you have time.

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