Switch from android-2.3.2_r1 to android-2.3.3_r1

[Ade Akinyooye]

Hi,

When I switch branches from 2.3.2 to 2.3.3, and do a repo sync, the
build_id is still GRH78C and the platform version is still 2.3.2, do i
have to change these manually in build_id.mk etc or did I do something
wrong?

Thanks

Ade

[Jean-Baptiste Queru]

There was an issue with the push such that at some point the tag
wasn't pointing to the right commits. This has been fixed. 2.3.3_r1
now correctly points to GRI40. Syncing should take care of things.

JBQ

> --
> You received this message because you are subscribed to the "Android Building" mailing list.
> To post to this group, send email to android-...@googlegroups.com
> To unsubscribe from this group, send email to
> android-buildi...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/android-building?hl=en
>

--
Jean-Baptiste M. "JBQ" Queru
Software Engineer, Android Open-Source Project, 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.

[Magnus Bäck]

On Wednesday, March 02, 2011 at 02:14 CET,
Jean-Baptiste Queru <j...@android.com> wrote:

> There was an issue with the push such that at some point the tag
> wasn't pointing to the right commits. This has been fixed. 2.3.3_r1
> now correctly points to GRI40. Syncing should take care of things.

Syncing does *not* take care of things for users who have already got
the original tag since Git refuses to overwrite existing local tags.
If you know about this it's easy enough to do

repo forall -c 'git tag -d android-2.3.3_r1 && git fetch'

to get back on track again, but reaching all concerned with this
information isn't easy.

--
Magnus B�ck Opinions are my own and do not necessarily
SW Configuration Manager represent the ones of my employer, etc.
Sony Ericsson

[Jean-Baptiste Queru]

Ugh, I didn't know that :(

I didn't see the situation myself since I was on vacation when that
push was done.

Would it make sense to re-tag with a separate tag (e.g. 2.3.3_r1.0)
and update the 2.3.3_r1 manifest to point to the new tag (along with a
new 2.3.3_r1.0 manifest).

JBQ

On Tue, Mar 1, 2011 at 11:35 PM, Magnus Bäck
<magnu...@sonyericsson.com> wrote:
> On Wednesday, March 02, 2011 at 02:14 CET,
>     Jean-Baptiste Queru <j...@android.com> wrote:
>
>> There was an issue with the push such that at some point the tag
>> wasn't pointing to the right commits. This has been fixed. 2.3.3_r1
>> now correctly points to GRI40. Syncing should take care of things.
>
> Syncing does *not* take care of things for users who have already got
> the original tag since Git refuses to overwrite existing local tags.
> If you know about this it's easy enough to do
>
>   repo forall -c 'git tag -d android-2.3.3_r1 && git fetch'
>
> to get back on track again, but reaching all concerned with this
> information isn't easy.
>
> --

> Magnus Bäck                      Opinions are my own and do not necessarily

> SW Configuration Manager         represent the ones of my employer, etc.
> Sony Ericsson
>

[Magnus Bäck]

On Wednesday, March 02, 2011 at 16:56 CET,
Jean-Baptiste Queru <j...@android.com> wrote:

> On Tue, Mar 1, 2011 at 11:35 PM, Magnus B�ck
> <magnu...@sonyericsson.com> wrote:
>
> > Syncing does *not* take care of things for users who have already
> > got the original tag since Git refuses to overwrite existing local
> > tags. If you know about this it's easy enough to do
> >
> > repo forall -c 'git tag -d android-2.3.3_r1 && git fetch'
> >
> > to get back on track again, but reaching all concerned with this
> > information isn't easy.
>

> Ugh, I didn't know that :(
>
> I didn't see the situation myself since I was on vacation when that
> push was done.
>
> Would it make sense to re-tag with a separate tag (e.g. 2.3.3_r1.0)
> and update the 2.3.3_r1 manifest to point to the new tag (along with
> a new 2.3.3_r1.0 manifest).

Perhaps, but the cat is already out of the bag -- there are and will
always be people with a bad tag in their workspaces. Creating a new
tag won't change any of that, but it might reduce the confusion for
newcomers (two seemingly identical tags always raises questions).
Purging the old tag might help with that.

This morning we pushed the updated tag to our server (which had been
polluted with the bad tag from a 3rd party supplier) and sent out
an email to all our developers asking them to delete the old tag
from all their workspaces. That's really all we can do, and we'll
probably think twice before listing refs/tags/android-2.3.3_r1 in
the revision attribute of any internal manifest.

--
Magnus B�ck Opinions are my own and do not necessarily

[Jean-Baptiste Queru]

OK, that makes sense, I'm starting to understand the extent of the
problem. I hadn't realized that it affected every single client and
not just

I'll push a new tag, and make the existing manifest point to the new
tag. It won't "fix" the bad tag, but that tag won't be referenced by
any manifest any more so the remaining badness will be harmless. The
"beauty" is that the manifest is referenced by branch, not by tag, so
we can update it after the fact.

JBQ

On Wed, Mar 2, 2011 at 10:07 AM, Magnus Bäck
<magnu...@sonyericsson.com> wrote:
> On Wednesday, March 02, 2011 at 16:56 CET,
>     Jean-Baptiste Queru <j...@android.com> wrote:
>

>> On Tue, Mar 1, 2011 at 11:35 PM, Magnus Bäck

> Magnus Bäck                      Opinions are my own and do not necessarily

> SW Configuration Manager         represent the ones of my employer, etc.
> Sony Ericsson
>

[Ade Akinyooye]

thanks doing

repo forall -c 'git tag -d android-2.3.3_r1 && git fetch'

repo sync

worked for me

[Magnus Bäck]

On Wednesday, March 02, 2011 at 20:54 CET,
Ade Akinyooye <adeaki...@gmail.com> wrote:

> thanks doing
>
> repo forall -c 'git tag -d android-2.3.3_r1 && git fetch'
> repo sync
>
> worked for me

You don't need both "repo sync" and "git fetch". The former will (unless
you specify the -n option) both download updates from the remote server,
download updates of the manifest itself, update the checked out commit
in each git, and rebase any topic branch that you have checked out.

This can sometimes be more than what you're willing to do, hence my
suggestion of running "git fetch" in each git. That will just download
updates from the server, including a fresh copy of the tag that you just
deleted. Whichever you prefer, just pick one of them.

[Jean-Baptiste Queru]

Also, I've pushed a new tag under a different name, and I've updated
the android-2.3.3_r1 manifest to point to the new tag, so at this
point a plain repo sync is enough.

JBQ

On Wed, Mar 2, 2011 at 2:13 PM, Magnus Bäck
<magnu...@sonyericsson.com> wrote:
> On Wednesday, March 02, 2011 at 20:54 CET,
>     Ade Akinyooye <adeaki...@gmail.com> wrote:
>
>> thanks doing
>>
>>  repo forall -c 'git tag -d android-2.3.3_r1 && git fetch'
>> repo sync
>>
>> worked for me
>
> You don't need both "repo sync" and "git fetch". The former will (unless
> you specify the -n option) both download updates from the remote server,
> download updates of the manifest itself, update the checked out commit
> in each git, and rebase any topic branch that you have checked out.
>
> This can sometimes be more than what you're willing to do, hence my
> suggestion of running "git fetch" in each git. That will just download
> updates from the server, including a fresh copy of the tag that you just
> deleted. Whichever you prefer, just pick one of them.
>
> --

> Magnus Bäck                      Opinions are my own and do not necessarily

> SW Configuration Manager         represent the ones of my employer, etc.
> Sony Ericsson
>

[Josias Junior]

I tried to use the android-2.3.3_r1 repository, however when i tried
to make the source i got this message

make: *** No rule to make target `vendor/samsung/crespo/proprietary/
libpn544_fw.so', needed by `out/target/product/crespo/system/lib/
libpn544_fw.so'. Stop.

and i got similar message during ./extract-files.sh script,

2 KB/s (238 bytes in 0.091s)
remote object '/system/lib/libpn544_fw.so' does not exist
476 KB/s (47564 bytes in 0.097s)
4984 KB/s (1262240 bytes in 0.247s)
209 KB/s (18535 bytes in 0.086s)
83 KB/s (8355 bytes in 0.097s)
220 KB/s (17626 bytes in 0.078s)
27 KB/s (1221 bytes in 0.043s)
1862 KB/s (300352 bytes in 0.157s)
252 KB/s (22830 bytes in 0.088s)
6086 KB/s (2356920 bytes in 0.378s)
5759 KB/s (1993410 bytes in 0.338s)
336 KB/s (34608 bytes in 0.100s)
811 KB/s (97726 bytes in 0.117s)
505 KB/s (54748 bytes in 0.105s)
3719 KB/s (835315 bytes in 0.219s)
1752 KB/s (316933 bytes in 0.176s)
902 KB/s (129056 bytes in 0.139s)
362 KB/s (32085 bytes in 0.086s)
422 KB/s (37994 bytes in 0.087s)
2453 KB/s (420048 bytes in 0.167s)
1032 KB/s (156987 bytes in 0.148s)
2690 KB/s (600838 bytes in 0.218s)
7064 KB/s (2808267 bytes in 0.388s)

where can i get this file?

Best Regards,

Josias Junior

On Mar 2, 7:15 pm, Jean-Baptiste Queru <j...@android.com> wrote:
> Also, I've pushed a new tag under a different name, and I've updated
> the android-2.3.3_r1 manifest to point to the new tag, so at this
> point a plain repo sync is enough.
>
> JBQ
>
> On Wed, Mar 2, 2011 at 2:13 PM, Magnus Bäck
>
>
>
>
>
>
>
>
>
> <magnus.b...@sonyericsson.com> wrote:
> > On Wednesday, March 02, 2011 at 20:54 CET,

[Ade Akinyooye]

What version if your nexus S currently on? If it's not on the official
2.3.3 OTA then that may be why the driver was missing