Upstreaming emerge improvements (was: Goodbye Frankenbuild: New workflow for correct incremental builds) - Chromium OS dev

The old Google Groups will be going away soon, but your browser is incompatible with the new version.
Message from discussion Upstreaming emerge improvements (was: Goodbye Frankenbuild: New workflow for correct incremental builds)
View parsed - Show only message text
Received-SPF: pass (google.com: domain of an...@google.com designates 172.24.198.13 as permitted sender)
DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns;
	h=mime-version:sender:in-reply-to:references:date:
	x-google-sender-auth:message-id:subject:from:to:cc:content-type:x-system-of-record;
	b=g3TXudefkd34weENwKJtXyx7m6iyFqD5VNq6Sd994AVCD+Emgb/wCFCMNvXddvEoR
	Ax2V1UVa8qSXgfzCk0RLg==
MIME-Version: 1.0
Sender: an...@google.com
In-Reply-To: <AANLkTim_HP6PmwXUYCcHakYi9A2ahF8whx-ovLMEq...@mail.gmail.com>
References: <AANLkTinmFRV2AunwuA2B40ZFTS+kkozETBFk__x5D...@mail.gmail.com>
	<20100728112212.GA5972@hrair>
	<4C50DD6E.7010...@gentoo.org>
	<AANLkTim_HP6PmwXUYCcHakYi9A2ahF8whx-ovLMEq...@mail.gmail.com>
Date: Fri, 30 Jul 2010 00:36:29 -0700
Message-ID: <AANLkTinQW87_BsXGCX0jU_9JKp4e8FaXaDAXgZoO3...@mail.gmail.com>
Subject: Re: [cros-dev] Re: Upstreaming emerge improvements (was: Goodbye 
	Frankenbuild: New workflow for correct incremental builds)
From: =?UTF-8?B?QW51c2ggRWxhbmdvdmFuKOCuheCuqeCvgeCut+CvjSk=?= <an...@chromium.org>
To: Zac Medico <zmed...@gentoo.org>
Cc: Brian Harring <ferri...@gmail.com>, David James <davidja...@google.com>,
        SebastianLut...@gmx.de, chromium-os-...@chromium.org,
        brian.dol...@gmail.com, Tien-Ren <trc...@google.com>
Content-Type: multipart/mixed; boundary=0015174a0d9ecbb8f1048c95e82d

--0015174a0d9ecbb8f1048c95e82d
Content-Type: multipart/alternative; boundary=0015174a0d9ecbb8e4048c95e82b

--0015174a0d9ecbb8e4048c95e82b
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Resending from the correct email address to get to the mailing list.

On Fri, Jul 30, 2010 at 12:34 AM, Anush Elangovan(=E0=AE=85=E0=AE=A9=E0=AF=
=81=E0=AE=B7=E0=AF=8D)
<an...@google.com>wrote:

> Zac,
>    Here is a patch Tien-Ren came up with for HDEPEND. CC'ing him too. He
> was planning on revising the patch. Just fyi.
>
> Thanks
> Anush
>
>
> On Wed, Jul 28, 2010 at 6:46 PM, Zac Medico <zmed...@gentoo.org> wrote:
>
>> On 07/28/2010 04:22 AM, Brian Harring wrote:
>> > On Tue, Jul 27, 2010 at 09:05:28AM -0400, David James wrote:
>> >> On Mon, Jul 26, 2010 at 10:06 PM, Brian Harring <ferri...@gmail.com>
>> wrote:
>> >>> If I may ask, is there a reason you didn't look at an EAPI with
>> >>> (essentially) ABI slots?  Such a route, while it requires specifying=
 a
>> >>> bit more info (or tweaking the manager to generate that info), would
>> >>> give fine grained control to the resolver for doing rebuilds of the
>> >>> sort mentioned above.
>> >>
>> >> Long term, I think that that's exactly what we want. Right now, it's
>> >> hard to tell which packages require dependencies to be rebuilt, and
>> >> which packages do not have this requirement. If there were an
>> >> automated way to tell which packages need their dependencies to be
>> >> rebuilt, that would be great.
>> >>
>> >> The ABI slot solution sounds good, as long as we don't have too many
>> >> packages where the maintainers specify their rebuild requirements
>> >> incorrectly (e.g., by breaking binary compatibility without realizing
>> >> it). If we found that this was a regular problem, we would probably
>> >> want to go back to just rebuilding all dependencies whenever a packag=
e
>> >> changes.
>> >
>> > Bad packaging metadata we can't really do much about realistically,
>> > beyond threaten to wedige the packaging dev- that said a DT_NEEDED
>> > validation QA check to ensure the targets are within stated rdeps
>> > might be useful.
>> >
>> > Doesn't do anything for dlopen or static, but it was one of the more
>> > useful features of the old EBD/saviour branch of portage- iirc I named
>> > that feature 'verify-linkage'.  Implementation was ldd based (ick),
>> > but it was a start.
>>
>> A notable advantage of giving the resolver the metadata (ABI slots)
>> to account for rebuilds in advance is that it allows for more
>> informed decisions with respect to aggressive --jobs
>> parallelization. Considering --fast chromium-os builds, this seems
>> like an area of interest.
>>
>> >>> Aside from that, I'd be very interested if there is an ML, irc
>> >>> channel, or any area people are doing discussions of this sort- I'm
>> >>> the author of pkgcore, long term hacker of portage
>> >>> (refactoring/cleanup- trying to combat the mess rather than creating
>> >>> it), and have been working on issues similar to what y'all have been
>> >>> rolling out.  What's been a bit problematic is that there isn't
>> >>> exactly a lot of people doing the level of binpkg work y'all are- th=
us
>> >>> finding stakeholders to bug for info has been pretty sparse.
>> >>
>> >> Personally, I'd be quite interested in this problem. The
>> >> chromium-os-dev list is fine for this type of discussion, but if you
>> >> have another mailing list that would be better, I'd be happy to join.
>> >
>> > Unfortunately I'm not particularly aware of any.  Typically I track
>> > down people in irc and pick their brains directly; that said from an
>> > irc standpoint #gentoo-portage on freenode is probably the best spot
>> > to catch the appropriate people (zac medico/zmedico, sebastian
>> > luther/zac, solar, myself) who would have interest/comments.
>>
>> The gentoo-portage-...@gentoo.org list seems applicable.
>>
>> >> Here are a few other suggestions about things to address in regular
>> emerge:
>> >>  1. To address package rebuilds completely correctly, we'll also need
>> >> to differentiate between host and target build dependencies. There's =
a
>> >> patch for this, but it looks like it got closed as a duplicate:
>> >>   http://bugs.gentoo.org/show_bug.cgi?id=3D317337
>> >
>> > This was proposed as "bdepends" at one point- build time depends,
>> > specifically what is executed during building the package (bash and
>> > sed for example).
>> >
>> > The problem w/ a new dependency type is mainly getting developer buy
>> > in- building tools to help developers track/validate these
>> > dependencies.  At least in the past, this sort of proposal died out
>> > since their wasn't a sufficient carrot (nor was it easy to modify
>> > portage for such a capability).
>>
>> Nowadays, it would be pretty trivial to add a BDEPEND variable or
>> something like that. Adding a new *DEPEND variable like this would
>> be a lot less invasive that trying to jump to a DEPENDENCIES
>> variable that unifies *DEPEND.
>>
>> >>  2. Strangely, Portage often favors the dependencies (and masking) of
>> >> built packages over the ebuilds you have in your package dir. I would
>> >> rather that Portage look at the ebuilds, because developers often
>> >> change the ebuilds and want their new ebuild to be prioritized over
>> >> the one that was already built. In parallel_emerge, we work around
>> >> this by setting --usepkg=3Dn for dependency calculation and then conv=
ert
>> >> the source package to a binary package at a later stage.
>> >
>> > Essentially you want binpkgs to be utilized strictly as a cache,
>> > right?  I suspect this isn't a particularly hard mod to implement for
>> > the folk who know the innards of _emerge.* reasonably well.
>>
>> I think maybe he's talking about updating the *DEPEND metadata of
>> the binary packages, so that they match the ebuilds. I have an old
>> script that does it:
>>
>> http://dev.gentoo.org/~zmedico/portage/branches/2.1/bin/vdb-tools.py
>>
>> You could update the metadata of all binary packages with this command:
>>
>>  vdb-tools.py --transfer --pkgtype=3Dbinary
>>
>> >>  3. Does Portage have public APIs for calculating dependencies and
>> >> merging packages? Right now, parallel_emerge uses private APIs but I
>> >> would like to convert it to public APIs if they exist.
>> >
>> > CC'ing the folk who could best answer this one- at this point, there
>> > isn't perse a public api for the most part.  I know they're currently
>> > trying to derive one for packagekit/porthole/SoC, but I'm not aware of
>> > it's status.
>>
>> Brian Dolbeck (porthole developer) has been working on this, but I'm
>> unsure of progress. I've CC'd him in case he wants to chime in.
>>
>> >>  4. Portage is a bit aggressive about locking directories, so this
>> >> makes parallel merging slow. Whenever a package is being merged,
>> >> Portage locks the entire package directory. This means essentially
>> >> that package merges do not occur in parallel at all. Is it possible t=
o
>> >> reduce the scope of the locking so that it does not have such a
>> >> significant effect on performance?
>> >
>> > Heh.  This is a contentious issue.  Roughly, everything after
>> > pkg_setup when it comes to merging is expected to be the only thing
>> > modifying the FS during this- the reasoning is purely due to
>> > pkg_preinst/pkg_postinst being essentially uncontrolled access to the
>> > livefs.  That critical locking unfortunately does need to exist if
>> > those phases are defined.  I'd expect in addition that the treewalk
>> > bits (the merger) wouldn't particularly like having a run in with
>> > another active merge at the same time.
>> >
>> > That said, the scope of the locking definitely should be reducable,
>> > and parallelization increased w/in the atomic locked merge.  Locking
>> > of the binpkgs repository in particular seems unneeded since
>> > effectively it's an untarring to ${D}, and unpacking the xpak (that
>> > annoying trailing data after EOS on tbzs) to ${T} w/in the pkgs build
>> > env.  After that that point, there shouldn't need to be any further
>> > locking on binpkgs- further creating a new binpkg doesn't require a
>> > write lock until you actually try to make it live w/in the binpkg repo
>> > (the final atomic rename), so at least the compression steps should be
>> > able to be done in parallel.
>>
>> Of course it can be done. Again, additional metadata for ABI slots
>> will be quite helpful for aggressive --jobs parallelization like this.
>>
>> >>  5. Some packages will make global system changes in their postinstal=
l
>> >> scripts, but these scripts are not parallel-safe. Can we make these
>> >> scripts parallel-safe? Currently, this is not a big problem for emerg=
e
>> >> because it just locks for the entire merge, including postinstall (se=
e
>> >> #4), but once we get rid of that lock it becomes a problem.
>> >
>> > I'm definitely open to suggestions of how to make them safe, but by
>> > pkg_(pre|post)(inst|rm)'s nature, they're free form root level
>> > execution.  From a format standpoint, for better or worse they
>> > technically can do whatever the hell they want, bounded only by QA
>> > standards of that particularly repository.
>> >
>> > I could see adding a PROPERTIES hint of some sort indicating that the
>> > locking isn't needed for that pkg offhand, although that's a bit of a
>> > hack.
>>
>> A PROPERTIES or RESTRICT flag sounds pretty reasonable to me. This
>> leads to the question of whether it should be opt-in or opt-out. We
>> could conceivably make the opt-in/opt-out behavior conditional on
>> EAPI, but maybe that won't be necessary.
>>
>> We could also add helpers for locking/unlocking resources. This
>> could be implemented in an eclass, but it might be nicer to had the
>> helpers on the package manager side (in a new EAPI).
>> --
>> Thanks,
>> Zac
>>
>> --
>> Chromium OS Developers mailing list: chromium-os-...@chromium.org
>> View archives, change email options, or unsubscribe:
>> http://groups.google.com/a/chromium.org/group/chromium-os-dev?hl=3Den
>>
>
>

--0015174a0d9ecbb8e4048c95e82b
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Resending from the correct email address to get to the mailing list.=C2=A0<=
br><br><div class=3D"gmail_quote">On Fri, Jul 30, 2010 at 12:34 AM, Anush E=
langovan(=E0=AE=85=E0=AE=A9=E0=AF=81=E0=AE=B7=E0=AF=8D) <span dir=3D"ltr">&=
lt;<a href=3D"mailto:an...@google.com">an...@google.com</a>&gt;</span> wrot=
e:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex;"><div>Zac,</div><div>=C2=A0=C2=A0 Here is a =
patch Tien-Ren came up with for HDEPEND. CC&#39;ing him too. He was plannin=
g on revising the patch. Just fyi.=C2=A0</div>
<div><br></div>Thanks<div>Anush<div><div></div><div class=3D"h5"><br><br><d=
iv class=3D"gmail_quote">On Wed, Jul 28, 2010 at 6:46 PM, Zac Medico <span =
dir=3D"ltr">&lt;<a href=3D"mailto:zmed...@gentoo.org" target=3D"_blank">zme=
d...@gentoo.org</a>&gt;</span> wrote:<br>

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div><div></div><div>On 07/28/2010 04:22 AM,=
 Brian Harring wrote:<br>
&gt; On Tue, Jul 27, 2010 at 09:05:28AM -0400, David James wrote:<br>
&gt;&gt; On Mon, Jul 26, 2010 at 10:06 PM, Brian Harring &lt;<a href=3D"mai=
lto:ferri...@gmail.com" target=3D"_blank">ferri...@gmail.com</a>&gt; wrote:=
<br>
&gt;&gt;&gt; If I may ask, is there a reason you didn&#39;t look at an EAPI=
 with<br>
&gt;&gt;&gt; (essentially) ABI slots? =C2=A0Such a route, while it requires=
 specifying a<br>
&gt;&gt;&gt; bit more info (or tweaking the manager to generate that info),=
 would<br>
&gt;&gt;&gt; give fine grained control to the resolver for doing rebuilds o=
f the<br>
&gt;&gt;&gt; sort mentioned above.<br>
&gt;&gt;<br>
&gt;&gt; Long term, I think that that&#39;s exactly what we want. Right now=
, it&#39;s<br>
&gt;&gt; hard to tell which packages require dependencies to be rebuilt, an=
d<br>
&gt;&gt; which packages do not have this requirement. If there were an<br>
&gt;&gt; automated way to tell which packages need their dependencies to be=
<br>
&gt;&gt; rebuilt, that would be great.<br>
&gt;&gt;<br>
&gt;&gt; The ABI slot solution sounds good, as long as we don&#39;t have to=
o many<br>
&gt;&gt; packages where the maintainers specify their rebuild requirements<=
br>
&gt;&gt; incorrectly (e.g., by breaking binary compatibility without realiz=
ing<br>
&gt;&gt; it). If we found that this was a regular problem, we would probabl=
y<br>
&gt;&gt; want to go back to just rebuilding all dependencies whenever a pac=
kage<br>
&gt;&gt; changes.<br>
&gt;<br>
&gt; Bad packaging metadata we can&#39;t really do much about realistically=
,<br>
&gt; beyond threaten to wedige the packaging dev- that said a DT_NEEDED<br>
&gt; validation QA check to ensure the targets are within stated rdeps<br>
&gt; might be useful.<br>
&gt;<br>
&gt; Doesn&#39;t do anything for dlopen or static, but it was one of the mo=
re<br>
&gt; useful features of the old EBD/saviour branch of portage- iirc I named=
<br>
&gt; that feature &#39;verify-linkage&#39;. =C2=A0Implementation was ldd ba=
sed (ick),<br>
&gt; but it was a start.<br>
<br>
</div></div>A notable advantage of giving the resolver the metadata (ABI sl=
ots)<br>
to account for rebuilds in advance is that it allows for more<br>
informed decisions with respect to aggressive --jobs<br>
parallelization. Considering --fast chromium-os builds, this seems<br>
like an area of interest.<br>
<div><br>
&gt;&gt;&gt; Aside from that, I&#39;d be very interested if there is an ML,=
 irc<br>
&gt;&gt;&gt; channel, or any area people are doing discussions of this sort=
- I&#39;m<br>
&gt;&gt;&gt; the author of pkgcore, long term hacker of portage<br>
&gt;&gt;&gt; (refactoring/cleanup- trying to combat the mess rather than cr=
eating<br>
&gt;&gt;&gt; it), and have been working on issues similar to what y&#39;all=
 have been<br>
&gt;&gt;&gt; rolling out. =C2=A0What&#39;s been a bit problematic is that t=
here isn&#39;t<br>
&gt;&gt;&gt; exactly a lot of people doing the level of binpkg work y&#39;a=
ll are- thus<br>
&gt;&gt;&gt; finding stakeholders to bug for info has been pretty sparse.<b=
r>
&gt;&gt;<br>
&gt;&gt; Personally, I&#39;d be quite interested in this problem. The<br>
&gt;&gt; chromium-os-dev list is fine for this type of discussion, but if y=
ou<br>
&gt;&gt; have another mailing list that would be better, I&#39;d be happy t=
o join.<br>
&gt;<br>
&gt; Unfortunately I&#39;m not particularly aware of any. =C2=A0Typically I=
 track<br>
&gt; down people in irc and pick their brains directly; that said from an<b=
r>
&gt; irc standpoint #gentoo-portage on freenode is probably the best spot<b=
r>
&gt; to catch the appropriate people (zac medico/zmedico, sebastian<br>
&gt; luther/zac, solar, myself) who would have interest/comments.<br>
<br>
</div>The <a href=3D"mailto:gentoo-portage-...@gentoo.org" target=3D"_blank=
">gentoo-portage-...@gentoo.org</a> list seems applicable.<br>
<div><br>
&gt;&gt; Here are a few other suggestions about things to address in regula=
r emerge:<br>
&gt;&gt; =C2=A01. To address package rebuilds completely correctly, we&#39;=
ll also need<br>
&gt;&gt; to differentiate between host and target build dependencies. There=
&#39;s a<br>
&gt;&gt; patch for this, but it looks like it got closed as a duplicate:<br=
>
&gt;&gt; =C2=A0 <a href=3D"http://bugs.gentoo.org/show_bug.cgi?id=3D317337"=
 target=3D"_blank">http://bugs.gentoo.org/show_bug.cgi?id=3D317337</a><br>
&gt;<br>
&gt; This was proposed as &quot;bdepends&quot; at one point- build time dep=
ends,<br>
&gt; specifically what is executed during building the package (bash and<br=
>
&gt; sed for example).<br>
&gt;<br>
&gt; The problem w/ a new dependency type is mainly getting developer buy<b=
r>
&gt; in- building tools to help developers track/validate these<br>
&gt; dependencies. =C2=A0At least in the past, this sort of proposal died o=
ut<br>
&gt; since their wasn&#39;t a sufficient carrot (nor was it easy to modify<=
br>
&gt; portage for such a capability).<br>
<br>
</div>Nowadays, it would be pretty trivial to add a BDEPEND variable or<br>
something like that. Adding a new *DEPEND variable like this would<br>
be a lot less invasive that trying to jump to a DEPENDENCIES<br>
variable that unifies *DEPEND.<br>
<div><br>
&gt;&gt; =C2=A02. Strangely, Portage often favors the dependencies (and mas=
king) of<br>
&gt;&gt; built packages over the ebuilds you have in your package dir. I wo=
uld<br>
&gt;&gt; rather that Portage look at the ebuilds, because developers often<=
br>
&gt;&gt; change the ebuilds and want their new ebuild to be prioritized ove=
r<br>
&gt;&gt; the one that was already built. In parallel_emerge, we work around=
<br>
&gt;&gt; this by setting --usepkg=3Dn for dependency calculation and then c=
onvert<br>
&gt;&gt; the source package to a binary package at a later stage.<br>
&gt;<br>
&gt; Essentially you want binpkgs to be utilized strictly as a cache,<br>
&gt; right? =C2=A0I suspect this isn&#39;t a particularly hard mod to imple=
ment for<br>
&gt; the folk who know the innards of _emerge.* reasonably well.<br>
<br>
</div>I think maybe he&#39;s talking about updating the *DEPEND metadata of=
<br>
the binary packages, so that they match the ebuilds. I have an old<br>
script that does it:<br>
<br>
<a href=3D"http://dev.gentoo.org/~zmedico/portage/branches/2.1/bin/vdb-tool=
s.py" target=3D"_blank">http://dev.gentoo.org/~zmedico/portage/branches/2.1=
/bin/vdb-tools.py</a><br>
<br>
You could update the metadata of all binary packages with this command:<br>
<br>
 =C2=A0vdb-tools.py --transfer --pkgtype=3Dbinary<br>
<div><br>
&gt;&gt; =C2=A03. Does Portage have public APIs for calculating dependencie=
s and<br>
&gt;&gt; merging packages? Right now, parallel_emerge uses private APIs but=
 I<br>
&gt;&gt; would like to convert it to public APIs if they exist.<br>
&gt;<br>
&gt; CC&#39;ing the folk who could best answer this one- at this point, the=
re<br>
&gt; isn&#39;t perse a public api for the most part. =C2=A0I know they&#39;=
re currently<br>
&gt; trying to derive one for packagekit/porthole/SoC, but I&#39;m not awar=
e of<br>
&gt; it&#39;s status.<br>
<br>
</div>Brian Dolbeck (porthole developer) has been working on this, but I&#3=
9;m<br>
unsure of progress. I&#39;ve CC&#39;d him in case he wants to chime in.<br>
<div><br>
&gt;&gt; =C2=A04. Portage is a bit aggressive about locking directories, so=
 this<br>
&gt;&gt; makes parallel merging slow. Whenever a package is being merged,<b=
r>
&gt;&gt; Portage locks the entire package directory. This means essentially=
<br>
&gt;&gt; that package merges do not occur in parallel at all. Is it possibl=
e to<br>
&gt;&gt; reduce the scope of the locking so that it does not have such a<br=
>
&gt;&gt; significant effect on performance?<br>
&gt;<br>
&gt; Heh. =C2=A0This is a contentious issue. =C2=A0Roughly, everything afte=
r<br>
&gt; pkg_setup when it comes to merging is expected to be the only thing<br=
>
&gt; modifying the FS during this- the reasoning is purely due to<br>
&gt; pkg_preinst/pkg_postinst being essentially uncontrolled access to the<=
br>
&gt; livefs. =C2=A0That critical locking unfortunately does need to exist i=
f<br>
&gt; those phases are defined. =C2=A0I&#39;d expect in addition that the tr=
eewalk<br>
&gt; bits (the merger) wouldn&#39;t particularly like having a run in with<=
br>
&gt; another active merge at the same time.<br>
&gt;<br>
&gt; That said, the scope of the locking definitely should be reducable,<br=
>
&gt; and parallelization increased w/in the atomic locked merge. =C2=A0Lock=
ing<br>
&gt; of the binpkgs repository in particular seems unneeded since<br>
&gt; effectively it&#39;s an untarring to ${D}, and unpacking the xpak (tha=
t<br>
&gt; annoying trailing data after EOS on tbzs) to ${T} w/in the pkgs build<=
br>
&gt; env. =C2=A0After that that point, there shouldn&#39;t need to be any f=
urther<br>
&gt; locking on binpkgs- further creating a new binpkg doesn&#39;t require =
a<br>
&gt; write lock until you actually try to make it live w/in the binpkg repo=
<br>
&gt; (the final atomic rename), so at least the compression steps should be=
<br>
&gt; able to be done in parallel.<br>
<br>
</div>Of course it can be done. Again, additional metadata for ABI slots<br=
>
will be quite helpful for aggressive --jobs parallelization like this.<br>
<div><br>
&gt;&gt; =C2=A05. Some packages will make global system changes in their po=
stinstall<br>
&gt;&gt; scripts, but these scripts are not parallel-safe. Can we make thes=
e<br>
&gt;&gt; scripts parallel-safe? Currently, this is not a big problem for em=
erge<br>
&gt;&gt; because it just locks for the entire merge, including postinstall =
(see<br>
&gt;&gt; #4), but once we get rid of that lock it becomes a problem.<br>
&gt;<br>
&gt; I&#39;m definitely open to suggestions of how to make them safe, but b=
y<br>
&gt; pkg_(pre|post)(inst|rm)&#39;s nature, they&#39;re free form root level=
<br>
&gt; execution. =C2=A0From a format standpoint, for better or worse they<br=
>
&gt; technically can do whatever the hell they want, bounded only by QA<br>
&gt; standards of that particularly repository.<br>
&gt;<br>
&gt; I could see adding a PROPERTIES hint of some sort indicating that the<=
br>
&gt; locking isn&#39;t needed for that pkg offhand, although that&#39;s a b=
it of a<br>
&gt; hack.<br>
<br>
</div>A PROPERTIES or RESTRICT flag sounds pretty reasonable to me. This<br=
>
leads to the question of whether it should be opt-in or opt-out. We<br>
could conceivably make the opt-in/opt-out behavior conditional on<br>
EAPI, but maybe that won&#39;t be necessary.<br>
<br>
We could also add helpers for locking/unlocking resources. This<br>
could be implemented in an eclass, but it might be nicer to had the<br>
helpers on the package manager side (in a new EAPI).<br>
--<br>
Thanks,<br>
<font color=3D"#888888">Zac<br>
</font><div><div></div><div><br>
--<br>
Chromium OS Developers mailing list: <a href=3D"mailto:chromium-os-dev@chro=
mium.org" target=3D"_blank">chromium-os-...@chromium.org</a><br>
View archives, change email options, or unsubscribe:<br>
<a href=3D"http://groups.google.com/a/chromium.org/group/chromium-os-dev?hl=
=3Den" target=3D"_blank">http://groups.google.com/a/chromium.org/group/chro=
mium-os-dev?hl=3Den</a><br>
</div></div></blockquote></div><br></div></div></div>
</blockquote></div><br>

--0015174a0d9ecbb8e4048c95e82b--
--0015174a0d9ecbb8f1048c95e82d
Content-Type: application/octet-stream; name="portage-20100626-hdepend.diff"
Content-Disposition: attachment; filename="portage-20100626-hdepend.diff"
Content-Transfer-Encoding: base64
X-Attachment-Id: f_gc8pu0wl0

ZGlmZiAtLWdpdCBhL2Jpbi9lYnVpbGQuc2ggYi9iaW4vZWJ1aWxkLnNoCmluZGV4IDk3ODQyOTgu
LjlhYWJmYWUgMTAwNzU1Ci0tLSBhL2Jpbi9lYnVpbGQuc2gKKysrIGIvYmluL2VidWlsZC5zaApA
QCAtMTI1Niw2ICsxMjU2LDcgQEAgaW5oZXJpdCgpIHsKIAlsb2NhbCBCX0RFUEVORAogCWxvY2Fs
IEJfUkRFUEVORAogCWxvY2FsIEJfUERFUEVORAorCWxvY2FsIEJfSERFUEVORAogCXdoaWxlIFsg
IiQxIiBdOyBkbwogCQlsb2NhdGlvbj0iJHtFQ0xBU1NESVJ9LyR7MX0uZWNsYXNzIgogCQlvbG9j
YXRpb249IiIKQEAgLTEyOTQsMTkgKzEyOTUsMjAgQEAgaW5oZXJpdCgpIHsKIAkJCQlFQlVJTERf
T1ZFUkxBWV9FQ0xBU1NFUz0iJHtFQlVJTERfT1ZFUkxBWV9FQ0xBU1NFU30gJHtsb2NhdGlvbn0i
CiAJCWZpCiAKLQkJI1dlIG5lZWQgdG8gYmFjayB1cCB0aGUgdmFsdWUgb2YgREVQRU5EIGFuZCBS
REVQRU5EIHRvIEJfREVQRU5EIGFuZCBCX1JERVBFTkQKKwkJI1dlIG5lZWQgdG8gYmFjayB1cCB0
aGUgdmFsdWUgb2YgREVQRU5ELCBSREVQRU5EIGFuZCBIREVQRU5EIHRvIEJfREVQRU5ELCBCX1JE
RVBFTkQgYW5kIEJfSERFUEVORAogCQkjKGlmIHNldCkuLiBhbmQgdGhlbiByZXN0b3JlIHRoZW0g
YWZ0ZXIgdGhlIGluaGVyaXQgY2FsbC4KIAogCQkjdHVybiBvZmYgZ2xvYiBleHBhbnNpb24KIAkJ
c2V0IC1mCiAKIAkJIyBSZXRhaW4gdGhlIG9sZCBkYXRhIGFuZCByZXN0b3JlIGl0IGxhdGVyLgot
CQl1bnNldCBCX0lVU0UgQl9ERVBFTkQgQl9SREVQRU5EIEJfUERFUEVORAorCQl1bnNldCBCX0lV
U0UgQl9ERVBFTkQgQl9SREVQRU5EIEJfUERFUEVORCBCX0hERVBFTkQKIAkJWyAiJHtJVVNFK3Nl
dH0iICAgICAgID0gc2V0IF0gJiYgQl9JVVNFPSIke0lVU0V9IgogCQlbICIke0RFUEVORCtzZXR9
IiAgICAgPSBzZXQgXSAmJiBCX0RFUEVORD0iJHtERVBFTkR9IgogCQlbICIke1JERVBFTkQrc2V0
fSIgICAgPSBzZXQgXSAmJiBCX1JERVBFTkQ9IiR7UkRFUEVORH0iCiAJCVsgIiR7UERFUEVORCtz
ZXR9IiAgICA9IHNldCBdICYmIEJfUERFUEVORD0iJHtQREVQRU5EfSIKLQkJdW5zZXQgSVVTRSBE
RVBFTkQgUkRFUEVORCBQREVQRU5ECisJCVsgIiR7SERFUEVORCtzZXR9IiAgICA9IHNldCBdICYm
IEJfSERFUEVORD0iJHtIREVQRU5EfSIKKwkJdW5zZXQgSVVTRSBERVBFTkQgUkRFUEVORCBQREVQ
RU5EIEhERVBFTkQKIAkJI3R1cm4gb24gZ2xvYiBleHBhbnNpb24KIAkJc2V0ICtmCiAKQEAgLTEz
MjEsNiArMTMyMyw3IEBAIGluaGVyaXQoKSB7CiAJCVsgIiR7REVQRU5EK3NldH0iICAgICA9IHNl
dCBdICYmIGV4cG9ydCBFX0RFUEVORD0iJHtFX0RFUEVORH0gJHtERVBFTkR9IgogCQlbICIke1JE
RVBFTkQrc2V0fSIgICAgPSBzZXQgXSAmJiBleHBvcnQgRV9SREVQRU5EPSIke0VfUkRFUEVORH0g
JHtSREVQRU5EfSIKIAkJWyAiJHtQREVQRU5EK3NldH0iICAgID0gc2V0IF0gJiYgZXhwb3J0IEVf
UERFUEVORD0iJHtFX1BERVBFTkR9ICR7UERFUEVORH0iCisJCVsgIiR7SERFUEVORCtzZXR9IiAg
ICA9IHNldCBdICYmIGV4cG9ydCBFX0hERVBFTkQ9IiR7RV9IREVQRU5EfSAke0hERVBFTkR9Igog
CiAJCVsgIiR7Ql9JVVNFK3NldH0iICAgICA9IHNldCBdICYmIElVU0U9IiR7Ql9JVVNFfSIKIAkJ
WyAiJHtCX0lVU0Urc2V0fSIgICAgID0gc2V0IF0gfHwgdW5zZXQgSVVTRQpAQCAtMTMzNCw2ICsx
MzM3LDkgQEAgaW5oZXJpdCgpIHsKIAkJWyAiJHtCX1BERVBFTkQrc2V0fSIgID0gc2V0IF0gJiYg
UERFUEVORD0iJHtCX1BERVBFTkR9IgogCQlbICIke0JfUERFUEVORCtzZXR9IiAgPSBzZXQgXSB8
fCB1bnNldCBQREVQRU5ECiAKKwkJWyAiJHtCX0hERVBFTkQrc2V0fSIgID0gc2V0IF0gJiYgSERF
UEVORD0iJHtCX0hERVBFTkR9IgorCQlbICIke0JfSERFUEVORCtzZXR9IiAgPSBzZXQgXSB8fCB1
bnNldCBIREVQRU5ECisKIAkJI3R1cm4gb24gZ2xvYiBleHBhbnNpb24KIAkJc2V0ICtmCiAKQEAg
LTE1OTMsNyArMTU5OSw3IEBAIHNvdXJjZV9hbGxfYmFzaHJjcygpIHsKICMgd2hlbiBwb3J0YWdl
IGlzIHVwZ3JhZGluZyBpdHNlbGYuCiAKIFJFQURPTkxZX0VCVUlMRF9NRVRBREFUQT0iREVGSU5F
RF9QSEFTRVMgREVQRU5EIERFU0NSSVBUSU9OCi0JRUFQSSBIT01FUEFHRSBJTkhFUklURUQgSVVT
RSBLRVlXT1JEUyBMSUNFTlNFCisJRUFQSSBIREVQRU5EIEhPTUVQQUdFIElOSEVSSVRFRCBJVVNF
IEtFWVdPUkRTIExJQ0VOU0UKIAlQREVQRU5EIFBST1ZJREUgUkRFUEVORCBSRVNUUklDVCBTTE9U
IFNSQ19VUkkiCiAKIFJFQURPTkxZX1BPUlRBR0VfVkFSUz0iRCBFQlVJTEQgRUJVSUxEX1BIQVNF
IFwKQEAgLTE3NjcsNyArMTc3Myw3IEBAIHByZXByb2Nlc3NfZWJ1aWxkX2VudigpIHsKIGV4cG9y
dCBTQU5EQk9YX09OPSIxIgogZXhwb3J0IFM9JHtXT1JLRElSfS8ke1B9CiAKLXVuc2V0IEVfSVVT
RSBFX0RFUEVORCBFX1JERVBFTkQgRV9QREVQRU5ECit1bnNldCBFX0lVU0UgRV9ERVBFTkQgRV9S
REVQRU5EIEVfUERFUEVORCBFX0hERVBFTkQKIAogIyBUdXJuIG9mIGV4dGVuZGVkIGdsb2IgbWF0
Y2hpbmcgc28gdGhhdCBnKysgZG9lc24ndCBnZXQgaW5jb3JyZWN0bHkgbWF0Y2hlZC4KIHNob3B0
IC11IGV4dGdsb2IKQEAgLTE4NzEsNyArMTg3Nyw3IEBAIGlmICEgaGFzcSAiJEVCVUlMRF9QSEFT
RSIgY2xlYW4gY2xlYW5ybSA7IHRoZW4KIAkJIyBJbiBvcmRlciB0byBlbnN1cmUgY29ycmVjdCBp
bnRlcmFjdGlvbiBiZXR3ZWVuIGVidWlsZHMgYW5kCiAJCSMgZWNsYXNzZXMsIHRoZXkgbmVlZCB0
byBiZSB1bnNldCBiZWZvcmUgdGhpcyBwcm9jZXNzIG9mCiAJCSMgaW50ZXJhY3Rpb24gYmVnaW5z
LgotCQl1bnNldCBERVBFTkQgUkRFUEVORCBQREVQRU5EIElVU0UKKwkJdW5zZXQgREVQRU5EIFJE
RVBFTkQgUERFUEVORCBIREVQRU5EIElVU0UKIAogCQlpZiBbWyAkUE9SVEFHRV9ERUJVRyAhPSAx
IHx8ICR7LS94L30gIT0gJC0gXV0gOyB0aGVuCiAJCQlzb3VyY2UgIiRFQlVJTEQiIHx8IGRpZSAi
ZXJyb3Igc291cmNpbmcgZWJ1aWxkIgpAQCAtMTg5NCwxMyArMTkwMCwxOSBAQCBpZiAhIGhhc3Eg
IiRFQlVJTERfUEhBU0UiIGNsZWFuIGNsZWFucm0gOyB0aGVuCiAJCQlkZWJ1Zy1wcmludCAiUkRF
UEVORDogbm90IHNldC4uLiBTZXR0aW5nIHRvOiAke0RFUEVORH0iCiAJCWZpCiAKKwkJaWYgaGFz
ICIkRUFQSSIgMCAxIDIgMyAzX3ByZTIgOyB0aGVuCisJCQlleHBvcnQgSERFUEVORD0ke0hERVBF
TkQtJHtERVBFTkR9fQorCQkJZGVidWctcHJpbnQgIkhERVBFTkQ6IG5vdCBzZXQuLi4gU2V0dGlu
ZyB0bzogJHtERVBFTkR9IgorCQlmaQorCiAJCSMgYWRkIGluIGRlcGVuZGVuY3kgaW5mbyBmcm9t
IGVjbGFzc2VzCiAJCUlVU0U9IiR7SVVTRX0gJHtFX0lVU0V9IgogCQlERVBFTkQ9IiR7REVQRU5E
fSAke0VfREVQRU5EfSIKIAkJUkRFUEVORD0iJHtSREVQRU5EfSAke0VfUkRFUEVORH0iCiAJCVBE
RVBFTkQ9IiR7UERFUEVORH0gJHtFX1BERVBFTkR9IgorCQlIREVQRU5EPSIke0hERVBFTkR9ICR7
RV9IREVQRU5EfSIKIAotCQl1bnNldCBFQ0xBU1MgRV9JVVNFIEVfREVQRU5EIEVfUkRFUEVORCBF
X1BERVBFTkQKKwkJdW5zZXQgRUNMQVNTIEVfSVVTRSBFX0RFUEVORCBFX1JERVBFTkQgRV9QREVQ
RU5EIEVfSERFUEVORAogCiAJCSMgYWxwaGFiZXRpY2FsbHkgb3JkZXJlZCBieSAkRUJVSUxEX1BI
QVNFIHZhbHVlCiAJCWNhc2UgIiRFQVBJIiBpbgpAQCAtMjE0NSw3ICsyMTU3LDcgQEAgZWJ1aWxk
X21haW4oKSB7CiAKIAkJYXV4ZGJrZXlzPSJERVBFTkQgUkRFUEVORCBTTE9UIFNSQ19VUkkgUkVT
VFJJQ1QgSE9NRVBBR0UgTElDRU5TRQogCQkJREVTQ1JJUFRJT04gS0VZV09SRFMgSU5IRVJJVEVE
IElVU0UgVU5VU0VEXzAwIFBERVBFTkQgUFJPVklERSBFQVBJCi0JCQlQUk9QRVJUSUVTIERFRklO
RURfUEhBU0VTIFVOVVNFRF8wNSBVTlVTRURfMDQKKwkJCVBST1BFUlRJRVMgREVGSU5FRF9QSEFT
RVMgSERFUEVORCBVTlVTRURfMDQKIAkJCVVOVVNFRF8wMyBVTlVTRURfMDIgVU5VU0VEXzAxIgog
CiAJCSN0aGUgZXh0cmEgJChlY2hvKSBjb21tYW5kcyByZW1vdmUgbmV3bGluZXMKZGlmZiAtLWdp
dCBhL3B5bS9fZW1lcmdlL1BhY2thZ2UucHkgYi9weW0vX2VtZXJnZS9QYWNrYWdlLnB5CmluZGV4
IGJiYTU1Y2EuLjgxYTMzOGQgMTAwNjQ0Ci0tLSBhL3B5bS9fZW1lcmdlL1BhY2thZ2UucHkKKysr
IGIvcHltL19lbWVyZ2UvUGFja2FnZS5weQpAQCAtMzAsNyArMzAsNyBAQCBjbGFzcyBQYWNrYWdl
KFRhc2spOgogCQkiSU5IRVJJVEVEIiwgIklVU0UiLCAiS0VZV09SRFMiLAogCQkiTElDRU5TRSIs
ICJQREVQRU5EIiwgIlBST1ZJREUiLCAiUkRFUEVORCIsCiAJCSJyZXBvc2l0b3J5IiwgIlBST1BF
UlRJRVMiLCAiUkVTVFJJQ1QiLCAiU0xPVCIsICJVU0UiLAotCQkiX210aW1lXyIsICJERUZJTkVE
X1BIQVNFUyJdCisJCSJfbXRpbWVfIiwgIkRFRklORURfUEhBU0VTIiwgIkhERVBFTkQiXQogCiAJ
ZGVmIF9faW5pdF9fKHNlbGYsICoqa3dhcmdzKToKIAkJVGFzay5fX2luaXRfXyhzZWxmLCAqKmt3
YXJncykKZGlmZiAtLWdpdCBhL3B5bS9fZW1lcmdlL2RlcGdyYXBoLnB5IGIvcHltL19lbWVyZ2Uv
ZGVwZ3JhcGgucHkKaW5kZXggYTQ2NmU3ZC4uNmUyZGVhZiAxMDA2NDQKLS0tIGEvcHltL19lbWVy
Z2UvZGVwZ3JhcGgucHkKKysrIGIvcHltL19lbWVyZ2UvZGVwZ3JhcGgucHkKQEAgLTExMjgsNyAr
MTEyOCw3IEBAIGNsYXNzIGRlcGdyYXBoKG9iamVjdCk6CiAJCXJlbW92YWxfYWN0aW9uID0gInJl
bW92ZSIgaW4gc2VsZi5fZHluYW1pY19jb25maWcubXlwYXJhbXMKIAogCQllZGVwZW5kPXt9Ci0J
CWRlcGtleXMgPSBbIkRFUEVORCIsIlJERVBFTkQiLCJQREVQRU5EIl0KKwkJZGVwa2V5cyA9IFsi
REVQRU5EIiwiUkRFUEVORCIsIlBERVBFTkQiLCJIREVQRU5EIl0KIAkJZm9yIGsgaW4gZGVwa2V5
czoKIAkJCWVkZXBlbmRba10gPSBtZXRhZGF0YVtrXQogCkBAIC0xMTUzLDIzICsxMTUzLDI4IEBA
IGNsYXNzIGRlcGdyYXBoKG9iamVjdCk6CiAJCQllbHNlOgogCQkJCSMgYnVpbHQgcGFja2FnZXMg
ZG8gbm90IGhhdmUgYnVpbGQgdGltZSBkZXBlbmRlbmNpZXMuCiAJCQkJZWRlcGVuZFsiREVQRU5E
Il0gPSAiIgorCQkJCWVkZXBlbmRbIkhERVBFTkQiXSA9ICIiCiAKIAkJaWYgcmVtb3ZhbF9hY3Rp
b24gYW5kIHNlbGYuX2Zyb3plbl9jb25maWcubXlvcHRzLmdldCgiLS13aXRoLWJkZXBzIiwgInki
KSA9PSAibiI6CiAJCQllZGVwZW5kWyJERVBFTkQiXSA9ICIiCi0KLQkJaWYgcmVtb3ZhbF9hY3Rp
b246Ci0JCQliZGVwc19yb290ID0gbXlyb290Ci0JCWVsc2U6Ci0JCQliZGVwc19yb290ID0gIi8i
Ci0JCQlyb290X2RlcHMgPSBzZWxmLl9mcm96ZW5fY29uZmlnLm15b3B0cy5nZXQoIi0tcm9vdC1k
ZXBzIikKLQkJCWlmIHJvb3RfZGVwcyBpcyBub3QgTm9uZToKLQkJCQlpZiByb290X2RlcHMgaXMg
VHJ1ZToKLQkJCQkJYmRlcHNfcm9vdCA9IG15cm9vdAotCQkJCWVsaWYgcm9vdF9kZXBzID09ICJy
ZGVwcyI6Ci0JCQkJCWVkZXBlbmRbIkRFUEVORCJdID0gIiIKKwkJCWVkZXBlbmRbIkhERVBFTkQi
XSA9ICIiCisKKwkJcm9vdF9kZXBzID0gc2VsZi5fZnJvemVuX2NvbmZpZy5teW9wdHMuZ2V0KCIt
LXJvb3QtZGVwcyIpCisJCWlmIHJvb3RfZGVwcyBpcyBOb25lOgorCQkJZWRlcGVuZFsiSERFUEVO
RCJdLCBlZGVwZW5kWyJERVBFTkQiXSA9IGVkZXBlbmRbIkRFUEVORCJdLCAiIgorCQllbGlmIHJv
b3RfZGVwcyBpcyBUcnVlOgorCQkJZWRlcGVuZFsiSERFUEVORCJdID0gIiIKKwkJZWxpZiByb290
X2RlcHMgPT0gInJkZXBzIjoKKwkJCWVkZXBlbmRbIkhERVBFTkQiXSA9IGVkZXBlbmRbIkRFUEVO
RCJdID0gIiIKKwkJZWxpZiByb290X2RlcHMgIT0gImhkZXBzIjoKKwkJCXJhaXNlIFZhbHVlRXJy
b3IsICJpbnZhbGlkIC0tcm9vdC1kZXBzIGFyZ3VtZW50IgogCiAJCWRlcHMgPSAoCi0JCQkoYmRl
cHNfcm9vdCwgZWRlcGVuZFsiREVQRU5EIl0sCisJCQkoIi8iLCBlZGVwZW5kWyJIREVQRU5EIl0s
CisJCQkJc2VsZi5fcHJpb3JpdHkoYnVpbGR0aW1lPShub3QgYmRlcHNfb3B0aW9uYWwpLAorCQkJ
CW9wdGlvbmFsPWJkZXBzX29wdGlvbmFsKSwKKwkJCQlwa2cuYnVpbHQpLAorCQkJKG15cm9vdCwg
ZWRlcGVuZFsiREVQRU5EIl0sCiAJCQkJc2VsZi5fcHJpb3JpdHkoYnVpbGR0aW1lPShub3QgYmRl
cHNfb3B0aW9uYWwpLAogCQkJCW9wdGlvbmFsPWJkZXBzX29wdGlvbmFsKSwKIAkJCQlwa2cuYnVp
bHQpLApkaWZmIC0tZ2l0IGEvcHltL19lbWVyZ2UvaGVscC5weSBiL3B5bS9fZW1lcmdlL2hlbHAu
cHkKaW5kZXggZmQ0OWFkZS4uZWZjOGI3NCAxMDA2NDQKLS0tIGEvcHltL19lbWVyZ2UvaGVscC5w
eQorKysgYi9weW0vX2VtZXJnZS9oZWxwLnB5CkBAIC01NjcsNyArNTY3LDcgQEAgZGVmIGhlbHAo
bXlvcHRzLCBoYXZlY29sb3I9MSk6CiAJCWZvciBsaW5lIGluIHdyYXAoZGVzYywgZGVzY193aWR0
aCk6CiAJCQlwcmludChkZXNjX2luZGVudCArIGxpbmUpCiAJCXByaW50KCkKLQkJcHJpbnQoIiAg
ICAgICAiK2dyZWVuKCItLXJvb3QtZGVwc1s9cmRlcHNdIikpCisJCXByaW50KCIgICAgICAgIitn
cmVlbigiLS1yb290LWRlcHNbPXJkZXBzfD1oZGVwc10iKSkKIAkJZGVzYyA9ICJJZiBubyBhcmd1
bWVudCBpcyBnaXZlbiB0aGVuIGJ1aWxkLXRpbWUgZGVwZW5kZW5jaWVzIG9mIHBhY2thZ2VzIGZv
ciAiICsgXAogCQkJIlJPT1QgYXJlIGluc3RhbGxlZCB0byAiICsgXAogCQkJIlJPT1QgaW5zdGVh
ZCBvZiAvLiBJZiB0aGUgcmRlcHMgYXJndW1lbnQgaXMgZ2l2ZW4gdGhlbiBkaXNjYXJkICIgKyBc
CkBAIC01NzYsNyArNTc2LDkgQEAgZGVmIGhlbHAobXlvcHRzLCBoYXZlY29sb3I9MSk6CiAJCQki
YmUgZW5hYmxlZCB1bmRlciBub3JtYWwgY2lyY3Vtc3RhbmNlcy4gRm9yIGN1cnJlbnRseSBzdXBw
b3J0ZWQgIiArIFwKIAkJCSJFQVBJIHZhbHVlcywgdGhlIGJ1aWxkLXRpbWUgZGVwZW5kZW5jaWVz
IGFyZSBzcGVjaWZpZWQgaW4gdGhlICIgKyBcCiAJCQkiREVQRU5EIHZhcmlhYmxlLiBIb3dldmVy
LCBiZWhhdmlvciBtYXkgY2hhbmdlIGZvciBuZXcgIiArIFwKLQkJCSJFQVBJcyB3aGVuIHJlbGF0
ZWQgZXh0ZW5zaW9ucyBhcmUgYWRkZWQgaW4gdGhlIGZ1dHVyZS4iCisJCQkiRUFQSXMgd2hlbiBy
ZWxhdGVkIGV4dGVuc2lvbnMgYXJlIGFkZGVkIGluIHRoZSBmdXR1cmUuICIgKyBcCisJCQkiTkVX
OiB3ZSBub3cgY2FuIGdpdmUgaGRlcHMgYXJndW1lbnQgaGVyZSBmb3IgcHJvcGVyIGhvc3QvdGFy
Z2V0ICIgKyBcCisJCQkiZGVwZW5kZW5jeSBzZXBlcmF0aW9uLiIKIAkJZm9yIGxpbmUgaW4gd3Jh
cChkZXNjLCBkZXNjX3dpZHRoKToKIAkJCXByaW50KGRlc2NfaW5kZW50ICsgbGluZSkKIAkJcHJp
bnQoKQpkaWZmIC0tZ2l0IGEvcHltL19lbWVyZ2UvbWFpbi5weSBiL3B5bS9fZW1lcmdlL21haW4u
cHkKaW5kZXggOWU5MWVlOS4uMTI0YTgyOCAxMDA2NDQKLS0tIGEvcHltL19lbWVyZ2UvbWFpbi5w
eQorKysgYi9weW0vX2VtZXJnZS9tYWluLnB5CkBAIC0zOTgsNyArMzk4LDcgQEAgZGVmIGluc2Vy
dF9vcHRpb25hbF9hcmdzKGFyZ3MpOgogCQknLS1qb2JzJyAgICAgICA6IHZhbGlkX2ludGVnZXJz
LAogCQknLS1rZWVwLWdvaW5nJyAgICAgICAgICAgOiAoJ24nLCksCiAJCSctLXJlYnVpbHQtYmlu
YXJpZXMnICAgICA6ICgnbicsKSwKLQkJJy0tcm9vdC1kZXBzJyAgOiAoJ3JkZXBzJywpLAorCQkn
LS1yb290LWRlcHMnICA6ICgncmRlcHMnLCdoZGVwcycsKSwKIAkJJy0tc2VsZWN0JyAgICAgICAg
ICAgICAgIDogKCduJywpLAogCQknLS1zZWxlY3RpdmUnICAgICAgICAgICAgOiAoJ24nLCksCiAJ
CSItLXVzZS1lYnVpbGQtdmlzaWJpbGl0eSI6ICgnbicsKSwKQEAgLTY1Miw3ICs2NTIsNyBAQCBk
ZWYgcGFyc2Vfb3B0cyh0bXBjbWRsaW5lLCBzaWxlbnQ9RmFsc2UpOgogCQkiLS1yb290LWRlcHMi
OiB7CiAJCQkiaGVscCIgICAgOiAibW9kaWZ5IGludGVycHJldGF0aW9uIG9mIGRlcGVkZW5jaWVz
IiwKIAkJCSJ0eXBlIiAgICA6ICJjaG9pY2UiLAotCQkJImNob2ljZXMiIDooIlRydWUiLCAicmRl
cHMiKQorCQkJImNob2ljZXMiIDooIlRydWUiLCAicmRlcHMiLCAiaGRlcHMiKQogCQl9LAogCiAJ
CSItLXNlbGVjdCI6IHsKZGlmZiAtLWdpdCBhL3B5bS9wb3J0YWdlL19faW5pdF9fLnB5IGIvcHlt
L3BvcnRhZ2UvX19pbml0X18ucHkKaW5kZXggNzY0Yzk3NC4uMDI5ZDY4NSAxMDA2NDQKLS0tIGEv
cHltL3BvcnRhZ2UvX19pbml0X18ucHkKKysrIGIvcHltL3BvcnRhZ2UvX19pbml0X18ucHkKQEAg
LTQ5NCw3ICs0OTQsNyBAQCBhdXhkYmtleXMgPSAoCiAJJ1JFU1RSSUNUJywgICdIT01FUEFHRScs
ICAnTElDRU5TRScsICAgJ0RFU0NSSVBUSU9OJywKIAknS0VZV09SRFMnLCAgJ0lOSEVSSVRFRCcs
ICdJVVNFJywgJ1VOVVNFRF8wMCcsCiAJJ1BERVBFTkQnLCAgICdQUk9WSURFJywgJ0VBUEknLAot
CSdQUk9QRVJUSUVTJywgJ0RFRklORURfUEhBU0VTJywgJ1VOVVNFRF8wNScsICdVTlVTRURfMDQn
LAorCSdQUk9QRVJUSUVTJywgJ0RFRklORURfUEhBU0VTJywgJ0hERVBFTkQnLCAnVU5VU0VEXzA0
JywKIAknVU5VU0VEXzAzJywgJ1VOVVNFRF8wMicsICdVTlVTRURfMDEnLAogKQogYXV4ZGJrZXls
ZW49bGVuKGF1eGRia2V5cykKZGlmZiAtLWdpdCBhL3B5bS9wb3J0YWdlL2RiYXBpL3BvcnR0cmVl
LnB5IGIvcHltL3BvcnRhZ2UvZGJhcGkvcG9ydHRyZWUucHkKaW5kZXggY2JiYjI5MC4uMGJlYjBh
NyAxMDA2NDQKLS0tIGEvcHltL3BvcnRhZ2UvZGJhcGkvcG9ydHRyZWUucHkKKysrIGIvcHltL3Bv
cnRhZ2UvZGJhcGkvcG9ydHRyZWUucHkKQEAgLTQwMiw3ICs0MDIsNyBAQCBjbGFzcyBwb3J0ZGJh
cGkoZGJhcGkpOgogCQlzZWxmLl9hdXhfY2FjaGVfa2V5cyA9IHNldCgKIAkJCVsiREVQRU5EIiwg
IkVBUEkiLCAiSU5IRVJJVEVEIiwgIklVU0UiLCAiS0VZV09SRFMiLCAiTElDRU5TRSIsCiAJCQki
UERFUEVORCIsICJQUk9QRVJUSUVTIiwgIlBST1ZJREUiLCAiUkRFUEVORCIsICJyZXBvc2l0b3J5
IiwKLQkJCSJSRVNUUklDVCIsICJTTE9UIiwgIkRFRklORURfUEhBU0VTIl0pCisJCQkiUkVTVFJJ
Q1QiLCAiU0xPVCIsICJERUZJTkVEX1BIQVNFUyIsICJIREVQRU5EIl0pCiAKIAkJc2VsZi5fYXV4
X2NhY2hlID0ge30KIAkJc2VsZi5fYnJva2VuX2VidWlsZHMgPSBzZXQoKQo=
--0015174a0d9ecbb8f1048c95e82d--
Create a group - Google Groups - Google Home - Terms of Service - Privacy Policy
Account Options
