From: Mike Looijmans <mike.looijmans@topic.nl>
To: Paul Eggleton <paul.eggleton@linux.intel.com>
Cc: Otavio Salvador <otavio@ossystems.com.br>,
openembedded-core@lists.openembedded.org
Subject: Re: Request to move "gitpkgv.bbclass" from meta-oe to oe-core
Date: Mon, 20 Oct 2014 16:00:33 +0200 [thread overview]
Message-ID: <54451581.6020409@topic.nl> (raw)
In-Reply-To: <1796874.7cz1rBMpRa@peggleto-mobl5.ger.corp.intel.com>
On 10/10/2014 05:03 PM, Paul Eggleton wrote:
> Hi Mike,
>
> On Friday 10 October 2014 07:36:25 Mike Looijmans wrote:
>> On 10/10/2014 12:15 AM, Otavio Salvador wrote:
>>> On Thu, Oct 9, 2014 at 4:56 PM, Richard Purdie
>>>
>>> <richard.purdie@linuxfoundation.org> wrote:
>>>> On Thu, 2014-10-09 at 10:16 +0200, Mike Looijmans wrote:
>>>>> In partial reply to my own question, this has been discussed 2 years
>>>>> ago, but apparently nothing ever came out of it.
>>>>>
>>>>> http://lists.openembedded.org/pipermail/openembedded-core/2012-February/
>>>>> 056050.html
>>>>>
>>>>> So once more the request to be able to get sane version strings for git
>>>>> repos. Can we please just move gitpkgv. That's like five minutes work,
>>>>> and if anyone (e.g. me) feels like building something better, he or she
>>>>> is free do submit that and get rid of the gitpkgv class once it's
>>>>> obsolete.
>>>>
>>>> I do feel quite strongly that this is something which should get
>>>> improved in the fetcher itself. That is why I've pushed back on the
>>>> patch since if I take it into OE-Core, there is even less incentive to
>>>> fix the real problem...
>>>
>>> Mike I am also an user of gitpkgv but I must to agree with Richard
>>> here. Moving this to OE-Core will just make it worse. It is way better
>>> to prepare a patch and add support for it on the fetcher code of
>>> BitBake.
>>
>> Give me some pointers on what you're talking about here, and I'll be happy
>> to try and implement it. Currently I have no idea as to what is "wrong"
>> with the gitpkgv approach, and I also have no clue as to what it is you
>> want to have implemented in the git fetcher.
>
> The code would go into the fetcher itself i.e. lib/bb/fetch2/git.py and
> lib/bb/fetch2/__init__.py.
>
> I'm not sure whether it would be a case of setting a variable in order to have
> the value of SRCPV within OE (which calls bb.fetch2.get_srcrev() ) return the
> "git describe" style version instead of the current one, or whether we would
> preserve the separate GITPKGVTAG variable for that purpose. (The GITPKGV case
> is already handled by the current behaviour of SRCPV, right?)
>
> FWIW there is an open bug covering this issue:
> https://bugzilla.yoctoproject.org/show_bug.cgi?id=2872
I followed that link a few clicks deeper and noticed that Richard Purdie
suggested adding another interface method, but I couldn't quite understand
what he meant here.
I figured that "sortable_revision" was the method that I needed to delve into.
However, it turned out that this one is called about 50 times when building a
single package, and i cannot really run any git commands at that spot it
seems, the current directory is not inside the repo.
So that's a fail (my trial code from git.py with some extra logger output below).
def sortable_revision(self, ud, d, name):
"""
Return a sortable revision number by counting commits in the history
"""
rev = self._build_revision(ud, d, name)
logger.warn("git.sortable_revision url=%s" % (ud.url))
localpath = ud.localpath
rev_file = os.path.join(localpath, "oe-gitpkgv_" + rev)
if not os.path.exists(localpath):
logger.warn("git.sortable_revision non-existent: %s" % (localpath))
commits = None
else:
if not os.path.exists(rev_file) or not os.path.getsize(rev_file):
from pipes import quote
commits = bb.fetch2.runfetchcmd(
"git rev-list %s -- 2> /dev/null | wc -l" % (quote(rev)),
d, quiet=True).strip().lstrip('0')
if commits:
os.unlink(rev_file)
open(rev_file, "w").write("%d\n" % int(commits))
else:
commits = open(rev_file, "r").readline(128).strip()
logger.warn("git.sortable_revision commits=%s\n" % (commits))
if commits:
return False, "%s+%s" % (commits, rev[:7])
else:
return True, str(rev)
Met vriendelijke groet / kind regards,
Mike Looijmans
TOPIC Embedded Systems
Eindhovenseweg 32-C, NL-5683 KH Best
Postbus 440, NL-5680 AK Best
Telefoon: (+31) (0) 499 33 69 79
Telefax: (+31) (0) 499 33 69 70
E-mail: mike.looijmans@topic.nl
Website: www.topic.nl
Please consider the environment before printing this e-mail
Topic zoekt gedreven (embedded) software specialisten!
http://topic.nl/vacatures/topic-zoekt-software-engineers/
next prev parent reply other threads:[~2014-10-20 14:00 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-08 14:39 Request to move "gitpkgv.bbclass" from meta-oe to oe-core Mike Looijmans
2014-10-09 8:16 ` Mike Looijmans
2014-10-09 19:56 ` Richard Purdie
2014-10-09 22:15 ` Otavio Salvador
2014-10-10 5:36 ` Mike Looijmans
2014-10-10 15:03 ` Paul Eggleton
2014-10-20 14:00 ` Mike Looijmans [this message]
2014-11-03 14:18 ` Mike Looijmans
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=54451581.6020409@topic.nl \
--to=mike.looijmans@topic.nl \
--cc=openembedded-core@lists.openembedded.org \
--cc=otavio@ossystems.com.br \
--cc=paul.eggleton@linux.intel.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 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.