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.
Thanks, JBQ
-- 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.
That sounds great.. every minor change on cupcake has been breaking
the build. With your efforts to push it into master am sure things
would be sorted out.
Hope it would build for htc_dream. Currently extract_files.sh and the
corresponding make in both branches are incomplete from 'htc_dream'
point of view.
Thanks. And thanks .. repo synced master safely. Shall wait to hear
from you before syncing master again. Exciting.
On Mar 18, 1:35 am, 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.
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.
-- 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.
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.
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.
-- 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.
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.
-patch in change 9300 ( repo download platform/frameworks/base 9300/1 )
-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.
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.
-- 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.
> 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.
I have it working on Dream (starting from ADP1 1.1) but I had to hack through the dream and msm7k projects. I'll try to put patches up on gerrit so that people can repo download them.
On Thu, Mar 19, 2009 at 4:30 PM, Rajesh S <rajeshs...@gmail.com> wrote:
> Tried it out on emulator. Boots, throws a media force close error > while unlocking the screen.
> Did u try on a real device? Could I expect it to work? Let me try > 'building for dream' sequence with this tomorrow.
> On Mar 19, 8: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.
-- 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.
That would be very helpful JBQ and much appreciated (by many).
And for ADP1 firmware release, please ensure that we could rebuild but
for binaries to the same level from sources by repo syncing to a
particular change set / date.
Thanks and regards,
Rajesh.s
On Mar 19, 11:33 pm, Jean-Baptiste Queru <j...@android.com> wrote:
> I have it working on Dream (starting from ADP1 1.1) but I had to hack
> through the dream and msm7k projects. I'll try to put patches up on
> gerrit so that people can repo download them.
> JBQ
> On Thu, Mar 19, 2009 at 4:30 PM, Rajesh S <rajeshs...@gmail.com> wrote:
> > Tried it out on emulator. Boots, throws a media force close error
> > while unlocking the screen.
> > Did u try on a real device? Could I expect it to work? Let me try
> > 'building for dream' sequence with this tomorrow.
> > On Mar 19, 8: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.
All right, if you remove opencore and properly interleave changes 9300, 9307 and 9308 in the 'build for dream' sequence, I believe that you end up with a build that boots, at least if you start from an ADP1 running 1.1. I did a device/release/dream/userdebug build.
In addition to everything that's broken on the emulator, wifi doesn't work (but 3G data does). It can place phone calls but not receive them. The orientation system is busted. Contacts crash. The SD card doesn't seem to be recognized. I've had a few random restarts. But, hey, it's the latest open-source tree running on real hardware :)
On Thu, Mar 19, 2009 at 4:41 PM, Rajesh S <rajeshs...@gmail.com> wrote:
> That would be very helpful JBQ and much appreciated (by many). > And for ADP1 firmware release, please ensure that we could rebuild but > for binaries to the same level from sources by repo syncing to a > particular change set / date. > Thanks and regards, > Rajesh.s
> On Mar 19, 11:33 pm, Jean-Baptiste Queru <j...@android.com> wrote: >> I have it working on Dream (starting from ADP1 1.1) but I had to hack >> through the dream and msm7k projects. I'll try to put patches up on >> gerrit so that people can repo download them.
>> JBQ
>> On Thu, Mar 19, 2009 at 4:30 PM, Rajesh S <rajeshs...@gmail.com> wrote:
>> > Tried it out on emulator. Boots, throws a media force close error >> > while unlocking the screen.
>> > Did u try on a real device? Could I expect it to work? Let me try >> > 'building for dream' sequence with this tomorrow.
>> > On Mar 19, 8: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.
thats excellent for the single day you spent merging the branches!!
am baffled it boots! rest of my requests were for the time you
actually have a release for ADPs. But yes I would be very glad to have
the master branch working fully with more features on ADP even
earlier.
'Building for dream' sequence has this extract files (binaries) stuff.
But it doesn't really help bring the source build to the same level as
the release. If possible enhance that and the corresponding
Android*.mk to extract and push the closed apks (mail, maps, market,
youtube, ..) etc too from the released firmware if running on the
device.
Thanks a lot for all the stuff contributed.
Rajesh.S
On Mar 19, 11:54 pm, Jean-Baptiste Queru <j...@android.com> wrote:
> All right, if you remove opencore and properly interleave changes
> 9300, 9307 and 9308 in the 'build for dream' sequence, I believe that
> you end up with a build that boots, at least if you start from an ADP1
> running 1.1. I did a device/release/dream/userdebug build.
> In addition to everything that's broken on the emulator, wifi doesn't
> work (but 3G data does). It can place phone calls but not receive
> them. The orientation system is busted. Contacts crash. The SD card
> doesn't seem to be recognized. I've had a few random restarts. But,
> hey, it's the latest open-source tree running on real hardware :)
> JBQ
> On Thu, Mar 19, 2009 at 4:41 PM, Rajesh S <rajeshs...@gmail.com> wrote:
> > That would be very helpful JBQ and much appreciated (by many).
> > And for ADP1 firmware release, please ensure that we could rebuild but
> > for binaries to the same level from sources by repo syncing to a
> > particular change set / date.
> > Thanks and regards,
> > Rajesh.s
> > On Mar 19, 11:33 pm, Jean-Baptiste Queru <j...@android.com> wrote:
> >> I have it working on Dream (starting from ADP1 1.1) but I had to hack
> >> through the dream and msm7k projects. I'll try to put patches up on
> >> gerrit so that people can repo download them.
> >> JBQ
> >> On Thu, Mar 19, 2009 at 4:30 PM, Rajesh S <rajeshs...@gmail.com> wrote:
> >> > Tried it out on emulator. Boots, throws a media force close error
> >> > while unlocking the screen.
> >> > Did u try on a real device? Could I expect it to work? Let me try
> >> > 'building for dream' sequence with this tomorrow.
> >> > On Mar 19, 8: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.
The apks in question are far more fragile than the low-level native binaries, compatibility-wise, as they use plenty of non-SDK APIs, and the 1.1 apks most probably aren't going to work on master.
If you could have a source tree that exactly matches a released device, that'd be possible, though very fragile as there are still plenty of things you couldn't change in the system (e.g. you couldn't add or remove system resources).
Unless Google reverses its position on providing its applications for open-source builds, we need to assume that master builds just won't have access to Google's apps.
On Fri, Mar 20, 2009 at 12:27 AM, Rajesh S <rajeshs...@gmail.com> wrote:
> thats excellent for the single day you spent merging the branches!! > am baffled it boots! rest of my requests were for the time you > actually have a release for ADPs. But yes I would be very glad to have > the master branch working fully with more features on ADP even > earlier.
> 'Building for dream' sequence has this extract files (binaries) stuff. > But it doesn't really help bring the source build to the same level as > the release. If possible enhance that and the corresponding > Android*.mk to extract and push the closed apks (mail, maps, market, > youtube, ..) etc too from the released firmware if running on the > device.
> Thanks a lot for all the stuff contributed. > Rajesh.S
> On Mar 19, 11:54 pm, Jean-Baptiste Queru <j...@android.com> wrote: >> All right, if you remove opencore and properly interleave changes >> 9300, 9307 and 9308 in the 'build for dream' sequence, I believe that >> you end up with a build that boots, at least if you start from an ADP1 >> running 1.1. I did a device/release/dream/userdebug build.
>> In addition to everything that's broken on the emulator, wifi doesn't >> work (but 3G data does). It can place phone calls but not receive >> them. The orientation system is busted. Contacts crash. The SD card >> doesn't seem to be recognized. I've had a few random restarts. But, >> hey, it's the latest open-source tree running on real hardware :)
>> JBQ
>> On Thu, Mar 19, 2009 at 4:41 PM, Rajesh S <rajeshs...@gmail.com> wrote:
>> > That would be very helpful JBQ and much appreciated (by many). >> > And for ADP1 firmware release, please ensure that we could rebuild but >> > for binaries to the same level from sources by repo syncing to a >> > particular change set / date. >> > Thanks and regards, >> > Rajesh.s
>> > On Mar 19, 11:33 pm, Jean-Baptiste Queru <j...@android.com> wrote: >> >> I have it working on Dream (starting from ADP1 1.1) but I had to hack >> >> through the dream and msm7k projects. I'll try to put patches up on >> >> gerrit so that people can repo download them.
>> >> JBQ
>> >> On Thu, Mar 19, 2009 at 4:30 PM, Rajesh S <rajeshs...@gmail.com> wrote:
>> >> > Tried it out on emulator. Boots, throws a media force close error >> >> > while unlocking the screen.
>> >> > Did u try on a real device? Could I expect it to work? Let me try >> >> > 'building for dream' sequence with this tomorrow.
>> >> > On Mar 19, 8: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.
It could be as fragile as it could be but all am asking for is a
particular date or tag to repo sync to so that the firmware built out
of master is as close as possible to the release for ADP. Hopefully at
least in this case, the proprietary binaries (apks too) would be
compatible.
Even if the 1.1 or later APKs use non-SDK APIs, it must be possible to
patch (at least in some binary fashion) to use the extracted APKs
after building on master.
Else one of the critical purposes of the master branch as open source
for developers is defeated.
That would unfortunately motivate us to stick to the firmware from
Google and not use our own build for want of Google APKs on ADP1s.
On Mar 20, 12:32 pm, Jean-Baptiste Queru <j...@android.com> wrote:
> The apks in question are far more fragile than the low-level native
> binaries, compatibility-wise, as they use plenty of non-SDK APIs, and
> the 1.1 apks most probably aren't going to work on master.
> If you could have a source tree that exactly matches a released
> device, that'd be possible, though very fragile as there are still
> plenty of things you couldn't change in the system (e.g. you couldn't
> add or remove system resources).
> Unless Google reverses its position on providing its applications for
> open-source builds, we need to assume that master builds just won't
> have access to Google's apps.
> JBQ
> On Fri, Mar 20, 2009 at 12:27 AM, Rajesh S <rajeshs...@gmail.com> wrote:
> > thats excellent for the single day you spent merging the branches!!
> > am baffled it boots! rest of my requests were for the time you
> > actually have a release for ADPs. But yes I would be very glad to have
> > the master branch working fully with more features on ADP even
> > earlier.
> > 'Building for dream' sequence has this extract files (binaries) stuff.
> > But it doesn't really help bring the source build to the same level as
> > the release. If possible enhance that and the corresponding
> > Android*.mk to extract and push the closed apks (mail, maps, market,
> > youtube, ..) etc too from the released firmware if running on the
> > device.
> > Thanks a lot for all the stuff contributed.
> > Rajesh.S
> > On Mar 19, 11:54 pm, Jean-Baptiste Queru <j...@android.com> wrote:
> >> All right, if you remove opencore and properly interleave changes
> >> 9300, 9307 and 9308 in the 'build for dream' sequence, I believe that
> >> you end up with a build that boots, at least if you start from an ADP1
> >> running 1.1. I did a device/release/dream/userdebug build.
> >> In addition to everything that's broken on the emulator, wifi doesn't
> >> work (but 3G data does). It can place phone calls but not receive
> >> them. The orientation system is busted. Contacts crash. The SD card
> >> doesn't seem to be recognized. I've had a few random restarts. But,
> >> hey, it's the latest open-source tree running on real hardware :)
> >> JBQ
> >> On Thu, Mar 19, 2009 at 4:41 PM, Rajesh S <rajeshs...@gmail.com> wrote:
> >> > That would be very helpful JBQ and much appreciated (by many).
> >> > And for ADP1 firmware release, please ensure that we could rebuild but
> >> > for binaries to the same level from sources by repo syncing to a
> >> > particular change set / date.
> >> > Thanks and regards,
> >> > Rajesh.s
> >> > On Mar 19, 11:33 pm, Jean-Baptiste Queru <j...@android.com> wrote:
> >> >> I have it working on Dream (starting from ADP1 1.1) but I had to hack
> >> >> through the dream and msm7k projects. I'll try to put patches up on
> >> >> gerrit so that people can repo download them.
> >> >> JBQ
> >> >> On Thu, Mar 19, 2009 at 4:30 PM, Rajesh S <rajeshs...@gmail.com> wrote:
> >> >> > Tried it out on emulator. Boots, throws a media force close error
> >> >> > while unlocking the screen.
> >> >> > Did u try on a real device? Could I expect it to work? Let me try
> >> >> > 'building for dream' sequence with this tomorrow.
> >> >> > On Mar 19, 8: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.
I don't expect master (which is bleeding edge by definition) to ever become stable enough to have official releases cut out of it (ADP1 or otherwise). Releases will come out of branches from master (or, much more likely, 2 or 3 levels away). I'm hoping that the exact platform source code that is used to build ADP1 releases and SDK releases can be made available, but I can't quite promise it.
Your point remains, it'd be nice if Google could make their apps available for the Android Open-Source Project. I've relayed that request several times, so I know that the people who can make such a decision know about it.
Personally, I'm more concerned about getting the code from the Android Open-Source Project to reliably work on some flashable and commonly available hardware.
On Fri, Mar 20, 2009 at 6:07 AM, Rajesh S <rajeshs...@gmail.com> wrote:
> It could be as fragile as it could be but all am asking for is a > particular date or tag to repo sync to so that the firmware built out > of master is as close as possible to the release for ADP. Hopefully at > least in this case, the proprietary binaries (apks too) would be > compatible.
> Even if the 1.1 or later APKs use non-SDK APIs, it must be possible to > patch (at least in some binary fashion) to use the extracted APKs > after building on master. > Else one of the critical purposes of the master branch as open source > for developers is defeated. > That would unfortunately motivate us to stick to the firmware from > Google and not use our own build for want of Google APKs on ADP1s.
> On Mar 20, 12:32 pm, Jean-Baptiste Queru <j...@android.com> wrote: >> The apks in question are far more fragile than the low-level native >> binaries, compatibility-wise, as they use plenty of non-SDK APIs, and >> the 1.1 apks most probably aren't going to work on master.
>> If you could have a source tree that exactly matches a released >> device, that'd be possible, though very fragile as there are still >> plenty of things you couldn't change in the system (e.g. you couldn't >> add or remove system resources).
>> Unless Google reverses its position on providing its applications for >> open-source builds, we need to assume that master builds just won't >> have access to Google's apps.
>> JBQ
>> On Fri, Mar 20, 2009 at 12:27 AM, Rajesh S <rajeshs...@gmail.com> wrote:
>> > thats excellent for the single day you spent merging the branches!! >> > am baffled it boots! rest of my requests were for the time you >> > actually have a release for ADPs. But yes I would be very glad to have >> > the master branch working fully with more features on ADP even >> > earlier.
>> > 'Building for dream' sequence has this extract files (binaries) stuff. >> > But it doesn't really help bring the source build to the same level as >> > the release. If possible enhance that and the corresponding >> > Android*.mk to extract and push the closed apks (mail, maps, market, >> > youtube, ..) etc too from the released firmware if running on the >> > device.
>> > Thanks a lot for all the stuff contributed. >> > Rajesh.S
>> > On Mar 19, 11:54 pm, Jean-Baptiste Queru <j...@android.com> wrote: >> >> All right, if you remove opencore and properly interleave changes >> >> 9300, 9307 and 9308 in the 'build for dream' sequence, I believe that >> >> you end up with a build that boots, at least if you start from an ADP1 >> >> running 1.1. I did a device/release/dream/userdebug build.
>> >> In addition to everything that's broken on the emulator, wifi doesn't >> >> work (but 3G data does). It can place phone calls but not receive >> >> them. The orientation system is busted. Contacts crash. The SD card >> >> doesn't seem to be recognized. I've had a few random restarts. But, >> >> hey, it's the latest open-source tree running on real hardware :)
>> >> JBQ
>> >> On Thu, Mar 19, 2009 at 4:41 PM, Rajesh S <rajeshs...@gmail.com> wrote:
>> >> > That would be very helpful JBQ and much appreciated (by many). >> >> > And for ADP1 firmware release, please ensure that we could rebuild but >> >> > for binaries to the same level from sources by repo syncing to a >> >> > particular change set / date. >> >> > Thanks and regards, >> >> > Rajesh.s
>> >> > On Mar 19, 11:33 pm, Jean-Baptiste Queru <j...@android.com> wrote: >> >> >> I have it working on Dream (starting from ADP1 1.1) but I had to hack >> >> >> through the dream and msm7k projects. I'll try to put patches up on >> >> >> gerrit so that people can repo download them.
>> >> >> JBQ
>> >> >> On Thu, Mar 19, 2009 at 4:30 PM, Rajesh S <rajeshs...@gmail.com> wrote:
>> >> >> > Tried it out on emulator. Boots, throws a media force close error >> >> >> > while unlocking the screen.
>> >> >> > Did u try on a real device? Could I expect it to work? Let me try >> >> >> > 'building for dream' sequence with this tomorrow.
>> >> >> > On Mar 19, 8: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.
Yes JBQ, it would be nice to have the level 2 or 3 branched platform
source not necessarily through git .. may be as a tarball with
proprietary stuff given as binaries only.
We won't even need the second option suggested by you. As long as we
can extract the binaries and APKs from a phone flashed with your
latest release and reuse with the specific branch/tarball, we are
fine. Let the close sourced stuff remain so, just help it work with
some open source build while releasing.
And am are very very glad about you helping the master branch work
with some hardware (ADP1 today). Thanks a lot.
Regards,
Rajesh.S
On Mar 20, 1:26 pm, Jean-Baptiste Queru <j...@android.com> wrote:
> I don't expect master (which is bleeding edge by definition) to ever
> become stable enough to have official releases cut out of it (ADP1 or
> otherwise). Releases will come out of branches from master (or, much
> more likely, 2 or 3 levels away). I'm hoping that the exact platform
> source code that is used to build ADP1 releases and SDK releases can
> be made available, but I can't quite promise it.
> Your point remains, it'd be nice if Google could make their apps
> available for the Android Open-Source Project. I've relayed that
> request several times, so I know that the people who can make such a
> decision know about it.
> Personally, I'm more concerned about getting the code from the Android
> Open-Source Project to reliably work on some flashable and commonly
> available hardware.
> JBQ
> On Fri, Mar 20, 2009 at 6:07 AM, Rajesh S <rajeshs...@gmail.com> wrote:
> > It could be as fragile as it could be but all am asking for is a
> > particular date or tag to repo sync to so that the firmware built out
> > of master is as close as possible to the release for ADP. Hopefully at
> > least in this case, the proprietary binaries (apks too) would be
> > compatible.
> > Even if the 1.1 or later APKs use non-SDK APIs, it must be possible to
> > patch (at least in some binary fashion) to use the extracted APKs
> > after building on master.
> > Else one of the critical purposes of the master branch as open source
> > for developers is defeated.
> > That would unfortunately motivate us to stick to the firmware from
> > Google and not use our own build for want of Google APKs on ADP1s.
> > On Mar 20, 12:32 pm, Jean-Baptiste Queru <j...@android.com> wrote:
> >> The apks in question are far more fragile than the low-level native
> >> binaries, compatibility-wise, as they use plenty of non-SDK APIs, and
> >> the 1.1 apks most probably aren't going to work on master.
> >> If you could have a source tree that exactly matches a released
> >> device, that'd be possible, though very fragile as there are still
> >> plenty of things you couldn't change in the system (e.g. you couldn't
> >> add or remove system resources).
> >> Unless Google reverses its position on providing its applications for
> >> open-source builds, we need to assume that master builds just won't
> >> have access to Google's apps.
> >> JBQ
> >> On Fri, Mar 20, 2009 at 12:27 AM, Rajesh S <rajeshs...@gmail.com> wrote:
> >> > thats excellent for the single day you spent merging the branches!!
> >> > am baffled it boots! rest of my requests were for the time you
> >> > actually have a release for ADPs. But yes I would be very glad to have
> >> > the master branch working fully with more features on ADP even
> >> > earlier.
> >> > 'Building for dream' sequence has this extract files (binaries) stuff.
> >> > But it doesn't really help bring the source build to the same level as
> >> > the release. If possible enhance that and the corresponding
> >> > Android*.mk to extract and push the closed apks (mail, maps, market,
> >> > youtube, ..) etc too from the released firmware if running on the
> >> > device.
> >> > Thanks a lot for all the stuff contributed.
> >> > Rajesh.S
> >> > On Mar 19, 11:54 pm, Jean-Baptiste Queru <j...@android.com> wrote:
> >> >> All right, if you remove opencore and properly interleave changes
> >> >> 9300, 9307 and 9308 in the 'build for dream' sequence, I believe that
> >> >> you end up with a build that boots, at least if you start from an ADP1
> >> >> running 1.1. I did a device/release/dream/userdebug build.
> >> >> In addition to everything that's broken on the emulator, wifi doesn't
> >> >> work (but 3G data does). It can place phone calls but not receive
> >> >> them. The orientation system is busted. Contacts crash. The SD card
> >> >> doesn't seem to be recognized. I've had a few random restarts. But,
> >> >> hey, it's the latest open-source tree running on real hardware :)
> >> >> JBQ
> >> >> On Thu, Mar 19, 2009 at 4:41 PM, Rajesh S <rajeshs...@gmail.com> wrote:
> >> >> > That would be very helpful JBQ and much appreciated (by many).
> >> >> > And for ADP1 firmware release, please ensure that we could rebuild but
> >> >> > for binaries to the same level from sources by repo syncing to a
> >> >> > particular change set / date.
> >> >> > Thanks and regards,
> >> >> > Rajesh.s
> >> >> > On Mar 19, 11:33 pm, Jean-Baptiste Queru <j...@android.com> wrote:
> >> >> >> I have it working on Dream (starting from ADP1 1.1) but I had to hack
> >> >> >> through the dream and msm7k projects. I'll try to put patches up on
> >> >> >> gerrit so that people can repo download them.
> >> >> >> JBQ
> >> >> >> On Thu, Mar 19, 2009 at 4:30 PM, Rajesh S <rajeshs...@gmail.com> wrote:
> >> >> >> > Tried it out on emulator. Boots, throws a media force close error
> >> >> >> > while unlocking the screen.
> >> >> >> > Did u try on a real device? Could I expect it to work? Let me try
> >> >> >> > 'building for dream' sequence with this tomorrow.
> >> >> >> > On Mar 19, 8: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.
On Fri, Mar 20, 2009 at 7:45 AM, Rajesh S <rajeshs...@gmail.com> wrote:
> Yes JBQ, it would be nice to have the level 2 or 3 branched platform > source not necessarily through git .. may be as a tarball with > proprietary stuff given as binaries only.
> We won't even need the second option suggested by you. As long as we > can extract the binaries and APKs from a phone flashed with your > latest release and reuse with the specific branch/tarball, we are > fine. Let the close sourced stuff remain so, just help it work with > some open source build while releasing.
> And am are very very glad about you helping the master branch work > with some hardware (ADP1 today). Thanks a lot.
> Regards, > Rajesh.S
> On Mar 20, 1:26 pm, Jean-Baptiste Queru <j...@android.com> wrote: >> I don't expect master (which is bleeding edge by definition) to ever >> become stable enough to have official releases cut out of it (ADP1 or >> otherwise). Releases will come out of branches from master (or, much >> more likely, 2 or 3 levels away). I'm hoping that the exact platform >> source code that is used to build ADP1 releases and SDK releases can >> be made available, but I can't quite promise it.
>> Your point remains, it'd be nice if Google could make their apps >> available for the Android Open-Source Project. I've relayed that >> request several times, so I know that the people who can make such a >> decision know about it.
>> Personally, I'm more concerned about getting the code from the Android >> Open-Source Project to reliably work on some flashable and commonly >> available hardware.
>> JBQ
>> On Fri, Mar 20, 2009 at 6:07 AM, Rajesh S <rajeshs...@gmail.com> wrote:
>> > It could be as fragile as it could be but all am asking for is a >> > particular date or tag to repo sync to so that the firmware built out >> > of master is as close as possible to the release for ADP. Hopefully at >> > least in this case, the proprietary binaries (apks too) would be >> > compatible.
>> > Even if the 1.1 or later APKs use non-SDK APIs, it must be possible to >> > patch (at least in some binary fashion) to use the extracted APKs >> > after building on master. >> > Else one of the critical purposes of the master branch as open source >> > for developers is defeated. >> > That would unfortunately motivate us to stick to the firmware from >> > Google and not use our own build for want of Google APKs on ADP1s.
>> > On Mar 20, 12:32 pm, Jean-Baptiste Queru <j...@android.com> wrote: >> >> The apks in question are far more fragile than the low-level native >> >> binaries, compatibility-wise, as they use plenty of non-SDK APIs, and >> >> the 1.1 apks most probably aren't going to work on master.
>> >> If you could have a source tree that exactly matches a released >> >> device, that'd be possible, though very fragile as there are still >> >> plenty of things you couldn't change in the system (e.g. you couldn't >> >> add or remove system resources).
>> >> Unless Google reverses its position on providing its applications for >> >> open-source builds, we need to assume that master builds just won't >> >> have access to Google's apps.
>> >> JBQ
>> >> On Fri, Mar 20, 2009 at 12:27 AM, Rajesh S <rajeshs...@gmail.com> wrote:
>> >> > thats excellent for the single day you spent merging the branches!! >> >> > am baffled it boots! rest of my requests were for the time you >> >> > actually have a release for ADPs. But yes I would be very glad to have >> >> > the master branch working fully with more features on ADP even >> >> > earlier.
>> >> > 'Building for dream' sequence has this extract files (binaries) stuff. >> >> > But it doesn't really help bring the source build to the same level as >> >> > the release. If possible enhance that and the corresponding >> >> > Android*.mk to extract and push the closed apks (mail, maps, market, >> >> > youtube, ..) etc too from the released firmware if running on the >> >> > device.
>> >> > Thanks a lot for all the stuff contributed. >> >> > Rajesh.S
>> >> > On Mar 19, 11:54 pm, Jean-Baptiste Queru <j...@android.com> wrote: >> >> >> All right, if you remove opencore and properly interleave changes >> >> >> 9300, 9307 and 9308 in the 'build for dream' sequence, I believe that >> >> >> you end up with a build that boots, at least if you start from an ADP1 >> >> >> running 1.1. I did a device/release/dream/userdebug build.
>> >> >> In addition to everything that's broken on the emulator, wifi doesn't >> >> >> work (but 3G data does). It can place phone calls but not receive >> >> >> them. The orientation system is busted. Contacts crash. The SD card >> >> >> doesn't seem to be recognized. I've had a few random restarts. But, >> >> >> hey, it's the latest open-source tree running on real hardware :)
>> >> >> JBQ
>> >> >> On Thu, Mar 19, 2009 at 4:41 PM, Rajesh S <rajeshs...@gmail.com> wrote:
>> >> >> > That would be very helpful JBQ and much appreciated (by many). >> >> >> > And for ADP1 firmware release, please ensure that we could rebuild but >> >> >> > for binaries to the same level from sources by repo syncing to a >> >> >> > particular change set / date. >> >> >> > Thanks and regards, >> >> >> > Rajesh.s
>> >> >> > On Mar 19, 11:33 pm, Jean-Baptiste Queru <j...@android.com> wrote: >> >> >> >> I have it working on Dream (starting from ADP1 1.1) but I had to hack >> >> >> >> through the dream and msm7k projects. I'll try to put patches up on >> >> >> >> gerrit so that people can repo download them.
>> >> >> >> JBQ
>> >> >> >> On Thu, Mar 19, 2009 at 4:30 PM, Rajesh S <rajeshs...@gmail.com> wrote:
>> >> >> >> > Tried it out on emulator. Boots, throws a media force close error >> >> >> >> > while unlocking the screen.
>> >> >> >> > Did u try on a real device? Could I expect it to work? Let me try >> >> >> >> > 'building for dream' sequence with this tomorrow.
>> >> >> >> > On Mar 19, 8: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.
Thanks JBQ as long as firmware built from sources could accommodate
binary packages too. Thanks a lot for your time. I'll stop disturbing
on this, as you have very well acknowledged my request, so that you
could work and give us a good stable master branch for ADP1 ;-)
On Mar 20, 2:54 pm, Jean-Baptiste Queru <j...@android.com> wrote:
> I really expect that future source drops would be done through git.
> It's just much more efficient at several levels.
> JBQ
> On Fri, Mar 20, 2009 at 7:45 AM, Rajesh S <rajeshs...@gmail.com> wrote:
> > Yes JBQ, it would be nice to have the level 2 or 3 branched platform
> > source not necessarily through git .. may be as a tarball with
> > proprietary stuff given as binaries only.
> > We won't even need the second option suggested by you. As long as we
> > can extract the binaries and APKs from a phone flashed with your
> > latest release and reuse with the specific branch/tarball, we are
> > fine. Let the close sourced stuff remain so, just help it work with
> > some open source build while releasing.
> > And am are very very glad about you helping the master branch work
> > with some hardware (ADP1 today). Thanks a lot.
> > Regards,
> > Rajesh.S
> > On Mar 20, 1:26 pm, Jean-Baptiste Queru <j...@android.com> wrote:
> >> I don't expect master (which is bleeding edge by definition) to ever
> >> become stable enough to have official releases cut out of it (ADP1 or
> >> otherwise). Releases will come out of branches from master (or, much
> >> more likely, 2 or 3 levels away). I'm hoping that the exact platform
> >> source code that is used to build ADP1 releases and SDK releases can
> >> be made available, but I can't quite promise it.
> >> Your point remains, it'd be nice if Google could make their apps
> >> available for the Android Open-Source Project. I've relayed that
> >> request several times, so I know that the people who can make such a
> >> decision know about it.
> >> Personally, I'm more concerned about getting the code from the Android
> >> Open-Source Project to reliably work on some flashable and commonly
> >> available hardware.
> >> JBQ
> >> On Fri, Mar 20, 2009 at 6:07 AM, Rajesh S <rajeshs...@gmail.com> wrote:
> >> > It could be as fragile as it could be but all am asking for is a
> >> > particular date or tag to repo sync to so that the firmware built out
> >> > of master is as close as possible to the release for ADP. Hopefully at
> >> > least in this case, the proprietary binaries (apks too) would be
> >> > compatible.
> >> > Even if the 1.1 or later APKs use non-SDK APIs, it must be possible to
> >> > patch (at least in some binary fashion) to use the extracted APKs
> >> > after building on master.
> >> > Else one of the critical purposes of the master branch as open source
> >> > for developers is defeated.
> >> > That would unfortunately motivate us to stick to the firmware from
> >> > Google and not use our own build for want of Google APKs on ADP1s.
> >> > On Mar 20, 12:32 pm, Jean-Baptiste Queru <j...@android.com> wrote:
> >> >> The apks in question are far more fragile than the low-level native
> >> >> binaries, compatibility-wise, as they use plenty of non-SDK APIs, and
> >> >> the 1.1 apks most probably aren't going to work on master.
> >> >> If you could have a source tree that exactly matches a released
> >> >> device, that'd be possible, though very fragile as there are still
> >> >> plenty of things you couldn't change in the system (e.g. you couldn't
> >> >> add or remove system resources).
> >> >> Unless Google reverses its position on providing its applications for
> >> >> open-source builds, we need to assume that master builds just won't
> >> >> have access to Google's apps.
> >> >> JBQ
> >> >> On Fri, Mar 20, 2009 at 12:27 AM, Rajesh S <rajeshs...@gmail.com> wrote:
> >> >> > thats excellent for the single day you spent merging the branches!!
> >> >> > am baffled it boots! rest of my requests were for the time you
> >> >> > actually have a release for ADPs. But yes I would be very glad to have
> >> >> > the master branch working fully with more features on ADP even
> >> >> > earlier.
> >> >> > 'Building for dream' sequence has this extract files (binaries) stuff.
> >> >> > But it doesn't really help bring the source build to the same level as
> >> >> > the release. If possible enhance that and the corresponding
> >> >> > Android*.mk to extract and push the closed apks (mail, maps, market,
> >> >> > youtube, ..) etc too from the released firmware if running on the
> >> >> > device.
> >> >> > Thanks a lot for all the stuff contributed.
> >> >> > Rajesh.S
> >> >> > On Mar 19, 11:54 pm, Jean-Baptiste Queru <j...@android.com> wrote:
> >> >> >> All right, if you remove opencore and properly interleave changes
> >> >> >> 9300, 9307 and 9308 in the 'build for dream' sequence, I believe that
> >> >> >> you end up with a build that boots, at least if you start from an ADP1
> >> >> >> running 1.1. I did a device/release/dream/userdebug build.
> >> >> >> In addition to everything that's broken on the emulator, wifi doesn't
> >> >> >> work (but 3G data does). It can place phone calls but not receive
> >> >> >> them. The orientation system is busted. Contacts crash. The SD card
> >> >> >> doesn't seem to be recognized. I've had a few random restarts. But,
> >> >> >> hey, it's the latest open-source tree running on real hardware :)
> >> >> >> JBQ
> >> >> >> On Thu, Mar 19, 2009 at 4:41 PM, Rajesh S <rajeshs...@gmail.com> wrote:
> >> >> >> > That would be very helpful JBQ and much appreciated (by many).
> >> >> >> > And for ADP1 firmware release, please ensure that we could rebuild but
> >> >> >> > for binaries to the same level from sources by repo syncing to a
> >> >> >> > particular change set / date.
> >> >> >> > Thanks and regards,
> >> >> >> > Rajesh.s
> >> >> >> > On Mar 19, 11:33 pm, Jean-Baptiste Queru <j...@android.com> wrote:
> >> >> >> >> I have it working on Dream (starting from ADP1 1.1) but I had to hack
> >> >> >> >> through the dream and msm7k projects. I'll try to put patches up on
> >> >> >> >> gerrit so that people can repo download them.
> >> >> >> >> JBQ
> >> >> >> >> On Thu, Mar 19, 2009 at 4:30 PM, Rajesh S <rajeshs...@gmail.com> wrote:
> >> >> >> >> > Tried it out on emulator. Boots, throws a media force close error
> >> >> >> >> > while unlocking the screen.
> >> >> >> >> > Did u try on a real device? Could I expect it to work? Let me try
> >> >> >> >> > 'building for dream' sequence with this tomorrow.
> >> >> >> >> > On Mar 19, 8: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
I've put in a few fixes that should help run the master branch on ADP1 (makes it build without the need for 9307 and 9308, and adds wifi support).
The need to remove opencore and patch in 9300 is still there, though. I was hoping for a better solution before the week-end, but somehow trying to replicate 9300 "cleanly" didn't quite work and I can't spot the difference.
On Thu, Mar 19, 2009 at 4:54 PM, Jean-Baptiste Queru <j...@android.com> wrote: > All right, if you remove opencore and properly interleave changes > 9300, 9307 and 9308 in the 'build for dream' sequence, I believe that > you end up with a build that boots, at least if you start from an ADP1 > running 1.1. I did a device/release/dream/userdebug build.
> In addition to everything that's broken on the emulator, wifi doesn't > work (but 3G data does). It can place phone calls but not receive > them. The orientation system is busted. Contacts crash. The SD card > doesn't seem to be recognized. I've had a few random restarts. But, > hey, it's the latest open-source tree running on real hardware :)
> JBQ
> On Thu, Mar 19, 2009 at 4:41 PM, Rajesh S <rajeshs...@gmail.com> wrote:
>> That would be very helpful JBQ and much appreciated (by many). >> And for ADP1 firmware release, please ensure that we could rebuild but >> for binaries to the same level from sources by repo syncing to a >> particular change set / date. >> Thanks and regards, >> Rajesh.s
>> On Mar 19, 11:33 pm, Jean-Baptiste Queru <j...@android.com> wrote: >>> I have it working on Dream (starting from ADP1 1.1) but I had to hack >>> through the dream and msm7k projects. I'll try to put patches up on >>> gerrit so that people can repo download them.
>>> JBQ
>>> On Thu, Mar 19, 2009 at 4:30 PM, Rajesh S <rajeshs...@gmail.com> wrote:
>>> > Tried it out on emulator. Boots, throws a media force close error >>> > while unlocking the screen.
>>> > Did u try on a real device? Could I expect it to work? Let me try >>> > 'building for dream' sequence with this tomorrow.
>>> > On Mar 19, 8: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.
Hi JBQ,
Thanks for the merged code.. many things work. But there are a few
bugs.. some that have always been there on master.
Not worth mentioning as bugs since this is in between a merge.
But just in case if it is going to help, here are some observations:
- wifi, soft-keyboard, transitions, spare parts, ... work well.
- as expected media error reports for all triggers (start-up, volume,
music app, ...)
- not sure if i have the wrong version of radio but even on
completion of a sms sequence, i get to see the flashing android
logo .. probably the init process restarts, and gets back to home
screen within a 10 seconds.
- camera crashes on app start.. (libOmxCore...?)
- home button has no effect
- messaging/browser app orientation gets stuck when hardware keyboard
is shut and soft-keyboard is used.
- and of course none of the proprietary apps work if pushed in
through system.img
Regards,
Rajesh.S
On Mar 21, 2:59 am, Jean-Baptiste Queru <j...@android.com> wrote:
> I've put in a few fixes that should help run the master branch on ADP1
> (makes it build without the need for 9307 and 9308, and adds wifi
> support).
> The need to remove opencore and patch in 9300 is still there, though.
> I was hoping for a better solution before the week-end, but somehow
> trying to replicate 9300 "cleanly" didn't quite work and I can't spot
> the difference.
> JBQ
> On Thu, Mar 19, 2009 at 4:54 PM, Jean-Baptiste Queru <j...@android.com> wrote:
> > All right, if you remove opencore and properly interleave changes
> > 9300, 9307 and 9308 in the 'build for dream' sequence, I believe that
> > you end up with a build that boots, at least if you start from an ADP1
> > running 1.1. I did a device/release/dream/userdebug build.
> > In addition to everything that's broken on the emulator, wifi doesn't
> > work (but 3G data does). It can place phone calls but not receive
> > them. The orientation system is busted. Contacts crash. The SD card
> > doesn't seem to be recognized. I've had a few random restarts. But,
> > hey, it's the latest open-source tree running on real hardware :)
> > JBQ
> > On Thu, Mar 19, 2009 at 4:41 PM, Rajesh S <rajeshs...@gmail.com> wrote:
> >> That would be very helpful JBQ and much appreciated (by many).
> >> And for ADP1 firmware release, please ensure that we could rebuild but
> >> for binaries to the same level from sources by repo syncing to a
> >> particular change set / date.
> >> Thanks and regards,
> >> Rajesh.s
> >> On Mar 19, 11:33 pm, Jean-Baptiste Queru <j...@android.com> wrote:
> >>> I have it working on Dream (starting from ADP1 1.1) but I had to hack
> >>> through the dream and msm7k projects. I'll try to put patches up on
> >>> gerrit so that people can repo download them.
> >>> JBQ
> >>> On Thu, Mar 19, 2009 at 4:30 PM, Rajesh S <rajeshs...@gmail.com> wrote:
> >>> > Tried it out on emulator. Boots, throws a media force close error
> >>> > while unlocking the screen.
> >>> > Did u try on a real device? Could I expect it to work? Let me try
> >>> > 'building for dream' sequence with this tomorrow.
> >>> > On Mar 19, 8: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:21 AM, Rajesh S <rajeshs...@gmail.com> wrote:
> Hi JBQ, > Thanks for the merged code.. many things work. But there are a few > bugs.. some that have always been there on master. > Not worth mentioning as bugs since this is in between a merge. > But just in case if it is going to help, here are some observations: > - wifi, soft-keyboard, transitions, spare parts, ... work well. > - as expected media error reports for all triggers (start-up, volume, > music app, ...) > - not sure if i have the wrong version of radio but even on > completion of a sms sequence, i get to see the flashing android > logo .. probably the init process restarts, and gets back to home > screen within a 10 seconds. > - camera crashes on app start.. (libOmxCore...?) > - home button has no effect > - messaging/browser app orientation gets stuck when hardware keyboard > is shut and soft-keyboard is used.
> - and of course none of the proprietary apps work if pushed in > through system.img
> Regards, > Rajesh.S
> On Mar 21, 2:59 am, Jean-Baptiste Queru <j...@android.com> wrote: >> I've put in a few fixes that should help run the master branch on ADP1 >> (makes it build without the need for 9307 and 9308, and adds wifi >> support).
>> The need to remove opencore and patch in 9300 is still there, though. >> I was hoping for a better solution before the week-end, but somehow >> trying to replicate 9300 "cleanly" didn't quite work and I can't spot >> the difference.
>> JBQ
>> On Thu, Mar 19, 2009 at 4:54 PM, Jean-Baptiste Queru <j...@android.com> wrote: >> > All right, if you remove opencore and properly interleave changes >> > 9300, 9307 and 9308 in the 'build for dream' sequence, I believe that >> > you end up with a build that boots, at least if you start from an ADP1 >> > running 1.1. I did a device/release/dream/userdebug build.
>> > In addition to everything that's broken on the emulator, wifi doesn't >> > work (but 3G data does). It can place phone calls but not receive >> > them. The orientation system is busted. Contacts crash. The SD card >> > doesn't seem to be recognized. I've had a few random restarts. But, >> > hey, it's the latest open-source tree running on real hardware :)
>> > JBQ
>> > On Thu, Mar 19, 2009 at 4:41 PM, Rajesh S <rajeshs...@gmail.com> wrote:
>> >> That would be very helpful JBQ and much appreciated (by many). >> >> And for ADP1 firmware release, please ensure that we could rebuild but >> >> for binaries to the same level from sources by repo syncing to a >> >> particular change set / date. >> >> Thanks and regards, >> >> Rajesh.s
>> >> On Mar 19, 11:33 pm, Jean-Baptiste Queru <j...@android.com> wrote: >> >>> I have it working on Dream (starting from ADP1 1.1) but I had to hack >> >>> through the dream and msm7k projects. I'll try to put patches up on >> >>> gerrit so that people can repo download them.
>> >>> JBQ
>> >>> On Thu, Mar 19, 2009 at 4:30 PM, Rajesh S <rajeshs...@gmail.com> wrote:
>> >>> > Tried it out on emulator. Boots, throws a media force close error >> >>> > while unlocking the screen.
>> >>> > Did u try on a real device? Could I expect it to work? Let me try >> >>> > 'building for dream' sequence with this tomorrow.
>> >>> > On Mar 19, 8: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.
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.
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.
-- 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.
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.
> 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.
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 in https://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.
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.
-- 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.
> 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.
> 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.
-- 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.
