[Toaster] License manifest, plus packages included-but-not-built cache problem

Wed Mar 5 02:41:39 PST 2014

I have some comments below,

Alex

On Tue, Mar 4, 2014 at 10:04 PM, Reyna, David L (Wind River) <
david.reyna at windriver.com> wrote:

> Hi Belen and Alex,
>
> I understand your proposal, but there are two practical problems.
>
> 1) While we can construct most of the license manifest path (with the
> image name and machine name), there is no entry in the database that
> indicates the "date_time" part of the name. And while we can impugn it once
> Alex populates the image files table, that would be a heuristic and not a
> definitive computation.
>
>
> <projectdir>/tmp/deploy/licenses/{{image}}-{{machine}}-20130611152226/license.manifest

---------------------------------------------------------^^^^^^^^^^^^^^?
>
[Alex] I agree that we need to collect and store the path to the
license.manifest file.

>
> 2) While the license manifest file data is in the database, it also is
> not. The issue appears to be this, and all of us here at WR are
> encountering this issue.
>
> The "Packages Included" table for each target would seem to be all of the
> packages that make up the respective image, but it seems rather to be the
> included packages _that_were_built_ this exact time.

[Alex] If this happens, this is a bug. Packages Included needs to contain
all packages that are in the image, regardless of when the packages were
built. Can you please open an issue in Bugzilla to track this ?

> While this delta in meaning is logical in terms of how Toaster collects
> data, the new result is that the "Packages Included" table is way
> incomplete as used in the GUI.
>
> We see this when we (re-)build a single recipe, where the "Packages
> Included" equals zero, which is misleading. We see this when we (re-)build
> an image, where the "Packages Included" equals some very unlikely low
> number. We will see this when we attempt to use the database to generate
> the license manifest file data, because most of the packages will be
> missing.
>
> The efficiency is good in that we are benefiting from our cache as
> intended. We however need a database method that will return _all_ packages
> included in a given image, including the cached ones, for the above uses in
> the GUI.
>
> David
>
> > -----Original Message-----
> > From: Barros Pena, Belen [mailto:belen.barros.pena at intel.com]
> > Sent: Tuesday, March 04, 2014 7:22 AM
> > To: DAMIAN, ALEXANDRU; Reyna, David
> > Cc: Wymore, Farrell; toaster at yoctoproject.org; Amit Kumar Chaudhary
> > Subject: Re: Question about Build Dashboard page
> >
> > On 04/03/2014 14:56, "Damian, Alexandru" <alexandru.damian at intel.com>
> > wrote:
> >
> > >Hello,
> > >
> > >After revieweing the license.manifest content, it appears that we
> already
> > >have this information (i.e package name, version, recipe name and
> > >license) already stored in the database.
> > >
> > >
> > >Therefore this seems rather a info display problem, and the file may not
> > >be needed. I'm postponing any modifications until Belen takes a decision
> > >either way about this bug.
> >
> > Right, I still think is worth displaying the path to the file, at least
> > for the current release where the main use case is still local. But the
> > information in it we already store and we can show it. The easiest thing
> > for the moment is turning the "License manifest" label into a link. I
> > think turning the path itself into a link will be a bit misleading: you
> > would probably expect that to download the real file, not to bring you
> > somewhere else in Toaster.
> >
> >
> > When you click the link, we bring you to the list of installed packages
> > (/gui/build/<build_id>/target/<target_id>/) with the following columns
> > shown:
> >
> > Package
> > Package version
> > License
> > Recipe
> >
> > That is exactly the same information you get in the license manifest
> file.
> >
> > Thoughts?
> >
> > Belén
> >
> >
> > >
> > >I'm pushing the wip-15022014 patchset ast it is to toaster/master, and
> > >I'm focusing on collecting correct data for the new database structure.
> > >
> > >Cheers,
> > >Alex
> > >
> > >
> > >
> > >
> > >On Tue, Mar 4, 2014 at 11:58 AM, Damian, Alexandru
> > ><alexandru.damian at intel.com> wrote:
> > >
> > >Hi,
> > >
> > >I have not seen any other reply to the review requested patchset for the
> > >DB changes.
> > >
> > >
> > >So I assume that this is the review, I will add the License Manifest
> > >field to Target_Image_File, and merge everything into toaster/master.
> > >
> > >
> > >There is not yet code for populating the data in there, I'm working on
> it.
> > >
> > >Cheers,
> > >
> > >Alex
> > >
> > >
> > >
> > >
> > >On Thu, Feb 27, 2014 at 9:54 PM, Reyna, David
> > ><david.reyna at windriver.com> wrote:
> > >
> > >Hi Alex and Belen,
> > >
> > >I am having Farrell complete the Build Dashboard page, merging in Amit¹s
> > >Error/Warning work when it is ready. We have reviewed your patch set
> that
> > >adds the ³Target_Image_File² table. It applied to Farrell¹s
> installation,
> > >and he is updating his code to
> > > use it.
> > >
> > >We do have two questions:
> > >  * We do not yet have a table member for the License Manifest.
> > >  * We did not see anywhere in the patch that populates the
> > >³Target_Image_File² table (Farrell is pushing simulated data in to the
> db
> > >for now).
> > >
> > >I think that we should accept your patch and push it so that I can also
> > >update the ³build.html² with the To-Do for the ³output² column.
> > >
> > >- David
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >--
> > >Alex Damian
> > >Yocto Project
> > >
> > >SSG / OTC
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >--
> > >Alex Damian
> > >Yocto Project
> > >
> > >SSG / OTC
> > >
> > >
> >
>
>

-- 
Alex Damian
Yocto Project
SSG / OTC
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/toaster/attachments/20140305/6f3217ab/attachment.html>