Patchwork archiver.bbclass: Archive the native builds as well

On my build no copy of gcc/opkg-utils was archived. For gcc it is
bad as libgcc will end up in the image and the sources should be
provided. Update the method and comment to not exclude the native
version of the build.
---
 meta/classes/archiver.bbclass |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

> On my build no copy of gcc/opkg-utils was archived. For gcc it is
> bad as libgcc will end up in the image and the sources should be
> provided. Update the method and comment to not exclude the native
> version of the build.

Native packages shouldn't be included in the target image, and therefor do
not need to have their sources archived for any compliance purposes.

-Kevin

On 01/18/2013 06:34 AM, Holger Hans Peter Freyther wrote:
> On my build no copy of gcc/opkg-utils was archived. For gcc it is
> bad as libgcc will end up in the image and the sources should be
> provided. Update the method and comment to not exclude the native
> version of the build.

I understand what the issue is here, but I am not sure this is the right 
solution. This will likely bring in way more than is wanted or needed 
for source archiving.

What's needed from the opkg-utils-native?

Sau!


> ---
>   meta/classes/archiver.bbclass |    4 ++--
>   1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/meta/classes/archiver.bbclass b/meta/classes/archiver.bbclass
> index a4a2158..516f947 100644
> --- a/meta/classes/archiver.bbclass
> +++ b/meta/classes/archiver.bbclass
> @@ -187,11 +187,11 @@ def get_applying_patches(d):
>
>   def not_tarball(d):
>       """
> -    packages including key words 'work-shared', 'native', 'packagegroup-' will be passed
> +    packages including key words 'work-shared', 'packagegroup-' will be passed
>       """
>       workdir = d.getVar('WORKDIR', True)
>       s = d.getVar('S', True)
> -    if 'work-shared' in s or 'packagegroup-' in workdir or 'native' in workdir:
> +    if 'work-shared' in s or 'packagegroup-' in workdir:
>           return True
>       else:
>           return False
>

On 01/18/2013 10:24 AM, kevin.strasser@linux.intel.com wrote:
>> On my build no copy of gcc/opkg-utils was archived. For gcc it is
>> bad as libgcc will end up in the image and the sources should be
>> provided. Update the method and comment to not exclude the native
>> version of the build.
>
> Native packages shouldn't be included in the target image, and therefor do
>not need to have their sources archived for any compliance purposes.
>

Correct, but in this case the gcc package provides the libgcc libraries 
on the target, GCC is a special case since it's source in the 
work-shared directory. There is a libgcc in work/<arch>/libgcc, but it 
only contains the build, the sources are all in the work-shared/gcc dir.

Sau!

> -Kevin
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>
>

On Fri, Jan 18, 2013 at 10:25:43AM -0800, Saul Wold wrote:
> 
> I understand what the issue is here, but I am not sure this is the
> right solution. This will likely bring in way more than is wanted or
> needed for source archiving.
> 
> What's needed from the opkg-utils-native?

IANAL so let me say it is company/personal policy to release more than
would be the minimumm specially to avoid corner cases like we have with
gcc/libgcc.

I think there are some issues..

a.) Missing option to tarball everything. I can prepare a patch for that.

b.) At least libgcc sources not being present.

c.) How can I get back to compliance? I would have to use something like
the old DISTRO_PR after I patched the archiver class and rebuild everything.
How can this be handled today? I have installations in the field that I
want to upgrade, so the PR of each package should increase.

d.) Verify that for the meta-toolchain target the necessary GCC sources
are archived.

cheers
	holger

PS: Re-sent from the right address

On Sat, 2013-01-19 at 09:44 +0100, Holger Hans Peter Freyther wrote:
> On Fri, Jan 18, 2013 at 10:25:43AM -0800, Saul Wold wrote:
> > 
> > I understand what the issue is here, but I am not sure this is the
> > right solution. This will likely bring in way more than is wanted or
> > needed for source archiving.
> > 
> > What's needed from the opkg-utils-native?
> 
> IANAL so let me say it is company/personal policy to release more than
> would be the minimumm specially to avoid corner cases like we have with
> gcc/libgcc.
> 
> I think there are some issues..
> 
> a.) Missing option to tarball everything. I can prepare a patch for that.
> 
> b.) At least libgcc sources not being present.
> 
> c.) How can I get back to compliance? I would have to use something like
> the old DISTRO_PR after I patched the archiver class and rebuild everything.
> How can this be handled today? I have installations in the field that I
> want to upgrade, so the PR of each package should increase.
> 
> d.) Verify that for the meta-toolchain target the necessary GCC sources
> are archived.
> 
> cheers
> 	holger
> 
> PS: Re-sent from the right address

From a technical perspective, I think gcc could be breaking for two
reasons:

a) It uses the "shared sources" functionality so there is one ${S}
directory for all the different targets. I'm not sure if the archiver
class interacts well with that.

b) libgcc is a "stub" recipe which packages pieces built by a cross
recipe and stashed in the sysroot. The recipe is important as it is a
"target" recipe rather than the other cross recipes.

I'm not sure how removing "native" from the class helps either of these
two things though. Its not like we have a gcc-native or a libgcc-native.

So there could well be a problem here but I'm not feeling happy we've
solved it yet. More information would be appreciated.

Cheers,

Richard

On Sun, Jan 20, 2013 at 12:56:08PM +0000, Richard Purdie wrote:

Dear Richard,

> So there could well be a problem here but I'm not feeling happy we've
> solved it yet. More information would be appreciated.

I agree. The removal of -native comes from the fact that I wanted the
source opkg-utils-native (because at least in edison there were patches
that are not inside the Openmoki SVN, this also means I backported the
archiver). So the -native helped with that part. I was just curious to
check if I have the sources for libgcc and I didn't.

It will take me at least two weeks before I can re-try with OE-Core HEAD
and check if the sources for GCC are missing or not. For the policy part
I am pretty sure that I want _all_ the sources (except the LICENSE is closed).

holger