date:20170925

[yocto] rootfs encryption support

2017-09-25 Thread Kumar, Shrawan

Hello Team ,

Is it possible to get encrypted rootfs during image build  ?

Currently , I am running "cryptsetup" (as sudo) manually   after the final 
image(rootfs.ext4) is produced  . The idea is to get this done within yocto 
environment without sudo problem .


Thanks and Regards
Shrawan
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] eSDK install script failure

2017-09-25 Thread Andrea Galbusera

Paul,

On Tue, Sep 26, 2017 at 6:33 AM, Paul Eggleton <
paul.eggle...@linux.intel.com> wrote:

> Hi Andrea,
>
> On Tuesday, 26 September 2017 4:33:46 AM NZDT Andrea Galbusera wrote:
> > I'm back to this issue after the weeken break. See below the feedback
> from
> > your suggestions.
> >
> > On Thu, Sep 21, 2017 at 11:49 PM, Paul Eggleton <
> > paul.eggle...@linux.intel.com> wrote:
> >
> > > On Friday, 22 September 2017 9:40:41 AM NZST Paul Eggleton wrote:
> > > > On Friday, 22 September 2017 9:22:08 AM NZST Andrea Galbusera wrote:
> > > > > On Thu, Sep 21, 2017 at 10:48 PM, Paul Eggleton <
> > > > > paul.eggle...@linux.intel.com> wrote:
> > > > > > Right, so the next step would be looking for the hash for
> > > > > > python-native.do_populate_sysroot in conf/locked_sigs.inc
> within the
> > > > > > failed SDK install directory and then looking for that in both
> the
> > > sstate-
> > > > > > cache directory within the failed SDK and then in the
> sstate-cache
> > > > > > directory of the build that built it. I suspect it may not be
> there,
> > > but
> > > > > > let me know what you find.
> > > > >
> > > > > Good catch! In the failing SDK neither conf/locked_sigs.inc nor
> > > > > sstate-cache do include any python-native signature or object...
> Only
> > > > > python3-native stuff is there. Weird! As said, SDKs from the same
> build
> > > > > directory, used to work since a few weeks ago. May any recent
> change in
> > > > > poky master have caused this while periodically upgrading without
> > > > > regenerating the sstate-cache?
> > > >
> > > > No, I can't see any added references to python-native anywhere in the
> > > last few
> > > > weeks. If you do bitbake -c clean python-native and then rebuild the
> SDK
> > > does
> > > > the issue go away?
> > >
> > > Actually scratch that, that's not going to help. The question is where
> is
> > > this dependency coming from and why isn't it properly picked up such
> > > that it gets included. bitbake -g -c populate_sdk_ext your-image might
> be
> > > useful in determining that.
> > >
> >
> > $ bitbake core-image-base-dlms -c populate_sdk_ext -g
> >
> > Grepping task-depends.dot for "python-native" gives no match.
> Surprisingly
> > enough (at least for me) I read a different story when doing the same for
> > the image itself
> >
> > $ bitbake core-image-base-dlms -g
> > $ grep python-native task-depends.dot
> >  "python-native.do_populate_lic" [label="python-native
> > do_populate_lic\n:2.7.13-r1.1\n/home/gizero/work/
> smartliving/distro/repo-master/build-poky/conf/../../
> layers/poky/meta/recipes-devtools/python/python[18/7956]
> > .7.13.bb"]
> > "python-native.do_populate_lic" -> "python-native.do_patch"
> > "python-native.do_prepare_recipe_sysroot" [label="python-native
> > do_prepare_recipe_sysroot\n:2.7.13-r1.1\n/home/gizero/work/
> smartliving/distro/repo-master/build-poky/conf/../../
> layers/poky/meta/recipes-devtools/py
> > thon/python-native_2.7.13.bb"]
> > "python-native.do_prepare_recipe_sysroot" ->
> > "openssl-native.do_populate_sysroot"
> > "python-native.do_prepare_recipe_sysroot" ->
> > "pkgconfig-native.do_populate_sysroot"
> > "python-native.do_prepare_recipe_sysroot" ->
> > "automake-native.do_populate_sysroot"
> > "python-native.do_prepare_recipe_sysroot" ->
> > "expat-native.do_populate_sysroot"
> > "python-native.do_prepare_recipe_sysroot" ->
> > "sqlite3-native.do_populate_sysroot"
> > "python-native.do_prepare_recipe_sysroot" -> "python-native.do_fetch"
> > "python-native.do_prepare_recipe_sysroot" ->
> > "bzip2-native.do_populate_sysroot"
> > "python-native.do_prepare_recipe_sysroot" ->
> > "readline-native.do_populate_sysroot"
> > "python-native.do_prepare_recipe_sysroot" ->
> > "zlib-native.do_populate_sysroot"
> > "python-native.do_prepare_recipe_sysroot" ->
> > "autoconf-native.do_populate_sysroot"
> > "python-native.do_prepare_recipe_sysroot" ->
> > "gnu-config-native.do_populate_sysroot"
> > "python-native.do_prepare_recipe_sysroot" ->
> > "libtool-native.do_populate_sysroot"
> > "python-native.do_rm_work_all" [label="python-native
> > do_rm_work_all\n:2.7.13-r1.1\n/home/gizero/work/smartliving/distro/repo-
> master/build-poky/conf/../../layers/poky/meta/recipes-
> devtools/python/python-native_2.7
> > .13.bb"]
> > "python-native.do_rm_work_all" -> "readline-native.do_rm_work"
> > "python-native.do_rm_work_all" -> "gnu-config-native.do_rm_work"
> > "python-native.do_rm_work_all" -> "openssl-native.do_rm_work"
> > "python-native.do_rm_work_all" -> "automake-native.do_rm_work"
> > "python-native.do_rm_work_all" -> "m4-native.do_rm_work"
> > "python-native.do_rm_work_all" -> "makedepend-native.do_rm_work"
> > "python-native.do_rm_work_all" -> "xproto-native.do_rm_work"
> > "python-native.do_rm_work_all" -> "bzip2-native.do_rm_work"
> > "python-native.do_rm_work_all" -> "ncurses-native.do_rm_work"
> > "python-native.do_rm_work_all" -> "python-native.do_rm_work"
> > "python-native.do_rm_work_all" -> "expat-native.do_rm_work"
> >

Re: [yocto] eSDK install script failure

2017-09-25 Thread Paul Eggleton

Hi Andrea,

On Tuesday, 26 September 2017 4:33:46 AM NZDT Andrea Galbusera wrote:
> I'm back to this issue after the weeken break. See below the feedback from
> your suggestions.
> 
> On Thu, Sep 21, 2017 at 11:49 PM, Paul Eggleton <
> paul.eggle...@linux.intel.com> wrote:
> 
> > On Friday, 22 September 2017 9:40:41 AM NZST Paul Eggleton wrote:
> > > On Friday, 22 September 2017 9:22:08 AM NZST Andrea Galbusera wrote:
> > > > On Thu, Sep 21, 2017 at 10:48 PM, Paul Eggleton <
> > > > paul.eggle...@linux.intel.com> wrote:
> > > > > Right, so the next step would be looking for the hash for
> > > > > python-native.do_populate_sysroot in conf/locked_sigs.inc within the
> > > > > failed SDK install directory and then looking for that in both the
> > sstate-
> > > > > cache directory within the failed SDK and then in the sstate-cache
> > > > > directory of the build that built it. I suspect it may not be there,
> > but
> > > > > let me know what you find.
> > > >
> > > > Good catch! In the failing SDK neither conf/locked_sigs.inc nor
> > > > sstate-cache do include any python-native signature or object... Only
> > > > python3-native stuff is there. Weird! As said, SDKs from the same build
> > > > directory, used to work since a few weeks ago. May any recent change in
> > > > poky master have caused this while periodically upgrading without
> > > > regenerating the sstate-cache?
> > >
> > > No, I can't see any added references to python-native anywhere in the
> > last few
> > > weeks. If you do bitbake -c clean python-native and then rebuild the SDK
> > does
> > > the issue go away?
> >
> > Actually scratch that, that's not going to help. The question is where is
> > this dependency coming from and why isn't it properly picked up such
> > that it gets included. bitbake -g -c populate_sdk_ext your-image might be
> > useful in determining that.
> >
> 
> $ bitbake core-image-base-dlms -c populate_sdk_ext -g
> 
> Grepping task-depends.dot for "python-native" gives no match. Surprisingly
> enough (at least for me) I read a different story when doing the same for
> the image itself
> 
> $ bitbake core-image-base-dlms -g
> $ grep python-native task-depends.dot
>  "python-native.do_populate_lic" [label="python-native
> do_populate_lic\n:2.7.13-r1.1\n/home/gizero/work/smartliving/distro/repo-master/build-poky/conf/../../layers/poky/meta/recipes-devtools/python/python[18/7956]
> .7.13.bb"]
> "python-native.do_populate_lic" -> "python-native.do_patch"
> "python-native.do_prepare_recipe_sysroot" [label="python-native
> do_prepare_recipe_sysroot\n:2.7.13-r1.1\n/home/gizero/work/smartliving/distro/repo-master/build-poky/conf/../../layers/poky/meta/recipes-devtools/py
> thon/python-native_2.7.13.bb"]
> "python-native.do_prepare_recipe_sysroot" ->
> "openssl-native.do_populate_sysroot"
> "python-native.do_prepare_recipe_sysroot" ->
> "pkgconfig-native.do_populate_sysroot"
> "python-native.do_prepare_recipe_sysroot" ->
> "automake-native.do_populate_sysroot"
> "python-native.do_prepare_recipe_sysroot" ->
> "expat-native.do_populate_sysroot"
> "python-native.do_prepare_recipe_sysroot" ->
> "sqlite3-native.do_populate_sysroot"
> "python-native.do_prepare_recipe_sysroot" -> "python-native.do_fetch"
> "python-native.do_prepare_recipe_sysroot" ->
> "bzip2-native.do_populate_sysroot"
> "python-native.do_prepare_recipe_sysroot" ->
> "readline-native.do_populate_sysroot"
> "python-native.do_prepare_recipe_sysroot" ->
> "zlib-native.do_populate_sysroot"
> "python-native.do_prepare_recipe_sysroot" ->
> "autoconf-native.do_populate_sysroot"
> "python-native.do_prepare_recipe_sysroot" ->
> "gnu-config-native.do_populate_sysroot"
> "python-native.do_prepare_recipe_sysroot" ->
> "libtool-native.do_populate_sysroot"
> "python-native.do_rm_work_all" [label="python-native
> do_rm_work_all\n:2.7.13-r1.1\n/home/gizero/work/smartliving/distro/repo-master/build-poky/conf/../../layers/poky/meta/recipes-devtools/python/python-native_2.7
> .13.bb"]
> "python-native.do_rm_work_all" -> "readline-native.do_rm_work"
> "python-native.do_rm_work_all" -> "gnu-config-native.do_rm_work"
> "python-native.do_rm_work_all" -> "openssl-native.do_rm_work"
> "python-native.do_rm_work_all" -> "automake-native.do_rm_work"
> "python-native.do_rm_work_all" -> "m4-native.do_rm_work"
> "python-native.do_rm_work_all" -> "makedepend-native.do_rm_work"
> "python-native.do_rm_work_all" -> "xproto-native.do_rm_work"
> "python-native.do_rm_work_all" -> "bzip2-native.do_rm_work"
> "python-native.do_rm_work_all" -> "ncurses-native.do_rm_work"
> "python-native.do_rm_work_all" -> "python-native.do_rm_work"
> "python-native.do_rm_work_all" -> "expat-native.do_rm_work"
> "python-native.do_rm_work_all" -> "pigz-native.do_rm_work"
> "python-native.do_rm_work_all" -> "libtool-native.do_rm_work"
> "python-native.do_rm_work_all" -> "pkgconfig-native.do_rm_work"
> "python-native.do_rm_work_all" -> "gettext-minimal-native.do_rm_work"
> "python-native.do_rm_work_all" ->

Re: [yocto] [layerindex][PATCH] Indicate if layer has YP Compatible certification

2017-09-25 Thread Paul Eggleton

On Tuesday, 26 September 2017 2:23:15 PM NZDT akuster wrote:
> On 09/25/2017 04:41 PM, Amanda Brindle wrote:
> > Allow admin to create Yocto Project versions with the version name,
> > description, an icon link that represents that version, and a link that
> > contains more information about the version.
> 
> Who are the Admins ?

As far as this patch is concerned, anyone who is a superuser or has the 
required permission.

For the OE layer index specifically - Michael Halstead, Mark Hatle and myself 
currently. It's most likely we will grant the permission to someone who is 
involved with maintaining the Yocto Project Compatible program that this links 
to and they'll be the one who manages these things.

Cheers,
Paul

-- 

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

Re: [yocto] [layerindex][PATCH] Indicate if layer has YP Compatible certification

2017-09-25 Thread akuster



On 09/25/2017 04:41 PM, Amanda Brindle wrote:
> Allow admin to create Yocto Project versions with the version name,
> description, an icon link that represents that version, and a link that
> contains more information about the version.

Who are the Admins ?

- armin
>
> Admins who have the "set_yp_compatibility" permission can then
> decide if a layer has Yocto Project compatible certification,
> and if it does, admin can choose which version of Yocto Project
> the layer is compatible with. If a layer is deemed compatible,
> the version's icon will appear next to the layer's name, and
> the icon will redirect to the link with more information.
>
> Fixes [YOCTO #11452]
>
> Signed-off-by: Amanda Brindle 
> ---
>  layerindex/admin.py| 11 +--
>  layerindex/models.py   | 15 +++
>  layerindex/static/css/additional.css   |  5 +
>  templates/layerindex/detail.html   |  3 +++
>  templates/layerindex/layers.html   |  6 +-
>  templates/layerindex/reviewdetail.html |  3 +++
>  templates/layerindex/reviewlist.html   |  6 +-
>  7 files changed, 45 insertions(+), 4 deletions(-)
>
> diff --git a/layerindex/admin.py b/layerindex/admin.py
> index d25829a..a7d024b 100644
> --- a/layerindex/admin.py
> +++ b/layerindex/admin.py
> @@ -44,6 +44,9 @@ class BranchAdmin(CompareVersionAdmin):
>  layerdependency.save()
>  duplicate.short_description = "Duplicate selected Branches"
>  
> +class YPCompatibleVersionAdmin(CompareVersionAdmin):
> +pass
> +
>  class LayerItemAdmin(CompareVersionAdmin):
>  list_filter = ['status', 'layer_type']
>  save_as = True
> @@ -61,9 +64,12 @@ class LayerBranchAdmin(CompareVersionAdmin):
>  LayerMaintainerInline,
>  ]
>  def get_readonly_fields(self, request, obj=None):
> +readonly_fields = self.readonly_fields
>  if obj:
> -return self.readonly_fields + ('layer', 'branch')
> -return self.readonly_fields
> +readonly_fields += ('layer', 'branch')
> +if not request.user.has_perm('layerindex.set_yp_compatibility'):
> +readonly_fields += ('yp_compatible_version',)
> +return readonly_fields
>  
>  class LayerMaintainerAdmin(CompareVersionAdmin):
>  list_filter = ['status', 'layerbranch__layer__name']
> @@ -145,6 +151,7 @@ class RecipeChangesetAdmin(admin.ModelAdmin):
>  ]
>  
>  admin.site.register(Branch, BranchAdmin)
> +admin.site.register(YPCompatibleVersion, YPCompatibleVersionAdmin)
>  admin.site.register(LayerItem, LayerItemAdmin)
>  admin.site.register(LayerBranch, LayerBranchAdmin)
>  admin.site.register(LayerMaintainer, LayerMaintainerAdmin)
> diff --git a/layerindex/models.py b/layerindex/models.py
> index fb2e026..2297152 100644
> --- a/layerindex/models.py
> +++ b/layerindex/models.py
> @@ -141,6 +141,17 @@ class LayerItem(models.Model):
>  def __str__(self):
>  return self.name
>  
> +class YPCompatibleVersion(models.Model):
> +name = models.CharField('Yocto Project Version', max_length=25, 
> unique=True, help_text='Name of this Yocto Project compatible version (e.g. 
> "2.0")')
> +description = models.TextField(blank=True)
> +image_url = models.CharField('Image URL', max_length=300, blank=True)
> +redirect_url = models.CharField('Redirection URL', max_length=100, 
> blank=True)
> +
> +class Meta:
> +ordering = ('name',)
> +
> +def __str__(self):
> +return self.name
>  
>  class LayerBranch(models.Model):
>  layer = models.ForeignKey(LayerItem)
> @@ -152,11 +163,15 @@ class LayerBranch(models.Model):
>  vcs_last_rev = models.CharField('Last revision fetched', max_length=80, 
> blank=True)
>  vcs_last_commit = models.DateTimeField('Last commit date', blank=True, 
> null=True)
>  actual_branch = models.CharField('Actual Branch', max_length=80, 
> blank=True, help_text='Name of the actual branch in the repository matching 
> the core branch')
> +yp_compatible_version = models.ForeignKey(YPCompatibleVersion, 
> null=True, blank=True, on_delete=models.SET_NULL, help_text='Which version of 
> the Yocto Project Compatible program has this layer been approved for for?')
>  
>  updated = models.DateTimeField(auto_now=True)
>  
>  class Meta:
>  verbose_name_plural = "Layer branches"
> +permissions = (
> +("set_yp_compatibility", "Can set YP compatibility"),
> +)
>  
>  def sorted_recipes(self):
>  return self.recipe_set.order_by('pn', '-pv')
> diff --git a/layerindex/static/css/additional.css 
> b/layerindex/static/css/additional.css
> index 2a27712..324ee34 100644
> --- a/layerindex/static/css/additional.css
> +++ b/layerindex/static/css/additional.css
> @@ -232,3 +232,8 @@ blockquote.span7.warn {
>  .valign-middle {
>  vertical-align: middle;
>  }
> +
> +.yp-icon {
> +width: auto;
> +height: 1em;
> +}
> diff --git

[yocto] [infra] git domain name updates

2017-09-25 Thread Michael Halstead

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hello,

As Yocto Project continues to grow load on our git server does as
well. We are going to make a few changes to our git infrastructure to
allow for more growth.

All read-only git operations should point at git.yoctoproject.org. For
example poky can be cloned from the following URLs:

git://git.yoctoproject.org/poky
https://git.yoctoproject.org/git/poky

If you have repositories pointed at www.yoctoproject.org,
git.pokylinux.org, or any other domain name please update their remotes
to git.yoctoproject.org.

Read-write operations via ssh will use a new domain specifically for
that purpose. I've added push.yoctoproject.org and ra.yoctoproject.org
(like ra.kernel.org).

Read-write URLs should be updated to the new domain names. I've
changed mine like so:


git remote set-url origin ssh://g...@push.yoctoproject.org/poky-contrib


This is all ready to go right now. Please update your remotes.

We will have to make these changes required before we can start to get
performance benefits from them. I suggest November 1st 2017 but I need
more feedback before we can set a cut off date.

Thank you,

- --
Michael Halstead
Yocto Project / SysAdmin
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEzowQ2UYmQerfiW8/amSWNbpCWpUFAlnJnKsACgkQamSWNbpC
WpVwphAAkRfTKy64rClsiB2lijbi2Z7o/NJIEbkDgbYf92aeAAJw4KQHLMxbrOS+
lZi6MtUSEGtFGdcxqOZ3RCNagfjA9peiDpcxf0A/Jnax02yQz5njHQco12n7IuYl
Q92CW2wMWfqVHJ+0NZe2THb72OUd6cepjHOeNBUb4L3TFOK6NAc63zaFD24vXqq0
VAx+x3s8DPIyzttS7s3lA1IXlLS1S3jGdhLM/0G0E48QJM3Y/I3ntUJ3G02mVMYc
wJ1a8E1/YTTgcL0Xwioa+EoGXeuAPmbrirlp+e9QXwBzYw/2EjNTt3stEpGCK+xK
Pf7+TNGgky/OMzX9pr51jHl1XwgtZJzmumyyIDA3UewVxxvkkOwsFjICN0keWM3W
GGlkOn+Sn+V7Nnw5MVchX9cexojgebgbaDuyFmlpr+nXin9YKO7ELPnOaENTQouk
lq72nvlfllHDGa0yx6ZbhP/UV5E03Q0g+aDLvoYvY+HWFZGyMFP5cyumEI4H2puQ
mqTjg9aWE3NExA5/gseihxjW/UvGhApfkV5OWXcxv03FmCfLIGNBKdFYJYTtC4gm
WUGZbV8yyw13/F0gwPe/538BEsL+4oJxhk4AqNtGYjbb3m0XpjIxVP/Gbf7WASJi
2r3NDP8SE0ehQE79gqxQIX07+s1smCPJ3EkHvvKY/Bk8QCa2iBg=
=TfzM
-END PGP SIGNATURE-
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [ANNOUNCEMENT] Yocto Project 2.3.2 (pyro 17.0.2) Released

2017-09-25 Thread Tracy Graydon

Hello,

The latest release of the Yocto Project 2.3.2 (pyro-17.0.2) is now available 
for download at:

http://downloads.yoctoproject.org/releases/yocto/yocto-2.3.2/poky-pyro-17.0.2.tar.bz2
http://mirrors.kernel.org/yocto/yocto/yocto-2.3.2/poky-pyro-17.0.2.tar.bz2

A gpg signed version of these release notes is available at:

http://downloads.yoctoproject.org/releases/yocto/yocto-2.3.2/RELEASENOTES

Full pass test report is available at:

https://wiki.yoctoproject.org/wiki/WW38_-_2017-09-20-_Full_Test_Cycle_-_2.3.2_rc1

Thank you to everyone for your contributions to this release!

Tracy Graydon
Yocto Project Build and Release
tracy.gray...@intel.com


--
yocto-2.3.2 Errata


Release Name: eclipse-poky-mars-pyro-17.0.2
Branch: mars/pyro
Tag: mars/pyro-17.0.2
Hash: 92aa0e79e8b01c56f0670af3cd8296ec68b43350
md5: 127844bae64343d1397c12d04eb2bf46
Download Locations:
http://downloads.yoctoproject.org/releases/yocto/yocto-2.3.2/eclipse-poky-mars-pyro-17.0.2.tar.bz2
http://mirrors.kernel.org/yocto/yocto/yocto-2.3.2/eclipse-poky-mars-pyro-17.0.2.tar.bz2

Release Name: eclipse-poky-neon-pyro-17.0.2
Branch: neon/pyro
Tag: neon/pyro-17.0.2
Hash: 83e0083ef3a71e10039ace7d18057dddc154408b
md5: 5a10f42077876d72caafa1e15d8efb8b
Download Locations:
http://downloads.yoctoproject.org/releases/yocto/yocto-2.3.2/eclipse-poky-neon-pyro-17.0.2.tar.bz2
http://mirrors.kernel.org/yocto/yocto/yocto-2.3.2/eclipse-poky-neon-pyro-17.0.2.tar.bz2

Release Name: meta-qt3-pyro-17.0.2
Branch: pyro
Tag: pyro-17.0.2
Hash: f33b73a9563f2dfdfd0ee37b61d65d90197a456f
md5: 60b56ee643f21dd576fda1278a1f5f36
Download Locations:
http://downloads.yoctoproject.org/releases/yocto/yocto-2.3.2/meta-qt3-pyro-17.0.2.tar.bz2
http://mirrors.kernel.org/yocto/yocto/yocto-2.3.2/meta-qt3-pyro-17.0.2.tar.bz2

Release Name: meta-qt4-pyro-17.0.2
Branch: pyro
Tag: pyro-17.0.2
Hash: 88989ae3abe98b30089e7518d3adabe990c40a10
md5: c9f40bd1022ee9219f179bc8b4e46d94
Download Locations:
http://downloads.yoctoproject.org/releases/yocto/yocto-2.3.2/meta-qt4-pyro-17.0.2.tar.bz2
http://mirrors.kernel.org/yocto/yocto/yocto-2.3.2/meta-qt4-pyro-17.0.2.tar.bz2

Release Name: poky-pyro-17.0.2
Branch: pyro
Tag: pyro-17.0.2
Hash: ce26a57e04ad65c02087629701d96448a44e73d5
md5: 97e770b63320860fc0c12cad23480f4a
Download Locations:
http://downloads.yoctoproject.org/releases/yocto/yocto-2.3.2/poky-pyro-17.0.2.tar.bz2
http://mirrors.kernel.org/yocto/yocto/yocto-2.3.2/poky-pyro-17.0.2.tar.bz2


---
 Known Issues
---
N/A

---
Security Fixes
---
linuux-yocto/4.1: update to 4.1.43 plus bluetooth CVE-2017-1000251
linux-yocto/4.9: bluetooth: CVE-2017-1000251
linux-yocto/4.4: bluetooth: CVE-2017-1000251
linux-yocto/4.10: bluetooth: CVE-2017-1000251
linux-yocto/4.10: CVE & misc fixes
libxml2: Fix CVE-2017-8872
taglib: Security fix CVE-2017-12678
ghostscript: CVE-2017-9727, -9835, -11714
ghostscript: fix several CVEs by adding bounds checking
libtasn1: CVE-2017-10790
libsndfile1: Fix CVE-2017-8363
libsndfile1: Fix CVE-2017-8362
libsndfile1: Fix CVE-2017-8361 and CVE-2017-8365
libsndfile1: Fix CVE-2017-6892
wget: Security fix CVE-2017-6508
xserver-xorg: Fix CVE-2017-10971
ruby: fix CVE-2017-922{6-9}
ruby: fix CVE-2017-9224
connman: Fix for CVE-2017-12865
kernel.bbclass: set CVE_PRODUCT to linux_kernel if not set by recipe
cve-check.bbclass: use weak assignment for default CVE_PRODUCT
wpa-supplicant_2.6.bb: set CVE_PRODUCT to wpa_supplicant
sqlite3.inc: set CVE_PRODUCT to sqlite
quota_4.03.bb: set CVE_PRODUCT to linux_diskquota
lttng-ust_2.9.1.bb: set CVE_PRODUCT to ust
python.inc: set CVE_PRODUCT to python
nspr_4.14.bb: set CVE_PRODUCT to netscape_portable_runtime
libsndfile1_1.0.28.bb: set CVE_PRODUCT to libsndfile
libsamplerate0_0.1.9.bb: set CVE_PRODUCT to libsamplerate
libpcre2_10.23.bb: set CVE_PRODUCT to pcre2
libpcre_8.40.bb: set CVE_PRODUCT to prce
icu.inc: set CVE_PRODUCT to international_components_for_unicode
glibc-common.inc: set CVE_PRODUCT to glibc
glib.inc: set CVE_PRODUCT to glib
gcc-common.inc: set CVE_PRODUCT to gcc
flac_1.3.1.bb: set CVE_PRODUCT to libflac
eglinfo.inc: set CVE_PRODUCT to eglinfo
bluez5.inc: set CVE_PRODUCT to bluez
acpid.inc: set CVE_PRODUCT to acpid2
systemd: refuse to load units with errors (CVE-2017-182)
libxml2: Fix CVE-2017-0663
libxml2: Fix CVE-2017-5969
libxml2: Fix CVE-2017-9049 and CVE-2017-9050
libxml2: Fix CVE-2017-9047 and CVE-2017-9048
libgcrypt: fix CVE-2017-7526
libgcrypt: fix CVE-2017-9526

---
Fixes
---
image.bbclass: Sorted ctypes to avoid basehash error
bitbake: cooker: add BB_CMDLINE to enable access to UI command line with memres
linux-yocto/4.1: generix86* bsp fix perf issue with gcc >=7
linux-yocto: Update genericx86* SRCREVs for linux-yocto 4.1
meta-yocto-bsp: bump 4.1 to latest linux stable kernel for the non-x86 BSPs
meta-yocto-bsp: bump to the latest linux stable kernel for the non-x86 BSPs
linux-yocto: Update genericx86* SRCREVs

[yocto] [layerindex][PATCH] Don't show "Starting bitbake server" in update log

2017-09-25 Thread Amanda Brindle

If a log level is set on the command line with -q/-d,
set tinfoil's log level to the appropriate log level.

Fixes [YOCTO #11931]

Signed-off-by: Amanda Brindle 
---
 layerindex/recipeparse.py | 5 -
 layerindex/utils.py   | 5 -
 2 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/layerindex/recipeparse.py b/layerindex/recipeparse.py
index f2a5235..af0c736 100644
--- a/layerindex/recipeparse.py
+++ b/layerindex/recipeparse.py
@@ -73,7 +73,10 @@ def init_parser(settings, branch, bitbakepath, 
enable_tracking=False, nocheckout
 saved_cwd = os.getcwd()
 os.chdir(tempdir)
 
-tinfoil = utils.setup_tinfoil(bitbakepath, enable_tracking)
+if logger:
+tinfoil = utils.setup_tinfoil(bitbakepath, enable_tracking, 
loglevel=logger.getEffectiveLevel())
+else:
+tinfoil = utils.setup_tinfoil(bitbakepath, enable_tracking)
 
 os.chdir(saved_cwd)
 
diff --git a/layerindex/utils.py b/layerindex/utils.py
index 2f9501c..e58d8f6 100644
--- a/layerindex/utils.py
+++ b/layerindex/utils.py
@@ -180,7 +180,7 @@ def set_layerbranch_collection_version(layerbranch, 
config_data, logger=None):
 ver_str += layerbranch.collection
 layerbranch.version = config_data.getVar(ver_str, True)
 
-def setup_tinfoil(bitbakepath, enable_tracking):
+def setup_tinfoil(bitbakepath, enable_tracking, loglevel=None):
 sys.path.insert(0, bitbakepath + '/lib')
 import bb.tinfoil
 import bb.cooker
@@ -192,6 +192,9 @@ def setup_tinfoil(bitbakepath, enable_tracking):
 tinfoil = bb.tinfoil.Tinfoil()
 if enable_tracking:
 tinfoil.cooker.enableDataTracking()
+tinfoil.logger.setLevel(logging.WARNING)
+if loglevel:
+tinfoil.logger.setLevel(loglevel)
 tinfoil.prepare(config_only = True)
 
 return tinfoil
-- 
2.7.4

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

[yocto] [layerindex][PATCH] Indicate if layer has YP Compatible certification

2017-09-25 Thread Amanda Brindle

Allow admin to create Yocto Project versions with the version name,
description, an icon link that represents that version, and a link that
contains more information about the version.

Admins who have the "set_yp_compatibility" permission can then
decide if a layer has Yocto Project compatible certification,
and if it does, admin can choose which version of Yocto Project
the layer is compatible with. If a layer is deemed compatible,
the version's icon will appear next to the layer's name, and
the icon will redirect to the link with more information.

Fixes [YOCTO #11452]

Signed-off-by: Amanda Brindle 
---
 layerindex/admin.py| 11 +--
 layerindex/models.py   | 15 +++
 layerindex/static/css/additional.css   |  5 +
 templates/layerindex/detail.html   |  3 +++
 templates/layerindex/layers.html   |  6 +-
 templates/layerindex/reviewdetail.html |  3 +++
 templates/layerindex/reviewlist.html   |  6 +-
 7 files changed, 45 insertions(+), 4 deletions(-)

diff --git a/layerindex/admin.py b/layerindex/admin.py
index d25829a..a7d024b 100644
--- a/layerindex/admin.py
+++ b/layerindex/admin.py
@@ -44,6 +44,9 @@ class BranchAdmin(CompareVersionAdmin):
 layerdependency.save()
 duplicate.short_description = "Duplicate selected Branches"
 
+class YPCompatibleVersionAdmin(CompareVersionAdmin):
+pass
+
 class LayerItemAdmin(CompareVersionAdmin):
 list_filter = ['status', 'layer_type']
 save_as = True
@@ -61,9 +64,12 @@ class LayerBranchAdmin(CompareVersionAdmin):
 LayerMaintainerInline,
 ]
 def get_readonly_fields(self, request, obj=None):
+readonly_fields = self.readonly_fields
 if obj:
-return self.readonly_fields + ('layer', 'branch')
-return self.readonly_fields
+readonly_fields += ('layer', 'branch')
+if not request.user.has_perm('layerindex.set_yp_compatibility'):
+readonly_fields += ('yp_compatible_version',)
+return readonly_fields
 
 class LayerMaintainerAdmin(CompareVersionAdmin):
 list_filter = ['status', 'layerbranch__layer__name']
@@ -145,6 +151,7 @@ class RecipeChangesetAdmin(admin.ModelAdmin):
 ]
 
 admin.site.register(Branch, BranchAdmin)
+admin.site.register(YPCompatibleVersion, YPCompatibleVersionAdmin)
 admin.site.register(LayerItem, LayerItemAdmin)
 admin.site.register(LayerBranch, LayerBranchAdmin)
 admin.site.register(LayerMaintainer, LayerMaintainerAdmin)
diff --git a/layerindex/models.py b/layerindex/models.py
index fb2e026..2297152 100644
--- a/layerindex/models.py
+++ b/layerindex/models.py
@@ -141,6 +141,17 @@ class LayerItem(models.Model):
 def __str__(self):
 return self.name
 
+class YPCompatibleVersion(models.Model):
+name = models.CharField('Yocto Project Version', max_length=25, 
unique=True, help_text='Name of this Yocto Project compatible version (e.g. 
"2.0")')
+description = models.TextField(blank=True)
+image_url = models.CharField('Image URL', max_length=300, blank=True)
+redirect_url = models.CharField('Redirection URL', max_length=100, 
blank=True)
+
+class Meta:
+ordering = ('name',)
+
+def __str__(self):
+return self.name
 
 class LayerBranch(models.Model):
 layer = models.ForeignKey(LayerItem)
@@ -152,11 +163,15 @@ class LayerBranch(models.Model):
 vcs_last_rev = models.CharField('Last revision fetched', max_length=80, 
blank=True)
 vcs_last_commit = models.DateTimeField('Last commit date', blank=True, 
null=True)
 actual_branch = models.CharField('Actual Branch', max_length=80, 
blank=True, help_text='Name of the actual branch in the repository matching the 
core branch')
+yp_compatible_version = models.ForeignKey(YPCompatibleVersion, null=True, 
blank=True, on_delete=models.SET_NULL, help_text='Which version of the Yocto 
Project Compatible program has this layer been approved for for?')
 
 updated = models.DateTimeField(auto_now=True)
 
 class Meta:
 verbose_name_plural = "Layer branches"
+permissions = (
+("set_yp_compatibility", "Can set YP compatibility"),
+)
 
 def sorted_recipes(self):
 return self.recipe_set.order_by('pn', '-pv')
diff --git a/layerindex/static/css/additional.css 
b/layerindex/static/css/additional.css
index 2a27712..324ee34 100644
--- a/layerindex/static/css/additional.css
+++ b/layerindex/static/css/additional.css
@@ -232,3 +232,8 @@ blockquote.span7.warn {
 .valign-middle {
 vertical-align: middle;
 }
+
+.yp-icon {
+width: auto;
+height: 1em;
+}
diff --git a/templates/layerindex/detail.html b/templates/layerindex/detail.html
index 4f1b333..f721096 100644
--- a/templates/layerindex/detail.html
+++ b/templates/layerindex/detail.html
@@ -30,6 +30,9 @@
 
 
 {{ layeritem.name }}
+{% if

[yocto] RPI VideoCore IV bare-metal release

2017-09-25 Thread Edward Vidal

Hello All.When Ultibo core was first released at the start of 2016 perhaps the 
most surprising thing for us was how much interest there was in using graphics 
and displaying information on screen, the questions began almost from day one 
and have persisted to this day. We had initially envisaged Ultibo as an IoT 
platform to be hidden away and used for sensing, controlling and monitoring 
often without any console, display or visual output at all. Of course IoT means 
many things to many people so our vision of network connected gadgets didn’t 
quite take account of the true potential offered by the Raspberry Pi.It is with 
great pleasure that we announce today the release of Ultibo core 2.0, the 
Beetroot release, and the inclusion of full support for the VideoCore IV GPU in 
all models of the Raspberry Pi. Anyone who has read about this subject will 
have seen a lot of information, some of it true, some of it not so true and 
others just plain wrong. Along the way we’ve seen many claims, there is no 
documentation, it’s all a secret and closed source or it can’t be done because 
they won’t release the details. We are not about to try and tell you this was 
an easy task but with a lot of research, reading, exploration and 
experimentation we have arrived at a result that we are very proud of. Once 
again it shows that anything can be done if you really want it to happen.Today 
we pass the baton to you, the Ultibo community, it’s your turn to show us what 
you can do now that you have some of the most powerful graphics features at 
your disposal. Let’s get the message out to the world and show everyone what is 
possible if you have a little bit of imagination, it’s time to make something 
amazing.As always the latest installer is available from the download page, get 
your copy now and try it out.
 For those who might prefer to build their own version for Windows or for Linux 
see the wiki for instructions.
https://ultibo.org/Let me know if you have any questions.
 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] Unclear sstate-cache dir permissions

2017-09-25 Thread Zoran Stojsavljevic

My best guess is that being user1 from the user-group, I would NOT want my
permissions to be 775, since any other user of this user-group would have
unrestricted RWX access to my private /home/user1 space. Rather 640 by
default.

And sharing cache among different users of the same group with the same
permissions 775 still, in my opinion, is not a good idea, since, as my best
understanding is, having different packages/releases, sstate-cache will be
superposition of these different packages/releases (humongous
sstate-cache)... In the sense, that any user can do whatever to shared
sstate-cache, and to harm other users (unintentionally).

Divide and conquer is better approach. Agree if the same user shares two
different releases with the same sstate-cache, as single user. Has only
control over, does not harm anyone else if something go awry.

Much more cleaner... Seems. IMHO.

Zoran
___

On Mon, Sep 25, 2017 at 8:55 PM, Burton, Ross  wrote:

> I'm guessing one of the users has a different umask to the other, so is
> writing directories with mode 755 instead of 775.
>
> Ross
>
> On 25 September 2017 at 19:41, Marco  wrote:
>
>> Hello,
>> I am trying to share a sstate-cache between two (or more) users in a
>> shared directory.
>> Although I set the directory owner, group and permissions I face to a
>> weird condition that I don't understand.
>> Particularly why some directories don't have the group write
>> permisisons that drive me to a buld failure for mambers of the group.
>>
>> I wonder if I am doing something wrong or I have an unexpected issue.
>>
>>
>> koan@kmobile:sstate-cache$ ll
>> totale 1028
>> drwxrwxr-x   2 koan devgroup 4096 set 14 15:32 00
>> drwxrwxr-x   2 koan devgroup 4096 set 14 14:37 01
>> ...
>> drwxr-xr-x   2 koan devgroup 4096 set 14 15:31 1d
>> drwxrwxr-x   2 koan devgroup 4096 set 14 15:31 1e
>> ...
>> drwxr-xr-x   2 koan devgroup 4096 set 14 15:32 27
>> drwxrwxr-x   2 koan devgroup 4096 set 14 15:32 28
>> ...
>> etc...
>>
>>
>> Any help would be greatly appreciated.
>>
>> Thank you
>> --
>> Marco 'mckoan'
>> --
>> ___
>> yocto mailing list
>> yocto@yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/yocto
>>
>
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Release directory layout 2.3.2

2017-09-25 Thread Jeremy A. Puhlman

Was the change to the directory structure release for 2.3.2 intentional. 
All the other releases are under:

http://downloads.yoctoproject.org/releases/yocto/yocto-
where as 2.3.2 is
http://downloads.yoctoproject.org/releases/yocto/yocto-version>/yocto-


--
Jeremy A. Puhlman
jpuhl...@mvista.com

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

Re: [yocto] Unclear sstate-cache dir permissions

2017-09-25 Thread Burton, Ross

I'm guessing one of the users has a different umask to the other, so is
writing directories with mode 755 instead of 775.

Ross

On 25 September 2017 at 19:41, Marco  wrote:

> Hello,
> I am trying to share a sstate-cache between two (or more) users in a
> shared directory.
> Although I set the directory owner, group and permissions I face to a
> weird condition that I don't understand.
> Particularly why some directories don't have the group write
> permisisons that drive me to a buld failure for mambers of the group.
>
> I wonder if I am doing something wrong or I have an unexpected issue.
>
>
> koan@kmobile:sstate-cache$ ll
> totale 1028
> drwxrwxr-x   2 koan devgroup 4096 set 14 15:32 00
> drwxrwxr-x   2 koan devgroup 4096 set 14 14:37 01
> ...
> drwxr-xr-x   2 koan devgroup 4096 set 14 15:31 1d
> drwxrwxr-x   2 koan devgroup 4096 set 14 15:31 1e
> ...
> drwxr-xr-x   2 koan devgroup 4096 set 14 15:32 27
> drwxrwxr-x   2 koan devgroup 4096 set 14 15:32 28
> ...
> etc...
>
>
> Any help would be greatly appreciated.
>
> Thank you
> --
> Marco 'mckoan'
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Unclear sstate-cache dir permissions

2017-09-25 Thread Marco

Hello,
I am trying to share a sstate-cache between two (or more) users in a
shared directory.
Although I set the directory owner, group and permissions I face to a
weird condition that I don't understand.
Particularly why some directories don't have the group write
permisisons that drive me to a buld failure for mambers of the group.

I wonder if I am doing something wrong or I have an unexpected issue.


koan@kmobile:sstate-cache$ ll
totale 1028
drwxrwxr-x   2 koan devgroup 4096 set 14 15:32 00
drwxrwxr-x   2 koan devgroup 4096 set 14 14:37 01
...
drwxr-xr-x   2 koan devgroup 4096 set 14 15:31 1d
drwxrwxr-x   2 koan devgroup 4096 set 14 15:31 1e
...
drwxr-xr-x   2 koan devgroup 4096 set 14 15:32 27
drwxrwxr-x   2 koan devgroup 4096 set 14 15:32 28
...
etc...


Any help would be greatly appreciated.

Thank you
--
Marco 'mckoan'
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [ANNOUNCEMENT] Yocto Project 2.2.2 (morty 16.0.2) Released

2017-09-25 Thread Tracy Graydon

Hello,

The latest release of the Yocto Project 2.2.2 (morty-16.0.2) is now available 
for download at:

http://downloads.yoctoproject.org/releases/yocto/yocto-2.2.2/poky-morty-16.0.2.tar.bz2
http://mirrors.kernel.org/yocto/yocto/yocto-2.2.2/poky-morty-16.0.2.tar.bz2

A gpg signed version of these release notes is available at:

http://downloads.yoctoproject.org/releases/yocto/yocto-2.2.2/RELEASENOTES

Full pass test report is available at:

https://wiki.yoctoproject.org/wiki/WW37_-_2017-09-13_-_Full_Point_Release_Test_Cycle_2.2.2_rc2

Thank you to everyone for your contributions to this release!

Tracy Graydon
Yocto Project Build and Release
tracy.gray...@intel.com




yocto-2.2.2 Errata


Release Name: eclipse-poky-mars-morty-16.0.2
Branch: mars/morty
Tag: mars/morty-16.0.2
Hash: 92aa0e79e8b01c56f0670af3cd8296ec68b43350
md5: a4090d5ca39f9fbe256a975e275855d0
Download Locations:
http://downloads.yoctoproject.org/releases/yocto/yocto-2.2.2/eclipse-poky-mars-morty-16.0.2.tar.bz2
http://mirrors.kernel.org/yocto/yocto/yocto-2.2.2/eclipse-poky-mars-morty-16.0.2.tar.bz2

Release Name: eclipse-poky-neon-morty-16.0.2
Branch: neon/morty
Tag: neon/morty-16.0.2
Hash: 83e0083ef3a71e10039ace7d18057dddc154408b
md5: a5966c547946858abc7145cbef4bf9e7
Download Locations:
http://downloads.yoctoproject.org/releases/yocto/yocto-2.2.2/eclipse-poky-neon-morty-16.0.2.tar.bz2
http://mirrors.kernel.org/yocto/yocto/yocto-2.2.2/eclipse-poky-neon-morty-16.0.2.tar.bz2

Release Name: meta-qt3-morty-16.0.2
Branch: morty
Tag: morty-16.0.2
Hash: f33b73a9563f2dfdfd0ee37b61d65d90197a456f
md5: c20650532eba08fe1c8001e9ddec8df2
Download Locations:
http://downloads.yoctoproject.org/releases/yocto/yocto-2.2.2/meta-qt3-morty-16.0.2.tar.bz2
http://mirrors.kernel.org/yocto/yocto/yocto-2.2.2/meta-qt3-morty-16.0.2.tar.bz2

Release Name: meta-qt4-morty-16.0.2
Branch: morty
Tag: morty-16.0.2
Hash: f389368dc86e745df14cab9eeb9a94bc02bd273e
md5: bfcd270937944d1c48a356a50cb6dfb7
Download Locations:
http://downloads.yoctoproject.org/releases/yocto/yocto-2.2.2/meta-qt4-morty-16.0.2.tar.bz2
http://mirrors.kernel.org/yocto/yocto/yocto-2.2.2/meta-qt4-morty-16.0.2.tar.bz2

Release Name: poky-morty-16.0.2
Branch: morty
Tag: morty-16.0.2
Hash: 60402978fe3648bf560b3386c6e9dd661cdf2083
md5: d09e757d5d73093062f59a07ec51b4f6
Download Locations:
http://downloads.yoctoproject.org/releases/yocto/yocto-2.2.2/poky-morty-16.0.2.tar.bz2
http://mirrors.kernel.org/yocto/yocto/yocto-2.2.2/poky-morty-16.0.2.tar.bz2


---
 Known Issues
---
N/A

---
Security Fixes
---
connman: Fix for CVE-2017-12865
systemd: refuse to load units with errors (CVE-2017-182)
glibc: Security fix CVE-2016-6323
bash: CVE-2016-0634
libxslt: Fix CVE-2017-5029
binutils: fix CVE-2017-7210
binutils: fix CVE-2017-7209 in readelf
binutils: fix CVE-2017-6969 in readelf
libgcrypt: fix CVE-2017-7526
libgcrypt: fix CVE-2017-9526
ghostscript : CVE-2016-10219, CVE-2016-10220, CVE-2017-5951
ghostscript: CVE-2017-7207
libxml2: CVE-2016-9318
bind: Security fix CVE-2016-6170
bind: Security fix CVE-2016-8864
busybox: Security fix CVE-2016-6301
binutils: Fix CVE-2017-6965 and CVE-2017-6966
tar: CVE-2016-6321
bash: fix CVE-2016-9401


---
Fixes
---
glibc-locale: add runtime dependency on glibc
neard: Fix parallel build issue
oeqa/selftest: Drop http sstate sharing
selftest/eSDK.py: Cleanup when there is an error in setUpClass
oeqa/selftest: Adds test case for sdk-update eSDK
selftest/eSDK.py: fix sstate dir not found error
uninative: Update to 1.7 uninative release
yocto-uninative: Update to the 1.6 release
yocto-uninative: Update to the 1.5 release
python3-native: Avoid use of getentropy/getrandom
python-numpy: Fix issues with recent glibc versions
qemu: Backport a patch for recent glibc versions
recipes-kernel: Skip kernel version check on kernel templates
scripts/runqemu: avoid overridden user input for bootparams
kernel, license, sstate, rootfs.py: Remove deploy directory README
insane.bbclass: fix override handling in RDEPENDS QA
icecc.bbclass: prevent nativesdk builds depending on target specific KERNEL_CC
sstate-sysroot-cruft: Add /etc/ld.so.conf to whitelist
test-dependencies.sh: Strip also '\.bb: .*' before adding failed recipe to list 
of failed
image: Fix "metadata is not deterministic" when chaining 2+ CONVERSION_CMDs
image.bbclass: Correct chaining compression support
systemd: remove upstreamed patch
archiver: Escape recipe name in regex
libpng12: move SRC_URI back to SOURCEFORGE_MIRROR
systemd: Disable DefaultDependencies for sysv scripts on rcS runlevel
lsof: update SRC_URI
lsof: minor recipe cleanup
lsof: clear setuid
ed: update SRC_URI to OSL
rng-tools: update SRC_URI to SOURCEFORGE_MIRROR
pcre: update SRC_URI to SOURCEFORGE_MIRROR
glibc: fix pthread_cond_broadcast issue (arm)
wic: fix calculation of partition number
docbook-utils: update SRC_URI from fedora to osl
sgml-common: update SRC_URI

Re: [yocto] eSDK install script failure

2017-09-25 Thread Andrea Galbusera

Hi Paul,

I'm back to this issue after the weeken break. See below the feedback from
your suggestions.

On Thu, Sep 21, 2017 at 11:49 PM, Paul Eggleton <
paul.eggle...@linux.intel.com> wrote:

> On Friday, 22 September 2017 9:40:41 AM NZST Paul Eggleton wrote:
> > On Friday, 22 September 2017 9:22:08 AM NZST Andrea Galbusera wrote:
> > > On Thu, Sep 21, 2017 at 10:48 PM, Paul Eggleton <
> > > paul.eggle...@linux.intel.com> wrote:
> > > > Right, so the next step would be looking for the hash for
> > > > python-native.do_populate_sysroot in conf/locked_sigs.inc within the
> > > > failed SDK install directory and then looking for that in both the
> sstate-
> > > > cache directory within the failed SDK and then in the sstate-cache
> > > > directory of the build that built it. I suspect it may not be there,
> but
> > > > let me know what you find.
> > >
> > > Good catch! In the failing SDK neither conf/locked_sigs.inc nor
> > > sstate-cache do include any python-native signature or object... Only
> > > python3-native stuff is there. Weird! As said, SDKs from the same build
> > > directory, used to work since a few weeks ago. May any recent change in
> > > poky master have caused this while periodically upgrading without
> > > regenerating the sstate-cache?
> >
> > No, I can't see any added references to python-native anywhere in the
> last few
> > weeks. If you do bitbake -c clean python-native and then rebuild the SDK
> does
> > the issue go away?
>
> Actually scratch that, that's not going to help. The question is where is
> this dependency coming from and why isn't it properly picked up such
> that it gets included. bitbake -g -c populate_sdk_ext your-image might be
> useful in determining that.
>

$ bitbake core-image-base-dlms -c populate_sdk_ext -g

Grepping task-depends.dot for "python-native" gives no match. Surprisingly
enough (at least for me) I read a different story when doing the same for
the image itself

$ bitbake core-image-base-dlms -g
$ grep python-native task-depends.dot
 "python-native.do_populate_lic" [label="python-native
do_populate_lic\n:2.7.13-r1.1\n/home/gizero/work/smartliving/distro/repo-master/build-poky/conf/../../layers/poky/meta/recipes-devtools/python/python[18/7956]
.7.13.bb"]
"python-native.do_populate_lic" -> "python-native.do_patch"
"python-native.do_prepare_recipe_sysroot" [label="python-native
do_prepare_recipe_sysroot\n:2.7.13-r1.1\n/home/gizero/work/smartliving/distro/repo-master/build-poky/conf/../../layers/poky/meta/recipes-devtools/py
thon/python-native_2.7.13.bb"]
"python-native.do_prepare_recipe_sysroot" ->
"openssl-native.do_populate_sysroot"
"python-native.do_prepare_recipe_sysroot" ->
"pkgconfig-native.do_populate_sysroot"
"python-native.do_prepare_recipe_sysroot" ->
"automake-native.do_populate_sysroot"
"python-native.do_prepare_recipe_sysroot" ->
"expat-native.do_populate_sysroot"
"python-native.do_prepare_recipe_sysroot" ->
"sqlite3-native.do_populate_sysroot"
"python-native.do_prepare_recipe_sysroot" -> "python-native.do_fetch"
"python-native.do_prepare_recipe_sysroot" ->
"bzip2-native.do_populate_sysroot"
"python-native.do_prepare_recipe_sysroot" ->
"readline-native.do_populate_sysroot"
"python-native.do_prepare_recipe_sysroot" ->
"zlib-native.do_populate_sysroot"
"python-native.do_prepare_recipe_sysroot" ->
"autoconf-native.do_populate_sysroot"
"python-native.do_prepare_recipe_sysroot" ->
"gnu-config-native.do_populate_sysroot"
"python-native.do_prepare_recipe_sysroot" ->
"libtool-native.do_populate_sysroot"
"python-native.do_rm_work_all" [label="python-native
do_rm_work_all\n:2.7.13-r1.1\n/home/gizero/work/smartliving/distro/repo-master/build-poky/conf/../../layers/poky/meta/recipes-devtools/python/python-native_2.7
.13.bb"]
"python-native.do_rm_work_all" -> "readline-native.do_rm_work"
"python-native.do_rm_work_all" -> "gnu-config-native.do_rm_work"
"python-native.do_rm_work_all" -> "openssl-native.do_rm_work"
"python-native.do_rm_work_all" -> "automake-native.do_rm_work"
"python-native.do_rm_work_all" -> "m4-native.do_rm_work"
"python-native.do_rm_work_all" -> "makedepend-native.do_rm_work"
"python-native.do_rm_work_all" -> "xproto-native.do_rm_work"
"python-native.do_rm_work_all" -> "bzip2-native.do_rm_work"
"python-native.do_rm_work_all" -> "ncurses-native.do_rm_work"
"python-native.do_rm_work_all" -> "python-native.do_rm_work"
"python-native.do_rm_work_all" -> "expat-native.do_rm_work"
"python-native.do_rm_work_all" -> "pigz-native.do_rm_work"
"python-native.do_rm_work_all" -> "libtool-native.do_rm_work"
"python-native.do_rm_work_all" -> "pkgconfig-native.do_rm_work"
"python-native.do_rm_work_all" -> "gettext-minimal-native.do_rm_work"
"python-native.do_rm_work_all" -> "util-macros-native.do_rm_work"
"python-native.do_rm_work_all" -> "quilt-native.do_rm_work"
"python-native.do_rm_work_all" -> "autoconf-native.do_rm_work"
"python-native.do_rm_work_all" -> "cryptodev-linux-native.do_rm_work"
"python-native.do_rm_work_all" -> "xz-native.do_rm_work"

[yocto] Yocto Project Status WW39’17

2017-09-25 Thread Jolley, Stephen K

Current Dev Position: YP 2.4 M4 - We are feature frozen.

Next Deadline: YP 2.4 Final Cut off is Sept. 18, 2017

SWAT team rotation: Stephano -> Maxin on Sept. 22, 2017.

SWAT team rotation: Maxin -> Cal on Sept. 29, 2017

https://wiki.yoctoproject.org/wiki/Yocto_Build_Failure_Swat_Team

Key Status/Updates:

·YP 2.3.2 (pyro) had a successful QA pass and is due for release
imminently. See:
https://wiki.yoctoproject.org/wiki/WW38_-_2017-09-20-_Full_Test_Cycle_-_2.3.2_rc1

·YP 2.2.2 (morty) had a successful QA pass and is due for release
imminently. The issues previously identified were due to confusion over
features between master and morty. See:
https://wiki.yoctoproject.org/wiki/WW37_-_2017-09-13_-_Full_Point_Release_Test_Cycle_2.2.2_rc2

·2.4 rc1 has not been built yet however several key issues have been
addressed including a couple of pseudo issues (select file descriptor overflows
and fastop reply data loss protection), qemu logging issues which generated
incorrect error reports and bitbake server timeout problems.

·The remaining major issue is size overflow of the sato-sdk-ptest image
which occurs when we merge certain pending patches. We’re working on
identifying a solution to allow the remaining patches to merged and will then
be ready for the rc1 build.

·As a reminder, we are still in feature freeze and working on bug
fixing. As such, recipe upgrades are not going to be taken, nor are patches
which cause changes in behavior or break compatibility. In future releases our
policy regarding version upgrades will be to identify anything that needs to
change in M4 in advance (e.g. kernel or u-boot) so this issue becomes clearer
and only known changes come in.

Planned upcoming dot releases:

YP 2.2.2 Cut off June 5, 2017 - Pending release soon.

YP 2.2.2 Release by June, 16 2017

YP 2.3.2 Cut off Sept. 1, 2017 - Pending release soon.

YP 2.3.2 Release by Sept. 15, 2017

Key YP 2.4 Dates are:

YP 2.4 M4 (Final) Cut off is Sept. 18, 2017 - Should build soon

YP 2.4 M4 (Final) Release by Oct. 20, 2017

Tracking Metrics:

WDD 2380 (last week 2456)

(https://wiki.yoctoproject.org/charts/combo.html)

Key Status Links for YP:

https://wiki.yoctoproject.org/wiki/Yocto_Project_v2.4_Status

https://wiki.yoctoproject.org/wiki/Yocto_2.4_Schedule

https://wiki.yoctoproject.org/wiki/Yocto_2.4_Features

[If anyone has suggestions for other information you’d like to see on this
weekly status update, let us know!]

Thanks,

Stephen K. Jolley
Yocto Project Program Manager
INTEL, MS JF1-255, 2111 N.E. 25th Avenue, Hillsboro, OR 97124
• Work Telephone:(503) 712-0534
•Cell: (208) 244-4460
• Email: stephen.k.jol...@intel.com

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

Re: [linux-yocto] [kernel-cache][PATCH] intel-common-drivers: Add x2apic

2017-09-25 Thread Bruce Ashfield


On 09/25/2017 12:56 AM, Syed Mohamad Fauzi, Syed Johan Arif wrote:

I almost forgot to mention, can this patch be applied to kernel 4.4 and 4.9.



This is now merged.

But is there any reason that 4.10 and 4.12 wouldn't want the same
change ?

Bruce


Kind regards
Johan

-Original Message-
From: Syed Mohamad Fauzi, Syed Johan Arif
Sent: Thursday, September 21, 2017 7:29 PM
To: linux-yocto@yoctoproject.org
Cc: Syed Mohamad Fauzi, Syed Johan Arif 
; Tan, Raymond 

Subject: [linux-yocto][kernel-cache][PATCH] intel-common-drivers: Add x2apic

Dear maintainer,

The Intel Denverton platform requires x2apic to boot hence the need to enable 
it in intel-common-drivers as a built-in feature

Syed Mohamad Fauzi, Syed Johan Arif (1):
   intel-common: adding x2apic

  bsp/intel-common/intel-common-drivers.scc | 1 +
  1 file changed, 1 insertion(+)

--
1.9.1



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

Re: [linux-yocto] [PATCH 1/2][v2] cgl: Add cgl features

2017-09-25 Thread Bruce Ashfield


On 09/25/2017 07:43 AM, zhe...@windriver.com wrote:

From: He Zhe 

Add features for Carrier Grade Linux
https://wiki.linuxfoundation.org/cgl/start


This says patch 1/2, but I don't think there's actually a patch
two. If that is wrong, resend patch 2, since I don't have it.

I've merged this to the 4.12 and master branches of the kernel-cache

Bruce



Signed-off-by: He Zhe 
---
  cgl/cfg/dmm.cfg  |  1 +
  cgl/cfg/dmm.scc  |  4 
  cgl/cfg/drbd.cfg |  1 +
  cgl/cfg/drbd.scc |  4 
  cgl/cfg/fs/ocfs2.cfg | 15 +++
  cgl/cfg/fs/ocfs2.scc |  4 
  cgl/cfg/iscsi.cfg| 14 ++
  cgl/cfg/iscsi.scc|  6 ++
  cgl/cfg/net/ip_vs.cfg| 36 
  cgl/cfg/net/ip_vs.scc|  4 
  cgl/cfg/net/l2tp.cfg | 15 +++
  cgl/cfg/net/l2tp.scc |  4 
  cgl/cfg/net/macvlan.cfg  | 14 ++
  cgl/cfg/net/macvlan.scc  |  4 
  cgl/features/aoe/aoe.cfg |  1 +
  cgl/features/aoe/aoe.scc |  4 
  cgl/features/audit/audit.cfg |  6 ++
  cgl/features/audit/audit.scc |  4 
  cgl/features/mip6/mip6.cfg   |  8 
  cgl/features/mip6/mip6.scc   |  5 +
  cgl/features/pstore/pstore.cfg   |  3 +++
  cgl/features/pstore/pstore.scc   |  4 
  cgl/features/qdisc/qdisc_stats.cfg   |  1 +
  cgl/features/qdisc/qdisc_stats.scc   |  1 +
  cgl/features/quota/quota.cfg |  5 +
  cgl/features/quota/quota.scc |  4 
  cgl/features/selinux/selinux-dev.cfg |  3 +++
  cgl/features/selinux/selinux-dev.scc |  3 +++
  cgl/features/selinux/selinux.cfg | 11 +++
  cgl/features/selinux/selinux.scc |  4 
  cgl/features/udp/udp_stats.cfg   |  1 +
  cgl/features/udp/udp_stats.scc   |  1 +
  32 files changed, 195 insertions(+)
  create mode 100644 cgl/cfg/dmm.cfg
  create mode 100644 cgl/cfg/dmm.scc
  create mode 100644 cgl/cfg/drbd.cfg
  create mode 100644 cgl/cfg/drbd.scc
  create mode 100644 cgl/cfg/fs/ocfs2.cfg
  create mode 100644 cgl/cfg/fs/ocfs2.scc
  create mode 100644 cgl/cfg/iscsi.cfg
  create mode 100644 cgl/cfg/iscsi.scc
  create mode 100644 cgl/cfg/net/ip_vs.cfg
  create mode 100644 cgl/cfg/net/ip_vs.scc
  create mode 100644 cgl/cfg/net/l2tp.cfg
  create mode 100644 cgl/cfg/net/l2tp.scc
  create mode 100644 cgl/cfg/net/macvlan.cfg
  create mode 100644 cgl/cfg/net/macvlan.scc
  create mode 100644 cgl/features/aoe/aoe.cfg
  create mode 100644 cgl/features/aoe/aoe.scc
  create mode 100644 cgl/features/audit/audit.cfg
  create mode 100644 cgl/features/audit/audit.scc
  create mode 100644 cgl/features/mip6/mip6.cfg
  create mode 100644 cgl/features/mip6/mip6.scc
  create mode 100644 cgl/features/pstore/pstore.cfg
  create mode 100644 cgl/features/pstore/pstore.scc
  create mode 100644 cgl/features/qdisc/qdisc_stats.cfg
  create mode 100644 cgl/features/qdisc/qdisc_stats.scc
  create mode 100644 cgl/features/quota/quota.cfg
  create mode 100644 cgl/features/quota/quota.scc
  create mode 100644 cgl/features/selinux/selinux-dev.cfg
  create mode 100644 cgl/features/selinux/selinux-dev.scc
  create mode 100644 cgl/features/selinux/selinux.cfg
  create mode 100644 cgl/features/selinux/selinux.scc
  create mode 100644 cgl/features/udp/udp_stats.cfg
  create mode 100644 cgl/features/udp/udp_stats.scc

diff --git a/cgl/cfg/dmm.cfg b/cgl/cfg/dmm.cfg
new file mode 100644
index 000..e8645a2
--- /dev/null
+++ b/cgl/cfg/dmm.cfg
@@ -0,0 +1 @@
+CONFIG_DM_MULTIPATH=y
diff --git a/cgl/cfg/dmm.scc b/cgl/cfg/dmm.scc
new file mode 100644
index 000..49fc19a
--- /dev/null
+++ b/cgl/cfg/dmm.scc
@@ -0,0 +1,4 @@
+define KFEATURE_DESCRIPTION "Device Mapper Multipath Support"
+define KFEATURE_COMPATIBILITY all
+
+kconf non-hardware dmm.cfg
diff --git a/cgl/cfg/drbd.cfg b/cgl/cfg/drbd.cfg
new file mode 100644
index 000..475b821
--- /dev/null
+++ b/cgl/cfg/drbd.cfg
@@ -0,0 +1 @@
+CONFIG_BLK_DEV_DRBD=y
diff --git a/cgl/cfg/drbd.scc b/cgl/cfg/drbd.scc
new file mode 100644
index 000..a6de3b8
--- /dev/null
+++ b/cgl/cfg/drbd.scc
@@ -0,0 +1,4 @@
+define KFEATURE_DESCRIPTION "DRBD Block Device Support"
+define KFEATURE_COMPATIBILITY all
+
+kconf non-hardware drbd.cfg
diff --git a/cgl/cfg/fs/ocfs2.cfg b/cgl/cfg/fs/ocfs2.cfg
new file mode 100644
index 000..8d7caf3
--- /dev/null
+++ b/cgl/cfg/fs/ocfs2.cfg
@@ -0,0 +1,15 @@
+#.
+#WARNING
+#
+# This file is a kernel configuration fragment, and not a full kernel
+# configuration file.  The final kernel configuration is made up of
+# an assembly of processed fragments, each of which is designed to
+# capture a specific part of the

Re: [linux-yocto] [linux-yocto-4.8][PATCH] mm/workingset.c: fix implicit declaration of __list_lru_init_key

2017-09-25 Thread Bruce Ashfield


On 09/22/2017 07:02 PM, akuster808 wrote:

Cal,


On 09/22/2017 03:48 PM, California Sullivan wrote:

__list_lru_init_key does not exist. We're looking for __list_lru_init as
shown in the patch "26690f5 mm: workingset: fix premature shadow node
shrinking with cgroups".

Signed-off-by: California Sullivan 


I believe this fix is already in latest 4.8 preempt-base.

http://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto-4.8/commit/mm/workingset.c?h=standard/preempt-rt/base=26690f5a8bdf03966c5db20181089f86f8ca8eef


It was like that, but a merge from standard/base has munged it into
the incorrect form .. and since it is a merge commit, git whatchanged
hides the fact a bit.

I've applied this and pushed it to the -rt branches.

Bruce



I am working on updating morty to the latest versions.

- armin


---

This is for the standard/preempt-rt/base branch. Standard/base is OK.

  mm/workingset.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/mm/workingset.c b/mm/workingset.c
index 1856fdb..5e953eb 100644
--- a/mm/workingset.c
+++ b/mm/workingset.c
@@ -493,7 +493,7 @@ static int __init workingset_init(void)
pr_info("workingset: timestamp_bits=%d max_order=%d bucket_order=%u\n",
   timestamp_bits, max_order, bucket_order);
  
-	ret = __list_lru_init_key(&__workingset_shadow_nodes, true, _nodes_key);

+   ret = __list_lru_init(&__workingset_shadow_nodes, true, 
_nodes_key);
if (ret)
goto err;
ret = register_shrinker(_shadow_shrinker);





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

Re: [yocto] [OE-core] OpenEmbedded Developer Meeting Oct 22, 2017 in Prague (before ELCE)

2017-09-25 Thread Hudson, Sean

Ruslan,

  There is no charge.  Feel free to join.

--
Sean


> -Original Message-
> From: openembedded-members-boun...@lists.openembedded.org
> [mailto:openembedded-members-boun...@lists.openembedded.org] On
> Behalf Of Ruslan Bilovol
> Sent: Wednesday, September 13, 2017 10:41 AM
> To: Philip Balister 
> Cc: Yocto Project ; openembedded-
> memb...@lists.openembedded.org; openembedded-architecture
> ;
> openembedded-de...@lists.openembedded.org; openembedded-core
> 
> Subject: Re: [OE-core] OpenEmbedded Developer Meeting Oct 22, 2017 in
> Prague (before ELCE)
> 
> On Thu, Aug 24, 2017 at 9:37 PM, Philip Balister  wrote:
> > Once again we will have a developer meeting in Prague the Sunday before
> > ELCE.
> >
> > Please go to https://www.openembedded.org/wiki/OEDEM_2017 and
> add
> > yourself if you are attending and ideas for topics.
> >
> > Although it is called a developer meeting, we invite members of the
> > larger community to attend. The core developers are always interested in
> > hearing how OpenEmbedded is used, and what we can do to make it
> better
> > for building the embedded devices of the future.
> 
> Is it free to attend, anything else required except of
> self-registration on wiki?
> 
> Thanks,
> Ruslan
> --
> ___
> Openembedded-members mailing list
> openembedded-memb...@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-
> members
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-java][PATCH 5/6] bdwgc: import from meta-oe

2017-09-25 Thread Philip Balister

On 09/24/2017 05:05 PM, Maxin B. John wrote:
> keep a copy of bdwgc recipe in meta-java from meta-oe layer.
> cacao in meta-java depends on bdwgc.

Duplicating recipes in recipes is frowned upon.

Shouldn't we have the discussion why you are  not proposing this for
Openembedded-core instead of duplicating the recipe? Duping a recipe
just to drop a layer dependency isn't a long term solution.

Philip

> 
> Signed-off-by: Maxin B. John 
> ---
>  ...ac-add-check-for-NO_GETCONTEXT-definition.patch | 29 +++
>  recipes-extended/bdwgc/bdwgc/musl_header_fix.patch | 27 ++
>  recipes-extended/bdwgc/bdwgc_7.6.0.bb  | 42 
> ++
>  3 files changed, 98 insertions(+)
>  create mode 100644 
> recipes-extended/bdwgc/bdwgc/0001-configure.ac-add-check-for-NO_GETCONTEXT-definition.patch
>  create mode 100644 recipes-extended/bdwgc/bdwgc/musl_header_fix.patch
>  create mode 100644 recipes-extended/bdwgc/bdwgc_7.6.0.bb
> 
> diff --git 
> a/recipes-extended/bdwgc/bdwgc/0001-configure.ac-add-check-for-NO_GETCONTEXT-definition.patch
>  
> b/recipes-extended/bdwgc/bdwgc/0001-configure.ac-add-check-for-NO_GETCONTEXT-definition.patch
> new file mode 100644
> index 000..8ef774f
> --- /dev/null
> +++ 
> b/recipes-extended/bdwgc/bdwgc/0001-configure.ac-add-check-for-NO_GETCONTEXT-definition.patch
> @@ -0,0 +1,29 @@
> +configure.ac: add check for NO_GETCONTEXT definition
> +
> +Signed-off-by: Samuel Martin 
> +[yann.morin.1...@free.fr: add a comment, change variable name, use
> + AS_IF, remove debug traces, use AC_CHECK_FUNCS (as suggested by
> + Thomas)]
> +Signed-off-by: "Yann E. MORIN" 
> +Cc: Thomas Petazzoni 
> +
> +---
> +Upstream-Status: Pending
> + configure.ac | 6 ++
> + 1 file changed, 6 insertions(+)
> +
> +--- bdwgc-7.2f.orig/configure.ac 2014-06-01 19:00:47.0 +0200
>  bdwgc-7.2f/configure.ac  2014-12-23 14:13:11.585716713 +0100
> +@@ -365,6 +365,12 @@
> +   AC_MSG_RESULT($ac_cv_fno_strict_aliasing)
> + fi
> + 
> ++# Check for getcontext (uClibc can be configured without it, for example)
> ++AC_CHECK_FUNCS([getcontext])
> ++AS_IF([test "$ac_cv_func_getcontext" = "no"],
> ++  [CFLAGS="$CFLAGS -DNO_GETCONTEXT"
> ++   CPPFLAGS="$CPPFLAGS -DNO_GETCONTEXT"])
> ++
> + case "$host" in
> + # While IRIX 6 has libdl for the O32 and N32 ABIs, it's missing for N64
> + # and unnecessary everywhere.
> diff --git a/recipes-extended/bdwgc/bdwgc/musl_header_fix.patch 
> b/recipes-extended/bdwgc/bdwgc/musl_header_fix.patch
> new file mode 100644
> index 000..4a18496
> --- /dev/null
> +++ b/recipes-extended/bdwgc/bdwgc/musl_header_fix.patch
> @@ -0,0 +1,27 @@
> +Add missing header to avoid:
> +
> +| 1472659610.016355: ../git/pthread_stop_world.c: In function 
> 'GC_brief_async_signal_safe_sleep':
> +| 1472659610.0540252: ../git/pthread_stop_world.c:397:22: error: storage 
> size of 'tv' isn't known
> +| 1472659610.0540252:struct timeval tv;
> +| 1472659610.0540252:   ^~
> +| 1472659610.054099: ../git/pthread_stop_world.c:397:22: warning: unused 
> variable 'tv' [-Wunused-variable]
> +| 1472659610.054099:struct timeval tv;
> +| 1472659610.054099:   ^~
> +| 1472659610.054099: Makefile:1530: recipe for target 
> 'pthread_stop_world.lo' failed
> +
> +in musl builds.
> +
> +Upstream-Status: Pending
> +
> +Index: git/pthread_stop_world.c
> +===
> +--- git.orig/pthread_stop_world.c
>  git/pthread_stop_world.c
> +@@ -45,6 +45,7 @@
> + #include 
> + #include 
> + #include 
> ++#include 
> + #include "atomic_ops.h"
> + 
> + /* It's safe to call original pthread_sigmask() here.   */
> diff --git a/recipes-extended/bdwgc/bdwgc_7.6.0.bb 
> b/recipes-extended/bdwgc/bdwgc_7.6.0.bb
> new file mode 100644
> index 000..dcb68f0
> --- /dev/null
> +++ b/recipes-extended/bdwgc/bdwgc_7.6.0.bb
> @@ -0,0 +1,42 @@
> +SUMMARY = "A garbage collector for C and C++"
> +
> +DESCRIPTION = "The Boehm-Demers-Weiser conservative garbage collector can be\
> + used as a garbage collecting replacement for C malloc or C++ new. It allows\
> + you to allocate memory basically as you normally would, without explicitly\
> + deallocating memory that is no longer useful. The collector automatically\
> + recycles memory when it determines that it can no longer be otherwise\
> + accessed.\
> +  The collector is also used by a number of programming language\
> + implementations that either use C as intermediate code, want to facilitate\
> + easier interoperation with C libraries, or just prefer the simple collector\
> + interface.\
> +  Alternatively, the garbage collector may be used as a leak detector for C\
> + or C++ programs, though that is not its primary goal.\
> +  Empirically, this collector works with most unmodified C programs, simply\
> + by replacing malloc with

Re: [yocto] RFC: Backwards compatibility checking sstate-cache

2017-09-25 Thread Mike Looijmans


On 23-09-17 00:51, Joshua Lock wrote:

On 22/09/17 15:00, Mike Looijmans wrote:
I think this remark in the referenced link is the best summary of "what 
could be improved":


"""the biggest weakness of the sstate signature bits, in my opinion, is that 
it only tracks inputs, not outputs. If task A depends on B, and the metadata 
input to B changes, then A will be rebuilt, even if the *output* of B didn't 
change as a result of the change to its metadata."""


For example, if someone fixes a bug in gcc that only applies to MIPS, then 
builds that only target an ARM machine shouldn't be affected. Much worse 
than that, I have a dependency like:

gcc -> ... -> python -> bitstream tool -> FPGA image

so this means that a change in gcc causes Python to rebuild, which causes 
the bitstream tool to be rebuilt and produce idential output, and that 
triggers a roughly 31-hour build of lots of FPGA images. These are the ones 
we really want to break. A binary output compare would help a lot, even if 
80% of the libraries fail to create reproducible output, I may still be 
spared those 31 hours...


I think tracking digital output is technically feasible, and won't require 
any change to existing recipes.


Also think about "feed" setups. When I see my settop reporting "331 packages 
need updating"... It'd be great if that could be avoided.




That's what packagefeed-stability.bbclass is for. Work on binary 
reproducibility will improve things here too.


Interesting, thanks for the hint.

That might cut down a bit on the over 4TB/month "update my box" traffic.


Kind regards,

Mike Looijmans
System Expert

TOPIC Products
Materiaalweg 4, NL-5681 RJ Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
E-mail: mike.looijm...@topicproducts.com
Website: www.topicproducts.com

Please consider the environment before printing this e-mail


Visit us at the Space Tech Expo Europe (Stand E-71)
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[linux-yocto] [PATCH 1/2][v2] cgl: Add cgl features

2017-09-25 Thread zhe.he

From: He Zhe 

Add features for Carrier Grade Linux
https://wiki.linuxfoundation.org/cgl/start

Signed-off-by: He Zhe 
---
 cgl/cfg/dmm.cfg  |  1 +
 cgl/cfg/dmm.scc  |  4 
 cgl/cfg/drbd.cfg |  1 +
 cgl/cfg/drbd.scc |  4 
 cgl/cfg/fs/ocfs2.cfg | 15 +++
 cgl/cfg/fs/ocfs2.scc |  4 
 cgl/cfg/iscsi.cfg| 14 ++
 cgl/cfg/iscsi.scc|  6 ++
 cgl/cfg/net/ip_vs.cfg| 36 
 cgl/cfg/net/ip_vs.scc|  4 
 cgl/cfg/net/l2tp.cfg | 15 +++
 cgl/cfg/net/l2tp.scc |  4 
 cgl/cfg/net/macvlan.cfg  | 14 ++
 cgl/cfg/net/macvlan.scc  |  4 
 cgl/features/aoe/aoe.cfg |  1 +
 cgl/features/aoe/aoe.scc |  4 
 cgl/features/audit/audit.cfg |  6 ++
 cgl/features/audit/audit.scc |  4 
 cgl/features/mip6/mip6.cfg   |  8 
 cgl/features/mip6/mip6.scc   |  5 +
 cgl/features/pstore/pstore.cfg   |  3 +++
 cgl/features/pstore/pstore.scc   |  4 
 cgl/features/qdisc/qdisc_stats.cfg   |  1 +
 cgl/features/qdisc/qdisc_stats.scc   |  1 +
 cgl/features/quota/quota.cfg |  5 +
 cgl/features/quota/quota.scc |  4 
 cgl/features/selinux/selinux-dev.cfg |  3 +++
 cgl/features/selinux/selinux-dev.scc |  3 +++
 cgl/features/selinux/selinux.cfg | 11 +++
 cgl/features/selinux/selinux.scc |  4 
 cgl/features/udp/udp_stats.cfg   |  1 +
 cgl/features/udp/udp_stats.scc   |  1 +
 32 files changed, 195 insertions(+)
 create mode 100644 cgl/cfg/dmm.cfg
 create mode 100644 cgl/cfg/dmm.scc
 create mode 100644 cgl/cfg/drbd.cfg
 create mode 100644 cgl/cfg/drbd.scc
 create mode 100644 cgl/cfg/fs/ocfs2.cfg
 create mode 100644 cgl/cfg/fs/ocfs2.scc
 create mode 100644 cgl/cfg/iscsi.cfg
 create mode 100644 cgl/cfg/iscsi.scc
 create mode 100644 cgl/cfg/net/ip_vs.cfg
 create mode 100644 cgl/cfg/net/ip_vs.scc
 create mode 100644 cgl/cfg/net/l2tp.cfg
 create mode 100644 cgl/cfg/net/l2tp.scc
 create mode 100644 cgl/cfg/net/macvlan.cfg
 create mode 100644 cgl/cfg/net/macvlan.scc
 create mode 100644 cgl/features/aoe/aoe.cfg
 create mode 100644 cgl/features/aoe/aoe.scc
 create mode 100644 cgl/features/audit/audit.cfg
 create mode 100644 cgl/features/audit/audit.scc
 create mode 100644 cgl/features/mip6/mip6.cfg
 create mode 100644 cgl/features/mip6/mip6.scc
 create mode 100644 cgl/features/pstore/pstore.cfg
 create mode 100644 cgl/features/pstore/pstore.scc
 create mode 100644 cgl/features/qdisc/qdisc_stats.cfg
 create mode 100644 cgl/features/qdisc/qdisc_stats.scc
 create mode 100644 cgl/features/quota/quota.cfg
 create mode 100644 cgl/features/quota/quota.scc
 create mode 100644 cgl/features/selinux/selinux-dev.cfg
 create mode 100644 cgl/features/selinux/selinux-dev.scc
 create mode 100644 cgl/features/selinux/selinux.cfg
 create mode 100644 cgl/features/selinux/selinux.scc
 create mode 100644 cgl/features/udp/udp_stats.cfg
 create mode 100644 cgl/features/udp/udp_stats.scc

diff --git a/cgl/cfg/dmm.cfg b/cgl/cfg/dmm.cfg
new file mode 100644
index 000..e8645a2
--- /dev/null
+++ b/cgl/cfg/dmm.cfg
@@ -0,0 +1 @@
+CONFIG_DM_MULTIPATH=y
diff --git a/cgl/cfg/dmm.scc b/cgl/cfg/dmm.scc
new file mode 100644
index 000..49fc19a
--- /dev/null
+++ b/cgl/cfg/dmm.scc
@@ -0,0 +1,4 @@
+define KFEATURE_DESCRIPTION "Device Mapper Multipath Support"
+define KFEATURE_COMPATIBILITY all
+
+kconf non-hardware dmm.cfg
diff --git a/cgl/cfg/drbd.cfg b/cgl/cfg/drbd.cfg
new file mode 100644
index 000..475b821
--- /dev/null
+++ b/cgl/cfg/drbd.cfg
@@ -0,0 +1 @@
+CONFIG_BLK_DEV_DRBD=y
diff --git a/cgl/cfg/drbd.scc b/cgl/cfg/drbd.scc
new file mode 100644
index 000..a6de3b8
--- /dev/null
+++ b/cgl/cfg/drbd.scc
@@ -0,0 +1,4 @@
+define KFEATURE_DESCRIPTION "DRBD Block Device Support"
+define KFEATURE_COMPATIBILITY all
+
+kconf non-hardware drbd.cfg
diff --git a/cgl/cfg/fs/ocfs2.cfg b/cgl/cfg/fs/ocfs2.cfg
new file mode 100644
index 000..8d7caf3
--- /dev/null
+++ b/cgl/cfg/fs/ocfs2.cfg
@@ -0,0 +1,15 @@
+#.
+#WARNING
+#
+# This file is a kernel configuration fragment, and not a full kernel
+# configuration file.  The final kernel configuration is made up of
+# an assembly of processed fragments, each of which is designed to
+# capture a specific part of the final configuration (e.g. platform
+# configuration, feature configuration, and board specific hardware
+# configuration).  For more information on kernel configuration, please
+# consult the product documentation.
+#
+#.
+
+CONFIG_OCFS2_FS=m

Re: [yocto] want to execute a script having sudo : sudo cryptsetup

2017-09-25 Thread Kumar, Shrawan

Hello Team ,

I am trying to achieve below from yocto , do we have a way  ?


dd if=/dev/zero of=hello.enc bs=4k count=$400
mknod /dev/loop_dev_0
losetup /dev/loop_dev_0 hello.enc
sudo cryptsetup --type=plain open /dev/loop_dev_0  plainMap < $2




Thanks and Regards
Shrawan

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

[yocto] image

2017-09-25 Thread Stéphane Ancelot


Hi,

I am a newbie , I tried the first steps in the tutorial , created the 
sato image. I know have few questions.



I want to create some images, do I need to clone the working environment 
I used to create sato image, or I can work in the same folder, in which 
I can create many images ?



Imagine I want to go a little bit further with the sato image , eg by 
adding a new app to matchbox panel. It is a bit confusing to myself to 
understand how the sato image is created and its layout. can you detail 
please.



Regards,

Steph

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

[yocto] rootfs encryption support

Re: [yocto] eSDK install script failure

Re: [yocto] eSDK install script failure

Re: [yocto] [layerindex][PATCH] Indicate if layer has YP Compatible certification

Re: [yocto] [layerindex][PATCH] Indicate if layer has YP Compatible certification

[yocto] [infra] git domain name updates

[yocto] [ANNOUNCEMENT] Yocto Project 2.3.2 (pyro 17.0.2) Released

[yocto] [layerindex][PATCH] Don't show "Starting bitbake server" in update log

[yocto] [layerindex][PATCH] Indicate if layer has YP Compatible certification

[yocto] RPI VideoCore IV bare-metal release

Re: [yocto] Unclear sstate-cache dir permissions

[yocto] Release directory layout 2.3.2

Re: [yocto] Unclear sstate-cache dir permissions

[yocto] Unclear sstate-cache dir permissions

[yocto] [ANNOUNCEMENT] Yocto Project 2.2.2 (morty 16.0.2) Released

Re: [yocto] eSDK install script failure

[yocto] Yocto Project Status WW39’17

Re: [linux-yocto] [kernel-cache][PATCH] intel-common-drivers: Add x2apic

Re: [linux-yocto] [PATCH 1/2][v2] cgl: Add cgl features

Re: [linux-yocto] [linux-yocto-4.8][PATCH] mm/workingset.c: fix implicit declaration of __list_lru_init_key

Re: [yocto] [OE-core] OpenEmbedded Developer Meeting Oct 22, 2017 in Prague (before ELCE)

Re: [yocto] [meta-java][PATCH 5/6] bdwgc: import from meta-oe

Re: [yocto] RFC: Backwards compatibility checking sstate-cache

[linux-yocto] [PATCH 1/2][v2] cgl: Add cgl features

Re: [yocto] want to execute a script having sudo : sudo cryptsetup

[yocto] image

26 matches

Site Navigation

Mail list logo

Footer information