On 6 September 2011 19:03, Paul Sokolovsky wrote:
> On Tue, 6 Sep 2011 17:34:11 +0300
> Fathi Boudra wrote:
>
>> On 6 September 2011 17:28, Alexander Sack wrote:
>> >
>> > On Tue, Sep 6, 2011 at 4:25 PM, Fathi Boudra
>> > wrote:
>> >>
>> >> On 6 September 2011 08:28, Fathi Boudra
>> >> wrote:
On Tue, 6 Sep 2011 17:34:11 +0300
Fathi Boudra wrote:
> On 6 September 2011 17:28, Alexander Sack wrote:
> >
> > On Tue, Sep 6, 2011 at 4:25 PM, Fathi Boudra
> > wrote:
> >>
> >> On 6 September 2011 08:28, Fathi Boudra
> >> wrote:
> >> > On 6 September 2011 00:15, Alexander Sack
> >> > wrote:
On 6 September 2011 00:28, Fathi Boudra wrote:
> On 6 September 2011 00:15, Alexander Sack wrote:
>> On Mon, Sep 5, 2011 at 10:37 PM, Paul Sokolovsky
>> wrote:
>>>
>>> On Mon, 5 Sep 2011 14:36:48 +0300
>>> Paul Sokolovsky wrote:
>>>
>>> Ok, patched repo is available as:
>>>
>>> http://android.g
On 6 September 2011 17:28, Alexander Sack wrote:
>
> On Tue, Sep 6, 2011 at 4:25 PM, Fathi Boudra
> wrote:
>>
>> On 6 September 2011 08:28, Fathi Boudra wrote:
>> > On 6 September 2011 00:15, Alexander Sack wrote:
>> >> On Mon, Sep 5, 2011 at 10:37 PM, Paul Sokolovsky
>> >> wrote:
>> >>>
>> >>
On Tue, Sep 6, 2011 at 4:25 PM, Fathi Boudra wrote:
> On 6 September 2011 08:28, Fathi Boudra wrote:
> > On 6 September 2011 00:15, Alexander Sack wrote:
> >> On Mon, Sep 5, 2011 at 10:37 PM, Paul Sokolovsky
> >> wrote:
> >>>
> >>> On Mon, 5 Sep 2011 14:36:48 +0300
> >>> Paul Sokolovsky wrote:
On 6 September 2011 08:28, Fathi Boudra wrote:
> On 6 September 2011 00:15, Alexander Sack wrote:
>> On Mon, Sep 5, 2011 at 10:37 PM, Paul Sokolovsky
>> wrote:
>>>
>>> On Mon, 5 Sep 2011 14:36:48 +0300
>>> Paul Sokolovsky wrote:
>>>
>>> Ok, patched repo is available as:
>>>
>>> http://android.g
On 6 September 2011 00:15, Alexander Sack wrote:
> On Mon, Sep 5, 2011 at 10:37 PM, Paul Sokolovsky
> wrote:
>>
>> On Mon, 5 Sep 2011 14:36:48 +0300
>> Paul Sokolovsky wrote:
>>
>> Ok, patched repo is available as:
>>
>> http://android.git.linaro.org/gitweb?p=tools/repo.git;a=blob_plain;f=repo;h
On Mon, Sep 5, 2011 at 10:37 PM, Paul Sokolovsky wrote:
> On Mon, 5 Sep 2011 14:36:48 +0300
> Paul Sokolovsky wrote:
>
> Ok, patched repo is available as:
>
> http://android.git.linaro.org/gitweb?p=tools/repo.git;a=blob_plain;f=repo;hb=refs/heads/linaro-stable
> that file should be downloaded an
On Mon, 5 Sep 2011 14:36:48 +0300
Paul Sokolovsky wrote:
Ok, patched repo is available as:
http://android.git.linaro.org/gitweb?p=tools/repo.git;a=blob_plain;f=repo;hb=refs/heads/linaro-stable
that file should be downloaded and named as "repo". Apparently, it
should be mirrored at download server
Hello Fathi,
On Fri, 2 Sep 2011 13:19:11 -0500
Zach Pfeffer wrote:
[]
> > But we already seem to have decided to use patched repo, no??
>
> Seems to be the consensus.
>
> Would you write up where to pull Linaro's repo from and why its
> different? Make sure the release engineers are in the lo
Hello Loïc,
On Fri, 2 Sep 2011 23:18:33 +0200
Loïc Minier wrote:
> On Fri, Sep 02, 2011, Zach Pfeffer wrote:
> > repo bootstraps itself by syncing the repo guts from google, google
> > signs the repo guts so that people know that they're using a trusted
> > source. As our repo in not a trusted s
On Fri, Sep 02, 2011, Zach Pfeffer wrote:
> repo bootstraps itself by syncing the repo guts from google, google
> signs the repo guts so that people know that they're using a trusted
> source. As our repo in not a trusted source, people may be reluctant
> to use it and will instead use Google's ver
On 30 August 2011 10:50, Christian Robottom Reis wrote:
> On Tue, Aug 30, 2011 at 10:46:55AM -0500, Zach Pfeffer wrote:
>> Because we push everything upstream.
>
> While I agree with that blanket statement, there's no reason we wouldn't
> provide a [potentially temporary] version of repo that incl
On 2 September 2011 12:39, Paul Sokolovsky wrote:
> On Thu, 01 Sep 2011 18:21:30 -0400
> James Westby wrote:
>
>> On Thu, 1 Sep 2011 17:10:03 -0500, Zach Pfeffer
>> wrote:
>> > We've had two instances of this problem for all the builds we've
>> > ever done. One instance was trying to sync u-boot
On Thu, 01 Sep 2011 18:21:30 -0400
James Westby wrote:
> On Thu, 1 Sep 2011 17:10:03 -0500, Zach Pfeffer
> wrote:
> > We've had two instances of this problem for all the builds we've
> > ever done. One instance was trying to sync u-boot and the other was
> > trying to sync the TI LT kernel. John
On Thu, 1 Sep 2011 17:54:55 -0500, Zach Pfeffer wrote:
> On 1 September 2011 17:21, James Westby wrote:
> > On Thu, 1 Sep 2011 17:10:03 -0500, Zach Pfeffer
> > wrote:
> >> We've had two instances of this problem for all the builds we've ever
> >> done. One instance was trying to sync u-boot and
On 1 September 2011 17:21, James Westby wrote:
> On Thu, 1 Sep 2011 17:10:03 -0500, Zach Pfeffer
> wrote:
>> We've had two instances of this problem for all the builds we've ever
>> done. One instance was trying to sync u-boot and the other was trying
>> to sync the TI LT kernel. John Rigby sugg
On Thu, 1 Sep 2011 17:10:03 -0500, Zach Pfeffer wrote:
> We've had two instances of this problem for all the builds we've ever
> done. One instance was trying to sync u-boot and the other was trying
> to sync the TI LT kernel. John Rigby suggested the branch approach and
> it seems to have worked,
On 1 September 2011 17:04, James Westby wrote:
> On Thu, 1 Sep 2011 16:51:25 -0500, Zach Pfeffer
> wrote:
>> Anyhow, we have a few ways to solve this issue. I would say that as
>> long as we reference trees whose shas are reachable from the branches
>> in the remote git, then we should be fine.
On Thu, 1 Sep 2011 16:51:25 -0500, Zach Pfeffer wrote:
> Anyhow, we have a few ways to solve this issue. I would say that as
> long as we reference trees whose shas are reachable from the branches
> in the remote git, then we should be fine. From a manifest
> perspective, we like to sync a tip bra
On 1 September 2011 05:59, Christian Robottom Reis wrote:
> On Tue, Aug 30, 2011 at 11:13:08AM -0500, Zach Pfeffer wrote:
>> > Any other issues that I've missed? Where should we come down in this case?
>>
>> I say we stay the course and fix the issue of sha's disappearing. I
>> feel this way becau
On Thu, 1 Sep 2011 13:23:37 +0200
Alexander Sack wrote:
> On Thu, Sep 1, 2011 at 1:05 PM, Christian Robottom Reis
> wrote:
>
> > On Wed, Aug 31, 2011 at 02:19:08PM +0300, Paul Sokolovsky wrote:
> > > Hello Christian,
> > >
> > > On Tue, 30 Aug 2011 12:43:40 -0300
> > > Christian Robottom Reis w
On Thu, Sep 1, 2011 at 1:05 PM, Christian Robottom Reis wrote:
> On Wed, Aug 31, 2011 at 02:19:08PM +0300, Paul Sokolovsky wrote:
> > Hello Christian,
> >
> > On Tue, 30 Aug 2011 12:43:40 -0300
> > Christian Robottom Reis wrote:
> >
> > > On Tue, Aug 30, 2011 at 01:25:15PM +0300, Paul Sokolovsky
On Wed, Aug 31, 2011 at 02:19:08PM +0300, Paul Sokolovsky wrote:
> Hello Christian,
>
> On Tue, 30 Aug 2011 12:43:40 -0300
> Christian Robottom Reis wrote:
>
> > On Tue, Aug 30, 2011 at 01:25:15PM +0300, Paul Sokolovsky wrote:
> > > Yeah, I have patch for that. But we cannot use before upstream
On Tue, Aug 30, 2011 at 11:13:08AM -0500, Zach Pfeffer wrote:
> > Any other issues that I've missed? Where should we come down in this case?
>
> I say we stay the course and fix the issue of sha's disappearing. I
> feel this way because its:
>
> 1. Technically feasible in the short term.
> 2. Sav
On Wed, 31 Aug 2011 13:12:30 -0500, Zach Pfeffer
wrote:
> Can we tag across all the gits in the manifest?
I think you can do anything you want with
repo forall git tag foo
However, we've already established that tags aren't currently sufficient
to keep all these refs accessible, so this seem
On 31 August 2011 08:06, James Westby wrote:
> On Tue, 30 Aug 2011 22:38:22 -0500, Zach Pfeffer
> wrote:
>> > It sounds like you are advocating using a model where we use tags to
>> > ensure that the referenced revisions are reachable from a head, and then
>> > refer to the sha ids of the revisi
On Tue, 30 Aug 2011 22:40:57 -0500
Zach Pfeffer wrote:
[]
> The tag thing is a means to an end, to keep the sha's around. If we
> just tracked history trees we'd be fine, but all the rebasing causes
> refs to become unreachable. All trees in Android should be history
> trees so we shouldn't have
On Tue, 30 Aug 2011 22:38:22 -0500, Zach Pfeffer
wrote:
> > It sounds like you are advocating using a model where we use tags to
> > ensure that the referenced revisions are reachable from a head, and then
> > refer to the sha ids of the revisions in the manifest. Is that correct?
>
> Yup.
We c
Hello Christian,
On Tue, 30 Aug 2011 12:43:40 -0300
Christian Robottom Reis wrote:
> On Tue, Aug 30, 2011 at 01:25:15PM +0300, Paul Sokolovsky wrote:
> > Yeah, I have patch for that. But we cannot use before upstream
> > accepts it (because people will get errors checking out tree) and I
> > don
On 30 August 2011 19:48, Alexander Sack wrote:
> On Wed, Aug 31, 2011 at 2:09 AM, James Westby
> wrote:
>>
>> On Tue, 30 Aug 2011 11:10:10 -0500, Zach Pfeffer
>> wrote:
>> > There's no reason to do it now, because its solving the wrong problem.
>> > The problem is sha's disappear. We use sha's b
On 30 August 2011 19:09, James Westby wrote:
> On Tue, 30 Aug 2011 11:10:10 -0500, Zach Pfeffer
> wrote:
>> There's no reason to do it now, because its solving the wrong problem.
>> The problem is sha's disappear. We use sha's because the provide
>> immovable references to the state of a set of
On Wed, Aug 31, 2011 at 2:09 AM, James Westby wrote:
> On Tue, 30 Aug 2011 11:10:10 -0500, Zach Pfeffer
> wrote:
> > There's no reason to do it now, because its solving the wrong problem.
> > The problem is sha's disappear. We use sha's because the provide
> > immovable references to the state of
On Tue, Aug 30, 2011 at 12:46 PM, Paul Sokolovsky <
paul.sokolov...@linaro.org> wrote:
> On Mon, 29 Aug 2011 18:42:29 +0200
> Alexander Sack wrote:
>
> > On Mon, Aug 29, 2011 at 3:22 PM, Paul Sokolovsky
> > > > wrote:
> >
> > > It's not enough if you still want to refer to it via SHA, due to
> >
On Tue, 30 Aug 2011 11:10:10 -0500, Zach Pfeffer
wrote:
> There's no reason to do it now, because its solving the wrong problem.
> The problem is sha's disappear. We use sha's because the provide
> immovable references to the state of a set of git trees so that people
> can reproduce builds exact
On 30 August 2011 10:58, James Westby wrote:
> On Tue, 30 Aug 2011 12:50:51 -0300, Christian Robottom Reis
> wrote:
>> On Tue, Aug 30, 2011 at 10:46:55AM -0500, Zach Pfeffer wrote:
>> > Because we push everything upstream.
>>
>> While I agree with that blanket statement, there's no reason we wou
On 30 August 2011 10:50, Christian Robottom Reis wrote:
> On Tue, Aug 30, 2011 at 10:46:55AM -0500, Zach Pfeffer wrote:
>> Because we push everything upstream.
>
> While I agree with that blanket statement, there's no reason we wouldn't
> provide a [potentially temporary] version of repo that incl
On Tue, 30 Aug 2011 12:50:51 -0300, Christian Robottom Reis
wrote:
> On Tue, Aug 30, 2011 at 10:46:55AM -0500, Zach Pfeffer wrote:
> > Because we push everything upstream.
>
> While I agree with that blanket statement, there's no reason we wouldn't
> provide a [potentially temporary] version of
On Tue, Aug 30, 2011 at 10:46:55AM -0500, Zach Pfeffer wrote:
> Because we push everything upstream.
While I agree with that blanket statement, there's no reason we wouldn't
provide a [potentially temporary] version of repo that included the
changes we're pushing upstream.
We do this for every on
Because we push everything upstream.
On 30 August 2011 10:43, Christian Robottom Reis wrote:
> On Tue, Aug 30, 2011 at 01:25:15PM +0300, Paul Sokolovsky wrote:
>> Yeah, I have patch for that. But we cannot use before upstream accepts
>> it (because people will get errors checking out tree) and I
On Tue, Aug 30, 2011 at 01:25:15PM +0300, Paul Sokolovsky wrote:
> Yeah, I have patch for that. But we cannot use before upstream accepts
> it (because people will get errors checking out tree) and I don't hold
> my breath for that at all.
Why wouldn't we provide our own version of repo that worke
On 30 August 2011 05:46, Paul Sokolovsky wrote:
> On Mon, 29 Aug 2011 18:42:29 +0200
> Alexander Sack wrote:
>
>> On Mon, Aug 29, 2011 at 3:22 PM, Paul Sokolovsky
>> > > wrote:
>>
>> > It's not enough if you still want to refer to it via SHA, due to
>> > repo peculiarities. It should be also reac
On Mon, 29 Aug 2011 18:42:29 +0200
Alexander Sack wrote:
> On Mon, Aug 29, 2011 at 3:22 PM, Paul Sokolovsky
> > wrote:
>
> > It's not enough if you still want to refer to it via SHA, due to
> > repo peculiarities. It should be also reachable from one of the live
> > branches (so, instead of a t
On Mon, 29 Aug 2011 12:15:15 -0500
Zach Pfeffer wrote:
[]
> >> We could probably just update the branch after the automerge step.
> > What do you mean "SHA1 reachability"? I can "reach" arbitrary
> > HEADs using a hash even if they're not tagged so long as I didn't
> > garbage collect. If I tag
On Mon, 29 Aug 2011 10:41:59 -0500
Zach Pfeffer wrote:
> On 29 August 2011 10:13, Andy Green wrote:
> > On 08/29/2011 09:22 PM, Somebody in the thread at some point said:
> >
> >> It's not enough if you still want to refer to it via SHA, due to
> >> repo peculiarities. It should be also reachabl
Hello Andy,
On Mon, 29 Aug 2011 23:13:07 +0800
Andy Green wrote:
> On 08/29/2011 09:22 PM, Somebody in the thread at some point said:
>
> > It's not enough if you still want to refer to it via SHA, due to
> > repo peculiarities. It should be also reachable from one of the live
> > branches (so,
On Tue, 30 Aug 2011 11:44:35 +0800, Andy Green wrote:
> > The first is that repo currently only fetches branches, and not
> > tags. This means that simply tagging isn't enough to ensure that you
> > have the object in your repo.
>
> Not sure what "your repo" means but I get the message.
Yeah, so
On 08/30/2011 10:56 AM, Somebody in the thread at some point said:
On Tue, 30 Aug 2011 10:19:35 +0800, Andy Green wrote:
I think you missed my point, if I tagged it, you CAN check it out. So
"reachability" is not the issue.
I think there are two things here:
The first is that repo currently
On Tue, 30 Aug 2011 10:19:35 +0800, Andy Green wrote:
> I think you missed my point, if I tagged it, you CAN check it out. So
> "reachability" is not the issue.
I think there are two things here:
The first is that repo currently only fetches branches, and not
tags. This means that simply taggi
On 08/30/2011 01:15 AM, Somebody in the thread at some point said:
Anyway, this isn't an issue with repo, its a sha1 reachability issue.
repo 's just a foreach git tool.
What do you mean "SHA1 reachability"? I can "reach" arbitrary HEADs using a
hash even if they're not tagged so long as I di
On 29 August 2011 10:58, Andy Green wrote:
> On 08/29/2011 11:41 PM, Somebody in the thread at some point said:
>>
>> On 29 August 2011 10:13, Andy Green wrote:
>>>
>>> On 08/29/2011 09:22 PM, Somebody in the thread at some point said:
>>>
It's not enough if you still want to refer to it via
On Mon, Aug 29, 2011 at 3:22 PM, Paul Sokolovsky wrote:
> It's not enough if you still want to refer to it via SHA, due to repo
> peculiarities. It should be also reachable from one of the live
> branches (so, instead of a tag, a branch can be created right away).
>
Paul, what happened to the re
On 08/29/2011 11:41 PM, Somebody in the thread at some point said:
On 29 August 2011 10:13, Andy Green wrote:
On 08/29/2011 09:22 PM, Somebody in the thread at some point said:
It's not enough if you still want to refer to it via SHA, due to repo
peculiarities. It should be also reachable fro
On 29 August 2011 10:13, Andy Green wrote:
> On 08/29/2011 09:22 PM, Somebody in the thread at some point said:
>
>> It's not enough if you still want to refer to it via SHA, due to repo
>> peculiarities. It should be also reachable from one of the live
>> branches (so, instead of a tag, a branch
On 08/29/2011 09:22 PM, Somebody in the thread at some point said:
It's not enough if you still want to refer to it via SHA, due to repo
peculiarities. It should be also reachable from one of the live
branches (so, instead of a tag, a branch can be created right away).
Sorry... this means for
On 29 August 2011 08:22, Paul Sokolovsky wrote:
> On Mon, 29 Aug 2011 08:08:17 -0500
> Zach Pfeffer wrote:
>
>> Now that we have an Android build for every board and Gerrit and LAVA
>> I'd like to unify how we handle kernels for each so that we can work
>> more efficiently, start to unify the ker
On Mon, 29 Aug 2011 08:08:17 -0500
Zach Pfeffer wrote:
> Now that we have an Android build for every board and Gerrit and LAVA
> I'd like to unify how we handle kernels for each so that we can work
> more efficiently, start to unify the kernels and provide a means for
> external Android users to
Now that we have an Android build for every board and Gerrit and LAVA
I'd like to unify how we handle kernels for each so that we can work
more efficiently, start to unify the kernels and provide a means for
external Android users to start to improve these trees.
First, since we control the kernel
58 matches
Mail list logo
