[OE-core] [meta-oe][PATCH] dosfstools-2.11: Fix memory leak in mkdosfs

Khem Raj raj.khem at gmail.com
Sun Aug 9 17:03:25 UTC 2015


On Aug 9, 2015 9:21 AM, "Paul Eggleton" <paul.eggleton at linux.intel.com>
wrote:
>
> On Saturday 08 August 2015 11:54:45 Khem Raj wrote:
> > > On Aug 7, 2015, at 12:54 PM, Paul Eggleton <
paul.eggleton at linux.intel.com>
> > > wrote:>
> > > On Friday 07 August 2015 12:26:56 Khem Raj wrote:
> > >>> On Aug 7, 2015, at 2:51 AM, Paul Eggleton
> > >>> <paul.eggleton at linux.intel.com>
> > >>> wrote:>
> > >>>
> > >>> On Thursday 06 August 2015 19:52:28 Khem Raj wrote:
> > >>>> On Thu, Aug 6, 2015 at 2:25 AM, Paul Eggleton
> > >>>>
> > >>>> <paul.eggleton at linux.intel.com> wrote:
> > >>>>> On Thursday 06 August 2015 12:12:35 Alexander Kanavin wrote:
> > >>>>>> On 08/06/2015 12:06 PM, Amarnath Valluri wrote:
> > >>>>>>> Added new patch that fixes the memory leak that was introduced
in
> > >>>>>>> mkdosfs-dir.patch.
> > >>>>>>
> > >>>>>> You should update the original patch then, not pile additional
> > >>>>>> patches
> > >>>>>> on top. The least painful way is:
> > >>>>>>
> > >>>>>> 1) unpack the sources (manually from tarball, or using bitbake -c
> > >>>>>> unpack)
> > >>>>>> 2) 'git init; git add *; git commit' to create an git repository
from
> > >>>>>> the sources
> > >>>>>> 3) apply the patch that needs fixing, then do the fix
> > >>>>>> 4) make a git commit, then produce a patch using git
format-patch,
> > >>>>>> then
> > >>>>>> move the new patch back to the recipe directory and update the
recipe
> > >>>>>> 5) build the recipe to make sure it still builds
> > >>>>>> 6) make a git commit with the recipe update, and submit it here
:)
> > >>>>>
> > >>>>> On the contrary - the much less painful way (as of fido) is to use
> > >>>>> devtool:
> > >>>>>
> > >>>>> 1) Extract source and set the build system up to use it:
> > >>>>>  devtool modify dosfstools -x ~/projects/dosfstools
> > >>>>>
> > >>>>> 2) Make whatever changes you want to in the git tree that has
been set
> > >>>>> up
> > >>>>> in the specified path
> > >>>>>
> > >>>>> 3) Build the recipe (as you would normally) to make sure it still
> > >>>>> builds
> > >>>>>
> > >>>>> 4) Write the modified/added commits as patches back to the recipe:
> > >>>>>   devtool update-recipe dosfstools
> > >>>>>
> > >>>>> 5) Make a git commit with the recipe update, and submit it here :)
> > >>>>>
> > >>>>> I'd really like people to start using devtool for this kind of
thing.
> > >>>>> If
> > >>>>> it's not working for some reason please do let me know.
> > >>>>
> > >>>> This assumes either we use OE-Core or poky, I dont get it to work
with
> > >>>> angstrom out of box
> > >>>> what am I missing
> > >>>
> > >>> Well, whatever error / problem you are experiencing seems to be
missing
> > >>> at
> > >>> least ;)
> > >>
> > >> devtool modify dosfstools -x ~/projects/dosfstools
> > >> ERROR: This script can only be run after initialising the build
> > >> environment
> > >> (e.g. by using oe-init-build-env)
> > >>
> > >> so is it must now to use the setup script ? or can be extract some
needed
> > >> setup from it to let it work with setups not using the init script
> > >
> > > Well it needs to be able to run bitbake internally (directly and using
> > > tinfoil), hence the need to have the environment set up to do so. I
don't
> > > really see a way around that.
> >
> > Then limited use of  devtool should be documented as available
>
> How is this limited? It operates under the same conditions as bitbake
itself
> does.

Your last email indicated as if it always needs internal build environment.
If that's not the case then it's what I was requesting for the settings
that are required to execute it provided bitbake is in path and is building
fine but it's not using the settings provided by setup environment script
>
> Cheers,
> Paul
>
> --
>
> Paul Eggleton
> Intel Open Source Technology Centre
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20150809/f528f0e7/attachment-0002.html>


More information about the Openembedded-core mailing list