Not worth a *facepalm*. We understand how much volume you are dealing
with. Well.. you deserve a weekend break :-).
I have a master repo synced of Wednesday (that you pointed at).. but
haven't got a public server to host it. Is there someway it could be
made useful?
Regards,
Rajesh.S
On Mar 22, 1:07 am, Jean-Baptiste Queru <j...@android.com> wrote:
> > On Mar 22, 12:15 am, Jean-Baptiste Queru <j...@android.com> wrote:
> >> Well, repo could be used to do a repo forall -c git checkout <tag>,
> >> but that'd require to tag every single project, which would really
> >> only be practical for admins. On top of that I believe that we only
> >> want to tag actual long-term releases, and whatever state master was
> >> on before the merge last Wednesday wasn't a release.
> >> The real process would have been to do a "repo manifest -r -o -" in a
> >> synced tree before the merge, and post this manifest here on the
> >> group. This can still be done today by someone who has a synced tree
> >> in the state as of Wednesday noon PDT. I don't have such a tree, and
> >> my top priority at this point is to help people move ahead, not to
> >> help them stay behind.
> >> The breakage wasn't supposed to last that long. I expected a day at
> >> most, and it's been 3 days already. I'm really sorry about that. I've
> >> been trying to fix things, but it turned out to be much harder than I
> >> had anticipated, at several different levels.
> >> If you'd like to help, my current sticky point is to find out why my
> >> LOCAL_CFLAGS inhttps://review.source.android.com/Gerrit#patch,sidebyside,9356,1,medi...
> >> doesn't seem to get passed to the compiler, so that I've had to
> >> temporarily use #if 0 instead of #ifndef opencore in the source tree.
> >> We'll also need a better fix for 9357, as I guess it should be
> >> possible to prevent that crash without having to modify the phone app.
> >> JBQ
> >> On Sat, Mar 21, 2009 at 1:20 PM, Rajesh S <rajeshs...@gmail.com> wrote:
> >> > JBQ does this 'repo' script have support for tagging at all?
> >> > I could not find much in the docs.. am I missing it?
> >> > And I'll try the 3 instead of 9300 on the device.
> >> > Regards,
> >> > Rajesh.S
> >> > On Mar 21, 7:23 pm, André Oriani <aori...@gmail.com> wrote:
> >> >> Hi JBQ,
> >> >> I would suggest to apply a tag so we can know what is the last stable
> >> >> piece of code on master branch before doing a repo sync and getting a
> >> >> broken build. That would certainly help.
> >> >> Thanks,
> >> >> André Oriani
> >> >> On 21 mar, 15:50, Jean-Baptiste Queru <j...@android.com> wrote:
> >> >> > I've been working on a "better" batch of patches (now it feels more
> >> >> > like open-heart surgery with a meat cleaver):
> >> >> > -no need to delete the opencore directory or to remove it from the manifest.
> >> >> > -you need to repo download changes 9355, 9356 and 9357. No need to
> >> >> > take 9300. I know it's 3 changes instead of 1, because I had to touch
> >> >> > a few more parts of the system, but those are much cleaner.
> >> >> > -only tested on the emulator, so those might very well cause
> >> >> > regressions on dream.
> >> >> > JBQ
> >> >> > On Thu, Mar 19, 2009 at 1:07 PM, Jean-Baptiste Queru <j...@android.com> wrote:
> >> >> > > I've put together a hack that allows the system to compile and start
> >> >> > > all the way to the home app. I worked with the delicateness of
> >> >> > > open-heart surgery performed with a chainsaw.
> >> >> > > Steps:
> >> >> > > -remove the opencore files ( rm -rf external/opencore
> >> >> > > .repo/projects/external/opencore.git ). Remove opencore from your
> >> >> > > .repo/manifest.xml if you intend to repo sync the entire world but
> >> >> > > don't want to have to remove opencore every single time.
> >> >> > > -most probably do a clean build ( rm -rf out/ ; make )
> >> >> > > I've "tested" on a device/release/generic/userdebug build. On my
> >> >> > > machine, it compiles, launches. The media process dies (which probably
> >> >> > > means that downloads are busted too), as well as the music player. The
> >> >> > > browser starts and can access the network.
> >> >> > > JBQ
> >> >> > > On Wed, Mar 18, 2009 at 7:57 PM, Jean-Baptiste Queru <j...@android.com> wrote:
> >> >> > >> I've submitted the merge (106 projects!), and I believe that the tree
> >> >> > >> is in the state that it should be.
> >> >> > >> Caveats:
> >> >> > >> -THE BUILD IS BROKEN. You've been warned. There's been some drift
> >> >> > >> around OpenCORE (probably situations where new code was written in
> >> >> > >> cupcake that uses OpenCORE 1, or where APIs were removed in cupcake
> >> >> > >> that OpenCORE 2 relies on).
> >> >> > >> The proper command to try to merge the OpenCORE code should be "git
> >> >> > >> merge remotes/korg/cupcake" (I'm typing from memory).
> >> >> > >> -I'm not 100% sure that the server contains exactly what it should.
> >> >> > >> I've had a filesystem failure right as I was trying to verify it, and
> >> >> > >> I'm not gonna be able to verify until at least sometime tomorrow.
> >> >> > >> JBQ
> >> >> > >> On Wed, Mar 18, 2009 at 12:43 PM, Jean-Baptiste Queru <j...@android.com> wrote:
> >> >> > >>> I expect to start submitting the changes in about an hour, i.e.
> >> >> > >>> between 1:30pm and 2pm PDT.
> >> >> > >>> Starting right now, you may want to avoid initiating a new repo sync,
> >> >> > >>> unless you're OK ending up with a tree that might not even compile.
> >> >> > >>> JBQ
> >> >> > >>> On Tue, Mar 17, 2009 at 6:35 PM, Jean-Baptiste Queru <j...@android.com> wrote:
> >> >> > >>>> [bcc android-platform, android-framework, android-porting]
> >> >> > >>>> I'm working on merging the latest cupcake code drop into master. The
> >> >> > >>>> task is quite hairy, so the following two guidelines probably apply:
> >> >> > >>>> -please don't submit anything in gerrit, as you'll just get in my way.
> >> >> > >>>> -now is a good time to repo sync master, as I'm going to have to
> >> >> > >>>> submit the result of the merge in a state where it doesn't build, and
> >> >> > >>>> I have no idea how long it'll take to get it to build again after
> >> >> > >>>> that.
> >> >> > >>>> Questions sent directly to me that have no reason for being private
> >> >> > >>>> will likely get ignored or forwarded to a public forum with no further
> >> >> > >>>> warning.
> >> >> > >>> Questions sent directly to me that have no reason for being private
> >> >> > >>> will likely get ignored or forwarded to a public forum with no further
> >> >> > >>> warning.
> >> >> > >> Questions sent directly to me that have no reason for being private
> >> >> > >> will likely get ignored or forwarded to a public forum with no further
> >> >> > >> warning.
> >> >> > > Questions sent directly to me that have no reason for being private
> >> >> > > will likely get ignored or forwarded to a public forum with no further
> >> >> > > warning.
> >> >> > Questions sent directly to me that have no reason for being private
> >> >> > will likely get ignored or forwarded to a public forum with no further
> >> >> > warning.
> >> Questions sent directly to me that have no reason for being private
> >> will likely get ignored or forwarded to a public forum with no further
> >> warning.
> Questions sent directly to me that have no reason for being private
> will likely get ignored or forwarded to a public forum with no further
> warning.
On Sat, Mar 21, 2009 at 6:15 PM, Rajesh S <rajeshs...@gmail.com> wrote:
> Not worth a *facepalm*. We understand how much volume you are dealing > with. Well.. you deserve a weekend break :-). > I have a master repo synced of Wednesday (that you pointed at).. but > haven't got a public server to host it. Is there someway it could be > made useful?
> Regards, > Rajesh.S
> On Mar 22, 1:07 am, Jean-Baptiste Queru <j...@android.com> wrote: >> *facepalm*
>> Doh. Doh. Doh. Doh.
>> JBQ
>> On Sat, Mar 21, 2009 at 5:53 PM, Rajesh S <rajeshs...@gmail.com> wrote:
>> > is it because you have defined >> > BUILD_WITHOUT_PV := true >> > and you are checking for negative
>> > were you actually wishing for 'ifeq' instead?
>> > Regards, >> > Rajesh.S
>> > On Mar 22, 12:15 am, Jean-Baptiste Queru <j...@android.com> wrote: >> >> Well, repo could be used to do a repo forall -c git checkout <tag>, >> >> but that'd require to tag every single project, which would really >> >> only be practical for admins. On top of that I believe that we only >> >> want to tag actual long-term releases, and whatever state master was >> >> on before the merge last Wednesday wasn't a release.
>> >> The real process would have been to do a "repo manifest -r -o -" in a >> >> synced tree before the merge, and post this manifest here on the >> >> group. This can still be done today by someone who has a synced tree >> >> in the state as of Wednesday noon PDT. I don't have such a tree, and >> >> my top priority at this point is to help people move ahead, not to >> >> help them stay behind.
>> >> The breakage wasn't supposed to last that long. I expected a day at >> >> most, and it's been 3 days already. I'm really sorry about that. I've >> >> been trying to fix things, but it turned out to be much harder than I >> >> had anticipated, at several different levels.
>> >> If you'd like to help, my current sticky point is to find out why my >> >> LOCAL_CFLAGS inhttps://review.source.android.com/Gerrit#patch,sidebyside,9356,1,medi... >> >> doesn't seem to get passed to the compiler, so that I've had to >> >> temporarily use #if 0 instead of #ifndef opencore in the source tree. >> >> We'll also need a better fix for 9357, as I guess it should be >> >> possible to prevent that crash without having to modify the phone app.
>> >> JBQ
>> >> On Sat, Mar 21, 2009 at 1:20 PM, Rajesh S <rajeshs...@gmail.com> wrote:
>> >> > JBQ does this 'repo' script have support for tagging at all? >> >> > I could not find much in the docs.. am I missing it?
>> >> > And I'll try the 3 instead of 9300 on the device.
>> >> > Regards, >> >> > Rajesh.S
>> >> > On Mar 21, 7:23 pm, André Oriani <aori...@gmail.com> wrote: >> >> >> Hi JBQ,
>> >> >> I would suggest to apply a tag so we can know what is the last stable >> >> >> piece of code on master branch before doing a repo sync and getting a >> >> >> broken build. That would certainly help.
>> >> >> Thanks, >> >> >> André Oriani
>> >> >> On 21 mar, 15:50, Jean-Baptiste Queru <j...@android.com> wrote:
>> >> >> > I've been working on a "better" batch of patches (now it feels more >> >> >> > like open-heart surgery with a meat cleaver):
>> >> >> > -no need to delete the opencore directory or to remove it from the manifest.
>> >> >> > -you need to repo download changes 9355, 9356 and 9357. No need to >> >> >> > take 9300. I know it's 3 changes instead of 1, because I had to touch >> >> >> > a few more parts of the system, but those are much cleaner.
>> >> >> > -only tested on the emulator, so those might very well cause >> >> >> > regressions on dream.
>> >> >> > JBQ
>> >> >> > On Thu, Mar 19, 2009 at 1:07 PM, Jean-Baptiste Queru <j...@android.com> wrote: >> >> >> > > I've put together a hack that allows the system to compile and start >> >> >> > > all the way to the home app. I worked with the delicateness of >> >> >> > > open-heart surgery performed with a chainsaw.
>> >> >> > > Steps:
>> >> >> > > -remove the opencore files ( rm -rf external/opencore >> >> >> > > .repo/projects/external/opencore.git ). Remove opencore from your >> >> >> > > .repo/manifest.xml if you intend to repo sync the entire world but >> >> >> > > don't want to have to remove opencore every single time.
>> >> >> > > -most probably do a clean build ( rm -rf out/ ; make )
>> >> >> > > I've "tested" on a device/release/generic/userdebug build. On my >> >> >> > > machine, it compiles, launches. The media process dies (which probably >> >> >> > > means that downloads are busted too), as well as the music player. The >> >> >> > > browser starts and can access the network.
>> >> >> > > JBQ
>> >> >> > > On Wed, Mar 18, 2009 at 7:57 PM, Jean-Baptiste Queru <j...@android.com> wrote: >> >> >> > >> I've submitted the merge (106 projects!), and I believe that the tree >> >> >> > >> is in the state that it should be.
>> >> >> > >> Caveats:
>> >> >> > >> -THE BUILD IS BROKEN. You've been warned. There's been some drift >> >> >> > >> around OpenCORE (probably situations where new code was written in >> >> >> > >> cupcake that uses OpenCORE 1, or where APIs were removed in cupcake >> >> >> > >> that OpenCORE 2 relies on).
>> >> >> > >> The proper command to try to merge the OpenCORE code should be "git >> >> >> > >> merge remotes/korg/cupcake" (I'm typing from memory).
>> >> >> > >> -I'm not 100% sure that the server contains exactly what it should. >> >> >> > >> I've had a filesystem failure right as I was trying to verify it, and >> >> >> > >> I'm not gonna be able to verify until at least sometime tomorrow.
>> >> >> > >> JBQ
>> >> >> > >> On Wed, Mar 18, 2009 at 12:43 PM, Jean-Baptiste Queru <j...@android.com> wrote: >> >> >> > >>> I expect to start submitting the changes in about an hour, i.e. >> >> >> > >>> between 1:30pm and 2pm PDT.
>> >> >> > >>> Starting right now, you may want to avoid initiating a new repo sync, >> >> >> > >>> unless you're OK ending up with a tree that might not even compile.
>> >> >> > >>> JBQ
>> >> >> > >>> On Tue, Mar 17, 2009 at 6:35 PM, Jean-Baptiste Queru <j...@android.com> wrote: >> >> >> > >>>> [bcc android-platform, android-framework, android-porting]
>> >> >> > >>>> I'm working on merging the latest cupcake code drop into master. The >> >> >> > >>>> task is quite hairy, so the following two guidelines probably apply:
>> >> >> > >>>> -please don't submit anything in gerrit, as you'll just get in my way. >> >> >> > >>>> -now is a good time to repo sync master, as I'm going to have to >> >> >> > >>>> submit the result of the merge in a state where it doesn't build, and >> >> >> > >>>> I have no idea how long it'll take to get it to build again after >> >> >> > >>>> that.
>> >> >> > >>>> Questions sent directly to me that have no reason for being private >> >> >> > >>>> will likely get ignored or forwarded to a public forum with no further >> >> >> > >>>> warning.
>> >> >> > >>> Questions sent directly to me that have no reason for being private >> >> >> > >>> will likely get ignored or forwarded to a public forum with no further >> >> >> > >>> warning.
>> >> >> > >> Questions sent directly to me that have no reason for being private >> >> >> > >> will likely get ignored or forwarded to a public forum with no further >> >> >> > >> warning.
>> >> >> > > Questions sent directly to me that have no reason for being private >> >> >> > > will likely get ignored or forwarded to a public forum with no further >> >> >> > > warning.
>> >> >> > Questions sent directly to me that have no reason for being private >> >> >> > will likely get ignored or forwarded to a public forum with no further >> >> >> > warning.
>> >> Questions sent directly to me that have no reason for being private >> >> will likely get ignored or forwarded to a public forum with no further >> >> warning.
>> Questions sent directly to me that have no reason for being private >> will likely get ignored or forwarded to a public forum with no further >> warning.
-- Jean-Baptiste M. "JBQ" Queru Android Engineer, Google.
Questions sent directly to me that have no reason for being private will likely get ignored or forwarded to a public forum with no further warning.
> If you could run "repo manifest -r -o -" on your pre-merge master and
> just copy-paste the output in a new thread here, that'd be great.
> JBQ
> On Sat, Mar 21, 2009 at 6:15 PM, Rajesh S <rajeshs...@gmail.com> wrote:
> > Not worth a *facepalm*. We understand how much volume you are dealing
> > with. Well.. you deserve a weekend break :-).
> > I have a master repo synced of Wednesday (that you pointed at).. but
> > haven't got a public server to host it. Is there someway it could be
> > made useful?
> > Regards,
> > Rajesh.S
> > On Mar 22, 1:07 am, Jean-Baptiste Queru <j...@android.com> wrote:
> >> *facepalm*
> >> Doh. Doh. Doh. Doh.
> >> JBQ
> >> On Sat, Mar 21, 2009 at 5:53 PM, Rajesh S <rajeshs...@gmail.com> wrote:
> >> > is it because you have defined
> >> > BUILD_WITHOUT_PV := true
> >> > and you are checking for negative
> >> > were you actually wishing for 'ifeq' instead?
> >> > Regards,
> >> > Rajesh.S
> >> > On Mar 22, 12:15 am, Jean-Baptiste Queru <j...@android.com> wrote:
> >> >> Well, repo could be used to do a repo forall -c git checkout <tag>,
> >> >> but that'd require to tag every single project, which would really
> >> >> only be practical for admins. On top of that I believe that we only
> >> >> want to tag actual long-term releases, and whatever state master was
> >> >> on before the merge last Wednesday wasn't a release.
> >> >> The real process would have been to do a "repo manifest -r -o -" in a
> >> >> synced tree before the merge, and post this manifest here on the
> >> >> group. This can still be done today by someone who has a synced tree
> >> >> in the state as of Wednesday noon PDT. I don't have such a tree, and
> >> >> my top priority at this point is to help people move ahead, not to
> >> >> help them stay behind.
> >> >> The breakage wasn't supposed to last that long. I expected a day at
> >> >> most, and it's been 3 days already. I'm really sorry about that. I've
> >> >> been trying to fix things, but it turned out to be much harder than I
> >> >> had anticipated, at several different levels.
> >> >> If you'd like to help, my current sticky point is to find out why my
> >> >> LOCAL_CFLAGS inhttps://review.source.android.com/Gerrit#patch,sidebyside,9356,1,medi...
> >> >> doesn't seem to get passed to the compiler, so that I've had to
> >> >> temporarily use #if 0 instead of #ifndef opencore in the source tree.
> >> >> We'll also need a better fix for 9357, as I guess it should be
> >> >> possible to prevent that crash without having to modify the phone app.
> >> >> JBQ
> >> >> On Sat, Mar 21, 2009 at 1:20 PM, Rajesh S <rajeshs...@gmail.com> wrote:
> >> >> > JBQ does this 'repo' script have support for tagging at all?
> >> >> > I could not find much in the docs.. am I missing it?
> >> >> > And I'll try the 3 instead of 9300 on the device.
> >> >> > Regards,
> >> >> > Rajesh.S
> >> >> > On Mar 21, 7:23 pm, André Oriani <aori...@gmail.com> wrote:
> >> >> >> Hi JBQ,
> >> >> >> I would suggest to apply a tag so we can know what is the last stable
> >> >> >> piece of code on master branch before doing a repo sync and getting a
> >> >> >> broken build. That would certainly help.
> >> >> >> Thanks,
> >> >> >> André Oriani
> >> >> >> On 21 mar, 15:50, Jean-Baptiste Queru <j...@android.com> wrote:
> >> >> >> > I've been working on a "better" batch of patches (now it feels more
> >> >> >> > like open-heart surgery with a meat cleaver):
> >> >> >> > -no need to delete the opencore directory or to remove it from the manifest.
> >> >> >> > -you need to repo download changes 9355, 9356 and 9357. No need to
> >> >> >> > take 9300. I know it's 3 changes instead of 1, because I had to touch
> >> >> >> > a few more parts of the system, but those are much cleaner.
> >> >> >> > -only tested on the emulator, so those might very well cause
> >> >> >> > regressions on dream.
> >> >> >> > JBQ
> >> >> >> > On Thu, Mar 19, 2009 at 1:07 PM, Jean-Baptiste Queru <j...@android.com> wrote:
> >> >> >> > > I've put together a hack that allows the system to compile and start
> >> >> >> > > all the way to the home app. I worked with the delicateness of
> >> >> >> > > open-heart surgery performed with a chainsaw.
> >> >> >> > > Steps:
> >> >> >> > > -remove the opencore files ( rm -rf external/opencore
> >> >> >> > > .repo/projects/external/opencore.git ). Remove opencore from your
> >> >> >> > > .repo/manifest.xml if you intend to repo sync the entire world but
> >> >> >> > > don't want to have to remove opencore every single time.
> >> >> >> > > -most probably do a clean build ( rm -rf out/ ; make )
> >> >> >> > > I've "tested" on a device/release/generic/userdebug build. On my
> >> >> >> > > machine, it compiles, launches. The media process dies (which probably
> >> >> >> > > means that downloads are busted too), as well as the music player. The
> >> >> >> > > browser starts and can access the network.
> >> >> >> > > JBQ
> >> >> >> > > On Wed, Mar 18, 2009 at 7:57 PM, Jean-Baptiste Queru <j...@android.com> wrote:
> >> >> >> > >> I've submitted the merge (106 projects!), and I believe that the tree
> >> >> >> > >> is in the state that it should be.
> >> >> >> > >> Caveats:
> >> >> >> > >> -THE BUILD IS BROKEN. You've been warned. There's been some drift
> >> >> >> > >> around OpenCORE (probably situations where new code was written in
> >> >> >> > >> cupcake that uses OpenCORE 1, or where APIs were removed in cupcake
> >> >> >> > >> that OpenCORE 2 relies on).
> >> >> >> > >> The proper command to try to merge the OpenCORE code should be "git
> >> >> >> > >> merge remotes/korg/cupcake" (I'm typing from memory).
> >> >> >> > >> -I'm not 100% sure that the server contains exactly what it should.
> >> >> >> > >> I've had a filesystem failure right as I was trying to verify it, and
> >> >> >> > >> I'm not gonna be able to verify until at least sometime tomorrow.
> >> >> >> > >> JBQ
> >> >> >> > >> On Wed, Mar 18, 2009 at 12:43 PM, Jean-Baptiste Queru <j...@android.com> wrote:
> >> >> >> > >>> I expect to start submitting the changes in about an hour, i.e.
> >> >> >> > >>> between 1:30pm and 2pm PDT.
> >> >> >> > >>> Starting right now, you may want to avoid initiating a new repo sync,
> >> >> >> > >>> unless you're OK ending up with a tree that might not even compile.
> >> >> >> > >>> JBQ
> >> >> >> > >>> On Tue, Mar 17, 2009 at 6:35 PM, Jean-Baptiste Queru <j...@android.com> wrote:
> >> >> >> > >>>> [bcc android-platform, android-framework, android-porting]
> >> >> >> > >>>> I'm working on merging the latest cupcake code drop into master. The
> >> >> >> > >>>> task is quite hairy, so the following two guidelines probably apply:
> >> >> >> > >>>> -please don't submit anything in gerrit, as you'll just get in my way.
> >> >> >> > >>>> -now is a good time to repo sync master, as I'm going to have to
> >> >> >> > >>>> submit the result of the merge in a state where it doesn't build, and
> >> >> >> > >>>> I have no idea how long it'll take to get it to build again after
> >> >> >> > >>>> that.
> >> >> >> > >>>> Questions sent directly to me that have no reason for being private
> >> >> >> > >>>> will likely get ignored or forwarded to a public forum with no further
> >> >> >> > >>>> warning.
> >> >> >> > >>> Questions sent directly to me that have no reason for being private
> >> >> >> > >>> will likely get ignored or forwarded to a public forum with no further
> >> >> >> > >>> warning.
> >> >> >> > >> Questions sent directly to me that have no reason for being private
> >> >> >> > >> will likely get ignored or forwarded to a public forum with no further
> >> >> >> > >> warning.
> >> >> >> > > Questions sent directly to me that have no reason for being private
> >> >> >> > > will likely get ignored or forwarded to a public forum with no further
> >> >> >> > > warning.
> >> >> >> > Questions sent directly to me that have no reason for being private
> >> >> >> > will likely get ignored or forwarded to a public forum with no further
> >> >> >> > warning.
> >> >> Questions sent directly to me that have no reason for being private
> >> >> will likely get ignored or forwarded to a public forum with no further
> >> >> warning.
> >> Questions sent directly to me that have no reason for being private
> >> will likely get ignored or forwarded to a public forum with no further
> >> warning.
On Sat, Mar 21, 2009 at 11:50 AM, Jean-Baptiste Queru <j...@android.com> wrote: > I've been working on a "better" batch of patches (now it feels more > like open-heart surgery with a meat cleaver):
> -no need to delete the opencore directory or to remove it from the manifest.
> -you need to repo download changes 9355, 9356 and 9357. No need to > take 9300. I know it's 3 changes instead of 1, because I had to touch > a few more parts of the system, but those are much cleaner.
> -only tested on the emulator, so those might very well cause > regressions on dream.
> JBQ
> On Thu, Mar 19, 2009 at 1:07 PM, Jean-Baptiste Queru <j...@android.com> wrote: >> I've put together a hack that allows the system to compile and start >> all the way to the home app. I worked with the delicateness of >> open-heart surgery performed with a chainsaw.
>> Steps:
>> -remove the opencore files ( rm -rf external/opencore >> .repo/projects/external/opencore.git ). Remove opencore from your >> .repo/manifest.xml if you intend to repo sync the entire world but >> don't want to have to remove opencore every single time.
>> -most probably do a clean build ( rm -rf out/ ; make )
>> I've "tested" on a device/release/generic/userdebug build. On my >> machine, it compiles, launches. The media process dies (which probably >> means that downloads are busted too), as well as the music player. The >> browser starts and can access the network.
>> JBQ
>> On Wed, Mar 18, 2009 at 7:57 PM, Jean-Baptiste Queru <j...@android.com> wrote: >>> I've submitted the merge (106 projects!), and I believe that the tree >>> is in the state that it should be.
>>> Caveats:
>>> -THE BUILD IS BROKEN. You've been warned. There's been some drift >>> around OpenCORE (probably situations where new code was written in >>> cupcake that uses OpenCORE 1, or where APIs were removed in cupcake >>> that OpenCORE 2 relies on).
>>> The proper command to try to merge the OpenCORE code should be "git >>> merge remotes/korg/cupcake" (I'm typing from memory).
>>> -I'm not 100% sure that the server contains exactly what it should. >>> I've had a filesystem failure right as I was trying to verify it, and >>> I'm not gonna be able to verify until at least sometime tomorrow.
>>> JBQ
>>> On Wed, Mar 18, 2009 at 12:43 PM, Jean-Baptiste Queru <j...@android.com> wrote: >>>> I expect to start submitting the changes in about an hour, i.e. >>>> between 1:30pm and 2pm PDT.
>>>> Starting right now, you may want to avoid initiating a new repo sync, >>>> unless you're OK ending up with a tree that might not even compile.
>>>> JBQ
>>>> On Tue, Mar 17, 2009 at 6:35 PM, Jean-Baptiste Queru <j...@android.com> wrote: >>>>> [bcc android-platform, android-framework, android-porting]
>>>>> I'm working on merging the latest cupcake code drop into master. The >>>>> task is quite hairy, so the following two guidelines probably apply:
>>>>> -please don't submit anything in gerrit, as you'll just get in my way. >>>>> -now is a good time to repo sync master, as I'm going to have to >>>>> submit the result of the merge in a state where it doesn't build, and >>>>> I have no idea how long it'll take to get it to build again after >>>>> that.
>>>>> Questions sent directly to me that have no reason for being private >>>>> will likely get ignored or forwarded to a public forum with no further >>>>> warning.
>>>> Questions sent directly to me that have no reason for being private >>>> will likely get ignored or forwarded to a public forum with no further >>>> warning.
>>> Questions sent directly to me that have no reason for being private >>> will likely get ignored or forwarded to a public forum with no further >>> warning.
>> Questions sent directly to me that have no reason for being private >> will likely get ignored or forwarded to a public forum with no further >> warning.
> Questions sent directly to me that have no reason for being private > will likely get ignored or forwarded to a public forum with no further > warning.
-- Jean-Baptiste M. "JBQ" Queru Android Engineer, Google.
Questions sent directly to me that have no reason for being private will likely get ignored or forwarded to a public forum with no further warning.
thanks for your patch! i'm really new to this git stuff so whats the
command for downloading this patch? repo always wants to have some
project with the download command...
On 22 Mrz., 06:35, Jean-Baptiste Queru <j...@android.com> wrote:
> -quickly tested both on emulator and dream, and seems to work well
> enough to not have the phone app crash in a loop.
> -I expect to submit 9356 on Monday morning PDT.
> JBQ
> On Sat, Mar 21, 2009 at 11:50 AM, Jean-Baptiste Queru <j...@android.com> wrote:
> > I've been working on a "better" batch of patches (now it feels more
> > like open-heart surgery with a meat cleaver):
> > -no need to delete the opencore directory or to remove it from the manifest.
> > -you need to repo download changes 9355, 9356 and 9357. No need to
> > take 9300. I know it's 3 changes instead of 1, because I had to touch
> > a few more parts of the system, but those are much cleaner.
> > -only tested on the emulator, so those might very well cause
> > regressions on dream.
> > JBQ
> > On Thu, Mar 19, 2009 at 1:07 PM, Jean-Baptiste Queru <j...@android.com> wrote:
> >> I've put together a hack that allows the system to compile and start
> >> all the way to the home app. I worked with the delicateness of
> >> open-heart surgery performed with a chainsaw.
> >> Steps:
> >> -remove the opencore files ( rm -rf external/opencore
> >> .repo/projects/external/opencore.git ). Remove opencore from your
> >> .repo/manifest.xml if you intend to repo sync the entire world but
> >> don't want to have to remove opencore every single time.
> >> -most probably do a clean build ( rm -rf out/ ; make )
> >> I've "tested" on a device/release/generic/userdebug build. On my
> >> machine, it compiles, launches. The media process dies (which probably
> >> means that downloads are busted too), as well as the music player. The
> >> browser starts and can access the network.
> >> JBQ
> >> On Wed, Mar 18, 2009 at 7:57 PM, Jean-Baptiste Queru <j...@android.com> wrote:
> >>> I've submitted the merge (106 projects!), and I believe that the tree
> >>> is in the state that it should be.
> >>> Caveats:
> >>> -THE BUILD IS BROKEN. You've been warned. There's been some drift
> >>> around OpenCORE (probably situations where new code was written in
> >>> cupcake that uses OpenCORE 1, or where APIs were removed in cupcake
> >>> that OpenCORE 2 relies on).
> >>> The proper command to try to merge the OpenCORE code should be "git
> >>> merge remotes/korg/cupcake" (I'm typing from memory).
> >>> -I'm not 100% sure that the server contains exactly what it should.
> >>> I've had a filesystem failure right as I was trying to verify it, and
> >>> I'm not gonna be able to verify until at least sometime tomorrow.
> >>> JBQ
> >>> On Wed, Mar 18, 2009 at 12:43 PM, Jean-Baptiste Queru <j...@android.com> wrote:
> >>>> I expect to start submitting the changes in about an hour, i.e.
> >>>> between 1:30pm and 2pm PDT.
> >>>> Starting right now, you may want to avoid initiating a new repo sync,
> >>>> unless you're OK ending up with a tree that might not even compile.
> >>>> JBQ
> >>>> On Tue, Mar 17, 2009 at 6:35 PM, Jean-Baptiste Queru <j...@android.com> wrote:
> >>>>> [bcc android-platform, android-framework, android-porting]
> >>>>> I'm working on merging the latest cupcake code drop into master. The
> >>>>> task is quite hairy, so the following two guidelines probably apply:
> >>>>> -please don't submit anything in gerrit, as you'll just get in my way.
> >>>>> -now is a good time to repo sync master, as I'm going to have to
> >>>>> submit the result of the merge in a state where it doesn't build, and
> >>>>> I have no idea how long it'll take to get it to build again after
> >>>>> that.
> >>>>> Questions sent directly to me that have no reason for being private
> >>>>> will likely get ignored or forwarded to a public forum with no further
> >>>>> warning.
> >>>> Questions sent directly to me that have no reason for being private
> >>>> will likely get ignored or forwarded to a public forum with no further
> >>>> warning.
> >>> Questions sent directly to me that have no reason for being private
> >>> will likely get ignored or forwarded to a public forum with no further
> >>> warning.
> >> Questions sent directly to me that have no reason for being private
> >> will likely get ignored or forwarded to a public forum with no further
> >> warning.
> > Questions sent directly to me that have no reason for being private
> > will likely get ignored or forwarded to a public forum with no further
> > warning.
> Questions sent directly to me that have no reason for being private
> will likely get ignored or forwarded to a public forum with no further
> warning.
On Sun, Mar 22, 2009 at 11:21 AM, michael m. <mir...@gmx.net> wrote:
> thanks for your patch! i'm really new to this git stuff so whats the > command for downloading this patch? repo always wants to have some > project with the download command...
>> -quickly tested both on emulator and dream, and seems to work well >> enough to not have the phone app crash in a loop.
>> -I expect to submit 9356 on Monday morning PDT.
>> JBQ
>> On Sat, Mar 21, 2009 at 11:50 AM, Jean-Baptiste Queru <j...@android.com> wrote: >> > I've been working on a "better" batch of patches (now it feels more >> > like open-heart surgery with a meat cleaver):
>> > -no need to delete the opencore directory or to remove it from the manifest.
>> > -you need to repo download changes 9355, 9356 and 9357. No need to >> > take 9300. I know it's 3 changes instead of 1, because I had to touch >> > a few more parts of the system, but those are much cleaner.
>> > -only tested on the emulator, so those might very well cause >> > regressions on dream.
>> > JBQ
>> > On Thu, Mar 19, 2009 at 1:07 PM, Jean-Baptiste Queru <j...@android.com> wrote: >> >> I've put together a hack that allows the system to compile and start >> >> all the way to the home app. I worked with the delicateness of >> >> open-heart surgery performed with a chainsaw.
>> >> Steps:
>> >> -remove the opencore files ( rm -rf external/opencore >> >> .repo/projects/external/opencore.git ). Remove opencore from your >> >> .repo/manifest.xml if you intend to repo sync the entire world but >> >> don't want to have to remove opencore every single time.
>> >> -most probably do a clean build ( rm -rf out/ ; make )
>> >> I've "tested" on a device/release/generic/userdebug build. On my >> >> machine, it compiles, launches. The media process dies (which probably >> >> means that downloads are busted too), as well as the music player. The >> >> browser starts and can access the network.
>> >> JBQ
>> >> On Wed, Mar 18, 2009 at 7:57 PM, Jean-Baptiste Queru <j...@android.com> wrote: >> >>> I've submitted the merge (106 projects!), and I believe that the tree >> >>> is in the state that it should be.
>> >>> Caveats:
>> >>> -THE BUILD IS BROKEN. You've been warned. There's been some drift >> >>> around OpenCORE (probably situations where new code was written in >> >>> cupcake that uses OpenCORE 1, or where APIs were removed in cupcake >> >>> that OpenCORE 2 relies on).
>> >>> The proper command to try to merge the OpenCORE code should be "git >> >>> merge remotes/korg/cupcake" (I'm typing from memory).
>> >>> -I'm not 100% sure that the server contains exactly what it should. >> >>> I've had a filesystem failure right as I was trying to verify it, and >> >>> I'm not gonna be able to verify until at least sometime tomorrow.
>> >>> JBQ
>> >>> On Wed, Mar 18, 2009 at 12:43 PM, Jean-Baptiste Queru <j...@android.com> wrote: >> >>>> I expect to start submitting the changes in about an hour, i.e. >> >>>> between 1:30pm and 2pm PDT.
>> >>>> Starting right now, you may want to avoid initiating a new repo sync, >> >>>> unless you're OK ending up with a tree that might not even compile.
>> >>>> JBQ
>> >>>> On Tue, Mar 17, 2009 at 6:35 PM, Jean-Baptiste Queru <j...@android.com> wrote: >> >>>>> [bcc android-platform, android-framework, android-porting]
>> >>>>> I'm working on merging the latest cupcake code drop into master. The >> >>>>> task is quite hairy, so the following two guidelines probably apply:
>> >>>>> -please don't submit anything in gerrit, as you'll just get in my way. >> >>>>> -now is a good time to repo sync master, as I'm going to have to >> >>>>> submit the result of the merge in a state where it doesn't build, and >> >>>>> I have no idea how long it'll take to get it to build again after >> >>>>> that.
>> >>>>> Questions sent directly to me that have no reason for being private >> >>>>> will likely get ignored or forwarded to a public forum with no further >> >>>>> warning.
>> >>>> Questions sent directly to me that have no reason for being private >> >>>> will likely get ignored or forwarded to a public forum with no further >> >>>> warning.
>> >>> Questions sent directly to me that have no reason for being private >> >>> will likely get ignored or forwarded to a public forum with no further >> >>> warning.
>> >> Questions sent directly to me that have no reason for being private >> >> will likely get ignored or forwarded to a public forum with no further >> >> warning.
>> > Questions sent directly to me that have no reason for being private >> > will likely get ignored or forwarded to a public forum with no further >> > warning.
>> Questions sent directly to me that have no reason for being private >> will likely get ignored or forwarded to a public forum with no further >> warning.
-- Jean-Baptiste M. "JBQ" Queru Android Engineer, Google.
Questions sent directly to me that have no reason for being private will likely get ignored or forwarded to a public forum with no further warning.
> thanks for your patch! i'm really new to this git stuff so whats the
> command for downloading this patch? repo always wants to have some
> project with the download command...
> On 22 Mrz., 06:35, Jean-Baptiste Queru <j...@android.com> wrote:
> > -quickly tested both on emulator and dream, and seems to work well
> > enough to not have the phone app crash in a loop.
> > -I expect to submit 9356 on Monday morning PDT.
> > JBQ
> > On Sat, Mar 21, 2009 at 11:50 AM, Jean-Baptiste Queru <j...@android.com> wrote:
> > > I've been working on a "better" batch of patches (now it feels more
> > > like open-heart surgery with a meat cleaver):
> > > -no need to delete the opencore directory or to remove it from the manifest.
> > > -you need to repo download changes 9355, 9356 and 9357. No need to
> > > take 9300. I know it's 3 changes instead of 1, because I had to touch
> > > a few more parts of the system, but those are much cleaner.
> > > -only tested on the emulator, so those might very well cause
> > > regressions on dream.
> > > JBQ
> > > On Thu, Mar 19, 2009 at 1:07 PM, Jean-Baptiste Queru <j...@android.com> wrote:
> > >> I've put together a hack that allows the system to compile and start
> > >> all the way to the home app. I worked with the delicateness of
> > >> open-heart surgery performed with a chainsaw.
> > >> Steps:
> > >> -remove the opencore files ( rm -rf external/opencore
> > >> .repo/projects/external/opencore.git ). Remove opencore from your
> > >> .repo/manifest.xml if you intend to repo sync the entire world but
> > >> don't want to have to remove opencore every single time.
> > >> -most probably do a clean build ( rm -rf out/ ; make )
> > >> I've "tested" on a device/release/generic/userdebug build. On my
> > >> machine, it compiles, launches. The media process dies (which probably
> > >> means that downloads are busted too), as well as the music player. The
> > >> browser starts and can access the network.
> > >> JBQ
> > >> On Wed, Mar 18, 2009 at 7:57 PM, Jean-Baptiste Queru <j...@android.com> wrote:
> > >>> I've submitted the merge (106 projects!), and I believe that the tree
> > >>> is in the state that it should be.
> > >>> Caveats:
> > >>> -THE BUILD IS BROKEN. You've been warned. There's been some drift
> > >>> around OpenCORE (probably situations where new code was written in
> > >>> cupcake that uses OpenCORE 1, or where APIs were removed in cupcake
> > >>> that OpenCORE 2 relies on).
> > >>> The proper command to try to merge the OpenCORE code should be "git
> > >>> merge remotes/korg/cupcake" (I'm typing from memory).
> > >>> -I'm not 100% sure that the server contains exactly what it should.
> > >>> I've had a filesystem failure right as I was trying to verify it, and
> > >>> I'm not gonna be able to verify until at least sometime tomorrow.
> > >>> JBQ
> > >>> On Wed, Mar 18, 2009 at 12:43 PM, Jean-Baptiste Queru <j...@android.com> wrote:
> > >>>> I expect to start submitting the changes in about an hour, i.e.
> > >>>> between 1:30pm and 2pm PDT.
> > >>>> Starting right now, you may want to avoid initiating a new repo sync,
> > >>>> unless you're OK ending up with a tree that might not even compile.
> > >>>> JBQ
> > >>>> On Tue, Mar 17, 2009 at 6:35 PM, Jean-Baptiste Queru <j...@android.com> wrote:
> > >>>>> [bcc android-platform, android-framework, android-porting]
> > >>>>> I'm working on merging the latest cupcake code drop into master. The
> > >>>>> task is quite hairy, so the following two guidelines probably apply:
> > >>>>> -please don't submit anything in gerrit, as you'll just get in my way.
> > >>>>> -now is a good time to repo sync master, as I'm going to have to
> > >>>>> submit the result of the merge in a state where it doesn't build, and
> > >>>>> I have no idea how long it'll take to get it to build again after
> > >>>>> that.
> > >>>>> Questions sent directly to me that have no reason for being private
> > >>>>> will likely get ignored or forwarded to a public forum with no further
> > >>>>> warning.
> > >>>> Questions sent directly to me that have no reason for being private
> > >>>> will likely get ignored or forwarded to a public forum with no further
> > >>>> warning.
> > >>> Questions sent directly to me that have no reason for being private
> > >>> will likely get ignored or forwarded to a public forum with no further
> > >>> warning.
> > >> Questions sent directly to me that have no reason for being private
> > >> will likely get ignored or forwarded to a public forum with no further
> > >> warning.
> > > Questions sent directly to me that have no reason for being private
> > > will likely get ignored or forwarded to a public forum with no further
> > > warning.
> > Questions sent directly to me that have no reason for being private
> > will likely get ignored or forwarded to a public forum with no further
> > warning.
>> > were you actually wishing for 'ifeq' instead?
>> > Regards, >> > Rajesh.S
>> > On Mar 22, 12:15 am, Jean-Baptiste Queru <j...@android.com> wrote: >> >> Well, repo could be used to do a repo forall -c git checkout <tag>, >> >> but that'd require to tag every single project, which would really >> >> only be practical for admins. On top of that I believe that we only >> >> want to tag actual long-term releases, and whatever state master was >> >> on before the merge last Wednesday wasn't a release.
>> >> The real process would have been to do a "repo manifest -r -o -" in a >> >> synced tree before the merge, and post this manifest here on the >> >> group. This can still be done today by someone who has a synced tree >> >> in the state as of Wednesday noon PDT. I don't have such a tree, and >> >> my top priority at this point is to help people move ahead, not to >> >> help them stay behind.
>> >> The breakage wasn't supposed to last that long. I expected a day at >> >> most, and it's been 3 days already. I'm really sorry about that. I've >> >> been trying to fix things, but it turned out to be much harder than I >> >> had anticipated, at several different levels.
>> >> If you'd like to help, my current sticky point is to find out why my >> >> LOCAL_CFLAGS inhttps://review.source.android.com/Gerrit#patch,sidebyside,9356,1,medi... >> >> doesn't seem to get passed to the compiler, so that I've had to >> >> temporarily use #if 0 instead of #ifndef opencore in the source tree. >> >> We'll also need a better fix for 9357, as I guess it should be >> >> possible to prevent that crash without having to modify the phone app.
>> >> JBQ
>> >> On Sat, Mar 21, 2009 at 1:20 PM, Rajesh S <rajeshs...@gmail.com> wrote:
>> >> > JBQ does this 'repo' script have support for tagging at all? >> >> > I could not find much in the docs.. am I missing it?
>> >> > And I'll try the 3 instead of 9300 on the device.
>> >> > Regards, >> >> > Rajesh.S
>> >> > On Mar 21, 7:23 pm, André Oriani <aori...@gmail.com> wrote: >> >> >> Hi JBQ,
>> >> >> I would suggest to apply a tag so we can know what is the last stable >> >> >> piece of code on master branch before doing a repo sync and getting a >> >> >>brokenbuild. That would certainly help.
>> >> >> Thanks, >> >> >> André Oriani
>> >> >> On 21 mar, 15:50, Jean-Baptiste Queru <j...@android.com> wrote:
>> >> >> > I've been working on a "better" batch of patches (now it feels more >> >> >> > like open-heart surgery with a meat cleaver):
>> >> >> > -no need to delete the opencore directory or to remove it from the manifest.
>> >> >> > -you need to repo download changes 9355, 9356 and 9357. No need to >> >> >> > take 9300. I know it's 3 changes instead of 1, because I had to touch >> >> >> > a few more parts of the system, but those are much cleaner.
>> >> >> > -only tested on the emulator, so those might very well cause >> >> >> > regressions on dream.
>> >> >> > JBQ
>> >> >> > On Thu, Mar 19, 2009 at 1:07 PM, Jean-Baptiste Queru <j...@android.com> wrote: >> >> >> > > I've put together a hack that allows the system to compile and start >> >> >> > > all the way to the home app. I worked with the delicateness of >> >> >> > > open-heart surgery performed with a chainsaw.
>> >> >> > > Steps:
>> >> >> > > -remove the opencore files ( rm -rf external/opencore >> >> >> > > .repo/projects/external/opencore.git ). Remove opencore from your >> >> >> > > .repo/manifest.xml if you intend to repo sync the entire world but >> >> >> > > don't want to have to remove opencore every single time.
>> >> >> > > -most probably do a clean build ( rm -rf out/ ; make )
>> >> >> > > I've "tested" on a device/release/generic/userdebug build. On my >> >> >> > > machine, it compiles, launches. The media process dies (which probably >> >> >> > > means that downloads are busted too), as well as the music player. The >> >> >> > > browser starts and can access the network.
>> >> >> > > JBQ
>> >> >> > > On Wed, Mar 18, 2009 at 7:57 PM, Jean-Baptiste Queru <j...@android.com> wrote: >> >> >> > >> I've submitted the merge (106 projects!), and I believe that the tree >> >> >> > >> is in the state that it should be.
>> >> >> > >> Caveats:
>> >> >> > >> -THE BUILD ISBROKEN. You've been warned. There's been some drift >> >> >> > >> around OpenCORE (probably situations where new code was written in >> >> >> > >>cupcakethat uses OpenCORE 1, or where APIs were removed incupcake >> >> >> > >> that OpenCORE 2 relies on).
>> >> >> > >> The proper command to try to merge the OpenCORE code should be "git >> >> >> > >> merge remotes/korg/cupcake" (I'm typing from memory).
>> >> >> > >> -I'm not 100% sure that the server contains exactly what it should. >> >> >> > >> I've had a filesystem failure right as I was trying to verify it, and >> >> >> > >> I'm not gonna be able to verify until at least sometime tomorrow.
>> >> >> > >> JBQ
>> >> >> > >> On Wed, Mar 18, 2009 at 12:43 PM, Jean-Baptiste Queru <j...@android.com> wrote: >> >> >> > >>> I expect to start submitting the changes in about an hour, i.e. >> >> >> > >>> between 1:30pm and 2pm PDT.
>> >> >> > >>> Starting right now, you may want to avoid initiating a new repo sync, >> >> >> > >>> unless you're OK ending up with a tree that might not even compile.
>> >> >> > >>> JBQ
>> >> >> > >>> On Tue, Mar 17, 2009 at 6:35 PM, Jean-Baptiste Queru <j...@android.com> wrote: >> >> >> > >>>> [bcc android-platform, android-framework, android-porting]
>> >> >> > >>>> I'm working on merging the latestcupcakecode drop into master. The >> >> >> > >>>> task is quite hairy, so the following two guidelines probably apply:
>> >> >> > >>>> -please don't submit anything in gerrit, as you'll just get in my way. >> >> >> > >>>> -now is a good time to repo sync master, as I'm going to have to >> >> >> > >>>> submit the result of the merge in a state where it doesn't build, and >> >> >> > >>>> I have no idea how long it'll take to get it to build again after >> >> >> > >>>> that.
>> >> >> > >>>> Questions sent directly to me that have no reason for being private >> >> >> > >>>> will likely get ignored or forwarded to a public forum with no further >> >> >> > >>>> warning.
>> >> >> > >>> Questions sent directly to me that have no reason for being private >> >> >> > >>> will likely get ignored or forwarded to a public forum with no further >> >> >> > >>> warning.
>> >> >> > >> Questions sent directly to me that have no reason for being private >> >> >> > >> will likely get ignored or forwarded to a public forum with no further >> >> >> > >> warning.
>> >> >> > > Questions sent directly to me that have no reason for being private >> >> >> > > will likely get ignored or forwarded to a public forum with no further >> >> >> > > warning.
>> >> >> > Questions sent directly to me that have no reason for being private >> >> >> > will likely get ignored or forwarded to a public forum with no further >> >> >> > warning.
>> >> Questions sent directly to me that have no reason for being private >> >> will likely get ignored or forwarded to a public forum with no further >> >> warning.
>> Questions sent directly to me that have no reason for being private >> will likely get ignored or forwarded to a public forum with no further >> warning.
-- Jean-Baptiste M. "JBQ" Queru Android Engineer, Google.
Questions sent directly to me that have no reason for being private will likely get ignored or forwarded to a public forum with no further warning.
> -quickly tested both on emulator and dream, and seems to work well
> enough to not have the phone app crash in a loop.
> -I expect to submit 9356 on Monday morning PDT.
> JBQ
> On Sat, Mar 21, 2009 at 11:50 AM, Jean-Baptiste Queru <j...@android.com> wrote:
> > I've been working on a "better" batch of patches (now it feels more
> > like open-heart surgery with a meat cleaver):
> > -no need to delete the opencore directory or to remove it from the manifest.
> > -you need to repo download changes 9355, 9356 and 9357. No need to
> > take 9300. I know it's 3 changes instead of 1, because I had to touch
> > a few more parts of the system, but those are much cleaner.
> > -only tested on the emulator, so those might very well cause
> > regressions on dream.
> > JBQ
> > On Thu, Mar 19, 2009 at 1:07 PM, Jean-Baptiste Queru <j...@android.com> wrote:
> >> I've put together a hack that allows the system to compile and start
> >> all the way to the home app. I worked with the delicateness of
> >> open-heart surgery performed with a chainsaw.
> >> Steps:
> >> -remove the opencore files ( rm -rf external/opencore
> >> .repo/projects/external/opencore.git ). Remove opencore from your
> >> .repo/manifest.xml if you intend to repo sync the entire world but
> >> don't want to have to remove opencore every single time.
> >> -most probably do a clean build ( rm -rf out/ ; make )
> >> I've "tested" on a device/release/generic/userdebug build. On my
> >> machine, it compiles, launches. The media process dies (which probably
> >> means that downloads are busted too), as well as the music player. The
> >> browser starts and can access the network.
> >> JBQ
> >> On Wed, Mar 18, 2009 at 7:57 PM, Jean-Baptiste Queru <j...@android.com> wrote:
> >>> I've submitted the merge (106 projects!), and I believe that the tree
> >>> is in the state that it should be.
> >>> Caveats:
> >>> -THE BUILD IS BROKEN. You've been warned. There's been some drift
> >>> around OpenCORE (probably situations where new code was written in
> >>> cupcake that uses OpenCORE 1, or where APIs were removed in cupcake
> >>> that OpenCORE 2 relies on).
> >>> The proper command to try to merge the OpenCORE code should be "git
> >>> merge remotes/korg/cupcake" (I'm typing from memory).
> >>> -I'm not 100% sure that the server contains exactly what it should.
> >>> I've had a filesystem failure right as I was trying to verify it, and
> >>> I'm not gonna be able to verify until at least sometime tomorrow.
> >>> JBQ
> >>> On Wed, Mar 18, 2009 at 12:43 PM, Jean-Baptiste Queru <j...@android.com> wrote:
> >>>> I expect to start submitting the changes in about an hour, i.e.
> >>>> between 1:30pm and 2pm PDT.
> >>>> Starting right now, you may want to avoid initiating a new repo sync,
> >>>> unless you're OK ending up with a tree that might not even compile.
> >>>> JBQ
> >>>> On Tue, Mar 17, 2009 at 6:35 PM, Jean-Baptiste Queru <j...@android.com> wrote:
> >>>>> [bcc android-platform, android-framework, android-porting]
> >>>>> I'm working on merging the latest cupcake code drop into master. The
> >>>>> task is quite hairy, so the following two guidelines probably apply:
> >>>>> -please don't submit anything in gerrit, as you'll just get in my way.
> >>>>> -now is a good time to repo sync master, as I'm going to have to
> >>>>> submit the result of the merge in a state where it doesn't build, and
> >>>>> I have no idea how long it'll take to get it to build again after
> >>>>> that.
> >>>>> Questions sent directly to me that have no reason for being private
> >>>>> will likely get ignored or forwarded to a public forum with no further
> >>>>> warning.
> >>>> Questions sent directly to me that have no reason for being private
> >>>> will likely get ignored or forwarded to a public forum with no further
> >>>> warning.
> >>> Questions sent directly to me that have no reason for being private
> >>> will likely get ignored or forwarded to a public forum with no further
> >>> warning.
> >> Questions sent directly to me that have no reason for being private
> >> will likely get ignored or forwarded to a public forum with no further
> >> warning.
> > Questions sent directly to me that have no reason for being private
> > will likely get ignored or forwarded to a public forum with no further
> > warning.
> Questions sent directly to me that have no reason for being private
> will likely get ignored or forwarded to a public forum with no further
> warning.
> On Mar 22, 1:35 pm, Jean-Baptiste Queru <j...@android.com> wrote: >> [still bcc android-platform, android-framework, android-porting]
>> Latest status:
>> -we're back to one patch: 9356.
>> -build with "BUILD_WITHOUT_PV=true make"
>> -quickly tested both on emulator and dream, and seems to work well >> enough to not have the phone app crash in a loop.
>> -I expect to submit 9356 on Monday morning PDT.
>> JBQ
>> On Sat, Mar 21, 2009 at 11:50 AM, Jean-Baptiste Queru <j...@android.com> wrote: >> > I've been working on a "better" batch of patches (now it feels more >> > like open-heart surgery with a meat cleaver):
>> > -no need to delete the opencore directory or to remove it from the manifest.
>> > -you need to repo download changes 9355, 9356 and 9357. No need to >> > take 9300. I know it's 3 changes instead of 1, because I had to touch >> > a few more parts of the system, but those are much cleaner.
>> > -only tested on the emulator, so those might very well cause >> > regressions on dream.
>> > JBQ
>> > On Thu, Mar 19, 2009 at 1:07 PM, Jean-Baptiste Queru <j...@android.com> wrote: >> >> I've put together a hack that allows the system to compile and start >> >> all the way to the home app. I worked with the delicateness of >> >> open-heart surgery performed with a chainsaw.
>> >> Steps:
>> >> -remove the opencore files ( rm -rf external/opencore >> >> .repo/projects/external/opencore.git ). Remove opencore from your >> >> .repo/manifest.xml if you intend to repo sync the entire world but >> >> don't want to have to remove opencore every single time.
>> >> -most probably do a clean build ( rm -rf out/ ; make )
>> >> I've "tested" on a device/release/generic/userdebug build. On my >> >> machine, it compiles, launches. The media process dies (which probably >> >> means that downloads are busted too), as well as the music player. The >> >> browser starts and can access the network.
>> >> JBQ
>> >> On Wed, Mar 18, 2009 at 7:57 PM, Jean-Baptiste Queru <j...@android.com> wrote: >> >>> I've submitted the merge (106 projects!), and I believe that the tree >> >>> is in the state that it should be.
>> >>> Caveats:
>> >>> -THE BUILD IS BROKEN. You've been warned. There's been some drift >> >>> around OpenCORE (probably situations where new code was written in >> >>> cupcake that uses OpenCORE 1, or where APIs were removed in cupcake >> >>> that OpenCORE 2 relies on).
>> >>> The proper command to try to merge the OpenCORE code should be "git >> >>> merge remotes/korg/cupcake" (I'm typing from memory).
>> >>> -I'm not 100% sure that the server contains exactly what it should. >> >>> I've had a filesystem failure right as I was trying to verify it, and >> >>> I'm not gonna be able to verify until at least sometime tomorrow.
>> >>> JBQ
>> >>> On Wed, Mar 18, 2009 at 12:43 PM, Jean-Baptiste Queru <j...@android.com> wrote: >> >>>> I expect to start submitting the changes in about an hour, i.e. >> >>>> between 1:30pm and 2pm PDT.
>> >>>> Starting right now, you may want to avoid initiating a new repo sync, >> >>>> unless you're OK ending up with a tree that might not even compile.
>> >>>> JBQ
>> >>>> On Tue, Mar 17, 2009 at 6:35 PM, Jean-Baptiste Queru <j...@android.com> wrote: >> >>>>> [bcc android-platform, android-framework, android-porting]
>> >>>>> I'm working on merging the latest cupcake code drop into master. The >> >>>>> task is quite hairy, so the following two guidelines probably apply:
>> >>>>> -please don't submit anything in gerrit, as you'll just get in my way. >> >>>>> -now is a good time to repo sync master, as I'm going to have to >> >>>>> submit the result of the merge in a state where it doesn't build, and >> >>>>> I have no idea how long it'll take to get it to build again after >> >>>>> that.
>> >>>>> Questions sent directly to me that have no reason for being private >> >>>>> will likely get ignored or forwarded to a public forum with no further >> >>>>> warning.
>> >>>> Questions sent directly to me that have no reason for being private >> >>>> will likely get ignored or forwarded to a public forum with no further >> >>>> warning.
>> >>> Questions sent directly to me that have no reason for being private >> >>> will likely get ignored or forwarded to a public forum with no further >> >>> warning.
>> >> Questions sent directly to me that have no reason for being private >> >> will likely get ignored or forwarded to a public forum with no further >> >> warning.
>> > Questions sent directly to me that have no reason for being private >> > will likely get ignored or forwarded to a public forum with no further >> > warning.
>> Questions sent directly to me that have no reason for being private >> will likely get ignored or forwarded to a public forum with no further >> warning.
-- Jean-Baptiste M. "JBQ" Queru Android Engineer, Google.
Questions sent directly to me that have no reason for being private will likely get ignored or forwarded to a public forum with no further warning.
Sorry if this has been addressed elsewhere... should we expect better
list scrolling performance on the G1 compared to the cupcake build?
Lists seem to scroll much smoother on the G1. Is this due to GL or is
there some other factor?
Thanks!
-Brad
On Mar 23, 4:04 pm, Jean-Baptiste Queru <j...@android.com> wrote:
> > On Mar 22, 1:35 pm, Jean-Baptiste Queru <j...@android.com> wrote:
> >> [still bcc android-platform, android-framework, android-porting]
> >> Latest status:
> >> -we're back to one patch: 9356.
> >> -build with "BUILD_WITHOUT_PV=true make"
> >> -quickly tested both on emulator and dream, and seems to work well
> >> enough to not have the phone app crash in a loop.
> >> -I expect to submit 9356 on Monday morning PDT.
> >> JBQ
> >> On Sat, Mar 21, 2009 at 11:50 AM, Jean-Baptiste Queru <j...@android.com> wrote:
> >> > I've been working on a "better" batch of patches (now it feels more
> >> > like open-heart surgery with a meat cleaver):
> >> > -no need to delete the opencore directory or to remove it from the manifest.
> >> > -you need to repo download changes 9355, 9356 and 9357. No need to
> >> > take 9300. I know it's 3 changes instead of 1, because I had to touch
> >> > a few more parts of the system, but those are much cleaner.
> >> > -only tested on the emulator, so those might very well cause
> >> > regressions on dream.
> >> > JBQ
> >> > On Thu, Mar 19, 2009 at 1:07 PM, Jean-Baptiste Queru <j...@android.com> wrote:
> >> >> I've put together a hack that allows the system to compile and start
> >> >> all the way to the home app. I worked with the delicateness of
> >> >> open-heart surgery performed with a chainsaw.
> >> >> Steps:
> >> >> -remove the opencore files ( rm -rf external/opencore
> >> >> .repo/projects/external/opencore.git ). Remove opencore from your
> >> >> .repo/manifest.xml if you intend to repo sync the entire world but
> >> >> don't want to have to remove opencore every single time.
> >> >> -most probably do a clean build ( rm -rf out/ ; make )
> >> >> I've "tested" on a device/release/generic/userdebug build. On my
> >> >> machine, it compiles, launches. The media process dies (which probably
> >> >> means that downloads are busted too), as well as the music player. The
> >> >> browser starts and can access the network.
> >> >> JBQ
> >> >> On Wed, Mar 18, 2009 at 7:57 PM, Jean-Baptiste Queru <j...@android.com> wrote:
> >> >>> I've submitted the merge (106 projects!), and I believe that the tree
> >> >>> is in the state that it should be.
> >> >>> Caveats:
> >> >>> -THE BUILD IS BROKEN. You've been warned. There's been some drift
> >> >>> around OpenCORE (probably situations where new code was written in
> >> >>> cupcake that uses OpenCORE 1, or where APIs were removed in cupcake
> >> >>> that OpenCORE 2 relies on).
> >> >>> The proper command to try to merge the OpenCORE code should be "git
> >> >>> merge remotes/korg/cupcake" (I'm typing from memory).
> >> >>> -I'm not 100% sure that the server contains exactly what it should.
> >> >>> I've had a filesystem failure right as I was trying to verify it, and
> >> >>> I'm not gonna be able to verify until at least sometime tomorrow.
> >> >>> JBQ
> >> >>> On Wed, Mar 18, 2009 at 12:43 PM, Jean-Baptiste Queru <j...@android.com> wrote:
> >> >>>> I expect to start submitting the changes in about an hour, i.e.
> >> >>>> between 1:30pm and 2pm PDT.
> >> >>>> Starting right now, you may want to avoid initiating a new repo sync,
> >> >>>> unless you're OK ending up with a tree that might not even compile.
> >> >>>> JBQ
> >> >>>> On Tue, Mar 17, 2009 at 6:35 PM, Jean-Baptiste Queru <j...@android.com> wrote:
> >> >>>>> [bcc android-platform, android-framework, android-porting]
> >> >>>>> I'm working on merging the latest cupcake code drop into master. The
> >> >>>>> task is quite hairy, so the following two guidelines probably apply:
> >> >>>>> -please don't submit anything in gerrit, as you'll just get in my way.
> >> >>>>> -now is a good time to repo sync master, as I'm going to have to
> >> >>>>> submit the result of the merge in a state where it doesn't build, and
> >> >>>>> I have no idea how long it'll take to get it to build again after
> >> >>>>> that.
> >> >>>>> Questions sent directly to me that have no reason for being private
> >> >>>>> will likely get ignored or forwarded to a public forum with no further
> >> >>>>> warning.
> >> >>>> Questions sent directly to me that have no reason for being private
> >> >>>> will likely get ignored or forwarded to a public forum with no further
> >> >>>> warning.
> >> >>> Questions sent directly to me that have no reason for being private
> >> >>> will likely get ignored or forwarded to a public forum with no further
> >> >>> warning.
> >> >> Questions sent directly to me that have no reason for being private
> >> >> will likely get ignored or forwarded to a public forum with no further
> >> >> warning.
> >> > Questions sent directly to me that have no reason for being private
> >> > will likely get ignored or forwarded to a public forum with no further
> >> > warning.
> >> Questions sent directly to me that have no reason for being private
> >> will likely get ignored or forwarded to a public forum with no further
> >> warning.
> Questions sent directly to me that have no reason for being private
> will likely get ignored or forwarded to a public forum with no further
> warning.
On Mon, Mar 23, 2009 at 3:10 PM, Brad Larson <bklar...@gmail.com> wrote:
> Hey JBQ,
> Sorry if this has been addressed elsewhere... should we expect better > list scrolling performance on the G1 compared to the cupcake build? > Lists seem to scroll much smoother on the G1. Is this due to GL or is > there some other factor?
> Thanks! > -Brad
> On Mar 23, 4:04 pm, Jean-Baptiste Queru <j...@android.com> wrote: >> I'll have a look at those.
>> JBQ
>> On Mon, Mar 23, 2009 at 2:02 PM, Scott Tsai <scottt...@gmail.com> wrote:
>> > Since 9356 was recently merged, I repo sync'ed and can verify that >> > "BUILD_WITHOUT_PV=true make" gives me a successful build.
>> > On Mar 22, 1:35 pm, Jean-Baptiste Queru <j...@android.com> wrote: >> >> [still bcc android-platform, android-framework, android-porting]
>> >> Latest status:
>> >> -we're back to one patch: 9356.
>> >> -build with "BUILD_WITHOUT_PV=true make"
>> >> -quickly tested both on emulator and dream, and seems to work well >> >> enough to not have the phone app crash in a loop.
>> >> -I expect to submit 9356 on Monday morning PDT.
>> >> JBQ
>> >> On Sat, Mar 21, 2009 at 11:50 AM, Jean-Baptiste Queru <j...@android.com> wrote: >> >> > I've been working on a "better" batch of patches (now it feels more >> >> > like open-heart surgery with a meat cleaver):
>> >> > -no need to delete the opencore directory or to remove it from the manifest.
>> >> > -you need to repo download changes 9355, 9356 and 9357. No need to >> >> > take 9300. I know it's 3 changes instead of 1, because I had to touch >> >> > a few more parts of the system, but those are much cleaner.
>> >> > -only tested on the emulator, so those might very well cause >> >> > regressions on dream.
>> >> > JBQ
>> >> > On Thu, Mar 19, 2009 at 1:07 PM, Jean-Baptiste Queru <j...@android.com> wrote: >> >> >> I've put together a hack that allows the system to compile and start >> >> >> all the way to the home app. I worked with the delicateness of >> >> >> open-heart surgery performed with a chainsaw.
>> >> >> Steps:
>> >> >> -remove the opencore files ( rm -rf external/opencore >> >> >> .repo/projects/external/opencore.git ). Remove opencore from your >> >> >> .repo/manifest.xml if you intend to repo sync the entire world but >> >> >> don't want to have to remove opencore every single time.
>> >> >> -most probably do a clean build ( rm -rf out/ ; make )
>> >> >> I've "tested" on a device/release/generic/userdebug build. On my >> >> >> machine, it compiles, launches. The media process dies (which probably >> >> >> means that downloads are busted too), as well as the music player. The >> >> >> browser starts and can access the network.
>> >> >> JBQ
>> >> >> On Wed, Mar 18, 2009 at 7:57 PM, Jean-Baptiste Queru <j...@android.com> wrote: >> >> >>> I've submitted the merge (106 projects!), and I believe that the tree >> >> >>> is in the state that it should be.
>> >> >>> Caveats:
>> >> >>> -THE BUILD IS BROKEN. You've been warned. There's been some drift >> >> >>> around OpenCORE (probably situations where new code was written in >> >> >>> cupcake that uses OpenCORE 1, or where APIs were removed in cupcake >> >> >>> that OpenCORE 2 relies on).
>> >> >>> The proper command to try to merge the OpenCORE code should be "git >> >> >>> merge remotes/korg/cupcake" (I'm typing from memory).
>> >> >>> -I'm not 100% sure that the server contains exactly what it should. >> >> >>> I've had a filesystem failure right as I was trying to verify it, and >> >> >>> I'm not gonna be able to verify until at least sometime tomorrow.
>> >> >>> JBQ
>> >> >>> On Wed, Mar 18, 2009 at 12:43 PM, Jean-Baptiste Queru <j...@android.com> wrote: >> >> >>>> I expect to start submitting the changes in about an hour, i.e. >> >> >>>> between 1:30pm and 2pm PDT.
>> >> >>>> Starting right now, you may want to avoid initiating a new repo sync, >> >> >>>> unless you're OK ending up with a tree that might not even compile.
>> >> >>>> JBQ
>> >> >>>> On Tue, Mar 17, 2009 at 6:35 PM, Jean-Baptiste Queru <j...@android.com> wrote: >> >> >>>>> [bcc android-platform, android-framework, android-porting]
>> >> >>>>> I'm working on merging the latest cupcake code drop into master. The >> >> >>>>> task is quite hairy, so the following two guidelines probably apply:
>> >> >>>>> -please don't submit anything in gerrit, as you'll just get in my way. >> >> >>>>> -now is a good time to repo sync master, as I'm going to have to >> >> >>>>> submit the result of the merge in a state where it doesn't build, and >> >> >>>>> I have no idea how long it'll take to get it to build again after >> >> >>>>> that.
>> >> >>>>> Questions sent directly to me that have no reason for being private >> >> >>>>> will likely get ignored or forwarded to a public forum with no further >> >> >>>>> warning.
>> >> >>>> Questions sent directly to me that have no reason for being private >> >> >>>> will likely get ignored or forwarded to a public forum with no further >> >> >>>> warning.
>> >> >>> Questions sent directly to me that have no reason for being private >> >> >>> will likely get ignored or forwarded to a public forum with no further >> >> >>> warning.
>> >> >> Questions sent directly to me that have no reason for being private >> >> >> will likely get ignored or forwarded to a public forum with no further >> >> >> warning.
>> >> > Questions sent directly to me that have no reason for being private >> >> > will likely get ignored or forwarded to a public forum with no further >> >> > warning.
>> >> Questions sent directly to me that have no reason for being private >> >> will likely get ignored or forwarded to a public forum with no further >> >> warning.
>> Questions sent directly to me that have no reason for being private >> will likely get ignored or forwarded to a public forum with no further >> warning.
-- Jean-Baptiste M. "JBQ" Queru Android Engineer, Google.
Questions sent directly to me that have no reason for being private will likely get ignored or forwarded to a public forum with no further warning.
>> On Mar 22, 1:35 pm, Jean-Baptiste Queru <j...@android.com> wrote: >>> [still bcc android-platform, android-framework, android-porting]
>>> Latest status:
>>> -we're back to one patch: 9356.
>>> -build with "BUILD_WITHOUT_PV=true make"
>>> -quickly tested both on emulator and dream, and seems to work well >>> enough to not have the phone app crash in a loop.
>>> -I expect to submit 9356 on Monday morning PDT.
>>> JBQ
>>> On Sat, Mar 21, 2009 at 11:50 AM, Jean-Baptiste Queru <j...@android.com> wrote: >>> > I've been working on a "better" batch of patches (now it feels more >>> > like open-heart surgery with a meat cleaver):
>>> > -no need to delete the opencore directory or to remove it from the manifest.
>>> > -you need to repo download changes 9355, 9356 and 9357. No need to >>> > take 9300. I know it's 3 changes instead of 1, because I had to touch >>> > a few more parts of the system, but those are much cleaner.
>>> > -only tested on the emulator, so those might very well cause >>> > regressions on dream.
>>> > JBQ
>>> > On Thu, Mar 19, 2009 at 1:07 PM, Jean-Baptiste Queru <j...@android.com> wrote: >>> >> I've put together a hack that allows the system to compile and start >>> >> all the way to the home app. I worked with the delicateness of >>> >> open-heart surgery performed with a chainsaw.
>>> >> Steps:
>>> >> -remove the opencore files ( rm -rf external/opencore >>> >> .repo/projects/external/opencore.git ). Remove opencore from your >>> >> .repo/manifest.xml if you intend to repo sync the entire world but >>> >> don't want to have to remove opencore every single time.
>>> >> -most probably do a clean build ( rm -rf out/ ; make )
>>> >> I've "tested" on a device/release/generic/userdebug build. On my >>> >> machine, it compiles, launches. The media process dies (which probably >>> >> means that downloads are busted too), as well as the music player. The >>> >> browser starts and can access the network.
>>> >> JBQ
>>> >> On Wed, Mar 18, 2009 at 7:57 PM, Jean-Baptiste Queru <j...@android.com> wrote: >>> >>> I've submitted the merge (106 projects!), and I believe that the tree >>> >>> is in the state that it should be.
>>> >>> Caveats:
>>> >>> -THE BUILD IS BROKEN. You've been warned. There's been some drift >>> >>> around OpenCORE (probably situations where new code was written in >>> >>> cupcake that uses OpenCORE 1, or where APIs were removed in cupcake >>> >>> that OpenCORE 2 relies on).
>>> >>> The proper command to try to merge the OpenCORE code should be "git >>> >>> merge remotes/korg/cupcake" (I'm typing from memory).
>>> >>> -I'm not 100% sure that the server contains exactly what it should. >>> >>> I've had a filesystem failure right as I was trying to verify it, and >>> >>> I'm not gonna be able to verify until at least sometime tomorrow.
>>> >>> JBQ
>>> >>> On Wed, Mar 18, 2009 at 12:43 PM, Jean-Baptiste Queru <j...@android.com> wrote: >>> >>>> I expect to start submitting the changes in about an hour, i.e. >>> >>>> between 1:30pm and 2pm PDT.
>>> >>>> Starting right now, you may want to avoid initiating a new repo sync, >>> >>>> unless you're OK ending up with a tree that might not even compile.
>>> >>>> JBQ
>>> >>>> On Tue, Mar 17, 2009 at 6:35 PM, Jean-Baptiste Queru <j...@android.com> wrote: >>> >>>>> [bcc android-platform, android-framework, android-porting]
>>> >>>>> I'm working on merging the latest cupcake code drop into master. The >>> >>>>> task is quite hairy, so the following two guidelines probably apply:
>>> >>>>> -please don't submit anything in gerrit, as you'll just get in my way. >>> >>>>> -now is a good time to repo sync master, as I'm going to have to >>> >>>>> submit the result of the merge in a state where it doesn't build, and >>> >>>>> I have no idea how long it'll take to get it to build again after >>> >>>>> that.
>>> >>>>> Questions sent directly to me that have no reason for being private >>> >>>>> will likely get ignored or forwarded to a public forum with no further >>> >>>>> warning.
>>> >>>> Questions sent directly to me that have no reason for being private >>> >>>> will likely get ignored or forwarded to a public forum with no further >>> >>>> warning.
>>> >>> Questions sent directly to me that have no reason for being private >>> >>> will likely get ignored or forwarded to a public forum with no further >>> >>> warning.
>>> >> Questions sent directly to me that have no reason for being private >>> >> will likely get ignored or forwarded to a public forum with no further >>> >> warning.
>>> > Questions sent directly to me that have no reason for being private >>> > will likely get ignored or forwarded to a public forum with no further >>> > warning.
>>> Questions sent directly to me that have no reason for being private >>> will likely get ignored or forwarded to a public forum with no further >>> warning.
> Questions sent directly to me that have no reason for being private > will likely get ignored or forwarded to a public forum with no further > warning.
-- Jean-Baptiste M. "JBQ" Queru Android Engineer, Google.
Questions sent directly to me that have no reason for being private will likely get ignored or forwarded to a public forum with no further warning.
Thanks for the reviews! :)
With 9326, 9327 and 9329 merged, I could complete a:
TARGET_ARCH:=x86
TARGET_PRODUCT:=eee_701
build on my Fedora 11 machine.
The Android prebuilt toolchains don't have STL as part of libstdc++
but Webkit needs it so a partial copy of the header files is included
under "external/webkit/WebKit/android/stl". When doing a simulator
build with the gcc-4.4 toolchain that comes with Fedora this then
fails with
In file included from external/webkit/WebCore/WebCorePrefixAndroid.h:
54,
from <command-line>:2:
external/webkit/WebKit/android/stl/algorithm:79: error: redefinition
of ‘template<class _Tp> void std::swap(_Tp&, _Tp&)’
/usr/lib/gcc/x86_64-redhat-linux/4.4.0/../../../../include/c++/4.4.0/
bits/move.h:81: error: ‘template<class _Tp> void std::swap(_Tp&,
_Tp&)’ previously declared here
( .. >_<... paragraphs below are going to read like a rant ...)
.... So the next time an engineer working on the android code base
wants to integrate a third party C++ library that needs STL they'll
include another copy and when porting Android to another embedded
Linux platform which already comes with a toolchain I'll need to build
a bionic toolchain first which increases the difficulty of porting to
non-Arm and x86 platforms substantially.
I sure hope the benefits of using bionic are worth all the extra
effort it causes ;)
On Mar 24, 6:28 am, Jean-Baptiste Queru <j...@android.com> wrote:
> >> On Mar 22, 1:35 pm, Jean-Baptiste Queru <j...@android.com> wrote:
> >>> [still bcc android-platform, android-framework, android-porting]
> >>> Latest status:
> >>> -we're back to one patch: 9356.
> >>> -build with "BUILD_WITHOUT_PV=true make"
> >>> -quickly tested both on emulator and dream, and seems to work well
> >>> enough to not have the phone app crash in a loop.
> >>> -I expect to submit 9356 on Monday morning PDT.
> >>> JBQ
> >>> On Sat, Mar 21, 2009 at 11:50 AM, Jean-Baptiste Queru <j...@android.com> wrote:
> >>> > I've been working on a "better" batch of patches (now it feels more
> >>> > like open-heart surgery with a meat cleaver):
> >>> > -no need to delete the opencore directory or to remove it from the manifest.
> >>> > -you need to repo download changes 9355, 9356 and 9357. No need to
> >>> > take 9300. I know it's 3 changes instead of 1, because I had to touch
> >>> > a few more parts of the system, but those are much cleaner.
> >>> > -only tested on the emulator, so those might very well cause
> >>> > regressions on dream.
> >>> > JBQ
> >>> > On Thu, Mar 19, 2009 at 1:07 PM, Jean-Baptiste Queru <j...@android.com> wrote:
> >>> >> I've put together a hack that allows the system to compile and start
> >>> >> all the way to the home app. I worked with the delicateness of
> >>> >> open-heart surgery performed with a chainsaw.
> >>> >> Steps:
> >>> >> -remove the opencore files ( rm -rf external/opencore
> >>> >> .repo/projects/external/opencore.git ). Remove opencore from your
> >>> >> .repo/manifest.xml if you intend to repo sync the entire world but
> >>> >> don't want to have to remove opencore every single time.
> >>> >> -most probably do a clean build ( rm -rf out/ ; make )
> >>> >> I've "tested" on a device/release/generic/userdebug build. On my
> >>> >> machine, it compiles, launches. The media process dies (which probably
> >>> >> means that downloads are busted too), as well as the music player. The
> >>> >> browser starts and can access the network.
> >>> >> JBQ
> >>> >> On Wed, Mar 18, 2009 at 7:57 PM, Jean-Baptiste Queru <j...@android.com> wrote:
> >>> >>> I've submitted the merge (106 projects!), and I believe that the tree
> >>> >>> is in the state that it should be.
> >>> >>> Caveats:
> >>> >>> -THE BUILD IS BROKEN. You've been warned. There's been some drift
> >>> >>> around OpenCORE (probably situations where new code was written in
> >>> >>> cupcake that uses OpenCORE 1, or where APIs were removed in cupcake
> >>> >>> that OpenCORE 2 relies on).
> >>> >>> The proper command to try to merge the OpenCORE code should be "git
> >>> >>> merge remotes/korg/cupcake" (I'm typing from memory).
> >>> >>> -I'm not 100% sure that the server contains exactly what it should.
> >>> >>> I've had a filesystem failure right as I was trying to verify it, and
> >>> >>> I'm not gonna be able to verify until at least sometime tomorrow.
> >>> >>> JBQ
> >>> >>> On Wed, Mar 18, 2009 at 12:43 PM, Jean-Baptiste Queru <j...@android.com> wrote:
> >>> >>>> I expect to start submitting the changes in about an hour, i.e.
> >>> >>>> between 1:30pm and 2pm PDT.
> >>> >>>> Starting right now, you may want to avoid initiating a new repo sync,
> >>> >>>> unless you're OK ending up with a tree that might not even compile.
> >>> >>>> JBQ
> >>> >>>> On Tue, Mar 17, 2009 at 6:35 PM, Jean-Baptiste Queru <j...@android.com> wrote:
> >>> >>>>> [bcc android-platform, android-framework, android-porting]
> >>> >>>>> I'm working on merging the latest cupcake code drop into master. The
> >>> >>>>> task is quite hairy, so the following two guidelines probably apply:
> >>> >>>>> -please don't submit anything in gerrit, as you'll just get in my way.
> >>> >>>>> -now is a good time to repo sync master, as I'm going to have to
> >>> >>>>> submit the result of the merge in a state where it doesn't build, and
> >>> >>>>> I have no idea how long it'll take to get it to build again after
> >>> >>>>> that.
> >>> >>>>> Questions sent directly to me that have no reason for being private
> >>> >>>>> will likely get ignored or forwarded to a public forum with no further
> >>> >>>>> warning.
> >>> >>>> Questions sent directly to me that have no reason for being private
> >>> >>>> will likely get ignored or forwarded to a public forum with no further
> >>> >>>> warning.
> >>> >>> Questions sent directly to me that have no reason for being private
> >>> >>> will likely get ignored or forwarded to a public forum with no further
> >>> >>> warning.
> >>> >> Questions sent directly to me that have no reason for being private
> >>> >> will likely get ignored or forwarded to a public forum with no further
> >>> >> warning.
> >>> > Questions sent directly to me that have no reason for being private
> >>> > will likely get ignored or forwarded to a public forum with no further
> >>> > warning.
> >>> Questions sent directly to me that have no reason for being private
> >>> will likely get ignored or forwarded to a public forum with no further
> >>> warning.
> > Questions sent directly to me that have no reason for being private
> > will likely get ignored or forwarded to a public forum with no further
> > warning.
> Questions sent directly to me that have no reason for being private
> will likely get ignored or forwarded to a public forum with no further
> warning.
On Sat, Mar 21, 2009 at 10:35 PM, Jean-Baptiste Queru <j...@android.com> wrote: > [still bcc android-platform, android-framework, android-porting]
> Latest status:
> -we're back to one patch: 9356.
> -build with "BUILD_WITHOUT_PV=true make"
> -quickly tested both on emulator and dream, and seems to work well > enough to not have the phone app crash in a loop.
> -I expect to submit 9356 on Monday morning PDT.
> JBQ
> On Sat, Mar 21, 2009 at 11:50 AM, Jean-Baptiste Queru <j...@android.com> wrote: >> I've been working on a "better" batch of patches (now it feels more >> like open-heart surgery with a meat cleaver):
>> -no need to delete the opencore directory or to remove it from the manifest.
>> -you need to repo download changes 9355, 9356 and 9357. No need to >> take 9300. I know it's 3 changes instead of 1, because I had to touch >> a few more parts of the system, but those are much cleaner.
>> -only tested on the emulator, so those might very well cause >> regressions on dream.
>> JBQ
>> On Thu, Mar 19, 2009 at 1:07 PM, Jean-Baptiste Queru <j...@android.com> wrote: >>> I've put together a hack that allows the system to compile and start >>> all the way to the home app. I worked with the delicateness of >>> open-heart surgery performed with a chainsaw.
>>> Steps:
>>> -remove the opencore files ( rm -rf external/opencore >>> .repo/projects/external/opencore.git ). Remove opencore from your >>> .repo/manifest.xml if you intend to repo sync the entire world but >>> don't want to have to remove opencore every single time.
>>> -most probably do a clean build ( rm -rf out/ ; make )
>>> I've "tested" on a device/release/generic/userdebug build. On my >>> machine, it compiles, launches. The media process dies (which probably >>> means that downloads are busted too), as well as the music player. The >>> browser starts and can access the network.
>>> JBQ
>>> On Wed, Mar 18, 2009 at 7:57 PM, Jean-Baptiste Queru <j...@android.com> wrote: >>>> I've submitted the merge (106 projects!), and I believe that the tree >>>> is in the state that it should be.
>>>> Caveats:
>>>> -THE BUILD IS BROKEN. You've been warned. There's been some drift >>>> around OpenCORE (probably situations where new code was written in >>>> cupcake that uses OpenCORE 1, or where APIs were removed in cupcake >>>> that OpenCORE 2 relies on).
>>>> The proper command to try to merge the OpenCORE code should be "git >>>> merge remotes/korg/cupcake" (I'm typing from memory).
>>>> -I'm not 100% sure that the server contains exactly what it should. >>>> I've had a filesystem failure right as I was trying to verify it, and >>>> I'm not gonna be able to verify until at least sometime tomorrow.
>>>> JBQ
>>>> On Wed, Mar 18, 2009 at 12:43 PM, Jean-Baptiste Queru <j...@android.com> wrote: >>>>> I expect to start submitting the changes in about an hour, i.e. >>>>> between 1:30pm and 2pm PDT.
>>>>> Starting right now, you may want to avoid initiating a new repo sync, >>>>> unless you're OK ending up with a tree that might not even compile.
>>>>> JBQ
>>>>> On Tue, Mar 17, 2009 at 6:35 PM, Jean-Baptiste Queru <j...@android.com> wrote: >>>>>> [bcc android-platform, android-framework, android-porting]
>>>>>> I'm working on merging the latest cupcake code drop into master. The >>>>>> task is quite hairy, so the following two guidelines probably apply:
>>>>>> -please don't submit anything in gerrit, as you'll just get in my way. >>>>>> -now is a good time to repo sync master, as I'm going to have to >>>>>> submit the result of the merge in a state where it doesn't build, and >>>>>> I have no idea how long it'll take to get it to build again after >>>>>> that.
>>>>>> Questions sent directly to me that have no reason for being private >>>>>> will likely get ignored or forwarded to a public forum with no further >>>>>> warning.
>>>>> Questions sent directly to me that have no reason for being private >>>>> will likely get ignored or forwarded to a public forum with no further >>>>> warning.
>>>> Questions sent directly to me that have no reason for being private >>>> will likely get ignored or forwarded to a public forum with no further >>>> warning.
>>> Questions sent directly to me that have no reason for being private >>> will likely get ignored or forwarded to a public forum with no further >>> warning.
>> Questions sent directly to me that have no reason for being private >> will likely get ignored or forwarded to a public forum with no further >> warning.
> Questions sent directly to me that have no reason for being private > will likely get ignored or forwarded to a public forum with no further > warning.
-- Jean-Baptiste M. "JBQ" Queru Android Engineer, Google.
Questions sent directly to me that have no reason for being private will likely get ignored or forwarded to a public forum with no further warning.
Thanks JBQ & Scott, am trying it out but what could be expected 'not
to work' on this branch? Would like to see if the expected to work
components are fine enough.
And could you give a rough idea of the differences between this branch
and a typical release. There are some apparent ones. Some aren't. Like
somebody had a good point about not so smooth scrolling on this
branch. Anyway it would be very useful to see even the obvious list of
differences from somebody in the Android team.
Thanks,
Rajesh.S
On Mar 24, 1:37 am, Jean-Baptiste Queru <j...@android.com> wrote:
> We're now one step closer. Change 9356 was submitted, so that the
> source tree "as is" can be compiled.
> You still need to set BUILD_WITHOUT_PV=true.
> JBQ
> On Sat, Mar 21, 2009 at 10:35 PM, Jean-Baptiste Queru <j...@android.com> wrote:
> > [still bcc android-platform, android-framework, android-porting]
> > Latest status:
> > -we're back to one patch: 9356.
> > -build with "BUILD_WITHOUT_PV=true make"
> > -quickly tested both on emulator and dream, and seems to work well
> > enough to not have the phone app crash in a loop.
> > -I expect to submit 9356 on Monday morning PDT.
> > JBQ
> > On Sat, Mar 21, 2009 at 11:50 AM, Jean-Baptiste Queru <j...@android.com> wrote:
> >> I've been working on a "better" batch of patches (now it feels more
> >> like open-heart surgery with a meat cleaver):
> >> -no need to delete the opencore directory or to remove it from the manifest.
> >> -you need to repo download changes 9355, 9356 and 9357. No need to
> >> take 9300. I know it's 3 changes instead of 1, because I had to touch
> >> a few more parts of the system, but those are much cleaner.
> >> -only tested on the emulator, so those might very well cause
> >> regressions on dream.
> >> JBQ
> >> On Thu, Mar 19, 2009 at 1:07 PM, Jean-Baptiste Queru <j...@android.com> wrote:
> >>> I've put together a hack that allows the system to compile and start
> >>> all the way to the home app. I worked with the delicateness of
> >>> open-heart surgery performed with a chainsaw.
> >>> Steps:
> >>> -remove the opencore files ( rm -rf external/opencore
> >>> .repo/projects/external/opencore.git ). Remove opencore from your
> >>> .repo/manifest.xml if you intend to repo sync the entire world but
> >>> don't want to have to remove opencore every single time.
> >>> -most probably do a clean build ( rm -rf out/ ; make )
> >>> I've "tested" on a device/release/generic/userdebug build. On my
> >>> machine, it compiles, launches. The media process dies (which probably
> >>> means that downloads are busted too), as well as the music player. The
> >>> browser starts and can access the network.
> >>> JBQ
> >>> On Wed, Mar 18, 2009 at 7:57 PM, Jean-Baptiste Queru <j...@android.com> wrote:
> >>>> I've submitted the merge (106 projects!), and I believe that the tree
> >>>> is in the state that it should be.
> >>>> Caveats:
> >>>> -THE BUILD IS BROKEN. You've been warned. There's been some drift
> >>>> around OpenCORE (probably situations where new code was written in
> >>>>cupcakethat uses OpenCORE 1, or where APIs were removed incupcake
> >>>> that OpenCORE 2 relies on).
> >>>> The proper command to try to merge the OpenCORE code should be "git
> >>>> merge remotes/korg/cupcake" (I'm typing from memory).
> >>>> -I'm not 100% sure that the server contains exactly what it should.
> >>>> I've had a filesystem failure right as I was trying to verify it, and
> >>>> I'm not gonna be able to verify until at least sometime tomorrow.
> >>>> JBQ
> >>>> On Wed, Mar 18, 2009 at 12:43 PM, Jean-Baptiste Queru <j...@android.com> wrote:
> >>>>> I expect to start submitting the changes in about an hour, i.e.
> >>>>> between 1:30pm and 2pm PDT.
> >>>>> Starting right now, you may want to avoid initiating a new repo sync,
> >>>>> unless you're OK ending up with a tree that might not even compile.
> >>>>> JBQ
> >>>>> On Tue, Mar 17, 2009 at 6:35 PM, Jean-Baptiste Queru <j...@android.com> wrote:
> >>>>>> [bcc android-platform, android-framework, android-porting]
> >>>>>> I'm working on merging the latestcupcakecode drop into master. The
> >>>>>> task is quite hairy, so the following two guidelines probably apply:
> >>>>>> -please don't submit anything in gerrit, as you'll just get in my way.
> >>>>>> -now is a good time to repo sync master, as I'm going to have to
> >>>>>> submit the result of the merge in a state where it doesn't build, and
> >>>>>> I have no idea how long it'll take to get it to build again after
> >>>>>> that.
> >>>>>> Questions sent directly to me that have no reason for being private
> >>>>>> will likely get ignored or forwarded to a public forum with no further
> >>>>>> warning.
> >>>>> Questions sent directly to me that have no reason for being private
> >>>>> will likely get ignored or forwarded to a public forum with no further
> >>>>> warning.
> >>>> Questions sent directly to me that have no reason for being private
> >>>> will likely get ignored or forwarded to a public forum with no further
> >>>> warning.
> >>> Questions sent directly to me that have no reason for being private
> >>> will likely get ignored or forwarded to a public forum with no further
> >>> warning.
> >> Questions sent directly to me that have no reason for being private
> >> will likely get ignored or forwarded to a public forum with no further
> >> warning.
> > Questions sent directly to me that have no reason for being private
> > will likely get ignored or forwarded to a public forum with no further
> > warning.
> Questions sent directly to me that have no reason for being private
> will likely get ignored or forwarded to a public forum with no further
> warning.
>Thanks JBQ & Scott, am trying it out but what could be expected 'not
>to work' on this branch? Would like to see if the expected to work
>components are fine enough.
>And could you give a rough idea of the differences between this branch
>and a typical release. There are some apparent ones. Some aren't. Like
>somebody had a good point about not so smooth scrolling on this
>branch. Anyway it would be very useful to see even the obvious list of
>differences from somebody in the Android team.
>> We're now one step closer. Change 9356 was submitted, so that the
>> source tree "as is" can be compiled.
>> You still need to set BUILD_WITHOUT_PV=true.
>> JBQ
>> On Sat, Mar 21, 2009 at 10:35 PM, Jean-Baptiste Queru <j...@android.com> wrote:
>> > [still bcc android-platform, android-framework, android-porting]
>> > Latest status:
>> > -we're back to one patch: 9356.
>> > -build with "BUILD_WITHOUT_PV=true make"
>> > -quickly tested both on emulator and dream, and seems to work well
>> > enough to not have the phone app crash in a loop.
>> > -I expect to submit 9356 on Monday morning PDT.
>> > JBQ
>> > On Sat, Mar 21, 2009 at 11:50 AM, Jean-Baptiste Queru <j...@android.com> wrote:
>> >> I've been working on a "better" batch of patches (now it feels more
>> >> like open-heart surgery with a meat cleaver):
>> >> -no need to delete the opencore directory or to remove it from the manifest.
>> >> -you need to repo download changes 9355, 9356 and 9357. No need to
>> >> take 9300. I know it's 3 changes instead of 1, because I had to touch
>> >> a few more parts of the system, but those are much cleaner.
>> >> -only tested on the emulator, so those might very well cause
>> >> regressions on dream.
>> >> JBQ
>> >> On Thu, Mar 19, 2009 at 1:07 PM, Jean-Baptiste Queru <j...@android.com> wrote:
>> >>> I've put together a hack that allows the system to compile and start
>> >>> all the way to the home app. I worked with the delicateness of
>> >>> open-heart surgery performed with a chainsaw.
>> >>> Steps:
>> >>> -remove the opencore files ( rm -rf external/opencore
>> >>> .repo/projects/external/opencore.git ). Remove opencore from your
>> >>> .repo/manifest.xml if you intend to repo sync the entire world but
>> >>> don't want to have to remove opencore every single time.
>> >>> -most probably do a clean build ( rm -rf out/ ; make )
>> >>> I've "tested" on a device/release/generic/userdebug build. On my
>> >>> machine, it compiles, launches. The media process dies (which probably
>> >>> means that downloads are busted too), as well as the music player. The
>> >>> browser starts and can access the network.
>> >>> JBQ
>> >>> On Wed, Mar 18, 2009 at 7:57 PM, Jean-Baptiste Queru <j...@android.com> wrote:
>> >>>> I've submitted the merge (106 projects!), and I believe that the tree
>> >>>> is in the state that it should be.
>> >>>> Caveats:
>> >>>> -THE BUILD IS BROKEN. You've been warned. There's been some drift
>> >>>> around OpenCORE (probably situations where new code was written in
>> >>>>cupcakethat uses OpenCORE 1, or where APIs were removed incupcake
>> >>>> that OpenCORE 2 relies on).
>> >>>> The proper command to try to merge the OpenCORE code should be "git
>> >>>> merge remotes/korg/cupcake" (I'm typing from memory).
>> >>>> -I'm not 100% sure that the server contains exactly what it should.
>> >>>> I've had a filesystem failure right as I was trying to verify it, and
>> >>>> I'm not gonna be able to verify until at least sometime tomorrow.
>> >>>> JBQ
>> >>>> On Wed, Mar 18, 2009 at 12:43 PM, Jean-Baptiste Queru <j...@android.com> wrote:
>> >>>>> I expect to start submitting the changes in about an hour, i.e.
>> >>>>> between 1:30pm and 2pm PDT.
>> >>>>> Starting right now, you may want to avoid initiating a new repo sync,
>> >>>>> unless you're OK ending up with a tree that might not even compile.
>> >>>>> JBQ
>> >>>>> On Tue, Mar 17, 2009 at 6:35 PM, Jean-Baptiste Queru <j...@android.com> wrote:
>> >>>>>> [bcc android-platform, android-framework, android-porting]
>> >>>>>> I'm working on merging the latestcupcakecode drop into master. The
>> >>>>>> task is quite hairy, so the following two guidelines probably apply:
>> >>>>>> -please don't submit anything in gerrit, as you'll just get in my way.
>> >>>>>> -now is a good time to repo sync master, as I'm going to have to
>> >>>>>> submit the result of the merge in a state where it doesn't build, and
>> >>>>>> I have no idea how long it'll take to get it to build again after
>> >>>>>> that.
>> >>>>>> Questions sent directly to me that have no reason for being private
>> >>>>>> will likely get ignored or forwarded to a public forum with no further
>> >>>>>> warning.
>> >>>>> Questions sent directly to me that have no reason for being private
>> >>>>> will likely get ignored or forwarded to a public forum with no further
>> >>>>> warning.
>> >>>> Questions sent directly to me that have no reason for being private
>> >>>> will likely get ignored or forwarded to a public forum with no further
>> >>>> warning.
>> >>> Questions sent directly to me that have no reason for being private
>> >>> will likely get ignored or forwarded to a public forum with no further
>> >>> warning.
>> >> Questions sent directly to me that have no reason for being private
>> >> will likely get ignored or forwarded to a public forum with no further
>> >> warning.
>> > Questions sent directly to me that have no reason for being private
>> > will likely get ignored or forwarded to a public forum with no further
>> > warning.
>> Questions sent directly to me that have no reason for being private
>> will likely get ignored or forwarded to a public forum with no further
>> warning.
The master branch is definitely not a release. It's the mainline, the trunk, the unstable. As such, almost by definition, it has issues (and, in this case, very major issues).
At this point, nobody on the Android team has any visibility over its exact state beyond what can be seen in a few minutes (media is busted, orientation doesn't switch properly, several apps crash at launch, the runtime crashes frequently...).
Cupcake is probably a lot more stable, though even in that case we have little visibility over the exact state of the open-source tree.
On Tue, Mar 24, 2009 at 1:57 AM, Rajesh S <rajeshs...@gmail.com> wrote:
> Thanks JBQ & Scott, am trying it out but what could be expected 'not > to work' on this branch? Would like to see if the expected to work > components are fine enough.
> And could you give a rough idea of the differences between this branch > and a typical release. There are some apparent ones. Some aren't. Like > somebody had a good point about not so smooth scrolling on this > branch. Anyway it would be very useful to see even the obvious list of > differences from somebody in the Android team.
> Thanks, > Rajesh.S
> On Mar 24, 1:37 am, Jean-Baptiste Queru <j...@android.com> wrote: >> [still bcc android-platform, android-framework, android-porting]
>> We're now one step closer. Change 9356 was submitted, so that the >> source tree "as is" can be compiled.
>> You still need to set BUILD_WITHOUT_PV=true.
>> JBQ
>> On Sat, Mar 21, 2009 at 10:35 PM, Jean-Baptiste Queru <j...@android.com> wrote: >> > [still bcc android-platform, android-framework, android-porting]
>> > Latest status:
>> > -we're back to one patch: 9356.
>> > -build with "BUILD_WITHOUT_PV=true make"
>> > -quickly tested both on emulator and dream, and seems to work well >> > enough to not have the phone app crash in a loop.
>> > -I expect to submit 9356 on Monday morning PDT.
>> > JBQ
>> > On Sat, Mar 21, 2009 at 11:50 AM, Jean-Baptiste Queru <j...@android.com> wrote: >> >> I've been working on a "better" batch of patches (now it feels more >> >> like open-heart surgery with a meat cleaver):
>> >> -no need to delete the opencore directory or to remove it from the manifest.
>> >> -you need to repo download changes 9355, 9356 and 9357. No need to >> >> take 9300. I know it's 3 changes instead of 1, because I had to touch >> >> a few more parts of the system, but those are much cleaner.
>> >> -only tested on the emulator, so those might very well cause >> >> regressions on dream.
>> >> JBQ
>> >> On Thu, Mar 19, 2009 at 1:07 PM, Jean-Baptiste Queru <j...@android.com> wrote: >> >>> I've put together a hack that allows the system to compile and start >> >>> all the way to the home app. I worked with the delicateness of >> >>> open-heart surgery performed with a chainsaw.
>> >>> Steps:
>> >>> -remove the opencore files ( rm -rf external/opencore >> >>> .repo/projects/external/opencore.git ). Remove opencore from your >> >>> .repo/manifest.xml if you intend to repo sync the entire world but >> >>> don't want to have to remove opencore every single time.
>> >>> -most probably do a clean build ( rm -rf out/ ; make )
>> >>> I've "tested" on a device/release/generic/userdebug build. On my >> >>> machine, it compiles, launches. The media process dies (which probably >> >>> means that downloads are busted too), as well as the music player. The >> >>> browser starts and can access the network.
>> >>> JBQ
>> >>> On Wed, Mar 18, 2009 at 7:57 PM, Jean-Baptiste Queru <j...@android.com> wrote: >> >>>> I've submitted the merge (106 projects!), and I believe that the tree >> >>>> is in the state that it should be.
>> >>>> Caveats:
>> >>>> -THE BUILD IS BROKEN. You've been warned. There's been some drift >> >>>> around OpenCORE (probably situations where new code was written in >> >>>>cupcakethat uses OpenCORE 1, or where APIs were removed incupcake >> >>>> that OpenCORE 2 relies on).
>> >>>> The proper command to try to merge the OpenCORE code should be "git >> >>>> merge remotes/korg/cupcake" (I'm typing from memory).
>> >>>> -I'm not 100% sure that the server contains exactly what it should. >> >>>> I've had a filesystem failure right as I was trying to verify it, and >> >>>> I'm not gonna be able to verify until at least sometime tomorrow.
>> >>>> JBQ
>> >>>> On Wed, Mar 18, 2009 at 12:43 PM, Jean-Baptiste Queru <j...@android.com> wrote: >> >>>>> I expect to start submitting the changes in about an hour, i.e. >> >>>>> between 1:30pm and 2pm PDT.
>> >>>>> Starting right now, you may want to avoid initiating a new repo sync, >> >>>>> unless you're OK ending up with a tree that might not even compile.
>> >>>>> JBQ
>> >>>>> On Tue, Mar 17, 2009 at 6:35 PM, Jean-Baptiste Queru <j...@android.com> wrote: >> >>>>>> [bcc android-platform, android-framework, android-porting]
>> >>>>>> I'm working on merging the latestcupcakecode drop into master. The >> >>>>>> task is quite hairy, so the following two guidelines probably apply:
>> >>>>>> -please don't submit anything in gerrit, as you'll just get in my way. >> >>>>>> -now is a good time to repo sync master, as I'm going to have to >> >>>>>> submit the result of the merge in a state where it doesn't build, and >> >>>>>> I have no idea how long it'll take to get it to build again after >> >>>>>> that.
>> >>>>>> Questions sent directly to me that have no reason for being private >> >>>>>> will likely get ignored or forwarded to a public forum with no further >> >>>>>> warning.
>> >>>>> Questions sent directly to me that have no reason for being private >> >>>>> will likely get ignored or forwarded to a public forum with no further >> >>>>> warning.
>> >>>> Questions sent directly to me that have no reason for being private >> >>>> will likely get ignored or forwarded to a public forum with no further >> >>>> warning.
>> >>> Questions sent directly to me that have no reason for being private >> >>> will likely get ignored or forwarded to a public forum with no further >> >>> warning.
>> >> Questions sent directly to me that have no reason for being private >> >> will likely get ignored or forwarded to a public forum with no further >> >> warning.
>> > Questions sent directly to me that have no reason for being private >> > will likely get ignored or forwarded to a public forum with no further >> > warning.
>> Questions sent directly to me that have no reason for being private >> will likely get ignored or forwarded to a public forum with no further >> warning.
-- Jean-Baptiste M. "JBQ" Queru Android Engineer, Google.
Questions sent directly to me that have no reason for being private will likely get ignored or forwarded to a public forum with no further warning.
But am I right that the cupcake branch cannot be deployed on a real
device?
Yesterday I build the master branch and flashed my ADP1 with it but it
does not boot. One time it booted but then i got errors of the
com.android.phone process. I am interested in the on screen keyboard
and was also looking at the widget framework for the home screen.
On Mar 24, 3:37 pm, Jean-Baptiste Queru <j...@android.com> wrote:
> The master branch is definitely not a release. It's the mainline, the
> trunk, the unstable. As such, almost by definition, it has issues
> (and, in this case, very major issues).
> At this point, nobody on the Android team has any visibility over its
> exact state beyond what can be seen in a few minutes (media is busted,
> orientation doesn't switch properly, several apps crash at launch, the
> runtime crashes frequently...).
> Cupcake is probably a lot more stable, though even in that case we
> have little visibility over the exact state of the open-source tree.
> JBQ
> On Tue, Mar 24, 2009 at 1:57 AM, Rajesh S <rajeshs...@gmail.com> wrote:
> > Thanks JBQ & Scott, am trying it out but what could be expected 'not
> > to work' on this branch? Would like to see if the expected to work
> > components are fine enough.
> > And could you give a rough idea of the differences between this branch
> > and a typical release. There are some apparent ones. Some aren't. Like
> > somebody had a good point about not so smooth scrolling on this
> > branch. Anyway it would be very useful to see even the obvious list of
> > differences from somebody in the Android team.
> > Thanks,
> > Rajesh.S
> > On Mar 24, 1:37 am, Jean-Baptiste Queru <j...@android.com> wrote:
> >> [still bcc android-platform, android-framework, android-porting]
> >> We're now one step closer. Change 9356 was submitted, so that the
> >> source tree "as is" can be compiled.
> >> You still need to set BUILD_WITHOUT_PV=true.
> >> JBQ
> >> On Sat, Mar 21, 2009 at 10:35 PM, Jean-Baptiste Queru <j...@android.com> wrote:
> >> > [still bcc android-platform, android-framework, android-porting]
> >> > Latest status:
> >> > -we're back to one patch: 9356.
> >> > -build with "BUILD_WITHOUT_PV=true make"
> >> > -quickly tested both on emulator and dream, and seems to work well
> >> > enough to not have the phone app crash in a loop.
> >> > -I expect to submit 9356 on Monday morning PDT.
> >> > JBQ
> >> > On Sat, Mar 21, 2009 at 11:50 AM, Jean-Baptiste Queru <j...@android.com> wrote:
> >> >> I've been working on a "better" batch of patches (now it feels more
> >> >> like open-heart surgery with a meat cleaver):
> >> >> -no need to delete the opencore directory or to remove it from the manifest.
> >> >> -you need to repo download changes 9355, 9356 and 9357. No need to
> >> >> take 9300. I know it's 3 changes instead of 1, because I had to touch
> >> >> a few more parts of the system, but those are much cleaner.
> >> >> -only tested on the emulator, so those might very well cause
> >> >> regressions on dream.
> >> >> JBQ
> >> >> On Thu, Mar 19, 2009 at 1:07 PM, Jean-Baptiste Queru <j...@android.com> wrote:
> >> >>> I've put together a hack that allows the system to compile and start
> >> >>> all the way to the home app. I worked with the delicateness of
> >> >>> open-heart surgery performed with a chainsaw.
> >> >>> Steps:
> >> >>> -remove the opencore files ( rm -rf external/opencore
> >> >>> .repo/projects/external/opencore.git ). Remove opencore from your
> >> >>> .repo/manifest.xml if you intend to repo sync the entire world but
> >> >>> don't want to have to remove opencore every single time.
> >> >>> -most probably do a clean build ( rm -rf out/ ; make )
> >> >>> I've "tested" on a device/release/generic/userdebug build. On my
> >> >>> machine, it compiles, launches. The media process dies (which probably
> >> >>> means that downloads are busted too), as well as the music player. The
> >> >>> browser starts and can access the network.
> >> >>> JBQ
> >> >>> On Wed, Mar 18, 2009 at 7:57 PM, Jean-Baptiste Queru <j...@android.com> wrote:
> >> >>>> I've submitted the merge (106 projects!), and I believe that the tree
> >> >>>> is in the state that it should be.
> >> >>>> Caveats:
> >> >>>> -THE BUILD IS BROKEN. You've been warned. There's been some drift
> >> >>>> around OpenCORE (probably situations where new code was written in
> >> >>>>cupcakethat uses OpenCORE 1, or where APIs were removed incupcake
> >> >>>> that OpenCORE 2 relies on).
> >> >>>> The proper command to try to merge the OpenCORE code should be "git
> >> >>>> merge remotes/korg/cupcake" (I'm typing from memory).
> >> >>>> -I'm not 100% sure that the server contains exactly what it should.
> >> >>>> I've had a filesystem failure right as I was trying to verify it, and
> >> >>>> I'm not gonna be able to verify until at least sometime tomorrow.
> >> >>>> JBQ
> >> >>>> On Wed, Mar 18, 2009 at 12:43 PM, Jean-Baptiste Queru <j...@android.com> wrote:
> >> >>>>> I expect to start submitting the changes in about an hour, i.e.
> >> >>>>> between 1:30pm and 2pm PDT.
> >> >>>>> Starting right now, you may want to avoid initiating a new repo sync,
> >> >>>>> unless you're OK ending up with a tree that might not even compile.
> >> >>>>> JBQ
> >> >>>>> On Tue, Mar 17, 2009 at 6:35 PM, Jean-Baptiste Queru <j...@android.com> wrote:
> >> >>>>>> [bcc android-platform, android-framework, android-porting]
> >> >>>>>> I'm working on merging the latestcupcakecode drop into master. The
> >> >>>>>> task is quite hairy, so the following two guidelines probably apply:
> >> >>>>>> -please don't submit anything in gerrit, as you'll just get in my way.
> >> >>>>>> -now is a good time to repo sync master, as I'm going to have to
> >> >>>>>> submit the result of the merge in a state where it doesn't build, and
> >> >>>>>> I have no idea how long it'll take to get it to build again after
> >> >>>>>> that.
> >> >>>>>> Questions sent directly to me that have no reason for being private
> >> >>>>>> will likely get ignored or forwarded to a public forum with no further
> >> >>>>>> warning.
> >> >>>>> Questions sent directly to me that have no reason for being private
> >> >>>>> will likely get ignored or forwarded to a public forum with no further
> >> >>>>> warning.
> >> >>>> Questions sent directly to me that have no reason for being private
> >> >>>> will likely get ignored or forwarded to a public forum with no further
> >> >>>> warning.
> >> >>> Questions sent directly to me that have no reason for being private
> >> >>> will likely get ignored or forwarded to a public forum with no further
> >> >>> warning.
> >> >> Questions sent directly to me that have no reason for being private
> >> >> will likely get ignored or forwarded to a public forum with no further
> >> >> warning.
> >> > Questions sent directly to me that have no reason for being private
> >> > will likely get ignored or forwarded to a public forum with no further
> >> > warning.
> >> Questions sent directly to me that have no reason for being private
> >> will likely get ignored or forwarded to a public forum with no further
> >> warning.
> Questions sent directly to me that have no reason for being private
> will likely get ignored or forwarded to a public forum with no further
> warning.
Cupcake can be deployed on devices (as a general statement) though it's not production-quality yet. However, at the moment, the matching proprietary files necessary to make it run "as is" on dream aren't available (and we believe that the versions of those files that can be extracted from a 1.1 phone are unlikely to be compatible - I haven't had time to try that myself, though).
JBQ
On Tue, Mar 24, 2009 at 7:45 AM, Johan de Koning <ikbennu...@gmail.com> wrote:
> But am I right that the cupcake branch cannot be deployed on a real > device?
> Yesterday I build the master branch and flashed my ADP1 with it but it > does not boot. One time it booted but then i got errors of the > com.android.phone process. I am interested in the on screen keyboard > and was also looking at the widget framework for the home screen.
> On Mar 24, 3:37 pm, Jean-Baptiste Queru <j...@android.com> wrote: >> The master branch is definitely not a release. It's the mainline, the >> trunk, the unstable. As such, almost by definition, it has issues >> (and, in this case, very major issues).
>> At this point, nobody on the Android team has any visibility over its >> exact state beyond what can be seen in a few minutes (media is busted, >> orientation doesn't switch properly, several apps crash at launch, the >> runtime crashes frequently...).
>> Cupcake is probably a lot more stable, though even in that case we >> have little visibility over the exact state of the open-source tree.
>> JBQ
>> On Tue, Mar 24, 2009 at 1:57 AM, Rajesh S <rajeshs...@gmail.com> wrote:
>> > Thanks JBQ & Scott, am trying it out but what could be expected 'not >> > to work' on this branch? Would like to see if the expected to work >> > components are fine enough.
>> > And could you give a rough idea of the differences between this branch >> > and a typical release. There are some apparent ones. Some aren't. Like >> > somebody had a good point about not so smooth scrolling on this >> > branch. Anyway it would be very useful to see even the obvious list of >> > differences from somebody in the Android team.
>> > Thanks, >> > Rajesh.S
>> > On Mar 24, 1:37 am, Jean-Baptiste Queru <j...@android.com> wrote: >> >> [still bcc android-platform, android-framework, android-porting]
>> >> We're now one step closer. Change 9356 was submitted, so that the >> >> source tree "as is" can be compiled.
>> >> You still need to set BUILD_WITHOUT_PV=true.
>> >> JBQ
>> >> On Sat, Mar 21, 2009 at 10:35 PM, Jean-Baptiste Queru <j...@android.com> wrote: >> >> > [still bcc android-platform, android-framework, android-porting]
>> >> > Latest status:
>> >> > -we're back to one patch: 9356.
>> >> > -build with "BUILD_WITHOUT_PV=true make"
>> >> > -quickly tested both on emulator and dream, and seems to work well >> >> > enough to not have the phone app crash in a loop.
>> >> > -I expect to submit 9356 on Monday morning PDT.
>> >> > JBQ
>> >> > On Sat, Mar 21, 2009 at 11:50 AM, Jean-Baptiste Queru <j...@android.com> wrote: >> >> >> I've been working on a "better" batch of patches (now it feels more >> >> >> like open-heart surgery with a meat cleaver):
>> >> >> -no need to delete the opencore directory or to remove it from the manifest.
>> >> >> -you need to repo download changes 9355, 9356 and 9357. No need to >> >> >> take 9300. I know it's 3 changes instead of 1, because I had to touch >> >> >> a few more parts of the system, but those are much cleaner.
>> >> >> -only tested on the emulator, so those might very well cause >> >> >> regressions on dream.
>> >> >> JBQ
>> >> >> On Thu, Mar 19, 2009 at 1:07 PM, Jean-Baptiste Queru <j...@android.com> wrote: >> >> >>> I've put together a hack that allows the system to compile and start >> >> >>> all the way to the home app. I worked with the delicateness of >> >> >>> open-heart surgery performed with a chainsaw.
>> >> >>> Steps:
>> >> >>> -remove the opencore files ( rm -rf external/opencore >> >> >>> .repo/projects/external/opencore.git ). Remove opencore from your >> >> >>> .repo/manifest.xml if you intend to repo sync the entire world but >> >> >>> don't want to have to remove opencore every single time.
>> >> >>> -most probably do a clean build ( rm -rf out/ ; make )
>> >> >>> I've "tested" on a device/release/generic/userdebug build. On my >> >> >>> machine, it compiles, launches. The media process dies (which probably >> >> >>> means that downloads are busted too), as well as the music player. The >> >> >>> browser starts and can access the network.
>> >> >>> JBQ
>> >> >>> On Wed, Mar 18, 2009 at 7:57 PM, Jean-Baptiste Queru <j...@android.com> wrote: >> >> >>>> I've submitted the merge (106 projects!), and I believe that the tree >> >> >>>> is in the state that it should be.
>> >> >>>> Caveats:
>> >> >>>> -THE BUILD IS BROKEN. You've been warned. There's been some drift >> >> >>>> around OpenCORE (probably situations where new code was written in >> >> >>>>cupcakethat uses OpenCORE 1, or where APIs were removed incupcake >> >> >>>> that OpenCORE 2 relies on).
>> >> >>>> The proper command to try to merge the OpenCORE code should be "git >> >> >>>> merge remotes/korg/cupcake" (I'm typing from memory).
>> >> >>>> -I'm not 100% sure that the server contains exactly what it should. >> >> >>>> I've had a filesystem failure right as I was trying to verify it, and >> >> >>>> I'm not gonna be able to verify until at least sometime tomorrow.
>> >> >>>> JBQ
>> >> >>>> On Wed, Mar 18, 2009 at 12:43 PM, Jean-Baptiste Queru <j...@android.com> wrote: >> >> >>>>> I expect to start submitting the changes in about an hour, i.e. >> >> >>>>> between 1:30pm and 2pm PDT.
>> >> >>>>> Starting right now, you may want to avoid initiating a new repo sync, >> >> >>>>> unless you're OK ending up with a tree that might not even compile.
>> >> >>>>> JBQ
>> >> >>>>> On Tue, Mar 17, 2009 at 6:35 PM, Jean-Baptiste Queru <j...@android.com> wrote: >> >> >>>>>> [bcc android-platform, android-framework, android-porting]
>> >> >>>>>> I'm working on merging the latestcupcakecode drop into master. The >> >> >>>>>> task is quite hairy, so the following two guidelines probably apply:
>> >> >>>>>> -please don't submit anything in gerrit, as you'll just get in my way. >> >> >>>>>> -now is a good time to repo sync master, as I'm going to have to >> >> >>>>>> submit the result of the merge in a state where it doesn't build, and >> >> >>>>>> I have no idea how long it'll take to get it to build again after >> >> >>>>>> that.
>> >> >>>>>> Questions sent directly to me that have no reason for being private >> >> >>>>>> will likely get ignored or forwarded to a public forum with no further >> >> >>>>>> warning.
>> >> >>>>> Questions sent directly to me that have no reason for being private >> >> >>>>> will likely get ignored or forwarded to a public forum with no further >> >> >>>>> warning.
>> >> >>>> Questions sent directly to me that have no reason for being private >> >> >>>> will likely get ignored or forwarded to a public forum with no further >> >> >>>> warning.
>> >> >>> Questions sent directly to me that have no reason for being private >> >> >>> will likely get ignored or forwarded to a public forum with no further >> >> >>> warning.
>> >> >> Questions sent directly to me that have no reason for being private >> >> >> will likely get ignored or forwarded to a public forum with no further >> >> >> warning.
>> >> > Questions sent directly to me that have no reason for being private >> >> > will likely get ignored or forwarded to a public forum with no further >> >> > warning.
>> >> Questions sent directly to me that have no reason for being private >> >> will likely get ignored or forwarded to a public forum with no further >> >> warning.
>> Questions sent directly to me that have no reason for being private >> will likely get ignored or forwarded to a public forum with no further >> warning.
-- Jean-Baptiste M. "JBQ" Queru Android Engineer, Google.
Questions sent directly to me that have no reason for being private will likely get ignored or forwarded to a public forum with no further warning.
> But am I right that the cupcake branch cannot be deployed on a real
> device?
> Yesterday I build the master branch and flashed my ADP1 with it but it
> does not boot. One time it booted but then i got errors of the
> com.android.phone process. I am interested in the on screen keyboard
> and was also looking at the widget framework for the home screen.
> On Mar 24, 3:37 pm, Jean-Baptiste Queru <j...@android.com> wrote:
> > The master branch is definitely not a release. It's the mainline, the
> > trunk, the unstable. As such, almost by definition, it has issues
> > (and, in this case, very major issues).
> > At this point, nobody on the Android team has any visibility over its
> > exact state beyond what can be seen in a few minutes (media is busted,
> > orientation doesn't switch properly, several apps crash at launch, the
> > runtime crashes frequently...).
> > Cupcake is probably a lot more stable, though even in that case we
> > have little visibility over the exact state of the open-source tree.
> > JBQ
> > On Tue, Mar 24, 2009 at 1:57 AM, Rajesh S <rajeshs...@gmail.com> wrote:
> > > Thanks JBQ & Scott, am trying it out but what could be expected 'not
> > > to work' on this branch? Would like to see if the expected to work
> > > components are fine enough.
> > > And could you give a rough idea of the differences between this branch
> > > and a typical release. There are some apparent ones. Some aren't. Like
> > > somebody had a good point about not so smooth scrolling on this
> > > branch. Anyway it would be very useful to see even the obvious list of
> > > differences from somebody in the Android team.
> > > Thanks,
> > > Rajesh.S
> > > On Mar 24, 1:37 am, Jean-Baptiste Queru <j...@android.com> wrote:
> > >> [still bcc android-platform, android-framework, android-porting]
> > >> We're now one step closer. Change 9356 was submitted, so that the
> > >> source tree "as is" can be compiled.
> > >> You still need to set BUILD_WITHOUT_PV=true.
> > >> JBQ
> > >> On Sat, Mar 21, 2009 at 10:35 PM, Jean-Baptiste Queru <j...@android.com> wrote:
> > >> > [still bcc android-platform, android-framework, android-porting]
> > >> > Latest status:
> > >> > -we're back to one patch: 9356.
> > >> > -build with "BUILD_WITHOUT_PV=true make"
> > >> > -quickly tested both on emulator and dream, and seems to work well
> > >> > enough to not have the phone app crash in a loop.
> > >> > -I expect to submit 9356 on Monday morning PDT.
> > >> > JBQ
> > >> > On Sat, Mar 21, 2009 at 11:50 AM, Jean-Baptiste Queru <j...@android.com> wrote:
> > >> >> I've been working on a "better" batch of patches (now it feels more
> > >> >> like open-heart surgery with a meat cleaver):
> > >> >> -no need to delete the opencore directory or to remove it from the manifest.
> > >> >> -you need to repo download changes 9355, 9356 and 9357. No need to
> > >> >> take 9300. I know it's 3 changes instead of 1, because I had to touch
> > >> >> a few more parts of the system, but those are much cleaner.
> > >> >> -only tested on the emulator, so those might very well cause
> > >> >> regressions on dream.
> > >> >> JBQ
> > >> >> On Thu, Mar 19, 2009 at 1:07 PM, Jean-Baptiste Queru <j...@android.com> wrote:
> > >> >>> I've put together a hack that allows the system to compile and start
> > >> >>> all the way to the home app. I worked with the delicateness of
> > >> >>> open-heart surgery performed with a chainsaw.
> > >> >>> Steps:
> > >> >>> -remove the opencore files ( rm -rf external/opencore
> > >> >>> .repo/projects/external/opencore.git ). Remove opencore from your
> > >> >>> .repo/manifest.xml if you intend to repo sync the entire world but
> > >> >>> don't want to have to remove opencore every single time.
> > >> >>> -most probably do a clean build ( rm -rf out/ ; make )
> > >> >>> I've "tested" on a device/release/generic/userdebug build. On my
> > >> >>> machine, it compiles, launches. The media process dies (which probably
> > >> >>> means that downloads are busted too), as well as the music player. The
> > >> >>> browser starts and can access the network.
> > >> >>> JBQ
> > >> >>> On Wed, Mar 18, 2009 at 7:57 PM, Jean-Baptiste Queru <j...@android.com> wrote:
> > >> >>>> I've submitted the merge (106 projects!), and I believe that the tree
> > >> >>>> is in the state that it should be.
> > >> >>>> Caveats:
> > >> >>>> -THE BUILD IS BROKEN. You've been warned. There's been some drift
> > >> >>>> around OpenCORE (probably situations where new code was written in
> > >> >>>>cupcakethat uses OpenCORE 1, or where APIs were removed incupcake
> > >> >>>> that OpenCORE 2 relies on).
> > >> >>>> The proper command to try to merge the OpenCORE code should be "git
> > >> >>>> merge remotes/korg/cupcake" (I'm typing from memory).
> > >> >>>> -I'm not 100% sure that the server contains exactly what it should.
> > >> >>>> I've had a filesystem failure right as I was trying to verify it, and
> > >> >>>> I'm not gonna be able to verify until at least sometime tomorrow.
> > >> >>>> JBQ
> > >> >>>> On Wed, Mar 18, 2009 at 12:43 PM, Jean-Baptiste Queru <j...@android.com> wrote:
> > >> >>>>> I expect to start submitting the changes in about an hour, i.e.
> > >> >>>>> between 1:30pm and 2pm PDT.
> > >> >>>>> Starting right now, you may want to avoid initiating a new repo sync,
> > >> >>>>> unless you're OK ending up with a tree that might not even compile.
> > >> >>>>> JBQ
> > >> >>>>> On Tue, Mar 17, 2009 at 6:35 PM, Jean-Baptiste Queru <j...@android.com> wrote:
> > >> >>>>>> [bcc android-platform, android-framework, android-porting]
> > >> >>>>>> I'm working on merging the latestcupcakecode drop into master. The
> > >> >>>>>> task is quite hairy, so the following two guidelines probably apply:
> > >> >>>>>> -please don't submit anything in gerrit, as you'll just get in my way.
> > >> >>>>>> -now is a good time to repo sync master, as I'm going to have to
> > >> >>>>>> submit the result of the merge in a state where it doesn't build, and
> > >> >>>>>> I have no idea how long it'll take to get it to build again after
> > >> >>>>>> that.
> > >> >>>>>> Questions sent directly to me that have no reason for being private
> > >> >>>>>> will likely get ignored or forwarded to a public forum with no further
> > >> >>>>>> warning.
> > >> >>>>> Questions sent directly to me that have no reason for being private
> > >> >>>>> will likely get ignored or forwarded to a public forum with no further
> > >> >>>>> warning.
> > >> >>>> Questions sent directly to me that have no reason for being private
> > >> >>>> will likely get ignored or forwarded to a public forum with no further
> > >> >>>> warning.
> > >> >>> Questions sent directly to me that have no reason for being private
> > >> >>> will likely get ignored or forwarded to a public forum with no further
> > >> >>> warning.
> > >> >> Questions sent directly to me that have no reason for being private
> > >> >> will likely get ignored or forwarded to a public forum with no further
> > >> >> warning.
> > >> > Questions sent directly to me that have no reason for being private
> > >> > will likely get ignored or forwarded to a public forum with no further
> > >> > warning.
> > >> Questions sent directly to me that have no reason for being private
> > >> will likely get ignored or forwarded to a public forum with no further
> > >> warning.
> > Questions sent directly to me that have no reason for being private
> > will likely get ignored or forwarded to a public forum with no further
> > warning.
-BUILD_WITHOUT_PV=true is now the default in master, so that a plain "make" should work again. This is still only a temporary hack and we'll have to fix this the right way in the future, but it'll let people build "out of the box".
-Sorry for the delay in getting this done. Everything has been hectic.
On Sat, Mar 21, 2009 at 10:35 PM, Jean-Baptiste Queru <j...@android.com> wrote: > [still bcc android-platform, android-framework, android-porting]
> Latest status:
> -we're back to one patch: 9356.
> -build with "BUILD_WITHOUT_PV=true make"
> -quickly tested both on emulator and dream, and seems to work well > enough to not have the phone app crash in a loop.
> -I expect to submit 9356 on Monday morning PDT.
> JBQ
> On Sat, Mar 21, 2009 at 11:50 AM, Jean-Baptiste Queru <j...@android.com> wrote: >> I've been working on a "better" batch of patches (now it feels more >> like open-heart surgery with a meat cleaver):
>> -no need to delete the opencore directory or to remove it from the manifest.
>> -you need to repo download changes 9355, 9356 and 9357. No need to >> take 9300. I know it's 3 changes instead of 1, because I had to touch >> a few more parts of the system, but those are much cleaner.
>> -only tested on the emulator, so those might very well cause >> regressions on dream.
>> JBQ
>> On Thu, Mar 19, 2009 at 1:07 PM, Jean-Baptiste Queru <j...@android.com> wrote: >>> I've put together a hack that allows the system to compile and start >>> all the way to the home app. I worked with the delicateness of >>> open-heart surgery performed with a chainsaw.
>>> Steps:
>>> -remove the opencore files ( rm -rf external/opencore >>> .repo/projects/external/opencore.git ). Remove opencore from your >>> .repo/manifest.xml if you intend to repo sync the entire world but >>> don't want to have to remove opencore every single time.
>>> -most probably do a clean build ( rm -rf out/ ; make )
>>> I've "tested" on a device/release/generic/userdebug build. On my >>> machine, it compiles, launches. The media process dies (which probably >>> means that downloads are busted too), as well as the music player. The >>> browser starts and can access the network.
>>> JBQ
>>> On Wed, Mar 18, 2009 at 7:57 PM, Jean-Baptiste Queru <j...@android.com> wrote: >>>> I've submitted the merge (106 projects!), and I believe that the tree >>>> is in the state that it should be.
>>>> Caveats:
>>>> -THE BUILD IS BROKEN. You've been warned. There's been some drift >>>> around OpenCORE (probably situations where new code was written in >>>> cupcake that uses OpenCORE 1, or where APIs were removed in cupcake >>>> that OpenCORE 2 relies on).
>>>> The proper command to try to merge the OpenCORE code should be "git >>>> merge remotes/korg/cupcake" (I'm typing from memory).
>>>> -I'm not 100% sure that the server contains exactly what it should. >>>> I've had a filesystem failure right as I was trying to verify it, and >>>> I'm not gonna be able to verify until at least sometime tomorrow.
>>>> JBQ
>>>> On Wed, Mar 18, 2009 at 12:43 PM, Jean-Baptiste Queru <j...@android.com> wrote: >>>>> I expect to start submitting the changes in about an hour, i.e. >>>>> between 1:30pm and 2pm PDT.
>>>>> Starting right now, you may want to avoid initiating a new repo sync, >>>>> unless you're OK ending up with a tree that might not even compile.
>>>>> JBQ
>>>>> On Tue, Mar 17, 2009 at 6:35 PM, Jean-Baptiste Queru <j...@android.com> wrote: >>>>>> [bcc android-platform, android-framework, android-porting]
>>>>>> I'm working on merging the latest cupcake code drop into master. The >>>>>> task is quite hairy, so the following two guidelines probably apply:
>>>>>> -please don't submit anything in gerrit, as you'll just get in my way. >>>>>> -now is a good time to repo sync master, as I'm going to have to >>>>>> submit the result of the merge in a state where it doesn't build, and >>>>>> I have no idea how long it'll take to get it to build again after >>>>>> that.
>>>>>> Questions sent directly to me that have no reason for being private >>>>>> will likely get ignored or forwarded to a public forum with no further >>>>>> warning.
>>>>> Questions sent directly to me that have no reason for being private >>>>> will likely get ignored or forwarded to a public forum with no further >>>>> warning.
>>>> Questions sent directly to me that have no reason for being private >>>> will likely get ignored or forwarded to a public forum with no further >>>> warning.
>>> Questions sent directly to me that have no reason for being private >>> will likely get ignored or forwarded to a public forum with no further >>> warning.
>> Questions sent directly to me that have no reason for being private >> will likely get ignored or forwarded to a public forum with no further >> warning.
> Questions sent directly to me that have no reason for being private > will likely get ignored or forwarded to a public forum with no further > warning.
-- Jean-Baptiste M. "JBQ" Queru Android Engineer, Google.
Questions sent directly to me that have no reason for being private will likely get ignored or forwarded to a public forum with no further warning.
> -BUILD_WITHOUT_PV=true is now the default in master, so that a plain > "make" should work again. This is still only a temporary hack and > we'll have to fix this the right way in the future, but it'll let > people build "out of the box".
> -Sorry for the delay in getting this done. Everything has been hectic.
> JBQ
> On Sat, Mar 21, 2009 at 10:35 PM, Jean-Baptiste Queru > <j...@android.com> wrote: >> [still bcc android-platform, android-framework, android-porting]
>> Latest status:
>> -we're back to one patch: 9356.
>> -build with "BUILD_WITHOUT_PV=true make"
>> -quickly tested both on emulator and dream, and seems to work well >> enough to not have the phone app crash in a loop.
>> -I expect to submit 9356 on Monday morning PDT.
>> JBQ
>> On Sat, Mar 21, 2009 at 11:50 AM, Jean-Baptiste Queru <j...@android.com >> > wrote: >>> I've been working on a "better" batch of patches (now it feels more >>> like open-heart surgery with a meat cleaver):
>>> -no need to delete the opencore directory or to remove it from the >>> manifest.
>>> -you need to repo download changes 9355, 9356 and 9357. No need to >>> take 9300. I know it's 3 changes instead of 1, because I had to >>> touch >>> a few more parts of the system, but those are much cleaner.
>>> -only tested on the emulator, so those might very well cause >>> regressions on dream.
>>> JBQ
>>> On Thu, Mar 19, 2009 at 1:07 PM, Jean-Baptiste Queru <j...@android.com >>> > wrote: >>>> I've put together a hack that allows the system to compile and >>>> start >>>> all the way to the home app. I worked with the delicateness of >>>> open-heart surgery performed with a chainsaw.
>>>> Steps:
>>>> -remove the opencore files ( rm -rf external/opencore >>>> .repo/projects/external/opencore.git ). Remove opencore from your >>>> .repo/manifest.xml if you intend to repo sync the entire world but >>>> don't want to have to remove opencore every single time.
>>>> -most probably do a clean build ( rm -rf out/ ; make )
>>>> I've "tested" on a device/release/generic/userdebug build. On my >>>> machine, it compiles, launches. The media process dies (which >>>> probably >>>> means that downloads are busted too), as well as the music >>>> player. The >>>> browser starts and can access the network.
>>>> JBQ
>>>> On Wed, Mar 18, 2009 at 7:57 PM, Jean-Baptiste Queru <j...@android.com >>>> > wrote: >>>>> I've submitted the merge (106 projects!), and I believe that the >>>>> tree >>>>> is in the state that it should be.
>>>>> Caveats:
>>>>> -THE BUILD IS BROKEN. You've been warned. There's been some drift >>>>> around OpenCORE (probably situations where new code was written in >>>>> cupcake that uses OpenCORE 1, or where APIs were removed in >>>>> cupcake >>>>> that OpenCORE 2 relies on).
>>>>> The proper command to try to merge the OpenCORE code should be >>>>> "git >>>>> merge remotes/korg/cupcake" (I'm typing from memory).
>>>>> -I'm not 100% sure that the server contains exactly what it >>>>> should. >>>>> I've had a filesystem failure right as I was trying to verify >>>>> it, and >>>>> I'm not gonna be able to verify until at least sometime tomorrow.
>>>>> JBQ
>>>>> On Wed, Mar 18, 2009 at 12:43 PM, Jean-Baptiste Queru <j...@android.com >>>>> > wrote: >>>>>> I expect to start submitting the changes in about an hour, i.e. >>>>>> between 1:30pm and 2pm PDT.
>>>>>> Starting right now, you may want to avoid initiating a new repo >>>>>> sync, >>>>>> unless you're OK ending up with a tree that might not even >>>>>> compile.
>>>>>> JBQ
>>>>>> On Tue, Mar 17, 2009 at 6:35 PM, Jean-Baptiste Queru <j...@android.com >>>>>> > wrote: >>>>>>> [bcc android-platform, android-framework, android-porting]
>>>>>>> I'm working on merging the latest cupcake code drop into >>>>>>> master. The >>>>>>> task is quite hairy, so the following two guidelines probably >>>>>>> apply:
>>>>>>> -please don't submit anything in gerrit, as you'll just get in >>>>>>> my way. >>>>>>> -now is a good time to repo sync master, as I'm going to have to >>>>>>> submit the result of the merge in a state where it doesn't >>>>>>> build, and >>>>>>> I have no idea how long it'll take to get it to build again >>>>>>> after >>>>>>> that.
>>>>>>> Questions sent directly to me that have no reason for being >>>>>>> private >>>>>>> will likely get ignored or forwarded to a public forum with no >>>>>>> further >>>>>>> warning.
>>>>>> Questions sent directly to me that have no reason for being >>>>>> private >>>>>> will likely get ignored or forwarded to a public forum with no >>>>>> further >>>>>> warning.
>>>>> Questions sent directly to me that have no reason for being >>>>> private >>>>> will likely get ignored or forwarded to a public forum with no >>>>> further >>>>> warning.
>>>> Questions sent directly to me that have no reason for being private >>>> will likely get ignored or forwarded to a public forum with no >>>> further >>>> warning.
>>> Questions sent directly to me that have no reason for being private >>> will likely get ignored or forwarded to a public forum with no >>> further >>> warning.
>> Questions sent directly to me that have no reason for being private >> will likely get ignored or forwarded to a public forum with no >> further >> warning.
> Questions sent directly to me that have no reason for being private > will likely get ignored or forwarded to a public forum with no further > warning.
>> -BUILD_WITHOUT_PV=true is now the default in master, so that a plain >> "make" should work again. This is still only a temporary hack and >> we'll have to fix this the right way in the future, but it'll let >> people build "out of the box".
>> -Sorry for the delay in getting this done. Everything has been hectic.
>> JBQ
>> On Sat, Mar 21, 2009 at 10:35 PM, Jean-Baptiste Queru <j...@android.com> >> wrote:
>>> -quickly tested both on emulator and dream, and seems to work well >>> enough to not have the phone app crash in a loop.
>>> -I expect to submit 9356 on Monday morning PDT.
>>> JBQ
>>> On Sat, Mar 21, 2009 at 11:50 AM, Jean-Baptiste Queru <j...@android.com> >>> wrote:
>>>> I've been working on a "better" batch of patches (now it feels more >>>> like open-heart surgery with a meat cleaver):
>>>> -no need to delete the opencore directory or to remove it from the >>>> manifest.
>>>> -you need to repo download changes 9355, 9356 and 9357. No need to >>>> take 9300. I know it's 3 changes instead of 1, because I had to touch >>>> a few more parts of the system, but those are much cleaner.
>>>> -only tested on the emulator, so those might very well cause >>>> regressions on dream.
>>>> JBQ
>>>> On Thu, Mar 19, 2009 at 1:07 PM, Jean-Baptiste Queru <j...@android.com> >>>> wrote:
>>>>> I've put together a hack that allows the system to compile and start >>>>> all the way to the home app. I worked with the delicateness of >>>>> open-heart surgery performed with a chainsaw.
>>>>> Steps:
>>>>> -remove the opencore files ( rm -rf external/opencore >>>>> .repo/projects/external/opencore.git ). Remove opencore from your >>>>> .repo/manifest.xml if you intend to repo sync the entire world but >>>>> don't want to have to remove opencore every single time.
>>>>> -most probably do a clean build ( rm -rf out/ ; make )
>>>>> I've "tested" on a device/release/generic/userdebug build. On my >>>>> machine, it compiles, launches. The media process dies (which probably >>>>> means that downloads are busted too), as well as the music player. The >>>>> browser starts and can access the network.
>>>>> JBQ
>>>>> On Wed, Mar 18, 2009 at 7:57 PM, Jean-Baptiste Queru <j...@android.com> >>>>> wrote:
>>>>>> I've submitted the merge (106 projects!), and I believe that the tree >>>>>> is in the state that it should be.
>>>>>> Caveats:
>>>>>> -THE BUILD IS BROKEN. You've been warned. There's been some drift >>>>>> around OpenCORE (probably situations where new code was written in >>>>>> cupcake that uses OpenCORE 1, or where APIs were removed in cupcake >>>>>> that OpenCORE 2 relies on).
>>>>>> The proper command to try to merge the OpenCORE code should be "git >>>>>> merge remotes/korg/cupcake" (I'm typing from memory).
>>>>>> -I'm not 100% sure that the server contains exactly what it should. >>>>>> I've had a filesystem failure right as I was trying to verify it, and >>>>>> I'm not gonna be able to verify until at least sometime tomorrow.
>>>>>> JBQ
>>>>>> On Wed, Mar 18, 2009 at 12:43 PM, Jean-Baptiste Queru >>>>>> <j...@android.com> wrote:
>>>>>>> I expect to start submitting the changes in about an hour, i.e. >>>>>>> between 1:30pm and 2pm PDT.
>>>>>>> Starting right now, you may want to avoid initiating a new repo sync, >>>>>>> unless you're OK ending up with a tree that might not even compile.
>>>>>>> JBQ
>>>>>>> On Tue, Mar 17, 2009 at 6:35 PM, Jean-Baptiste Queru >>>>>>> <j...@android.com> wrote:
>>>>>>>> I'm working on merging the latest cupcake code drop into master. The >>>>>>>> task is quite hairy, so the following two guidelines probably apply:
>>>>>>>> -please don't submit anything in gerrit, as you'll just get in my >>>>>>>> way. >>>>>>>> -now is a good time to repo sync master, as I'm going to have to >>>>>>>> submit the result of the merge in a state where it doesn't build, >>>>>>>> and >>>>>>>> I have no idea how long it'll take to get it to build again after >>>>>>>> that.
>>>>>>>> Questions sent directly to me that have no reason for being private >>>>>>>> will likely get ignored or forwarded to a public forum with no >>>>>>>> further >>>>>>>> warning.
>>>>>>> Questions sent directly to me that have no reason for being private >>>>>>> will likely get ignored or forwarded to a public forum with no >>>>>>> further >>>>>>> warning.
>>>>>> Questions sent directly to me that have no reason for being private >>>>>> will likely get ignored or forwarded to a public forum with no further >>>>>> warning.
>>>>> Questions sent directly to me that have no reason for being private >>>>> will likely get ignored or forwarded to a public forum with no further >>>>> warning.
>>>> Questions sent directly to me that have no reason for being private >>>> will likely get ignored or forwarded to a public forum with no further >>>> warning.
>>> Questions sent directly to me that have no reason for being private >>> will likely get ignored or forwarded to a public forum with no further >>> warning.
>> Questions sent directly to me that have no reason for being private >> will likely get ignored or forwarded to a public forum with no further >> warning.
-- Jean-Baptiste M. "JBQ" Queru Android Engineer, Google.
Questions sent directly to me that have no reason for being private will likely get ignored or forwarded to a public forum with no further warning.
