[dylan] Backport request

[dylan] Backport request

[Paul Barker]

[-- Attachment #1: Type: text/plain, Size: 543 bytes --]

Hi Paul,

I know dylan is old but it's still the recommended branch for the TI MCSDK.
We've ran into a problem automating deployment as symlinks aren't created for
the modules archives when they are deployed. This was fixed by commit
ef9fad8fff1c413bc0eab15625f051d4e2d0a201 in openembedded-core which looks pretty
simple. I've tested this on the dylan branch in our builds and it works.

Could this be backported to the dylan branch please?

Thanks,

-- 
Paul Barker

Email: paul@paulbarker.me.uk
http://www.paulbarker.me.uk

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 501 bytes --]

Re: [dylan] Backport request

[Paul Eggleton]

Hi Paul,

On Thursday 08 January 2015 18:13:42 Paul Barker wrote:
> I know dylan is old but it's still the recommended branch for the TI MCSDK.
> We've ran into a problem automating deployment as symlinks aren't created
> for the modules archives when they are deployed. This was fixed by commit
> ef9fad8fff1c413bc0eab15625f051d4e2d0a201 in openembedded-core which looks
> pretty simple. I've tested this on the dylan branch in our builds and it
> works.
> 
> Could this be backported to the dylan branch please?

No problem, Richard has now applied this.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: [dylan] Backport Request

[Paul Eggleton]

Hi Paul,

On Friday 18 September 2015 08:52:41 Paul Barker wrote:
> I'm not sure if there are many other poor souls still using dylan, but if
> there are I'd like to request a backport of the following commit. In our
> case it is needed to ensure that a package is rebuilt when INITSCRIPT_NAME
> or INITSCRIPT_PARAMS is changed in a recipe.

Sure, whilst dylan is nominally no longer maintained in this case the change 
is fairly self-contained and straightforward so in theory it should be OK.

> Hopefully we'll be able to upgrade soon, but if so it will probably be only
> as far as daisy...

I'd urge you to consider upgrading further than that; daisy is already out of 
support (and will be one release further out by October). If there are things 
that prevent you from doing that we should discuss them as it might be 
something we need to address in terms of making upgrades easier.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

[dylan] Backport Request

[Paul Barker]

[-- Attachment #1: Type: text/plain, Size: 1522 bytes --]

Hi,

I'm not sure if there are many other poor souls still using dylan, but if there
are I'd like to request a backport of the following commit. In our case it is
needed to ensure that a package is rebuilt when INITSCRIPT_NAME or
INITSCRIPT_PARAMS is changed in a recipe.

Hopefully we'll be able to upgrade soon, but if so it will probably be only as
far as daisy...

commit 4003218f774c38bb5de0d95a43153f8b8d7fc4ce
Author: Richard Purdie <richard.purdie@linuxfoundation.org>
Date:   Fri Oct 4 12:29:08 2013 +0100
    udpated-rc.d: Track postinst/prerm/postrm in task checksum
    
    When these functions change, the package should rebuild but currently it
    does not. We need to add the dependencies manually as the dependency
    code can't track dynamically created variables.
    
    Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
diff --git a/meta/classes/update-rc.d.bbclass b/meta/classes/update-rc.d.bbclass
index 5588569..f726f2f 100644
--- a/meta/classes/update-rc.d.bbclass
+++ b/meta/classes/update-rc.d.bbclass
@@ -54,6 +54,8 @@ python __anonymous() {
 
 PACKAGESPLITFUNCS_prepend = "populate_packages_updatercd "
 
+populate_packages_updatercd[vardeps] += "updatercd_prerm updatercd_postrm updatercd_postinst"
+
 python populate_packages_updatercd () {
     def update_rcd_package(pkg):
         bb.debug(1, 'adding update-rc.d calls to postinst/postrm for %s' % pkg)

-- 
Paul Barker

Email: paul@paulbarker.me.uk
http://www.paulbarker.me.uk

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 501 bytes --]

Re: [dylan] Backport request

[Paul Barker]

On 14 March 2014 19:16, Khem Raj <raj.khem@gmail.com> wrote:
> On Fri, Mar 14, 2014 at 12:13 PM, Chris Larson <clarson@kergoth.com> wrote:
>> You'll be amazed how many headaches you can save having the host environment
>> be a known quantity :)
>
> absolutely
> I cant agree more.
> -Khem

I used to do this with a separate build VM but after a hardware
re-arrange I don't have the spare machine anymore. I've never used
containers before but I've read plenty about them. Just setup Ubuntu
Server 12.04 in a container and I'm going to see if I can get the
builds running in this.

I still think the backport of the fix for eglibc-2.17 with make
version > 4.0 is worth doing, but this route gives me a more stable
build environment anyway.

Cheers for the advice!

-- 
Paul Barker

Email: paul@paulbarker.me.uk
http://www.paulbarker.me.uk

Re: [dylan] Backport request

[Khem Raj]

On Fri, Mar 14, 2014 at 12:13 PM, Chris Larson <clarson@kergoth.com> wrote:
> You'll be amazed how many headaches you can save having the host environment
> be a known quantity :)

absolutely
I cant agree more.
-Khem

Re: [dylan] Backport request

[Khem Raj]

On Fri, Mar 14, 2014 at 12:11 PM, Jack Mitchell <ml@communistcode.co.uk> wrote:
>
>
> On 14/03/2014 18:57, Saul Wold wrote:
>>
>> On 03/14/2014 11:34 AM, Paul Barker wrote:
>>>
>>> I'm stuck using Dylan for a project as I need a 3.2 series kernel.
>>> Building on my current development machine I ran into two failures:
>>>
>>> eglibc-initial, do_configure: Make 4.0 isn't recognised
>>>
>>> This can be fixed by backporting
>>> a678243d6e4add90c1e9459da42de34d3724db5d (already in Dora).
>>>
>>> linux-yocto_3.2: do_patch: Unsupported version of git (1.9.0)
>>>
>>> I fixed this by removing git-native from ASSUME_PROVIDED in
>>> meta/conf/bitbake.conf so that git-native-1.8.1.4 was built and used.
>>> That isn't something we should commit in Dylan but may be useful for
>>> others to know the solution if they run into the same problem.
>>>
>> Can't you use the buildtools tarball?  It includes the right version of
>> make and git.
>
>
> Indeed, this is what I do on my ArchLinux machines when something is too
> new; it's just a simple sourcing of an environment file before the build and
> you're good to go.

build system underneath might still inject bugs into your cross build
even though you got it building.

Re: [dylan] Backport request

[Chris Larson]

[-- Attachment #1: Type: text/plain, Size: 752 bytes --]

On Fri, Mar 14, 2014 at 12:11 PM, Paul Barker <paul@paulbarker.me.uk> wrote:

> >> I use containers. systemd-nspawn goes long way
> >
> >
> > Yeah, containers (systemd-nspawn, docker) or even a chroot can be
> > invaluable. schroot on a debian machine works quite well too for
> something
> > as simple as builds. I end up aliasing bb and bitbake to transparently
> run
> > in the chroot at all times.
>
> It's time I learnt how to use these newfangled containers then...


You'll be amazed how many headaches you can save having the host
environment be a known quantity :)
-- 
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics

[-- Attachment #2: Type: text/html, Size: 1183 bytes --]

Re: [dylan] Backport request

[Jack Mitchell]

On 14/03/2014 18:57, Saul Wold wrote:
> On 03/14/2014 11:34 AM, Paul Barker wrote:
>> I'm stuck using Dylan for a project as I need a 3.2 series kernel.
>> Building on my current development machine I ran into two failures:
>>
>> eglibc-initial, do_configure: Make 4.0 isn't recognised
>>
>> This can be fixed by backporting
>> a678243d6e4add90c1e9459da42de34d3724db5d (already in Dora).
>>
>> linux-yocto_3.2: do_patch: Unsupported version of git (1.9.0)
>>
>> I fixed this by removing git-native from ASSUME_PROVIDED in
>> meta/conf/bitbake.conf so that git-native-1.8.1.4 was built and used.
>> That isn't something we should commit in Dylan but may be useful for
>> others to know the solution if they run into the same problem.
>>
> Can't you use the buildtools tarball?  It includes the right version of
> make and git.

Indeed, this is what I do on my ArchLinux machines when something is too 
new; it's just a simple sourcing of an environment file before the build 
and you're good to go.

Cheers,

>
> Sau!
>
>> Thanks,
>>

Re: [dylan] Backport request

[Paul Barker]

On 14 March 2014 19:06, Chris Larson <clarson@kergoth.com> wrote:
>
> On Fri, Mar 14, 2014 at 11:46 AM, Khem Raj <raj.khem@gmail.com> wrote:
>>
>> On Fri, Mar 14, 2014 at 11:44 AM, Paul Barker <paul@paulbarker.me.uk>
>> wrote:
>> > On 14 March 2014 18:37, Khem Raj <raj.khem@gmail.com> wrote:
>> >> On Fri, Mar 14, 2014 at 11:34 AM, Paul Barker <paul@paulbarker.me.uk>
>> >> wrote:
>> >>> I'm stuck using Dylan for a project as I need a 3.2 series kernel.
>> >>> Building on my current development machine I ran into two failures:
>> >>>
>> >>> eglibc-initial, do_configure: Make 4.0 isn't recognised
>> >>>
>> >>> This can be fixed by backporting
>> >>> a678243d6e4add90c1e9459da42de34d3724db5d (already in Dora).
>> >>>
>> >>> linux-yocto_3.2: do_patch: Unsupported version of git (1.9.0)
>> >>>
>> >>> I fixed this by removing git-native from ASSUME_PROVIDED in
>> >>> meta/conf/bitbake.conf so that git-native-1.8.1.4 was built and used.
>> >>> That isn't something we should commit in Dylan but may be useful for
>> >>> others to know the solution if they run into the same problem.
>> >>
>> >> I think if you also lock your build machine OS along with yocto
>> >> release, it is less painful.
>> >
>> > It is definitely less painful. I'm lacking the spare hardware though
>> > and I want to avoid building inside a VM if I can as I'll be limited
>> > on how much RAM I can allocate to it and I think the performance will
>> > take a hit. Thankfully this project isn't far off end-of-life now.
>>
>> I use containers. systemd-nspawn goes long way
>
>
> Yeah, containers (systemd-nspawn, docker) or even a chroot can be
> invaluable. schroot on a debian machine works quite well too for something
> as simple as builds. I end up aliasing bb and bitbake to transparently run
> in the chroot at all times.

It's time I learnt how to use these newfangled containers then...

-- 
Paul Barker

Email: paul@paulbarker.me.uk
http://www.paulbarker.me.uk

Re: [dylan] Backport request

[Chris Larson]

[-- Attachment #1: Type: text/plain, Size: 1892 bytes --]

On Fri, Mar 14, 2014 at 11:46 AM, Khem Raj <raj.khem@gmail.com> wrote:

> On Fri, Mar 14, 2014 at 11:44 AM, Paul Barker <paul@paulbarker.me.uk>
> wrote:
> > On 14 March 2014 18:37, Khem Raj <raj.khem@gmail.com> wrote:
> >> On Fri, Mar 14, 2014 at 11:34 AM, Paul Barker <paul@paulbarker.me.uk>
> wrote:
> >>> I'm stuck using Dylan for a project as I need a 3.2 series kernel.
> >>> Building on my current development machine I ran into two failures:
> >>>
> >>> eglibc-initial, do_configure: Make 4.0 isn't recognised
> >>>
> >>> This can be fixed by backporting
> >>> a678243d6e4add90c1e9459da42de34d3724db5d (already in Dora).
> >>>
> >>> linux-yocto_3.2: do_patch: Unsupported version of git (1.9.0)
> >>>
> >>> I fixed this by removing git-native from ASSUME_PROVIDED in
> >>> meta/conf/bitbake.conf so that git-native-1.8.1.4 was built and used.
> >>> That isn't something we should commit in Dylan but may be useful for
> >>> others to know the solution if they run into the same problem.
> >>
> >> I think if you also lock your build machine OS along with yocto
> >> release, it is less painful.
> >
> > It is definitely less painful. I'm lacking the spare hardware though
> > and I want to avoid building inside a VM if I can as I'll be limited
> > on how much RAM I can allocate to it and I think the performance will
> > take a hit. Thankfully this project isn't far off end-of-life now.
>
> I use containers. systemd-nspawn goes long way


Yeah, containers (systemd-nspawn, docker) or even a chroot can be
invaluable. schroot on a debian machine works quite well too for something
as simple as builds. I end up aliasing bb and bitbake to transparently run
in the chroot at all times.
-- 
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics

[-- Attachment #2: Type: text/html, Size: 2632 bytes --]

Re: [dylan] Backport request

[Saul Wold]

On 03/14/2014 11:34 AM, Paul Barker wrote:
> I'm stuck using Dylan for a project as I need a 3.2 series kernel.
> Building on my current development machine I ran into two failures:
>
> eglibc-initial, do_configure: Make 4.0 isn't recognised
>
> This can be fixed by backporting
> a678243d6e4add90c1e9459da42de34d3724db5d (already in Dora).
>
> linux-yocto_3.2: do_patch: Unsupported version of git (1.9.0)
>
> I fixed this by removing git-native from ASSUME_PROVIDED in
> meta/conf/bitbake.conf so that git-native-1.8.1.4 was built and used.
> That isn't something we should commit in Dylan but may be useful for
> others to know the solution if they run into the same problem.
>
Can't you use the buildtools tarball?  It includes the right version of 
make and git.

Sau!

> Thanks,
>

Re: [dylan] Backport request

[Khem Raj]

On Fri, Mar 14, 2014 at 11:44 AM, Paul Barker <paul@paulbarker.me.uk> wrote:
> On 14 March 2014 18:37, Khem Raj <raj.khem@gmail.com> wrote:
>> On Fri, Mar 14, 2014 at 11:34 AM, Paul Barker <paul@paulbarker.me.uk> wrote:
>>> I'm stuck using Dylan for a project as I need a 3.2 series kernel.
>>> Building on my current development machine I ran into two failures:
>>>
>>> eglibc-initial, do_configure: Make 4.0 isn't recognised
>>>
>>> This can be fixed by backporting
>>> a678243d6e4add90c1e9459da42de34d3724db5d (already in Dora).
>>>
>>> linux-yocto_3.2: do_patch: Unsupported version of git (1.9.0)
>>>
>>> I fixed this by removing git-native from ASSUME_PROVIDED in
>>> meta/conf/bitbake.conf so that git-native-1.8.1.4 was built and used.
>>> That isn't something we should commit in Dylan but may be useful for
>>> others to know the solution if they run into the same problem.
>>
>> I think if you also lock your build machine OS along with yocto
>> release, it is less painful.
>
> It is definitely less painful. I'm lacking the spare hardware though
> and I want to avoid building inside a VM if I can as I'll be limited
> on how much RAM I can allocate to it and I think the performance will
> take a hit. Thankfully this project isn't far off end-of-life now.

I use containers. systemd-nspawn goes long way

Re: [dylan] Backport request

[Paul Barker]

On 14 March 2014 18:37, Khem Raj <raj.khem@gmail.com> wrote:
> On Fri, Mar 14, 2014 at 11:34 AM, Paul Barker <paul@paulbarker.me.uk> wrote:
>> I'm stuck using Dylan for a project as I need a 3.2 series kernel.
>> Building on my current development machine I ran into two failures:
>>
>> eglibc-initial, do_configure: Make 4.0 isn't recognised
>>
>> This can be fixed by backporting
>> a678243d6e4add90c1e9459da42de34d3724db5d (already in Dora).
>>
>> linux-yocto_3.2: do_patch: Unsupported version of git (1.9.0)
>>
>> I fixed this by removing git-native from ASSUME_PROVIDED in
>> meta/conf/bitbake.conf so that git-native-1.8.1.4 was built and used.
>> That isn't something we should commit in Dylan but may be useful for
>> others to know the solution if they run into the same problem.
>
> I think if you also lock your build machine OS along with yocto
> release, it is less painful.

It is definitely less painful. I'm lacking the spare hardware though
and I want to avoid building inside a VM if I can as I'll be limited
on how much RAM I can allocate to it and I think the performance will
take a hit. Thankfully this project isn't far off end-of-life now.

-- 
Paul Barker

Email: paul@paulbarker.me.uk
http://www.paulbarker.me.uk

Re: [dylan] Backport request

[Khem Raj]

On Fri, Mar 14, 2014 at 11:34 AM, Paul Barker <paul@paulbarker.me.uk> wrote:
> I'm stuck using Dylan for a project as I need a 3.2 series kernel.
> Building on my current development machine I ran into two failures:
>
> eglibc-initial, do_configure: Make 4.0 isn't recognised
>
> This can be fixed by backporting
> a678243d6e4add90c1e9459da42de34d3724db5d (already in Dora).
>
> linux-yocto_3.2: do_patch: Unsupported version of git (1.9.0)
>
> I fixed this by removing git-native from ASSUME_PROVIDED in
> meta/conf/bitbake.conf so that git-native-1.8.1.4 was built and used.
> That isn't something we should commit in Dylan but may be useful for
> others to know the solution if they run into the same problem.

I think if you also lock your build machine OS along with yocto
release, it is less painful.

[dylan] Backport request

[Paul Barker]

I'm stuck using Dylan for a project as I need a 3.2 series kernel.
Building on my current development machine I ran into two failures:

eglibc-initial, do_configure: Make 4.0 isn't recognised

This can be fixed by backporting
a678243d6e4add90c1e9459da42de34d3724db5d (already in Dora).

linux-yocto_3.2: do_patch: Unsupported version of git (1.9.0)

I fixed this by removing git-native from ASSUME_PROVIDED in
meta/conf/bitbake.conf so that git-native-1.8.1.4 was built and used.
That isn't something we should commit in Dylan but may be useful for
others to know the solution if they run into the same problem.

Thanks,

-- 
Paul Barker

Email: paul@paulbarker.me.uk
http://www.paulbarker.me.uk