All of lore.kernel.org
 help / color / mirror / Atom feed
From: Awais Belal <awais_belal@mentor.com>
To: <yocto@yoctoproject.org>
Subject: [meta-selinux][PATCH] refpolicy_git.inc: lock SRCREVs on the actual version hashes
Date: Fri, 5 Oct 2018 11:34:00 +0500	[thread overview]
Message-ID: <1538721240-17988-1-git-send-email-awais_belal@mentor.com> (raw)

Using AUTOREV in the main repository has its downsides.
1. The checked out version isn't actually the version depicted
   by PV.
2. Breaks builds in scenarios where network isn't available
   or BB_NO_NETWORK is used even after sources are already
   fetched.

1 is self explanatory, for 2 whenever SRCREV is set to AUTOREV and
SRCPV is used in PV the fetcher tries to access the network in order
to determine SRCPV (bb.fetch2.get_srcrev) and fails for obvious
reasons during parsing even when versioned recipes are used as
PREFERRED_VERSION because parsing still happens for recipes that are
in BB's search paths and we see.
Traceback (most recent call last):
bb.data_smart.ExpansionError: Failure expanding variable SRCPV, expression was ${@bb.fetch2.get_srcrev(d)} which triggered exception NetworkAccess: Network access disabled through BB_NO_NETWORK (or set indirectly due to use of BB_FETCH_PREMIRRORONLY) but access requested with command git -c core.fsyncobjectfiles=0 ls-remote git://github.com/TresysTechnology/refpolicy.git  (for url git://github.com/TresysTechnology/refpolicy.git)

So we lock the REVs and do that with a soft assignment which
allows overriding the REVs from elsewhere.

Signed-off-by: Awais Belal <awais_belal@mentor.com>
---
 recipes-security/refpolicy/refpolicy_git.inc | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/recipes-security/refpolicy/refpolicy_git.inc b/recipes-security/refpolicy/refpolicy_git.inc
index f71eb35..6c318ab 100644
--- a/recipes-security/refpolicy/refpolicy_git.inc
+++ b/recipes-security/refpolicy/refpolicy_git.inc
@@ -3,8 +3,8 @@ PV = "2.20170805+git${SRCPV}"
 SRC_URI = "git://github.com/TresysTechnology/refpolicy.git;protocol=git;branch=master;name=refpolicy;destsuffix=refpolicy"
 SRC_URI += "git://github.com/TresysTechnology/refpolicy-contrib.git;protocol=git;branch=master;name=refpolicy-contrib;destsuffix=refpolicy/policy/modules/contrib"
 
-SRCREV_refpolicy = "${AUTOREV}"
-SRCREV_refpolicy-contrib = "${AUTOREV}"
+SRCREV_refpolicy ?= "794ed7efd0eca19d0353659a1ec9d4ef4e4b751c"
+SRCREV_refpolicy-contrib ?= "a393275a6ecb76311323726a029767a3a01e109e"
 SRCREV_FORMAT = "refpolicy.refpolicy-contrib"
 
 FILESEXTRAPATHS_prepend := "${THISDIR}/refpolicy-git:"
-- 
2.7.4



                 reply	other threads:[~2018-10-05  6:34 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=1538721240-17988-1-git-send-email-awais_belal@mentor.com \
    --to=awais_belal@mentor.com \
    --cc=yocto@yoctoproject.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.