Openembedded Core Discussions
 help / color / mirror / Atom feed
From: Trevor Woerner <twoerner@gmail.com>
To: Khem Raj <raj.khem@gmail.com>
Cc: Patches and discussions about the oe-core layer
	<openembedded-core@lists.openembedded.org>
Subject: Re: [PATCH] buildhistory.bbclass: metadata-revs show repo parent
Date: Sat, 12 Mar 2016 10:26:54 -0500	[thread overview]
Message-ID: <56E4353E.90002@gmail.com> (raw)
In-Reply-To: <CAMKF1spxHV_pMSVUqxDh4Z9iELQx1=pEmdTqs0GfCJWmmBfUFA@mail.gmail.com>



On 03/12/16 06:55, Khem Raj wrote:
> On Sat, Mar 12, 2016 at 1:33 PM, Trevor Woerner <twoerner@gmail.com> wrote:
>> To me, the purpose of buildhistory's metadata-revs is to enable someone else
>> (or myself in the future) to recreate a specific build, that's why I always
>> save this file with any build artifacts. Simply saying "meta" isn't good
>> enough because it doesn't specify which repository's "meta". So the purpose
>> of this patch is to try to clarify which repositories we're talking about.
>>
>>> Before:
>>>      meta              = master:00d3fd571a8d261d065b43f5cf3076a381843984
>>>      meta-oe           = master:a1e135a499998add7575682bf53db5e02e753580
>>>      meta-gnome        = master:a1e135a499998add7575682bf53db5e02e753580
>>>      meta-rpb          = master:203903ca6f4e8df09bef6ea3c6e899d07eca8df9
>>>      meta-96boards     = master:2be59f0d381b5ec173d7fc24f3ae14aaf47b8649
>>>      meta-qcom         = master:32fcda819acb8ec485d9ab05108d554f807bf75d
>>>      meta-browser      = master:a3789a4168fcd42f1cdf5b5febe2c779a9467919
>>>      meta-linaro-toolchain =
>>> master:367f784b831938dc508b7d472342d2d0d6ed9769
>>>      meta              = master:37b61b059031e3c272a929b834e12fd83f46598c
>>>      meta-poky         = master:37b61b059031e3c272a929b834e12fd83f46598c
>>>
>>> After:
>>>      openembedded-core/meta =
>>> master:00d3fd571a8d261d065b43f5cf3076a381843984
>>>      meta-openembedded/meta-oe =
>>> master:a1e135a499998add7575682bf53db5e02e753580
>>>      meta-openembedded/meta-gnome =
>>> master:a1e135a499998add7575682bf53db5e02e753580
>>>      meta-rpb          = master:203903ca6f4e8df09bef6ea3c6e899d07eca8df9
>>>      meta-96boards     = master:2be59f0d381b5ec173d7fc24f3ae14aaf47b8649
>>>      meta-qcom         = master:32fcda819acb8ec485d9ab05108d554f807bf75d
>>>      meta-browser      = master:a3789a4168fcd42f1cdf5b5febe2c779a9467919
>>>      meta-linaro/meta-linaro-toolchain =
>>> master:367f784b831938dc508b7d472342d2d0d6ed9769
>>>      meta-poky/meta    = master:37b61b059031e3c272a929b834e12fd83f46598c
>>>      meta-poky/meta-poky = master:37b61b059031e3c272a929b834e12fd83f46598c
>>
>> I have a second patch, now, that will generate the following output, which I
>> think is even better:
>>
>>      git://git.openembedded.org/openembedded-core.git
>>      openembedded-core/meta = master:00d3fd571a8d261d065b43f5cf3076a381843984
>>
>>      git://git.openembedded.org/meta-openembedded
>>      meta-openembedded/meta-oe =
>> master:a1e135a499998add7575682bf53db5e02e753580
>>
>>      git://git.openembedded.org/meta-openembedded
>>      meta-openembedded/meta-gnome =
>> master:a1e135a499998add7575682bf53db5e02e753580
>>
>>      git://github.com/96boards/meta-rpb.git
>>      meta-rpb          = master:203903ca6f4e8df09bef6ea3c6e899d07eca8df9
>>
>>      https://github.com/96boards/meta-96boards.git
>>      meta-96boards     = master:2be59f0d381b5ec173d7fc24f3ae14aaf47b8649
>>
>>      https://github.com/ndechesne/meta-qcom.git
>>      meta-qcom         = master:32fcda819acb8ec485d9ab05108d554f807bf75d
>>
>>      git://github.com/OSSystems/meta-browser.git
>>      meta-browser      = master:a3789a4168fcd42f1cdf5b5febe2c779a9467919
>>
>>      git://git.linaro.org/openembedded/meta-linaro.git
>>      meta-linaro/meta-linaro-toolchain =
>> master:367f784b831938dc508b7d472342d2d0d6ed9769
>>
>>      git://git.yoctoproject.org/poky
>>      meta-poky/meta    = master:37b61b059031e3c272a929b834e12fd83f46598c
>>
>>      git://git.yoctoproject.org/poky
>>      meta-poky/meta-poky = master:37b61b059031e3c272a929b834e12fd83f46598c
>>
>> Frankly, there are too many forks and clones. There are too many
>> meta-beaglebone or meta-odroid or meta-raspberrypi repositories. If six
>> months from now I want to recreate a build I've done today, I'll need to
>> know the repository, where it's from, and which commit was checked out. My
>> latest patch provides that information.
>>
>> Is this better?
> what happens if one has a local checkout forked from upstream branch ?
> it reports that one, so buildhistory is expecting you to control the repos
> e.g. when using tools like repo, it gets utterly confused since its meant
> to track local checkout SHAs not remote ones, may be your change
> can establish a better origin tracking. it would be interesting to see
> how it works with repo and when I have more than 1 remotes in a single
> repo

Here's how it handled a build that I have where the repositories are 
handled by the repo tool:

https://github.com/openembedded/openembedded-core
meta              = 
contrib/twoerner/buildhistory-patches:953046fa31617a0c53f66faacf3fa9ef88375dee

https://github.com/openembedded/meta-openembedded
../meta-openembedded/meta-oe = HEAD:dc5634968b270dde250690609f0015f881db81f2

https://github.com/openembedded/meta-openembedded
../meta-openembedded/meta-gnome = 
HEAD:dc5634968b270dde250690609f0015f881db81f2

https://github.com/96boards/meta-rpb
../meta-rpb       = HEAD:203903ca6f4e8df09bef6ea3c6e899d07eca8df9

https://github.com/96boards/meta-96boards
../meta-96boards  = HEAD:2be59f0d381b5ec173d7fc24f3ae14aaf47b8649

http://git.linaro.org/openembedded/meta-linaro
../meta-linaro/meta-linaro-toolchain = 
HEAD:395ca11e22c26bd0c26ea1078722628ba6aa2332

https://github.com/ndechesne/meta-qcom
../meta-qcom      = HEAD:32fcda819acb8ec485d9ab05108d554f807bf75d

https://github.com/linaro-home/meta-browser
../meta-browser   = HEAD:5c00d0114c5963a178cb33f6d06181c588c03ae0


My patch simply uses "git remote -v" and takes the first line. I'll look 
into reporting multiple remotes.

Local forks of upstream repositories would simply be reported as local 
repositories. I'm not even sure what I would do on the cmdline to figure 
out that sort of repository's origin, other than to manually work 
backwards until I found something that looked sensible.

In any case, the above is an improvement?


  reply	other threads:[~2016-03-12 15:26 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-12  2:49 [PATCH] buildhistory.bbclass: metadata-revs show repo parent Trevor Woerner
2016-03-12  3:59 ` Khem Raj
2016-03-12  4:28   ` Trevor Woerner
2016-03-12  5:33     ` Trevor Woerner
2016-03-12 11:55       ` Khem Raj
2016-03-12 15:26         ` Trevor Woerner [this message]
2016-03-12 21:54     ` Burton, Ross
2016-03-12 22:32       ` Trevor Woerner
2016-03-13 19:25         ` Paul Eggleton
2016-03-13  0:34 ` Trevor Woerner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=56E4353E.90002@gmail.com \
    --to=twoerner@gmail.com \
    --cc=openembedded-core@lists.openembedded.org \
    --cc=raj.khem@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox