Re: [OE-core] [PATCH 1/2] image.bbclass: Correct chaining compression support

2017-09-19 Thread Tom Rini 
On Tue, Sep 19, 2017 at 11:23:33AM +0200, Martin Hundebøll wrote:
> Hi Tom,
> 
> On 2017-07-22 00:06, Tom Rini wrote:
> >diff --git a/meta/classes/image.bbclass b/meta/classes/image.bbclass
> >index de535ce6fcff..bd6a5b7b810a 100644
> >--- a/meta/classes/image.bbclass
> >+++ b/meta/classes/image.bbclass
> >@@ -453,7 +453,7 @@ python () {
> >  rm_tmp_images = set()
> >  def gen_conversion_cmds(bt):
> >  for ctype in ctypes:
> >-if bt[bt.find('.') + 1:] == ctype:
> >+if bt.endswith("." + ctype):
> >  type = bt[0:-len(ctype) - 1]
> >  if type.startswith("debugfs_"):
> >  type = type[8:]
> 
> This is the change that in fact messes with our cpio.gz.u-boot image
> types, causing base hash changes.
> 
> I suspect the changed if-check to be too permissive. In our case, it
> now matches any ctype that ends with ".u-boot", and not just
> "gz.u-boot" as set in IMAGE_FSTYPES.
> 
> Wouldn't it be correct to match on the entire bt variable? I.e.
> 
> diff --git a/meta/classes/image.bbclass b/meta/classes/image.bbclass
> 
> index ef2b38aeaf..818932f7f1 100644
> --- a/meta/classes/image.bbclass
> +++ b/meta/classes/image.bbclass
> @@ -454,7 +454,7 @@ python () {
>  rm_tmp_images = set()
>  def gen_conversion_cmds(bt):
>  for ctype in ctypes:
> -if bt.endswith("." + ctype):
> +if bt.split('.', 1) == [t, ctype]:
>  type = bt[0:-len(ctype) - 1]
>  if type.startswith("debugfs_"):
>  type = type[8:]
> 
> This works for me, preliminary tested with the following fs types
> configured:
> 
>   IMAGE_FSTYPES = "cpio.gz.u-boot"
>   IMAGE_FSTYPES = "tar cpio cpio.gz cpio.gz.u-boot"
>   IMAGE_FSTYPES = "tar cpio cpio.gz cpio.gz.u-boot tar.bz2 jffs2 wic
> wic.bmap"

Good catch.  Does it also work with say cpio.u-boot.gz ?  And does
oe-selftest still pass for the image related parts?  I think those are
spelled out in the thread too (I've forgotten the incantation myself
now, sorry).

-- 
Tom


signature.asc
Description: Digital signature
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] State of bitbake world, Failed tasks 2017-09-14

2017-09-19 Thread Martin Jansa 
Done
https://github.com/shr-project/jenkins-jobs/commit/dbb5e4e4e2c5821381eda729ab746a21238c8801

On Sat, Sep 16, 2017 at 5:01 PM, Khem Raj  wrote:

> On Sat, Sep 16, 2017 at 7:41 AM, Martin Jansa 
> wrote:
> > Just the commit IDs from the top won't be very useful, because it's from
> > jansa/master branches which are rebased even more often than master-next.
> >
> > If you really want to see them, then there are links to the build logs
> for
> > each MACHINE and you can see the build configuration there.
> >
> > That's why at the bottom is the list of last master commit (as seen in
> > qemuarm build directory) and list of patches currently applied on top of
> it.
> > But to make it accurate for all MACHINEs I would either need to update
> the
> > branches only once in 2-3 days when the builds are all finished or to
> repeat
> > this section 3 times (which is sometimes quite long even when listed just
> > for qemuarm).
> >
> > What I'll do is to include similar git log at the beginning of each
> build,
> > so if in doubt opening the individual logs will not only show the
> > configuration as seen by bitbake, but also the master branch and applied
> > patches.
> >
>
> I think that will be useful.
>
> >
> > On Sat, Sep 16, 2017 at 4:32 PM, Khem Raj  wrote:
> >>
> >> On Sat, Sep 16, 2017 at 2:00 AM, Martin Jansa 
> >> wrote:
> >> > Probably is, qemux86 was built from slightly older metadata, so
> probably
> >> > including previous versions of your klibc changes.
> >> >
> >> > I know it's confusing in the report, but still each build takes around
> >> > 24
> >> > hours per machine and I have only 2 builders. e.g. this qemux86 build
> >> > was
> >> > started 20170912_234104 as the log directory shows and at that time
> >> > there
> >> > wasn't even the latest version of klibc patches on ML.
> >> >
> >>
> >> thats ok. May be top of build configuration would be a good thing to
> >> have in report. so we know which commit the results belong to.
> >>
> >> > Thanks
> >> >
> >> > On Sat, Sep 16, 2017 at 1:02 AM, Khem Raj  wrote:
> >> >>
> >> >> On Fri, Sep 15, 2017 at 3:08 PM, Martin Jansa <
> martin.ja...@gmail.com>
> >> >> wrote:
> >> >> > http://www.openembedded.org/wiki/Bitbake_World_Status
> >> >> >
> >> >> > == Number of issues - stats ==
> >> >> > {| class='wikitable'
> >> >> > !|Date  !!colspan='3'|Failed tasks !!|Signatures
> >> >> > !!colspan='14'|QA
> >> >> > !!Comment
> >> >> > |-
> >> >> > || ||qemuarm ||qemux86 ||qemux86_64 ||all ||already-stripped
> ||libdir
> >> >> > ||textrel ||build-deps ||file-rdeps ||version-going-backwards
> >> >> > ||host-user-contaminated ||installed-vs-shipped
> >> >> > ||unknown-configure-option
> >> >> > ||symlink-to-sysroot ||invalid-pkgconfig ||pkgname ||ldflags
> >> >> > ||compile-host-path ||
> >> >> > |-
> >> >> > ||2017-09-14 ||3 ||6 ||2 ||0 ||0 ||0 ||5 ||0 ||0 ||91 ||3 ||0 ||0
> ||0
> >> >> > ||0
> >> >> > ||0 ||0 ||0 ||
> >> >> > |}
> >> >> >
> >> >> > == Failed tasks 2017-09-14 ==
> >> >> >
> >> >> > INFO: jenkins-job.sh-1.8.29 Complete log available at
> >> >> >
> >> >> >
> >> >> > http://logs.nslu2-linux.org/buildlogs/oe/world/rocko/log.
> report.20170915_120505.log
> >> >> >
> >> >> > === common (1) ===
> >> >> > *
> >> >> > meta-browser/recipes-mozilla/firefox/firefox_45.9.0esr.bb:d
> o_compile
> >> >> >
> >> >> > === common-x86 (0) ===
> >> >> >
> >> >> > === qemuarm (2) ===
> >> >> > *
> >> >> >
> >> >> >
> >> >> > meta-openembedded/meta-multimedia/recipes-
> connectivity/libupnp/libupnp1.6_1.6.21.bb:do_fetch
> >> >> > *
> >> >> >
> >> >> >
> >> >> > meta-openembedded/meta-oe/recipes-devtools/android-
> tools/android-tools_5.1.1.r37.bb:do_compile
> >> >> >
> >> >> > === qemux86 (5) ===
> >> >> > *
> >> >> >
> >> >> >
> >> >> > meta-openembedded/meta-initramfs/recipes-devtools/
> mtd/ubi-utils-klibc_1.5.1.bb:do_compile
> >> >> > *
> >> >> >
> >> >> >
> >> >> > meta-openembedded/meta-initramfs/recipes-kernel/
> kexec/kexec-tools-klibc_2.0.2.bb:do_configure
> >> >> > *
> >> >> >
> >> >> >
> >> >> > meta-openembedded/meta-multimedia/recipes-multimedia/
> gerbera/gerbera_git.bb:do_configure
> >> >> > * meta-qt5/recipes-qt/qt5/qtlocation_git.bb:do_compile
> >> >> > *
> >> >> >
> >> >> >
> >> >> > virtual:klibc:meta-openembedded/meta-initramfs/
> recipes-bsp/kexecboot/kexecboot_git.bb:do_configure
> >> >> >
> >> >>
> >> >> all meta-initramfs should have been fixed with latest patchset it
> that
> >> >> not
> >> >> the case ?
> >> >>
> >> >> > === qemux86_64 (1) ===
> >> >> > *
> >> >> >
> >> >> >
> >> >> > virtual:native:meta-openembedded/meta-oe/recipes-
> support/uim/uim_1.8.6.bb:do_install
> >> >> >
> >> >> > === Number of failed tasks (11) ===
> >> >> > {| class=wikitable
> >> >> > |-
> >> >> > || qemuarm || 3 ||
> >> >> >
> >> >> >
> >> >> > http://logs.nslu2-linux.org/buildlogs/oe/world/rocko/log.
>

[OE-core] [PATCH 1/3] arch-x86: Add x86-x32 to MACHINEOVERRIDES

2017-09-19 Thread Saul Wold 
This is needed as an x32 more generic x32 override later in the
OVERRIDES, currently linux-gnux32 is the first override, but we
need a stronger (later in the list) x32 override to deal with some
needed x32 dependency overrides.

Signed-off-by: Saul Wold 
---
 meta/conf/machine/include/x86/arch-x86.inc | 1 +
 1 file changed, 1 insertion(+)

diff --git a/meta/conf/machine/include/x86/arch-x86.inc 
b/meta/conf/machine/include/x86/arch-x86.inc
index e51d595f74..31d30b3304 100644
--- a/meta/conf/machine/include/x86/arch-x86.inc
+++ b/meta/conf/machine/include/x86/arch-x86.inc
@@ -26,6 +26,7 @@ TUNE_LDARGS += "${@bb.utils.contains('TUNE_FEATURES', 'mx32', 
'-m elf32_x86_64',
 TUNE_ASARGS += "${@bb.utils.contains('TUNE_FEATURES', 'mx32', '-x32', '', d)}"
 # user mode qemu doesn't support x32
 MACHINE_FEATURES_BACKFILL_CONSIDERED_append = " 
${@bb.utils.contains('TUNE_FEATURES', 'mx32', 'qemu-usermode', '', d)}"
+MACHINEOVERRIDES =. "${@bb.utils.contains('TUNE_FEATURES', 'mx32', 'x86_x32:', 
'' ,d)}"
 
 # ELF64 ABI
 TUNEVALID[m64] = "IA32e (x86_64) ELF64 standard ABI"
-- 
2.11.0

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH 3/3] systemd-boot: Should not build x32

2017-09-19 Thread Saul Wold 
Since systemd-boot is a bootloader, it needs to be built for
the native IA instruction set size and x32 is not valid.

Signed-off-by: Saul Wold 
---
 meta/recipes-core/systemd/systemd-boot_234.bb | 1 +
 1 file changed, 1 insertion(+)

diff --git a/meta/recipes-core/systemd/systemd-boot_234.bb 
b/meta/recipes-core/systemd/systemd-boot_234.bb
index 655797f3cc..7b18b25e35 100644
--- a/meta/recipes-core/systemd/systemd-boot_234.bb
+++ b/meta/recipes-core/systemd/systemd-boot_234.bb
@@ -21,6 +21,7 @@ EXTRA_OECONF = " --enable-gnuefi \
 # Imported from the old gummiboot recipe
 TUNE_CCARGS_remove = "-mfpmath=sse"
 COMPATIBLE_HOST = "(x86_64.*|i.86.*)-linux"
+COMPATIBLE_HOST_linux-gnux32 = "null"
 
 do_compile() {
SYSTEMD_BOOT_EFI_ARCH="ia32"
-- 
2.11.0

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH 0/3] Disable systemd-boot from building with x32 IA Machine

2017-09-19 Thread Saul Wold 
systemd-boot has to be build for the native IA instruction set size, this
patch series is needed to disable it from building or being depended on 
by WIC when building x32 as DEFAULTTUNE and not just as multilib.

Sau!

Saul Wold (3):
  arch-x86: Add x86-x32 to MACHINEOVERRIDES
  wic: remove systemd-boot for x32
  systemd-boot: Should not build x32

 meta/classes/image_types_wic.bbclass  | 1 +
 meta/conf/machine/include/x86/arch-x86.inc| 1 +
 meta/recipes-core/meta/wic-tools.bb   | 1 +
 meta/recipes-core/systemd/systemd-boot_234.bb | 1 +
 4 files changed, 4 insertions(+)

-- 
2.11.0

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH 2/3] wic: remove systemd-boot for x32

2017-09-19 Thread Saul Wold 
Currently systemd-boot actually incorporates libgcc, since the
systemd-boot needs to be built with 64bit instructions it can not
use the x32 based libgcc.

Use the new override to ensure it gets overriden, linux-gnux32 could
not be used because x86-64 has higher priority.

Signed-off-by: Saul Wold 
---
 meta/classes/image_types_wic.bbclass | 1 +
 meta/recipes-core/meta/wic-tools.bb  | 1 +
 2 files changed, 2 insertions(+)

diff --git a/meta/classes/image_types_wic.bbclass 
b/meta/classes/image_types_wic.bbclass
index b825b47ce5..b9503c69c5 100644
--- a/meta/classes/image_types_wic.bbclass
+++ b/meta/classes/image_types_wic.bbclass
@@ -45,6 +45,7 @@ WKS_FILE_DEPENDS_DEFAULT = "syslinux-native bmap-tools-native 
cdrtools-native bt
 WKS_FILE_DEPENDS_BOOTLOADERS = ""
 WKS_FILE_DEPENDS_BOOTLOADERS_x86 = "syslinux grub-efi systemd-boot"
 WKS_FILE_DEPENDS_BOOTLOADERS_x86-64 = "syslinux grub-efi systemd-boot"
+WKS_FILE_DEPENDS_BOOTLOADERS_x86_x32 = "syslinux grub-efi"
 
 WKS_FILE_DEPENDS ??= "${WKS_FILE_DEPENDS_DEFAULT} 
${WKS_FILE_DEPENDS_BOOTLOADERS}"
 
diff --git a/meta/recipes-core/meta/wic-tools.bb 
b/meta/recipes-core/meta/wic-tools.bb
index 57dd37a440..09eb409e87 100644
--- a/meta/recipes-core/meta/wic-tools.bb
+++ b/meta/recipes-core/meta/wic-tools.bb
@@ -10,6 +10,7 @@ DEPENDS = "\
"
 DEPENDS_append_x86 = " syslinux grub-efi systemd-boot"
 DEPENDS_append_x86-64 = " syslinux grub-efi systemd-boot"
+DEPENDS_append_x86-x32 = " syslinux grub-efi"
 
 INHIBIT_DEFAULT_DEPS = "1"
 
-- 
2.11.0

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] pseudo: use epoll API on Linux

2017-09-19 Thread Trevor Woerner 
On Tue, Sep 19, 2017 at 7:20 AM, Alexander Kanavin
 wrote:
> and with
> Jussi Kukkonen no longer involved in the project

This is sad news :-(
So long Jussi, and thanks for all the recipes
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] image.bbclass: Sorted ctypes to avoid basehash error

2017-09-19 Thread Gerson Fernando Budke 
When selected multiple subimages a similar error could happend:
  Variable do_image_cpio[subimages] value changed \
from 'cpio.gz.u-boot cpio.gz' to 'cpio.gz cpio.gz.u-boot'
To avoid this, 'ctypes' should be sorted at 'gen_conversion_cmds'.

This garantee that 'CONVERSION_CMD_xxx' are always written in tha same
order and consequently 'do_image_cpio' have the same hash.

Signed-off-by: Gerson Fernando Budke 
---
 meta/classes/image.bbclass | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/classes/image.bbclass b/meta/classes/image.bbclass
index 3639aa4..bef634b 100644
--- a/meta/classes/image.bbclass
+++ b/meta/classes/image.bbclass
@@ -452,7 +452,7 @@ python () {
 
 rm_tmp_images = set()
 def gen_conversion_cmds(bt):
-for ctype in ctypes:
+for ctype in sorted(ctypes):
 if bt.endswith("." + ctype):
 type = bt[0:-len(ctype) - 1]
 if type.startswith("debugfs_"):
-- 
2.7.4

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [oe] Use of github /archive/ tarballs in SRC_URI

2017-09-19 Thread Randy MacLeod 

Add oe-core, oe-devel back after checking privately with Ross.

On 2017-09-19 12:38 PM, Burton, Ross wrote:
On 19 September 2017 at 17:29, Randy MacLeod 
> wrote:


On 2017-09-19 04:09 AM, Burton, Ross wrote:

Then the tarball for one of Erlang's repositories changed, and
was noticed
by the checksum in the recipe (thanks Gunnar Andersson for reporting
this).  The extracted contents are identical, but the tarball
itself has
changed.  I'm presuming this is due to the old tarball expiring
in their
cache, and a newly generated tarball using a later version of tar.

So we now have documented evidence that this can and does
happen, and it's
quite frustrating when this happens.  So, I suggest that use of
github.com 
/archive/  URLs be considered a bad practise for the primary
SRC_URI tarball.


Agreed but it's a shame to have to deal with this as users rather
than have github fix the problem.

Could report a bug if it's not already known?
https://github.com/contact


They know, and don't commit to the /archive/ tarballs being persistent.  
They're for convenience and if the project owner wants a stable tarball 
they should upload one (that's almost quoted verbatim from my mails with 
github).


Last time I looked they were generated on demand using git-archive and 
cached for "some time" on AWS.  If nobody access the tarball for a while 
it will fall off AWS and then be re-generated.  The output from 
git-archive will be identical but eg a new tar may write a different 
byte stream for the same input.


Ugh, but I guess it makes sense from their point of view since
they're all about the git repos.

Thanks for the background info Ross,

--
# Randy MacLeod.  WR Linux
# Wind River an Intel Company
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCHv2] pseudo: use epoll API on Linux

2017-09-19 Thread Trevor Woerner 
On Tue, Sep 19, 2017 at 12:12 AM, Seebs  wrote:
> On Mon, 18 Sep 2017 19:41:03 -0400
> Trevor Woerner  wrote:
>
>> Would you be open to a co-maintainership? Maybe a co-maintainer who
>> doesn't push to master directly?
>
> Maybe? I don't know, I'd need to think about that a bit. I recognize
> that there's a need to get some of this stuff fixed, but I think the
> amount of busy I've been recently is probably transient and not likely
> to happen very often.

Okay, sounds good. I'm glad to hear it's just a transient thing. I was
under a mistaken impression.
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] linux-firmware: package qat-firmware

2017-09-19 Thread Burton, Ross 
On 5 September 2017 at 10:27, Liwei Song  wrote:

> + ${PN}-qat-license ${PN}-qat_895xcc ${PN}-qat_895xcc_mmp
> ${PN}-qat_c3xxx ${PN}-qat_c3xxx_mmp ${PN}-qat_c62x ${PN}-qat_c62x_mmp
> ${PN}-qat_mmp \
>

*** Error: Package name  contains illegal characters, (other than
[a-z0-9.+-])

You can't use _ in packages, please just use -.

Ross
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] classes/image: fix do_image_qa dependencies

2017-09-19 Thread Burton, Ross 
On 19 September 2017 at 17:07, Burton, Ross  wrote:

> On 19 September 2017 at 11:36, Tomasz Meresiński <
> tomasz.meresin...@comarch.pl> wrote:
>
>> After do_image_complete IMAGE_ROOTFS directory is empty so qa checks do
>> not work
>
>
> Important context: this only happens if rm_work is enabled.  I'm wondering
> if the task should be moved earlier so its between rootfs and image, as
> it's actually a *rootfs* QA hook (its expected that functions examine the
> contents of IMAGE_ROOTFS).
>
> I think we need to push the task back a bit in the tree and put it in
> between rootfs and image.  This way if it fails the image generation
> doesn't happen, and rm_work won't break it.
>

I've just sent an alternative patch the list, can you verify that it solves
your problem and doesn't break your existing image QA functions?

Cheers,
Ross
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] classes/image: move image_qa to between rootfs and image

2017-09-19 Thread Ross Burton 
It was noticed that do_image_qa is useless when rm_work is enabled as the rootfs
directory is deleted before image_qa is called.

This indicates that image_qa is incorrectly scheduled as it failing should mean
images don't get generated, so move it between do_rootfs and do_image.

Also, add a little bit more documentation to the comments.

Signed-off-by: Ross Burton 
---
 meta/classes/image.bbclass | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/meta/classes/image.bbclass b/meta/classes/image.bbclass
index 3639aa44f4e..4850eed7717 100644
--- a/meta/classes/image.bbclass
+++ b/meta/classes/image.bbclass
@@ -297,8 +297,11 @@ addtask do_image_complete_setscene
 # IMAGE_QA_COMMANDS += " \
 # image_check_everything_ok \
 # "
-# This task runs all functions in IMAGE_QA_COMMANDS after the image
+# This task runs all functions in IMAGE_QA_COMMANDS after the rootfs
 # construction has completed in order to validate the resulting image.
+#
+# The functions should use ${IMAGE_ROOTFS} to find the unpacked rootfs
+# directory, which if QA passes will be the basis for the images.
 fakeroot python do_image_qa () {
 from oe.utils import ImageQAFailed
 
@@ -320,7 +323,7 @@ fakeroot python do_image_qa () {
 imgname = d.getVar('IMAGE_NAME')
 bb.fatal("QA errors found whilst validating image: %s\n%s" % (imgname, 
qamsg))
 }
-addtask do_image_qa after do_image_complete before do_build
+addtask do_image_qa after do_rootfs before do_image
 
 SSTATETASKS += "do_image_qa"
 SSTATE_SKIP_CREATION_task-image-qa = '1'
-- 
2.11.0

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] classes/image: fix do_image_qa dependencies

2017-09-19 Thread Burton, Ross 
On 19 September 2017 at 11:36, Tomasz Meresiński <
tomasz.meresin...@comarch.pl> wrote:

> After do_image_complete IMAGE_ROOTFS directory is empty so qa checks do
> not work


Important context: this only happens if rm_work is enabled.  I'm wondering
if the task should be moved earlier so its between rootfs and image, as
it's actually a *rootfs* QA hook (its expected that functions examine the
contents of IMAGE_ROOTFS).

I think we need to push the task back a bit in the tree and put it in
between rootfs and image.  This way if it fails the image generation
doesn't happen, and rm_work won't break it.

Ross
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [oe] Use of github /archive/ tarballs in SRC_URI

2017-09-19 Thread Burton, Ross 
On 19 September 2017 at 15:34, Carlos Alberto Lopez Perez  wrote:

> On 19/09/17 10:09, Burton, Ross wrote:
> > Then the tarball for one of Erlang's repositories changed, and was
> noticed
> > by the checksum in the recipe (thanks Gunnar Andersson for reporting
> > this).  The extracted contents are identical, but the tarball itself has
> > changed.  I'm presuming this is due to the old tarball expiring in their
> > cache, and a newly generated tarball using a later version of tar.
>
> I don't think tar is the one to blame, but gzip.
> I have just tested GNU tar (versions 1.29 and 1.26) and BSD tar (from
> OpenBSD 5.8) and the 3 have produced identical archives (same md5sum)
> when invoked like git archive does.
>
> However, the .tar.gz file generated was different in the case of BSD.
> It even had a different file size.
>
> I bet that if you uncompress both files, the .tar will have the same
> checksum in both cases.
>

In the situation that I was talking to Gunnar with, the source is the tar
itself.

https://paste.fedoraproject.org/paste/rP67aSPn1IuYbQcz2UNY3g

They have identical length
> $ wc -c new-OTP-18.2.3.tar
> 159068160 new-OTP-18.2.3.tar
> 159068160 orig-OTP-18.2.3.tar
> ...but different content
> $ cmp new-OTP-18.2.3.tar orig-OTP-18.2.3.tar
> $ new-OTP-18.2.3.tar orig-OTP-18.2.3.tar differ: byte 79122433, line
> 2004431
>

Basically, both tar and gzip can cause problems.

Ross
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [RFC][PATCHv2] insane.bbclass: Add do_qa_pseudo function to check for common errors listed in pseudo.log

2017-09-19 Thread Martin Jansa 
* we often see QA warnings like:
  glibc-locale-2.26: glibc-locale: 
/glibc-binary-localedata-en-gb/usr/lib/locale/en_GB/LC_MEASUREMENT is owned by 
uid 3004, which is the same as the user running bitbake. This may be due to 
host contamination [host-user-contaminated]
  glibc-locale-2.26: glibc-locale: 
/glibc-binary-localedata-nn-no.iso-8859-1/usr/lib/locale/nn_NO.ISO-8859-1/LC_MEASUREMENT
 is owned by uid 3004, which is the same as the user running bitbake. This may 
be due to host contamination [host-user-contaminated]
  but we don't know the root cause of it.
* don't trigger error from '^inode mismatch'
* show parts of pseudo.log in console
  many builds are executed in tmpfs, so I cannot check the pseudo.log later
* lower from error to warn as I hate all my builds reporting failure
  just because of this pseudo debug
* the only theory we currently have is that it's a bug in pseudo when
  inode is being reused for different files, which is supported by
  pseudo.log entries:

  Good build:
  pseudo$ grep -v "^path mismatch" pseudo.log
  debug_logfile: fd 2
  pid 7975 [parent 7974], doing new pid setup and server start
  Setup complete, sending SIGUSR1 to pid 7974.
  db cleanup for server shutdown, 17:33:58.787
  memory-to-file backup complete, 17:33:58.787.
  db cleanup finished, 17:33:58.787

  Build with QA host-user-contaminated issue:
  ERROR: foo-1.0.0-r0 do_package_qa: QA Issue: foo: file-with-wrong-UID is owned
  by uid 2001, which is the same as the user running bitbake. This may be due to
  host contamination [host-user-contaminated]

  pseudo$ grep "file-with-wrong-UID" pseudo.log
  inode mismatch: 'file-with-wrong-UID' ino 13242270 in db, 13242271 in request.
  creat ignored for existing file 'file-with-wrong-UID'.
  inode mismatch: 'file-with-wrong-UID' ino 13242270 in db, 13242271 in request.
  inode mismatch: 'file-with-wrong-UID' ino 13242270 in db, 13242271 in request.
  inode mismatch: 'file-with-wrong-UID' ino 13242270 in db, 13242271 in request.
  inode mismatch: 'file-with-wrong-UID' ino 13242270 in db, 13242271 in request.
  inode mismatch: 'file-with-wrong-UID' ino 13242270 in db, 13242271 in request.
  inode mismatch: 'file-with-wrong-UID' ino 13242270 in db, 13242271 in request.
  path mismatch [1 link]: ino 13242270 db 'file-with-wrong-UID' req 
'some-other-unrelated-file'.
  creat for 'some-other-unrelated-file' replaces existing 13242270 
['file-with-wrong-UID'].
  db cleanup for server shutdown, 02:16:23.685
  memory-to-file backup complete, 02:16:23.685.
  db cleanup finished, 02:16:23.685

  And some-other-unrelated-file is really some different file, not just hardlink
  to the same file from some different directory (like between WORKDIR and 
sysroot
  other "path mismatch" entries show).

Signed-off-by: Martin Jansa 
---
 meta/classes/insane.bbclass | 43 +++
 1 file changed, 43 insertions(+)

diff --git a/meta/classes/insane.bbclass b/meta/classes/insane.bbclass
index 0a3b528ddb..76cd92709b 100644
--- a/meta/classes/insane.bbclass
+++ b/meta/classes/insane.bbclass
@@ -1238,6 +1238,44 @@ python do_qa_unpack() {
 bb.warn('%s: the directory %s (%s) pointed to by the S variable 
doesn\'t exist - please set S within the recipe to point to where the source 
has been unpacked to' % (d.getVar('PN'), d.getVar('S', False), s_dir))
 }
 
+python do_qa_pseudo() {
+###
+# Check pseudo.log for unexpected errors
+#
+# Typical pseudo.log contains many "^path mismatch" lines for all the 
hardlinked files
+# e.g. in some smaller component I see 231/237 lines to be "^path 
mismatch" other 6
+# lines are setup and cleanup lines like this:
+# debug_logfile: fd 2
+# pid 7975 [parent 7974], doing new pid setup and server start
+# Setup complete, sending SIGUSR1 to pid 7974.
+# db cleanup for server shutdown, 17:33:58.787
+# memory-to-file backup complete, 17:33:58.787.
+# db cleanup finished, 17:33:58.787
+#
+# but if there is one of:
+# "^inode mismatch"
+# "^creat ignored for existing file"
+# "^creat for.*replaces existing"
+# then there might be some bigger issue which sometimes results in 
host-user-contaminated QA warnings
+###
+
+import subprocess
+
+pseudodir = d.getVar('PSEUDO_LOCALSTATEDIR')
+bb.note("Checking pseudo.log for common errors")
+pseudolog = os.path.join(pseudodir, "pseudo.log")
+statement = "grep" \
+" -e '^creat ignored for existing file'" \
+" -e '^creat for.*replaces existing'" \
+" %s" % pseudolog
+if subprocess.call("%s -q" % statement, shell=True) == 0:
+statement2 = "grep -v '^path mismatch' %s" % pseudolog
+statement2_count = "grep -v '^path mismatch' -c %s" % pseudolog
+output =

Re: [OE-core] [oe] Use of github /archive/ tarballs in SRC_URI

2017-09-19 Thread Carlos Alberto Lopez Perez 
On 19/09/17 10:09, Burton, Ross wrote:
> Then the tarball for one of Erlang's repositories changed, and was noticed
> by the checksum in the recipe (thanks Gunnar Andersson for reporting
> this).  The extracted contents are identical, but the tarball itself has
> changed.  I'm presuming this is due to the old tarball expiring in their
> cache, and a newly generated tarball using a later version of tar.

I don't think tar is the one to blame, but gzip.
I have just tested GNU tar (versions 1.29 and 1.26) and BSD tar (from
OpenBSD 5.8) and the 3 have produced identical archives (same md5sum)
when invoked like git archive does.

However, the .tar.gz file generated was different in the case of BSD.
It even had a different file size.

I bet that if you uncompress both files, the .tar will have the same
checksum in both cases.

I guess that a different version (or implementation) of gzip, or even
different local settings like forcing a more or less aggressive
compression can be the explanation here.

Maybe an idea is that OE could gain a feature to optionally do a
checksum of the .tar file once uncompressed that could be used as a
fallback second check if the first one fails?
If the first one fails but the second one passes a non-fatal WARN could
be issued.



signature.asc
Description: OpenPGP digital signature
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH v3] u-boot-fw-utils: Fix cross and target builds

2017-09-19 Thread Tom Rini 
On Tue, Sep 19, 2017 at 10:19:41AM -0300, Otavio Salvador wrote:

>  - The environment tools target has change to envtools;
>  - The HOSTCC variable must be used to set CC for cross;
>  - Drop ARCH variable as it is set on config;
> 
> Signed-off-by: Otavio Salvador 

Reviewed-by: Tom Rini 

-- 
Tom


signature.asc
Description: Digital signature
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] u-boot-fw-utils: Fix cross and target builds

2017-09-19 Thread Otavio Salvador 
On Tue, Sep 19, 2017 at 9:39 AM, Tom Rini  wrote:
> On Tue, Sep 19, 2017 at 08:53:38AM -0300, Otavio Salvador wrote:
>> Em 19 de set de 2017 8:26 AM, "Tom Rini"  escreveu:
>>
>> On Tue, Sep 19, 2017 at 02:40:58AM -0300, Otavio Salvador wrote:
>> >  - The environment tools target has change to envtools;
>> >  - The HOSTCC variable must be used to set CC for cross;
>> >  - The ARCH variable must be set for cross;
>> >
>> > Signed-off-by: Otavio Salvador 
>> > ---
>> >
>> >  meta/recipes-bsp/u-boot/u-boot-fw-utils_2017.09.bb | 6 +++---
>> >  1 file changed, 3 insertions(+), 3 deletions(-)
>> >
>> > diff --git a/meta/recipes-bsp/u-boot/u-boot-fw-utils_2017.09.bb
>> b/meta/recipes-bsp/u-boot/u-boot-fw-utils_2017.09.bb
>> > index c2e8f0fb84..21ab5b3e6d 100644
>> > --- a/meta/recipes-bsp/u-boot/u-boot-fw-utils_2017.09.bb
>> > +++ b/meta/recipes-bsp/u-boot/u-boot-fw-utils_2017.09.bb
>> > @@ -5,13 +5,13 @@ DEPENDS = "mtd-utils"
>> >
>> >  INSANE_SKIP_${PN} = "already-stripped"
>> >  EXTRA_OEMAKE_class-target = 'CROSS_COMPILE=${TARGET_PREFIX} CC="${CC}
>> ${CFLAGS} ${LDFLAGS}" HOSTCC="${BUILD_CC} ${BUILD_CFLAGS} ${BUILD_LDFLAGS}"
>> V=1'
>> > -EXTRA_OEMAKE_class-cross = 'ARCH=${TARGET_ARCH} CC="${CC} ${CFLAGS}
>> ${LDFLAGS}" V=1'
>> > +EXTRA_OEMAKE_class-cross = 'ARCH=${ARCH} HOSTCC="${CC} ${CFLAGS}
>> ${LDFLAGS}" V=0'
>>
>> Since we're messing with this, U-Boot's build system doesn't take ARCH.
>> It's one of the variables that you pick in Kconfig, not set so that
>> arch/$(ARCH)/Kconfig is sourced.  We should drop that.
>>
>>
>> You can't. Try dropping it...
>
> I've never ever built U-Boot with ARCH=, so, what's going on in OE land?

Drop works; it was set wrong. v3 is on the way !!! Thanks to spot it ...


-- 
Otavio Salvador O.S. Systems
http://www.ossystems.com.brhttp://code.ossystems.com.br
Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] bluez5: Upgrade 5.46 -> 5.47

2017-09-19 Thread Burton, Ross 
It's too late for this in master, but I've queued it in my branch for when
master reopens.

Ross

On 19 September 2017 at 14:16, Marc Ferland  wrote:

> This release includes:
>
> - SDP fix for CVE-2017-1000250.
> - New bluetooth mesh profile.
> - Various fixes to GATT, A2DP and BR/EDR vs LE bearer handling.
>
> This commit also drops the following two patches which are included in
> 5.47:
>
> - 0001-hciattach-bcm43xx-fix-the-delay-timer-for-firmware-d.patch
> - cve-2017-1000250.patch
>
> Signed-off-by: Marc Ferland 
> ---
>  meta/recipes-connectivity/bluez5/bluez5.inc|  3 +-
>  ...cm43xx-fix-the-delay-timer-for-firmware-d.patch | 36
> --
>  .../bluez5/bluez5/cve-2017-1000250.patch   | 34
> 
>  .../bluez5/{bluez5_5.46.bb => bluez5_5.47.bb}  |  4 +--
>  4 files changed, 3 insertions(+), 74 deletions(-)
>  delete mode 100644 meta/recipes-connectivity/
> bluez5/bluez5/0001-hciattach-bcm43xx-fix-the-delay-timer-
> for-firmware-d.patch
>  delete mode 100644 meta/recipes-connectivity/bluez5/bluez5/cve-2017-
> 1000250.patch
>  rename meta/recipes-connectivity/bluez5/{bluez5_5.46.bb => bluez5_5.47.bb}
> (91%)
>
> diff --git a/meta/recipes-connectivity/bluez5/bluez5.inc
> b/meta/recipes-connectivity/bluez5/bluez5.inc
> index 2ae4553d48..3a8d3476ea 100644
> --- a/meta/recipes-connectivity/bluez5/bluez5.inc
> +++ b/meta/recipes-connectivity/bluez5/bluez5.inc
> @@ -41,6 +41,7 @@ PACKAGECONFIG[sixaxis] = "--enable-sixaxis,--disable-
> sixaxis"
>  PACKAGECONFIG[tools] = "--enable-tools,--disable-tools"
>  PACKAGECONFIG[threads] = "--enable-threads,--disable-threads"
>  PACKAGECONFIG[deprecated] = "--enable-deprecated,--disable-deprecated"
> +PACKAGECONFIG[mesh] = "--enable-mesh,--disable-mesh, json-c"
>
>  SRC_URI = "\
>  ${KERNELORG_MIRROR}/linux/bluetooth/bluez-${PV}.tar.xz \
> @@ -49,8 +50,6 @@ SRC_URI = "\
>  file://run-ptest \
>  ${@bb.utils.contains('DISTRO_FEATURES', 'systemd', '',
> 'file://0001-Allow-using-obexd-without-systemd-in-the-user-sessio.patch',
> d)} \
>  file://0001-tests-add-a-target-for-building-tests-without-runnin.patch
> \
> -file://0001-hciattach-bcm43xx-fix-the-delay-timer-for-firmware-d.patch
> \
> -file://cve-2017-1000250.patch \
>  "
>  S = "${WORKDIR}/bluez-${PV}"
>
> diff --git a/meta/recipes-connectivity/bluez5/bluez5/0001-hciattach-
> bcm43xx-fix-the-delay-timer-for-firmware-d.patch
> b/meta/recipes-connectivity/bluez5/bluez5/0001-hciattach-
> bcm43xx-fix-the-delay-timer-for-firmware-d.patch
> deleted file mode 100644
> index 46794381f7..00
> --- a/meta/recipes-connectivity/bluez5/bluez5/0001-hciattach-
> bcm43xx-fix-the-delay-timer-for-firmware-d.patch
> +++ /dev/null
> @@ -1,36 +0,0 @@
> -From 3b341fb421ef61db7782bf1314ec693828467de9 Mon Sep 17 00:00:00 2001
> -From: Andy Duan 
> -Date: Wed, 23 Nov 2016 17:12:12 +0800
> -Subject: [PATCH] hciattach: bcm43xx: fix the delay timer for firmware
> download
> -
> -From the log in .bcm43xx_load_firmware():
> -/* Wait 50ms to let the firmware placed in download mode */
> -nanosleep(_mode, NULL);
> -
> -But timespec tm_mode is real is 50us. Correct the delayed timer count.
> -
> -Upstream-Status: Accepted [https://git.kernel.org/pub/
> scm/bluetooth/bluez.git/commit/?id=76255f732d68aef2b90d36d9c7be51
> a9e1739ce7]
> -
> -Signed-off-by: Fugang Duan 
> 
> - tools/hciattach_bcm43xx.c | 4 ++--
> - 1 file changed, 2 insertions(+), 2 deletions(-)
> -
> -diff --git a/tools/hciattach_bcm43xx.c b/tools/hciattach_bcm43xx.c
> -index 81f38cb..ac1b3c1 100644
>  a/tools/hciattach_bcm43xx.c
> -+++ b/tools/hciattach_bcm43xx.c
> -@@ -228,8 +228,8 @@ static int bcm43xx_set_speed(int fd, struct termios
> *ti, uint32_t speed)
> - static int bcm43xx_load_firmware(int fd, const char *fw)
> - {
> -   unsigned char cmd[] = { HCI_COMMAND_PKT, 0x2e, 0xfc, 0x00 };
> --  struct timespec tm_mode = { 0, 5 };
> --  struct timespec tm_ready = { 0, 200 };
> -+  struct timespec tm_mode = { 0, 5000 };
> -+  struct timespec tm_ready = { 0, 2 };
> -   unsigned char resp[CC_MIN_SIZE];
> -   unsigned char tx_buf[1024];
> -   int len, fd_fw, n;
> ---
> -1.9.1
> -
> diff --git a/meta/recipes-connectivity/bluez5/bluez5/cve-2017-1000250.patch
> b/meta/recipes-connectivity/bluez5/bluez5/cve-2017-1000250.patch
> deleted file mode 100644
> index 9fac961bcf..00
> --- a/meta/recipes-connectivity/bluez5/bluez5/cve-2017-1000250.patch
> +++ /dev/null
> @@ -1,34 +0,0 @@
> -All versions of the SDP server in BlueZ 5.46 and earlier are vulnerable
> to an
> -information disclosure vulnerability which allows remote attackers to
> obtain
> -sensitive information from the bluetoothd process memory. This
> vulnerability
> -lies in the processing of SDP search attribute requests.
> -
> -CVE: CVE-2017-1000250
> -Upstream-Status: Backport
>

[OE-core] [PATCH v3] u-boot-fw-utils: Fix cross and target builds

2017-09-19 Thread Otavio Salvador 
 - The environment tools target has change to envtools;
 - The HOSTCC variable must be used to set CC for cross;
 - Drop ARCH variable as it is set on config;

Signed-off-by: Otavio Salvador 
---

Changes in v3:
- drop ARCH (trini)

Changes in v2:
- pass V=1 for cross - sorry

 meta/recipes-bsp/u-boot/u-boot-fw-utils_2017.09.bb | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/meta/recipes-bsp/u-boot/u-boot-fw-utils_2017.09.bb 
b/meta/recipes-bsp/u-boot/u-boot-fw-utils_2017.09.bb
index c2e8f0fb84..02887a138a 100644
--- a/meta/recipes-bsp/u-boot/u-boot-fw-utils_2017.09.bb
+++ b/meta/recipes-bsp/u-boot/u-boot-fw-utils_2017.09.bb
@@ -5,13 +5,13 @@ DEPENDS = "mtd-utils"
 
 INSANE_SKIP_${PN} = "already-stripped"
 EXTRA_OEMAKE_class-target = 'CROSS_COMPILE=${TARGET_PREFIX} CC="${CC} 
${CFLAGS} ${LDFLAGS}" HOSTCC="${BUILD_CC} ${BUILD_CFLAGS} ${BUILD_LDFLAGS}" V=1'
-EXTRA_OEMAKE_class-cross = 'ARCH=${TARGET_ARCH} CC="${CC} ${CFLAGS} 
${LDFLAGS}" V=1'
+EXTRA_OEMAKE_class-cross = 'HOSTCC="${CC} ${CFLAGS} ${LDFLAGS}" V=1'
 
 inherit uboot-config
 
 do_compile () {
oe_runmake ${UBOOT_MACHINE}
-   oe_runmake env
+   oe_runmake envtools
 }
 
 do_install () {
-- 
2.14.1

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] bluez5: Upgrade 5.46 -> 5.47

2017-09-19 Thread Marc Ferland 
This release includes:

- SDP fix for CVE-2017-1000250.
- New bluetooth mesh profile.
- Various fixes to GATT, A2DP and BR/EDR vs LE bearer handling.

This commit also drops the following two patches which are included in
5.47:

- 0001-hciattach-bcm43xx-fix-the-delay-timer-for-firmware-d.patch
- cve-2017-1000250.patch

Signed-off-by: Marc Ferland 
---
 meta/recipes-connectivity/bluez5/bluez5.inc|  3 +-
 ...cm43xx-fix-the-delay-timer-for-firmware-d.patch | 36 --
 .../bluez5/bluez5/cve-2017-1000250.patch   | 34 
 .../bluez5/{bluez5_5.46.bb => bluez5_5.47.bb}  |  4 +--
 4 files changed, 3 insertions(+), 74 deletions(-)
 delete mode 100644 
meta/recipes-connectivity/bluez5/bluez5/0001-hciattach-bcm43xx-fix-the-delay-timer-for-firmware-d.patch
 delete mode 100644 
meta/recipes-connectivity/bluez5/bluez5/cve-2017-1000250.patch
 rename meta/recipes-connectivity/bluez5/{bluez5_5.46.bb => bluez5_5.47.bb} 
(91%)

diff --git a/meta/recipes-connectivity/bluez5/bluez5.inc 
b/meta/recipes-connectivity/bluez5/bluez5.inc
index 2ae4553d48..3a8d3476ea 100644
--- a/meta/recipes-connectivity/bluez5/bluez5.inc
+++ b/meta/recipes-connectivity/bluez5/bluez5.inc
@@ -41,6 +41,7 @@ PACKAGECONFIG[sixaxis] = "--enable-sixaxis,--disable-sixaxis"
 PACKAGECONFIG[tools] = "--enable-tools,--disable-tools"
 PACKAGECONFIG[threads] = "--enable-threads,--disable-threads"
 PACKAGECONFIG[deprecated] = "--enable-deprecated,--disable-deprecated"
+PACKAGECONFIG[mesh] = "--enable-mesh,--disable-mesh, json-c"
 
 SRC_URI = "\
 ${KERNELORG_MIRROR}/linux/bluetooth/bluez-${PV}.tar.xz \
@@ -49,8 +50,6 @@ SRC_URI = "\
 file://run-ptest \
 ${@bb.utils.contains('DISTRO_FEATURES', 'systemd', '', 
'file://0001-Allow-using-obexd-without-systemd-in-the-user-sessio.patch', d)} \
 file://0001-tests-add-a-target-for-building-tests-without-runnin.patch \
-file://0001-hciattach-bcm43xx-fix-the-delay-timer-for-firmware-d.patch \
-file://cve-2017-1000250.patch \
 "
 S = "${WORKDIR}/bluez-${PV}"
 
diff --git 
a/meta/recipes-connectivity/bluez5/bluez5/0001-hciattach-bcm43xx-fix-the-delay-timer-for-firmware-d.patch
 
b/meta/recipes-connectivity/bluez5/bluez5/0001-hciattach-bcm43xx-fix-the-delay-timer-for-firmware-d.patch
deleted file mode 100644
index 46794381f7..00
--- 
a/meta/recipes-connectivity/bluez5/bluez5/0001-hciattach-bcm43xx-fix-the-delay-timer-for-firmware-d.patch
+++ /dev/null
@@ -1,36 +0,0 @@
-From 3b341fb421ef61db7782bf1314ec693828467de9 Mon Sep 17 00:00:00 2001
-From: Andy Duan 
-Date: Wed, 23 Nov 2016 17:12:12 +0800
-Subject: [PATCH] hciattach: bcm43xx: fix the delay timer for firmware download
-
-From the log in .bcm43xx_load_firmware():
-/* Wait 50ms to let the firmware placed in download mode */
-nanosleep(_mode, NULL);
-
-But timespec tm_mode is real is 50us. Correct the delayed timer count.
-
-Upstream-Status: Accepted 
[https://git.kernel.org/pub/scm/bluetooth/bluez.git/commit/?id=76255f732d68aef2b90d36d9c7be51a9e1739ce7]
-
-Signed-off-by: Fugang Duan 

- tools/hciattach_bcm43xx.c | 4 ++--
- 1 file changed, 2 insertions(+), 2 deletions(-)
-
-diff --git a/tools/hciattach_bcm43xx.c b/tools/hciattach_bcm43xx.c
-index 81f38cb..ac1b3c1 100644
 a/tools/hciattach_bcm43xx.c
-+++ b/tools/hciattach_bcm43xx.c
-@@ -228,8 +228,8 @@ static int bcm43xx_set_speed(int fd, struct termios *ti, 
uint32_t speed)
- static int bcm43xx_load_firmware(int fd, const char *fw)
- {
-   unsigned char cmd[] = { HCI_COMMAND_PKT, 0x2e, 0xfc, 0x00 };
--  struct timespec tm_mode = { 0, 5 };
--  struct timespec tm_ready = { 0, 200 };
-+  struct timespec tm_mode = { 0, 5000 };
-+  struct timespec tm_ready = { 0, 2 };
-   unsigned char resp[CC_MIN_SIZE];
-   unsigned char tx_buf[1024];
-   int len, fd_fw, n;
--- 
-1.9.1
-
diff --git a/meta/recipes-connectivity/bluez5/bluez5/cve-2017-1000250.patch 
b/meta/recipes-connectivity/bluez5/bluez5/cve-2017-1000250.patch
deleted file mode 100644
index 9fac961bcf..00
--- a/meta/recipes-connectivity/bluez5/bluez5/cve-2017-1000250.patch
+++ /dev/null
@@ -1,34 +0,0 @@
-All versions of the SDP server in BlueZ 5.46 and earlier are vulnerable to an
-information disclosure vulnerability which allows remote attackers to obtain
-sensitive information from the bluetoothd process memory. This vulnerability
-lies in the processing of SDP search attribute requests.
-
-CVE: CVE-2017-1000250
-Upstream-Status: Backport
-Signed-off-by: Ross Burton 
-
-From 9e009647b14e810e06626dde7f1bb9ea3c375d09 Mon Sep 17 00:00:00 2001
-From: Luiz Augusto von Dentz 
-Date: Wed, 13 Sep 2017 10:01:40 +0300
-Subject: sdp: Fix Out-of-bounds heap read in service_search_attr_req function
-
-Check if there is enough data to continue otherwise return an error.

- src/sdpd-request.c | 2 +-
- 1 file

Re: [OE-core] [PATCH] u-boot-fw-utils: Fix cross and target builds

2017-09-19 Thread Tom Rini 
On Tue, Sep 19, 2017 at 08:53:38AM -0300, Otavio Salvador wrote:
> Em 19 de set de 2017 8:26 AM, "Tom Rini"  escreveu:
> 
> On Tue, Sep 19, 2017 at 02:40:58AM -0300, Otavio Salvador wrote:
> >  - The environment tools target has change to envtools;
> >  - The HOSTCC variable must be used to set CC for cross;
> >  - The ARCH variable must be set for cross;
> >
> > Signed-off-by: Otavio Salvador 
> > ---
> >
> >  meta/recipes-bsp/u-boot/u-boot-fw-utils_2017.09.bb | 6 +++---
> >  1 file changed, 3 insertions(+), 3 deletions(-)
> >
> > diff --git a/meta/recipes-bsp/u-boot/u-boot-fw-utils_2017.09.bb
> b/meta/recipes-bsp/u-boot/u-boot-fw-utils_2017.09.bb
> > index c2e8f0fb84..21ab5b3e6d 100644
> > --- a/meta/recipes-bsp/u-boot/u-boot-fw-utils_2017.09.bb
> > +++ b/meta/recipes-bsp/u-boot/u-boot-fw-utils_2017.09.bb
> > @@ -5,13 +5,13 @@ DEPENDS = "mtd-utils"
> >
> >  INSANE_SKIP_${PN} = "already-stripped"
> >  EXTRA_OEMAKE_class-target = 'CROSS_COMPILE=${TARGET_PREFIX} CC="${CC}
> ${CFLAGS} ${LDFLAGS}" HOSTCC="${BUILD_CC} ${BUILD_CFLAGS} ${BUILD_LDFLAGS}"
> V=1'
> > -EXTRA_OEMAKE_class-cross = 'ARCH=${TARGET_ARCH} CC="${CC} ${CFLAGS}
> ${LDFLAGS}" V=1'
> > +EXTRA_OEMAKE_class-cross = 'ARCH=${ARCH} HOSTCC="${CC} ${CFLAGS}
> ${LDFLAGS}" V=0'
> 
> Since we're messing with this, U-Boot's build system doesn't take ARCH.
> It's one of the variables that you pick in Kconfig, not set so that
> arch/$(ARCH)/Kconfig is sourced.  We should drop that.
> 
> 
> You can't. Try dropping it...

I've never ever built U-Boot with ARCH=, so, what's going on in OE land?

-- 
Tom


signature.asc
Description: Digital signature
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] base-files: profile: Get rid of "resize"

2017-09-19 Thread Burton, Ross 
On 18 September 2017 at 22:11, Andre McCurdy  wrote:

> The "get rid of resize" patch seems to have made it into mut.
>

It was reverted at 8pm last night but I didn't push.

Ross
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] base-files: profile: Get rid of "resize"

2017-09-19 Thread Burton, Ross 
On 19 September 2017 at 06:26, Mike Looijmans 
wrote:

> My experience is that it does not, and never has. I run serial consoles
> all the time, and if they're not sized to 80x25 weird stuff happens.
>
> Start vi on a serial terminal and it only uses the top 80x25. If a command
> exceed the 80 char mark, the cursor goes all weird.
> Running "eval `resize`" fixes that (until you resize the window). Running
> just "resize" does not have any effect on that at all.
>
> Cannot we determine the presence of "tty" and "resize" commands at compile
> time? something like:
>
> if has_command("tty") and has_command("resize"):
> install -m 755 ${S}/resize.sh ${D}${sysconfdir}/profile.d/


As part of busybox, yes.  Not anywhere else though.

Ross
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] u-boot-fw-utils: Fix cross and target builds

2017-09-19 Thread Otavio Salvador 
Em 19 de set de 2017 8:26 AM, "Tom Rini"  escreveu:

On Tue, Sep 19, 2017 at 02:40:58AM -0300, Otavio Salvador wrote:
>  - The environment tools target has change to envtools;
>  - The HOSTCC variable must be used to set CC for cross;
>  - The ARCH variable must be set for cross;
>
> Signed-off-by: Otavio Salvador 
> ---
>
>  meta/recipes-bsp/u-boot/u-boot-fw-utils_2017.09.bb | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/meta/recipes-bsp/u-boot/u-boot-fw-utils_2017.09.bb
b/meta/recipes-bsp/u-boot/u-boot-fw-utils_2017.09.bb
> index c2e8f0fb84..21ab5b3e6d 100644
> --- a/meta/recipes-bsp/u-boot/u-boot-fw-utils_2017.09.bb
> +++ b/meta/recipes-bsp/u-boot/u-boot-fw-utils_2017.09.bb
> @@ -5,13 +5,13 @@ DEPENDS = "mtd-utils"
>
>  INSANE_SKIP_${PN} = "already-stripped"
>  EXTRA_OEMAKE_class-target = 'CROSS_COMPILE=${TARGET_PREFIX} CC="${CC}
${CFLAGS} ${LDFLAGS}" HOSTCC="${BUILD_CC} ${BUILD_CFLAGS} ${BUILD_LDFLAGS}"
V=1'
> -EXTRA_OEMAKE_class-cross = 'ARCH=${TARGET_ARCH} CC="${CC} ${CFLAGS}
${LDFLAGS}" V=1'
> +EXTRA_OEMAKE_class-cross = 'ARCH=${ARCH} HOSTCC="${CC} ${CFLAGS}
${LDFLAGS}" V=0'

Since we're messing with this, U-Boot's build system doesn't take ARCH.
It's one of the variables that you pick in Kconfig, not set so that
arch/$(ARCH)/Kconfig is sourced.  We should drop that.


You can't. Try dropping it...

And the
changelog doesn't say you're going from V=1 to V=0.


I sent v2 just after.


--
Tom

--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] go-runtime does not build for mips32r2 tune

2017-09-19 Thread Matt Madison 
On Mon, Sep 18, 2017 at 4:26 PM, Khem Raj  wrote:
> On Mon, Sep 18, 2017 at 3:52 PM, Mark Hatle  wrote:
>> On 9/18/17 5:50 PM, Matt Madison wrote:
>>>
 On 18 Sep 2017, at 2:11 PM, Slater, Joseph > wrote:

 This is the default tune for qemumips.  It appears that the problem does 
 not
 occur for an oe-core checkout just before the split creating go-runtime.

 Before the split, go-helloworld will build, but after the split it will not
 because it needs go-runtime.
>>>
>>> There’s a TUNE_CCARGS_remove in go_1.9.bb to remove the ‘-march=mips32r2’ 
>>> flag
>>> that probably either needs to be moved to a .inc file or copied to
>>> go-runtime_1.9.bb.  Missed that when splitting out the runtime recipe.
>>
>> That seems wrong.  We should be using the TUNE_CCARGS, and -not- using the
>> arguments that 'go' has decided must be right.
>>
>> Otherwise the optimizations may or may not be compatible... and if someone
>> selects different arguments, they won't get filtered.
>
> go supports mips32r1, and needs fpu or kernel FPU emulation enabled
> so using mips32r2 might be fine back when I was adding it to oe-core it
> did not work, things might be different with 1.9 release where mips
> support is complete in golang.

It's still mips32r1, though, and the go build tool explicitly adds
'-march=mips32 -mabi=32' when invoking the C compiler for cgo.

-Matt
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] u-boot-fw-utils: Fix cross and target builds

2017-09-19 Thread Tom Rini 
On Tue, Sep 19, 2017 at 02:40:58AM -0300, Otavio Salvador wrote:
>  - The environment tools target has change to envtools;
>  - The HOSTCC variable must be used to set CC for cross;
>  - The ARCH variable must be set for cross;
> 
> Signed-off-by: Otavio Salvador 
> ---
> 
>  meta/recipes-bsp/u-boot/u-boot-fw-utils_2017.09.bb | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/meta/recipes-bsp/u-boot/u-boot-fw-utils_2017.09.bb 
> b/meta/recipes-bsp/u-boot/u-boot-fw-utils_2017.09.bb
> index c2e8f0fb84..21ab5b3e6d 100644
> --- a/meta/recipes-bsp/u-boot/u-boot-fw-utils_2017.09.bb
> +++ b/meta/recipes-bsp/u-boot/u-boot-fw-utils_2017.09.bb
> @@ -5,13 +5,13 @@ DEPENDS = "mtd-utils"
>  
>  INSANE_SKIP_${PN} = "already-stripped"
>  EXTRA_OEMAKE_class-target = 'CROSS_COMPILE=${TARGET_PREFIX} CC="${CC} 
> ${CFLAGS} ${LDFLAGS}" HOSTCC="${BUILD_CC} ${BUILD_CFLAGS} ${BUILD_LDFLAGS}" 
> V=1'
> -EXTRA_OEMAKE_class-cross = 'ARCH=${TARGET_ARCH} CC="${CC} ${CFLAGS} 
> ${LDFLAGS}" V=1'
> +EXTRA_OEMAKE_class-cross = 'ARCH=${ARCH} HOSTCC="${CC} ${CFLAGS} ${LDFLAGS}" 
> V=0'

Since we're messing with this, U-Boot's build system doesn't take ARCH.
It's one of the variables that you pick in Kconfig, not set so that
arch/$(ARCH)/Kconfig is sourced.  We should drop that.  And the
changelog doesn't say you're going from V=1 to V=0.

-- 
Tom


signature.asc
Description: Digital signature
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] pseudo: use epoll API on Linux

2017-09-19 Thread Alexander Kanavin 

On 09/16/2017 03:06 AM, Trevor Woerner wrote:

So, my understand is that pseudo is looking for a new maintainer.
Maybe that person has been found? ;-)



If that person is me, then thank you for the trust, but:

a) I had no idea how pseudo works until last week; right now I'm 
familiar with maybe 3% of its code;


b) taking responsibility for these things is unfortunately something of 
a zero-sum game; my main area is maintenance of oe-core content, and 
with Jussi Kukkonen no longer involved in the project, I only expect 
more work, not less. Particularly around graphics, multimedia and 
gnome-related things.



Alex
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [oe] Use of github /archive/ tarballs in SRC_URI

2017-09-19 Thread Burton, Ross 
On 19 September 2017 at 09:32,  wrote:

> Yes, we have been affected by this several times too.
>
> In addition to fixing recipes, a sanity test to warn about the situation
> would be nice to have so that the issue could be detected in other
> meta layers too.
>

So I have a class adding a few tests to package_qa, including this one:

https://github.com/rossburton/meta-ross/blob/0f788385dbe13914e9e07d382793c494c4927ef9/classes/insanitier.bbclass#L93

If I get a moment I'll move it to insane.bbclass.

Ross
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] classes/image: fix do_image_qa dependencies

2017-09-19 Thread Tomasz Meresiński 
After do_image_complete IMAGE_ROOTFS directory is empty so qa checks do not work

Signed-off-by: Tomasz Meresiński 
---
 meta/classes/image.bbclass | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/classes/image.bbclass b/meta/classes/image.bbclass
index 3639aa44f4..7059f947ed 100644
--- a/meta/classes/image.bbclass
+++ b/meta/classes/image.bbclass
@@ -320,7 +320,7 @@ fakeroot python do_image_qa () {
 imgname = d.getVar('IMAGE_NAME')
 bb.fatal("QA errors found whilst validating image: %s\n%s" % (imgname, 
qamsg))
 }
-addtask do_image_qa after do_image_complete before do_build
+addtask do_image_qa after do_image before do_image_complete
 
 SSTATETASKS += "do_image_qa"
 SSTATE_SKIP_CREATION_task-image-qa = '1'
-- 
2.12.3

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] classes/image: fix do_image_qa dependencies

2017-09-19 Thread Tomasz Meresiński 
After do_image_complete IMAGE_ROOTFS directory is empty so qa checks do not work

Signed-off-by: Tomasz Meresiński 
---
 meta/classes/image.bbclass | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/classes/image.bbclass b/meta/classes/image.bbclass
index 3639aa44f4..7059f947ed 100644
--- a/meta/classes/image.bbclass
+++ b/meta/classes/image.bbclass
@@ -320,7 +320,7 @@ fakeroot python do_image_qa () {
 imgname = d.getVar('IMAGE_NAME')
 bb.fatal("QA errors found whilst validating image: %s\n%s" % (imgname, 
qamsg))
 }
-addtask do_image_qa after do_image_complete before do_build
+addtask do_image_qa after do_image before do_image_complete

 SSTATETASKS += "do_image_qa"
 SSTATE_SKIP_CREATION_task-image-qa = '1'
--
2.12.3

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] classes/image_live: fix using squashfs as image filesystem

2017-09-19 Thread Tomasz Meresiński 
Different squashfs versions have IMAGE_TYPE with hyphen (eg squashfs-lz4).
Tasks on the other hand have names with underscore (eg do_image_squashfs_lz4).

Signed-off-by: Tomasz Meresiński 
---
 meta/classes/image-live.bbclass | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/classes/image-live.bbclass b/meta/classes/image-live.bbclass
index c1862b1319..7a388d5c60 100644
--- a/meta/classes/image-live.bbclass
+++ b/meta/classes/image-live.bbclass
@@ -34,7 +34,7 @@ do_bootimg[depends] += "dosfstools-native:do_populate_sysroot 
\
 ${MLPREFIX}syslinux:do_populate_sysroot \
 syslinux-native:do_populate_sysroot \
 ${@oe.utils.ifelse(d.getVar('COMPRESSISO', 
False),'zisofs-tools-native:do_populate_sysroot','')} \
-${PN}:do_image_${LIVE_ROOTFS_TYPE} \
+
${PN}:do_image_${@d.getVar('LIVE_ROOTFS_TYPE').replace('-', '_')} \
 "


--
2.12.3

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 1/2] image.bbclass: Correct chaining compression support

2017-09-19 Thread Martin Hundebøll 

Hi Tom,

On 2017-07-22 00:06, Tom Rini wrote:

diff --git a/meta/classes/image.bbclass b/meta/classes/image.bbclass
index de535ce6fcff..bd6a5b7b810a 100644
--- a/meta/classes/image.bbclass
+++ b/meta/classes/image.bbclass
@@ -453,7 +453,7 @@ python () {
  rm_tmp_images = set()
  def gen_conversion_cmds(bt):
  for ctype in ctypes:
-if bt[bt.find('.') + 1:] == ctype:
+if bt.endswith("." + ctype):
  type = bt[0:-len(ctype) - 1]
  if type.startswith("debugfs_"):
  type = type[8:]


This is the change that in fact messes with our cpio.gz.u-boot image 
types, causing base hash changes.


I suspect the changed if-check to be too permissive. In our case, it now 
matches any ctype that ends with ".u-boot", and not just "gz.u-boot" as 
set in IMAGE_FSTYPES.


Wouldn't it be correct to match on the entire bt variable? I.e.

diff --git a/meta/classes/image.bbclass b/meta/classes/image.bbclass 


index ef2b38aeaf..818932f7f1 100644
--- a/meta/classes/image.bbclass
+++ b/meta/classes/image.bbclass
@@ -454,7 +454,7 @@ python () {
 rm_tmp_images = set()
 def gen_conversion_cmds(bt):
 for ctype in ctypes:
-if bt.endswith("." + ctype):
+if bt.split('.', 1) == [t, ctype]:
 type = bt[0:-len(ctype) - 1]
 if type.startswith("debugfs_"):
 type = type[8:]

This works for me, preliminary tested with the following fs types 
configured:


IMAGE_FSTYPES = "cpio.gz.u-boot"
IMAGE_FSTYPES = "tar cpio cpio.gz cpio.gz.u-boot"
	IMAGE_FSTYPES = "tar cpio cpio.gz cpio.gz.u-boot tar.bz2 jffs2 wic 
wic.bmap"


// Martin
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] image: Fix "metadata is not deterministic" when chaining 2+ CONVERSION_CMDs

2017-09-19 Thread Martin Hundebøll 



On 2017-09-15 20:20, Martin Hundebøll wrote:

On 2017-09-15 14:16, Tom Rini wrote:

This commit has resulted in more or less persistent basehash issues
for my cpio.gz.u-boot image:

ERROR: When reparsing 
/home/mnhu/projects/pil/yocto/meta-pil/recipes-filesystems/rescue-rootfs.bb.do_image_cpio, 


the basehash value changed from ac9907bbb8ee2ee6d9ca90f7a7e265f5 to
8c7b717add6b1d1ba6ff761ebfdedf01. The metadata is not deterministic
and this needs to be fixed.

The error occurs repeatedly when doing `bitbake -c clean
rescue-rootfs && bitbake rescue-rootfs`. Reverting the commit makes
the error go away.

Also, the issue only appears for cpio.gz.u-boot image types, but not
for cpio.gz

I am far from an expert in bitbake signature handling, so please let
me know what to do, to debug this further.

Can you let me know what layers and machine I need to reproduce this?
I'll take a look, thanks!


I am able to reproduce with the following:

   - Ubuntu 16.04 based on the attached Dockerfile
   - A clean clone of poky (commit 072430b9b3)
   - meta, meta-poky, and meta-yocto-bsp (see build-config.log)
   - beaglebone machine and gpio.gz.u-boot image type (see local.conf)


Sorry, this seems to be caused by your earlier patch: 88eec32150 
('image.bbclass: Correct chaining compression support'). My first 
conclusion was probably caused by caching playing me a trick.


I'll reply to that patch instead.

// Martin
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [oe] Use of github /archive/ tarballs in SRC_URI

2017-09-19 Thread Mikko.Rapeli 
Yes, we have been affected by this several times too.

In addition to fixing recipes, a sanity test to warn about the situation
would be nice to have so that the issue could be detected in other
meta layers too.

-Mikko
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [U-Boot] [PATCH] u-boot: Upgrade to 2017.09

2017-09-19 Thread Marek Vasut 
On 09/18/2017 06:06 PM, Tom Rini wrote:
> On Mon, Sep 18, 2017 at 04:51:31PM +0100, Burton, Ross wrote:
>> On 18 September 2017 at 16:46, Otavio Salvador <
>> otavio.salva...@ossystems.com.br> wrote:
>>
>>> What is the policy on doing u-boot version upgrades this late in the
>>>
>>> release cycle? SHouldn't this wait until after the release?
>>>
>>>
>>> Why?
>>>
>>> It is just another recipe and we are upgrading to the final release.
>>>
>>> As Martin said, it was already broken.
>>>
>>> I'll take the responsibility to fix it. But as other packages, upgrades
>>> has risk and we have more than enough time to proper fix it.
>>>
>>
>> Why?  Because it was merged to master after the freeze.
>>
>> Personally I'm of the opinion that u-boot is one of those special recipes
>> that if an upgrade appears just after freeze, we consider it.  If we don't
>> keep it up to date BSPs won't use the recipe, and we'll be back to every
>> BSP layer containing its own special copy of the u-boot recipe.
> 
> Also please note that U-Boot has a rather regular and public release
> schedule: http://www.denx.de/wiki/U-Boot/ReleaseCycle so you can have a
> good idea beforehand if you want to grab something for a release or not.
> 
> Personally, I would like to see this in.  But the security issue that's
> been disclosed now is "resolved" just by not enabling functionality that
> no one was enabling in mainline, and will be removed in the next
> release, so don't feel you need to pull it in on those grounds.

I agree that the 2017.09 upgrade is a good idea.

-- 
Best regards,
Marek Vasut
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] Use of github /archive/ tarballs in SRC_URI

2017-09-19 Thread Burton, Ross 
Hi,

Some people have insisted for a long time that the dynamically generated
/archive/ tarballs at github cannot be trusted for long-term stability, as
they are generated using git-archive.  Others said that git-archive takes
measures to ensure the files are identical, and basic testing does indeed
show that.  Personally I was on the fence: a dynamically generated tarball
that is cached *could* change, but the git-archive generates the same file
list and the tools are stable.

Then the tarball for one of Erlang's repositories changed, and was noticed
by the checksum in the recipe (thanks Gunnar Andersson for reporting
this).  The extracted contents are identical, but the tarball itself has
changed.  I'm presuming this is due to the old tarball expiring in their
cache, and a newly generated tarball using a later version of tar.

So we now have documented evidence that this can and does happen, and it's
quite frustrating when this happens.  So, I suggest that use of github.com
/archive/ URLs be considered a bad practise for the primary SRC_URI tarball.

I'm working my way through the recipes in oe-core that use /archive/ and
replacing them with either maintainer-generated tarballs or git clones, but
there are a number of recipes in meta-oe which could do with fixing:

$ git grep -l -E github\\.com/.*/archive/
meta-initramfs/recipes-devtools/grubby/grubby_8.40.bb
meta-multimedia/recipes-support/gst-instruments/gst-instruments_0.2.3.bb
meta-multimedia/recipes-support/libsrtp/libsrtp_1.5.2.bb
meta-networking/recipes-support/geoip/geoip-perl_1.50.bb
meta-oe/recipes-connectivity/libuv/libuv_1.11.0.bb
meta-oe/recipes-connectivity/libwebsockets/libwebsockets_2.1.0.bb
meta-oe/recipes-devtools/protobuf/protobuf-c_1.2.1.bb
meta-oe/recipes-devtools/python/python-cpuset_1.5.7.bb
meta-oe/recipes-extended/boinc/boinc-client_7.6.33.bb
meta-oe/recipes-graphics/libvncserver/libvncserver_0.9.11.bb
meta-oe/recipes-graphics/openjpeg/openjpeg_2.1.1.bb
meta-oe/recipes-kernel/crash/crash_7.1.9.bb
meta-oe/recipes-multimedia/mplayer/mpv_0.24.0.bb
meta-oe/recipes-support/hunspell/hunspell_1.6.1.bb
meta-oe/recipes-support/lm_sensors/lmsensors_3.4.0.bb
meta-oe/recipes-test/gtest/gtest_1.8.0.bb
meta-perl/recipes-perl/libmodule/libmodule-pluggable-perl_5.2.bb
meta-perl/recipes-perl/libmodule/libmodule-runtime-perl_0.015.bb

Ross
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCHv2] pseudo: use epoll API on Linux

2017-09-19 Thread Burton, Ross 
On 19 September 2017 at 00:16, Trevor Woerner  wrote:

> It doesn't make sense to carry these large patches against pseudo in
> OE itself. Isn't pseudo one of the tools under The Yocto Project
> umbrella? Adding patches to a recipe is what happens when upstream
> isn't under our control, isn't responsive, or isn't cooperating.
>
> Can someone volunteer to be the active maintainer of it and get commit
> access? I'll volunteer, if nobody else does. But if I become the
> maintainer, I'll need some time to get up-to-speed, or some potential
> support from the current maintainer.


This patch may not yet be acceptable "upstream" but is sufficient for our
purposes, and we've obviously got a good relationship with "upstream" so
carrying it in oe-core is a short-term measure.

Ross
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] base-files: profile: Get rid of "resize"

2017-09-19 Thread Mike Looijmans 

On 19-09-17 01:07, Trevor Woerner wrote:

I use resize quasi-regularly. Ever end up in the situation where
you've run vim and now the command-line has no idea how large the
console is, so everything wraps or scrolls at the wrong times/places?
resize fixes that:

# . resize

Please don't remove it.



We're not removing the "resize" command itself. It's about removing something 
that started as a simple one-liner in /etc/profile to call "resize" (that did 
not fix the problem) and grew out to be a monster over time.



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



--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core