I've submitted your patch upstream after testing. Please wait until it's merged, and then mark Resolved/Fixed.
Alex On Tue, Mar 24, 2015 at 7:44 PM, Lerner, David M (Wind River) < [email protected]> wrote: > Hi Alex, > I'm not sure if you want me to take back ownership and mark it > Resolved/Fixed or if you are just suggesting a different alternative than > my patch and will handle it. > Dave > > > -----Original Message----- > > From: Damian, Alexandru [mailto:[email protected]] > > Sent: Tuesday, March 24, 2015 10:29 AM > > To: Lerner, Dave > > Cc: BARROS PENA, BELEN; [email protected] > > Subject: Re: [Toaster] [review-request] 7414-cut the prefix from layer > file paths for > > bitbake variables > > > > Hi, > > > > > > After thinking about the issue, if we mangle at build time, we'll have > trouble > > distinguishing between paths originating in the layer directories and > paths in the build > > directory. So the good solution is that we mangle the path at display > time, and I will > > be taking this patch. > > > > > > I have some more comments below, > > > > > > Cheers, > > > > Alex > > > > > > On Wed, Mar 18, 2015 at 3:48 PM, Lerner, David M (Wind River) > > <[email protected]> wrote: > > > > > > Alex, > > I've thought about this some more... see below. > > Dave > > > > > -----Original Message----- > > > From: Damian, Alexandru [mailto:[email protected]] > > > Sent: Tuesday, March 17, 2015 10:19 AM > > > To: BARROS PENA, BELEN > > > Cc: Lerner, Dave; [email protected] > > > Subject: Re: [Toaster] [review-request] 7414-cut the prefix from > layer file paths > > for > > > bitbake variables > > > > > > Hi, > > > > > > > > > Sorry for the significant delay in addressing this patch - I've > been a bit > > overwhelmed. > > > > It's not a significant delay and the delay is not a problem. > > > > > > > > > > > I am NOT taking this patch because of the way the layer matching > is done. > > > > > > > > > We already have local paths for layers present in the build in > the Layer object; > > we also > > > know _where_ the build took place, for we have > > > "build.buildrequest.buildenvironment.builddir" variable that > holds the path to > > the build > > > directory. > > > > Either there is a bug, or your claim isn't quite right regarding > > orm_layer.local_paths which are all empty or null for a yocto release > build. That was > > my first choice examining the database, but not possible since data was > missing. > > > > > > > > I should've been more clear than this. The layers which HAVE BEEN > built have local_path > > set to a correct value. The layers that we know about because they are > imported manually > > or from Layer Index, the local_path is NULL. The variables are always > attached to a > > build, so the layers on which the variables are modified will have > local_path set to > > something else than NULL. > > > > > > > > > > > > > > > We must verify that the file path starts with one of the layer > paths or the build > > > environment builddir path, and strip that leading path from the > full file path. > > > > > > > I agree that would make more sense, but that data isn't in the > table, and I believe > > due to performance reasons, that it should be done at display-a-page > time. > > > > > I would also expect this to be done at data logging time instead > of data display > > time > > > (i.e. in the buildinfohelper.py), with the distinct advantage of > speeding up page > > > processing time. > > > > > > Since build-time layer path extraction for the given database > structures penalizes > > all build times for the low likelihood that some user wants the path to > a layer, I would > > recommend adding just a little more processing time to the data logging > as follows: > > > > a) Constraining Layer.local_path to non-null, and always > populating that field, > > > > > > > > This is impossible due to the fact that we keep info about layers that > have not been > > checked-out in that table. > > > > > > > > > > b) normalizing things a bit by creating a new Model Config which > has: > > b1) the full path that was formerly in the (non-normalized) > > VariableHistory.file_name and > > b2) a foreign key to from Config to it's Layer, calculated once > > c) modifying (normalizing) orm_variablehistory > > c1) removing orm_variablehistory.file_name and > > c2) replacing that with a foreign key to it's defining Config > model. > > > > > > > > > > Yes, this makes sense. Still it wouldn't work 100% because some > variables are modified > > outside any Layer checkout (i.e. in the build directory). Having foreign > keys to > > different objects to re-compute the path in the "Config" model would be > unworkable in > > the queries sense. > > > > > > > > > > Then display time could just join on demand to find the config > file's layer's local > > path whenever the last bitbake path or history is required. > > > > Or else provide the display-time matching against a non-null > Layer.file_name, which > > would be much faster since the set of layers is of order 10^ and the > list to match is at > > most 150 variables(per page), still my first choice. > > > > Dave > > > > > > > > Thank you, > > > > > > Alex > > > > > > > My recommendations are: > > 1) to populate the Layer model with local_path in all cases, > changing the > > local_path to NOT NULL > > 2) perform the trim of variable names at display time, which > should be faster than > > penalizing builds with Config model updates, or variable defined file > stripping for > > every new config file read. > > OR) > > 3) add the Config model, update each variable log with the key to > the Config model. > > > > > > > > > > > > On Mon, Mar 16, 2015 at 3:41 PM, Barros Pena, Belen < > [email protected]> > > wrote: > > > > > > > > > > > > > > > On 16/03/2015 14:14, "Lerner, Dave" < > [email protected]> wrote: > > > > > > >Hi Belen, > > > > > > > >> -----Original Message----- > > > >> From: Barros Pena, Belen [mailto: > [email protected]] > > > >> Sent: Friday, March 13, 2015 9:17 AM > > > >> To: Lerner, Dave > > > >> Cc: [email protected] > > > >> Subject: Re: [review-request] 7414-cut the prefix from > layer file paths > > > >>for bitbake > > > >> variables > > > >> > > > >> Hi Dave, > > > >> > > > >> This is looking good. But I've realised I forgot about > something. Not > > > >>all > > > >> files setting variables are inside a layer: some of > them are > > > >>configuration > > > >> files inside the /build or /bitbake directories. > > > >> > > > >> I guess we should also cut those, showing only the path > inside the root > > > >> source directory. So something like > > > >> > > > >> /home/user/poky/build/conf/local.conf > > > >> > > > >> Would show as > > > >> > > > >> build/conf/local.conf > > > >> > > > >> I am not fully sure if this is the right thing to do, > so I'd be > > > >>interested > > > >> in hearing what you and the others think. > > > >> > > > >> I also realise this was not explicitly explained in the > original bug. If > > > >> you want me to open a separate issue in Bugzilla, I can > do so: just let > > > >>me > > > >> know. > > > > > > > >Please open a separate bug and give Alex the ok for > 7414. Layer relative > > > >makes sense to me, active-build-directory-relative does > not, too many > > > >questions "what is the relative to?" are raised. > > > > > > > > > > http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=lerner/trim_v > > > > > arpath_7414 < > http://git.yoctoproject.org/cgit/cgit.cgi/poky- > > > contrib/log/?h=lerner/trim_v arpath_7414> > > > > > > > > is good to go, then. I've opened this > > > > > > https://bugzilla.yoctoproject.org/show_bug.cgi?id=7463 > > > > > > for the configuration file paths. > > > > > > Cheers > > > > > > Belén > > > > > > > > > > > > > > > > >Dave > > > > > > > >> > > > >> Thanks! > > > >> > > > >> Belén > > > >> > > > >> On 12/03/2015 15:48, "Lerner, Dave" < > [email protected]> wrote: > > > >> > > > >> >rebased. > > > >> >Dave > > > >> > > > > >> >> -----Original Message----- > > > >> >> From: Lerner, Dave > > > >> >> Sent: Thursday, March 12, 2015 10:46 AM > > > >> >> To: Barros Pena, Belen ([email protected]) > > > >> >> Subject: RE: [review-request] 7414-cut the prefix > from layer file > > > >>paths > > > >> >>for bitbake > > > >> >> variables > > > >> >> > > > >> >> I don't think that I rebased (since Tuesday) before > I pushed. Can > > > >>you > > > >> >>hold off pulling > > > >> >> for 15 minutes? I'll send a note when rebased. > > > >> >> Dave > > > >> >> > > > >> >> > -----Original Message----- > > > >> >> > From: Lerner, Dave > > > >> >> > Sent: Thursday, March 12, 2015 10:29 AM > > > >> >> > To: Barros Pena, Belen ( > [email protected]); Damian, > > > >> >>Alexandru > > > >> >> > ([email protected]) > > > >> >> > Cc: [email protected] > > > >> >> > Subject: [review-request] 7414-cut the prefix from > layer file paths > > > >> >>for bitbake > > > >> >> > variables > > > >> >> > > > > >> >> > > > > >> > > > >>>> > http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=lerner/tr > > > >>>>im > > > >> >>_varpath_7414 > > > >> >> > > > > >> >> > > > > >> >> > Page Testing: > > > >> >> > Create project using yocto master which includes > openembedded-core, > > > >> >>meta-yocto and > > > >> >> meta- > > > >> >> > yocto-bsp, then add layers meta-oe, meta-games. > > > >> >> > Build the project. > > > >> >> > > > > >> >> > Open the build, configuration page, bitbake > variables. > > > >> >> > Note the following types of variable path names in > the "Set in > > > >>file" > > > >> >>column and when > > > >> >> > clicking the variable in the History. > > > >> >> > > > > >> >> > Variable: B > > > >> >> > Set in file/history: meta/conf/bitbake.conf > > > >> >> > > > > >> >> > Variable: BBFILE_PATTERN_core > > > >> >> > Set in file: full path to configure > > > >> >> > History: first meta/conf/layer.conf, then > > > >> >> > > /path/_poky_master.toaster_cloned/bitbake/lib/bb/data_smart.py > > > >> >> > > > > >> >> > Variable: BBFILE_PATTTERN_games-layers > > > >> >> > Set in file and History: > > > >> >>meta-games_master.toaster_cloned/conf/layer.conf > > > >> >> > > > > >> >> > > > > >> >> > HTML Validation: Pass > > > >> >> > Dave Lerner > > > >> > > > > > > > > > > -- > > > _______________________________________________ > > > toaster mailing list > > > [email protected] > > > https://lists.yoctoproject.org/listinfo/toaster > > > > > > > > > > > > > > > > > > -- > > > > > > Alex Damian > > > Yocto Project > > > > > > SSG / OTC > > > > > > > > > > > > -- > > > > Alex Damian > > Yocto Project > > > > SSG / OTC > -- Alex Damian Yocto Project SSG / OTC
-- _______________________________________________ toaster mailing list [email protected] https://lists.yoctoproject.org/listinfo/toaster
