All of lore.kernel.org
 help / color / mirror / Atom feed
* Generating license/manifest for a specific layer?
@ 2018-06-11 13:46 Michael Habibi
  2018-06-11 15:55 ` Beth Flanagan
  2018-06-11 19:16 ` Ulf Samuelsson
  0 siblings, 2 replies; 6+ messages in thread
From: Michael Habibi @ 2018-06-11 13:46 UTC (permalink / raw)
  To: Yocto

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

Our use case is to capture the license files, manifest (package/version),
and download information only for packages we modify/add. We use our own
layer to modify/add packages, everything coming from standard Yocto layers
are untouched.

Is there a way to generate this information on a layer-by-layer basis,
instead of a full manifest that includes all standard, unmodified packages?

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

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Generating license/manifest for a specific layer?
  2018-06-11 13:46 Generating license/manifest for a specific layer? Michael Habibi
@ 2018-06-11 15:55 ` Beth Flanagan
  2018-06-13 13:42   ` Michael Habibi
  2018-06-11 19:16 ` Ulf Samuelsson
  1 sibling, 1 reply; 6+ messages in thread
From: Beth Flanagan @ 2018-06-11 15:55 UTC (permalink / raw)
  To: Michael Habibi; +Cc: Yocto

On Mon, Jun 11, 2018 at 2:46 PM, Michael Habibi <mikehabibi@gmail.com> wrote:
> Our use case is to capture the license files, manifest (package/version),
> and download information only for packages we modify/add. We use our own
> layer to modify/add packages, everything coming from standard Yocto layers
> are untouched.
>
> Is there a way to generate this information on a layer-by-layer basis,
> instead of a full manifest that includes all standard, unmodified packages?

The easy (cheating) way, would be to modify the tmp/deploy/licenses
artifact post build (I do it to remove -native- and -cross- from
things I distribute as I'm not actually distributing them) or put in a
post do_rootfs function that does it.

I guess my question would be (and this is less a technical question
and more of a legal one) is why would you want to only include a
manifest for only part of what you're distributing (or am I
misunderstanding what you're trying to do here?)

-b
>
> --
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Generating license/manifest for a specific layer?
  2018-06-11 13:46 Generating license/manifest for a specific layer? Michael Habibi
  2018-06-11 15:55 ` Beth Flanagan
@ 2018-06-11 19:16 ` Ulf Samuelsson
  1 sibling, 0 replies; 6+ messages in thread
From: Ulf Samuelsson @ 2018-06-11 19:16 UTC (permalink / raw)
  To: Michael Habibi; +Cc: Yocto

I have been working on a release-notes bbclass which will for each recipe included in am image extract stuff like package name, license info, cve info, SUMMARY, DESCRIPTION etc. and generate LaTex files.
repo diffmanifests is used to extract the difference between a previous manifest and the current manifest. 
Each patch committed has a JIRA ticket number, and a LaTex file is generated with a symbolic link to our JIRA server.
Everything is collected by a separate project, and once the LaTex files are complete,
I only have to do 
make <product>-release-notes.pdf.

Once it is merged locally, I am considering upstreaming.

Best Regards,
Ulf Samuelsson

> 11 juni 2018 kl. 15:46 skrev Michael Habibi <mikehabibi@gmail.com>:
> 
> Our use case is to capture the license files, manifest (package/version), and download information only for packages we modify/add. We use our own layer to modify/add packages, everything coming from standard Yocto layers are untouched.
> 
> Is there a way to generate this information on a layer-by-layer basis, instead of a full manifest that includes all standard, unmodified packages?
> -- 
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto



^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Generating license/manifest for a specific layer?
  2018-06-11 15:55 ` Beth Flanagan
@ 2018-06-13 13:42   ` Michael Habibi
  2018-06-13 13:59     ` Beth Flanagan
  0 siblings, 1 reply; 6+ messages in thread
From: Michael Habibi @ 2018-06-13 13:42 UTC (permalink / raw)
  To: pidge; +Cc: Yocto

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

Beth,

This is for internal consumption. We want to be able to generate a full
manifest, and also one that reflects how we diverged from base Yocto
distribution.

On Mon, Jun 11, 2018 at 10:55 AM Beth Flanagan <pidge@toganlabs.com> wrote:

> On Mon, Jun 11, 2018 at 2:46 PM, Michael Habibi <mikehabibi@gmail.com>
> wrote:
> > Our use case is to capture the license files, manifest (package/version),
> > and download information only for packages we modify/add. We use our own
> > layer to modify/add packages, everything coming from standard Yocto
> layers
> > are untouched.
> >
> > Is there a way to generate this information on a layer-by-layer basis,
> > instead of a full manifest that includes all standard, unmodified
> packages?
>
> The easy (cheating) way, would be to modify the tmp/deploy/licenses
> artifact post build (I do it to remove -native- and -cross- from
> things I distribute as I'm not actually distributing them) or put in a
> post do_rootfs function that does it.
>
> I guess my question would be (and this is less a technical question
> and more of a legal one) is why would you want to only include a
> manifest for only part of what you're distributing (or am I
> misunderstanding what you're trying to do here?)
>
> -b
> >
> > --
> > _______________________________________________
> > yocto mailing list
> > yocto@yoctoproject.org
> > https://lists.yoctoproject.org/listinfo/yocto
> >
>

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

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Generating license/manifest for a specific layer?
  2018-06-13 13:42   ` Michael Habibi
@ 2018-06-13 13:59     ` Beth Flanagan
  2018-06-13 20:00       ` Michael Habibi
  0 siblings, 1 reply; 6+ messages in thread
From: Beth Flanagan @ 2018-06-13 13:59 UTC (permalink / raw)
  To: Michael Habibi; +Cc: Yocto

Ok, I guess my question there then would be is how you'd determine
where a recipe "lived". Like, if meta-foo has a bbappends for
something in core, would you include it or not in your manifest?

If so, then taking the original manifest and just doing some text
manipulation in a ROOTFS_POSTPROCESS_COMMAND would be the way I'd
probably look at tackling it.

On Wed, Jun 13, 2018 at 2:42 PM, Michael Habibi <mikehabibi@gmail.com> wrote:
> Beth,
>
> This is for internal consumption. We want to be able to generate a full
> manifest, and also one that reflects how we diverged from base Yocto
> distribution.
>
> On Mon, Jun 11, 2018 at 10:55 AM Beth Flanagan <pidge@toganlabs.com> wrote:
>>
>> On Mon, Jun 11, 2018 at 2:46 PM, Michael Habibi <mikehabibi@gmail.com>
>> wrote:
>> > Our use case is to capture the license files, manifest
>> > (package/version),
>> > and download information only for packages we modify/add. We use our own
>> > layer to modify/add packages, everything coming from standard Yocto
>> > layers
>> > are untouched.
>> >
>> > Is there a way to generate this information on a layer-by-layer basis,
>> > instead of a full manifest that includes all standard, unmodified
>> > packages?
>>
>> The easy (cheating) way, would be to modify the tmp/deploy/licenses
>> artifact post build (I do it to remove -native- and -cross- from
>> things I distribute as I'm not actually distributing them) or put in a
>> post do_rootfs function that does it.
>>
>> I guess my question would be (and this is less a technical question
>> and more of a legal one) is why would you want to only include a
>> manifest for only part of what you're distributing (or am I
>> misunderstanding what you're trying to do here?)
>>
>> -b
>> >
>> > --
>> > _______________________________________________
>> > yocto mailing list
>> > yocto@yoctoproject.org
>> > https://lists.yoctoproject.org/listinfo/yocto
>> >


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Generating license/manifest for a specific layer?
  2018-06-13 13:59     ` Beth Flanagan
@ 2018-06-13 20:00       ` Michael Habibi
  0 siblings, 0 replies; 6+ messages in thread
From: Michael Habibi @ 2018-06-13 20:00 UTC (permalink / raw)
  To: pidge; +Cc: Yocto

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

So to clarify your question, basically everything we would want in the
custom manifest would be in our own layer: both bbappends and new bb
recipes. Given that, you think I could still modify it like you suggest to
get what I want?

On Wed, Jun 13, 2018 at 8:59 AM Beth Flanagan <pidge@toganlabs.com> wrote:

> Ok, I guess my question there then would be is how you'd determine
> where a recipe "lived". Like, if meta-foo has a bbappends for
> something in core, would you include it or not in your manifest?
>
> If so, then taking the original manifest and just doing some text
> manipulation in a ROOTFS_POSTPROCESS_COMMAND would be the way I'd
> probably look at tackling it.
>
> On Wed, Jun 13, 2018 at 2:42 PM, Michael Habibi <mikehabibi@gmail.com>
> wrote:
> > Beth,
> >
> > This is for internal consumption. We want to be able to generate a full
> > manifest, and also one that reflects how we diverged from base Yocto
> > distribution.
> >
> > On Mon, Jun 11, 2018 at 10:55 AM Beth Flanagan <pidge@toganlabs.com>
> wrote:
> >>
> >> On Mon, Jun 11, 2018 at 2:46 PM, Michael Habibi <mikehabibi@gmail.com>
> >> wrote:
> >> > Our use case is to capture the license files, manifest
> >> > (package/version),
> >> > and download information only for packages we modify/add. We use our
> own
> >> > layer to modify/add packages, everything coming from standard Yocto
> >> > layers
> >> > are untouched.
> >> >
> >> > Is there a way to generate this information on a layer-by-layer basis,
> >> > instead of a full manifest that includes all standard, unmodified
> >> > packages?
> >>
> >> The easy (cheating) way, would be to modify the tmp/deploy/licenses
> >> artifact post build (I do it to remove -native- and -cross- from
> >> things I distribute as I'm not actually distributing them) or put in a
> >> post do_rootfs function that does it.
> >>
> >> I guess my question would be (and this is less a technical question
> >> and more of a legal one) is why would you want to only include a
> >> manifest for only part of what you're distributing (or am I
> >> misunderstanding what you're trying to do here?)
> >>
> >> -b
> >> >
> >> > --
> >> > _______________________________________________
> >> > yocto mailing list
> >> > yocto@yoctoproject.org
> >> > https://lists.yoctoproject.org/listinfo/yocto
> >> >
>

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

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2018-06-13 20:01 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-06-11 13:46 Generating license/manifest for a specific layer? Michael Habibi
2018-06-11 15:55 ` Beth Flanagan
2018-06-13 13:42   ` Michael Habibi
2018-06-13 13:59     ` Beth Flanagan
2018-06-13 20:00       ` Michael Habibi
2018-06-11 19:16 ` Ulf Samuelsson

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.