From: Joshua Lock <joshua.g.lock@linux.intel.com>
To: Alexander Kanavin <alexander.kanavin@linux.intel.com>,
"openembedded-core@lists.openembedded.org"
<openembedded-core@lists.openembedded.org>
Subject: Re: [PATCH] zlib: update SRC_URI to fix fetching
Date: Wed, 08 Feb 2017 14:23:09 +0000 [thread overview]
Message-ID: <1486563789.3754.14.camel@linux.intel.com> (raw)
In-Reply-To: <d1db8f00-0628-233f-2793-a7240f3fa4ea@linux.intel.com>
On Fri, 2017-01-13 at 17:53 +0200, Alexander Kanavin wrote:
> On 01/13/2017 05:36 PM, Joshua Lock wrote:
>
> > Running checkpkg on the autobuilders won't really help as the
> > autobuilders rely on the bitbake invocation returning a non-zero
> > exit
> > code to determine whether to mark the build step as failed, and
> > that's
> > not the case when checkpkg doesn't find an update version.
> >
> > If we regularly run checkpkg on the autobuilders how should we
> > detect
> > that a SRC_URI change has caused the upstream version check to
> > fail?
>
> - run bitbake -c checkpkg world
> - inspect tmp/log/checkpkg.csv for lines with 'UNKNOWN' upstream
> status,
> make a list of recipes that have it
> - compare that list against a stored list of exceptions (currently
> it
> would have about 32 entries), if the lists don't match exactly, the
> upstream version check has failed.
>
> All of this can be wrapped in poky/scripts/upstream-check-all
> perhaps.
Thanks, I've filed a bug to track implementing this feature:
https://bugzilla.yoctoproject.org/show_bug.cgi?id=11031
Joshua
prev parent reply other threads:[~2017-02-08 14:23 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-05 16:34 [PATCH] zlib: update SRC_URI to fix fetching Joshua Lock
2017-01-09 12:56 ` Alexander Kanavin
2017-01-13 13:00 ` Alexander Kanavin
2017-01-13 13:54 ` Joshua Lock
[not found] ` <1484315514.3828.2.camel@intel.com>
2017-01-13 14:18 ` Alexander Kanavin
2017-01-13 15:36 ` Joshua Lock
2017-01-13 15:53 ` Alexander Kanavin
2017-02-08 14:23 ` Joshua Lock [this message]
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=1486563789.3754.14.camel@linux.intel.com \
--to=joshua.g.lock@linux.intel.com \
--cc=alexander.kanavin@linux.intel.com \
--cc=openembedded-core@lists.openembedded.org \
/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.