* [PATCH] pax : strip off the trailing slash of file name
From: jackie.huang @ 2016-11-01 3:01 UTC (permalink / raw)
To: openembedded-core
From: Zhang Xiao <xiao.zhang@windriver.com>
When extracting packaes, the trailing slash of the file name
has no means but may cause some issue on system call lstat.
Remove it.
Signed-off-by: Zhang Xiao <xiao.zhang@windriver.com>
Signed-off-by: Jackie Huang <jackie.huang@windriver.com>
---
.../pax-strip-off-file-name-s-trailing-slash.patch | 48 ++++++++++++++++++++++
meta/recipes-extended/pax/pax_3.4.bb | 4 +-
2 files changed, 51 insertions(+), 1 deletion(-)
create mode 100644 meta/recipes-extended/pax/pax/pax-strip-off-file-name-s-trailing-slash.patch
diff --git a/meta/recipes-extended/pax/pax/pax-strip-off-file-name-s-trailing-slash.patch b/meta/recipes-extended/pax/pax/pax-strip-off-file-name-s-trailing-slash.patch
new file mode 100644
index 0000000..9e0a335
--- /dev/null
+++ b/meta/recipes-extended/pax/pax/pax-strip-off-file-name-s-trailing-slash.patch
@@ -0,0 +1,48 @@
+From aa8ba118869b75a2a9cd681b2f0362d9d8f1c7ec Mon Sep 17 00:00:00 2001
+From: Zhang Xiao <xiao.zhang@windriver.com>
+Date: Tue, 12 Jul 2016 11:34:45 +0800
+Subject: [PATCH] pax: strip off the trailing slash of file name
+
+When extracting packaes, the trailing slash of the file name
+has no means but may cause some issue on system call lstat.
+Remove it.
+
+Upstream-Status: Pending
+
+Signed-off-by: Zhang Xiao <xiao.zhang@windriver.com>
+---
+ src/pat_rep.c | 11 ++++++++++-
+ 1 file changed, 10 insertions(+), 1 deletion(-)
+
+diff --git a/src/pat_rep.c b/src/pat_rep.c
+index b9a4636..4cbf6bf 100644
+--- a/src/pat_rep.c
++++ b/src/pat_rep.c
+@@ -605,7 +605,7 @@ int
+ mod_name(ARCHD *arcn)
+ {
+ int res = 0;
+-
++ char *pt;
+ /*
+ * Strip off leading '/' if appropriate.
+ * Currently, this option is only set for the tar format.
+@@ -639,6 +639,15 @@ mod_name(ARCHD *arcn)
+ }
+
+ /*
++ * strip off trailing slash.
++ */
++ pt = &(arcn->name[strlen(arcn->name) - 1]);
++ if (*pt == '/') {
++ *pt = '\0';
++ arcn->nlen = strlen(arcn->name);
++ }
++
++ /*
+ * IMPORTANT: We have a problem. what do we do with symlinks?
+ * Modifying a hard link name makes sense, as we know the file it
+ * points at should have been seen already in the archive (and if it
+--
+1.8.5.2.233.g932f7e4
+
diff --git a/meta/recipes-extended/pax/pax_3.4.bb b/meta/recipes-extended/pax/pax_3.4.bb
index 9d1abfb..7ce43ce 100644
--- a/meta/recipes-extended/pax/pax_3.4.bb
+++ b/meta/recipes-extended/pax/pax_3.4.bb
@@ -16,7 +16,9 @@ DEPENDS_append_libc-musl = " fts "
SRC_URI = "http://pkgs.fedoraproject.org/repo/pkgs/${BPN}/${BP}.tar.bz2/fbd9023b590b45ac3ade95870702a0d6/${BP}.tar.bz2 \
file://fix_for_compile_with_gcc-4.6.0.patch \
- file://pax-3.4_fix_for_x32.patch"
+ file://pax-3.4_fix_for_x32.patch \
+ file://pax-strip-off-file-name-s-trailing-slash.patch \
+"
SRC_URI_append_libc-musl = " file://0001-Fix-build-with-musl.patch \
file://0001-use-strtoll-instead-of-strtoq.patch \
--
2.8.3
^ permalink raw reply related
* Re: [PATCH 1/7] classes/license: fix handling of symlinks pointed to in LIC_FILES_CHKSUM
From: Christopher Larson @ 2016-11-01 0:53 UTC (permalink / raw)
To: Khem Raj; +Cc: Paul Eggleton, Patches and discussions about the oe-core layer
In-Reply-To: <1A7D1C00-1B1C-40CF-8240-9BC100D0EA8A@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 698 bytes --]
On Mon, Oct 31, 2016 at 3:34 PM, Khem Raj <raj.khem@gmail.com> wrote:
> > On Oct 31, 2016, at 12:41 PM, Paul Eggleton <
> paul.eggleton@linux.intel.com> wrote:
> >
> > Hi Khem,
> >
> > Why wouldn't it be?
>
> Was thinking out loud if the path is expanded to absolute paths then
> does it get recorded into task checksums ?
It’s resolved in the copy_license_files function, not at parse time. Of
course, any functions calling copy_license_files will change checksums due
to the function itself changing, presumably.
--
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics
[-- Attachment #2: Type: text/html, Size: 1176 bytes --]
^ permalink raw reply
* Re: [PATCH 1/7] classes/license: fix handling of symlinks pointed to in LIC_FILES_CHKSUM
From: Khem Raj @ 2016-10-31 22:34 UTC (permalink / raw)
To: Paul Eggleton; +Cc: Patches and discussions about the oe-core layer
In-Reply-To: <2111229.GbldrazETl@peggleto-mobl.ger.corp.intel.com>
[-- Attachment #1: Type: text/plain, Size: 2157 bytes --]
> On Oct 31, 2016, at 12:41 PM, Paul Eggleton <paul.eggleton@linux.intel.com> wrote:
>
> Hi Khem,
>
> Why wouldn't it be?
Was thinking out loud if the path is expanded to absolute paths then
does it get recorded into task checksums ?
>
> Cheers,
> Paul
>
> On Mon, 31 Oct 2016 12:23:04 Khem Raj wrote:
>> Is this sstate safe?
>>
>> On Oct 30, 2016 9:11 PM, "Paul Eggleton" <paul.eggleton@linux.intel.com>
>>
>> wrote:
>>> If you set LIC_FILES_CHKSUM to point to a relative symlink then you'll
>>> get "Could not copy license file" warnings in copy_license_files() since
>>> the symlink won't be valid after it's copied. If the source is a symlink
>>> then we need to dereference it first.
>>>
>>> I encountered this when I used recipetool on the sources for capnproto,
>>> where the c++ directory contains a LICENSE.txt symlink to the LICENSE
>>> file in the parent directory, and this symlink ends up being pointed to
>>> in LIC_FILES_CHKSUM.
>>>
>>> Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
>>> ---
>>>
>>> meta/classes/license.bbclass | 2 ++
>>> 1 file changed, 2 insertions(+)
>>>
>>> diff --git a/meta/classes/license.bbclass b/meta/classes/license.bbclass
>>> index da4fc3e..660b85f 100644
>>> --- a/meta/classes/license.bbclass
>>> +++ b/meta/classes/license.bbclass
>>>
>>> @@ -351,6 +351,8 @@ def copy_license_files(lic_files_paths, destdir):
>>> dst = os.path.join(destdir, basename)
>>>
>>> if os.path.exists(dst):
>>> os.remove(dst)
>>>
>>> + if os.path.islink(src):
>>> + src = os.path.realpath(src)
>>>
>>> canlink = os.access(src, os.W_OK) and (os.stat(src).st_dev ==
>>>
>>> os.stat(destdir).st_dev)
>>>
>>> if canlink:
>>> try:
>>> --
>>> 2.5.5
>>>
>>> --
>>> _______________________________________________
>>> Openembedded-core mailing list
>>> Openembedded-core@lists.openembedded.org
>>> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
> --
>
> Paul Eggleton
> Intel Open Source Technology Centre
[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 211 bytes --]
^ permalink raw reply
* Re: [PATCH] boost: fix the SRC_URI to point to an actual release, and not a master snapshot
From: Andreas Oberritter @ 2016-10-31 20:44 UTC (permalink / raw)
To: Alexander Kanavin; +Cc: openembedded-core
In-Reply-To: <20161031132336.16626-1-alexander.kanavin@linux.intel.com>
Hello Alexander,
On 31.10.2016 14:23, Alexander Kanavin wrote:
> Sourceforge does a not-so-clever redirecting that fails miserably here:
>
> Proxy request sent, awaiting response... 301 Moved Permanently
> Location: http://downloads.sourceforge.net/project/boost/boost/snapshots/master/boost_1_62_0.tar.bz2 [following]
>
> Also, boost developers are naming their snapshot tarballs the same as
> release tarballs. The two things conspired together.
>
> The new tarball does have the same checksum as the one in release
> announcement, so we should be good now:
>
> http://lists.boost.org/Archives/boost/2016/09/230886.php
>
> Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com>
> ---
> meta/recipes-support/boost/boost-1.62.0.inc | 8 +++++---
> 1 file changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/meta/recipes-support/boost/boost-1.62.0.inc b/meta/recipes-support/boost/boost-1.62.0.inc
> index a097ea1..cd99b0e 100644
> --- a/meta/recipes-support/boost/boost-1.62.0.inc
> +++ b/meta/recipes-support/boost/boost-1.62.0.inc
> @@ -11,9 +11,11 @@ BOOST_VER = "${@"_".join(d.getVar("PV", True).split("."))}"
> BOOST_MAJ = "${@"_".join(d.getVar("PV", True).split(".")[0:2])}"
> BOOST_P = "boost_${BOOST_VER}"
>
> -SRC_URI = "${SOURCEFORGE_MIRROR}/boost/${BOOST_P}.tar.bz2"
> +SRC_URI = "${SOURCEFORGE_MIRROR}/project/boost/boost/${PV}/${BOOST_P}.tar.bz2"
>
> -SRC_URI[md5sum] = "7ef085456c48c49a7fe8237f07e5f674"
> -SRC_URI[sha256sum] = "bce80293052e2d6230f1bec9b7524b33412e4fb26e9723460a0f362ac15b7acb"
> +SRC_URI[md5sum] = "5fb94629535c19e48703bdb2b2e9490f"
> +SRC_URI[sha256sum] = "36c96b0f6155c98404091d8ceb48319a28279ca0333fba1ad8611eb90afb2ca0"
> +
> +PR = "r1"
doesn't the changed SRC_URI (or even the modified checksums alone)
render the PR bump unnecessary?
Regards,
Andreas
^ permalink raw reply
* Re: [PATCH v2] uninative: rebuild uninative for gcc 4.8 and 4.9
From: Burton, Ross @ 2016-10-31 20:11 UTC (permalink / raw)
To: Ed Bartosh; +Cc: OE-core
In-Reply-To: <1477552212-8536-1-git-send-email-ed.bartosh@linux.intel.com>
[-- Attachment #1: Type: text/plain, Size: 353 bytes --]
On 27 October 2016 at 08:10, Ed Bartosh <ed.bartosh@linux.intel.com> wrote:
> + match = re.match(".* (\d\.\d)\.\d .*", output.split('\n')[0])
>
Debian uses this string:
gcc (Debian 4.9.2-10) 4.9.2
So your regex needs to be a bit more permissive, and it looks like grabbing
the second number would be more appropriate here too.
Ross
[-- Attachment #2: Type: text/html, Size: 998 bytes --]
^ permalink raw reply
* Re: [PATCH 1/7] classes/license: fix handling of symlinks pointed to in LIC_FILES_CHKSUM
From: Paul Eggleton @ 2016-10-31 19:41 UTC (permalink / raw)
To: Khem Raj; +Cc: Patches and discussions about the oe-core layer
In-Reply-To: <CAMKF1soshS9nzHZ_OEQ9cJvZNRREnAKQKz6fXUzcJQGBD6nvHA@mail.gmail.com>
Hi Khem,
Why wouldn't it be?
Cheers,
Paul
On Mon, 31 Oct 2016 12:23:04 Khem Raj wrote:
> Is this sstate safe?
>
> On Oct 30, 2016 9:11 PM, "Paul Eggleton" <paul.eggleton@linux.intel.com>
>
> wrote:
> > If you set LIC_FILES_CHKSUM to point to a relative symlink then you'll
> > get "Could not copy license file" warnings in copy_license_files() since
> > the symlink won't be valid after it's copied. If the source is a symlink
> > then we need to dereference it first.
> >
> > I encountered this when I used recipetool on the sources for capnproto,
> > where the c++ directory contains a LICENSE.txt symlink to the LICENSE
> > file in the parent directory, and this symlink ends up being pointed to
> > in LIC_FILES_CHKSUM.
> >
> > Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
> > ---
> >
> > meta/classes/license.bbclass | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git a/meta/classes/license.bbclass b/meta/classes/license.bbclass
> > index da4fc3e..660b85f 100644
> > --- a/meta/classes/license.bbclass
> > +++ b/meta/classes/license.bbclass
> >
> > @@ -351,6 +351,8 @@ def copy_license_files(lic_files_paths, destdir):
> > dst = os.path.join(destdir, basename)
> >
> > if os.path.exists(dst):
> > os.remove(dst)
> >
> > + if os.path.islink(src):
> > + src = os.path.realpath(src)
> >
> > canlink = os.access(src, os.W_OK) and (os.stat(src).st_dev ==
> >
> > os.stat(destdir).st_dev)
> >
> > if canlink:
> > try:
> > --
> > 2.5.5
> >
> > --
> > _______________________________________________
> > Openembedded-core mailing list
> > Openembedded-core@lists.openembedded.org
> > http://lists.openembedded.org/mailman/listinfo/openembedded-core
--
Paul Eggleton
Intel Open Source Technology Centre
^ permalink raw reply
* Re: [PATCH 1/7] classes/license: fix handling of symlinks pointed to in LIC_FILES_CHKSUM
From: Khem Raj @ 2016-10-31 19:23 UTC (permalink / raw)
To: Paul Eggleton; +Cc: Patches and discussions about the oe-core layer
In-Reply-To: <e1af68e680f3fbf20d7b0a8c55802a9cdd3f404b.1477886344.git.paul.eggleton@linux.intel.com>
[-- Attachment #1: Type: text/plain, Size: 1636 bytes --]
Is this sstate safe?
On Oct 30, 2016 9:11 PM, "Paul Eggleton" <paul.eggleton@linux.intel.com>
wrote:
> If you set LIC_FILES_CHKSUM to point to a relative symlink then you'll
> get "Could not copy license file" warnings in copy_license_files() since
> the symlink won't be valid after it's copied. If the source is a symlink
> then we need to dereference it first.
>
> I encountered this when I used recipetool on the sources for capnproto,
> where the c++ directory contains a LICENSE.txt symlink to the LICENSE
> file in the parent directory, and this symlink ends up being pointed to
> in LIC_FILES_CHKSUM.
>
> Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
> ---
> meta/classes/license.bbclass | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/meta/classes/license.bbclass b/meta/classes/license.bbclass
> index da4fc3e..660b85f 100644
> --- a/meta/classes/license.bbclass
> +++ b/meta/classes/license.bbclass
> @@ -351,6 +351,8 @@ def copy_license_files(lic_files_paths, destdir):
> dst = os.path.join(destdir, basename)
> if os.path.exists(dst):
> os.remove(dst)
> + if os.path.islink(src):
> + src = os.path.realpath(src)
> canlink = os.access(src, os.W_OK) and (os.stat(src).st_dev ==
> os.stat(destdir).st_dev)
> if canlink:
> try:
> --
> 2.5.5
>
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
[-- Attachment #2: Type: text/html, Size: 2334 bytes --]
^ permalink raw reply
* Re: [PATCH] cmake.bbclass: Exclude native sysroot from CMAKE_FIND_ROOT_PATH
From: Andreas Müller @ 2016-10-31 17:51 UTC (permalink / raw)
To: Khem Raj; +Cc: Patches and discussions about the oe-core layer
In-Reply-To: <CALbNGRTr4dVBSxrUCjFgNPRM8Hf4aQba6xqzz8WJOv4+-Qa-Uw@mail.gmail.com>
On Mon, Oct 31, 2016 at 6:49 PM, Andreas Müller
<schnitzeltony@googlemail.com> wrote:
> On Mon, Oct 31, 2016 at 5:25 PM, Khem Raj <raj.khem@gmail.com> wrote:
>>
>>> On Oct 31, 2016, at 5:48 AM, Andreas Müller <schnitzeltony@googlemail.com> wrote:
>>>
>>> On Sun, Oct 30, 2016 at 9:07 PM, Andreas Müller
>>> <schnitzeltony@googlemail.com> wrote:
>>>> On Sun, Oct 30, 2016 at 6:38 PM, Khem Raj <raj.khem@gmail.com> wrote:
>>>>> On Sun, Oct 30, 2016 at 6:34 AM, Andreas Müller
>>>>> <schnitzeltony@googlemail.com> wrote:
>>>>>> On Sat, Oct 29, 2016 at 10:47 AM, Khem Raj <raj.khem@gmail.com> wrote:
>>>>>>> This has been cause of issue where we were getting both usr/include
>>>>>>> dirs ( from target as well as native sysroot) added to compiler
>>>>>>> flags.
>>>>>>>
>>>>>>> CXX_INCLUDES in final flags.cmake would include
>>>>>>> -I<target-sysroot>/usr/include -I<native-sysroot>/usr/include
>>>>>>> most of the time it would work since headers are mostly
>>>>>>> common but netflix package failed to compile since one of
>>>>>>> the headers was including curl headers which it could not
>>>>>>> find in target sysroot and it went to next include path
>>>>>>> and found it in native sysroot which is not what we want
>>>>>>> when doing cross compile.
>>>>>>>
>>>>>>> As per https://cmake.org/Wiki/CMake_Cross_Compiling
>>>>>>> never search for programs in target sysroot but search
>>>>>>> for packages,libs,includes only.
>>>>>>>
>>>>>>> Signed-off-by: Khem Raj <raj.khem@gmail.com>
>>>>>>> ---
>>>>>>> meta/classes/cmake.bbclass | 3 ++-
>>>>>>> 1 file changed, 2 insertions(+), 1 deletion(-)
>>>>>>>
>>>>>>> diff --git a/meta/classes/cmake.bbclass b/meta/classes/cmake.bbclass
>>>>>>> index 3e762de..3e8df37 100644
>>>>>>> --- a/meta/classes/cmake.bbclass
>>>>>>> +++ b/meta/classes/cmake.bbclass
>>>>>>> @@ -25,6 +25,7 @@ OECMAKE_PERLNATIVE_DIR ??= ""
>>>>>>> OECMAKE_EXTRA_ROOT_PATH ?= ""
>>>>>>>
>>>>>>> OECMAKE_FIND_ROOT_PATH_MODE_PROGRAM = "ONLY"
>>>>>>> +OECMAKE_FIND_ROOT_PATH_MODE_PROGRAM_class-target = "NEVER"
>>>>>> ^ Split this into a second patch please you are changing two more or
>>>>>> less unrelated settings in one patch.
>>>>>
>>>>> These changes are related and should stay together in same patch
>>>>> otherwise it will break.
>>>>>
>>>>>>> OECMAKE_FIND_ROOT_PATH_MODE_PROGRAM_class-native = "BOTH"
>>>>>>>
>>>>>>> EXTRA_OECMAKE_append = " ${PACKAGECONFIG_CONFARGS}"
>>>>>>> @@ -60,7 +61,7 @@ set( CMAKE_CXX_LINK_FLAGS "${OECMAKE_CXX_LINK_FLAGS}" CACHE STRING "LDFLAGS" )
>>>>>>>
>>>>>>> # only search in the paths provided so cmake doesnt pick
>>>>>>> # up libraries and tools from the native build machine
>>>>>>> -set( CMAKE_FIND_ROOT_PATH ${STAGING_DIR_HOST} ${STAGING_DIR_NATIVE} ${CROSS_DIR} ${OECMAKE_PERLNATIVE_DIR} ${OECMAKE_EXTRA_ROOT_PATH} ${EXTERNAL_TOOLCHAIN})
>>>>>>> +set( CMAKE_FIND_ROOT_PATH ${STAGING_DIR_HOST} ${CROSS_DIR} ${OECMAKE_PERLNATIVE_DIR} ${OECMAKE_EXTRA_ROOT_PATH} ${EXTERNAL_TOOLCHAIN})
>>>>>> ^ Are you sure this doesn't break native builds? I am a bit scared: In
>>>>>> meta-qt5-extra I have lot's of native builds for build-helpers. KDE
>>>>>> guys seem to prefer this over shell scripts...
>>>>>
>>>>> It hasnt broken anything for my world builds thus far. I dont use
>>>>> meta-qt5-extras though. So testing help is welcome.
>>>> I'll give it a meta-qt5-extra world build and let you know
>>>>
>>> Huge fallout:
>>>
>>> /home/superandy/data/oe-core/sources/meta-qt5-extra/recipes-kde/kf5/tier1/karchive/karchive.bb:do_configure
>>> /home/superandy/data/oe-core/sources/meta-qt5-extra/recipes-kde/kf5/tier2/kdoctools/kdoctools-native.bb:do_configure
>>> /home/superandy/data/oe-core/sources/meta-qt5-extra/recipes-kde/kf5/tier1/kwindowsystem/kwindowsystem.bb:do_configure
>>> /home/superandy/data/oe-core/sources/meta-qt5-extra/recipes-kde/kf5/tier1/kcodecs/kcodecs.bb:do_configure
>>> /home/superandy/data/oe-core/sources/meta-qt5-extra/recipes-kde/kf5/tier1/kconfig/kconfig.bb:do_configure
>>> /home/superandy/data/oe-core/sources/meta-qt5-extra/recipes-kde/kf5/tier1/kguiaddons/kguiaddons.bb:do_configure
>>> /home/superandy/data/oe-core/sources/meta-qt5-extra/recipes-kde/kf5/tier1/kdbusaddons/kdbusaddons.bb:do_configure
>>> /home/superandy/data/oe-core/sources/meta-qt5-extra/recipes-kde/kf5/tier1/kitemviews/kitemviews.bb:do_configure
>>> /home/superandy/data/oe-core/sources/meta-qt5-extra/recipes-kde/kf5/tier1/attica/attica.bb:do_configure
>>> /home/superandy/data/oe-core/sources/meta-qt5-extra/recipes-kde/kf5/tier1/sonnet/sonnet.bb:do_configure
>>> /home/superandy/data/oe-core/sources/meta-qt5-extra/recipes-kde/kf5/tier1/kcoreaddons/kcoreaddons-native.bb:do_compile
>>> /home/superandy/data/oe-core/sources/meta-qt5-extra/recipes-kde/kf5/tier1/kidletime/kidletime.bb:do_configure
>>> /home/superandy/data/oe-core/sources/meta-qt5-extra/recipes-kde/kf5/tier1/kwayland/kwayland.bb:do_configure
>>> /home/superandy/data/oe-core/sources/meta-qt5-extra/recipes-lxqt/libqtxdg/libqtxdg_git.bb:do_configure
>>> /home/superandy/data/oe-core/sources/meta-qt5-extra/recipes-kde/kf5/tier1/threadweaver/threadweaver.bb:do_configure
>>> /home/superandy/data/oe-core/sources/meta-qt5-extra/recipes-kde/kf5/tier1/networkmanager-qt/networkmanager-qt.bb:do_configure
>>> /home/superandy/data/oe-core/sources/meta-qt5-extra/recipes-kde/kf5/tier1/kdnssd/kdnssd.bb:do_configure
>>> /home/superandy/data/oe-core/sources/meta-qt5-extra/recipes-kde/kf5/tier1/modemmanager-qt/modemmanager-qt.bb:do_configure
>>> /home/superandy/data/oe-core/sources/meta-qt5-extra/recipes-misc/recipes-multimedia/projectm/projectm_git.bb:do_configure
>>> /home/superandy/data/oe-core/sources/meta-qt5-extra/recipes-kde/kf5/tier1/kplotting/kplotting.bb:do_configure
>>> /home/superandy/data/oe-core/sources/meta-qt5-extra/recipes-kde/kf5/tier1/breeze-icons/breeze-icons.bb:do_configure
>>> /home/superandy/data/oe-core/sources/meta-qt5-extra/recipes-lxqt/compton-conf/compton-conf_git.bb:do_configure
>>> /home/superandy/data/oe-core/sources/meta-qt5-extra/recipes-lxqt/qterminal/qterminal_git.bb:do_configure
>>> /home/superandy/data/oe-core/sources/meta-qt5-extra/recipes-lxqt/obconf-qt/obconf-qt_git.bb:do_configure
>>> /home/superandy/data/oe-core/sources/meta-qt5-extra/recipes-misc/recipes-multimedia/mixxx/mixxx_git.bb:do_compile
>>
>>
>>>
>>> so please don't apply this one
>>
>> Not yet, but specify both native includedir and target includedir while building something is broken at core
>> that must be fixed in anycase. May be these fallouts are just latent issues that were papered over in past.
>> Can you upload the logs somewhere ?
>>
> Sorry I killed them - my harddisk is not able to keep much more than 2
> tmpdirs and I lost 1 day for this test already. I think the problem is
> that you want to kill references to includedir but you kill all
> references even those to native binaries addressed and required by
> cmake. These native binaries cannot be addressed anymore without
> searching in native sysroot and there is nothing wrong about it.
I was not precise enough: replace native binaries by native executables.
Andreas
^ permalink raw reply
* Re: [PATCH] cmake.bbclass: Exclude native sysroot from CMAKE_FIND_ROOT_PATH
From: Andreas Müller @ 2016-10-31 17:49 UTC (permalink / raw)
To: Khem Raj; +Cc: Patches and discussions about the oe-core layer
In-Reply-To: <582B4854-F54B-492A-8897-F09981AA23C1@gmail.com>
On Mon, Oct 31, 2016 at 5:25 PM, Khem Raj <raj.khem@gmail.com> wrote:
>
>> On Oct 31, 2016, at 5:48 AM, Andreas Müller <schnitzeltony@googlemail.com> wrote:
>>
>> On Sun, Oct 30, 2016 at 9:07 PM, Andreas Müller
>> <schnitzeltony@googlemail.com> wrote:
>>> On Sun, Oct 30, 2016 at 6:38 PM, Khem Raj <raj.khem@gmail.com> wrote:
>>>> On Sun, Oct 30, 2016 at 6:34 AM, Andreas Müller
>>>> <schnitzeltony@googlemail.com> wrote:
>>>>> On Sat, Oct 29, 2016 at 10:47 AM, Khem Raj <raj.khem@gmail.com> wrote:
>>>>>> This has been cause of issue where we were getting both usr/include
>>>>>> dirs ( from target as well as native sysroot) added to compiler
>>>>>> flags.
>>>>>>
>>>>>> CXX_INCLUDES in final flags.cmake would include
>>>>>> -I<target-sysroot>/usr/include -I<native-sysroot>/usr/include
>>>>>> most of the time it would work since headers are mostly
>>>>>> common but netflix package failed to compile since one of
>>>>>> the headers was including curl headers which it could not
>>>>>> find in target sysroot and it went to next include path
>>>>>> and found it in native sysroot which is not what we want
>>>>>> when doing cross compile.
>>>>>>
>>>>>> As per https://cmake.org/Wiki/CMake_Cross_Compiling
>>>>>> never search for programs in target sysroot but search
>>>>>> for packages,libs,includes only.
>>>>>>
>>>>>> Signed-off-by: Khem Raj <raj.khem@gmail.com>
>>>>>> ---
>>>>>> meta/classes/cmake.bbclass | 3 ++-
>>>>>> 1 file changed, 2 insertions(+), 1 deletion(-)
>>>>>>
>>>>>> diff --git a/meta/classes/cmake.bbclass b/meta/classes/cmake.bbclass
>>>>>> index 3e762de..3e8df37 100644
>>>>>> --- a/meta/classes/cmake.bbclass
>>>>>> +++ b/meta/classes/cmake.bbclass
>>>>>> @@ -25,6 +25,7 @@ OECMAKE_PERLNATIVE_DIR ??= ""
>>>>>> OECMAKE_EXTRA_ROOT_PATH ?= ""
>>>>>>
>>>>>> OECMAKE_FIND_ROOT_PATH_MODE_PROGRAM = "ONLY"
>>>>>> +OECMAKE_FIND_ROOT_PATH_MODE_PROGRAM_class-target = "NEVER"
>>>>> ^ Split this into a second patch please you are changing two more or
>>>>> less unrelated settings in one patch.
>>>>
>>>> These changes are related and should stay together in same patch
>>>> otherwise it will break.
>>>>
>>>>>> OECMAKE_FIND_ROOT_PATH_MODE_PROGRAM_class-native = "BOTH"
>>>>>>
>>>>>> EXTRA_OECMAKE_append = " ${PACKAGECONFIG_CONFARGS}"
>>>>>> @@ -60,7 +61,7 @@ set( CMAKE_CXX_LINK_FLAGS "${OECMAKE_CXX_LINK_FLAGS}" CACHE STRING "LDFLAGS" )
>>>>>>
>>>>>> # only search in the paths provided so cmake doesnt pick
>>>>>> # up libraries and tools from the native build machine
>>>>>> -set( CMAKE_FIND_ROOT_PATH ${STAGING_DIR_HOST} ${STAGING_DIR_NATIVE} ${CROSS_DIR} ${OECMAKE_PERLNATIVE_DIR} ${OECMAKE_EXTRA_ROOT_PATH} ${EXTERNAL_TOOLCHAIN})
>>>>>> +set( CMAKE_FIND_ROOT_PATH ${STAGING_DIR_HOST} ${CROSS_DIR} ${OECMAKE_PERLNATIVE_DIR} ${OECMAKE_EXTRA_ROOT_PATH} ${EXTERNAL_TOOLCHAIN})
>>>>> ^ Are you sure this doesn't break native builds? I am a bit scared: In
>>>>> meta-qt5-extra I have lot's of native builds for build-helpers. KDE
>>>>> guys seem to prefer this over shell scripts...
>>>>
>>>> It hasnt broken anything for my world builds thus far. I dont use
>>>> meta-qt5-extras though. So testing help is welcome.
>>> I'll give it a meta-qt5-extra world build and let you know
>>>
>> Huge fallout:
>>
>> /home/superandy/data/oe-core/sources/meta-qt5-extra/recipes-kde/kf5/tier1/karchive/karchive.bb:do_configure
>> /home/superandy/data/oe-core/sources/meta-qt5-extra/recipes-kde/kf5/tier2/kdoctools/kdoctools-native.bb:do_configure
>> /home/superandy/data/oe-core/sources/meta-qt5-extra/recipes-kde/kf5/tier1/kwindowsystem/kwindowsystem.bb:do_configure
>> /home/superandy/data/oe-core/sources/meta-qt5-extra/recipes-kde/kf5/tier1/kcodecs/kcodecs.bb:do_configure
>> /home/superandy/data/oe-core/sources/meta-qt5-extra/recipes-kde/kf5/tier1/kconfig/kconfig.bb:do_configure
>> /home/superandy/data/oe-core/sources/meta-qt5-extra/recipes-kde/kf5/tier1/kguiaddons/kguiaddons.bb:do_configure
>> /home/superandy/data/oe-core/sources/meta-qt5-extra/recipes-kde/kf5/tier1/kdbusaddons/kdbusaddons.bb:do_configure
>> /home/superandy/data/oe-core/sources/meta-qt5-extra/recipes-kde/kf5/tier1/kitemviews/kitemviews.bb:do_configure
>> /home/superandy/data/oe-core/sources/meta-qt5-extra/recipes-kde/kf5/tier1/attica/attica.bb:do_configure
>> /home/superandy/data/oe-core/sources/meta-qt5-extra/recipes-kde/kf5/tier1/sonnet/sonnet.bb:do_configure
>> /home/superandy/data/oe-core/sources/meta-qt5-extra/recipes-kde/kf5/tier1/kcoreaddons/kcoreaddons-native.bb:do_compile
>> /home/superandy/data/oe-core/sources/meta-qt5-extra/recipes-kde/kf5/tier1/kidletime/kidletime.bb:do_configure
>> /home/superandy/data/oe-core/sources/meta-qt5-extra/recipes-kde/kf5/tier1/kwayland/kwayland.bb:do_configure
>> /home/superandy/data/oe-core/sources/meta-qt5-extra/recipes-lxqt/libqtxdg/libqtxdg_git.bb:do_configure
>> /home/superandy/data/oe-core/sources/meta-qt5-extra/recipes-kde/kf5/tier1/threadweaver/threadweaver.bb:do_configure
>> /home/superandy/data/oe-core/sources/meta-qt5-extra/recipes-kde/kf5/tier1/networkmanager-qt/networkmanager-qt.bb:do_configure
>> /home/superandy/data/oe-core/sources/meta-qt5-extra/recipes-kde/kf5/tier1/kdnssd/kdnssd.bb:do_configure
>> /home/superandy/data/oe-core/sources/meta-qt5-extra/recipes-kde/kf5/tier1/modemmanager-qt/modemmanager-qt.bb:do_configure
>> /home/superandy/data/oe-core/sources/meta-qt5-extra/recipes-misc/recipes-multimedia/projectm/projectm_git.bb:do_configure
>> /home/superandy/data/oe-core/sources/meta-qt5-extra/recipes-kde/kf5/tier1/kplotting/kplotting.bb:do_configure
>> /home/superandy/data/oe-core/sources/meta-qt5-extra/recipes-kde/kf5/tier1/breeze-icons/breeze-icons.bb:do_configure
>> /home/superandy/data/oe-core/sources/meta-qt5-extra/recipes-lxqt/compton-conf/compton-conf_git.bb:do_configure
>> /home/superandy/data/oe-core/sources/meta-qt5-extra/recipes-lxqt/qterminal/qterminal_git.bb:do_configure
>> /home/superandy/data/oe-core/sources/meta-qt5-extra/recipes-lxqt/obconf-qt/obconf-qt_git.bb:do_configure
>> /home/superandy/data/oe-core/sources/meta-qt5-extra/recipes-misc/recipes-multimedia/mixxx/mixxx_git.bb:do_compile
>
>
>>
>> so please don't apply this one
>
> Not yet, but specify both native includedir and target includedir while building something is broken at core
> that must be fixed in anycase. May be these fallouts are just latent issues that were papered over in past.
> Can you upload the logs somewhere ?
>
Sorry I killed them - my harddisk is not able to keep much more than 2
tmpdirs and I lost 1 day for this test already. I think the problem is
that you want to kill references to includedir but you kill all
references even those to native binaries addressed and required by
cmake. These native binaries cannot be addressed anymore without
searching in native sysroot and there is nothing wrong about it.
Andreas
^ permalink raw reply
* Re: [PATCH v2 1/1] package.bbclass: Remove unused variables and imports
From: Burton, Ross @ 2016-10-31 17:04 UTC (permalink / raw)
To: Ulf Magnusson; +Cc: OE-core
In-Reply-To: <1477503544-13794-2-git-send-email-ulfalizer@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 447 bytes --]
On 26 October 2016 at 18:39, Ulf Magnusson <ulfalizer@gmail.com> wrote:
> # Skip it if the target doesn't exist
> try:
> - s = os.stat(fpath)
> + os.stat(fpath)
> except OSError as e:
> (err, strerror) = e.args
> if err != errno.ENOENT:
>
Urgh, why not just use os.path.lexists()... Can you change the code to do
that?
Ross
[-- Attachment #2: Type: text/html, Size: 920 bytes --]
^ permalink raw reply
* Re: [PATCH 1/7] classes/license: fix handling of symlinks pointed to in LIC_FILES_CHKSUM
From: Martin Jansa @ 2016-10-31 16:56 UTC (permalink / raw)
To: Paul Eggleton; +Cc: openembedded-core
In-Reply-To: <e1af68e680f3fbf20d7b0a8c55802a9cdd3f404b.1477886344.git.paul.eggleton@linux.intel.com>
[-- Attachment #1: Type: text/plain, Size: 1749 bytes --]
On Mon, Oct 31, 2016 at 04:59:43PM +1300, Paul Eggleton wrote:
> If you set LIC_FILES_CHKSUM to point to a relative symlink then you'll
> get "Could not copy license file" warnings in copy_license_files() since
> the symlink won't be valid after it's copied. If the source is a symlink
> then we need to dereference it first.
>
> I encountered this when I used recipetool on the sources for capnproto,
> where the c++ directory contains a LICENSE.txt symlink to the LICENSE
> file in the parent directory, and this symlink ends up being pointed to
> in LIC_FILES_CHKSUM.
Acked-by: Martin Jansa <Martin.Jansa@gmail.com>
Please cherry-pick this to morty as well.
> Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
> ---
> meta/classes/license.bbclass | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/meta/classes/license.bbclass b/meta/classes/license.bbclass
> index da4fc3e..660b85f 100644
> --- a/meta/classes/license.bbclass
> +++ b/meta/classes/license.bbclass
> @@ -351,6 +351,8 @@ def copy_license_files(lic_files_paths, destdir):
> dst = os.path.join(destdir, basename)
> if os.path.exists(dst):
> os.remove(dst)
> + if os.path.islink(src):
> + src = os.path.realpath(src)
> canlink = os.access(src, os.W_OK) and (os.stat(src).st_dev == os.stat(destdir).st_dev)
> if canlink:
> try:
> --
> 2.5.5
>
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
--
Martin 'JaMa' Jansa jabber: Martin.Jansa@gmail.com
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 169 bytes --]
^ permalink raw reply
* [PATCH 2/2] slang: clean up options and dependencies
From: Ross Burton @ 2016-10-31 16:48 UTC (permalink / raw)
To: openembedded-core
In-Reply-To: <1477932495-21204-1-git-send-email-ross.burton@intel.com>
The AC_PATH_XTRA check for X11 headers is never actually used, so patch that out
and remove the options in EXTRA_OECONF.
Move pcre/png/zlib toggles to PACKAGECONFIG, retaining the behaviour that only
PCRE is enabled by default.
Add missing libiconv dependency.
Signed-off-by: Ross Burton <ross.burton@intel.com>
---
meta/recipes-extended/slang/slang/no-x.patch | 14 ++++++++++++++
meta/recipes-extended/slang/slang_2.3.0.bb | 15 ++++++++++-----
2 files changed, 24 insertions(+), 5 deletions(-)
create mode 100644 meta/recipes-extended/slang/slang/no-x.patch
diff --git a/meta/recipes-extended/slang/slang/no-x.patch b/meta/recipes-extended/slang/slang/no-x.patch
new file mode 100644
index 0000000..d7666bf
--- /dev/null
+++ b/meta/recipes-extended/slang/slang/no-x.patch
@@ -0,0 +1,14 @@
+There's no need to check for the X libraries as the socket module doesn't use
+anything from X.
+
+Upstream-Status: Pending
+Signed-off-by: Ross Burton <ross.burton@intel.com>
+
+diff --git a/autoconf/configure.ac b/autoconf/configure.ac
+index b61e974..a3e5db2 100644
+--- a/autoconf/configure.ac
++++ b/autoconf/configure.ac
+@@ -72,3 +71,0 @@ AC_SUBST(LIB_READLINE)
+-# For the socket module
+-AC_PATH_XTRA
+-
diff --git a/meta/recipes-extended/slang/slang_2.3.0.bb b/meta/recipes-extended/slang/slang_2.3.0.bb
index ce7b16a..52b2a63 100644
--- a/meta/recipes-extended/slang/slang_2.3.0.bb
+++ b/meta/recipes-extended/slang/slang_2.3.0.bb
@@ -9,7 +9,7 @@ to recode S-Lang procedures in C if you need to."
HOMEPAGE = "http://www.jedsoft.org/slang/"
SECTION = "libs"
-DEPENDS = "pcre ncurses"
+DEPENDS = "ncurses virtual/libiconv"
LICENSE = "GPLv2"
LIC_FILES_CHKSUM = "file://COPYING;md5=a52a18a472d4f7e45479b06563717c02"
@@ -20,18 +20,23 @@ SRC_URI = "http://www.jedsoft.org/releases/${BPN}/${BP}.tar.bz2 \
file://fix-check-pcre.patch \
file://slang-fix-the-iconv-existence-checking.patch \
file://0001-Fix-error-conflicting-types-for-posix_close.patch \
+ file://no-x.patch \
"
+SRC_URI[md5sum] = "3bcc790460d52db1316c20395b7ac2f1"
+SRC_URI[sha256sum] = "f95224060f45e0d8212a5039b339afa5f1a94a1bb0298e796104e5b12e926129"
+
UPSTREAM_CHECK_URI = "http://www.jedsoft.org/releases/slang/"
PREMIRRORS_append = "\n http://www.jedsoft.org/releases/slang/.* http://www.jedsoft.org/releases/slang/old/ \n"
inherit autotools-brokensep
-
CLEANBROKEN = "1"
-SRC_URI[md5sum] = "3bcc790460d52db1316c20395b7ac2f1"
-SRC_URI[sha256sum] = "f95224060f45e0d8212a5039b339afa5f1a94a1bb0298e796104e5b12e926129"
+EXTRA_OECONF = "--without-onig"
-EXTRA_OECONF += " --without-z --without-png --without-onig --x-includes=${STAGING_DIR_HOST}/usr/include/X11 --x-libraries=${STAGING_DIR_HOST}/usr/lib"
+PACKAGECONFIG ??= "pcre"
+PACKAGECONFIG[pcre] = "--with-pcre,--without-pcre,pcre"
+PACKAGECONFIG[png] = "--with-png,--without-png,libpng"
+PACKAGECONFIG[zlib] = "--with-z,--without-z,zlib"
do_configure_prepend() {
# slang keeps configure.ac and rest of autoconf files in autoconf/ directory
--
2.8.1
^ permalink raw reply related
* [PATCH 1/2] slang: add PREMIRRORS to handle upstream moving tarballs
From: Ross Burton @ 2016-10-31 16:48 UTC (permalink / raw)
To: openembedded-core
The slang maintainer only puts the current release at
jedsoft.org/releases/slang/slang-1.2.3.tar.bz2, all previous releases are moved
into /releases/slang/old/.
As this breaks the fetch the moment a new version is released, use PREMIRRORS to
also look in the /old/ directory.
Signed-off-by: Ross Burton <ross.burton@intel.com>
---
meta/recipes-extended/slang/slang_2.3.0.bb | 1 +
1 file changed, 1 insertion(+)
diff --git a/meta/recipes-extended/slang/slang_2.3.0.bb b/meta/recipes-extended/slang/slang_2.3.0.bb
index 17efbbe..ce7b16a 100644
--- a/meta/recipes-extended/slang/slang_2.3.0.bb
+++ b/meta/recipes-extended/slang/slang_2.3.0.bb
@@ -22,6 +22,7 @@ SRC_URI = "http://www.jedsoft.org/releases/${BPN}/${BP}.tar.bz2 \
file://0001-Fix-error-conflicting-types-for-posix_close.patch \
"
UPSTREAM_CHECK_URI = "http://www.jedsoft.org/releases/slang/"
+PREMIRRORS_append = "\n http://www.jedsoft.org/releases/slang/.* http://www.jedsoft.org/releases/slang/old/ \n"
inherit autotools-brokensep
--
2.8.1
^ permalink raw reply related
* Re: should a "*git.bb" recipe lock that recipe to a fixed version?
From: Khem Raj @ 2016-10-31 16:31 UTC (permalink / raw)
To: Robert P. J. Day; +Cc: Christopher Larson, OE Core mailing list
In-Reply-To: <alpine.LFD.2.20.1610310223510.6909@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 2551 bytes --]
> On Oct 30, 2016, at 11:29 PM, Robert P. J. Day <rpjday@crashcourse.ca> wrote:
>
> On Sun, 30 Oct 2016, Khem Raj wrote:
>
>> On Oct 30, 2016, at 4:36 PM, Burton, Ross <ross.burton@intel.com> wrote:
>>
>> On 30 October 2016 at 17:35, Robert P. J. Day <rpjday@crashcourse.ca> wrote:
>> fair enough ... i'm embarrassed to admit i didn't really understand
>> the versioning selection so i'm going to examine it way more carefully
>> now. i wonder how many recipes in oe-core are "_git" recipes that, in
>> the end, just lock down to a specific version. as you say, i was a bit
>> surprised.
>>
>> Personally I've been endorsing the practise where _git.bb is only
>> used for recipes that are actually tracking git development
>> branches, and if it's just a release that it simply fetched over git
>> via a SHA of a release tag then the recipe should be _1.2.3.bb for
>> clarity.
>>
>> with a system integrators hat on I agree. With developer hat on I do not.
>
> khem:
>
> could you expand on that? now that i understand how the versioning
> works, i'll be more careful in the future, but it's still misleading
> for a "_git"-named recipe file to be locked to a particular version.
>
> AFAICT, there are plenty of OE recipes that download via git, but
> are still named as being version locked. eg, here's
> meta/recipes-devtools/file/file_5.28.bb:
>
> SRC_URI = "git://github.com/file/file.git \
> file://debian-742262.patch \
> file://0001-Add-P-prompt-into-Usage-info.patch \
> "
>
> SRCREV = "3c521817322a6bf5160cfeb09b9145ccde587b2a"
>
> i'm assuming that that particular SRCREV corresponds to release
> version 5,28, so that makes perfect sense.
for traversing the git history file renaming doesnt work well
so when you want to use git log you get a distorted view unless you
use —follow option.
If we want to have a systematic way of flagging a package being locked ( foo_x.y.z.bb)
versus one using AUTOREV ( foo_git.bb), it will be fine and become
more useful.
>
> rday
>
> --
>
> ========================================================================
> Robert P. J. Day Ottawa, Ontario, CANADA
> http://crashcourse.ca
>
> Twitter: http://twitter.com/rpjday
> LinkedIn: http://ca.linkedin.com/in/rpjday
> ========================================================================
[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 211 bytes --]
^ permalink raw reply
* Re: [PATCH] cmake.bbclass: Exclude native sysroot from CMAKE_FIND_ROOT_PATH
From: Khem Raj @ 2016-10-31 16:25 UTC (permalink / raw)
To: Andreas Müller; +Cc: Patches and discussions about the oe-core layer
In-Reply-To: <CALbNGRRcthK1Vpp-Yx90hN9TjAHexgY3cVbJC3fgvcLtfoM4MA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 6381 bytes --]
> On Oct 31, 2016, at 5:48 AM, Andreas Müller <schnitzeltony@googlemail.com> wrote:
>
> On Sun, Oct 30, 2016 at 9:07 PM, Andreas Müller
> <schnitzeltony@googlemail.com> wrote:
>> On Sun, Oct 30, 2016 at 6:38 PM, Khem Raj <raj.khem@gmail.com> wrote:
>>> On Sun, Oct 30, 2016 at 6:34 AM, Andreas Müller
>>> <schnitzeltony@googlemail.com> wrote:
>>>> On Sat, Oct 29, 2016 at 10:47 AM, Khem Raj <raj.khem@gmail.com> wrote:
>>>>> This has been cause of issue where we were getting both usr/include
>>>>> dirs ( from target as well as native sysroot) added to compiler
>>>>> flags.
>>>>>
>>>>> CXX_INCLUDES in final flags.cmake would include
>>>>> -I<target-sysroot>/usr/include -I<native-sysroot>/usr/include
>>>>> most of the time it would work since headers are mostly
>>>>> common but netflix package failed to compile since one of
>>>>> the headers was including curl headers which it could not
>>>>> find in target sysroot and it went to next include path
>>>>> and found it in native sysroot which is not what we want
>>>>> when doing cross compile.
>>>>>
>>>>> As per https://cmake.org/Wiki/CMake_Cross_Compiling
>>>>> never search for programs in target sysroot but search
>>>>> for packages,libs,includes only.
>>>>>
>>>>> Signed-off-by: Khem Raj <raj.khem@gmail.com>
>>>>> ---
>>>>> meta/classes/cmake.bbclass | 3 ++-
>>>>> 1 file changed, 2 insertions(+), 1 deletion(-)
>>>>>
>>>>> diff --git a/meta/classes/cmake.bbclass b/meta/classes/cmake.bbclass
>>>>> index 3e762de..3e8df37 100644
>>>>> --- a/meta/classes/cmake.bbclass
>>>>> +++ b/meta/classes/cmake.bbclass
>>>>> @@ -25,6 +25,7 @@ OECMAKE_PERLNATIVE_DIR ??= ""
>>>>> OECMAKE_EXTRA_ROOT_PATH ?= ""
>>>>>
>>>>> OECMAKE_FIND_ROOT_PATH_MODE_PROGRAM = "ONLY"
>>>>> +OECMAKE_FIND_ROOT_PATH_MODE_PROGRAM_class-target = "NEVER"
>>>> ^ Split this into a second patch please you are changing two more or
>>>> less unrelated settings in one patch.
>>>
>>> These changes are related and should stay together in same patch
>>> otherwise it will break.
>>>
>>>>> OECMAKE_FIND_ROOT_PATH_MODE_PROGRAM_class-native = "BOTH"
>>>>>
>>>>> EXTRA_OECMAKE_append = " ${PACKAGECONFIG_CONFARGS}"
>>>>> @@ -60,7 +61,7 @@ set( CMAKE_CXX_LINK_FLAGS "${OECMAKE_CXX_LINK_FLAGS}" CACHE STRING "LDFLAGS" )
>>>>>
>>>>> # only search in the paths provided so cmake doesnt pick
>>>>> # up libraries and tools from the native build machine
>>>>> -set( CMAKE_FIND_ROOT_PATH ${STAGING_DIR_HOST} ${STAGING_DIR_NATIVE} ${CROSS_DIR} ${OECMAKE_PERLNATIVE_DIR} ${OECMAKE_EXTRA_ROOT_PATH} ${EXTERNAL_TOOLCHAIN})
>>>>> +set( CMAKE_FIND_ROOT_PATH ${STAGING_DIR_HOST} ${CROSS_DIR} ${OECMAKE_PERLNATIVE_DIR} ${OECMAKE_EXTRA_ROOT_PATH} ${EXTERNAL_TOOLCHAIN})
>>>> ^ Are you sure this doesn't break native builds? I am a bit scared: In
>>>> meta-qt5-extra I have lot's of native builds for build-helpers. KDE
>>>> guys seem to prefer this over shell scripts...
>>>
>>> It hasnt broken anything for my world builds thus far. I dont use
>>> meta-qt5-extras though. So testing help is welcome.
>> I'll give it a meta-qt5-extra world build and let you know
>>
> Huge fallout:
>
> /home/superandy/data/oe-core/sources/meta-qt5-extra/recipes-kde/kf5/tier1/karchive/karchive.bb:do_configure
> /home/superandy/data/oe-core/sources/meta-qt5-extra/recipes-kde/kf5/tier2/kdoctools/kdoctools-native.bb:do_configure
> /home/superandy/data/oe-core/sources/meta-qt5-extra/recipes-kde/kf5/tier1/kwindowsystem/kwindowsystem.bb:do_configure
> /home/superandy/data/oe-core/sources/meta-qt5-extra/recipes-kde/kf5/tier1/kcodecs/kcodecs.bb:do_configure
> /home/superandy/data/oe-core/sources/meta-qt5-extra/recipes-kde/kf5/tier1/kconfig/kconfig.bb:do_configure
> /home/superandy/data/oe-core/sources/meta-qt5-extra/recipes-kde/kf5/tier1/kguiaddons/kguiaddons.bb:do_configure
> /home/superandy/data/oe-core/sources/meta-qt5-extra/recipes-kde/kf5/tier1/kdbusaddons/kdbusaddons.bb:do_configure
> /home/superandy/data/oe-core/sources/meta-qt5-extra/recipes-kde/kf5/tier1/kitemviews/kitemviews.bb:do_configure
> /home/superandy/data/oe-core/sources/meta-qt5-extra/recipes-kde/kf5/tier1/attica/attica.bb:do_configure
> /home/superandy/data/oe-core/sources/meta-qt5-extra/recipes-kde/kf5/tier1/sonnet/sonnet.bb:do_configure
> /home/superandy/data/oe-core/sources/meta-qt5-extra/recipes-kde/kf5/tier1/kcoreaddons/kcoreaddons-native.bb:do_compile
> /home/superandy/data/oe-core/sources/meta-qt5-extra/recipes-kde/kf5/tier1/kidletime/kidletime.bb:do_configure
> /home/superandy/data/oe-core/sources/meta-qt5-extra/recipes-kde/kf5/tier1/kwayland/kwayland.bb:do_configure
> /home/superandy/data/oe-core/sources/meta-qt5-extra/recipes-lxqt/libqtxdg/libqtxdg_git.bb:do_configure
> /home/superandy/data/oe-core/sources/meta-qt5-extra/recipes-kde/kf5/tier1/threadweaver/threadweaver.bb:do_configure
> /home/superandy/data/oe-core/sources/meta-qt5-extra/recipes-kde/kf5/tier1/networkmanager-qt/networkmanager-qt.bb:do_configure
> /home/superandy/data/oe-core/sources/meta-qt5-extra/recipes-kde/kf5/tier1/kdnssd/kdnssd.bb:do_configure
> /home/superandy/data/oe-core/sources/meta-qt5-extra/recipes-kde/kf5/tier1/modemmanager-qt/modemmanager-qt.bb:do_configure
> /home/superandy/data/oe-core/sources/meta-qt5-extra/recipes-misc/recipes-multimedia/projectm/projectm_git.bb:do_configure
> /home/superandy/data/oe-core/sources/meta-qt5-extra/recipes-kde/kf5/tier1/kplotting/kplotting.bb:do_configure
> /home/superandy/data/oe-core/sources/meta-qt5-extra/recipes-kde/kf5/tier1/breeze-icons/breeze-icons.bb:do_configure
> /home/superandy/data/oe-core/sources/meta-qt5-extra/recipes-lxqt/compton-conf/compton-conf_git.bb:do_configure
> /home/superandy/data/oe-core/sources/meta-qt5-extra/recipes-lxqt/qterminal/qterminal_git.bb:do_configure
> /home/superandy/data/oe-core/sources/meta-qt5-extra/recipes-lxqt/obconf-qt/obconf-qt_git.bb:do_configure
> /home/superandy/data/oe-core/sources/meta-qt5-extra/recipes-misc/recipes-multimedia/mixxx/mixxx_git.bb:do_compile
>
> so please don't apply this one
Not yet, but specify both native includedir and target includedir while building something is broken at core
that must be fixed in anycase. May be these fallouts are just latent issues that were papered over in past.
Can you upload the logs somewhere ?
>
> Andreas
[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 211 bytes --]
^ permalink raw reply
* Re: [PATCH] boost: Fix SRC_URI checksums
From: Khem Raj @ 2016-10-31 16:22 UTC (permalink / raw)
To: Alexander Kanavin; +Cc: openembedded-core
In-Reply-To: <6a58f235-b235-f25c-b068-fe0c84cf4915@linux.intel.com>
[-- Attachment #1: Type: text/plain, Size: 991 bytes --]
> On Oct 31, 2016, at 5:53 AM, Alexander Kanavin <alexander.kanavin@linux.intel.com> wrote:
>
> On 10/31/2016 05:45 AM, Paul Eggleton wrote:
>>> Alex, any idea what's happened here? Do you have the originals from when you
>>> did the upgrade?
>>
>> Hmm, it seems we aren't the only ones to have hit this:
>>
>> http://osdir.com/ml/blfs-dev/2016-10/msg00013.html
>>
>> That said, I still don't think we should blindly trust the latest archives
>> until we're sure of what the differences are.
>
> Sourceforge is doing too-clever redirecting that fails miserably here:
>
> Proxy request sent, awaiting response... 301 Moved Permanently
> Location: http://downloads.sourceforge.net/project/boost/boost/snapshots/master/boost_1_62_0.tar.bz2 [following]
>
> So we've been fetching a moving master snapshot all along. Patch is coming shortly.
we should specify boost/boost/1.62.0/boost_1_62_0.tar.bz2 instead of boost/boost/boost_1_62_0.tar.bz2
>
> Alex
>
[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 211 bytes --]
^ permalink raw reply
* [PATCH 1/1] oe/copy_buildsystem.py: dereference symlink
From: Robert Yang @ 2016-10-31 15:48 UTC (permalink / raw)
To: openembedded-core
In-Reply-To: <cover.1477928374.git.liezhi.yang@windriver.com>
When there is a relative symlink in the layer, for example:
symA -> ../out/of/layer/file
symA will be invalid fater copied, it would be invalid from build time
if it points to a relative path, and would be invalid after extracted
the sdk if it points to a absolute py. Dereference symlink when copy
will fix the problem.
Use tar rather than shutil.copytree() to copy is because:
1) shutil.copytree(symlinks=Fasle) has bugs when dereference symlinks:
https://bugs.python.org/issue21697
And Ubunutu 1404 doesn't upgrade python3 to fix the problem.
2) shutil.copytree(symlinks=False) raises errors when there is a invalid
symlink, and tar just prints a warning, tar is preferred here since
the real world is unpredicatable
3) tar is faster than shutil.copytree() as said by oe.path.copytree()
So use tar to copy.
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
---
meta/lib/oe/copy_buildsystem.py | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/meta/lib/oe/copy_buildsystem.py b/meta/lib/oe/copy_buildsystem.py
index afaff68..29ac6d4 100644
--- a/meta/lib/oe/copy_buildsystem.py
+++ b/meta/lib/oe/copy_buildsystem.py
@@ -4,11 +4,15 @@ import stat
import shutil
def _smart_copy(src, dest):
+ import subprocess
# smart_copy will choose the correct function depending on whether the
# source is a file or a directory.
mode = os.stat(src).st_mode
if stat.S_ISDIR(mode):
- shutil.copytree(src, dest, symlinks=True, ignore=shutil.ignore_patterns('.git'))
+ bb.utils.mkdirhier(dest)
+ cmd = "tar --exclude='.git' --xattrs --xattrs-include='*' -chf - -C %s -p . \
+ | tar --xattrs --xattrs-include='*' -xf - -C %s" % (src, dest)
+ subprocess.check_output(cmd, shell=True, stderr=subprocess.STDOUT)
else:
shutil.copyfile(src, dest)
shutil.copymode(src, dest)
--
2.9.0
^ permalink raw reply related
* [PATCH 0/1] oe/copy_buildsystem.py: dereference symlink
From: Robert Yang @ 2016-10-31 15:48 UTC (permalink / raw)
To: openembedded-core
The following changes since commit 42b4fa2f923244bc047874752d2e0381ff6f0a25:
boost: fix the SRC_URI to point to an actual release, and not a master snapshot (2016-10-31 14:23:04 +0000)
are available in the git repository at:
git://git.openembedded.org/openembedded-core-contrib rbt/cp
http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=rbt/cp
Robert Yang (1):
oe/copy_buildsystem.py: dereference symlink
meta/lib/oe/copy_buildsystem.py | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
--
2.9.0
^ permalink raw reply
* Re: [PATCH 1/4] u-boot: Update to 2016.09.01 release
From: Burton, Ross @ 2016-10-31 14:59 UTC (permalink / raw)
To: Marek Vasut; +Cc: OE-core
In-Reply-To: <7cf154dd-ce37-d648-4f56-636e82a197c0@denx.de>
[-- Attachment #1: Type: text/plain, Size: 323 bytes --]
On 30 October 2016 at 18:18, Marek Vasut <marex@denx.de> wrote:
> So the simplest test would be to do the build of native u-boot-mkimage
> on, say, centos/fedora ?
>
No, a build on Debian (I've just replicated this on my own debian build
machine). Literally just "bitbake u-boot-mkimage" fails to build.
Ross
[-- Attachment #2: Type: text/html, Size: 735 bytes --]
^ permalink raw reply
* Re: [PATCHv2 24/26] lttng-tools: do not install manpages in ptest package
From: Alexander Kanavin @ 2016-10-31 13:43 UTC (permalink / raw)
To: Nathan Lynch; +Cc: openembedded-core
In-Reply-To: <c39f2013-9bad-9e64-d2b8-721db94001a0@mentor.com>
On 10/28/2016 09:46 PM, Nathan Lynch wrote:
> This actually breaks running the lttng-tools test suite on the target:
>
> root@qemux86-64:/usr/lib/lttng-tools/ptest# cat run-ptest
> #!/bin/sh
> # Without --ignore-exit, the tap harness causes any FAILs within a
> # test plan to raise ERRORs; this is just noise.
> makeargs="LOG_DRIVER_FLAGS=--ignore-exit"
> make -t all >/dev/null 2>&1 && exec make -s $makeargs check 2>/dev/null
>
> root@qemux86-64:/usr/lib/lttng-tools/ptest# sh -x run-ptest
> + makeargs=LOG_DRIVER_FLAGS=--ignore-exit
> + make -t all
>
> root@qemux86-64:/usr/lib/lttng-tools/ptest# echo $?
> 2
>
> root@qemux86-64:/usr/lib/lttng-tools/ptest# make -s -t all
> make[2]: *** No rule to make target 'lttng-health-check.3', needed by
> 'all-am'. Stop.
> make[1]: *** [Makefile:537: all-recursive] Error 1
> make: *** [Makefile:570: all-recursive] Error 1
>
>
> I'd rather see "do not install shared libraries in ptest package" go in
> first as it fixes an existing problem without regressing lttng-tools-ptest.
>
> I'm looking at reworking do_install_ptest to do a selective copy, as you
> suggested earlier, so maybe just drop this patch?
Thanks for checking. This hasn't yet made it to master, so it could
simply be dropped from master-next. If this doesn't happen, I'll submit
a revertion patch.
Alex
^ permalink raw reply
* [PATCH 3/3] distcc: Don't remove users/groups in postrm
From: Jussi Kukkonen @ 2016-10-31 13:40 UTC (permalink / raw)
To: openembedded-core
In-Reply-To: <cover.1477914497.git.jussi.kukkonen@intel.com>
There's no way to ensure that files owned by the users aren't left
on the system at postrm time: Removing the user would mean those
files are now owned by a non-existing user, and later may be owned
by a completely unrelated new user.
Signed-off-by: Jussi Kukkonen <jussi.kukkonen@intel.com>
---
meta/recipes-devtools/distcc/distcc_3.2.bb | 4 ----
1 file changed, 4 deletions(-)
diff --git a/meta/recipes-devtools/distcc/distcc_3.2.bb b/meta/recipes-devtools/distcc/distcc_3.2.bb
index c084ad2..ea3d7c1 100644
--- a/meta/recipes-devtools/distcc/distcc_3.2.bb
+++ b/meta/recipes-devtools/distcc/distcc_3.2.bb
@@ -65,7 +65,3 @@ FILES_${PN} = " ${sysconfdir} \
${systemd_unitdir}/system/distcc.service"
FILES_distcc-distmon-gnome = " ${bindir}/distccmon-gnome \
${datadir}/distcc"
-
-pkg_postrm_${PN} () {
- deluser distcc || true
-}
--
2.1.4
^ permalink raw reply related
* [PATCH 2/3] avahi: Don't remove users/groups in postrm
From: Jussi Kukkonen @ 2016-10-31 13:40 UTC (permalink / raw)
To: openembedded-core
In-Reply-To: <cover.1477914497.git.jussi.kukkonen@intel.com>
There's no way to ensure that files owned by the users aren't left
on the system at postrm time: Removing the user would mean those
files are now owned by a non-existing user, and later may be owned
by a completely unrelated new user.
[YOCTO #10442]
Signed-off-by: Jussi Kukkonen <jussi.kukkonen@intel.com>
---
meta/recipes-connectivity/avahi/avahi.inc | 10 ----------
1 file changed, 10 deletions(-)
diff --git a/meta/recipes-connectivity/avahi/avahi.inc b/meta/recipes-connectivity/avahi/avahi.inc
index cb36802..faa8741 100644
--- a/meta/recipes-connectivity/avahi/avahi.inc
+++ b/meta/recipes-connectivity/avahi/avahi.inc
@@ -153,13 +153,3 @@ if [ -z "$D" ]; then
killall -q -HUP dbus-daemon || true
fi
}
-
-pkg_postrm_avahi-daemon () {
- deluser avahi || true
- delgroup avahi || true
-}
-
-pkg_postrm_avahi-autoipd () {
- deluser avahi-autoipd || true
- delgroup avahi-autoipd || true
-}
--
2.1.4
^ permalink raw reply related
* [PATCH 1/3] e2fsprogs: Depend on attr
From: Jussi Kukkonen @ 2016-10-31 13:40 UTC (permalink / raw)
To: openembedded-core
In-Reply-To: <cover.1477914497.git.jussi.kukkonen@intel.com>
e2fsprogs builds fine with or without attr but it's possible to
end up with this sequence:
* e2fsprogs configure finds attr/xattr.h (coming from sstate)
* attr starts rebuild, attr/xattr.h is removed from sysroot
* e2fsprogs compile fails: "attr/xattr.h: No such file or directory"
Depend on attr to ensure reproducible build.
Signed-off-by: Jussi Kukkonen <jussi.kukkonen@intel.com>
---
meta/recipes-devtools/e2fsprogs/e2fsprogs.inc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/recipes-devtools/e2fsprogs/e2fsprogs.inc b/meta/recipes-devtools/e2fsprogs/e2fsprogs.inc
index 74e92f6..81d90a1 100644
--- a/meta/recipes-devtools/e2fsprogs/e2fsprogs.inc
+++ b/meta/recipes-devtools/e2fsprogs/e2fsprogs.inc
@@ -17,7 +17,7 @@ LIC_FILES_CHKSUM = "file://NOTICE;md5=b48f21d765b875bd10400975d12c1ca2 \
file://lib/et/et_name.c;beginline=1;endline=11;md5=ead236447dac7b980dbc5b4804d8c836 \
file://lib/ss/ss.h;beginline=1;endline=20;md5=6e89ad47da6e75fecd2b5e0e81e1d4a6"
SECTION = "base"
-DEPENDS = "util-linux"
+DEPENDS = "util-linux attr"
SRC_URI = "git://git.kernel.org/pub/scm/fs/ext2/e2fsprogs.git"
S = "${WORKDIR}/git"
--
2.1.4
^ permalink raw reply related
* [PATCH 0/3] Recipe bug fixes
From: Jussi Kukkonen @ 2016-10-31 13:40 UTC (permalink / raw)
To: openembedded-core
avahi,distcc: Don't remove users/groups on postrm
e2fsprogs: Fix a build issue noticed on autobuilder
Thanks,
Jussi
The following changes since commit 927ed6cbefbaea2905919e158ceda9546e3e710e:
maintainers.inc: remove SGML recipes (2016-10-28 16:32:31 +0100)
are available in the git repository at:
git://git.yoctoproject.org/poky-contrib jku/fixes
http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=jku/fixes
Jussi Kukkonen (3):
e2fsprogs: Depend on attr
avahi: Don't remove users/groups in postrm
distcc: Don't remove users/groups in postrm
meta/recipes-connectivity/avahi/avahi.inc | 10 ----------
meta/recipes-devtools/distcc/distcc_3.2.bb | 4 ----
meta/recipes-devtools/e2fsprogs/e2fsprogs.inc | 2 +-
3 files changed, 1 insertion(+), 15 deletions(-)
--
2.1.4
^ permalink raw reply
* [PATCH] boost: fix the SRC_URI to point to an actual release, and not a master snapshot
From: Alexander Kanavin @ 2016-10-31 13:23 UTC (permalink / raw)
To: openembedded-core
Sourceforge does a not-so-clever redirecting that fails miserably here:
Proxy request sent, awaiting response... 301 Moved Permanently
Location: http://downloads.sourceforge.net/project/boost/boost/snapshots/master/boost_1_62_0.tar.bz2 [following]
Also, boost developers are naming their snapshot tarballs the same as
release tarballs. The two things conspired together.
The new tarball does have the same checksum as the one in release
announcement, so we should be good now:
http://lists.boost.org/Archives/boost/2016/09/230886.php
Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com>
---
meta/recipes-support/boost/boost-1.62.0.inc | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/meta/recipes-support/boost/boost-1.62.0.inc b/meta/recipes-support/boost/boost-1.62.0.inc
index a097ea1..cd99b0e 100644
--- a/meta/recipes-support/boost/boost-1.62.0.inc
+++ b/meta/recipes-support/boost/boost-1.62.0.inc
@@ -11,9 +11,11 @@ BOOST_VER = "${@"_".join(d.getVar("PV", True).split("."))}"
BOOST_MAJ = "${@"_".join(d.getVar("PV", True).split(".")[0:2])}"
BOOST_P = "boost_${BOOST_VER}"
-SRC_URI = "${SOURCEFORGE_MIRROR}/boost/${BOOST_P}.tar.bz2"
+SRC_URI = "${SOURCEFORGE_MIRROR}/project/boost/boost/${PV}/${BOOST_P}.tar.bz2"
-SRC_URI[md5sum] = "7ef085456c48c49a7fe8237f07e5f674"
-SRC_URI[sha256sum] = "bce80293052e2d6230f1bec9b7524b33412e4fb26e9723460a0f362ac15b7acb"
+SRC_URI[md5sum] = "5fb94629535c19e48703bdb2b2e9490f"
+SRC_URI[sha256sum] = "36c96b0f6155c98404091d8ceb48319a28279ca0333fba1ad8611eb90afb2ca0"
+
+PR = "r1"
S = "${WORKDIR}/${BOOST_P}"
--
2.9.3
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox