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

[Petter Mabäcker]

 

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
 -- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-chip][RFC PATCH 0/3] Initial attempt at flashing instructions.

[Petter Mabäcker]

 

2017-06-16 23:15 skrev drew.mose...@mender.io: 

> From: Drew
Moseley 
> 
> This set of patches adds the
native tools and target components needed to
> reflash the CHIP boards.
Additionally a shell script is added to the deploy
> directory showing
how to kick off a flash update. It's not ideal as I've
> hardcoded a max
size for the UBI image into the script and didn't see much
> of an
alternative. It does function though.
> 
> Drew
> 
> The following
changes since commit 0079e6ac10fc371d6f527270c23b887561f717aa:
> 
>
chip: Append to MACHINE_EXTRA_RRECOMMENDS rather than overwriting
(2017-06-15 13:37:19 +0100)
> 
> are available in the git repository
at:
> 
> g...@github.com:drewmoseley/meta-chip.git
flashing-instructions
> 
> for you to fetch changes up to
195a92fc1faa49495d1a2b6cda0134f07ce72189:
> 
> chip: Add chip-u-boot-scr
recipe and flash script (2017-06-15 11:27:06 -0400)
> 
>

> Drew
Moseley (3):
> u-boot-chip: Deploy the sunxi-spl-with-ecc.bin file.
>
chip: Build sunxi-tools-native.
> chip: Add chip-u-boot-scr recipe and
flash script
> 
> README | 26 -
> conf/layer.conf | 3 ++
>
conf/machine/chip.conf | 3 +-
>
recipes-bsp/chip-u-boot-scr/chip-u-boot-scr.bb | 70
+
>
recipes-bsp/chip-u-boot-scr/files/boot.cmd.full | 32 +++
>
recipes-bsp/chip-u-boot-scr/files/boot.cmd.in | 43 +++
>
recipes-bsp/u-boot/u-boot-chip_git.bb | 7 +++
> 7 files changed, 182
insertions(+), 2 deletions(-)
> create mode 100644
recipes-bsp/chip-u-boot-scr/chip-u-boot-scr.bb
> create mode 100644
recipes-bsp/chip-u-boot-scr/files/boot.cmd.full
> create mode 100644
recipes-bsp/chip-u-boot-scr/files/boot.cmd.in
> 
> Drew Moseley (3):
>
u-boot-chip: Deploy the sunxi-spl-with-ecc.bin file.
> chip: Build
sunxi-tools-native.
> chip: Add chip-u-boot-scr recipe and flash
script
> 
> README | 26 -
> conf/layer.conf | 3 ++
>
conf/machine/chip.conf | 3 +-
>
recipes-bsp/chip-u-boot-scr/chip-u-boot-scr.bb | 70
+
>
recipes-bsp/chip-u-boot-scr/files/boot.cmd.full | 32 +++
>
recipes-bsp/chip-u-boot-scr/files/boot.cmd.in | 43 +++
>
recipes-bsp/u-boot/u-boot-chip_git.bb | 7 +++
> 7 files changed, 182
insertions(+), 2 deletions(-)
> create mode 100644
recipes-bsp/chip-u-boot-scr/chip-u-boot-scr.bb
> create mode 100644
recipes-bsp/chip-u-boot-scr/files/boot.cmd.full
> create mode 100644
recipes-bsp/chip-u-boot-scr/files/boot.cmd.in
> 
> -- 
> 2.7.4

Hi Drew,


First of all, great work. The flashing mechanism have been sort of a
headache for many. Even if like you say there are some limitations etc
with this proposal, it works and it's easy to use. Also since no other
major concern have been provided by other reviewers, I think you should
fix the comments received and then send it as non-RFC patch. Also check
with Andrei if he want to have this as a PR in github as well. 

BR
Petter 

Petter Mabäcker

Technux 
www.technux.se
 -- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [meta-selinux][PATCH] initscripts: use the 'i' option for restorecon command

[Zhixiong Chi]

Use the 'i' option for restorecon command to ignore the files that
don't exist when building project.

Signed-off-by: Zhixiong Chi 
---
 recipes-core/initscripts/initscripts_1.0.bbappend | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/recipes-core/initscripts/initscripts_1.0.bbappend 
b/recipes-core/initscripts/initscripts_1.0.bbappend
index f17cf07..0fc7a5e 100644
--- a/recipes-core/initscripts/initscripts_1.0.bbappend
+++ b/recipes-core/initscripts/initscripts_1.0.bbappend
@@ -5,9 +5,9 @@ FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
 do_install_append () {
cat <<-EOF >> ${D}${sysconfdir}/init.d/populate-volatile.sh
 touch /var/log/lastlog
-test ! -x /sbin/restorecon || /sbin/restorecon -RF /var/volatile/ /var/lib 
/run \
+test ! -x /sbin/restorecon || /sbin/restorecon -iRF /var/volatile/ /var/lib 
/run \
 /etc/resolv.conf /etc/adjtime
 EOF
-   sed -i '/mount -n -o remount,$rootmode/i\test ! -x /sbin/restorecon || 
/sbin/restorecon -RF /run' \
+   sed -i '/mount -n -o remount,$rootmode/i\test ! -x /sbin/restorecon || 
/sbin/restorecon -iRF /run' \
${D}${sysconfdir}/init.d/checkroot.sh
 }
-- 
1.9.1

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

Re: [yocto] AppArmor

[Anders Montonen]

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.

Regards,
Anders

[1] 
>-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [prelink-cross][PATCH] rtld: Add missing DT_NEEDED DSOs to needed_list

[Mark Hatle]

On 6/21/17 8:51 PM, Kyle Russell wrote:
> Just wanted to follow-up on this so it doesn't get lost.  Any chance this 
> could
> be included in cross_prelink_staging?

I just finished the sanity checking on it.  It should be in staging in a few
minutes.

(There are a couple of x32 patches as well, however I'm currently not able to
test those.  Something is wrong when the master x32 that there are missing
headers -- and even when that is resolved the testsuite doesn't appear to
properly find the ld.so and such.)

--Mark

> On Thu, Aug 25, 2016 at 1:03 PM, Mark Hatle  > wrote:
> 
> Thanks!  I'll try to get this included soon.
> 
> --Mark
> 
> On 8/25/16 10:39 AM, Kyle Russell wrote:
> > prelink-rtld may report an "error while loading shared libraries" for
> > the wrong library.
> >
> > If some set of DT_NEEDED DSOs are not in the default search path, they
> > may have a dso_list entry added, but no matching entry is added to the
> > needed_list.  This causes the linker to miscalculate the max number of
> > dsos during build_local_scope(), which later causes find_needed() to not
> > search the entire l_local_scope[0]->r_list during
> > _dl_check_map_versions() (since the max from build_local_scope() becomes
> > l_local_scope[0]->r_nlist).
> >
> > Since find_needed() searches through the r_list, which would have the
> > dso_list entries for the libraries that weren't found earlier, this cuts
> > the search short, meaning libraries near the end of the local scope 
> don't
> > get included in the map version search.
> >
> > As the comment in _dl_check_map_versions() suggests, if needed is NULL,
> > that means a dependency was not found and no stub entry created, which
> > should never happen.
> >
> > Signed-off-by: Kyle Russell  >
> > ---
> >  src/rtld/rtld.c | 36 ++--
> >  1 file changed, 22 insertions(+), 14 deletions(-)
> >
> > diff --git a/src/rtld/rtld.c b/src/rtld/rtld.c
> > index 8d7d760..d9a0862 100644
> > --- a/src/rtld/rtld.c
> > +++ b/src/rtld/rtld.c
> > @@ -686,6 +686,25 @@ find_lib_by_soname (const char *soname, struct
> dso_list *loader,
> >return NULL;
> >  }
> >
> > +static void
> > +add_dso_to_needed (struct dso_list *cur_dso_ent, struct dso_list
> *new_dso_ent)
> > +{
> > +  if (!cur_dso_ent->needed)
> > +{
> > +  cur_dso_ent->needed = malloc (sizeof (struct needed_list));
> > +  cur_dso_ent->needed_tail = cur_dso_ent->needed;
> > +  cur_dso_ent->needed_tail->ent = new_dso_ent;
> > +  cur_dso_ent->needed_tail->next = NULL;
> > +}
> > +  else if (!in_needed_list (cur_dso_ent->needed, new_dso_ent->name))
> > +{
> > +  cur_dso_ent->needed_tail->next = malloc (sizeof (struct 
> needed_list));
> > +  cur_dso_ent->needed_tail = cur_dso_ent->needed_tail->next;
> > +  cur_dso_ent->needed_tail->ent = new_dso_ent;
> > +  cur_dso_ent->needed_tail->next = NULL;
> > +}
> > +}
> > +
> >  static struct dso_list *
> >  load_dsos (DSO *dso, int host_paths)
> >  {
> > @@ -812,6 +831,8 @@ load_dsos (DSO *dso, int host_paths)
> > dso_list_tail->canon_filename = strdup(soname);
> > dso_list_tail->err_no = errno;
> >
> > +  add_dso_to_needed(cur_dso_ent, new_dso_ent);
> > +
> > continue;
> >   }
> >
> > @@ -854,20 +875,7 @@ load_dsos (DSO *dso, int host_paths)
> >   dso_list_tail->name = new_dso->soname;
> >   }
> >
> > -   if (!cur_dso_ent->needed)
> > - {
> > -   cur_dso_ent->needed = malloc (sizeof (struct
> needed_list));
> > -   cur_dso_ent->needed_tail = cur_dso_ent->needed;
> > -   cur_dso_ent->needed_tail->ent = new_dso_ent;
> > -   cur_dso_ent->needed_tail->next = NULL;
> > - }
> > -   else if (!in_needed_list (cur_dso_ent->needed, soname))
> > - {
> > -   cur_dso_ent->needed_tail->next = malloc (sizeof
> (struct needed_list));
> > -   cur_dso_ent->needed_tail = 
> cur_dso_ent->needed_tail->next;
> > -   cur_dso_ent->needed_tail->ent = new_dso_ent;
> > -   cur_dso_ent->needed_tail->next = NULL;
> > - }
> > +  add_dso_to_needed(cur_dso_ent, new_dso_ent);
> >
> > continue;
> >   }
> >
> 
> 

-- 

Re: [yocto] [prelink-cross][PATCH] rtld: Add missing DT_NEEDED DSOs to needed_list

[Kyle Russell]

Just wanted to follow-up on this so it doesn't get lost.  Any chance this
could be included in cross_prelink_staging?

On Thu, Aug 25, 2016 at 1:03 PM, Mark Hatle 
wrote:

> Thanks!  I'll try to get this included soon.
>
> --Mark
>
> On 8/25/16 10:39 AM, Kyle Russell wrote:
> > prelink-rtld may report an "error while loading shared libraries" for
> > the wrong library.
> >
> > If some set of DT_NEEDED DSOs are not in the default search path, they
> > may have a dso_list entry added, but no matching entry is added to the
> > needed_list.  This causes the linker to miscalculate the max number of
> > dsos during build_local_scope(), which later causes find_needed() to not
> > search the entire l_local_scope[0]->r_list during
> > _dl_check_map_versions() (since the max from build_local_scope() becomes
> > l_local_scope[0]->r_nlist).
> >
> > Since find_needed() searches through the r_list, which would have the
> > dso_list entries for the libraries that weren't found earlier, this cuts
> > the search short, meaning libraries near the end of the local scope don't
> > get included in the map version search.
> >
> > As the comment in _dl_check_map_versions() suggests, if needed is NULL,
> > that means a dependency was not found and no stub entry created, which
> > should never happen.
> >
> > Signed-off-by: Kyle Russell 
> > ---
> >  src/rtld/rtld.c | 36 ++--
> >  1 file changed, 22 insertions(+), 14 deletions(-)
> >
> > diff --git a/src/rtld/rtld.c b/src/rtld/rtld.c
> > index 8d7d760..d9a0862 100644
> > --- a/src/rtld/rtld.c
> > +++ b/src/rtld/rtld.c
> > @@ -686,6 +686,25 @@ find_lib_by_soname (const char *soname, struct
> dso_list *loader,
> >return NULL;
> >  }
> >
> > +static void
> > +add_dso_to_needed (struct dso_list *cur_dso_ent, struct dso_list
> *new_dso_ent)
> > +{
> > +  if (!cur_dso_ent->needed)
> > +{
> > +  cur_dso_ent->needed = malloc (sizeof (struct needed_list));
> > +  cur_dso_ent->needed_tail = cur_dso_ent->needed;
> > +  cur_dso_ent->needed_tail->ent = new_dso_ent;
> > +  cur_dso_ent->needed_tail->next = NULL;
> > +}
> > +  else if (!in_needed_list (cur_dso_ent->needed, new_dso_ent->name))
> > +{
> > +  cur_dso_ent->needed_tail->next = malloc (sizeof (struct
> needed_list));
> > +  cur_dso_ent->needed_tail = cur_dso_ent->needed_tail->next;
> > +  cur_dso_ent->needed_tail->ent = new_dso_ent;
> > +  cur_dso_ent->needed_tail->next = NULL;
> > +}
> > +}
> > +
> >  static struct dso_list *
> >  load_dsos (DSO *dso, int host_paths)
> >  {
> > @@ -812,6 +831,8 @@ load_dsos (DSO *dso, int host_paths)
> > dso_list_tail->canon_filename = strdup(soname);
> > dso_list_tail->err_no = errno;
> >
> > +  add_dso_to_needed(cur_dso_ent, new_dso_ent);
> > +
> > continue;
> >   }
> >
> > @@ -854,20 +875,7 @@ load_dsos (DSO *dso, int host_paths)
> >   dso_list_tail->name = new_dso->soname;
> >   }
> >
> > -   if (!cur_dso_ent->needed)
> > - {
> > -   cur_dso_ent->needed = malloc (sizeof (struct
> needed_list));
> > -   cur_dso_ent->needed_tail = cur_dso_ent->needed;
> > -   cur_dso_ent->needed_tail->ent = new_dso_ent;
> > -   cur_dso_ent->needed_tail->next = NULL;
> > - }
> > -   else if (!in_needed_list (cur_dso_ent->needed, soname))
> > - {
> > -   cur_dso_ent->needed_tail->next = malloc (sizeof
> (struct needed_list));
> > -   cur_dso_ent->needed_tail = cur_dso_ent->needed_tail->
> next;
> > -   cur_dso_ent->needed_tail->ent = new_dso_ent;
> > -   cur_dso_ent->needed_tail->next = NULL;
> > - }
> > +  add_dso_to_needed(cur_dso_ent, new_dso_ent);
> >
> > continue;
> >   }
> >
>
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Any ideas why my RPi app won't load?

[Paul D. DeRocco]

I've built a custom 32-bit non-GUI Raspberry Pi image, built the
corresponding SDK, and used the SDK's toolchain to build an app. When I
run the app on the RPi, from a command prompt as root, the shell
complains:

-sh: /path/to/app: No such file or directory

(with the real app name, obviously). sh is linked to bash. Here's what
I've checked:

1) The app exists, and is the correct executable.

2) Its execute permission bit is set.

3) Its ELF file format is the same as the ELF file format of every other
command in the system.

4) The shared libraries it uses all exist, recursively, in /lib or
/usr/lib. They are all listed by ldconfig -p.

5) There is no LD_LIBRARY_PATH variable.

6) If I run the app with LL_DEBUG=all, I get the same error, so it isn't
even getting as far as loading libraries. (Or perhaps LL_DEBUG isn't
supported on this build.)

Googling didn't turn up any other possibilities. Has anyone seen any other
reasons for this error?

-- 

Ciao,   Paul D. DeRocco
Paulmailto:pdero...@ix.netcom.com

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

Re: [yocto] AppArmor

[Khem Raj]

On Tue, Jun 20, 2017 at 9:56 AM Anders Montonen 
wrote:

> Hi,
>
> 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 ?

>
> Regards,
> Anders
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] AppArmor

[Gunnar Andersson]

Dominic ar Foll writes:

> I have been presenting AGL  Smack based security model in quite a few 
> conferences over the world and not many people have come to me
> to talk about their "solution" working either on SE Linux or
> AppArmor. So far I have the impression that AGL is quite unique in
> its full integration of an LSM module in an embedded project.
>
> One of the member of Genivi Alliance (I believe it was Bosh with 
> its product called at the time eCore) told (about 3 years 
> that they would put their security framework which was based on 
> AppAmor, in the Open, but I have never eared about it since that

https://apertis.org

Code and docs came out around a year after the initial announcement under
the new name, so it has been published about 2 years or so.

Apertis builds with OBS, so it might not directly help the OP however.


- Gunnar

-- 
Gunnar Andersson 
Development Lead
GENIVI Alliance


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

Re: [linux-yocto] [kernel-cache][PATCH 0/1] Update PWM config for leafhill platform

[Bruce Ashfield]

On 2017-06-20 5:30 PM, chong.yi.c...@intel.com wrote:

From: "Chai, Chong Yi" 

Hi Bruce,

This patch is targeted for yocto-kernel-cache yocto-4.1 branch.
The changes on configs enable PWM to be built in driver rather than
kernel module which is require by DC-IRIS camera driver.
The config is separated from main leafhill config to enable it call
out as KERNEL_FEATURE which has higher priority.


Looks good to me.

Merged.

Bruce



The patch is validated on leafhill platform.

Chai, Chong Yi (1):
   pwm_leafhill: set pwm as built in by default

  bsp/leafhill/pwm_leafhill.cfg | 4 
  bsp/leafhill/pwm_leafhill.scc | 2 ++
  2 files changed, 6 insertions(+)
  create mode 100644 bsp/leafhill/pwm_leafhill.cfg
  create mode 100644 bsp/leafhill/pwm_leafhill.scc



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

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

[Khem Raj]

On Wed, Jun 21, 2017 at 10:29 AM Matthew McClintock 
wrote:

> On Wed, Jun 21, 2017 at 9:26 AM, Andrei Gherzan  wrote:
> > On Sun, Jun 18, 2017 at 7:51 PM, Matthew McClintock <
> msm-...@mcclintock.net>
> > wrote:
> >>
> >> On Sat, Jun 17, 2017 at 11:41 AM, Khem Raj  wrote:
> >> > On Sat, Jun 17, 2017 at 8:20 AM, Tom Rini  wrote:
> >> >> On Fri, Jun 16, 2017 at 06:05:07PM -0700, Khem Raj wrote:
> >> >>> On Fri, Jun 16, 2017 at 12:12 PM, Matthew McClintock
> >> >>>  wrote:
> >> >>> > This is useful to update the bootloader/vfat partition from u-boot
> >> >>> > when
> >> >>> > you don't want to update everything:
> >> >>> >
> >> >>> > U-Boot> tftpboot 0x100 tmp/0VXje
> >> >>> > Waiting for Ethernet connection... done.
> >> >>> > Using sms0 device
> >> >>> > TFTP from server 192.168.0.1; our IP address is 192.168.0.26
> >> >>> > Filename 'image.vfat'.
> >> >>> > Load address: 0x100
> >> >>> > Loading: ##  40
> MiB
> >> >>> >  2.1 MiB/s
> >> >>> > done
> >> >>> > Bytes transferred = 41943040 (280 hex)
> >> >>> > U-Boot> mmc part
> >> >>> >
> >> >>> > Partition Map for MMC device 0  --   Partition Type: DOS
> >> >>> >
> >> >>> > PartStart SectorNum Sectors UUIDType
> >> >>> >   1 819281920   a63a4fbc-01 0c Boot
> >> >>> >   2 90112   163840  a63a4fbc-02 83
> >> >>> > U-Boot> mmc erase 0x2000 0x14000
> >> >>> >
> >> >>> > MMC erase: dev # 0, block # 8192, count 81920 ... 81920 blocks
> >> >>> > erased:
> >> >>> > OK
> >> >>> > U-Boot> mmc write 0x100 0x2000 0x14000
> >> >>> >
> >> >>> > MMC write: dev # 0, block # 8192, count 81920 ... 81920 blocks
> >> >>> > written:
> >> >>> > OK
> >> >>> > U-Boot>
> >> >>> >
> >> >>> > Signed-off-by: Matthew McClintock 
> >> >>> > ---
> >> >>> >  classes/sdcard_image-rpi.bbclass | 8 
> >> >>> >  1 file changed, 8 insertions(+)
> >> >>> >
> >> >>> > diff --git a/classes/sdcard_image-rpi.bbclass
> >> >>> > b/classes/sdcard_image-rpi.bbclass
> >> >>> > index af3e807..27a0dfc 100644
> >> >>> > --- a/classes/sdcard_image-rpi.bbclass
> >> >>> > +++ b/classes/sdcard_image-rpi.bbclass
> >> >>> > @@ -72,6 +72,10 @@ SDIMG =
> >> >>> > "${IMGDEPLOYDIR}/${IMAGE_NAME}.rootfs.rpi-sdimg"
> >> >>> >  # Additional files and/or directories to be copied into the vfat
> >> >>> > partition from the IMAGE_ROOTFS.
> >> >>> >  FATPAYLOAD ?= ""
> >> >>> >
> >> >>> > +# SD card vfat partition image name
> >> >>> > +SDIMG_VFAT = "${IMGDEPLOYDIR}/${IMAGE_NAME}.vfat"
> >> >>> > +SDIMG_LINK_VFAT = "${IMGDEPLOYDIR}/${IMAGE_LINK_NAME}.vfat"
> >> >>> > +
> >> >>> >  IMAGE_CMD_rpi-sdimg () {
> >> >>> >
> >> >>> > # Align partitions
> >> >>> > @@ -145,6 +149,10 @@ IMAGE_CMD_rpi-sdimg () {
> >> >>> > echo "${IMAGE_NAME}" > ${WORKDIR}/image-version-info
> >> >>> > mcopy -i ${WORKDIR}/boot.img -v
> >> >>> > ${WORKDIR}/image-version-info ::
> >> >>> >
> >> >>> > +# Deploy vfat partition
> >> >>> > +cp ${WORKDIR}/boot.img ${SDIMG_VFAT}
> >> >>> > +ln -sf ${SDIMG_VFAT} ${SDIMG_LINK_VFAT}
> >> >>> > +
> >> >>>
> >> >>> it is of use if I am not using u-boot ? is there any penalty ?
> >>
> >> Other than just having another thing copied into tmp there is no
> >> effect, even if you're not using u-boot.
> >>
> >> >>
> >> >> The stock firmware also uses a vfat partition, so this could just as
> >> >> easily hold those contents.
> >> >
> >> > yes it does, can it do the same operations like u-boot ?
> >
> >
> > I think what Khem is trying to say is if we don't need it (because I
> don't
> > think there is any use for it when using proprietary bootloader) can we
> > deploy it only in the case of uboot bootloader section?
> >
> > P.S.: Would really be helpful to push a PR to github too so I can merge
> it
> > easier.
>
> If that's what Khem is saying I can deply only with KERNEL_IMAGETYPE =
> uImage... and also go via github. I suppose it's not too useful for
> the proprietary bootloader.


Right if its only valid for uimage alone then let's make it so however I
was looking for it being expanded to other boot loader too

>
>
> Khem, is that what you want?
>
> -M
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] AppArmor

[Tom Rini]

On Tue, Jun 20, 2017 at 04:19:24PM +0300, Anders Montonen wrote:

> Hi,
> 
> 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.

The biggest problem I've found thus far with AppArmor was needing to do
some tweaks (which I've posted) so that the utilities have all of the
required python/perl bindings.  I do need to poke things harder however.

-- 
Tom


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

Re: [yocto] AppArmor

[Dominig ar Foll (Intel Open Source)]

  
  
Anders,
  
  in the Automotive Grade Linux (AGL) we are using Smack + Cynara
  and that has required quite a bit of side work to make it
  operational.
   - http://docs.automotivelinux.org/
  I have been presenting AGL  Smack based security model in quite a
  few conferences over the world and not many people have come to me
  to talk about their "solution" working either on SE Linux or
  AppArmor. So far I have the impression that AGL is quite unique in
  its full integration of an LSM module in an embedded project.
  
   One of the member of Genivi Alliance (I believe it was Bosh with
  its product called at the time eCore) told (about 3 years ago)
  that they would put their security framework which was based on
  AppAmor, in the Open, but I have never eared about it since that
  time.
  
  Initialisation and update/upgrade are where the LSM provides most
  of the pain. they rarely work out of the box once that LSM is
  active.
--
Dominig ar Foll
Senior Software Architect
Intel Open Source Technology Centre
Le 20/06/2017 à 15:19, Anders Montonen
  a écrit :

Hi,
  
  
  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.
  
  
  Regards,
  
  Anders 
  

-- 
___
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 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.

Cheers,
Paul


-- 

Paul Eggleton
Intel Open Source Technology Centre
-- 
___
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:
> On Sun, Jun 18, 2017 at 7:51 PM, Matthew McClintock 
> wrote:
>>
>> On Sat, Jun 17, 2017 at 11:41 AM, Khem Raj  wrote:
>> > On Sat, Jun 17, 2017 at 8:20 AM, Tom Rini  wrote:
>> >> On Fri, Jun 16, 2017 at 06:05:07PM -0700, Khem Raj wrote:
>> >>> On Fri, Jun 16, 2017 at 12:12 PM, Matthew McClintock
>> >>>  wrote:
>> >>> > This is useful to update the bootloader/vfat partition from u-boot
>> >>> > when
>> >>> > you don't want to update everything:
>> >>> >
>> >>> > U-Boot> tftpboot 0x100 tmp/0VXje
>> >>> > Waiting for Ethernet connection... done.
>> >>> > Using sms0 device
>> >>> > TFTP from server 192.168.0.1; our IP address is 192.168.0.26
>> >>> > Filename 'image.vfat'.
>> >>> > Load address: 0x100
>> >>> > Loading: ##  40 MiB
>> >>> >  2.1 MiB/s
>> >>> > done
>> >>> > Bytes transferred = 41943040 (280 hex)
>> >>> > U-Boot> mmc part
>> >>> >
>> >>> > Partition Map for MMC device 0  --   Partition Type: DOS
>> >>> >
>> >>> > PartStart SectorNum Sectors UUIDType
>> >>> >   1 819281920   a63a4fbc-01 0c Boot
>> >>> >   2 90112   163840  a63a4fbc-02 83
>> >>> > U-Boot> mmc erase 0x2000 0x14000
>> >>> >
>> >>> > MMC erase: dev # 0, block # 8192, count 81920 ... 81920 blocks
>> >>> > erased:
>> >>> > OK
>> >>> > U-Boot> mmc write 0x100 0x2000 0x14000
>> >>> >
>> >>> > MMC write: dev # 0, block # 8192, count 81920 ... 81920 blocks
>> >>> > written:
>> >>> > OK
>> >>> > U-Boot>
>> >>> >
>> >>> > Signed-off-by: Matthew McClintock 
>> >>> > ---
>> >>> >  classes/sdcard_image-rpi.bbclass | 8 
>> >>> >  1 file changed, 8 insertions(+)
>> >>> >
>> >>> > diff --git a/classes/sdcard_image-rpi.bbclass
>> >>> > b/classes/sdcard_image-rpi.bbclass
>> >>> > index af3e807..27a0dfc 100644
>> >>> > --- a/classes/sdcard_image-rpi.bbclass
>> >>> > +++ b/classes/sdcard_image-rpi.bbclass
>> >>> > @@ -72,6 +72,10 @@ SDIMG =
>> >>> > "${IMGDEPLOYDIR}/${IMAGE_NAME}.rootfs.rpi-sdimg"
>> >>> >  # Additional files and/or directories to be copied into the vfat
>> >>> > partition from the IMAGE_ROOTFS.
>> >>> >  FATPAYLOAD ?= ""
>> >>> >
>> >>> > +# SD card vfat partition image name
>> >>> > +SDIMG_VFAT = "${IMGDEPLOYDIR}/${IMAGE_NAME}.vfat"
>> >>> > +SDIMG_LINK_VFAT = "${IMGDEPLOYDIR}/${IMAGE_LINK_NAME}.vfat"
>> >>> > +
>> >>> >  IMAGE_CMD_rpi-sdimg () {
>> >>> >
>> >>> > # Align partitions
>> >>> > @@ -145,6 +149,10 @@ IMAGE_CMD_rpi-sdimg () {
>> >>> > echo "${IMAGE_NAME}" > ${WORKDIR}/image-version-info
>> >>> > mcopy -i ${WORKDIR}/boot.img -v
>> >>> > ${WORKDIR}/image-version-info ::
>> >>> >
>> >>> > +# Deploy vfat partition
>> >>> > +cp ${WORKDIR}/boot.img ${SDIMG_VFAT}
>> >>> > +ln -sf ${SDIMG_VFAT} ${SDIMG_LINK_VFAT}
>> >>> > +
>> >>>
>> >>> it is of use if I am not using u-boot ? is there any penalty ?
>>
>> Other than just having another thing copied into tmp there is no
>> effect, even if you're not using u-boot.
>>
>> >>
>> >> The stock firmware also uses a vfat partition, so this could just as
>> >> easily hold those contents.
>> >
>> > yes it does, can it do the same operations like u-boot ?
>
>
> I think what Khem is trying to say is if we don't need it (because I don't
> think there is any use for it when using proprietary bootloader) can we
> deploy it only in the case of uboot bootloader section?
>
> P.S.: Would really be helpful to push a PR to github too so I can merge it
> easier.

If that's what Khem is saying I can deply only with KERNEL_IMAGETYPE =
uImage... and also go via github. I suppose it's not too useful for
the proprietary bootloader.

Khem, is that what you want?

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

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

[Andrei Gherzan]

On Sun, Jun 18, 2017 at 7:51 PM, Matthew McClintock 
wrote:

> On Sat, Jun 17, 2017 at 11:41 AM, Khem Raj  wrote:
> > On Sat, Jun 17, 2017 at 8:20 AM, Tom Rini  wrote:
> >> On Fri, Jun 16, 2017 at 06:05:07PM -0700, Khem Raj wrote:
> >>> On Fri, Jun 16, 2017 at 12:12 PM, Matthew McClintock
> >>>  wrote:
> >>> > This is useful to update the bootloader/vfat partition from u-boot
> when
> >>> > you don't want to update everything:
> >>> >
> >>> > U-Boot> tftpboot 0x100 tmp/0VXje
> >>> > Waiting for Ethernet connection... done.
> >>> > Using sms0 device
> >>> > TFTP from server 192.168.0.1; our IP address is 192.168.0.26
> >>> > Filename 'image.vfat'.
> >>> > Load address: 0x100
> >>> > Loading: ##  40 MiB
> >>> >  2.1 MiB/s
> >>> > done
> >>> > Bytes transferred = 41943040 (280 hex)
> >>> > U-Boot> mmc part
> >>> >
> >>> > Partition Map for MMC device 0  --   Partition Type: DOS
> >>> >
> >>> > PartStart SectorNum Sectors UUIDType
> >>> >   1 819281920   a63a4fbc-01 0c Boot
> >>> >   2 90112   163840  a63a4fbc-02 83
> >>> > U-Boot> mmc erase 0x2000 0x14000
> >>> >
> >>> > MMC erase: dev # 0, block # 8192, count 81920 ... 81920 blocks
> erased:
> >>> > OK
> >>> > U-Boot> mmc write 0x100 0x2000 0x14000
> >>> >
> >>> > MMC write: dev # 0, block # 8192, count 81920 ... 81920 blocks
> written:
> >>> > OK
> >>> > U-Boot>
> >>> >
> >>> > Signed-off-by: Matthew McClintock 
> >>> > ---
> >>> >  classes/sdcard_image-rpi.bbclass | 8 
> >>> >  1 file changed, 8 insertions(+)
> >>> >
> >>> > diff --git a/classes/sdcard_image-rpi.bbclass
> b/classes/sdcard_image-rpi.bbclass
> >>> > index af3e807..27a0dfc 100644
> >>> > --- a/classes/sdcard_image-rpi.bbclass
> >>> > +++ b/classes/sdcard_image-rpi.bbclass
> >>> > @@ -72,6 +72,10 @@ SDIMG = "${IMGDEPLOYDIR}/${IMAGE_NAME}
> .rootfs.rpi-sdimg"
> >>> >  # Additional files and/or directories to be copied into the vfat
> partition from the IMAGE_ROOTFS.
> >>> >  FATPAYLOAD ?= ""
> >>> >
> >>> > +# SD card vfat partition image name
> >>> > +SDIMG_VFAT = "${IMGDEPLOYDIR}/${IMAGE_NAME}.vfat"
> >>> > +SDIMG_LINK_VFAT = "${IMGDEPLOYDIR}/${IMAGE_LINK_NAME}.vfat"
> >>> > +
> >>> >  IMAGE_CMD_rpi-sdimg () {
> >>> >
> >>> > # Align partitions
> >>> > @@ -145,6 +149,10 @@ IMAGE_CMD_rpi-sdimg () {
> >>> > echo "${IMAGE_NAME}" > ${WORKDIR}/image-version-info
> >>> > mcopy -i ${WORKDIR}/boot.img -v
> ${WORKDIR}/image-version-info ::
> >>> >
> >>> > +# Deploy vfat partition
> >>> > +cp ${WORKDIR}/boot.img ${SDIMG_VFAT}
> >>> > +ln -sf ${SDIMG_VFAT} ${SDIMG_LINK_VFAT}
> >>> > +
> >>>
> >>> it is of use if I am not using u-boot ? is there any penalty ?
>
> Other than just having another thing copied into tmp there is no
> effect, even if you're not using u-boot.
>
> >>
> >> The stock firmware also uses a vfat partition, so this could just as
> >> easily hold those contents.
> >
> > yes it does, can it do the same operations like u-boot ?
>

I think what Khem is trying to say is if we don't need it (because I don't
think there is any use for it when using proprietary bootloader) can we
deploy it only in the case of uboot bootloader section?

P.S.: Would really be helpful to push a PR to github too so I can merge it
easier.

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

[yocto] Yocto eSDK nativesdk vs native vs normal

[Aaron_Wright]

I'm having a hard time figuring out what specific package to install when 
I'm in the eSDK environment.

Say I want to install cmake, do I:

   devtool sdk-install cmake

or:

   devtool sdk-install cmake-native

or:

   devtool sdk-install nativesdk-cmake

CMake is just one example, any other package would cause the same 
confusion for me. 
Does it depend on the package; tools for use in the eSDK vs libraries for 
the target?-- 
___
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,

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
> @@ -188,6 +188,9 @@ def main():
>  parser.add_option("", "--nocheckout",
>  help = "Don't check out branches",
>  action="store_true", dest="nocheckout")
> +parser.add_option("-i", "--initial",
> +help = "Print initial layer value",

Can we change the help text to:

"Print initial values parsed from layer.conf only"


> +action="store_true")
>  parser.add_option("-d", "--debug",
>  help = "Enable debug output",
>  action="store_const", const=logging.DEBUG, dest="loglevel", 
> default=logging.INFO)
> @@ -336,7 +339,7 @@ def main():
>  layerdistros = Distro.objects.filter(layerbranch=layerbranch)
>  layerappends = BBAppend.objects.filter(layerbranch=layerbranch)
>  layerclasses = BBClass.objects.filter(layerbranch=layerbranch)
> -if layerbranch.vcs_last_rev != topcommit.hexsha or 
> options.reload:
> +if layerbranch.vcs_last_rev != topcommit.hexsha or 
> options.reload or options.initial:
>  # Check out appropriate branch
>  if not options.nocheckout:
>  utils.checkout_layer_branch(layerbranch, repodir, 
> logger=logger)
> @@ -361,6 +364,14 @@ def main():
>  layerconfparser.shutdown()
>  sys.exit(1)
>  utils.set_layerbranch_collection_version(layerbranch, 
> layer_config_data, logger=logger)
> +if options.initial:
> +# Use print() rather than logger.info() since "-q" makes 
> it print nothing.
> +print('Initial layer values: %s,%s,%s,%s' % (
> +utils.get_layer_var(layer_config_data, 
> 'BBFILE_COLLECTIONS'), \
> +utils.get_layer_var(layer_config_data, 
> 'LAYERVERSION'), \
> +utils.get_layer_var(layer_config_data, 
> 'LAYERDEPENDS'), \
> +utils.get_layer_var(layer_config_data, 
> 'LAYERRECOMMENDS')))
> +sys.exit(0)

This isn't meant to be human-readable, it's for update.py. Therefore I'd 
suggest a plain
VARIABLENAME = "value" with one variable/value pair per line, and then these 
can be
read by variable name rather than by index.


>  utils.add_dependencies(layerbranch, layer_config_data, 
> logger=logger)
>  utils.add_recommends(layerbranch, layer_config_data, 
> logger=logger)
>  layerbranch.save()
> @@ -716,8 +727,7 @@ def main():
>  import traceback
>  traceback.print_exc()
>  finally:
> -if LooseVersion(bb.__version__) > LooseVersion("1.27"):
> -tinfoil.shutdown()
> +utils.shutdown_tinfoil(tinfoil)

This change is not mentioned in the commit message and if you look at
19a559cfa665b1add51fad41b7db88237fa82a09 you'll see I check the version
intentionally because fido has a broken shutdown() function.


>  shutil.rmtree(tempdir)
>  sys.exit(0)
> diff --git a/layerindex/utils.py b/layerindex/utils.py
> index b7165d0..01a6200 100644
> --- a/layerindex/utils.py
> +++ b/layerindex/utils.py
> @@ -27,6 +27,33 @@ def get_layer(layername):
>  return res[0]
>  return None
>  
> +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.


> +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 is_deps_satisfied(req_col, req_ver, collections):
> +""" Check whether required collection and version are in collections"""
> +for existed_col, existed_ver in collections:
> +if req_col == existed_col:
> +# If there is no version constraint, return True when collection 
> matches
> +if not req_ver:
> +return True
> +else:
> +# If there is no version in the found layer, then don't use 
> this layer.
> +if not existed_ver:
> +continue
> +(op, dep_version) = req_ver.split()
> +success = bb.utils.vercmp_string_op(existed_ver, 
> dep_version, op)
> +if success:
> +return True
> +# Return False when not found
> +return False
> +
>  def get_dependency_layer(depname, version_str=None, logger=None):
>  from layerindex.models import LayerItem, LayerBranch
>  
> @@ -156,6 +183,17 @@ def 

[yocto] [AUH] Upgrade status: 2017-06-21

[auh]

AUH finished upgrade batch the result patches/logs can be found at:
https://logs.yoctoproject.org/auh//20170619081523, next are the statistics:

Recipe upgrade statistics:

* Failed(do_configure): 4
libinput, 1.7.901, Jussi Kukkonen 
gstreamer1.0-rtsp-server, 1.12.0, Maxin B. John 
pinentry, 1.0.0, Armin Kuster 
nspr, 4.15, Armin Kuster 
* Failed(other errors): 44
fontconfig, 2.12.3, Jussi Kukkonen 
libunwind, 1.2.1, Bruce Ashfield 
gstreamer1.0-plugins-bad, 1.12.0, Maxin B. John 
apt, 1.4.6, Aníbal Limón 
ghostscript, 9.21, Hongxu Jia 
psmisc, 23.1, Alexander Kanavin 
guile, 2.2.2, Robert Yang 
perl, 5.26.0, Aníbal Limón 
opkg, 0.3.5, Alejandro del Castillo 
kernelshark, 2.6.1, Alexander Kanavin 
kexec-tools, 2.0.15, Armin Kuster 
gtk+3, 3.90.0, Jussi Kukkonen 
epiphany, 3.24.2, Alexander Kanavin 
mesa, 17.1.3, Otavio Salvador 
opkg-utils, 0.3.5+gitAUTOINC+1a708fd73d, Alejandro del Castillo 

python3-setuptools, 36.0.1, Jose Lamego 
systemd-boot, 233, Chen Qi 
oprofile, 1.2.0rc1, Alexander Kanavin 
bash, 4.4, Hongxu Jia 
bc, 1.07.1, Jose Lamego 
valgrind, 3.13.0, Alexander Kanavin 
logrotate, 9-1, Robert Yang 
webkitgtk, 2.16.3, Alexander Kanavin 
gstreamer1.0, 1.12.0, Maxin B. John 
file, 5.31, Robert Yang 
util-linux, 2.30, Chen Qi 
apr-util, 1.6.0, Hongxu Jia 
gstreamer1.0-plugins-good, 1.12.0, Maxin B. John 
elfutils, 0.169, Hongxu Jia 
diffutils, 3.6, Chen Qi 
liburcu, 0.10.0, Alexander Kanavin 
qemu, 2.9.0, Aníbal Limón 
flex, 2.6.4, Chen Qi 
prelink, 20151030.+gitAUTOINC+927979bbd1, Mark Hatle 

sed, 4.4, Chen Qi 
busybox, 1.26.2, Armin Kuster 
npth, 1.5, Alexander Kanavin 
gstreamer1.0-plugins-base, 1.12.0, Maxin B. John 
dmidecode, 3.1, Alexander Kanavin 
debianutils, 4.8.1.1, Robert Yang 
libnl, 3.3.0, Alexander Kanavin 
openssl, 1.1.0f, Alexander Kanavin 
dpkg, 1.18.24, Aníbal Limón 
gobject-introspection, 1.52.1, Alexander Kanavin 

* Failed(do_fetch): 8
python3-git, 2.1.5, Jose Lamego 
kconfig-frontends, 4.11.0.1, Alexander Kanavin 

git, 2.13.1, Robert Yang 
vulkan, 1.0.51.0, Jussi Kukkonen 
ifupdown, 0.8.19, Maxin B. John 
cryptodev-linux, 1.9, Robert Yang 
cryptodev-tests, 1.9, Robert Yang 
cryptodev-module, 1.9, Robert Yang 
* Failed(get_env): 1
libnewt-python, 0.52.20, Hongxu Jia 
* Succeeded: 23
strace, 4.17, Robert Yang 
vala, 0.36.3, Alexander Kanavin 
apr, 1.6.2, Hongxu Jia 
libgcrypt, 1.7.7, Hongxu Jia 
libfakekey, 0.3+gitAUTOINC+7ad885912e, Alexander Kanavin 

gperf, 3.1, Alexander Kanavin 
sysstat, 11.5.6, Chen Qi 
curl, 7.54.1, Armin Kuster 
eudev, 3.2.2, Alejandro Hernandez 
lttng-tools, 2.9.5, Richard Purdie 
xdg-utils, 1.1.2, Jussi Kukkonen 

Re: [yocto] Yocto eSDK, Editing/Adding Recipes, and VCS

[Paul Eggleton]

Hi Aaron,

On Tuesday, 20 June 2017 11:04:56 PM CEST aaron_wri...@selinc.com wrote:
> I've been trying to document some workflows for my developers using the 
> Yocto eSDK for our image, but I am coming up empty when it comes to 
> editing or adding recipes. I can use devtool to edit a recipe like so:
> 
> devtool edit-recipe -a my-recipe
> 
> But any changes I make are hidden away in the 
> esdk/layers/poky/meta-mylayer directory, which isn't managed by a VCS (git 
> in this instance). So there's this modified file in a directory--great. 
> What is the developer supposed to do with it? Copy it over to a VCS 
> managed directory of meta-mylayer, commit, and push?
> 
> I feel like I'm missing something with the devtool workflow. Can anyone 
> point me in the right direction?

So making changes to existing recipes isn't a very well developed area of the
eSDK at the moment, you're not missing anything. There is a bug open to deal
with this:

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

Thinking off the top of my head, a relatively simple workaround would be
to do something like this (in your image recipe or a class inherited from
it):

sdk_ext_postinst_append() {
cd $target_sdk_dir/layers/
git init
git add -A .
git commit -m "Initial commit"
cd $target_sdk_dir
}

This will be executed at the end of installation and would at least let you 
track
changes, although as you rightly point out they will be a bit buried inside the
SDK structure.

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 03/10] utils.py: remove obsolete dependencies

[Paul Eggleton]

On Tuesday, 13 June 2017 4:36:44 AM CEST Robert Yang wrote:
> Fixed:
>   - set LAYERDEPENDS_openembedded-layer = "core"
>   - $ "update.py -l meta-oe -b master"
> Check from web, its dependency is "openembedded-core"
>   - Change LAYERDEPENDS_openembedded-layer = "foo"
>   - Run "update.py -l meta-oe -b master"
> Check from web, its dependency is "openembedded-core and foo", this is
> wrong, it should be "foo" only, this patch can fix the problem.
> 
> And also the existing checking should filter(required=required),
> otherwise it can't work well when a layer is in both depends and
> recommends, this can't happen in a normal case, but it would surprise the
> user when this happens.
> 
> Signed-off-by: Robert Yang 
> ---
>  layerindex/utils.py | 13 -
>  1 file changed, 12 insertions(+), 1 deletion(-)
> 
> diff --git a/layerindex/utils.py b/layerindex/utils.py
> index 442b121..b7165d0 100644
> --- a/layerindex/utils.py
> +++ b/layerindex/utils.py
> @@ -88,6 +88,7 @@ def _add_dependency(var, name, layerbranch, config_data, 
logger=None, required=T
>  logger.debug('Error parsing %s_%s for %s\n%s' % (var, var_name, 
layer_name, str(vse)))
>  return
>  
> +need_delete = None
>  for dep, ver_list in list(dep_dict.items()):
>  ver_str = None
>  if ver_list:
> @@ -106,8 +107,14 @@ def _add_dependency(var, name, layerbranch, 
config_data, logger=None, required=T
>  logger.error('Cannot resolve %s %s (version %s) for %s' % 
(name, dep, ver_str, layer_name))
>  continue
>  
> +# Preparing to remove obsolete ones
> +if not need_delete:
> +need_delete = 
LayerDependency.objects.filter(layerbranch=layerbranch).filter(required=required).exclude(dependency=dep_layer)
> +else:
> +need_delete = need_delete.exclude(dependency=dep_layer)
> +
>  # Skip existing entries.
> -existing = 
list(LayerDependency.objects.filter(layerbranch=layerbranch).filter(dependency=dep_layer))
> +existing = 
list(LayerDependency.objects.filter(layerbranch=layerbranch).filter(required=required).filter(dependency=dep_layer))
>  if existing:
>  logger.debug('Skipping %s - already a dependency for %s' % 
(dep, layer_name))
>  continue
> @@ -121,6 +128,10 @@ def _add_dependency(var, name, layerbranch, 
config_data, logger=None, required=T
>  layerdep.required = required
>  layerdep.save()
>  
> +if need_delete:
> +logger.debug("Removing obsolete dependencies: %s" % need_delete)
> +need_delete.delete()
> +
>  def set_layerbranch_collection_version(layerbranch, config_data, 
logger=None):
>  layerbranch.collection = config_data.getVar('BBFILE_COLLECTIONS', True)
>  ver_str = "LAYERVERSION_"

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
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.

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 01/10] update.py: update actual branch for layer and bitbake

[Paul Eggleton]

Hi Robert,

Apologies for the delay on reviewing these patches. Some comments below.

On Tuesday, 13 June 2017 4:36:42 AM CEST Robert Yang wrote:
> Add an option "-a" to update actual branch for layer and bitbake, it is
> useful when there are many layers and need update actual branches
> frequantly. We only can update them via website without this patch,
> which is not funny and easy to make mistakes.

frequantly -> frequently
funny -> fun


> * It works with "-l", and "-l bitbake" means update bitbake branch.
> * It requires "-b" to work, and only one branch is supported in a run.
> 
> For example:
> $ update.py -b master -a branch_20170526
> All the layers which have branch master and actual_branch branch_20170526
> will be updated to branch_20170526.
> 
> $ update.py -b master -l meta-oe -a branch_20170526
> Only meta-oe layer will be updated.
> 
> $ update.py -b master -l bitbake -a branch_20170526
> The bitbake's bitbake_branch will be updated.
> 
> Signed-off-by: Robert Yang 
> ---
>  layerindex/update.py | 81 
> ++--
>  layerindex/utils.py  | 11 +++
>  2 files changed, 83 insertions(+), 9 deletions(-)
> 
> diff --git a/layerindex/update.py b/layerindex/update.py
> index d5c56cd..7d2e367 100755
> --- a/layerindex/update.py
> +++ b/layerindex/update.py
> @@ -85,6 +85,43 @@ def prepare_update_layer_command(options, branch, layer, 
> updatedeps=False):
>  cmd += ' -q'
>  return cmd
>  
> +def update_actual_branch(layerquery, fetchdir, branch, options, 
> update_bitbake, bitbakepath):
> +"""Update actual branch for layers and bitbake in database"""
> +to_save = set()
> +actual_branch = options.actual_branch
> +if update_bitbake:
> +branchobj = utils.get_branch(branch)
> +if actual_branch != branchobj.bitbake_branch:
> +if utils.is_branch_valid(bitbakepath, actual_branch):
> +logger.info("bitbake: %s.bitbake_branch: %s -> %s" % 
> (branch, branchobj.bitbake_branch, actual_branch))
> +branchobj.bitbake_branch = actual_branch
> +to_save.add(branchobj)
> +else:
> +logger.info("Skipping update bitbake_branch for bitbake - 
> branch %s doens't exist" % actual_branch)

doens't -> doesn't (there are several of these)


> +else:
> +logger.info("bitbake: %s.bitbake_branch is already %s, so no 
> change" % (branch, actual_branch))
> +
> +for layer in layerquery:
> +urldir = layer.get_fetch_dir()
> +repodir = os.path.join(fetchdir, urldir)
> +if not utils.is_branch_valid(repodir, actual_branch):
> +logger.info("Skipping update actual_branch for %s - branch %s 
> doens't exist" % (layer.name, actual_branch))
> +continue
> +layerbranch = layer.get_layerbranch(branch)
> +if not layerbranch:
> +logger.info("Skipping update actual_branch for %s - layerbranch 
> %s doens't exist" % (layer.name, branch))
> +continue
> +if actual_branch != layerbranch.actual_branch:
> +logger.info("%s: %s.actual_branch: %s -> %s" % (layer.name, 
> branch, layerbranch.actual_branch, actual_branch))
> +layerbranch.actual_branch = actual_branch
> +to_save.add(layerbranch)
> +else:
> +logger.info("%s: %s.actual_branch is already %s, so no change" % 
> (layer.name, branch, actual_branch))
> +
> +# At last, do the save
> +if not options.dryrun:
> +for s in to_save:
> +s.save()
>  
>  def main():
>  if LooseVersion(git.__version__) < '0.3.1':
> @@ -102,6 +139,9 @@ def main():
>  parser.add_option("-l", "--layer",
>  help = "Specify layers to update (use commas to separate 
> multiple). Default is all published layers.",
>  action="store", dest="layers")
> +parser.add_option("-a", "--actual-branch",
> +help = "Update actual branch for layer and bitbake",

We should add "only" to the end of this since this option will suppress
the normal layer update since it returns afterwards, correct?


> +action="store", dest="actual_branch", default='')
>  parser.add_option("-r", "--reload",
>  help = "Reload recipe data instead of updating since last 
> update",
>  action="store_true", dest="reload")
> @@ -151,16 +191,35 @@ def main():
>  logger.error("Please set LAYER_FETCH_DIR in settings.py")
>  sys.exit(1)
>  
> +# 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 

Re: [yocto] Raspberry Pi: how do I change cmdline.txt?

[Piotr Lewicki]

You need to create a bbappend for the linux recipe (i.e. 
"linux-raspberrypi_%.bbappend") and later override the variable "CMDLINE".


For the original content of this variable see 
http://git.yoctoproject.org/cgit/cgit.cgi/meta-raspberrypi/tree/recipes-kernel/linux/linux-raspberrypi.inc



---

Piotr


On 21.06.2017 10:08, Paul D. DeRocco wrote:

I found cmdline.txt in a folder called bcm2835-bootfiles, so I thought
this was related to the bcm2835-bootfiles.bb recipe. I created my own
cmdline.txt and a .bbappend saying where I put it, but it didn't work.
Looking at the recipe, it doesn't mention cmdline.txt. What recipe deals
with that file? I'm just trying to specify tty1 as the console.



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

Re: [yocto] [EXTERNAL] Re: Openjdk-8 fetcher failure

[Maxin B. John]

Hi,

On Wed, Jun 21, 2017 at 05:28:39AM +, Pawar, Alok wrote:
> HI John, 
> 
> Using the 'wget',  I am able to download the file.

That could be a temporary issue then. Have you tried the build
openjdk-8 again to verify it ?

> Best Regards
> Alok Pawar
> Sr. Engineer Product Development

Warm Regards,
Maxin

> -Original Message-
> From: Maxin B. John [mailto:maxin.j...@intel.com] 
> Sent: Monday, June 19, 2017 6:37 PM
> To: Pawar, Alok 
> Cc: yocto@yoctoproject.org
> Subject: [EXTERNAL] Re: [yocto] Openjdk-8 fetcher failure
> 
> Hi Alok,
> 
> On Mon, Jun 19, 2017 at 06:11:20AM +, Pawar, Alok wrote:
> > 
> >Hi All,
> >
> > I am using yocto 2.1.2 krogoth, and I added meta-java in it, but when I 
> > tried to bitbake. I faced fetcher failure, following are the Error :
> >
> >ERROR: openjdk-8-102b14-r0 do_fetch: Fetcher failure: Fetch command failed 
> >with exit code 4, output:
> >
> >  Read error (Connection timed out) in headers.
> >
> >  Read error (Connection timed out) in headers.
> >
> >ERROR: openjdk-8-102b14-r0 do_fetch: Function failed: Fetcher failure for 
> >URL: 
> >'http://hg.openjdk.java.net/jdk8u/jdk8u/hotspot/archive/ac29c9c1193a.tar.bz2;name=hotspot;unpack=false'.
> > Unable to fetch URL from any source.
> >
> >Please give your inputs.
> 
> This could be related to the network configuration in your build machine.
> 
> Have you tried to fetch that file manually using wget from your machine ?
> ie:
> # wget 
> http://hg.openjdk.java.net/jdk8u/jdk8u/hotspot/archive/ac29c9c1193a.tar.bz2
> 
> 
> Best Regards,
> Maxin
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Compiling meta-browser ==>chromium ? cleaning ?

[Riko Ho]

It's compiling now, I cross my finger, thanks Guys,

EXTRA_OEGYP_prepend = "\
-Dcomponent=shared_library \
-Dremove_webcore_debug_symbols=1 -Dfastbuild=1 \
"



On 21/06/17 15:37, Gunnar Andersson wrote:

On Wed, 2017-06-21 at 12:42 +0800, Riko Ho wrote:

did I put it wrongly ?

...

browser/chromium/chromium_54.0.2810.2.bb:7: unparsed line:
'EXTRA_OEGYP_prepend = " -Dcomponent=shared_library

Maybe your line break did not use a backslash?  It was lost, or just
assumed, in Khem's example.

See recipe syntax in Yocto manual [1].  Look for the item "Line
continuation".

HTH
- Gunnar

[1] http://www.yoctoproject.org/docs/current/mega-manual/mega-manual.html#un
derstanding-recipe-syntax

--
Gunnar Andersson 
Development Lead
GENIVI Alliance




--
*

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

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

Re: [yocto] Compiling meta-browser ==>chromium ? cleaning ?

[Riko Ho]

Like this ?

EXTRA_OEGYP_prepend = "\ -Dcomponent=shared_library
-Dremove_webcore_debug_symbols=1 -Dfastbuild=1 \"


On 21/06/17 15:37, Gunnar Andersson wrote:

On Wed, 2017-06-21 at 12:42 +0800, Riko Ho wrote:

did I put it wrongly ?

...

browser/chromium/chromium_54.0.2810.2.bb:7: unparsed line:
'EXTRA_OEGYP_prepend = " -Dcomponent=shared_library

Maybe your line break did not use a backslash?  It was lost, or just
assumed, in Khem's example.

See recipe syntax in Yocto manual [1].  Look for the item "Line
continuation".

HTH
- Gunnar

[1] http://www.yoctoproject.org/docs/current/mega-manual/mega-manual.html#un
derstanding-recipe-syntax

--
Gunnar Andersson 
Development Lead
GENIVI Alliance




--
*

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

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

[yocto] Raspberry Pi: how do I change cmdline.txt?

[Paul D. DeRocco]

I found cmdline.txt in a folder called bcm2835-bootfiles, so I thought
this was related to the bcm2835-bootfiles.bb recipe. I created my own
cmdline.txt and a .bbappend saying where I put it, but it didn't work.
Looking at the recipe, it doesn't mention cmdline.txt. What recipe deals
with that file? I'm just trying to specify tty1 as the console.

-- 

Ciao,   Paul D. DeRocco
Paulmailto:pdero...@ix.netcom.com

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

Re: [yocto] Compiling meta-browser ==>chromium ? cleaning ?

[Gunnar Andersson]

On Wed, 2017-06-21 at 12:42 +0800, Riko Ho wrote:
> did I put it wrongly ?
...
> browser/chromium/chromium_54.0.2810.2.bb:7: unparsed line:
> 'EXTRA_OEGYP_prepend = " -Dcomponent=shared_library

Maybe your line break did not use a backslash?  It was lost, or just
assumed, in Khem's example.   

See recipe syntax in Yocto manual [1].  Look for the item "Line
continuation".

HTH
- Gunnar

[1] http://www.yoctoproject.org/docs/current/mega-manual/mega-manual.html#un
derstanding-recipe-syntax

-- 
Gunnar Andersson 
Development Lead
GENIVI Alliance


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