* 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
* Re: [PATCH] boost: Fix SRC_URI checksums
From: Paul Eggleton @ 2016-10-31 3:27 UTC (permalink / raw)
To: openembedded-core, Alexander Kanavin
In-Reply-To: <CAMKF1sriW41+1MTxTuBHQAbeR+b0LM65fkuUDRL-HapKSLze0A@mail.gmail.com>
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?
Cheers,
Paul
--
Paul Eggleton
Intel Open Source Technology Centre
^ permalink raw reply
* Re: should a "*git.bb" recipe lock that recipe to a fixed version?
From: Khem Raj @ 2016-10-31 2:54 UTC (permalink / raw)
To: Burton, Ross; +Cc: Christopher Larson, OE Core mailing list
In-Reply-To: <CAJTo0LZcHSgs+Qw1Zkrj4bUWnU-p6Ja-vg3+J8H22vxoscTrRg@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 1115 bytes --]
> 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 <mailto: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 <http://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 <http://1.2.3.bb/> for clarity.
with a system integrators hat on I agree. With developer hat on I do not.
>
> Ross
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
[-- Attachment #1.2: Type: text/html, Size: 2309 bytes --]
[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 211 bytes --]
^ permalink raw reply
* Re: any issue with duplicate recipes spread over different layers?
From: Khem Raj @ 2016-10-31 2:51 UTC (permalink / raw)
To: Robert P. J. Day; +Cc: OE Core mailing list
In-Reply-To: <alpine.LFD.2.20.1610300507330.27931@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 1734 bytes --]
> On Oct 30, 2016, at 2:10 AM, Robert P. J. Day <rpjday@crashcourse.ca> wrote:
>
>
> not a burning issue, but while cataloguing some python recipes, i'm
> running across stuff like this:
>
> $ find . -name python-six_1.10.0.bb
> ./meta-virtualization/recipes-devtools/python/python-six_1.10.0.bb
> ./openembedded-core/meta/recipes-devtools/python/python-six_1.10.0.bb
> ./meta-openembedded/meta-python/recipes-devtools/python/python-six_1.10.0.bb
> ...
>
> $ find . -name python3-six_1.10.0.bb
> ./openembedded-core/meta/recipes-devtools/python/python3-six_1.10.0.bb
> ./meta-openembedded/meta-python/recipes-devtools/python/python3-six_1.10.0.bb
> ...
>
> so it appears the same(?) recipe for python-six appears in three
> different layers ... is there any effort expended to identify
> redundancy and remove it?
since its in OE-Core ( since July 2016 ), it would have been good if a
pull request to these layers went out atomically to remove them. But
its never too late, I encourage you to send removal patches to these
layers
>
> 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: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 211 bytes --]
^ permalink raw reply
* Re: should a "*git.bb" recipe lock that recipe to a fixed version?
From: Burton, Ross @ 2016-10-30 23:36 UTC (permalink / raw)
To: Robert P. J. Day; +Cc: Christopher Larson, OE Core mailing list
In-Reply-To: <alpine.LFD.2.20.1610301333390.3944@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 676 bytes --]
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.
Ross
[-- Attachment #2: Type: text/html, Size: 1173 bytes --]
^ permalink raw reply
* Re: [PATCH] cmake.bbclass: Exclude native sysroot from CMAKE_FIND_ROOT_PATH
From: Andreas Müller @ 2016-10-30 20:07 UTC (permalink / raw)
To: Khem Raj; +Cc: Patches and discussions about the oe-core layer
In-Reply-To: <CAMKF1sr=VwcPUpdV9BTfVKuq_sD0Btnm6zkW3xFWNh=e_T=ZHw@mail.gmail.com>
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
Andreas
^ permalink raw reply
* Re: should a "*git.bb" recipe lock that recipe to a fixed version?
From: Christopher Larson @ 2016-10-30 19:40 UTC (permalink / raw)
To: Robert P. J. Day; +Cc: OE Core mailing list
In-Reply-To: <CABcZANnPcmg+iBWgB7HHbEEaTaDOfwtdXr8vfrG7OPzruRdTTQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1811 bytes --]
On Sun, Oct 30, 2016 at 10:16 AM, Christopher Larson <clarson@kergoth.com>
wrote:
> On Sun, Oct 30, 2016 at 5:25 AM, Robert P. J. Day <rpjday@crashcourse.ca>
> wrote:
>
>>
>> not sure if i should have noticed this before, but i was building a
>> number of python modules, and my collection of layers gave me two
>> possibilities for python-django:
>>
>> * python-django_git.bb (meta-openstack)
>> * python-django_1.9.7.bb (meta-python)
>>
>> i simply assumed that any "git"-versioned recipe would typically
>> take precedence over a fixed version recipe, so i was surprised to see
>> that what was built was python-django-1.8.6. huh?
>>
>> then i looked at the recipe from meta-openstack, and it contained
>> the lines:
>>
>> PV = "1.8.6"
>> SRCREV = "80b7e9d09f2d23209b591288f9b2cf3eb3d927c8"
>>
>> SRC_URI = " \
>> git://github.com/django/django.git;branch=stable/1.8.x \
>> "
>>
>> am i right in being a bit confused by that? i checked out the github
>> repo, and it has branches "stable/1.8.x", and also "stable/1.9.x" and
>> "stable/1.10.x". so what is that supposed to mean?
>>
>> am i right in assuming that a "git" recipe will (in the absence of
>> any PREFERRED_VERSION settings or other overriding settings) always be
>> considered before a fixed version recipe? and is that why i got this
>> (for me) unexpected result?
>>
>
> Bitbake selects default versions via DEFAULT_VERSION, PREFERRED_VERSION,
> and lacking both, a naïve version comparison. There’s nothing magic to
> select or not select an _git recipe.
>
s/DEFAULT_VERSION/DEFAULT_PREFERENCE/
--
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics
[-- Attachment #2: Type: text/html, Size: 2808 bytes --]
^ permalink raw reply
* Re: [PATCH 1/4] u-boot: Update to 2016.09.01 release
From: Marek Vasut @ 2016-10-30 18:19 UTC (permalink / raw)
To: Khem Raj; +Cc: OE-core
In-Reply-To: <6BB27325-3BFC-461B-B568-438E4CF04963@gmail.com>
On 10/28/2016 06:23 AM, Khem Raj wrote:
>
>> On Oct 27, 2016, at 5:18 PM, Marek Vasut <marex@denx.de> wrote:
>>
>> On 10/27/2016 01:44 PM, Stefan Müller-Klieser wrote:
>>> On 25.10.2016 21:24, Marek Vasut wrote:
>>>> On 10/25/2016 08:32 PM, Denys Dmytriyenko wrote:
>>>>> On Sat, Oct 22, 2016 at 10:32:12PM +0200, Marek Vasut wrote:
>>>>>> On 10/21/2016 09:47 AM, Burton, Ross wrote:
>>>>>>
>>>>>> Hi!
>>>>>>
>>>>>>> On 20 October 2016 at 14:35, Marek Vasut <marex@denx.de
>>>>>>> <mailto:marex@denx.de>> wrote:
>>>>>>>
>>>>>>> Upgrade U-Boot to the latest version.
>>>>>>>
>>>>>>>
>>>>>>> As usual, u-boot-mkimage broke again:
>>>>>>
>>>>>> That's weird, I successfully built it for nios2 during my tests.
>>>>>> Can you tell me how I can replicate the issue , so I can test for it to
>>>>>> prevent regression and roll out a patch ?
>>>>>
>>>>> Marek, Ross,
>>>>>
>>>>> Any progress on this? Need any help testing?
>>>>>
>>>> Yeah, how do you replicate this issue ?
>>>>
>>> Hi!
>>
>> Hi!
>>
>>> I am just looking at a similar problem and want to jump into the discussion.
>>> As Ross said, the problem is to not respect host/target -- cc/cflags/ldflags.
>>> So to replicate the issue, you can use a bare minimum build host with no
>>> cross toolchain installed, and I guess all targets will fail to build.
>>
>> Well both ARM and nios2 builds for me, so I wonder what sort of stupid
>> thing am I doing.
>
>
> perhaps, its manifesting when toolchain is used from sstate, moreover the sstate
> comes from a mirror which is populated from a workspace which has different
> build time paths, which means its encoding a different default sysroot into
> toolchain. So unless you add TOOLCHAIN_OPTIONS to the CC and its ilk
> you will have issues.
>
> May be you can reproduce it by
>
> 1. build first time ./oe-init-build-env /path/to/build1
> 2. Now set another builddir may be using ./oe-init-build-env /path/to/build2
> 3. Add a SSTATE_MIRROR pointing to sstate from first builddir add below to local.conf
>
> SSTATE_MIRRORS ?= "\
> file://.* file:///path/to/build1/sstate-cache/PATH”
>
> 4. bitbake <package>
> 5. bitbake -ccleansstate <package>
> 6. bitbake package
This seems pretty convoluted. If I understand Ross correctly, it might
be easier to just try the build on centos?
--
Best regards,
Marek Vasut
^ permalink raw reply
* Re: [PATCH 1/4] u-boot: Update to 2016.09.01 release
From: Marek Vasut @ 2016-10-30 18:18 UTC (permalink / raw)
To: Burton, Ross; +Cc: OE-core
In-Reply-To: <CAJTo0LbtQGRnE_ET=1joJKk2V70UF=uK10TfCv=WLSbnT7BAkA@mail.gmail.com>
On 10/28/2016 05:16 PM, Burton, Ross wrote:
>
> On 28 October 2016 at 03:14, Marek Vasut <marex@denx.de
> <mailto:marex@denx.de>> wrote:
>
> > Ross,
> >
> > Care to elaborate on what is breaking for you and what setup you are using?
>
> Please do, indeed.
>
>
> Sorry, I was away for a week and my out-of-office only fires for
> @intel.com <http://intel.com> senders to avoid spamming the mailing list. :)
>
> This was doing a build of *target* u-boot-mkimage for qemux86-64. I
> suspect that this autobuilder was running on Debian as Debian doesn't
> have a /lib/lib-linux-x86-64 but oe-core does, so a binary built for
> x86-64 oe-core may work on some distributions but not others.
So the simplest test would be to do the build of native u-boot-mkimage
on, say, centos/fedora ?
--
Best regards,
Marek Vasut
^ permalink raw reply
* Re: [PATCH] boost: Fix SRC_URI checksums
From: Khem Raj @ 2016-10-30 17:39 UTC (permalink / raw)
To: Richard Purdie; +Cc: Patches and discussions about the oe-core layer
In-Reply-To: <1477845629.23123.20.camel@linuxfoundation.org>
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.
>
> Cheers,
>
> Richard
>
>
>> ---
>> meta/recipes-support/boost/boost-1.62.0.inc | 4 ++--
>> 1 file changed, 2 insertions(+), 2 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..1144ac9 100644
>> --- a/meta/recipes-support/boost/boost-1.62.0.inc
>> +++ b/meta/recipes-support/boost/boost-1.62.0.inc
>> @@ -13,7 +13,7 @@ BOOST_P = "boost_${BOOST_VER}"
>>
>> SRC_URI = "${SOURCEFORGE_MIRROR}/boost/${BOOST_P}.tar.bz2"
>>
>> -SRC_URI[md5sum] = "7ef085456c48c49a7fe8237f07e5f674"
>> -SRC_URI[sha256sum] =
>> "bce80293052e2d6230f1bec9b7524b33412e4fb26e9723460a0f362ac15b7acb"
>> +SRC_URI[md5sum] = "21b799e5d35ba2beef75b225deaf199a"
>> +SRC_URI[sha256sum] =
>> "a715dc2adff2d451719352b1e863d78cbb100a03f7ed76097c89b9016c59091e"
>>
>> S = "${WORKDIR}/${BOOST_P}"
>> --
>> 2.10.1
>>
^ permalink raw reply
* Re: [PATCH] cmake.bbclass: Exclude native sysroot from CMAKE_FIND_ROOT_PATH
From: Khem Raj @ 2016-10-30 17:38 UTC (permalink / raw)
To: Andreas Müller; +Cc: Patches and discussions about the oe-core layer
In-Reply-To: <CALbNGRSvqDHCA-3VPt379-Np29hZo-0ONbj=ZFd+Eew1K=4zFw@mail.gmail.com>
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.
^ permalink raw reply
* Re: should a "*git.bb" recipe lock that recipe to a fixed version?
From: Robert P. J. Day @ 2016-10-30 17:35 UTC (permalink / raw)
To: Christopher Larson; +Cc: OE Core mailing list
In-Reply-To: <CABcZANnPcmg+iBWgB7HHbEEaTaDOfwtdXr8vfrG7OPzruRdTTQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2960 bytes --]
On Sun, 30 Oct 2016, Christopher Larson wrote:
> On Sun, Oct 30, 2016 at 5:25 AM, Robert P. J. Day <rpjday@crashcourse.ca> wrote:
>
> not sure if i should have noticed this before, but i was building a
> number of python modules, and my collection of layers gave me two
> possibilities for python-django:
>
> * python-django_git.bb (meta-openstack)
> * python-django_1.9.7.bb (meta-python)
>
> i simply assumed that any "git"-versioned recipe would typically
> take precedence over a fixed version recipe, so i was surprised to see
> that what was built was python-django-1.8.6. huh?
>
> then i looked at the recipe from meta-openstack, and it contained
> the lines:
>
> PV = "1.8.6"
> SRCREV = "80b7e9d09f2d23209b591288f9b2cf3eb3d927c8"
>
> SRC_URI = " \
> git://github.com/django/django.git;branch=stable/1.8.x \
> "
>
> am i right in being a bit confused by that? i checked out the github
> repo, and it has branches "stable/1.8.x", and also "stable/1.9.x" and
> "stable/1.10.x". so what is that supposed to mean?
>
> am i right in assuming that a "git" recipe will (in the absence of
> any PREFERRED_VERSION settings or other overriding settings) always be
> considered before a fixed version recipe? and is that why i got this
> (for me) unexpected result?
>
>
> Bitbake selects default versions via DEFAULT_VERSION,
> PREFERRED_VERSION, and lacking both, a naïve version comparison.
> There’s nothing magic to select or not select an _git recipe.
>
> It’s been a very common pattern for the _git recipe to be the
> development version / branch HEAD, to be used only when explicitly
> selected, whereas the versioned recipes are stable and versioned, so
> are appropriate defaults. That said, there are also _git recipes
> that set specific versions, and version recipes that use git to
> fetch that version. There’s a lack of consistency in that regard,
> but what you were surprised by has basically been the expected,
> default convention in the past, not the exception.
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.
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: Christopher Larson @ 2016-10-30 17:16 UTC (permalink / raw)
To: Robert P. J. Day; +Cc: OE Core mailing list
In-Reply-To: <alpine.LFD.2.20.1610300813220.27025@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 2160 bytes --]
On Sun, Oct 30, 2016 at 5:25 AM, Robert P. J. Day <rpjday@crashcourse.ca>
wrote:
>
> not sure if i should have noticed this before, but i was building a
> number of python modules, and my collection of layers gave me two
> possibilities for python-django:
>
> * python-django_git.bb (meta-openstack)
> * python-django_1.9.7.bb (meta-python)
>
> i simply assumed that any "git"-versioned recipe would typically
> take precedence over a fixed version recipe, so i was surprised to see
> that what was built was python-django-1.8.6. huh?
>
> then i looked at the recipe from meta-openstack, and it contained
> the lines:
>
> PV = "1.8.6"
> SRCREV = "80b7e9d09f2d23209b591288f9b2cf3eb3d927c8"
>
> SRC_URI = " \
> git://github.com/django/django.git;branch=stable/1.8.x \
> "
>
> am i right in being a bit confused by that? i checked out the github
> repo, and it has branches "stable/1.8.x", and also "stable/1.9.x" and
> "stable/1.10.x". so what is that supposed to mean?
>
> am i right in assuming that a "git" recipe will (in the absence of
> any PREFERRED_VERSION settings or other overriding settings) always be
> considered before a fixed version recipe? and is that why i got this
> (for me) unexpected result?
>
Bitbake selects default versions via DEFAULT_VERSION, PREFERRED_VERSION,
and lacking both, a naïve version comparison. There’s nothing magic to
select or not select an _git recipe.
It’s been a very common pattern for the _git recipe to be the development
version / branch HEAD, to be used only when explicitly selected, whereas
the versioned recipes are stable and versioned, so are appropriate
defaults. That said, there are also _git recipes that set specific
versions, and version recipes that use git to fetch that version. There’s a
lack of consistency in that regard, but what you were surprised by has
basically been the expected, default convention in the past, not the
exception.
--
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics
[-- Attachment #2: Type: text/html, Size: 3001 bytes --]
^ permalink raw reply
* [PATCH] connman: fix bad file descriptor initialisation
From: Lukasz Nowak @ 2016-10-30 17:10 UTC (permalink / raw)
To: openembedded-core
From: Lukasz Nowak <lnowak@tycoint.com>
Import a patch from upstream, which fixes a connman daemon freeze
under certain conditions (multiple active interfaces, no r/w storage).
Signed-off-by: Lukasz Nowak <lnowak@tycoint.com>
---
...ts-Fix-bad-file-descriptor-initialisation.patch | 102 +++++++++++++++++++++
meta/recipes-connectivity/connman/connman_1.33.bb | 1 +
2 files changed, 103 insertions(+)
create mode 100644 meta/recipes-connectivity/connman/connman/0003-stats-Fix-bad-file-descriptor-initialisation.patch
diff --git a/meta/recipes-connectivity/connman/connman/0003-stats-Fix-bad-file-descriptor-initialisation.patch b/meta/recipes-connectivity/connman/connman/0003-stats-Fix-bad-file-descriptor-initialisation.patch
new file mode 100644
index 0000000..c545811
--- /dev/null
+++ b/meta/recipes-connectivity/connman/connman/0003-stats-Fix-bad-file-descriptor-initialisation.patch
@@ -0,0 +1,102 @@
+From c7f4151fb053b0d0691d8f10d7e3690265d28889 Mon Sep 17 00:00:00 2001
+From: Lukasz Nowak <lnowak@tycoint.com>
+Date: Wed, 26 Oct 2016 18:13:02 +0100
+Subject: [PATCH] stats: Fix bad file descriptor initialisation
+
+Stats file code initialises its file descriptor field to 0. But 0 is
+a valid fd value. -1 should be used instead. This causes problems
+when an error happens before a stats file is open (e.g. mkdir
+fails). The clean-up procedure, stats_free() calls close(fd). When fd
+is 0, this first closes stdin, and then any files/sockets which
+received fd=0, re-used by the OS.
+
+Fixed several instances of bad file descriptor field handling, in case
+of errors.
+
+The bug results with connman freezing if there is no read/write storage
+directory available, and there are multiple active interfaces
+(fd=0 gets re-used for sockets in that case).
+
+The patch was imported from the Connman git repository
+(git://git.kernel.org/pub/scm/network/connman) as of commit id
+c7f4151fb053b0d0691d8f10d7e3690265d28889.
+
+Upstream-Status: Accepted
+Signed-off-by: Lukasz Nowak <lnowak@tycoint.com>
+---
+ src/stats.c | 15 +++++++++++++++
+ src/util.c | 4 ++--
+ 2 files changed, 17 insertions(+), 2 deletions(-)
+
+diff --git a/src/stats.c b/src/stats.c
+index 26343b1..c3ca738 100644
+--- a/src/stats.c
++++ b/src/stats.c
+@@ -378,6 +378,7 @@ static int stats_file_setup(struct stats_file *file)
+ strerror(errno), file->name);
+
+ TFR(close(file->fd));
++ file->fd = -1;
+ g_free(file->name);
+ file->name = NULL;
+
+@@ -393,6 +394,7 @@ static int stats_file_setup(struct stats_file *file)
+ err = stats_file_remap(file, size);
+ if (err < 0) {
+ TFR(close(file->fd));
++ file->fd = -1;
+ g_free(file->name);
+ file->name = NULL;
+
+@@ -649,6 +651,13 @@ static int stats_file_history_update(struct stats_file *data_file)
+ bzero(history_file, sizeof(struct stats_file));
+ bzero(temp_file, sizeof(struct stats_file));
+
++ /*
++ * 0 is a valid file descriptor - fd needs to be initialized
++ * to -1 to handle errors correctly
++ */
++ history_file->fd = -1;
++ temp_file->fd = -1;
++
+ err = stats_open(history_file, data_file->history_name);
+ if (err < 0)
+ return err;
+@@ -682,6 +691,12 @@ int __connman_stats_service_register(struct connman_service *service)
+ if (!file)
+ return -ENOMEM;
+
++ /*
++ * 0 is a valid file descriptor - fd needs to be initialized
++ * to -1 to handle errors correctly
++ */
++ file->fd = -1;
++
+ g_hash_table_insert(stats_hash, service, file);
+ } else {
+ return -EALREADY;
+diff --git a/src/util.c b/src/util.c
+index e6532c8..732d451 100644
+--- a/src/util.c
++++ b/src/util.c
+@@ -63,7 +63,7 @@ int __connman_util_init(void)
+ {
+ int r = 0;
+
+- if (f > 0)
++ if (f >= 0)
+ return 0;
+
+ f = open(URANDOM, O_RDONLY);
+@@ -86,7 +86,7 @@ int __connman_util_init(void)
+
+ void __connman_util_cleanup(void)
+ {
+- if (f > 0)
++ if (f >= 0)
+ close(f);
+
+ f = -1;
+--
+2.7.4
+
diff --git a/meta/recipes-connectivity/connman/connman_1.33.bb b/meta/recipes-connectivity/connman/connman_1.33.bb
index 6ea1a08..56a0a0f 100644
--- a/meta/recipes-connectivity/connman/connman_1.33.bb
+++ b/meta/recipes-connectivity/connman/connman_1.33.bb
@@ -5,6 +5,7 @@ SRC_URI = "${KERNELORG_MIRROR}/linux/network/${BPN}/${BP}.tar.xz \
file://connman \
file://no-version-scripts.patch \
file://includes.patch \
+ file://0003-stats-Fix-bad-file-descriptor-initialisation.patch \
"
SRC_URI_append_libc-musl = " file://0002-resolve-musl-does-not-implement-res_ninit.patch"
--
2.7.4
^ permalink raw reply related
* Re: [PATCH] boost: Fix SRC_URI checksums
From: Richard Purdie @ 2016-10-30 16:40 UTC (permalink / raw)
To: Khem Raj, openembedded-core
In-Reply-To: <20161029194615.19954-1-raj.khem@gmail.com>
On Sat, 2016-10-29 at 12:46 -0700, Khem Raj wrote:
> Signed-off-by: Khem Raj <raj.khem@gmail.com>
Why, what happened?
Cheers,
Richard
> ---
> meta/recipes-support/boost/boost-1.62.0.inc | 4 ++--
> 1 file changed, 2 insertions(+), 2 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..1144ac9 100644
> --- a/meta/recipes-support/boost/boost-1.62.0.inc
> +++ b/meta/recipes-support/boost/boost-1.62.0.inc
> @@ -13,7 +13,7 @@ BOOST_P = "boost_${BOOST_VER}"
>
> SRC_URI = "${SOURCEFORGE_MIRROR}/boost/${BOOST_P}.tar.bz2"
>
> -SRC_URI[md5sum] = "7ef085456c48c49a7fe8237f07e5f674"
> -SRC_URI[sha256sum] =
> "bce80293052e2d6230f1bec9b7524b33412e4fb26e9723460a0f362ac15b7acb"
> +SRC_URI[md5sum] = "21b799e5d35ba2beef75b225deaf199a"
> +SRC_URI[sha256sum] =
> "a715dc2adff2d451719352b1e863d78cbb100a03f7ed76097c89b9016c59091e"
>
> S = "${WORKDIR}/${BOOST_P}"
> --
> 2.10.1
>
^ permalink raw reply
* postgresql: "Taskhash mismatch"
From: Robert P. J. Day @ 2016-10-30 14:44 UTC (permalink / raw)
To: OE Core mailing list
i've never seen one of these before -- this was generated in a
completely fresh build:
ERROR: postgresql-9.4.8-r0.0 do_deploychef_install: Taskhash mismatch
834561f3f96987debe459a38ed29e3b5 versus
30bd6bedbae7ee7577cb2e6f9cd67d28 for
/home/rpjday/oe/dist/layers/meta-openembedded/meta-oe/recipes-support/postgresql/postgresql_9.4.8.bb.do_deploychef_install
ERROR: Taskhash mismatch 834561f3f96987debe459a38ed29e3b5 versus
30bd6bedbae7ee7577cb2e6f9cd67d28 for
/home/rpjday/oe/dist/layers/meta-openembedded/meta-oe/recipes-support/postgresql/postgresql_9.4.8.bb.do_deploychef_install
ERROR: postgresql-9.4.8-r0.0 do_package: Taskhash mismatch
dd7583ca4559829157cde56fe9a05763 versus
c875f1d5c39516c88f5063e4ba88a7cb for
/home/rpjday/oe/dist/layers/meta-openembedded/meta-oe/recipes-support/postgresql/postgresql_9.4.8.bb.do_package
ERROR: Taskhash mismatch dd7583ca4559829157cde56fe9a05763 versus
c875f1d5c39516c88f5063e4ba88a7cb for
/home/rpjday/oe/dist/layers/meta-openembedded/meta-oe/recipes-support/postgresql/postgresql_9.4.8.bb.do_package
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: [PATCH] cmake.bbclass: Exclude native sysroot from CMAKE_FIND_ROOT_PATH
From: Andreas Müller @ 2016-10-30 13:34 UTC (permalink / raw)
To: Khem Raj; +Cc: Patches and discussions about the oe-core layer
In-Reply-To: <20161029084707.29652-1-raj.khem@gmail.com>
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.
> 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...
Andreas
^ permalink raw reply
* should a "*git.bb" recipe lock that recipe to a fixed version?
From: Robert P. J. Day @ 2016-10-30 12:25 UTC (permalink / raw)
To: OE Core mailing list
not sure if i should have noticed this before, but i was building a
number of python modules, and my collection of layers gave me two
possibilities for python-django:
* python-django_git.bb (meta-openstack)
* python-django_1.9.7.bb (meta-python)
i simply assumed that any "git"-versioned recipe would typically
take precedence over a fixed version recipe, so i was surprised to see
that what was built was python-django-1.8.6. huh?
then i looked at the recipe from meta-openstack, and it contained
the lines:
PV = "1.8.6"
SRCREV = "80b7e9d09f2d23209b591288f9b2cf3eb3d927c8"
SRC_URI = " \
git://github.com/django/django.git;branch=stable/1.8.x \
"
am i right in being a bit confused by that? i checked out the github
repo, and it has branches "stable/1.8.x", and also "stable/1.9.x" and
"stable/1.10.x". so what is that supposed to mean?
am i right in assuming that a "git" recipe will (in the absence of
any PREFERRED_VERSION settings or other overriding settings) always be
considered before a fixed version recipe? and is that why i got this
(for me) unexpected result?
i note at least one recipe in oe-core that has that same property:
libepoxy_git.bb
which contains:
SRC_URI = " \
git://github.com/anholt/libepoxy.git \
file://0001-select-platforms-based-on-configuration-results.patch \
file://0002-add-an-option-to-disable-glx-support.patch \
file://no-need-for-python3.patch \
"
SRCREV="e2c33af5bfcfc9d168f9e776156dd47c33f428b3"
PV = "1.3.1"
it is just my responsibility to notice that, and use PREFERRED_VERSION
to make sure i get the version i want?
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
* any issue with duplicate recipes spread over different layers?
From: Robert P. J. Day @ 2016-10-30 9:10 UTC (permalink / raw)
To: OE Core mailing list
not a burning issue, but while cataloguing some python recipes, i'm
running across stuff like this:
$ find . -name python-six_1.10.0.bb
./meta-virtualization/recipes-devtools/python/python-six_1.10.0.bb
./openembedded-core/meta/recipes-devtools/python/python-six_1.10.0.bb
./meta-openembedded/meta-python/recipes-devtools/python/python-six_1.10.0.bb
...
$ find . -name python3-six_1.10.0.bb
./openembedded-core/meta/recipes-devtools/python/python3-six_1.10.0.bb
./meta-openembedded/meta-python/recipes-devtools/python/python3-six_1.10.0.bb
...
so it appears the same(?) recipe for python-six appears in three
different layers ... is there any effort expended to identify
redundancy and remove it?
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: [PATCH] systemd: Reload configuration on package install
From: Linus @ 2016-10-29 23:01 UTC (permalink / raw)
To: Khem Raj; +Cc: Patches and discussions about the oe-core layer
In-Reply-To: <CAMKF1so_4pLL+Ou9982Fvi4okEv+0EB80k6Qsvhf5GtYe8e1ww@mail.gmail.com>
This has also been discussed previously:
https://patchwork.openembedded.org/patch/47727/
On 2016-10-29 23:15, Khem Raj wrote:
> On Sat, Oct 29, 2016 at 12:52 PM, Linus <linus.wallgren@scypho.com> wrote:
>> I do believe so, quickly looking through a debian stretch package I found
>> that it uses deb-systemd-helper, as part of the init-system-helpers package,
>> which does reload things if anything changes:
>>
>> https://sources.debian.net/src/init-system-helpers/1.45/script/deb-systemd-helper/#L588
>
> thanks. Seems ok to me.
>
>>
>> On 2016-10-28 20:00, Khem Raj wrote:
>>>
>>>
>>>> On Oct 28, 2016, at 7:36 AM, Linus Wallgren <linus.wallgren@scypho.com>
>>>> wrote:
>>>>
>>>> When a systemd service file has changed it is required to reload
>>>> systemd's configuration. Otherwise changes to a service file will not be
>>>> picked up during package upgrade.
>>>
>>>
>>> while this seems reasonable. Does that happen on other distros using
>>> systemd
>>> too ?
>>>
>>>> ---
>>>> meta/classes/systemd.bbclass | 4 ++++
>>>> 1 file changed, 4 insertions(+)
>>>>
>>>> diff --git a/meta/classes/systemd.bbclass b/meta/classes/systemd.bbclass
>>>> index d56c760..7e51ed6 100644
>>>> --- a/meta/classes/systemd.bbclass
>>>> +++ b/meta/classes/systemd.bbclass
>>>> @@ -29,6 +29,10 @@ if [ -n "$D" ]; then
>>>> fi
>>>>
>>>> if type systemctl >/dev/null 2>/dev/null; then
>>>> + if [ -z "$D" ]; then
>>>> + systemctl daemon-reload
>>>> + fi
>>>> +
>>>> systemctl $OPTS ${SYSTEMD_AUTO_ENABLE} ${SYSTEMD_SERVICE}
>>>>
>>>> if [ -z "$D" -a "${SYSTEMD_AUTO_ENABLE}" = "enable" ]; then
>>>> --
>>>> 2.9.3
>>>>
>>>> --
>>>> _______________________________________________
>>>> Openembedded-core mailing list
>>>> Openembedded-core@lists.openembedded.org
>>>> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>>>
>>>
>> --
>> _______________________________________________
>> Openembedded-core mailing list
>> Openembedded-core@lists.openembedded.org
>> http://lists.openembedded.org/mailman/listinfo/openembedded-core
^ permalink raw reply
* Re: [PATCH] systemd: Reload configuration on package install
From: Khem Raj @ 2016-10-29 21:15 UTC (permalink / raw)
To: Linus; +Cc: Patches and discussions about the oe-core layer
In-Reply-To: <deb371d6-ee5c-8730-e235-f37b13f6cc9d@scypho.com>
On Sat, Oct 29, 2016 at 12:52 PM, Linus <linus.wallgren@scypho.com> wrote:
> I do believe so, quickly looking through a debian stretch package I found
> that it uses deb-systemd-helper, as part of the init-system-helpers package,
> which does reload things if anything changes:
>
> https://sources.debian.net/src/init-system-helpers/1.45/script/deb-systemd-helper/#L588
thanks. Seems ok to me.
>
> On 2016-10-28 20:00, Khem Raj wrote:
>>
>>
>>> On Oct 28, 2016, at 7:36 AM, Linus Wallgren <linus.wallgren@scypho.com>
>>> wrote:
>>>
>>> When a systemd service file has changed it is required to reload
>>> systemd's configuration. Otherwise changes to a service file will not be
>>> picked up during package upgrade.
>>
>>
>> while this seems reasonable. Does that happen on other distros using
>> systemd
>> too ?
>>
>>> ---
>>> meta/classes/systemd.bbclass | 4 ++++
>>> 1 file changed, 4 insertions(+)
>>>
>>> diff --git a/meta/classes/systemd.bbclass b/meta/classes/systemd.bbclass
>>> index d56c760..7e51ed6 100644
>>> --- a/meta/classes/systemd.bbclass
>>> +++ b/meta/classes/systemd.bbclass
>>> @@ -29,6 +29,10 @@ if [ -n "$D" ]; then
>>> fi
>>>
>>> if type systemctl >/dev/null 2>/dev/null; then
>>> + if [ -z "$D" ]; then
>>> + systemctl daemon-reload
>>> + fi
>>> +
>>> systemctl $OPTS ${SYSTEMD_AUTO_ENABLE} ${SYSTEMD_SERVICE}
>>>
>>> if [ -z "$D" -a "${SYSTEMD_AUTO_ENABLE}" = "enable" ]; then
>>> --
>>> 2.9.3
>>>
>>> --
>>> _______________________________________________
>>> Openembedded-core mailing list
>>> Openembedded-core@lists.openembedded.org
>>> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>>
>>
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
^ permalink raw reply
* [PATCH] gstreamer-plugins: Move introspection to individual recipes
From: Khem Raj @ 2016-10-29 19:58 UTC (permalink / raw)
To: openembedded-core
inc files are also used by plugins in other layers but they do
not use same srcrev for gst-common repo for various reasons e.g.
https://github.com/ndechesne/meta-qcom/blob/master/recipes-multimedia/gstreamer/gstreamer1.0-plugins-v4l2.bb
Currently, this patch is forced on these external packages too
and fails to patch cleanly in some cases. Therefore its
better to move this SRC_URI_append to the individual .bb files
Signed-off-by: Khem Raj <raj.khem@gmail.com>
---
meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad_1.8.3.bb | 1 +
meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad_git.bb | 1 +
meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-base_1.8.3.bb | 1 +
meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-base_git.bb | 1 +
meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-good_1.8.3.bb | 1 +
meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-good_git.bb | 1 +
meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-ugly_1.8.3.bb | 1 +
meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-ugly_git.bb | 1 +
meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins.inc | 2 --
9 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad_1.8.3.bb b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad_1.8.3.bb
index 108f4db..ae3f04d 100644
--- a/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad_1.8.3.bb
+++ b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad_1.8.3.bb
@@ -19,6 +19,7 @@ SRC_URI = " \
file://0006-glcolorconvert-GLES3-deprecates-texture2D-and-it-doe.patch \
file://0008-gl-implement-GstGLMemoryEGL.patch \
file://0009-glimagesink-Downrank-to-marginal.patch \
+ file://0001-introspection.m4-prefix-pkgconfig-paths-with-PKG_CON.patch \
"
SRC_URI[md5sum] = "955281a43e98c5464563fa049e0a0911"
SRC_URI[sha256sum] = "7899fcb18e6a1af2888b19c90213af018a57d741c6e72ec56b133bc73ec8509b"
diff --git a/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad_git.bb b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad_git.bb
index 1370380..609ea0b 100644
--- a/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad_git.bb
+++ b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad_git.bb
@@ -15,6 +15,7 @@ SRC_URI = " \
file://avoid-including-sys-poll.h-directly.patch \
file://ensure-valid-sentinels-for-gst_structure_get-etc.patch \
file://0001-gstreamer-gl.pc.in-don-t-append-GL_CFLAGS-to-CFLAGS.patch \
+ file://0001-introspection.m4-prefix-pkgconfig-paths-with-PKG_CON.patch \
"
PV = "1.8.2+git${SRCPV}"
diff --git a/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-base_1.8.3.bb b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-base_1.8.3.bb
index 986b5ac..84cbc04 100644
--- a/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-base_1.8.3.bb
+++ b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-base_1.8.3.bb
@@ -11,6 +11,7 @@ SRC_URI = " \
file://0004-subparse-set-need_segment-after-sink-pad-received-GS.patch \
file://encodebin-Need-more-buffers-in-output-queue-for-bett.patch \
file://make-gio_unix_2_0-dependency-configurable.patch \
+ file://0001-introspection.m4-prefix-pkgconfig-paths-with-PKG_CON.patch \
"
SRC_URI[md5sum] = "4d03dd81828ea6b98a44c8f1ab7f4976"
diff --git a/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-base_git.bb b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-base_git.bb
index 3c2b504..bdd4cb8 100644
--- a/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-base_git.bb
+++ b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-base_git.bb
@@ -14,6 +14,7 @@ SRC_URI = " \
file://0004-subparse-set-need_segment-after-sink-pad-received-GS.patch \
file://encodebin-Need-more-buffers-in-output-queue-for-bett.patch \
file://make-gio_unix_2_0-dependency-configurable.patch \
+ file://0001-introspection.m4-prefix-pkgconfig-paths-with-PKG_CON.patch \
"
PV = "1.8.2+git${SRCPV}"
diff --git a/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-good_1.8.3.bb b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-good_1.8.3.bb
index 5cc6578..840df15 100644
--- a/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-good_1.8.3.bb
+++ b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-good_1.8.3.bb
@@ -9,6 +9,7 @@ SRC_URI = " \
file://0001-gstrtpmp4gpay-set-dafault-value-for-MPEG4-without-co.patch \
file://avoid-including-sys-poll.h-directly.patch \
file://ensure-valid-sentinel-for-gst_structure_get.patch \
+ file://0001-introspection.m4-prefix-pkgconfig-paths-with-PKG_CON.patch \
"
SRC_URI[md5sum] = "473ebb1f15c67de99ddb6e4d027c0876"
diff --git a/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-good_git.bb b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-good_git.bb
index 9b79af2..120629c 100644
--- a/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-good_git.bb
+++ b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-good_git.bb
@@ -12,6 +12,7 @@ SRC_URI = " \
file://avoid-including-sys-poll.h-directly.patch \
file://ensure-valid-sentinel-for-gst_structure_get.patch \
file://0001-gstrtpmp4gpay-set-dafault-value-for-MPEG4-without-co.patch \
+ file://0001-introspection.m4-prefix-pkgconfig-paths-with-PKG_CON.patch \
"
PV = "1.8.2+git${SRCPV}"
diff --git a/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-ugly_1.8.3.bb b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-ugly_1.8.3.bb
index 2745937..4a9a437 100644
--- a/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-ugly_1.8.3.bb
+++ b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-ugly_1.8.3.bb
@@ -5,6 +5,7 @@ LIC_FILES_CHKSUM = "file://COPYING;md5=a6f89e2100d9b6cdffcea4f398e37343 \
SRC_URI = " \
http://gstreamer.freedesktop.org/src/gst-plugins-ugly/gst-plugins-ugly-${PV}.tar.xz \
+ file://0001-introspection.m4-prefix-pkgconfig-paths-with-PKG_CON.patch \
"
SRC_URI[md5sum] = "4fc66c77253b0ad5ce224bda654b2e7d"
diff --git a/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-ugly_git.bb b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-ugly_git.bb
index 22cca3a..61cdbe8 100644
--- a/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-ugly_git.bb
+++ b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-ugly_git.bb
@@ -8,6 +8,7 @@ LIC_FILES_CHKSUM = "file://COPYING;md5=a6f89e2100d9b6cdffcea4f398e37343 \
SRC_URI = " \
git://anongit.freedesktop.org/gstreamer/gst-plugins-ugly;branch=1.8;name=base \
git://anongit.freedesktop.org/gstreamer/common;destsuffix=git/common;name=common \
+ file://0001-introspection.m4-prefix-pkgconfig-paths-with-PKG_CON.patch \
"
PV = "1.8.2+git${SRCPV}"
diff --git a/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins.inc b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins.inc
index 9cfcec3..3f6d4c3 100644
--- a/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins.inc
+++ b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins.inc
@@ -28,8 +28,6 @@ EXTRA_OECONF = " \
--disable-examples \
"
-SRC_URI_append = " file://0001-introspection.m4-prefix-pkgconfig-paths-with-PKG_CON.patch"
-
delete_pkg_m4_file() {
# This m4 file is out of date and is missing PKG_CONFIG_SYSROOT_PATH tweaks which we need for introspection
rm "${S}/common/m4/pkg.m4" || true
--
2.10.1
^ permalink raw reply related
* Re: [PATCH] systemd: Reload configuration on package install
From: Linus @ 2016-10-29 19:52 UTC (permalink / raw)
Cc: openembedded-core
In-Reply-To: <D2F9E708-19E4-4967-AAF5-5D9C1D9941EA@gmail.com>
I do believe so, quickly looking through a debian stretch package I
found that it uses deb-systemd-helper, as part of the
init-system-helpers package, which does reload things if anything changes:
https://sources.debian.net/src/init-system-helpers/1.45/script/deb-systemd-helper/#L588
On 2016-10-28 20:00, Khem Raj wrote:
>
>> On Oct 28, 2016, at 7:36 AM, Linus Wallgren <linus.wallgren@scypho.com> wrote:
>>
>> When a systemd service file has changed it is required to reload
>> systemd's configuration. Otherwise changes to a service file will not be
>> picked up during package upgrade.
>
> while this seems reasonable. Does that happen on other distros using systemd
> too ?
>
>> ---
>> meta/classes/systemd.bbclass | 4 ++++
>> 1 file changed, 4 insertions(+)
>>
>> diff --git a/meta/classes/systemd.bbclass b/meta/classes/systemd.bbclass
>> index d56c760..7e51ed6 100644
>> --- a/meta/classes/systemd.bbclass
>> +++ b/meta/classes/systemd.bbclass
>> @@ -29,6 +29,10 @@ if [ -n "$D" ]; then
>> fi
>>
>> if type systemctl >/dev/null 2>/dev/null; then
>> + if [ -z "$D" ]; then
>> + systemctl daemon-reload
>> + fi
>> +
>> systemctl $OPTS ${SYSTEMD_AUTO_ENABLE} ${SYSTEMD_SERVICE}
>>
>> if [ -z "$D" -a "${SYSTEMD_AUTO_ENABLE}" = "enable" ]; then
>> --
>> 2.9.3
>>
>> --
>> _______________________________________________
>> Openembedded-core mailing list
>> Openembedded-core@lists.openembedded.org
>> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
^ permalink raw reply
* [PATCH] boost: Fix SRC_URI checksums
From: Khem Raj @ 2016-10-29 19:46 UTC (permalink / raw)
To: openembedded-core
Signed-off-by: Khem Raj <raj.khem@gmail.com>
---
meta/recipes-support/boost/boost-1.62.0.inc | 4 ++--
1 file changed, 2 insertions(+), 2 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..1144ac9 100644
--- a/meta/recipes-support/boost/boost-1.62.0.inc
+++ b/meta/recipes-support/boost/boost-1.62.0.inc
@@ -13,7 +13,7 @@ BOOST_P = "boost_${BOOST_VER}"
SRC_URI = "${SOURCEFORGE_MIRROR}/boost/${BOOST_P}.tar.bz2"
-SRC_URI[md5sum] = "7ef085456c48c49a7fe8237f07e5f674"
-SRC_URI[sha256sum] = "bce80293052e2d6230f1bec9b7524b33412e4fb26e9723460a0f362ac15b7acb"
+SRC_URI[md5sum] = "21b799e5d35ba2beef75b225deaf199a"
+SRC_URI[sha256sum] = "a715dc2adff2d451719352b1e863d78cbb100a03f7ed76097c89b9016c59091e"
S = "${WORKDIR}/${BOOST_P}"
--
2.10.1
^ permalink raw reply related
* [oe-core PATCH] wayland: upgrade from 1.11.0 to 1.11.1
From: Fathi Boudra @ 2016-10-29 14:57 UTC (permalink / raw)
To: openembedded-core
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
^ 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