* [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
* Re: [PATCH] boost: Fix SRC_URI checksums
From: Alexander Kanavin @ 2016-10-31 12:53 UTC (permalink / raw)
To: openembedded-core
In-Reply-To: <2141657.IdrglOmXLR@peggleto-mobl.ger.corp.intel.com>
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.
Alex
^ permalink raw reply
* Re: [PATCH] cmake.bbclass: Exclude native sysroot from CMAKE_FIND_ROOT_PATH
From: Andreas Müller @ 2016-10-31 12:48 UTC (permalink / raw)
To: Khem Raj; +Cc: Patches and discussions about the oe-core layer
In-Reply-To: <CALbNGRQ2aKUmRyH1b-aAjx1FNgyrrkOyCWwSRVENM5repVGY9w@mail.gmail.com>
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
Andreas
^ permalink raw reply
* Re: [oe-core PATCH] wayland: upgrade from 1.11.0 to 1.11.1
From: Burton, Ross @ 2016-10-31 11:32 UTC (permalink / raw)
To: Johannes Pointner; +Cc: OE-core
In-Reply-To: <CAHvQdo11Y5ZV0GaC0YsdFCEz6KwLymLms51hDkASayPXo-3TVA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 354 bytes --]
On 31 October 2016 at 08:25, Johannes Pointner <h4nn35.work@gmail.com>
wrote:
> Wouldn't it make more sense to update to 1.12?
> Since 1.11.1 is backporting fixes from 1.12 as stated in the annouce
> mail of the release.
>
Absolutely - there's a 1.12 so unless there's a good reason to avoid it in
master we should be moving to that.
Ross
[-- Attachment #2: Type: text/html, Size: 847 bytes --]
^ permalink raw reply
* [PATCH] mkefidisk.sh: add deprecation warning to the output
From: Ed Bartosh @ 2016-10-31 10:46 UTC (permalink / raw)
To: openembedded-core
mkefidisk.sh will soon be deprecated in favor of .wic images.
Added deprecation warning to the script to inform users that
this script will soon be removed from the codebase.
Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com>
---
scripts/contrib/mkefidisk.sh | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/scripts/contrib/mkefidisk.sh b/scripts/contrib/mkefidisk.sh
index d8db3c0..a175895 100755
--- a/scripts/contrib/mkefidisk.sh
+++ b/scripts/contrib/mkefidisk.sh
@@ -20,6 +20,11 @@
LANG=C
+echo
+echo "WARNING: This script is deprecated and will be removed soon."
+echo "Please consider using wic EFI images instead."
+echo
+
# Set to 1 to enable additional output
DEBUG=0
OUT="/dev/null"
--
2.1.4
^ permalink raw reply related
* Re: couple questions about proper PACKAGECONFIG usage
From: Robert P. J. Day @ 2016-10-31 10:40 UTC (permalink / raw)
To: Burton, Ross; +Cc: OE Core mailing list
In-Reply-To: <CAJTo0LYORU9-1SCYVikomMkQA=XGJ=PNn5PpFg37+X5ubvXj8A@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1325 bytes --]
On Mon, 31 Oct 2016, Burton, Ross wrote:
> On 29 October 2016 at 09:08, Robert P. J. Day <rpjday@crashcourse.ca> wrote:
> actually, that might be it for this post ... am i missing any other
> subtleties involving PACKAGECONFIG worth mentioning? another
> PACAKGECONFIG-related post coming shortly, but it's more focused so
> i'll post it separately.
>
> The only interesting thing is that the behaviour has changed
> recently: the PACKAGECONFIG implementation now sets
> PACKAGECONFIG_CONFARGS and it's up to the recipe and/or class to do
> what it needs with it. autotools.bbclass adds it to EXTRA_OECONF,
> cmake.bbclass adds it to EXTRA_OECMAKE, and so on. In the past it
> was added directly to EXTRA_OECONF but that made integration with
> non-autotools harder.
yes, i'd noticed that, definitely going to add that to my
explanation.
rday
--
========================================================================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
========================================================================
^ permalink raw reply
* Re: couple questions about proper PACKAGECONFIG usage
From: Burton, Ross @ 2016-10-31 10:26 UTC (permalink / raw)
To: Robert P. J. Day; +Cc: OE Core mailing list
In-Reply-To: <alpine.LFD.2.20.1610290343130.7545@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 738 bytes --]
On 29 October 2016 at 09:08, Robert P. J. Day <rpjday@crashcourse.ca> wrote:
> actually, that might be it for this post ... am i missing any other
> subtleties involving PACKAGECONFIG worth mentioning? another
> PACAKGECONFIG-related post coming shortly, but it's more focused so
> i'll post it separately.
>
The only interesting thing is that the behaviour has changed recently: the
PACKAGECONFIG implementation now sets PACKAGECONFIG_CONFARGS and it's up to
the recipe and/or class to do what it needs with it. autotools.bbclass
adds it to EXTRA_OECONF, cmake.bbclass adds it to EXTRA_OECMAKE, and so
on. In the past it was added directly to EXTRA_OECONF but that made
integration with non-autotools harder.
Ross
[-- Attachment #2: Type: text/html, Size: 1243 bytes --]
^ permalink raw reply
* Re: [PATCH] apache2: include .load files in modules.d
From: Robert Yang @ 2016-10-31 8:58 UTC (permalink / raw)
To: Junxian.Xiao, openembedded-core
In-Reply-To: <1477903377-19397-1-git-send-email-Junxian.Xiao@windriver.com>
Hi Junxian,
This should go into openembedded-devel@lists.openembedded.org
Please see README in each layer of meta-openembedded to see how to
send patches.
// Robert
On 10/31/2016 04:42 PM, Junxian.Xiao wrote:
> Issue: LIN8-5007
>
> According to other linux distributes like ubuntu, the modules
> are usually included by 'LoadModule' command in *.load files
> in mods-enable directory, and *.conf files in this directory
> are for special configurations for each module.
>
> The stucture of the files tree is not the same in yocto, so this
> may be not the rule that we must follow. But still add *.load to
> be compatible with customer's normal usage habits.
>
> Signed-off-by: Junxian.Xiao <Junxian.Xiao@windriver.com>
> ---
> .../recipes-httpd/apache2/apache2_2.4.16.bb | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/meta-webserver/recipes-httpd/apache2/apache2_2.4.16.bb b/meta-webserver/recipes-httpd/apache2/apache2_2.4.16.bb
> index 4aacff1..52127c2 100644
> --- a/meta-webserver/recipes-httpd/apache2/apache2_2.4.16.bb
> +++ b/meta-webserver/recipes-httpd/apache2/apache2_2.4.16.bb
> @@ -81,6 +81,7 @@ do_install_append() {
>
> # Ensure configuration file pulls in conf.d and modules.d
> printf "\nIncludeOptional ${sysconfdir}/${BPN}/conf.d/*.conf" >> ${D}/${sysconfdir}/${BPN}/httpd.conf
> + printf "\nIncludeOptional ${sysconfdir}/${BPN}/modules.d/*.load" >> ${D}/${sysconfdir}/${BPN}/httpd.conf
> printf "\nIncludeOptional ${sysconfdir}/${BPN}/modules.d/*.conf\n\n" >> ${D}/${sysconfdir}/${BPN}/httpd.conf
> # match with that is in init script
> printf "\nPidFile /run/httpd.pid" >> ${D}/${sysconfdir}/${BPN}/httpd.conf
>
^ permalink raw reply
* Re: couple questions about proper PACKAGECONFIG usage
From: Jussi Kukkonen @ 2016-10-31 8:45 UTC (permalink / raw)
To: Robert P. J. Day; +Cc: OE Core mailing list
In-Reply-To: <alpine.LFD.2.20.1610290343130.7545@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 4465 bytes --]
On 29 October 2016 at 11:08, Robert P. J. Day <rpjday@crashcourse.ca> wrote:
>
>
> one or two curiosities(?) i've run across re: PACKAGECONFIG usage,
> and as i'm writing a short tutorial page on that feature, i better
> make sure i understand the nuance.
>
> first, AIUI, for any recipe, *any* possible flag value that can be
> assigned to PACKAGECONFIG should be accompanied by the actual set of
> values assigned to that ... flag(?). random example: gnutls.inc:
>
> PACKAGECONFIG ??= "libidn zlib"
>
> PACKAGECONFIG[libidn] = "--with-idn,--without-idn,libidn"
> PACKAGECONFIG[libtasn1] =
"--with-included-libtasn1=no,--with-included-libtasn1,libtasn1"
> PACKAGECONFIG[p11-kit] = "--with-p11-kit,--without-p11-kit,p11-kit"
> PACKAGECONFIG[tpm] = "--with-tpm,--without-tpm,trousers"
> PACKAGECONFIG[zlib] = "--with-zlib,--without-zlib,zlib"
>
> so while the default PACKAGECONFIG flag settings are "libidn" and
> "zlib", that recipe clearly(?) defines five possible flags. i'm
> assuming it would be an error for any possible flag value to not be
> accompanied by a corresponding flag setting (not sure of the correct
> terminology here, i better check that).
>
> next, i've noticed a very small number of recipes that define
> "empty" flag strings, like this from opkg-utils_git.bb:
>
> PACKAGECONFIG = "python update-alternatives"
> PACKAGECONFIG[python] = ",,,${PYTHONRDEPS}"
> PACKAGECONFIG[update-alternatives] = ",,," <----- there
>
> that last line clearly represents a no-op in the context of
> PACKAGECONFIG, and i was puzzled for a minute until it occurred that
> the only way it would have value is if it were tested somewhere else
> in the recipe, and sure enough, further down:
>
> do_install() {
> oe_runmake PREFIX=${prefix} DESTDIR=${D} install
> if ! ${@bb.utils.contains('PACKAGECONFIG', 'update-alternatives',
'true', 'false', d)}; then
> rm -f "${D}${bindir}/update-alternatives"
> fi
> }
>
> so "no-op" PACKAGECONFIG flag settings like that:
>
> meta/recipes-devtools/opkg-utils/opkg-utils_git.bb:PACKAGECONFIG[update-alternatives]
= ",,,"
>
meta/recipes-multimedia/pulseaudio/pulseaudio.inc:PACKAGECONFIG[autospawn-for-root]
= ",,,"
> meta/recipes-connectivity/openssl/openssl.inc:PACKAGECONFIG[perl] = ",,,"
>
> appear to be just a kludgy way to pass a config value to a recipe that
> really just uses the PACKAGECONFIG mechanism to hand it over, without
> using actual PACKAGECONFIG processing, is that a fair way to describe
> that? (put another way, if any recipe defines a "no-op" like that, it
> better test that setting somewhere else manually; otherwise, there's
> no real point to it, yes?)
PACKAGECONFIG provides a means of (en/dis)abling features on a per-recipe
basis. How the recipe accomplishes that is really just an implementation
detail. It would be nice if the upstream project supported the required
configure flags but sometimes it does not. Without knowing the opkg-utils
case in detail I'd guess the best option would have been to add a
"--enable-update-alternatives" configuration flag upstream and making
install work without 'kludges' but that may have been considerably more
work than modifying do_install() in the recipe.
If PACKAGECONFIG sets no configure flags or dependencies and it is not used
elsewhere in the recipe to modify the resulting build or packaging, it is
indeed not doing anything.
> actually, that might be it for this post ... am i missing any other
> subtleties involving PACKAGECONFIG worth mentioning? another
> PACAKGECONFIG-related post coming shortly, but it's more focused so
> i'll post it separately.
No additional monkey business that I know of.
Cheers,
Jussi
> rday
>
> --
>
> ========================================================================
> Robert P. J. Day Ottawa, Ontario, CANADA
> http://crashcourse.ca
>
> Twitter: http://twitter.com/rpjday
> LinkedIn: http://ca.linkedin.com/in/rpjday
> ========================================================================
>
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
[-- Attachment #2: Type: text/html, Size: 5648 bytes --]
^ permalink raw reply
* [meta-webserver][PATCH] apache2: include .load files in modules.d
From: Junxian.Xiao @ 2016-10-31 8:42 UTC (permalink / raw)
To: openembedded-core
In-Reply-To: <1477903377-19397-1-git-send-email-Junxian.Xiao@windriver.com>
Issue: LIN8-5007
According to other linux distributes like ubuntu, the modules
are usually included by 'LoadModule' command in *.load files
in mods-enable directory, and *.conf files in this directory
are for special configurations for each module.
The stucture of the files tree is not the same in yocto, so this
may be not the rule that we must follow. But still add *.load to
be compatible with customer's normal usage habits.
(LOCAL REV: NOT UPSTREAM) -- sent to oe-devel on 20161031
Signed-off-by: Junxian.Xiao <Junxian.Xiao@windriver.com>
---
.../recipes-httpd/apache2/apache2_2.4.16.bb | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/meta-webserver/recipes-httpd/apache2/apache2_2.4.16.bb b/meta-webserver/recipes-httpd/apache2/apache2_2.4.16.bb
index 4aacff1..52127c2 100644
--- a/meta-webserver/recipes-httpd/apache2/apache2_2.4.16.bb
+++ b/meta-webserver/recipes-httpd/apache2/apache2_2.4.16.bb
@@ -81,6 +81,7 @@ do_install_append() {
# Ensure configuration file pulls in conf.d and modules.d
printf "\nIncludeOptional ${sysconfdir}/${BPN}/conf.d/*.conf" >> ${D}/${sysconfdir}/${BPN}/httpd.conf
+ printf "\nIncludeOptional ${sysconfdir}/${BPN}/modules.d/*.load" >> ${D}/${sysconfdir}/${BPN}/httpd.conf
printf "\nIncludeOptional ${sysconfdir}/${BPN}/modules.d/*.conf\n\n" >> ${D}/${sysconfdir}/${BPN}/httpd.conf
# match with that is in init script
printf "\nPidFile /run/httpd.pid" >> ${D}/${sysconfdir}/${BPN}/httpd.conf
--
1.7.1
^ permalink raw reply related
* [PATCH] apache2: include .load files in modules.d
From: Junxian.Xiao @ 2016-10-31 8:42 UTC (permalink / raw)
To: openembedded-core
Issue: LIN8-5007
According to other linux distributes like ubuntu, the modules
are usually included by 'LoadModule' command in *.load files
in mods-enable directory, and *.conf files in this directory
are for special configurations for each module.
The stucture of the files tree is not the same in yocto, so this
may be not the rule that we must follow. But still add *.load to
be compatible with customer's normal usage habits.
Signed-off-by: Junxian.Xiao <Junxian.Xiao@windriver.com>
---
.../recipes-httpd/apache2/apache2_2.4.16.bb | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/meta-webserver/recipes-httpd/apache2/apache2_2.4.16.bb b/meta-webserver/recipes-httpd/apache2/apache2_2.4.16.bb
index 4aacff1..52127c2 100644
--- a/meta-webserver/recipes-httpd/apache2/apache2_2.4.16.bb
+++ b/meta-webserver/recipes-httpd/apache2/apache2_2.4.16.bb
@@ -81,6 +81,7 @@ do_install_append() {
# Ensure configuration file pulls in conf.d and modules.d
printf "\nIncludeOptional ${sysconfdir}/${BPN}/conf.d/*.conf" >> ${D}/${sysconfdir}/${BPN}/httpd.conf
+ printf "\nIncludeOptional ${sysconfdir}/${BPN}/modules.d/*.load" >> ${D}/${sysconfdir}/${BPN}/httpd.conf
printf "\nIncludeOptional ${sysconfdir}/${BPN}/modules.d/*.conf\n\n" >> ${D}/${sysconfdir}/${BPN}/httpd.conf
# match with that is in init script
printf "\nPidFile /run/httpd.pid" >> ${D}/${sysconfdir}/${BPN}/httpd.conf
--
1.7.1
^ permalink raw reply related
* Re: [oe-core PATCH] wayland: upgrade from 1.11.0 to 1.11.1
From: Johannes Pointner @ 2016-10-31 8:25 UTC (permalink / raw)
To: Fathi Boudra; +Cc: OE-core
In-Reply-To: <20161029145747.32390-1-fathi.boudra@linaro.org>
Wouldn't it make more sense to update to 1.12?
Since 1.11.1 is backporting fixes from 1.12 as stated in the annouce
mail of the release.
2016-10-29 16:57 GMT+02:00 Fathi Boudra <fathi.boudra@linaro.org>:
> Update release tarball md5sum/sha256sum
>
> Signed-off-by: Fathi Boudra <fathi.boudra@linaro.org>
> ---
> .../wayland/wayland/0001-scanner-Use-unit32_t-instead-of-uint.patch | 2 +-
> .../recipes-graphics/wayland/{wayland_1.11.0.bb => wayland_1.11.1.bb} | 4 ++--
> 2 files changed, 3 insertions(+), 3 deletions(-)
> rename meta/recipes-graphics/wayland/{wayland_1.11.0.bb => wayland_1.11.1.bb} (92%)
>
> diff --git a/meta/recipes-graphics/wayland/wayland/0001-scanner-Use-unit32_t-instead-of-uint.patch b/meta/recipes-graphics/wayland/wayland/0001-scanner-Use-unit32_t-instead-of-uint.patch
> index dece95c..ef41b79 100644
> --- a/meta/recipes-graphics/wayland/wayland/0001-scanner-Use-unit32_t-instead-of-uint.patch
> +++ b/meta/recipes-graphics/wayland/wayland/0001-scanner-Use-unit32_t-instead-of-uint.patch
> @@ -16,7 +16,7 @@ diff --git a/src/scanner.c b/src/scanner.c
> index 5f06e8e..10a4023 100644
> --- a/src/scanner.c
> +++ b/src/scanner.c
> -@@ -808,7 +808,7 @@ find_enumeration(struct protocol *protocol,
> +@@ -812,7 +812,7 @@ find_enumeration(struct protocol *protocol,
> struct interface *i;
> struct enumeration *e;
> char *enum_name;
> diff --git a/meta/recipes-graphics/wayland/wayland_1.11.0.bb b/meta/recipes-graphics/wayland/wayland_1.11.1.bb
> similarity index 92%
> rename from meta/recipes-graphics/wayland/wayland_1.11.0.bb
> rename to meta/recipes-graphics/wayland/wayland_1.11.1.bb
> index 3413406..fa674f6 100644
> --- a/meta/recipes-graphics/wayland/wayland_1.11.0.bb
> +++ b/meta/recipes-graphics/wayland/wayland_1.11.1.bb
> @@ -13,8 +13,8 @@ LIC_FILES_CHKSUM = "file://COPYING;md5=b31d8f53b6aaf2b4985d7dd7810a70d1 \
> SRC_URI = "https://wayland.freedesktop.org/releases/${BPN}-${PV}.tar.xz \
> file://0001-scanner-Use-unit32_t-instead-of-uint.patch \
> "
> -SRC_URI[md5sum] = "fccf680be066e234729d5b69e0bd0fa9"
> -SRC_URI[sha256sum] = "9540925f7928becfdf5e3b84c70757f6589bf1ceef09bea78784d8e4772c0db0"
> +SRC_URI[md5sum] = "82f227c65faec3df0335847626811303"
> +SRC_URI[sha256sum] = "4c8a99d030282740e898dead98c92d92023be9c3536c7f504444d215a7e39195"
>
> EXTRA_OECONF_class-native = "--disable-documentation --disable-libraries"
>
> --
> 2.10.1
>
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
^ permalink raw reply
* any way to simply list the layers that contributed to final image?
From: Robert P. J. Day @ 2016-10-31 6:41 UTC (permalink / raw)
To: OE Core mailing list
in order to drag in a bunch of python modules to my
core-image-minimal, i added various layers just to play it safe:
BBLAYERS ?= " \
/home/rpjday/oe/dist/layers/poky/meta \
/home/rpjday/oe/dist/layers/poky/meta-poky \
/home/rpjday/oe/dist/layers/poky/meta-yocto-bsp \
/home/rpjday/oe/dist/layers/meta-openembedded/meta-oe \
/home/rpjday/oe/dist/layers/meta-openembedded/meta-webserver \
/home/rpjday/oe/dist/layers/meta-openembedded/meta-networking \
/home/rpjday/oe/dist/layers/meta-openembedded/meta-python \
/home/rpjday/oe/dist/layers/meta-cloud-services \
/home/rpjday/oe/dist/layers/meta-cloud-services/meta-openstack \
/home/rpjday/oe/dist/layers/meta-virtualization \
"
in the end, is there a way to list just those layers that actually
contributed recipes?
i know i can run:
$ bitbake-layers show-recipes
to see where *all* recipes would come from, but that's overly verbose.
is there a shortcut?
rday
--
========================================================================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
========================================================================
^ permalink raw reply
* Re: should a "*git.bb" recipe lock that recipe to a fixed version?
From: Robert P. J. Day @ 2016-10-31 6:29 UTC (permalink / raw)
To: Khem Raj; +Cc: Christopher Larson, OE Core mailing list
In-Reply-To: <F99EA06D-E6DA-4FD4-BBED-D10D157F200C@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2059 bytes --]
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.
rday
--
========================================================================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
========================================================================
^ permalink raw reply
* [PATCH 1/1] classes/npm: use npm install to do installation
From: Paul Eggleton @ 2016-10-31 4:02 UTC (permalink / raw)
To: openembedded-core
In-Reply-To: <cover.1477886520.git.paul.eggleton@linux.intel.com>
Using "npm install" instead of "cp -a" is the more correct thing to be
doing here, and ensures that symlinks for executable scripts are put
into ${prefix}/bin. (I'd prefer ${bindir}, but npm does not allow
specifying paths at that level - only a prefix.)
Fixes [YOCTO #10460].
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
---
meta/classes/npm.bbclass | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/meta/classes/npm.bbclass b/meta/classes/npm.bbclass
index fce4c11..43228c5 100644
--- a/meta/classes/npm.bbclass
+++ b/meta/classes/npm.bbclass
@@ -33,7 +33,11 @@ npm_do_compile() {
npm_do_install() {
mkdir -p ${NPM_INSTALLDIR}/
- cp -a ${S}/* ${NPM_INSTALLDIR}/ --no-preserve=ownership
+ npm install --prefix ${D}${prefix} -g --arch=${NPM_ARCH} --target_arch=${NPM_ARCH} --production --no-registry
+ if [ -d ${D}${prefix}/etc ] ; then
+ # This will be empty
+ rmdir ${D}${prefix}/etc
+ fi
}
python populate_packages_prepend () {
--
2.5.5
^ permalink raw reply related
* [PATCH 0/1] classes/npm: use npm install to do installation
From: Paul Eggleton @ 2016-10-31 4:02 UTC (permalink / raw)
To: openembedded-core
The following changes since commit b18fa5f2f2f46afc6fdc58f4d29679dea9c36c43:
Remove LIC_FILES_CHKSUM from recipes without SRC_URI (2016-10-28 11:27:33 +0100)
are available in the git repository at:
git://git.openembedded.org/openembedded-core-contrib paule/npm-install-fix
http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=paule/npm-install-fix
Paul Eggleton (1):
classes/npm: use npm install to do installation
meta/classes/npm.bbclass | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
--
2.5.5
^ permalink raw reply
* [PATCH 7/7] devtool: add "rename" subcommand
From: Paul Eggleton @ 2016-10-31 3:59 UTC (permalink / raw)
To: openembedded-core
In-Reply-To: <cover.1477886344.git.paul.eggleton@linux.intel.com>
When you run devtool add on a source tree we attempt to figure out the
correct name and version for the recipe. However, despite our best
efforts, sometimes the name and/or version we come up with isn't
correct, and the only way to remedy that up until now was to reset the
recipe, delete the source tree and start again, specifying the name this
time. To avoid this slightly painful procedure, add a "rename"
subcommand that lets you rename the recipe and/or change the version.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
---
meta/lib/oeqa/selftest/devtool.py | 60 +++++++++++
scripts/lib/devtool/build.py | 2 +-
scripts/lib/devtool/standard.py | 202 ++++++++++++++++++++++++++++++++++++++
3 files changed, 263 insertions(+), 1 deletion(-)
diff --git a/meta/lib/oeqa/selftest/devtool.py b/meta/lib/oeqa/selftest/devtool.py
index 71d205c..46f5a0b 100644
--- a/meta/lib/oeqa/selftest/devtool.py
+++ b/meta/lib/oeqa/selftest/devtool.py
@@ -1349,3 +1349,63 @@ class DevtoolTests(DevtoolBase):
files.remove(foundpatch)
if files:
self.fail('Unexpected file(s) copied next to bbappend: %s' % ', '.join(files))
+
+ def test_devtool_rename(self):
+ # Check preconditions
+ self.assertTrue(not os.path.exists(self.workspacedir), 'This test cannot be run with a workspace directory under the build directory')
+ self.track_for_cleanup(self.workspacedir)
+ self.add_command_to_tearDown('bitbake-layers remove-layer */workspace')
+
+ # First run devtool add
+ # We already have this recipe in OE-Core, but that doesn't matter
+ recipename = 'i2c-tools'
+ recipever = '3.1.2'
+ recipefile = os.path.join(self.workspacedir, 'recipes', recipename, '%s_%s.bb' % (recipename, recipever))
+ url = 'http://downloads.yoctoproject.org/mirror/sources/i2c-tools-%s.tar.bz2' % recipever
+ def add_recipe():
+ result = runCmd('devtool add %s' % url)
+ self.assertTrue(os.path.exists(recipefile), 'Expected recipe file not created')
+ self.assertTrue(os.path.exists(os.path.join(self.workspacedir, 'sources', recipename)), 'Source directory not created')
+ checkvars = {}
+ checkvars['S'] = None
+ checkvars['SRC_URI'] = url.replace(recipever, '${PV}')
+ self._test_recipe_contents(recipefile, checkvars, [])
+ add_recipe()
+ # Now rename it - change both name and version
+ newrecipename = 'mynewrecipe'
+ newrecipever = '456'
+ newrecipefile = os.path.join(self.workspacedir, 'recipes', newrecipename, '%s_%s.bb' % (newrecipename, newrecipever))
+ result = runCmd('devtool rename %s %s -V %s' % (recipename, newrecipename, newrecipever))
+ self.assertTrue(os.path.exists(newrecipefile), 'Recipe file not renamed')
+ self.assertFalse(os.path.exists(os.path.join(self.workspacedir, 'recipes', recipename)), 'Old recipe directory still exists')
+ newsrctree = os.path.join(self.workspacedir, 'sources', newrecipename)
+ self.assertTrue(os.path.exists(newsrctree), 'Source directory not renamed')
+ checkvars = {}
+ checkvars['S'] = '${WORKDIR}/%s-%s' % (recipename, recipever)
+ checkvars['SRC_URI'] = url
+ self._test_recipe_contents(newrecipefile, checkvars, [])
+ # Try again - change just name this time
+ result = runCmd('devtool reset -n %s' % newrecipename)
+ shutil.rmtree(newsrctree)
+ add_recipe()
+ newrecipefile = os.path.join(self.workspacedir, 'recipes', newrecipename, '%s_%s.bb' % (newrecipename, recipever))
+ result = runCmd('devtool rename %s %s' % (recipename, newrecipename))
+ self.assertTrue(os.path.exists(newrecipefile), 'Recipe file not renamed')
+ self.assertFalse(os.path.exists(os.path.join(self.workspacedir, 'recipes', recipename)), 'Old recipe directory still exists')
+ self.assertTrue(os.path.exists(os.path.join(self.workspacedir, 'sources', newrecipename)), 'Source directory not renamed')
+ checkvars = {}
+ checkvars['S'] = '${WORKDIR}/%s-${PV}' % recipename
+ checkvars['SRC_URI'] = url.replace(recipever, '${PV}')
+ self._test_recipe_contents(newrecipefile, checkvars, [])
+ # Try again - change just version this time
+ result = runCmd('devtool reset -n %s' % newrecipename)
+ shutil.rmtree(newsrctree)
+ add_recipe()
+ newrecipefile = os.path.join(self.workspacedir, 'recipes', recipename, '%s_%s.bb' % (recipename, newrecipever))
+ result = runCmd('devtool rename %s -V %s' % (recipename, newrecipever))
+ self.assertTrue(os.path.exists(newrecipefile), 'Recipe file not renamed')
+ self.assertTrue(os.path.exists(os.path.join(self.workspacedir, 'sources', recipename)), 'Source directory no longer exists')
+ checkvars = {}
+ checkvars['S'] = '${WORKDIR}/${BPN}-%s' % recipever
+ checkvars['SRC_URI'] = url
+ self._test_recipe_contents(newrecipefile, checkvars, [])
diff --git a/scripts/lib/devtool/build.py b/scripts/lib/devtool/build.py
index 6be549d..252379e 100644
--- a/scripts/lib/devtool/build.py
+++ b/scripts/lib/devtool/build.py
@@ -80,7 +80,7 @@ def register_commands(subparsers, context):
"""Register devtool subcommands from this plugin"""
parser_build = subparsers.add_parser('build', help='Build a recipe',
description='Builds the specified recipe using bitbake (up to and including %s)' % ', '.join(_get_build_tasks(context.config)),
- group='working')
+ group='working', order=50)
parser_build.add_argument('recipename', help='Recipe to build')
parser_build.add_argument('-s', '--disable-parallel-make', action="store_true", help='Disable make parallelism')
parser_build.set_defaults(func=build)
diff --git a/scripts/lib/devtool/standard.py b/scripts/lib/devtool/standard.py
index c15bfef..4523048 100644
--- a/scripts/lib/devtool/standard.py
+++ b/scripts/lib/devtool/standard.py
@@ -852,6 +852,199 @@ def modify(args, config, basepath, workspace):
return 0
+
+def rename(args, config, basepath, workspace):
+ """Entry point for the devtool 'rename' subcommand"""
+ import bb
+ import oe.recipeutils
+
+ check_workspace_recipe(workspace, args.recipename)
+
+ if not (args.newname or args.version):
+ raise DevtoolError('You must specify a new name, a version with -V/--version, or both')
+
+ recipefile = workspace[args.recipename]['recipefile']
+ if not recipefile:
+ raise DevtoolError('devtool rename can only be used where the recipe file itself is in the workspace (e.g. after devtool add)')
+
+ if args.newname and args.newname != args.recipename:
+ reason = oe.recipeutils.validate_pn(args.newname)
+ if reason:
+ raise DevtoolError(reason)
+ newname = args.newname
+ else:
+ newname = args.recipename
+
+ append = workspace[args.recipename]['bbappend']
+ appendfn = os.path.splitext(os.path.basename(append))[0]
+ splitfn = appendfn.split('_')
+ if len(splitfn) > 1:
+ origfnver = appendfn.split('_')[1]
+ else:
+ origfnver = ''
+
+ recipefilemd5 = None
+ tinfoil = setup_tinfoil(basepath=basepath, tracking=True)
+ try:
+ rd = parse_recipe(config, tinfoil, args.recipename, True)
+ if not rd:
+ return 1
+
+ bp = rd.getVar('BP', True)
+ bpn = rd.getVar('BPN', True)
+ if newname != args.recipename:
+ localdata = rd.createCopy()
+ localdata.setVar('PN', newname)
+ newbpn = localdata.getVar('BPN', True)
+ else:
+ newbpn = bpn
+ s = rd.getVar('S', False)
+ src_uri = rd.getVar('SRC_URI', False)
+ pv = rd.getVar('PV', True)
+
+ # Correct variable values that refer to the upstream source - these
+ # values must stay the same, so if the name/version are changing then
+ # we need to fix them up
+ new_s = s
+ new_src_uri = src_uri
+ if newbpn != bpn:
+ # ${PN} here is technically almost always incorrect, but people do use it
+ new_s = new_s.replace('${BPN}', bpn)
+ new_s = new_s.replace('${PN}', bpn)
+ new_s = new_s.replace('${BP}', '%s-${PV}' % bpn)
+ new_src_uri = new_src_uri.replace('${BPN}', bpn)
+ new_src_uri = new_src_uri.replace('${PN}', bpn)
+ new_src_uri = new_src_uri.replace('${BP}', '%s-${PV}' % bpn)
+ if args.version and origfnver == pv:
+ new_s = new_s.replace('${PV}', pv)
+ new_s = new_s.replace('${BP}', '${BPN}-%s' % pv)
+ new_src_uri = new_src_uri.replace('${PV}', pv)
+ new_src_uri = new_src_uri.replace('${BP}', '${BPN}-%s' % pv)
+ patchfields = {}
+ if new_s != s:
+ patchfields['S'] = new_s
+ if new_src_uri != src_uri:
+ patchfields['SRC_URI'] = new_src_uri
+ if patchfields:
+ recipefilemd5 = bb.utils.md5_file(recipefile)
+ oe.recipeutils.patch_recipe(rd, recipefile, patchfields)
+ newrecipefilemd5 = bb.utils.md5_file(recipefile)
+ finally:
+ tinfoil.shutdown()
+
+ if args.version:
+ newver = args.version
+ else:
+ newver = origfnver
+
+ if newver:
+ newappend = '%s_%s.bbappend' % (newname, newver)
+ newfile = '%s_%s.bb' % (newname, newver)
+ else:
+ newappend = '%s.bbappend' % newname
+ newfile = '%s.bb' % newname
+
+ oldrecipedir = os.path.dirname(recipefile)
+ newrecipedir = os.path.join(config.workspace_path, 'recipes', newname)
+ if oldrecipedir != newrecipedir:
+ bb.utils.mkdirhier(newrecipedir)
+
+ newappend = os.path.join(os.path.dirname(append), newappend)
+ newfile = os.path.join(newrecipedir, newfile)
+
+ # Rename bbappend
+ logger.info('Renaming %s to %s' % (append, newappend))
+ os.rename(append, newappend)
+ # Rename recipe file
+ logger.info('Renaming %s to %s' % (recipefile, newfile))
+ os.rename(recipefile, newfile)
+
+ # Rename source tree if it's the default path
+ appendmd5 = None
+ if not args.no_srctree:
+ srctree = workspace[args.recipename]['srctree']
+ if os.path.abspath(srctree) == os.path.join(config.workspace_path, 'sources', args.recipename):
+ newsrctree = os.path.join(config.workspace_path, 'sources', newname)
+ logger.info('Renaming %s to %s' % (srctree, newsrctree))
+ shutil.move(srctree, newsrctree)
+ # Correct any references (basically EXTERNALSRC*) in the .bbappend
+ appendmd5 = bb.utils.md5_file(newappend)
+ appendlines = []
+ with open(newappend, 'r') as f:
+ for line in f:
+ appendlines.append(line)
+ with open(newappend, 'w') as f:
+ for line in appendlines:
+ if srctree in line:
+ line = line.replace(srctree, newsrctree)
+ f.write(line)
+ newappendmd5 = bb.utils.md5_file(newappend)
+
+ bpndir = None
+ newbpndir = None
+ if newbpn != bpn:
+ bpndir = os.path.join(oldrecipedir, bpn)
+ if os.path.exists(bpndir):
+ newbpndir = os.path.join(newrecipedir, newbpn)
+ logger.info('Renaming %s to %s' % (bpndir, newbpndir))
+ shutil.move(bpndir, newbpndir)
+
+ bpdir = None
+ newbpdir = None
+ if newver != origfnver or newbpn != bpn:
+ bpdir = os.path.join(oldrecipedir, bp)
+ if os.path.exists(bpdir):
+ newbpdir = os.path.join(newrecipedir, '%s-%s' % (newbpn, newver))
+ logger.info('Renaming %s to %s' % (bpdir, newbpdir))
+ shutil.move(bpdir, newbpdir)
+
+ if oldrecipedir != newrecipedir:
+ # Move any stray files and delete the old recipe directory
+ for entry in os.listdir(oldrecipedir):
+ oldpath = os.path.join(oldrecipedir, entry)
+ newpath = os.path.join(newrecipedir, entry)
+ logger.info('Renaming %s to %s' % (oldpath, newpath))
+ shutil.move(oldpath, newpath)
+ os.rmdir(oldrecipedir)
+
+ # Now take care of entries in .devtool_md5
+ md5entries = []
+ with open(os.path.join(config.workspace_path, '.devtool_md5'), 'r') as f:
+ for line in f:
+ md5entries.append(line)
+
+ if bpndir and newbpndir:
+ relbpndir = os.path.relpath(bpndir, config.workspace_path) + '/'
+ else:
+ relbpndir = None
+ if bpdir and newbpdir:
+ relbpdir = os.path.relpath(bpdir, config.workspace_path) + '/'
+ else:
+ relbpdir = None
+
+ with open(os.path.join(config.workspace_path, '.devtool_md5'), 'w') as f:
+ for entry in md5entries:
+ splitentry = entry.rstrip().split('|')
+ if len(splitentry) > 2:
+ if splitentry[0] == args.recipename:
+ splitentry[0] = newname
+ if splitentry[1] == os.path.relpath(append, config.workspace_path):
+ splitentry[1] = os.path.relpath(newappend, config.workspace_path)
+ if appendmd5 and splitentry[2] == appendmd5:
+ splitentry[2] = newappendmd5
+ elif splitentry[1] == os.path.relpath(recipefile, config.workspace_path):
+ splitentry[1] = os.path.relpath(newfile, config.workspace_path)
+ if recipefilemd5 and splitentry[2] == recipefilemd5:
+ splitentry[2] = newrecipefilemd5
+ elif relbpndir and splitentry[1].startswith(relbpndir):
+ splitentry[1] = os.path.relpath(os.path.join(newbpndir, splitentry[1][len(relbpndir):]), config.workspace_path)
+ elif relbpdir and splitentry[1].startswith(relbpdir):
+ splitentry[1] = os.path.relpath(os.path.join(newbpdir, splitentry[1][len(relbpdir):]), config.workspace_path)
+ entry = '|'.join(splitentry) + '\n'
+ f.write(entry)
+ return 0
+
+
def _get_patchset_revs(srctree, recipe_path, initial_rev=None):
"""Get initial and update rev of a recipe. These are the start point of the
whole patchset and start point for the patches to be re-generated/updated.
@@ -1630,6 +1823,15 @@ def register_commands(subparsers, context):
parser_sync.add_argument('--keep-temp', action="store_true", help='Keep temporary directory (for debugging)')
parser_sync.set_defaults(func=sync)
+ parser_rename = subparsers.add_parser('rename', help='Rename a recipe file in the workspace',
+ description='Renames the recipe file for a recipe in the workspace, changing the name or version part or both, ensuring that all references within the workspace are updated at the same time. Only works when the recipe file itself is in the workspace, e.g. after devtool add. Particularly useful when devtool add did not automatically determine the correct name.',
+ group='working', order=10)
+ parser_rename.add_argument('recipename', help='Current name of recipe to rename')
+ parser_rename.add_argument('newname', nargs='?', help='New name for recipe (optional, not needed if you only want to change the version)')
+ parser_rename.add_argument('--version', '-V', help='Change the version (NOTE: this does not change the version fetched by the recipe, just the version in the recipe file name)')
+ parser_rename.add_argument('--no-srctree', '-s', action='store_true', help='Do not rename the source tree directory (if the default source tree path has been used) - keeping the old name may be desirable if there are internal/other external references to this path')
+ parser_rename.set_defaults(func=rename)
+
parser_update_recipe = subparsers.add_parser('update-recipe', help='Apply changes from external source tree to recipe',
description='Applies changes from external source tree to a recipe (updating/adding/removing patches as necessary, or by updating SRCREV). Note that these changes need to have been committed to the git repository in order to be recognised.',
group='working', order=-90)
--
2.5.5
^ permalink raw reply related
* [PATCH 6/7] oe-selftest: devtool: fix error message in _test_recipe_contents()
From: Paul Eggleton @ 2016-10-31 3:59 UTC (permalink / raw)
To: openembedded-core
In-Reply-To: <cover.1477886344.git.paul.eggleton@linux.intel.com>
If a variable is being set in the recipe when we've explicitly passed
None as the value to _test_recipe_contents() indicating that it
shouldn't be set at all, then we should be printing out the variable
name in the assertion message but it seems like I forgot to do a
substitution. Also include the value for informational purposes.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
---
meta/lib/oeqa/selftest/devtool.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/lib/oeqa/selftest/devtool.py b/meta/lib/oeqa/selftest/devtool.py
index 713f2c5..71d205c 100644
--- a/meta/lib/oeqa/selftest/devtool.py
+++ b/meta/lib/oeqa/selftest/devtool.py
@@ -44,7 +44,7 @@ class DevtoolBase(oeSelfTest):
if var and var in checkvars:
needvalue = checkvars.pop(var)
if needvalue is None:
- self.fail('Variable %s should not appear in recipe')
+ self.fail('Variable %s should not appear in recipe, but value is being set to "%s"' % (var, value))
if isinstance(needvalue, set):
if var == 'LICENSE':
value = set(value.split(' & '))
--
2.5.5
^ permalink raw reply related
* [PATCH 5/7] recipetool: create: separate LICENSE items with & by default
From: Paul Eggleton @ 2016-10-31 3:59 UTC (permalink / raw)
To: openembedded-core
In-Reply-To: <cover.1477886344.git.paul.eggleton@linux.intel.com>
recipetool sets the LICENSE value based on licenses detected from the
source tree. If there are multiple licenses then they were being
separated by spaces, but this isn't actually legal formatting and if
you're using "devtool add" you get a warning printed when devtool
parses the recipe internally.
Earlier I had made a conscious decision to do it this way since it's up
to the user to figure out whether the multiple licenses should all apply
(in which case they'd be separated with &) or if there is a choice of
license (in which case | is the correct separator). However, I've come
to the conclusion that we can just default to & and then the ugly
warning goes away, and it's the safest alternative of the two (and most
likely to be correct, since it's more common to have a codebase which is
made up of code with different licenses, i.e. all of them apply to the
combined work).
I've tweaked the comment that we add to the recipe to explicitly state
that we've used & and that the user needs to change that if that's not
accurate.
Fixes [YOCTO #10413].
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
---
meta/lib/oeqa/selftest/devtool.py | 5 ++++-
scripts/lib/recipetool/create.py | 12 +++++++-----
2 files changed, 11 insertions(+), 6 deletions(-)
diff --git a/meta/lib/oeqa/selftest/devtool.py b/meta/lib/oeqa/selftest/devtool.py
index e992dcf..713f2c5 100644
--- a/meta/lib/oeqa/selftest/devtool.py
+++ b/meta/lib/oeqa/selftest/devtool.py
@@ -46,7 +46,10 @@ class DevtoolBase(oeSelfTest):
if needvalue is None:
self.fail('Variable %s should not appear in recipe')
if isinstance(needvalue, set):
- value = set(value.split())
+ if var == 'LICENSE':
+ value = set(value.split(' & '))
+ else:
+ value = set(value.split())
self.assertEqual(value, needvalue, 'values for %s do not match' % var)
diff --git a/scripts/lib/recipetool/create.py b/scripts/lib/recipetool/create.py
index c1819b6..cb1c804 100644
--- a/scripts/lib/recipetool/create.py
+++ b/scripts/lib/recipetool/create.py
@@ -787,10 +787,12 @@ def handle_license_vars(srctree, lines_before, handled, extravalues, d):
lines_before.append('# your responsibility to verify that the values are complete and correct.')
if len(licvalues) > 1:
lines_before.append('#')
- lines_before.append('# NOTE: multiple licenses have been detected; if that is correct you should separate')
- lines_before.append('# these in the LICENSE value using & if the multiple licenses all apply, or | if there')
- lines_before.append('# is a choice between the multiple licenses. If in doubt, check the accompanying')
- lines_before.append('# documentation to determine which situation is applicable.')
+ lines_before.append('# NOTE: multiple licenses have been detected; they have been separated with &')
+ lines_before.append('# in the LICENSE value for now since it is a reasonable assumption that all')
+ lines_before.append('# of the licenses apply. If instead there is a choice between the multiple')
+ lines_before.append('# licenses then you should change the value to separate the licenses with |')
+ lines_before.append('# instead of &. If there is any doubt, check the accompanying documentation')
+ lines_before.append('# to determine which situation is applicable.')
if lic_unknown:
lines_before.append('#')
lines_before.append('# The following license files were not able to be identified and are')
@@ -814,7 +816,7 @@ def handle_license_vars(srctree, lines_before, handled, extravalues, d):
licenses = [pkg_license]
else:
lines_before.append('# NOTE: Original package metadata indicates license is: %s' % pkg_license)
- lines_before.append('LICENSE = "%s"' % ' '.join(licenses))
+ lines_before.append('LICENSE = "%s"' % ' & '.join(licenses))
lines_before.append('LIC_FILES_CHKSUM = "%s"' % ' \\\n '.join(lic_files_chksum))
lines_before.append('')
handled.append(('license', licvalues))
--
2.5.5
^ permalink raw reply related
* [PATCH 4/7] devtool: finish: warn if moving recipe to unconfigured destination layer
From: Paul Eggleton @ 2016-10-31 3:59 UTC (permalink / raw)
To: openembedded-core
In-Reply-To: <cover.1477886344.git.paul.eggleton@linux.intel.com>
If you run devtool finish to move a recipe created in the workspace by
devtool add or devtool upgrade to a layer, and that layer is not
currently included in bblayers.conf (perhaps unintentionally), then the
recipe will no longer be visible to bitbake. In this scenario, show a
warning so that the user isn't surprised by the recipe "going missing".
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
---
scripts/lib/devtool/standard.py | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/scripts/lib/devtool/standard.py b/scripts/lib/devtool/standard.py
index 9511d56..c15bfef 100644
--- a/scripts/lib/devtool/standard.py
+++ b/scripts/lib/devtool/standard.py
@@ -1517,6 +1517,11 @@ def finish(args, config, basepath, workspace):
destpath = oe.recipeutils.get_bbfile_path(rd, destlayerdir, origrelpath)
if not destpath:
raise DevtoolError("Unable to determine destination layer path - check that %s specifies an actual layer and %s/conf/layer.conf specifies BBFILES. You may also need to specify a more complete path." % (args.destination, destlayerdir))
+ # Warn if the layer isn't in bblayers.conf (the code to create a bbappend will do this in other cases)
+ layerdirs = [os.path.abspath(layerdir) for layerdir in rd.getVar('BBLAYERS', True).split()]
+ if not os.path.abspath(destlayerdir) in layerdirs:
+ bb.warn('Specified destination layer is not currently enabled in bblayers.conf, so the %s recipe will now be unavailable in your current configuration until you add the layer there' % args.recipename)
+
elif destlayerdir == origlayerdir:
# Same layer, update the original recipe
appendlayerdir = None
--
2.5.5
^ permalink raw reply related
* [PATCH 3/7] devtool: finish: fix error if destination layer is not in bblayers.conf
From: Paul Eggleton @ 2016-10-31 3:59 UTC (permalink / raw)
To: openembedded-core
In-Reply-To: <cover.1477886344.git.paul.eggleton@linux.intel.com>
If devtool finish is run on a recipe where the recipe file itself is in
the workspace (e.g. where devtool add / devtool upgrade has been used)
and the specified destination layer is not in bblayers.conf, then we
need to avoid running bitbake -c clean at the end because the recipe has
been moved, but the bbappend is still present in the workspace layer at
that point and so if we do it will fail due to the dangling bbappend.
It's difficult to do the clean at the point we'd want to because tinfoil
is holding bitbake.lock for most of the time, but in any case cleaning
the recipe is less important than it used to be since we started
managing the sysroot contents more strictly, so just disable cleaning
under these circumstances to avoid the problem.
Fixes [YOCTO #10484].
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
---
scripts/lib/devtool/standard.py | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/scripts/lib/devtool/standard.py b/scripts/lib/devtool/standard.py
index 8dfd538..9511d56 100644
--- a/scripts/lib/devtool/standard.py
+++ b/scripts/lib/devtool/standard.py
@@ -1479,6 +1479,7 @@ def finish(args, config, basepath, workspace):
check_workspace_recipe(workspace, args.recipename)
+ no_clean = False
tinfoil = setup_tinfoil(basepath=basepath, tracking=True)
try:
rd = parse_recipe(config, tinfoil, args.recipename, True)
@@ -1540,6 +1541,7 @@ def finish(args, config, basepath, workspace):
if origlayerdir == config.workspace_path and destpath:
# Recipe file itself is in the workspace - need to move it and any
# associated files to the specified layer
+ no_clean = True
logger.info('Moving recipe file to %s' % destpath)
recipedir = os.path.dirname(rd.getVar('FILE', True))
for root, _, files in os.walk(recipedir):
@@ -1554,7 +1556,7 @@ def finish(args, config, basepath, workspace):
tinfoil.shutdown()
# Everything else has succeeded, we can now reset
- _reset([args.recipename], no_clean=False, config=config, basepath=basepath, workspace=workspace)
+ _reset([args.recipename], no_clean=no_clean, config=config, basepath=basepath, workspace=workspace)
return 0
--
2.5.5
^ permalink raw reply related
* [PATCH 2/7] devtool: add: show recipetool create output
From: Paul Eggleton @ 2016-10-31 3:59 UTC (permalink / raw)
To: openembedded-core
In-Reply-To: <cover.1477886344.git.paul.eggleton@linux.intel.com>
When running devtool add, instead of hiding the recipetool create
output, change it so that it's appropriate to show in the devtool
context and show it in real-time. This means that you get status output
such as when a URL is being fetched (though currently no progress
information.) recipetool create now has a hidden --devtool option to
enable this display mode.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
---
scripts/lib/devtool/standard.py | 5 +++--
scripts/lib/recipetool/create.py | 25 +++++++++++++++++++------
2 files changed, 22 insertions(+), 8 deletions(-)
diff --git a/scripts/lib/devtool/standard.py b/scripts/lib/devtool/standard.py
index 4eff6f8..8dfd538 100644
--- a/scripts/lib/devtool/standard.py
+++ b/scripts/lib/devtool/standard.py
@@ -155,7 +155,7 @@ def add(args, config, basepath, workspace):
try:
while True:
try:
- stdout, _ = exec_build_env_command(config.init_path, basepath, 'recipetool --color=%s create -o %s "%s" %s' % (color, tempdir, source, extracmdopts))
+ stdout, _ = exec_build_env_command(config.init_path, basepath, 'recipetool --color=%s create --devtool -o %s \'%s\' %s' % (color, tempdir, source, extracmdopts), watch=True)
except bb.process.ExecutionError as e:
if e.exitcode == 14:
# FIXME this is a horrible hack that is unfortunately
@@ -164,11 +164,12 @@ def add(args, config, basepath, workspace):
# with references to it throughout the code, so we have
# to exit out and come back here to do it.
ensure_npm(config, basepath, args.fixed_setup)
+ logger.info('Re-running recipe creation process after building nodejs')
continue
elif e.exitcode == 15:
raise DevtoolError('Could not auto-determine recipe name, please specify it on the command line')
else:
- raise DevtoolError('Command \'%s\' failed:\n%s' % (e.command, e.stdout))
+ raise DevtoolError('Command \'%s\' failed' % e.command)
break
recipes = glob.glob(os.path.join(tempdir, '*.bb'))
diff --git a/scripts/lib/recipetool/create.py b/scripts/lib/recipetool/create.py
index d427d32..c1819b6 100644
--- a/scripts/lib/recipetool/create.py
+++ b/scripts/lib/recipetool/create.py
@@ -32,6 +32,18 @@ logger = logging.getLogger('recipetool')
tinfoil = None
plugins = None
+def log_error_cond(message, debugonly):
+ if debugonly:
+ logger.debug(message)
+ else:
+ logger.error(message)
+
+def log_info_cond(message, debugonly):
+ if debugonly:
+ logger.debug(message)
+ else:
+ logger.info(message)
+
def plugin_init(pluginlist):
# Take a reference to the list so we can use it later
global plugins
@@ -406,7 +418,7 @@ def create_recipe(args):
srctree = tempsrc
if fetchuri.startswith('npm://'):
# Check if npm is available
- check_npm(tinfoil.config_data)
+ check_npm(tinfoil.config_data, args.devtool)
logger.info('Fetching %s...' % srcuri)
try:
checksums = scriptutils.fetch_uri(tinfoil.config_data, fetchuri, srctree, srcrev)
@@ -640,7 +652,7 @@ def create_recipe(args):
if not outfile:
if not pn:
- logger.error('Unable to determine short program name from source tree - please specify name with -N/--name or output file name with -o/--outfile')
+ log_error_cond('Unable to determine short program name from source tree - please specify name with -N/--name or output file name with -o/--outfile', args.devtool)
# devtool looks for this specific exit code, so don't change it
sys.exit(15)
else:
@@ -736,7 +748,7 @@ def create_recipe(args):
shutil.move(srctree, args.extract_to)
if tempsrc == srctree:
tempsrc = None
- logger.info('Source extracted to %s' % args.extract_to)
+ log_info_cond('Source extracted to %s' % args.extract_to, args.devtool)
if outfile == '-':
sys.stdout.write('\n'.join(outlines) + '\n')
@@ -749,7 +761,7 @@ def create_recipe(args):
continue
f.write('%s\n' % line)
lastline = line
- logger.info('Recipe %s has been created; further editing may be required to make it fully functional' % outfile)
+ log_info_cond('Recipe %s has been created; further editing may be required to make it fully functional' % outfile, args.devtool)
if tempsrc:
if args.keep_temp:
@@ -1073,9 +1085,9 @@ def convert_rpm_xml(xmlfile):
return values
-def check_npm(d):
+def check_npm(d, debugonly=False):
if not os.path.exists(os.path.join(d.getVar('STAGING_BINDIR_NATIVE', True), 'npm')):
- logger.error('npm required to process specified source, but npm is not available - you need to build nodejs-native first')
+ log_error_cond('npm required to process specified source, but npm is not available - you need to build nodejs-native first', debugonly)
sys.exit(14)
def register_commands(subparsers):
@@ -1093,5 +1105,6 @@ def register_commands(subparsers):
parser_create.add_argument('--src-subdir', help='Specify subdirectory within source tree to use', metavar='SUBDIR')
parser_create.add_argument('-a', '--autorev', help='When fetching from a git repository, set SRCREV in the recipe to a floating revision instead of fixed', action="store_true")
parser_create.add_argument('--keep-temp', action="store_true", help='Keep temporary directory (for debugging)')
+ parser_create.add_argument('--devtool', action="store_true", help=argparse.SUPPRESS)
parser_create.set_defaults(func=create_recipe)
--
2.5.5
^ permalink raw reply related
* [PATCH 1/7] classes/license: fix handling of symlinks pointed to in LIC_FILES_CHKSUM
From: Paul Eggleton @ 2016-10-31 3:59 UTC (permalink / raw)
To: openembedded-core
In-Reply-To: <cover.1477886344.git.paul.eggleton@linux.intel.com>
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
^ permalink raw reply related
* [PATCH 0/7] devtool/recipetool improvements
From: Paul Eggleton @ 2016-10-31 3:59 UTC (permalink / raw)
To: openembedded-core
The following changes since commit b18fa5f2f2f46afc6fdc58f4d29679dea9c36c43:
Remove LIC_FILES_CHKSUM from recipes without SRC_URI (2016-10-28 11:27:33 +0100)
are available in the git repository at:
git://git.openembedded.org/openembedded-core-contrib paule/devtool22-oe
http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=paule/devtool22-oe
Paul Eggleton (7):
classes/license: fix handling of symlinks pointed to in LIC_FILES_CHKSUM
devtool: add: show recipetool create output
devtool: finish: fix error if destination layer is not in bblayers.conf
devtool: finish: warn if moving recipe to unconfigured destination layer
recipetool: create: separate LICENSE items with & by default
oe-selftest: devtool: fix error message in _test_recipe_contents()
devtool: add "rename" subcommand
meta/classes/license.bbclass | 2 +
meta/lib/oeqa/selftest/devtool.py | 67 +++++++++++-
scripts/lib/devtool/build.py | 2 +-
scripts/lib/devtool/standard.py | 216 +++++++++++++++++++++++++++++++++++++-
scripts/lib/recipetool/create.py | 37 +++++--
5 files changed, 307 insertions(+), 17 deletions(-)
--
2.5.5
^ permalink raw reply
* Re: [PATCH] boost: Fix SRC_URI checksums
From: Paul Eggleton @ 2016-10-31 3:45 UTC (permalink / raw)
To: openembedded-core
In-Reply-To: <1552039.tK8Y5jYAKD@peggleto-mobl.ger.corp.intel.com>
On Mon, 31 Oct 2016 16:27:15 Paul Eggleton wrote:
> On Sun, 30 Oct 2016 10:39:34 Khem Raj wrote:
> > On Sun, Oct 30, 2016 at 9:40 AM, Richard Purdie
> > <richard.purdie@linuxfoundation.org> wrote:
> > > On Sat, 2016-10-29 at 12:46 -0700, Khem Raj wrote:
> > >> Signed-off-by: Khem Raj <raj.khem@gmail.com>
> > >
> > > Why, what happened?
> >
> > I haven't checked in detail but after the recent master commits my
> > builds started to fail with checksum errors.
> > since it was happening on two different machines I though it might
> > have been over sight.
>
> We need to be extremely cautious changing the SRC_URI checksums when there's
> a mismatch, otherwise we might as well not have them at all. The SRC_URI
> checksums definitely were changed when the last update was done, so this
> doesn't appear to be a case where they accidentally weren't updated.
>
> 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.
Cheers,
Paul
--
Paul Eggleton
Intel Open Source Technology Centre
^ permalink raw reply
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