[ANN] Gerrit upgraded to 2.12.4

[Paul Sokolovsky]

Hello,

The Systems Team is happy to announce that all active Gerrit services:

review.linaro.org
android-review.linaro.org
dev-private-review.linaro.org
lhg-review.linaro.org

have been upgraded to version 2.12.4 (from 2.12.2). This is minor
versions upgrade since 2.12 deployment at the end of April. No major
features or fixes (affecting us) brought by this upgrade, just a
routine upgrade to make sure we stay close to mainline before the
Connect.

Smoke testing over weekend didn't show any problems, but please let us
know if you experience any issues (by replying to this mail privately,
or submitting ticket at
https://servicedesk.linaro.org/servicedesk/customer/portal/4)


-- 
Best Regards,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-dev

[ANN] android-build.linaro.org being decommissioned next week

[Paul Sokolovsky]

Hello,

android-build.linaro.org, the Jenkins CI system dedicated to Android
builds, has been deprecated and all jobs migrated to the central
system, ci.linaro.org about 2 months ago. android-build.linaro.org was
kept online (but largely in Jenkins shutdown mode for last month) to
let interested parties migrate remaining data or as a fallback in case
of issues with ci.linaro.org.

Over last 2 weeks, Systems and B teams made improvements to
ci.linaro.org to improve its capacity and stability under new
increased load, so migration from android-build.linaro.org to
ci.linaro.org can be called complete.

This is the last call to any android-build.linaro.org users who may
still have useful data there - please migrate/download/backup your
data, as next week we plan to stop and delete the EC2 instance running
it.

Please reply privately if you have concerns or need help.


Thanks,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-dev

[ANN] Gerrit 2.12.2 upgrade finished

[Paul Sokolovsky]

Hello,

The planned upgrade to Gerrit 2.12.2 is finished, all active Linaro
servers have been upgraded. There were changes requiring action on
users's side for https://android-review.linaro.org (see previous email
"Regression after android-review.linaro.org upgrade to Gerrit 2.12.2").

There was second issue on https://android-review.linaro.org where a
patch after clicking "Submit" was merged into the repository, but stuck
in conflicting state in the web interface. This is believed to be
caused by reliance on online reindexing introduced in recent Gerrit
versions, which proved to be non-robust by looking at the multiple
exceptions in logs. android-review.linaro.org has been reindexed in
offline mode and patches verified to be processed correctly, and all
following servers were upgraded in this mode.

If you spot any issues, please report them via
https://servicedesk.linaro.org/servicedesk/customer/portal/4


-- 
Best Regards,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-dev

[IMPORTANT] Regression after android-review.linaro.org upgrade to Gerrit 2.12.2

[Paul Sokolovsky]

Hello,

Summary: Your SSH username on https://android-review.linaro.org will
now match Linaro username (first.last) after the next login. You local
repository clones need to be updated for new username.

Detailed description:
https://android-review.linaro.org was the first Gerrit server in
Linaro, when there were no central LDAP user database yet. As a result,
there were free-form SSH usernames used, instead of the later standard
first.last as used on all the other Gerrit servers. This inconsistency
was a subject of background concern for Systems team, but of course not
something having enough priority to "fix". However, Gerrit 2.12.2
upgrade started tonight uncovered following issue: Gerrit tries to
synchronize its SSH username setting with LDAP, and fails, as Gerrits
own rules disallow changing of username. The symptom of this is error
"Authentication temporary unavailable" when a user with "old" SSH
username tries to login via browser.

While this can be classified as a Gerrit bug (and previous versions
were smart enough), we'll unlikely find any timely solution to keep
things as they are. So, it makes sense to take a chance of cleaning up
username and making this server follow standard username conventions.
Consequently:

1. All usernames which don't match "first.last" pattern are reset.
2. If you are affected, you won't be able to perform SSH operations
(like git clone/push) until you login via web interface.
3. On the next login via web interface, it will be set to LDAP's
"first.last" value.
4. You will need to update remotes of your existing git clones to new
username (or alternatively, re-clone).
5. If you already use "first.last" SSH username, you're unaffected.

The list of users affected is given below. While it seems long,
majority of enrties there are for people no longer at Linaro, or
for community accounts (which didn't work since we switched to LDAP
anyway). If you need further assistance, please open a ticket at
https://servicedesk.linaro.org/servicedesk/customer/portal/4 .

Thanks,
Paul


 username:Ng
 username:pfefferz
 username:asac
 username:james_w
 username:fgiff
 username:jserv
 username:mabac
 username:deeptik
 username:cyang
 username:mpoirier
 username:ndec
 username:mwaddel
 username:mansson
 username:Sachin
 username:vishalbhoj
 username:suapapa
 username:fabo
 username:pabhishek
 username:cnxsoft
 username:amitdanielk
 username:patrikryd
 username:sangwook
 username:ericm
 username:pundiramit
 username:glandium
 username:eazyigz
 username:tixy
 username:danilo
 username:john
 username:nytowl
 username:tony_tu
 username:Sangwook
 username:StefanEkenberg
 username:uichi
 username:plars
 username:zyga
 username:ruppi
 username:ebenpor
 username:jhkim
 username:Annamalai
 username:markoncomputer
 username:Claude
 username:tianhongwang
 username:rchand00
 username:omarrmz
 username:aviksil
 username:nvl1109
 username:a0132810
 username:pelya
 username:krtaylor
 username:developer4563
 username:yusufbu
 username:dzinman
 username:arussello
 username:mdupuy
 username:williamcharles
 username:aorth
 username:lanaczko
 username:rmcc
 username:kcrudup
 username:kelvin
 username:angelsl
 username:unixmanlinuxboy
 username:Quiter
 username:sourxsunny
 username:pbeeler
 username:anmar
 username:wucongdonglai
 username:bambi
 username:rperier
 username:sgt
 username:roalex
 username:vishveshwarbhat
 username:therbom
 username:rajagopalvenkat
 username:winner00
 username:ramesh
 username:abelloni
 username:sparksco
 username:fahadkdi
 username:ryanharkin
 username:axelfagerstedt
 username:nocoast
 username:milo
 username:fcarpenter
 username:hongbozhang
 username:fahadk
 username:pelya2
 username:janjic
 username:dpervushin
 username:qoowater
 username:cerial
 username:tinojantony
 username:stephan
 username:kishoreboddu
 username:nuclearmistake
 username:SanjasdfsafsffaySinghsdfasfRawat
 username:donvigo
 username:tinojgit
 username:afarah
 username:mechmetal
 username:akbennett
 username:c
 username:sikuner
 username:wasungkim
 username:stevanr
 username:deqiang
 username:anilkumar
 username:willnewton
 username:codeart
 username:lrabiet
 username:Bintian
 username:bintian
 username:vishalbhoj2
 username:tusharbehera
 username:jbergsag
 username:tgall
 username:amitkhare
 username:neo
 username:paramanands
 username:sumit
 username:danielt
 username:help
 username:XavierHsu
 username:Serban
 username:Z
 username:koenkooi
(127 rows)



-- 
Best Regards,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-dev

[ANN] Upcoming Gerrit 2.12 upgrade

[Paul Sokolovsky]

Hello,

4 months have passed since the previous Gerrit upgrade (see below for
reference), when Systems team had wanted to upgrade directly to 2.12,
but due to last-minute issues discovered in it, upgraded to 2.11.5
instead. Gerrit is at 2.12.2 now, with many issues fixed and it being
quite stable now. We also have stakeholders waiting for 2.12
functionality any day now.

So, Systems team plan to upgrade the following systems:

review.linaro.org
android-review.linaro.org
dev-private-review.linaro.org
lhg-review.linaro.org

starting end of day Friday, April 29th and throughout Saturday April
30th.

Let us know if you have questions or concerns (for example, if you need
uninterrupted Gerrit access until end of the US day on April 29).


Thanks,
Paul


Begin forwarded message:

Date: Mon, 14 Dec 2015 19:01:46 +0200
From: Paul Sokolovsky <paul.sokolov...@linaro.org>
To: linaro-dev <linaro-dev@lists.linaro.org>, linaro-android
<linaro-andr...@lists.linaro.org>, "syst...@linaro.org"
<syst...@linaro.org> Subject: [ANN] Planning next Gerrit upgrade


Hello,

We upgraded from Gerrit 2.8 to 2.10 in the beginning of September, and
it went pretty smooth and let us overcome few annoying issues and enjoy
few new features and better integration with other apps.

Unfortunately, 3 months later, 2.10 also feels old, with 2.12 having
been released in the interim. With various Linaro groups continuing to
leverage advanced Gerrit features and integrations with other apps
(Jenkins, Bugzilla), Systems team faces various bugs and issues. None
of these issues are too grave, but they're quite convoluted and take
much time to be researched and understood. And then we find out that
it's a known issue in 2.10, which was fixed in later versions.

Jenkins' Gerrit integration already requires 2.12 for full
functionality and warns about our version being too old and some
features not supported. Which in turns brings concerns that every
time it doesn't work as expected, it may be because Gerrit plugin is
no longer tested with 2.10 and hits some issue pertaining to it.

With that in mind, Systems team would like to start planning for
next Gerrit upgrade, and move straight to the latest, 2.12.

To remind, the reason we didn't upgrade to 2.11 last time, was because
2.10 was the last version which included old-style change review
screen, and we wanted to provide smoother transition and let people to
try the new screen at their own pace. So, if you still use the old
design, please go to https://review.linaro.org/#/settings/preferences ,
and in "Change View:" dropdown, select "New Screen", and give it a
chance with the help of this doc:
https://review.linaro.org/Documentation/user-review-ui.html

And if you have any concerns regarding the upgrade, please speak up now.

Otherwise, we can do it in one of the following timeframes:

1. Upgrade in January.
2. Upgrade a bit later, but still before the Connect.
3. Discuss and plan upgrade at the Connect.

Systems team votes for the choice 1, upgrade next month (apparently, by
the end of), as that will allows us to deliver smoother Gerrit
experience to other teams, instead of firefighting older version issues.


Thanks,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog


-- 
Best Regards,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-dev

[ANN] Gerrit upgraded to 2.11.5

[Paul Sokolovsky]

Hello,

All Linaro Gerrit servers have been upgraded to Gerrit 2.11.5 in
planned manner. As was announced previously, we intended to upgrade
directly to the latest 2.12, but literally couple of dates before
upgrade we found out that there's known issue which affects replication
services and thus our Git HA infrastructure. The bug has bean fixed by
now in the Gerrit master, but the date of 2.12.1 release wasn't yet
announced. As the aim of the current upgrade was to get on newer
Gerrit version than now-old 2.10, we decided to upgrade to 2.11.5
in the meantime, and revisit upgrade to 2.12 after bug fix releases.

Upgrade services appear to work stable based based on weekend
monitoring, ditto for CI loops integrating with Gerrit.

If you spot any issues, please provide details in a direct reply
(not "Reply All") to this mail.

One of the most user-facing changes in 2.11 is dropping support for
"old" change screen UI design. About 20 people of (hundreds) in Linaro
used the old design, and they were notified beforehand of the upgrade.

You can read about changes and new features in 2.11 at
https://gerrit-documentation.storage.googleapis.com/ReleaseNotes/ReleaseNotes-2.11.html

As a sneak peek:

* Yet in 2.10, there was introduced feature of editing a commit
message in the Web UI. That's convenient if you e.g. spotted a typo in
colleague's commit message - you don't need describe him/her an issue
and make them rebase a change via command line, but can fix it on spot
in the browser (subject to ACLs).

* 2.11 brings this idea forward and allows to create entire patchsets
via web browser, or post follow-up changes changes in the same way. It
yet to be seen how useful this functionality is (in github, which has
similar functionality, it's actually useful - if you e.g. read a README
and spot a typo, you can submit a pull request with the fix on spot).



Happy code reviewing from Systems Team!


-- 
Best Regards,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-dev

Re: Linaro Jenkins build system newbie

[Paul Sokolovsky]

Hello,

On Wed, 27 Jan 2016 14:30:08 +0200
Fathi Boudra  wrote:

> > I am wondering do/can I run Jenkins on a local machine for a single
> > platform or do I submit a .yaml build script. If I can run it
> > locally then can I run it on Debain rather than Ubuntu ?
> 
> You can run Jenkins on a local machine. The build jobs described with
> a yaml file using jenkins-job-builder isn't strictly required. Also,
> you can run it on Debian.

I guess it's worth adding that Jenkins is a separate open-source
project, headquartered at http://jenkins-ci.org/ . From there, you can
find documentation, mailing list(s), bug and patch tracker, etc. - we
use all that ourselves when we have questions about Jenkins.
jenkins-job-builder is also a separate project, part of the bigger
OpenStack project, with its own documentation, etc.:
http://docs.openstack.org/infra/jenkins-job-builder/

[]

-- 
Best Regards,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-dev

[ANN] Planning next Gerrit upgrade

[Paul Sokolovsky]

Hello,

We upgraded from Gerrit 2.8 to 2.10 in the beginning of September, and
it went pretty smooth and let us overcome few annoying issues and enjoy
few new features and better integration with other apps.

Unfortunately, 3 months later, 2.10 also feels old, with 2.12 having
been released in the interim. With various Linaro groups continuing to
leverage advanced Gerrit features and integrations with other apps
(Jenkins, Bugzilla), Systems team faces various bugs and issues. None
of these issues are too grave, but they're quite convoluted and take
much time to be researched and understood. And then we find out that
it's a known issue in 2.10, which was fixed in later versions.

Jenkins' Gerrit integration already requires 2.12 for full
functionality and warns about our version being too old and some
features not supported. Which in turns brings concerns that every
time it doesn't work as expected, it may be because Gerrit plugin is
no longer tested with 2.10 and hits some issue pertaining to it.

With that in mind, Systems team would like to start planning for
next Gerrit upgrade, and move straight to the latest, 2.12.

To remind, the reason we didn't upgrade to 2.11 last time, was because
2.10 was the last version which included old-style change review
screen, and we wanted to provide smoother transition and let people to
try the new screen at their own pace. So, if you still use the old
design, please go to https://review.linaro.org/#/settings/preferences ,
and in "Change View:" dropdown, select "New Screen", and give it a
chance with the help of this doc:
https://review.linaro.org/Documentation/user-review-ui.html

And if you have any concerns regarding the upgrade, please speak up now.

Otherwise, we can do it in one of the following timeframes:

1. Upgrade in January.
2. Upgrade a bit later, but still before the Connect.
3. Discuss and plan upgrade at the Connect.

Systems team votes for the choice 1, upgrade next month (apparently, by
the end of), as that will allows us to deliver smoother Gerrit
experience to other teams, instead of firefighting older version issues.


Thanks,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-dev

Re: [ANN] Round 2 (and 3) of Gerrit upgrade

[Paul Sokolovsky]

Hello,

System team is glad to announce that Gerrit was upgraded on the
following servers:

review.linaro.org
projectara-review.linaro.org
lhg-review.linaro.org

, which means that all our server base consistently runs Gerrit 2.10.6.

There are no new known issues beyond those discussed in previous mails,
to remind:

1. There's new change summary screen in Gerrit 2.10.6 by default, but
please watch a yellow pop-up at the top of the screen to get more info
about it or revert to old screen if you really like to.

2. All review are in "Merge Conflict" state after upgrade, but pressing
"Rebase" button in UI, or in rare cases, rebasing via git command line,
will fix it.


Thanks, and let Systems team know of issues you've seen.



On Sun, 30 Aug 2015 13:42:28 +0300
Paul Sokolovsky <paul.sokolov...@linaro.org> wrote:

> Hello,
> 
> https://dev-private-review.linaro.org/ has been upgraded to Gerrit
> 2.10.6. Upgrade went smooth, the only issue is that handful open
> reviews there are now in "Merge Conflict" state, as discussed below.
> However, I tried to merge a test review with such status and it went
> OK. If that won't work, a change need to be rebased and re-pushed from
> command line.
> 
> To remind, the biggest change in 2.10.x is a new change summary
> screen. Every user will be notified about it via popup on first
> access, linking to detailed documentation:
> https://dev-private-review.linaro.org/Documentation/user-review-ui.html
> and offering choice to switch back to classic screen (support for
> which is dropped in 2.11, so use your judgement when you want to
> learn the new screen - now or later).
> 
> 
> Please let me know of any issues seen. If nothing big pops up, we'll
> finish 2.10.6 migration next weekend, upgrading
> https://review.linaro.org and https://lhg-review.linaro.org as
> discussed below.
> 
> 
> Thanks,
> Paul
> 
> On Fri, 21 Aug 2015 16:25:58 +0300
> Paul Sokolovsky <paul.sokolov...@linaro.org> wrote:
> 
> > Hello,
> > 
> > As was announced previously, Linaro Systems team is working to
> > upgrade Gerrit version used on our hosts from 1-year old 2.8 to
> > recent and supported 2.10. Two weeks ago, we upgraded
> > https://android-review.linaro.org as a pilot. The upgrade went
> > largely OK, though as full disclosure, following issues were faced:
> > 
> > 1. Upgrade uncovered issues with duplicate accounts. This issue is
> > mostly specific to android-review.linaro.org - it's the oldest
> > Gerrit system in Linaro which accumulated number of accounts from
> > different authentication services we used as well as community
> > accounts. Other systems are unlikely to be affected at all, and
> > even on android-review.linaro.org only few active users were
> > affected and issues were resolved proactively.
> > 
> > 2. 2.10 exposed an AJAX caching issues we experienced intermittently
> > before - just to allow to nail them down and resolve consistently
> > for all servers. So, this is off the list.
> > 
> > 3. The "biggest" issue we saw is that after the upgrade, all pending
> > open changes in Gerrit were changed to "Merge Conflict" state,
> > which was not resolvable from UI, with Gerrit suggesting to rebase
> > and re-push change from command line. Having done that, a reviewed
> > worked without a problem. We even received a report that this issue
> > may be related to the new review UI, switching to old screen
> > allowed to rebase a change via UI button.
> > 
> > 
> > With this in mind, we think we're ready for the next round of
> > upgrade. Based on previous discussions, this would be
> > https://dev-private-review.linaro.org , slated to upgrade next
> > weekend. We'd like to confirm that this plan works well for them.
> > 
> > Otherwise, we'd plan to finish Gerrit upgrade (and do any needed
> > follow-up tweaks) before Connect, so there was productive work there
> > (and we can consult people on new UI/features they may want to use).
> > So, if everything goes smooth with dev-private-review.linaro.org, a
> > weekend after next (Sep, 5) we'd plan to upgrade 2 remaining
> > systems: https://review.linaro.org and
> > https://lhg-review.linaro.org . Again, we'd like to be sure that
> > their stakeholders are OK with this.
> > 
> > 
> > 
> > Thanks,
> > Paul
> > 
> > Linaro.org | Open source software for ARM SoCs
> > Follow Linaro: http://www.facebook.com/pages/Linaro
> > http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog
> 
> 
> 



-- 
Best Regards,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-dev

Re: [ANN] Round 2 (and 3) of Gerrit upgrade

[Paul Sokolovsky]

Hello,

https://dev-private-review.linaro.org/ has been upgraded to Gerrit
2.10.6. Upgrade went smooth, the only issue is that handful open
reviews there are now in Merge Conflict state, as discussed below.
However, I tried to merge a test review with such status and it went
OK. If that won't work, a change need to be rebased and re-pushed from
command line.

To remind, the biggest change in 2.10.x is a new change summary screen.
Every user will be notified about it via popup on first access, linking
to detailed documentation:
https://dev-private-review.linaro.org/Documentation/user-review-ui.html
and offering choice to switch back to classic screen (support for which
is dropped in 2.11, so use your judgement when you want to learn the
new screen - now or later).


Please let me know of any issues seen. If nothing big pops up, we'll
finish 2.10.6 migration next weekend, upgrading https://review.linaro.org
and https://lhg-review.linaro.org as discussed below.


Thanks,
Paul

On Fri, 21 Aug 2015 16:25:58 +0300
Paul Sokolovsky paul.sokolov...@linaro.org wrote:

 Hello,
 
 As was announced previously, Linaro Systems team is working to upgrade
 Gerrit version used on our hosts from 1-year old 2.8 to recent and
 supported 2.10. Two weeks ago, we upgraded
 https://android-review.linaro.org as a pilot. The upgrade went largely
 OK, though as full disclosure, following issues were faced:
 
 1. Upgrade uncovered issues with duplicate accounts. This issue is
 mostly specific to android-review.linaro.org - it's the oldest Gerrit
 system in Linaro which accumulated number of accounts from different
 authentication services we used as well as community accounts. Other
 systems are unlikely to be affected at all, and even on
 android-review.linaro.org only few active users were affected and
 issues were resolved proactively.
 
 2. 2.10 exposed an AJAX caching issues we experienced intermittently
 before - just to allow to nail them down and resolve consistently for
 all servers. So, this is off the list.
 
 3. The biggest issue we saw is that after the upgrade, all pending
 open changes in Gerrit were changed to Merge Conflict state,
 which was not resolvable from UI, with Gerrit suggesting to rebase and
 re-push change from command line. Having done that, a reviewed worked
 without a problem. We even received a report that this issue may be
 related to the new review UI, switching to old screen allowed to
 rebase a change via UI button.
 
 
 With this in mind, we think we're ready for the next round of upgrade.
 Based on previous discussions, this would be
 https://dev-private-review.linaro.org , slated to upgrade next
 weekend. We'd like to confirm that this plan works well for them.
 
 Otherwise, we'd plan to finish Gerrit upgrade (and do any needed
 follow-up tweaks) before Connect, so there was productive work there
 (and we can consult people on new UI/features they may want to use).
 So, if everything goes smooth with dev-private-review.linaro.org, a
 weekend after next (Sep, 5) we'd plan to upgrade 2 remaining systems:
 https://review.linaro.org and https://lhg-review.linaro.org . Again,
 we'd like to be sure that their stakeholders are OK with this.
 
 
 
 Thanks,
 Paul
 
 Linaro.org | Open source software for ARM SoCs
 Follow Linaro: http://www.facebook.com/pages/Linaro
 http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog



-- 
Best Regards,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-dev

[ANN] Round 2 (and 3) of Gerrit upgrade

[Paul Sokolovsky]

Hello,

As was announced previously, Linaro Systems team is working to upgrade
Gerrit version used on our hosts from 1-year old 2.8 to recent and
supported 2.10. Two weeks ago, we upgraded
https://android-review.linaro.org as a pilot. The upgrade went largely
OK, though as full disclosure, following issues were faced:

1. Upgrade uncovered issues with duplicate accounts. This issue is
mostly specific to android-review.linaro.org - it's the oldest Gerrit
system in Linaro which accumulated number of accounts from different
authentication services we used as well as community accounts. Other
systems are unlikely to be affected at all, and even on
android-review.linaro.org only few active users were affected and
issues were resolved proactively.

2. 2.10 exposed an AJAX caching issues we experienced intermittently
before - just to allow to nail them down and resolve consistently for
all servers. So, this is off the list.

3. The biggest issue we saw is that after the upgrade, all pending
open changes in Gerrit were changed to Merge Conflict state,
which was not resolvable from UI, with Gerrit suggesting to rebase and
re-push change from command line. Having done that, a reviewed worked
without a problem. We even received a report that this issue may be
related to the new review UI, switching to old screen allowed to rebase
a change via UI button.


With this in mind, we think we're ready for the next round of upgrade.
Based on previous discussions, this would be
https://dev-private-review.linaro.org , slated to upgrade next weekend.
We'd like to confirm that this plan works well for them.

Otherwise, we'd plan to finish Gerrit upgrade (and do any needed
follow-up tweaks) before Connect, so there was productive work there
(and we can consult people on new UI/features they may want to use).
So, if everything goes smooth with dev-private-review.linaro.org, a
weekend after next (Sep, 5) we'd plan to upgrade 2 remaining systems:
https://review.linaro.org and https://lhg-review.linaro.org . Again,
we'd like to be sure that their stakeholders are OK with this.



Thanks,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-dev

RFC: Gerrit version upgrade on Linaro hosts

[Paul Sokolovsky]

Hello,

All Linaro Gerrit services (4 of them) currently run Gerrit 2.8.6.1,
the latest of 2.8 branch, which is now 1 year old, and 3 major releases
behind the latest, 2.11.

We (Systems) regularly get requests regarding features available in
newer Gerrit versions, and regularly face issues, which are not even
reportable upstream, as we run a pretty old version.

With all the improvements we did to Gerrit management across different
installs lately, we're now ready to raise the question of the version
upgrade. Here're basic facts about recent Gerrit versions:

1. Major change in 2.9 is introduction of new change summary screen.
It's pretty different by both looks and feel and it's fair to say taht
one needs to relearn Gerrit a bit with its introduction. It's still
possible to use old screen, until it's removed in further versions.

2. 2.11 does remove support for old change summary screen.

3. 2.10 and 2.11 are actively supported and maintained (e.g. 2.10.6
released Jun 29, 2.11.2 - Jul, 14).

Based on this, we would like to propose upgrade to 2.10, to let people
some leeway to learn the new change screen, and be able to switch back
to the old screen in the meantime.

As usual, we'd like to select single server for pilot upgrade first,
and among 4 we have, Linaro Android Gerrit,
https://android-review.linaro.org seems like a good candidate, as it's
used just by subset of Linaro teams, and at the same time, used
regularly to call it tested after the pilot period.


Things you can do/help with in the meantime:

1. Provide feedback on the general idea of the upgrade.
2. Let us know if you'd like a server you regularly use to be upgraded
sooner rather than later. We in particular would like to know whether
Android Team (and other stakeholders) agree to pilot new version on 
https://android-review.linaro.org
3. Get feedback from any stakeholders which may be affected, first of
all, from BuildsBaselines, who run CI with Gerrit integration.
4. Get acquainted with new change screen extramurally, by reviewing
documentation with extensive screenshots:
https://gerrit-documentation.storage.googleapis.com/Documentation/2.9/user-review-ui.html



Thanks,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-dev

Login changes for review.linaro.org

[Paul Sokolovsky]

Hello,

If you don't use Gerrit review services of https://review.linaro.org
you can stop reading now.

Over this weekend, Systems team reconfigured login mechanism of
https://review.linaro.org to be based on LDAP authentication instead of
previously used OpenID authentication.

The only expected user-visible change is that now there will be native
Gerrit login page (https://review.linaro.org/login/q/status:open,n,z)
instead of redirection to https://crowd.linaro.org/... . So, please
don't be alerted, this is expected change. Login credentials otherwise
stay the same - Linaro email address and standard Linaro password. If
you find that you're still logged in to Gerrit on Monday, you're
recommended to log out and log in again via new methods.

The reason for this change is that unfortunately Gerrit ties generic
LDAP integration (e.g. being able to use LDAP groups) to LDAP-backed
authentication method. We had this enabled on few project-specific
instances, and as stakeholders elaborated Gerrit usage, we started to
get requests to set up more advanced workflows for the public instance
too. Unfortunately, with OpenID-based auth, we couldn't set up Gerrit
groups based on existing centrally managed LDAP groups, so the only
choice was to duplicate user lists which is error-prone and doesn't
scale. The change above fixes that, and it's expected that we'll follow
with the similar change on another public instance,
http://review.android.git.linaro.org/ .


We tried our best to make the migration seamless, but if you experience
or spot any issues, please let us know - either by directly replying to
this mail, pinging #linaro-systems channel or submitting ITS request
via i...@linaro.org (the latter is standard, preferred method, but feel
free to use other for possibly quicker turnaround). You are recommended
to check your Gerrit group membership after logging in via new method,
by visiting page
https://review.linaro.org/#/settings/group-memberships . If you see
that any groups you used to have are missing, let us know immediately. 


Thanks,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-dev

[ANN] New private Git/Gerrit service available

[Paul Sokolovsky]

Hello,

Linaro Systems and ITS teams are glad to announce general availability
of new generation of Private Git/Gerrit service. This service is the
successor of https://linaro-private.git.linaro.org/ , older Git-only
private service, and is based on underlying solutions which proved
themselves well on public Linaro Git services, specifically:

1. https://dev-private-git.linaro.org offers Gitweb browser and
Gitolite git self-management service.
2. https://dev-private-review.linaro.org adds change review
capabilities for private projects using Gerrit.

During the initial pilot period with couple of Linaro teams,
requirements for secure private hosting were determined. It is based on
providing each team a separate project area (identified by project path
prefix), access control to which is governed by a specific LDAP group.
Each project area is completely independent and not accessible to any
other group.

To start using the new private service, a manager of interested team
should prepare and provide project prefix and LDAP group name, as
explained above, and submit an ITS ticket in a usual way. More details
of the initial setup, usage, and constraints of the service are
available at
https://wiki.linaro.org/Internal/Platform/Systems/GitPrivate 

We welcome teams interested in private Git hosting to take benefit of
the new service, as well as teams which use older server at
https://linaro-private.git.linaro.org/ to migrate to the new one.

-- 
Best Regards,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

[ANN] Small git service updates

[Paul Sokolovsky]

Hello,

Systems team recently made some cleanups and elaborations to Linaro git
services, information about which we'd like to share here. None of
these changes require immediate changes on your side (compatibility
with old usage ways is kept), but we'd like to draw some attention to
them anyway, as they should make life a bit easier, especially for
newstarters, so it would be nice if people were aware of them and not
pass old information around.

1. To access gitolite push services, git user is now used
consistently across various hosts. (Previously, it was git for the
main server, git.linaro.org, but various other names on team- and
project-specific servers). Old names are kept for compatibility, but
you will see git@ in gitweb, and that's the preferred way to pass
links to other people.

2. Our initial instructions for git services included steps of update
user's SSH config in ~/.ssh/config. Based on the experience, we found
that lead to confusion and surprises (for example, if you switched
workstation or resetup one from scratch). So, this usage is
deprecated now - instead, SSH repo URLs should contain explicit
username (git@, per above). Instructions were updated
correspondingly. You can keep using your existing SSH config and
cloned repos, just please pass fully specified clone URLs to other
people. 


Summing up:

You can look up authoritative access URLs for a repo in gitweb. E.g.:
https://git.linaro.org/boot/u-boot-linaro-next.git . If you need to
pass git clone info to other people, please use what's written
there (giving gitweb URL is probably the easiest).

You don't need to change anything on your side.


-- 
Best Regards,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

[ANN] Reminder about recommended Linaro git access procedure

[Paul Sokolovsky]

Hello,

Recently, we had DoS-like episodes on the main Linaro git server,
http://git.linaro.org , which affected number of Linaro users,
including users of Gerrit system, http://review.linaro.org .

These episodes were related to unfriendly usage of native protocol,
git:// (service port 9418). The implementation of this protocol is known
to be resource-hungry and not scale to many connections and users. The
issue itself is not new, it is something which affected us in waves
over last 3 years, and a resolution for which was established a year
ago, providing 2 HTTP-based protocols (so called dump and smart
protocols) as more scalable replacement.

So, this is a gentle reminder that use of git:// protocol by is
discouraged for Linaro engineers, and completely unsupported(*1) for
third parties. Based on the analysis and outcome of the current
DoS-like activity, we may need to make git:// access more limited and
strict. So, please kindly:

1. Check URLs you use for cloning and updating your local trees. If you
use ssh:// or http(s):// protocols, you're ok. If you use git://,
please switch to using http-based protocol instead. In most cases, this
requires just replacing git:// schema with http://;. If in doubt,
please visit gitweb page for your repositories, which lists all
supported URLS to clone a repository, e.g.:
https://git.linaro.org/arm/arm-trusted-firmware.git

2. If you set up of oversee CI or automated build jobs, please
audit and apply similar changes to them.


Thanks,
Paul, on behalf of Linaro Systems Team and ITS


(*1) Unsupported in the current context means that git:// URLs are
not published in up-to-date information, and there's no warranty that
any 3rd party will be able to complete a clone successfully using this
protocol.

 
Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: [ANN] Reminder about recommended Linaro git access procedure

[Paul Sokolovsky]

Hello John,

On Thu, 28 Aug 2014 10:28:06 -0700
John Stultz john.stu...@linaro.org wrote:

 On Thu, Aug 28, 2014 at 10:05 AM, Paul Sokolovsky
 paul.sokolov...@linaro.org wrote:
  Recently, we had DoS-like episodes on the main Linaro git server,
  http://git.linaro.org , which affected number of Linaro users,
  including users of Gerrit system, http://review.linaro.org .
 
  These episodes were related to unfriendly usage of native protocol,
  git:// (service port 9418). The implementation of this protocol is
  known to be resource-hungry and not scale to many connections and
  users. The issue itself is not new, it is something which affected
  us in waves over last 3 years, and a resolution for which was
  established a year ago, providing 2 HTTP-based protocols (so called
  dump and smart protocols) as more scalable replacement.
 
  So, this is a gentle reminder that use of git:// protocol by is
  discouraged for Linaro engineers, and completely unsupported(*1) for
  third parties. Based on the analysis and outcome of the current
  DoS-like activity, we may need to make git:// access more limited
  and strict. So, please kindly:
 
 
 So why does this affect us but not kernel.org?

Regarding kernel.org, Milo Casagrande did some correspondence with them
and can share specific details. IIRC, they use some custom
infrastructure.

  1. Check URLs you use for cloning and updating your local trees. If
  you use ssh:// or http(s):// protocols, you're ok. If you use
  git://, please switch to using http-based protocol instead. In most
  cases, this requires just replacing git:// schema with http://;.
  If in doubt, please visit gitweb page for your repositories, which
  lists all supported URLS to clone a repository, e.g.:
  https://git.linaro.org/arm/arm-trusted-firmware.git
 
  2. If you set up of oversee CI or automated build jobs, please
  audit and apply similar changes to them.
 
 So this is problematic, because there are folks out there in the
 community who already use the git:// urls for fetching work from the
 Linaro repos. (The 0day build/test bot, for instance..).

So, it would be nice if they updated to use http://. We actually can be
proactive and contact them regarding this change (we could use your
help with that, or just with compiling list of parties who should
be contacted).

 While the git:// urls are now off the gitweb (which is good for future
 users), this wasn't the case previously.
 
 We already went through one painful transition where our URLs got
 scrambled, and I've had a few situations where folks have just
 recently realized that we still had trees, but the URLs were just
 different. So its quite frustrating to have to go through that again.

I'm not sure which transition you mean, but the matter of deprecating
git:// and switching to http:// indeed comes not the first time. And
previous time there were conservative (or skeptic) responses too, which
made transition be far complete, and now we need to approach the
same matter again, instead of having done it once and for all.

But otherwise, the world is dynamic place and changes all the time. For
example, in the summer 2011 aforementioned kernel.org was down for
unbelievable 1.5 months, and what, people coped. But we're not going to
do it like kernel.org and go down, but instead going to start as
seamless as possible transition (I hope you didn't get any other idea
from this mail). Just for that, we need some help of the users, first
of all, internal users, as about their access and its stability we care
the most.

 
 What would be required to just make the git:// urls work properly?

There can be different technical and organizational answers to this
question, but the most productive I can give is: Systems and ITS will be
working towards that; in the meantime, all parties which would like
a sustainable service are encouraged to upgrade to http:// protocol.

 Is this mainly an issue with the Android repos? 

It used to be. It was a big problem in that summer 2011, when with
kernel.org down, AOSP tree went down too and after couple of weeks
people rushed to fetch from us. But this time, it affected
git.linaro.org straight.

 If we reduce the
 git:// url load on the wort users, would that improve things enough?
 Do you have stats on which trees are hardest hit?

The case we have with git:// is that small number of users can hog
almost all resources of a server. This can happen at release time and
block work of Linaro engineers, something like that happened this time.
So, we're working on technical means to avoid hogging all resources,
but we also would like to be sure that we won't affect internal users,
and the most productive way for that is them to use a scalable protocol.


  (*1) Unsupported in the current context means that git:// URLs are
  not published in up-to-date information, and there's no warranty
  that any 3rd party will be able to complete a clone successfully
  using this protocol.
 
 So as someone who has sent git

Re: [ANN] Planned maintenance for ci.linaro.org, Friday 6th June

[Paul Sokolovsky]

Hello,

New ci.linaro.org is now online and most services are working as
expected. It is still in post-migration test mode, so please free to
use it and report any issues you see by replying to this mail (please
do not use Reply All), or on IRC to pfalcon or fabo. The server
so far has self-signed certificate to remind of its current status.

Thanks,
Paul



On Fri, 6 Jun 2014 12:59:26 +0300
Paul Sokolovsky paul.sokolov...@linaro.org wrote:

 Hello,
 
 Per previous announcement, ci.linaro.org goes down for maintenance
 today, 12:00pm UTC, until Monday.
 
 Please reply to this mail, or ping pfalcon on IRC, if you have
 requests/concerns.
 
 Thanks,
 Paul
 
 
 
 Begin forwarded message:
 
 Date: Tue, 3 Jun 2014 22:14:04 +0200
 From: Milo Casagrande milo.casagra...@linaro.org
 To: Linaro Development Mailing List linaro-dev@lists.linaro.org
 Subject: Planned maintenance for ci.linaro.org, Friday 6th June
 
 
 Hello,
 
 this email is to announce that ci.linaro.org will not be available on
 Friday 6th June due to planned maintenance.
 We will perform a server upgrade to the latest Ubuntu LTS release.
 
 In order to perform a smooth upgrade, please make any update to your
 jobs before Thursday 5th June at 12:00UTC.
 Another email will be sent out when the service has been restored.
 
 Regards.
 



-- 
Best Regards,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: [ANN] Planned maintenance for ci.linaro.org, Friday 6th June

[Paul Sokolovsky]

Hello,

We further validated and debugged some aspects of new ci.linaro.org, it
now should be consider back to normal production mode (production SSL
certificate installed too). We still debug smaller issues, and take a
chance to do refactorings and cleanups which waited for this migration,
so if your build is affected, or you see unexpected behavior, please
let me or Fathi know.

Thanks,
Paul



On Mon, 9 Jun 2014 11:56:26 +0300
Paul Sokolovsky paul.sokolov...@linaro.org wrote:

 Hello,
 
 New ci.linaro.org is now online and most services are working as
 expected. It is still in post-migration test mode, so please free to
 use it and report any issues you see by replying to this mail (please
 do not use Reply All), or on IRC to pfalcon or fabo. The server
 so far has self-signed certificate to remind of its current status.
 
 Thanks,
 Paul
 
 
 
 On Fri, 6 Jun 2014 12:59:26 +0300
 Paul Sokolovsky paul.sokolov...@linaro.org wrote:
 
  Hello,
  
  Per previous announcement, ci.linaro.org goes down for maintenance
  today, 12:00pm UTC, until Monday.
  
  Please reply to this mail, or ping pfalcon on IRC, if you have
  requests/concerns.
  
  Thanks,
  Paul
  
  
  
  Begin forwarded message:
  
  Date: Tue, 3 Jun 2014 22:14:04 +0200
  From: Milo Casagrande milo.casagra...@linaro.org
  To: Linaro Development Mailing List linaro-dev@lists.linaro.org
  Subject: Planned maintenance for ci.linaro.org, Friday 6th June
  
  
  Hello,
  
  this email is to announce that ci.linaro.org will not be available
  on Friday 6th June due to planned maintenance.
  We will perform a server upgrade to the latest Ubuntu LTS release.
  
  In order to perform a smooth upgrade, please make any update to your
  jobs before Thursday 5th June at 12:00UTC.
  Another email will be sent out when the service has been restored.
  
  Regards.
  
 
 
 



-- 
Best Regards,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

[ANN] Planned maintenance for ci.linaro.org, Friday 6th June

[Paul Sokolovsky]

Hello,

Per previous announcement, ci.linaro.org goes down for maintenance
today, 12:00pm UTC, until Monday.

Please reply to this mail, or ping pfalcon on IRC, if you have
requests/concerns.

Thanks,
Paul



Begin forwarded message:

Date: Tue, 3 Jun 2014 22:14:04 +0200
From: Milo Casagrande milo.casagra...@linaro.org
To: Linaro Development Mailing List linaro-dev@lists.linaro.org
Subject: Planned maintenance for ci.linaro.org, Friday 6th June


Hello,

this email is to announce that ci.linaro.org will not be available on
Friday 6th June due to planned maintenance.
We will perform a server upgrade to the latest Ubuntu LTS release.

In order to perform a smooth upgrade, please make any update to your
jobs before Thursday 5th June at 12:00UTC.
Another email will be sent out when the service has been restored.

Regards.

-- 
Milo Casagrande
Linaro.org www.linaro.org │ Open source software for ARM SoCs

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev


-- 
Best Regards,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: [ANN] lci-build-tools (aka lp:linaro-ci) migrated to git

[Paul Sokolovsky]

Hello,

Per the plan outlined above, bzr repository lp:linaro-ci was shutdown
today. Few test builds on ci.linaro.org showed some breakage, that's
being looked into (for example, linux-lng was broken and quickly fixed),
so please reply to this mail/ping me on IRC (pfalcon) if you need help
with this upgrade, and I'll be approaching owners of broken jobs too.

Thanks,
Paul


On Fri, 14 Mar 2014 08:29:45 +0200
Paul Sokolovsky paul.sokolov...@linaro.org wrote:

 Hello,
 
 As final steps of migrating infrastructure/CI projects from bzr to
 git, lci-build-tools repository (having a shortcut of lp:linaro-ci)
 was migrated to https://git.linaro.org/ci/lci-build-tools.git . All
 jobs directly referencing it on https://ci.linaro.org were already
 updated. However, according to Fathi, there may be wrapper build
 scripts, hosted elsewhere, which may fetch lci-build-tools on their
 own. So, if you use/maintain such script, please update it to use
 git. It should be something like replacing:
 
 bzr branch lp:linaro-ci lci-build-tools
 
 with:
 
 git clone https://git.linaro.org/ci/lci-build-tools.git
 
 
 Please kindly update your scripts during next week. On March 21, bzr
 repository will be shutdown, in an effort to formally finish
 the migration, catch last usages of the old repository, and avoid
 future confusion.
 
 Let us know if you have concerns with the plan above.
 
 Thanks,
 Linaro Infrastructure team
 
 Linaro.org | Open source software for ARM SoCs
 Follow Linaro: http://www.facebook.com/pages/Linaro
 http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog



-- 
Best Regards,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: [ANN] android-build.linaro.org upgrade to Linaro Login Service - complete

[Paul Sokolovsky]

Hello Bero,

On Sat, 29 Jun 2013 12:32:05 +0200
Bernhard Rosenkränzer bernhard.rosenkran...@linaro.org wrote:

 Hi,
 this breaks things badly for me: The login form is limited to 30
 characters, but bernhard.rosenkran...@linaro.org is 32.
 Even after injecting
 document.getElementById(id_username).maxLength=35 into the login
 page with a JS debugger, the login fails (probably because the 30
 character limit is not just imposed by the form at random -
 username/permission mappings stored in a sql field limited to 30
 chars?) (Yes, the proper fix would be getting me a shorter name ;) I
 don't have the right permissions to do that though ;) )

Sorry about this, Django's default username length is indeed too
restrictive. I updated it and verified that both DB and form now has
bigger limit (255). Can you please verify it works ok for you?

(Tracked as 
https://bugs.launchpad.net/linaro-android-infrastructure/+bug/1196514 )

 
 ttyl
 bero
 
 
 
 On 27 June 2013 19:35, Paul Sokolovsky paul.sokolov...@linaro.org
 wrote:
 
  Hello,
 
  After couple of iterations, android-build.linaro.org was updated to
  authenticate against Linaro Login system. Please use your
  login.linaro.org username (with @linaro.org suffix) and password to
  login from now on. Personal jobs were also renamed to have
  firstname.lastname prefix instead of Launchpad username. If you
  cannot see your jobs, please contact me to check their state.
 
  Below is interim progress report for completeness.
 
 
  Thanks,
  Paul
 
 
 
 
  Begin forwarded message:
 
  Date: Wed, 26 Jun 2013 22:43:07 +0300
  From: Paul Sokolovsky paul.sokolov...@linaro.org
  To: Paul Sokolovsky paul.sokolov...@linaro.org
  Cc: linaro-android linaro-andr...@lists.linaro.org, Infrastructure
  infrastruct...@linaro.org, Linaro Validation
  linaro-validat...@lists.linaro.org, Philip Colmer
  philip.col...@linaro.org Subject: Re: [ANN]
  android-build.linaro.org upgrade to Linaro Login Service
 
 
  Hello,
 
  On Wed, 26 Jun 2013 15:46:50 +0300
  Paul Sokolovsky paul.sokolov...@linaro.org wrote:
 
   Hello,
  
   With Android releases out, I'd like to proceed with switchover of
   Android Build frontend authenticaton to Linaro Login. Estimated
   downtime is 2hrs. To minimize impact, I'm scheduling this for
   later evening UTC (around 8pm UTC). Let me know if you need
   access to a-b at that time (otherwise, upgrade is OKed by Vishal).
 
  Upgrade went well, except that now it's not possible to create
  personal builds. That's because login username is used to form
  created job name, and with Linaro Login, username is
  first.l...@linaro.org - that's not valid as part of job name, and
  besides that, it's too long. Even if I adhocly remapped it to
  first-last, it's still too long, and still would required boring
  renaming of existing jobs.
 
  Atlassian Crowd supports login aliases, Philip mentioned that it's
  possible to create one, but I skipped doing that just for me, hoping
  that it would be offered for all folks as part of git migration or
  something, but that didn't happen. Well, I guess it's time to raise
  that request now - going submit ITS ticket for this.
 
 
  --
  Best Regards,
  Paul
 
  Linaro.org | Open source software for ARM SoCs
  Follow Linaro: http://www.facebook.com/pages/Linaro
  http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog
 
 
  --
  Best Regards,
  Paul
 
  Linaro.org | Open source software for ARM SoCs
  Follow Linaro: http://www.facebook.com/pages/Linaro
  http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog
 
  ___
  linaro-android mailing list
  linaro-andr...@lists.linaro.org
  http://lists.linaro.org/mailman/listinfo/linaro-android
 



-- 
Best Regards,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

[ANN] android-build.linaro.org upgrade to Linaro Login Service - complete

[Paul Sokolovsky]

Hello,

After couple of iterations, android-build.linaro.org was updated to
authenticate against Linaro Login system. Please use your
login.linaro.org username (with @linaro.org suffix) and password to
login from now on. Personal jobs were also renamed to have 
firstname.lastname prefix instead of Launchpad username. If you cannot
see your jobs, please contact me to check their state.

Below is interim progress report for completeness.


Thanks,
Paul




Begin forwarded message:

Date: Wed, 26 Jun 2013 22:43:07 +0300
From: Paul Sokolovsky paul.sokolov...@linaro.org
To: Paul Sokolovsky paul.sokolov...@linaro.org
Cc: linaro-android linaro-andr...@lists.linaro.org, Infrastructure
infrastruct...@linaro.org, Linaro Validation
linaro-validat...@lists.linaro.org, Philip Colmer
philip.col...@linaro.org Subject: Re: [ANN] android-build.linaro.org
upgrade to Linaro Login Service


Hello,

On Wed, 26 Jun 2013 15:46:50 +0300
Paul Sokolovsky paul.sokolov...@linaro.org wrote:

 Hello,
 
 With Android releases out, I'd like to proceed with switchover of
 Android Build frontend authenticaton to Linaro Login. Estimated
 downtime is 2hrs. To minimize impact, I'm scheduling this for later
 evening UTC (around 8pm UTC). Let me know if you need access to a-b
 at that time (otherwise, upgrade is OKed by Vishal).

Upgrade went well, except that now it's not possible to create personal
builds. That's because login username is used to form created job
name, and with Linaro Login, username is first.l...@linaro.org - that's
not valid as part of job name, and besides that, it's too long. Even if
I adhocly remapped it to first-last, it's still too long, and still
would required boring renaming of existing jobs.

Atlassian Crowd supports login aliases, Philip mentioned that it's
possible to create one, but I skipped doing that just for me, hoping
that it would be offered for all folks as part of git migration or
something, but that didn't happen. Well, I guess it's time to raise
that request now - going submit ITS ticket for this.


-- 
Best Regards,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog


-- 
Best Regards,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

[ANN] snapshots/releases.linaro.org switched to Linaro SSO for auth

[Paul Sokolovsky]

Hello,

Following up with the migration of all Linaro services to Linaro Cloud
infrastructure, ITS and LAVA teams proceed with migrating all
services to consistently use Linaro Login (Single Sign-On) for
authentication.

Linaro download servers, http://snapshots.linaro.org 
http://releases.linaro.org were migrated today. If you have access to
restricted areas on those servers, please find a minute to check that
everything works for you as expected. If you face any issues, please
send a report to i...@linaro.org .

http://android-build.linaro.org and http://validation.linaro.org are
expected to be next in line for Linaro SSO migration, in this month's
timeframe.

-- 
Best Regards,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Upcoming release.linaro.org migration

[Paul Sokolovsky]

Hello,

ITS and LAVA teams are finishing preparations to migrate our official
releases server, http://releases.linaro.org/ , to the Linaro Cloud.
We've scheduled to perform switchover first half of day on Friday, May
10th.

This migration probably doesn't affect many people inside Linaro, as
day-to-day file publishing activity is centered around
http://snapshots.linaro.org/ . There may be some changes which affect
Release Team process, and will be communicated separately (please feel
free to reply to this mail to be included in the discussion).


Thanks,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

[ANN] snapshots.linaro.org migrated to Linaro Cloud

[Paul Sokolovsky]

Hello,

http://snapshots.linaro.org, server with interim downloads as produced
by our Continuous Integration systems, has been migrated to Linaro EC2
Cloud, managed by our IT team.

All data from the old server was migrated to the new one, and for a
limited time, old server is available as
http://archive.snapshots.linaro.org/

Let us know if you experience any issues with new server (please
provide data required to reproduce the issue).


-- 
Best Regards,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: [RFC PATCH] drm.h: Fix DRM compilation with bare-metal toolchain.

[Paul Sokolovsky]

Hello,

On Fri, 12 Apr 2013 18:28:26 -0500
Nishanth Menon n...@ti.com wrote:

 From: Paul Sokolovsky paul.sokolov...@linaro.org
 
 An ifdef in drm.h expects to be compiled with full-fledged Linux
 toolchain, but it's common to compile kernel with just bare-metal
 toolchain which doesn't define __linux__. So, also add __KERNEL__
 check.
 
 [n...@ti.com: port forward to 3.9-rc6 and post to dri devel for
 feedback as RFC] Signed-off-by: Paul Sokolovsky
 paul.sokolov...@linaro.org ---
 Paul, Dri devel list,
 I picked up this patch from linaro tree:
 https://git.linaro.org/gitweb?p=people/asac/android/kernel/lt-ti.git;a=patch;h=719fbc876740cf75e82dd082ae5a00dfcf6fff7a
 Discussion thread:
 http://lists.linaro.org/pipermail/linaro-dev/2011-June/thread.html#4874
 Seems to me as a valid fix even for upstream perhaps? 

Yes, IIRC, per the discussion you quote above, I sent this patch for
review of our (Linaro's) kernel folks to see if it's ok (the patch is
simple, story why it's needed may be not such, though I was positive
it's needed). It might be forgotten somehow, thanks for picking it up!


 Regards, Nishanth Menon
 
  include/uapi/drm/drm.h |2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)
 
 diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h
 index 8d1e2bb..73a99e4 100644
 --- a/include/uapi/drm/drm.h
 +++ b/include/uapi/drm/drm.h
 @@ -36,7 +36,7 @@
  #ifndef _DRM_H_
  #define _DRM_H_
  
 -#if defined(__linux__)
 +#if defined(__KERNEL__) || defined(__linux__)
  
  #include linux/types.h
  #include asm/ioctl.h



-- 
Best Regards,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

staging.snapshots.linaro.org migration to EC2

[Paul Sokolovsky]

Hello,

Testing of new EC2 instance to replace staging.snapshots.linaro.org is
complete, here's publishing result:

http://ec2-54-234-163-41.compute-1.amazonaws.com/android/~pfalcon/galaxynexus-linaro/11

(Corresponds to
https://android-build.linaro.org/builds/~pfalcon/galaxynexus-linaro/#build=11)

Philip, can you please update staging.snapshots.linaro.org to point to
the new host?

staging.snapshots.linaro.org is internal testing host, so its migration
probably doesn't affect anyone outside LAVA team, but next in queue is
snapshots.linaro.org itself (where all Jenkins results go), so this is
early notice of its upcoming migration too (no specific ETA, but
optimistic plan is to do that this month).


-- 
Best Regards,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: LAVA: Jobs submitted to vexpress device type

[Paul Sokolovsky]

Hello,

On Mon, 24 Sep 2012 08:30:34 +0100
Dave Pigott dave.pig...@linaro.org wrote:

 Hi All,
 
 I notice that there are still some jobs being submitted to LAVA with
 the device-type vexpress. This device type is now deprecated and
 has been replaced by the more specific device type vexpress-a9. The
 jobs seem to be coming from CI and Android. Could someone amend these
 submissions?

Tracked as https://bugs.launchpad.net/linaro-ci/+bug/1055354 (Critical).

 
 Thanks
 
 Dave


-- 
Best Regards,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: Can't view the lava information from android-build for some builds

[Paul Sokolovsky]

Hello,

On Fri, 17 Aug 2012 11:18:36 +0800
YongQin Liu yongqin@linaro.org wrote:

 Hi,
 
 Just found that I can't view the lava result on android-build page for
 some build.
 but not all of them, I still can view some the information of some
 builds before.
 say the builds of
 https://android-build.linaro.org/builds/~linaro-android/snowball-jb-gcc47-igloo-stable-blob/.
 For the build #28 even I click the  login to LAVA  link and logged
 in, I still get this information like the NG.png attachment file.
 But for the build #26, I can see the lava information listed. Like the
 attached OK.png file

I was not logged into LAVA when I started, logged in from build details
page, and am able to see test results for both #26 and #28 (also tried
#25-#29). So, my guess would be that browser caches content - I saw
such issue on few occasions on android-build.linaro.org . So, please
try Shift+Reload in browser (i.e. click reload button with shift held),
or Ctrl+R few times in row and see if it helps. If you still see that
issue, I'd suggest opening bug at
https://bugs.launchpad.net/linaro-android-infrastructure and Infra's
maintenance engineers will look into it.


-- 
Best Regards,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: clone speed on jenkins

[Paul Sokolovsky]

Hello,

On Wed, 23 May 2012 08:42:59 +0200
Alexander Sack a...@linaro.org wrote:

[]
 
 remember that our http: proxy is set up in a way that it should not
 make much of a diff...
 
 The thing is that we have to transfer a complete linux tree to the
 slave node no matter what.
 
 Whether you --reference something on master or use the master hosted
 squid shouldn't make any significant net difference.

Speaking of squid, we have problems with it starting up after a reboot,
I filed https://bugs.launchpad.net/linaro-ci/+bug/1003835 for this.

And well, we probably should do more formal testing of it - when I
looked at it during ci.linaro.org migration to a bigger machine, I
didn't see stellar hit rate.

 
 So bottom line: I don't think you will win much, but I am happy to be
 proofen wrong.
 
 



-- 
Best Regards,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: [ANN] Disk upgrade on ci.linaro.org today

[Paul Sokolovsky]

Hello John,

On Wed, 9 May 2012 09:29:01 -0600
John Rigby john.ri...@linaro.org wrote:

 Paul,
 
 Not sure if it has anything to do with the upgrade but I am not able
 to create new jobs,  I tried with and without the copy existing
 option.
 
 https://pastebin.linaro.org/529/

Yes, apparently it is related, thanks for the report, it's fixed now
(verified work). Please let me know if there're any other abnormalities.

 
 --john
 
 On Wed, May 9, 2012 at 8:44 AM, Paul Sokolovsky
 paul.sokolov...@linaro.org wrote:
  On Wed, 9 May 2012 12:53:15 +0300
  Paul Sokolovsky paul.sokolov...@linaro.org wrote:
 
  Hello,
 
  The Infrastructure team works on improving disk layout on Jenkins
  build systems to avoid common cases of errors which lead to
  unexpected downtime. We recently migrated android-build.linaro.org
  to new partition setup, and would like to proceed with
  ci.linaro.org.
 
  This is potentially multi-step process, so we want to start it
  ASAP to not risk it protruding into release rush time.
 
  So, we'd like to schedule a downtime at 14:00 UTC today, expected
  duration is 1 hr. Please let me know if you have any issues with
  that time.
 
 
  Upgrade is complete, everything was performed in one stage. Please
  let Infra team know if you face any issues.
 
 
 
 
  --
  Best Regards,
  Paul
 
  Linaro.org | Open source software for ARM SoCs
  Follow Linaro: http://www.facebook.com/pages/Linaro
  http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog
 
  ___
  linaro-dev mailing list
  linaro-dev@lists.linaro.org
  http://lists.linaro.org/mailman/listinfo/linaro-dev



-- 
Best Regards,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

[ANN] Disk upgrade on ci.linaro.org today

[Paul Sokolovsky]

Hello,

The Infrastructure team works on improving disk layout on Jenkins build
systems to avoid common cases of errors which lead to unexpected
downtime. We recently migrated android-build.linaro.org to new
partition setup, and would like to proceed with ci.linaro.org.

This is potentially multi-step process, so we want to start it
ASAP to not risk it protruding into release rush time.

So, we'd like to schedule a downtime at 14:00 UTC today, expected
duration is 1 hr. Please let me know if you have any issues with that
time.


Thanks,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: [ANN] Disk upgrade on ci.linaro.org today

[Paul Sokolovsky]

On Wed, 9 May 2012 12:53:15 +0300
Paul Sokolovsky paul.sokolov...@linaro.org wrote:

 Hello,
 
 The Infrastructure team works on improving disk layout on Jenkins
 build systems to avoid common cases of errors which lead to unexpected
 downtime. We recently migrated android-build.linaro.org to new
 partition setup, and would like to proceed with ci.linaro.org.
 
 This is potentially multi-step process, so we want to start it
 ASAP to not risk it protruding into release rush time.
 
 So, we'd like to schedule a downtime at 14:00 UTC today, expected
 duration is 1 hr. Please let me know if you have any issues with that
 time.


Upgrade is complete, everything was performed in one stage. Please
let Infra team know if you face any issues.




-- 
Best Regards,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

[ANN] Android restricted-access builds

[Paul Sokolovsky]

Hello,

Linaro Infrastructure group is glad to announce support for
restricted-access builds for Linaro Android. Such builds will allow us
to adhere to our members' licensing and business restrictions for
limited-access features, while still as much as possible to follow
established Linaro open process, and let general public to be in loop
on the upcoming great new features for the ARM platform. Restricted
builds are used immediately for ongoing big.LITTLE enablement work.

Restricted builds are available in our standard Android Build System, in
a separate tab:

https://android-build.linaro.org/#builds=restricted

Members of the Launchpad group linaro-android-restricted are able to
setup new builds (please note that this group doesn't allow direct
access to restricted source code or downloads, only gives the ability
to establish a restricted build). Administrators of the group include
Alexander Sack and Zach Pfeffer, they should be contacted for
membership requests.

To set up a restricted build, select linaro-android-restricted as the
owning group in the dropdown on New build page (this is UI change
from previously available checkbox to create an official build, all
choices are now available in dropdown). As second step, add/replace
value of the following build config variable:

BUILD_TYPE=build-android-restricted


If you have a question regarding this functionality or found a bug,
please submit it directly or via the bug tracker at:
https://bugs.launchpad.net/linaro-android-infrastructure


Thanks,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: jenkins really broken right now

[Paul Sokolovsky]

Hello,

On Tue, 27 Mar 2012 17:06:53 -0600
John Rigby john.ri...@linaro.org wrote:

 On Tue, Mar 27, 2012 at 4:55 PM, Loïc Minier loic.min...@linaro.org
 wrote:
  On Tue, Mar 27, 2012, John Rigby wrote:
  Looks like initial git clones always fail.  I tried a simple job
  that just trys to run git and it fails.
 
   Alexander noticed too; new ci.linaro.org setup was launching jobs
  which were actually pointing at old ci.linaro.org setup as web
  proxy.  When the old instance was shut down, it exposed the
  problem.  Problem is that new instance doesn't have squid
  installed/configured.  We need to restore the config and any other
  missing bits.
 
 
 My jobs seem to be working again, I guess without the proxy for now
 but working none the less.  Thanks to all for fixing this.


Oh my, that's why I wanted Deepti to have another look before stopping
the old instance. But as she went on a leave, I had a look myself,
noted the squid difference and explicitly wrote it off as not in use.
But well, new instance couldn't automatically use squid on the old -
old had his IP/domain name changed, so stale config wouldn't explain
it. I also thought that Loic might have restarted the old instance, bit
it wasn't, so doesn't explain why builds went thru. So, maybe it's not
squid after all. We'll be looking into the issue immediately.


-- 
Best Regards,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: jenkins really broken right now

[Paul Sokolovsky]

On Wed, 28 Mar 2012 13:05:21 +0300
Paul Sokolovsky paul.sokolov...@linaro.org wrote:

 Hello,
 
 On Tue, 27 Mar 2012 17:06:53 -0600
 John Rigby john.ri...@linaro.org wrote:
 
  On Tue, Mar 27, 2012 at 4:55 PM, Loïc Minier
  loic.min...@linaro.org wrote:
   On Tue, Mar 27, 2012, John Rigby wrote:
   Looks like initial git clones always fail.  I tried a simple job
   that just trys to run git and it fails.
  
    Alexander noticed too; new ci.linaro.org setup was launching jobs
   which were actually pointing at old ci.linaro.org setup as web
   proxy.  When the old instance was shut down, it exposed the
   problem.  Problem is that new instance doesn't have squid
   installed/configured.  We need to restore the config and any other
   missing bits.
  
  
  My jobs seem to be working again, I guess without the proxy for now
  but working none the less.  Thanks to all for fixing this.
 


[]
 But well, new instance couldn't automatically use squid on the old -
 old had his IP/domain name changed, so stale config wouldn't explain
 it. I also thought that Loic might have restarted the old instance,
 bit it wasn't, so doesn't explain why builds went thru. So, maybe
 it's not squid after all. We'll be looking into the issue immediately.

Ok, it turns out that the cache was accessed as internal EC2 IP,
http://ip-10-195-115-143.ec2.internal:3128;. So, mystery off, the issue
fully understood and confirmed.


-- 
Best Regards,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Improvements to Android Build errors separation (and NOT BUILT status)

[Paul Sokolovsky]

Hello,

One of the issues with https://android-build.linaro.org/ is that, if
build fails, it's not easy to tell if it happened because of
compilation error (real failure) or due to non-deterministic error
with setting up infrastructure for build (e.g. during source checkout).
The latter not so uncommon due to vast source size of Android and
complexity of cloud infrastructure.

This became especially problematic with start of automated CI loop,
where it leads to false negatives when doing pre-merge testing.

Improving this situation was subject of few blueprints in which
Infrastructure team worked, and recently, a solution was deployed. With
it, if a build fails due to non-deterministic infrastructure error, it
will get status of NOT BUILT, meaning that a build never actually got
to compilation phase. Suggested action in such case is to retry.

Please note that Jenkins there is some inconsistency within the Jenkins
itself regarding NOT BUILT status - Pending is used as a display name
in places, and the same gray icon used as for ABORTED builds. So,
please keep that in mind, or yet better use Build Frontend.

Unfortunately, even short weekend testing showed that error separation
achieved is not ideal (folks who participated in Connect Q4.11
session dedicated to this, may remember that I said that it would
take adding AI to do that properly ;-) ).

In particular, if there was an issue with manifest file (essentially,
an error in Android source code), it will be reported as NOT BUILT
instead of FAILED. Here's example of such build:
https://android-build.linaro.org/jenkins/job/linaro-android_panda-ics-gcc44-kwg-upstream-open/77/console

Opposite miscategorization may also happen: very early infra error may
be reported as FAILED instead of NOT BUILT. Example: 
https://android-build.linaro.org/jenkins/job/linaro-android_panda-ics-gcc46-omapzoom-stable-blob/78/console

So, Infrastructure team will continue to work on improving reliability
of builds, but in the meantime please keep looking in the build logs for
actual cause of the failure (feel free to report unexpected build
status to https://bugs.launchpad.net/linaro-android-infrastructure)


-- 
Best Regards,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: [ANN] Support for fetching build configs from git for Android Builds

[Paul Sokolovsky]

Hello Alexander,

On Tue, 21 Feb 2012 16:08:22 +0100
Alexander Sack a...@linaro.org wrote:

 On Mon, Feb 20, 2012 at 5:11 PM, Paul Sokolovsky
 paul.sokolov...@linaro.org
  wrote:
 
  Hello,
 
  As the result of implementation of
 
  https://blueprints.launchpad.net/linaro-android-infrastructure/+spec/build-config-in-git,
  android-build.linaro.org now can indirectly fetch build config
  stored in a git repository. To achieve that, bootstrap config (as
  specified in android-build.linaro.org) should contain reference to
  config's repo/branch/file (configuration variables are modeled on
  the similar MANIFEST_* ones), e.g.:
 
  BUILD_CONFIG_REPO=git://
  git.linaro.org/people/pfalcon/android/linaro/build-configs.git
  BUILD_CONFIG_BRANCH=masterhttp://git.linaro.org/people/pfalcon/android/linaro/build-configs.git%0ABUILD_CONFIG_BRANCH=master
  BUILD_CONFIG_FILENAME=panda-ics-gcc46-tilt-tracking-blob.conf
 
 
  http://android.git.linaro.org/gitweb?p=linaro/build-configs.git;a=summary
  was created to store configs for the official builds in the Gerrit
  tree.
 
  Sample job is available here:
  https://android-build.linaro.org/builds/~pfalcon/git-build-config/
  (it uses personal repo as a test).
 
 
 
 That's a great feature ...
 
 I see a dev now could retrieve that config from git to then reproduce
 an exact build using the same configs and toolchain etc.

Nothing new here, any build's page already contained the exact build
config used for that particular build. E.g.

https://android-build.linaro.org/builds/~linaro-android/imx6-ics-gcc47-freescalelt-stable-open/#build=5

shows the exact build config used that build, #5. If a job config was
changed later and new builds fire with new config, that pages still
retains original config used for build #5.

In that respect, storing build configs in git actually makes it all
less visible. That's why I was a bit surprised to receive this request
- I thought that the whole purpose of Android Build is to keep it
visible, explicit, and interactive. Well, we know two major usecases for
configs in git - better change control and mass-editing. But it would
be little more complicated to figure out an answer to questions like
What kernel tree used in this build?, and to explain (to community
members for example) how to find out answer to that question.

 What kind of
 tools can we offer to make that easy?

So, that's orthogonal to this, and as Andy wrote, it's in works. And
I'm glad that we agreed to abstract that into a script (vs to just
textual instructions), because, again, having build configs in git
just makes it a bit more complex and require more steps to accomplish.


-- 
Best Regards,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: Initial Linaro+Android kernel for 12.02 is available

[Paul Sokolovsky]

Hello,

On Mon, 20 Feb 2012 15:23:36 -0800
john stultz johns...@us.ibm.com wrote:

 On Mon, 2012-02-20 at 17:19 -0600, Zach Pfeffer wrote:
  Paul,
  
  Would you get Andrey setup to push to android.git.linaro.org?
  
  We should name it
  
  kernel/kwg.git
  
  Sound good with everyone?
 
 Why not reuse the existing kernel/linaro-android.git ?

Yes, would be nice to get the target tree right (because Gerrit
doesn't support repo deletion). If Andrey starts to overlook integration
of kernel and Android patches, and that work is fully based on John's,
then it indeed would make sense to go on using
kernel/linaro-android.git . So, waiting for confirmation.

 
 thanks
 -john
 
 



-- 
Best Regards,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: [DOWNTIME] Android Build is down due to Ubuntu's sun-java6 package revocation

[Paul Sokolovsky]

Hello,

Ok, this has been fixed now, sun-java6 packages are installed from
local mirror on android-build, building capability is restored.

https://bugs.launchpad.net/linaro-android-infrastructure/+bug/936990 is
opened to track switching to OpenJDK, awaiting Android team response to
that.

Also, it turned out that Ubuntu's sun-java6 repository is actually in
inconsistent state, reported as 
https://bugs.launchpad.net/ubuntu/+source/sun-java6/+bug/937027


Thanks,
Paul

On Mon, 20 Feb 2012 03:11:50 +0200
Paul Sokolovsky paul.sokolov...@linaro.org wrote:

 Hello,
 
 Recently, Ubuntu revoked sun-java6-* packages following retirement of
 its license:
 
 https://lists.ubuntu.com/archives/ubuntu-security-announce/2012-January/001554.html
 
 It propagated to the repositories we use for android-build.linaro.org
 slaves on this weekend. The end effect of this besides builds not
 being able to proceed, is slave pile-up issue, as Jenkins, seeing an
 initialization error for one slave, tries to start another, all going
 in cycles. As it's pretty late in here, the action I'm taking is
 disabling builds altogether, to proceed with resolving this first
 thing in the morning (access to previous builds is still available).
 
 Proposed actions are:
 
 1. Install sun-java6-* from cached .deb's as risk-mitigating measure
 while analyzing the issue.
 2. Consider/test switching to OpenJDK, as recommended by
 https://wiki.ubuntu.com/LucidLynx/ReleaseNotes/Java6Transition . Note
 that sun-java6 have been, and still is, listed by Google as the
 Android build prerequisite:
 http://source.android.com/source/initializing.html However, there
 were success reports with OpenJDK from individual developers
 previously.
 
 



-- 
Best Regards,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

[ANN] Support for fetching build configs from git for Android Builds

[Paul Sokolovsky]

Hello,

As the result of implementation of
https://blueprints.launchpad.net/linaro-android-infrastructure/+spec/build-config-in-git
 ,
android-build.linaro.org now can indirectly fetch build config stored
in a git repository. To achieve that, bootstrap config (as specified
in android-build.linaro.org) should contain reference to config's
repo/branch/file (configuration variables are modeled on the similar
MANIFEST_* ones), e.g.:

BUILD_CONFIG_REPO=git://git.linaro.org/people/pfalcon/android/linaro/build-configs.git
BUILD_CONFIG_BRANCH=master
BUILD_CONFIG_FILENAME=panda-ics-gcc46-tilt-tracking-blob.conf


http://android.git.linaro.org/gitweb?p=linaro/build-configs.git;a=summary
was created to store configs for the official builds in the Gerrit tree.

Sample job is available here:
https://android-build.linaro.org/builds/~pfalcon/git-build-config/ (it
uses personal repo as a test).


-- 
Best Regards,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

[ANN] Finished migration of Android downloads to snapshots.linaro.org

[Paul Sokolovsky]

Hello,

We started migrating Android build artifacts as produced by
https://android-build.linaro.org/ to http:///snapshots.linaro.org
almost 2 months ago and now the migration can be pronounced complete.
From now on, http://snapshots.linaro.org/android/ is the master
download location for all Android builds, with all builds done in last 2
months available there, important historical builds (*1) migrated
there too, and archiving on android-build.linaro.org now turned off.
There are several benefits for hosting Android builds directly on
snapshots.linaro.org:

1. It is a central place for all Linaro downloads.
2. It allows to manage EULA protection in centralized manner.
3. It allows for consistent structuring and styling.
4. It allows for better space and retention policy management.
5. It alleviates Infrastructure team from maintaining Android
downloads on the Jenkins server, allowing us to concentrate on build
side of it.

Please note that this change is transparent to
https://android-build.linaro.org/ - artifacts can still be download
from its detailed pages, the links just point to
snapshots.linaro.org . All existing artifacts also stay available on
android-build.linaro.org, so any previously disseminated links remain
valid (*2).


*1 Only historical releases were migrated to snapshots.linaro.org,
historical daily and developers' built were not due to concerns with
current disk space availability on snapshots.linaro.org. But both daily
and developers' builds are subject to expiration (lifetime 3 months
max), and with 2 months of snapshots.linaro.org archiving, there's only
one month's worth of builds left on android-build.linaro.org, which
would expire shortly.

*2 Subject to expiration policy, per (*1)

-- 
Best Regards,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: Linaro Android against vanilla linux kernel versions

[Paul Sokolovsky]

Hello Tugrul,

On Fri, 3 Feb 2012 10:00:56 +0200
Guclu, Tugrul tugrul.gu...@siemens.com wrote:

 Hi Paul
 
 Thanks for your answer. That was what I'm looking for. I got 2 more
 questions if you would mind.
 
 1)
 All Android buils are available here
 https://android-build.linaro.org/#builds=all  ,correct ?

Yes, both official monthly releases and daily releases are available
there, old dailies are expired in 3 months though (release stay all the
time).

 If that is the case the oldest  belongs to
 ~linaro-android/panda-11.04-release 2011-04-28 15:28:40 

Yes, 2011.04 was apparently first official Linaro Android release,
and Linaro started working on Android not long before that.

 2) this is from ym download script
 /repo init -u git://android.git.linaro.org/platform/manifest.git -b
 linaro_android_2.3.5
 --repo-url=git://android.git.linaro.org/tools/repo.git -b gingerbread
 || exit 1 
 Where can I find the pinned manifest of linaro_android_2.3.5 ? Because
 this build is not displayed in the
 https://android-build.linaro.org/#builds=all  ?

Pinned manifests come for specific builds. The earliest release build
for imx35 appears to be
https://android-build.linaro.org/builds/~linaro-android/leb-imx53-11.07-release/
 ,
and from a quick look that's even 2.3.4. Not sure about the kernel
though, please check yourself - even though it's 2.3.4, we might have
used much newer kernel than AOSP 2.3.4 (well, that's what Linaro does -
leverages and tests newer technologies so vendors and community were
more comfortable with adopting them).

 BR
 
 Tugrul
 

-- 
Best Regards,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: Linaro Android against vanilla linux kernel versions

[Paul Sokolovsky]

Hello Tugrul,

On Thu, 2 Feb 2012 16:12:29 +0200
Guclu, Tugrul tugrul.gu...@siemens.com wrote:

 Hi
  
 I have already asked thi question at
 http://ask.linaro.org/questions/607/looking-for-android-distribution-bui
 ld-on-top-of-linux-kernel-26359-for-imx53-board
 http://ask.linaro.org/questions/607/looking-for-android-distribution-bu
 ild-on-top-of-linux-kernel-26359-for-imx53-board  but could not
 receive satisfactory answer.
  
 Exactly how can you determine against which vanilla linux kernel
 version linaro Android distribution is built ?

Unfortunately, Android doesn't offer any kind of package management or
even manifesting to make answering such question easy. We're aware of
this issue, and would like to do something about it, but it has low
priority, as it's unclear if that would be accepted upstream and we try
not to deviate much from AOSP.

So, that leaves with just tracing needed info thru binaries or sources.
And as Android is big, that's a bit of chore.

Let's go source way as an example. Suppose you want to figure out with
which kernel version this and exactly this build was made (because all
components including kernel change over time):

https://android-build.linaro.org/builds/~linaro-android/imx53-ics-gcc46-freescalelt-stable-open/#build=178

So, open pinned-manifest.xml from that page, which has exactly
component revisions used in the build. Look for kernel:

project name=kernel/imx53 path=kernel
revision=8083fb279331e989d3d98a71ba6273f803ed7b96/

That comes from default remote which is 

remote fetch=git://android.git.linaro.org/ name=aosp 
review=review.android.git.linaro.org/
default remote=aosp revision=refs/tags/android-4.0.3_r1 sync-j=4/

(don't pay attention to aosp, in this context it means Linaro's
extended mirror of AOSP).

That remote has git web on the same URL (which is good convention),
let's look for kernel/imx53 repository there:

http://android.git.linaro.org/gitweb?p=kernel/imx53.git;a=summary

Let's search for the revision from pinned-manifest.xml:

http://android.git.linaro.org/gitweb?p=kernel%2Fimx53.gita=searchh=HEADst=commits=8083fb279331e989d3d98a71ba6273f803ed7b96

What we're interested in is however the tree which corresponds to this
revision (click tree link):

http://android.git.linaro.org/gitweb?p=kernel/imx53.git;a=tree;h=a0b5ec7ae344797935a578e195ac8927a68c3671;hb=HEAD

Well, you're one click from the Makefile which starts with the kernel
version encoded:

http://android.git.linaro.org/gitweb?p=kernel/imx53.git;a=blob;f=Makefile;h=c44d720b88f0d8ac42b5b25c076ae605cb273263;hb=HEAD


 Thanks for your support
  
 BR
 Tugrul


-- 
Best Regards,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: Tracking patches to copy-to-slave Jenkins plugin

[Paul Sokolovsky]

Hello Guilherme,

On Tue, 17 Jan 2012 15:44:02 -0300
Guilherme Salgado guilherme.salg...@linaro.org wrote:

[]
  So, based on all this, I wouldn't think there's something to
  patch-track: it's not that much of upstream contribution, more of
  upstream bugreport + local workaround. But if you think we could
  track anything out of this, I'd appreciate a hint how to start with
  that.
 
 Right, it probably doesn't make sense to teach patches.l.o how to
 suck patches submitted by Linaro engineers from issues.jenkins-ci.org
 as we don't expect to see many contributions from Linaro there. If
 that changes in the future, we can certainly work something out, like
 we did for gerrit.
 
 The way you described it sounds like the patch you submitted isn't
 even going to be merged upstream, but if you have others that you
 expect to be, you can just email a copy of them to patches@l.o, as
 described at

That's my patch was just commenting some code around. I now tested
(tracked as
https://bugs.launchpad.net/linaro-android-infrastructure/+bug/917704),
the latest changes to the plugin made by the maintainer, and they were
re-done properly: using conditionals driven by UI configuration
settings.


 
https://wiki.linaro.org/Process/UpstreamPatches
 
 In that case you'll also want to ask for the creation of a new
 project on patches.l.o (instructions also on the page above)


Sounds good, thanks!



-- 
Best Regards,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

[ANN] Automated upstream syncing for Linaro Android tree

[Paul Sokolovsky]

Hello,

This should have gone more than a week ago, but was lost in
click-thru work. Anyway, we now finally have automatic syncing with
upstreams for our tree - that includes AOSP and other components we
mirror. It runs for more than 2 weeks now and works pretty well. For
AOSP, some components may be missing with upstream version upgrades,
then just please submit a ticket to have them picked up (manual op),
like this one:

https://bugs.launchpad.net/linaro-android-infrastructure/+bug/905664

to ensure timely processing.


Thanks, and Merry Christmas!
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Android Build seeded builds report

[Paul Sokolovsky]

Hello,

We launched seeded builds on Linaro Android Build System
(https://android-build.linaro.org) more than a week ago with the aim to
improve build performance and stability, following Android ICS import
which overloaded our previous build infrastructure, and looking forward
into making Android RC preparation to be comfortable instead of
stressful it became due to infra overload.

From the very first builds it was clear that it is huge relief
for problems we have, but it took entire Android team involvement to
prove that they're working as expected. And now, almost 2 weeks later,
we even enough stats materials to assess how much improvement they
actually did. So, I wrote a blog article about that, which includes
nice build time chart which vividly shows it all:
http://www.linaro.org/linaro-blog/2011/12/01/improving-performance-of-linaro-android-build-service/

The seeded builds launch effort was a big success in cooperation
between Infrastructure and Android team, led by Platform Director, and
I would like to thank everyone for you discussion, involvement, peer
review!

One last thing I would like to add though is that we essentially just
*started* deployment of the seeded builds, they will require more time
to uncover their full potential and made be well maintainable, so work
on that continues thru 11.12


Thanks,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: LAVA validation status

[Paul Sokolovsky]

Hello Dave,

On Fri, 11 Nov 2011 10:36:45 +
Dave Pigott dave.pig...@linaro.org wrote:

[]
 look and feel!), we're asking that you hold off submitting jobs to
 LAVA until we give the go-ahead.

Hold-off as in please don't submit jobs now - they disrupt us, or
if you submit now, be prepared to not get expected results?

 
 I'll e-mail later to let you know when we are fully operational again.
 
 Many thanks
 
 Dave Pigott
 Validation Engineer
 T: +44 1223 45 00 24 | M +44 7940 45 93 44
 Linaro.org │ Open source software for ARM SoCs
 Follow Linaro: Facebook | Twitter | Blog
 



-- 
Best Regards,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

[ANN] New process for communicating Android Infrastructure issues and requests

[Paul Sokolovsky]

Hello,

Based on the discussions and decisions made at the Linaro Connect Q4.11,
Infrastructure team is pleased to announce changes in the process of
Linaro Android Infrastructure planning and maintenance. The main
audience of the new process is Linaro Android Team, which is the primary
stakeholder of the Android infrastructure, but it also applies to other
groups and individuals in Linaro, as well as external contributors and
community.

The basic idea is to make Android infrastructure planning and
management more sustainable, as well as improve the Infrastructure Team
internal processes which will allow entire team to handle Android
infrastructure tasks and improve cross-team work and knowledge sharing.

The new process is as follows:

1. There's a new Linaro Android Infrastructure project at Launchpad,
https://launchpad.net/linaro-android-infrastructure/ , which is
intended to be a central facade for Android infrastructure development
and maintenance.

2. The bugtracker in that project,
https://bugs.launchpad.net/linaro-android-infrastructure is intended as
a single contact point to report Android infrastructure issues, so
please bookmark it and keep it handy. This ticket queue replaces all
older communication means, like direct email, IRC pings, etc. (that
doesn't mean they can't be used, it means that any issue should be
reported as a ticket nonetheless). The bugtracker is indeed conceived
to be a single point of contact, and if a ticket requires recursing to
Linaro IS team, that will be handled by Infrastructure team itself.
Using the bug also affects project Launchpad feature, tickets can be
easily cross-posted to other projects which are affected.

3. The blueprints area in that project,
https://blueprints.launchpad.net/linaro-android-infrastructure is used
to host all blueprints related to Android infrastructure. That may
change in the future (i.e. they will be filed against individual
projects), but so far it's good step forward from such bluprints being
filed against linaro-android project, which caused scheduling and
accounting issues for both Android and Infrastructure teams.

4. The usual rules of thumb are applied to blueprints and tickets:
Blueprints represent work to develop new (sub)systems or add
non-trivial functionality to existing systems. They can be filed at any
time, but prioritized and scheduled for execution at the beginning of
monthly milestones. Tickets represent issues reports and requests to
make changes which only Infra team can do, other maintenance requests,
and feature requests. Tickets which turn out to require substantial
effort, may be converted to blueprints.

5. For the time being, the Infrastructure team commits to working on
1-2 Android infrastructure blueprints each milestone, with more time
spent on maintenance (including documentation and testsuites) of
existing systems. Following the process above will allow us to optimize
and improve our workflow, and provide more resources to Android
infrastructure work, if that proves to be required.



Thanks,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

[ANN] Android Build downloads and other improvements

[Paul Sokolovsky]

Hello,

There were few user-facing improvements for
https://android-build.linaro.org/ , Linaro Android Build System, from
which can be downloaded daily builds of Android components (platform,
toolchain):

1. HTTP downloads were enabled.

It was long-standing feature request, and brings number of improvements
to user experience and system scalability:
  a) With 100Mb+ downloads android-build.linaro.org provides, going
  plain HTTP instead of SSL improves download speed pretty well.
  b) Taking into account that downloads are server by not very powerful
  EC2 instance, alleviating it from SSL number-crunching improve
  concurrent download speed and build performance.
  c) Using plain HTTP gets around SSL certificate issues, the need to
  do extra click-thru in browser or use obscure options for wget.

2. HTTP downloads made default for the Build Frontend.

Instead of documenting HTTP download link on some obscure web page,
they were made default when browsing build results from
https://android-build.linaro.org , e.g.:

https://android-build.linaro.org/builds/~linaro-android/staging-panda/

(Please note that all older links will keep working. Underlying
Jenkins instance also keeps using https:// links).

3. MD5SUMS are available for platform downloads.

Now it's easy to verify integrity of downloads using well-known
convention of MD5SUMS files. Whole download and integrity checking can
be scripted as:

wget -r -nd 
http://android-build.linaro.org/builds/~linaro-android/staging-panda/65/target/product/pandaboard/
md5sum -c MD5SUMS

4. Links to easily access build logs in several formats added.

Last milestone, we enabled Jenkins Log Parser plugin, which allowed
to get quickly to the location of errors within 20MB build log file.
However, it was available only from within Jenkins. Now, links to the
most useful log browsing pages were added directly to frontend's build
page, following concept that frontend page should make the most useful
build information available and developers' fingertips. Now there're
(under Log subsection on the page):

  * Parsed - parsed log mentioned above, providing quick jump to error
locations and stats about a build
  * Tail - Last 500KB or so of the log, which oftentimes contain error.
With one click, entire log can be browsed, with all lines still
nicely wrapped.
  * Raw - plain-text log, as available before. This is mostly suitable
for download and local view, as lines are not wrapped in most
browsers when viewing online.
  

See 
https://android-build.linaro.org/builds/~linaro-android/staging-panda/#build=59
for example.


-- 
Best Regards,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Android Build session at the Connect

[Paul Sokolovsky]

Hello,

There will be Android Build System related session at the Connect,
https://blueprints.launchpad.net/linaro-android/+spec/linaro-platforms-lc4.11-android-build

The plan is to have discussion on the following topics:

1. Performance of the Android Build during last half year
2. What was done and what was not from the previous big planning
session (LDS11.05)
3. How still not done items scale up to current evolution of Android
Build and Android team requirements.
4. Currently open fronts of work.
5. Future plans regarding Android Build - both on backend and frontend
(UI) side.


I'd like to invite for participation the Android team members, who work
with the system daily, PMs for both Infrastructure and Android teams,
and well as release manager(s), as one of the function of Android Build
is to disseminate interim release of Linaro Android, and we need to
coordinate how to do that better. Of course, wider audience interested
in the topic if welcome to join too!


Thanks,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: downloading repo -- can't connect to android.git.kernel.org ?

[Paul Sokolovsky]

Hello,

On Tue, 4 Oct 2011 14:19:39 -0700
Jean-Baptiste Queru j...@android.com wrote:

 Chicken-and-egg: you can't submit a patch for the AOSP web site saying
 that the AOSP servers are down... because the AOSP servers are down.
 
 We're working on it.


Now that kernel.org is up, any ETA for when we can expect
android.git.kernel.org be back up too? Or at least, can we be sure it
will be the same hosts structure/setup as before?


Thanks,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: Export kernel defconfig through android-build

[Paul Sokolovsky]

Hello Zach,

On Fri, 16 Sep 2011 11:08:48 -0500
Zach Pfeffer zach.pfef...@linaro.org wrote:

[]
 
 Sure, but we'd just do the kernel.
 
  Secondly, kernel, while special, is still integral component of
  Android, so our job is to provide the best kernel and its config,
  and those who need to tweak/replace it, need to already know how to
  do that, or learn their way thru it. And that knowledge is not
  Android-specific, as argued above, and as argued above, providing
  shortcuts for that would be more of disservice. YMMV ;-)
 
 I don't think so. The script would have all the commands in it so it
 would help people make this leap while lowering the burden on our team
 to answer each email with the steps that would be in the scripts.

Ok, if you think it's worth to develop and maintain support for such
script, then sure, it can be done. But I agree with James that it would
rather be blueprinted, so good attention can be paid to its
implementation and testing.


-- 
Best Regards,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Android Build Jenkins Log Parser plugin deployed

[Paul Sokolovsky]

Hello,

20Mb Android build logs were never easy to parse, and with increasing
number of builds we do, it becomes real chore. I had installing Jenkins
Log Parser plugin
(https://wiki.jenkins-ci.org/display/JENKINS/Log+Parser+Plugin) in my
background queue
(https://blueprints.launchpad.net/linaro-android/+spec/linaro-android-gradually-improve-build-ui)
for some time, and actually started deploying it few weeks ago, which
uncovered some issue in the build frontend. Today I finally enabled it
for all jobs (including future).

What changes this brings? At Jenkin's build page, e.g.
https://android-build.linaro.org/jenkins/job/patrik-ryd_pandroid/57/
you'll see new section with error count, e.g. 1 errors, 0 warnings.
Then by clicking Parsed Console Output link at the left, you can
open parsed log:

https://android-build.linaro.org/jenkins/job/patrik-ryd_pandroid/57/parsed_console/

, get list of errors, and easily navigate to their location in
the complete build log.

Besides showing errors/warnings, there's also category for info
messages, and example usage can be seen here:
https://android-build.linaro.org/jenkins/job/linaro-android_leb-origen/51/parsed_console/
where it provides quick way to look up which gcc version was used for
the build.


What is treated as error/warning/info is fully configured in the plugin
using regexps. Current config is here:
https://android-build.linaro.org/jenkins/userContent/android.parse/*view*/

That's pretty basic so far, and may miss some errors. So, if you'll see
such case, or have an idea what would be useful to export as an info
message, please let me know. I have bunch of ideas myself, which I'm
going to pursue with background priority as part of the aforementioned
blueprint.


-- 
Best Regards,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: Export kernel defconfig through android-build

[Paul Sokolovsky]

Hello,

Just my 2 cents.

On Thu, 15 Sep 2011 16:13:32 -0500
Zach Pfeffer zach.pfef...@linaro.org wrote:

 On 15 September 2011 15:58, James Westby james.wes...@linaro.org
 wrote:
  On Thu, 15 Sep 2011 15:08:26 -0500, Zach Pfeffer
  zach.pfef...@linaro.org wrote:
  I'm writing up some notes on building Android from scratch and
  replacing the kernel in an Android build from one built locally,
  and I realized that's it a bit of a chore to extract the kernel
  config that got used. 

How is it chore? You get uImage out of boot.tar.bz2 and run
scripts/extract-ikconfig from kernel tree on it, voila.

As long as we have CONFIG_IKCONFIG_PROC in defconfig, we're ok, and
every (open) kernel in the world has to have that option on. Btw, I
was really astonished to find out that Ubuntu doesn't have that option
set. Horror! My noname cheap tablet doesn't conceal its kernel config
from me, and Ubuntu does.

 I thought, it may make sense to provide an
  way in android-build to control what gets used - which would make
  finding this information easier since if would one of the configs
  that gets passed to the build like TARGET_PRODUCT. Thoughts?
 
  Hi,
 
  We could (fairly easily I imagine) make the actual config an
  artefact of the build. Then you could go to any build, grab the
  config, and so build the same thing locally.
 
  Passing it in would be ok, but I'm not sure we would want to make
  every build have the config specified as well as everything else?
  The only way that it would be universal would be if you had to
  specify this on every config, which seems to duplicate information
  inside the tree.
 
  Providing the config that was used as an artefact would be
  universal. I guess we even have a choice between providing the
  full .config, and just the name of the defconfig, if that's how the
  Android build system selects them.
 
 It just does it by name.
 
 Thinking more about this.
 
 Replacing a kernel is a pretty normal operation. 

It's normal operation for those who know how to do that. And giving
people who don't know a script doesn't help at all, because very next
question will be I get error running your script, wazzup?, next one
will be I made some random changes to defconfig and it no longer
boots, etc, etc.

 I think if we just
 generated a script that had the relevant paths from the build and
 posted that on the build page then that would streamline this
 operation. Something like:
 
 git clone git://git.linaro.org/people/jstultz/android.git
 cd android
 git checkout linaro-android-3.0
 
 wget --no-check-certificate
 https://android-build.linaro.org/jenkins/job/linaro-android_toolchain-4.6-linaro-master-with-generic-target/18/artifact/build/out/android-toolchain-eabi-linaro-4.6-2011.08-18-2011-09-12_08-38-17-linux-x86.tar.bz2
 
 tar -jxvf
 android-toolchain-eabi-linaro-4.6-2011.08-18-2011-09-12_08-38-17-linux-x86.tar.bz2
 
 make ARCH=arm CROSS_COMPILE=$PWD/android-toolchain-eabi/bin/arm-eabi-
 defconfig android_omap4_defconfig  make ARCH=arm
 CROSS_COMPILE=$PWD/android-toolchain-eabi/bin/arm-eabi- uImage
 
 Most of those values come out of the build system and you can find
 most of them, but have a script would be just one more way we're
 making it easier to work with these builds.

I am usually proponent of providing more information about builds (and
introspection into systems in general), but that seems a bit too
much/misplaced to me. First of all, kernel is of course a bit special,
but there're thousand other components in Android which might be good
to replace, so what about providing 1K scripts to handle that? With
that in mind, for me, threshold for how many such scripts to provide is
at 0, not 1.

Secondly, kernel, while special, is still integral component of Android,
so our job is to provide the best kernel and its config, and those who
need to tweak/replace it, need to already know how to do that, or learn
their way thru it. And that knowledge is not Android-specific, as
argued above, and as argued above, providing shortcuts for that would
be more of disservice. YMMV ;-)

 
  Thanks,
 
  James
 
 
 
 



-- 
Best Regards,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: [RFC] Upgrade Jenkins EC2 plugin to 1.13 on Android Build

[Paul Sokolovsky]

Hello Michael,

On Tue, 06 Sep 2011 08:35:57 +1200
Michael Hudson-Doyle michael.hud...@canonical.com wrote:

 On Mon, 5 Sep 2011 16:18:34 +0300, Paul Sokolovsky
 paul.sokolov...@linaro.org wrote:
  Hello,
  
  We're running Jenkins EC2 plugin v 1.11 on android-build.linaro.org,
  which is 2 releases behind the latest 1.13. Per ChangeLog, it fixes
  slave label expression evaluation, which affected me once when I
  tried to do more flexible slave selection for builds (we
  fortunately were able to get past it by the fact that we use same
  64-bit slave type for both platform and toolchain builds).
 
 Ah, that was a bug was it?  I remember playing around with it and
 failing completely :-)

Yeah, it did. And with new version, I was getting almost the same
behavior, until I remembered everything I tried with it previously. The
problems is that we have labels like '32bit' and '64bit', i.e. starting
with a digit. And label expression like 'ec2  64bit' doesn't work
(job with it hangs and doesn't start any instance), instead it should
be 'ec2  64bit'.

 
  So, I'd like to schedule an upgrade some time next week, to allow
  for sandbox testing and feedback collection time.
 
 I'm all in favour of staying up to date as a general rule.

Got to playing with it only today. Seems to do well, can be poked at
https://ec2-107-20-68-191.compute-1.amazonaws.com/jenkins/ . Going to
watch it for few days more, and schedule android-build upgrade to
Monday.

 
 Cheers,
 mwh

-- 
Best Regards,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

[ANN] Daily seeded builds of Android toolchain from gcc-linaro bzr

[Paul Sokolovsky]

Hello,

There're now regular builds of Android 4.5 and 4.6 toolchains from
gcc-linaro bzr repository. These builds will allow Android team to
track Toolchain WG progress closer, be more prepared to toolchain
release, and later - to do CI tests using it. 4.6 toolchain, which is
the scope of the current development and which is used to build Linaro
Android release, is build daily. 4.5 toolchain which is stable and
apparently heads towards maintenance release only, built twice a week
(Wed  Fri), to optimize utilization of pay-per-usage EC2 resources.

https://android-build.linaro.org/builds/~linaro-android/toolchain-4.5-bzr/
https://android-build.linaro.org/builds/~linaro-android/toolchain-4.6-bzr/


Thanks to Michael Hope's help, these builds use repository tarball
seeds to initialize bzr checkouts, and so both fast and optimal in
network bandwidth. The seed itself is available in S3: 

http://s3.amazonaws.com/gcc-linaro/lp-gcc-linaro-seed-bzr106808.tar.xz

and can be reused by other EC2-hosted projects to leverage optimal
resource usage practices. More info on how to use it can be found in
Michael's writeup at:
https://wiki.linaro.org/WorkingGroups/ToolChain/BzrSeeds


-- 
Best Regards,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: Gerrit refs regexp patterns don't work - usefully or at all

[Paul Sokolovsky]

Hello Edwin,

On Tue, 6 Sep 2011 15:52:49 +0200
Edwin Kempin edwin.kem...@gmail.com wrote:

 Hi Paul,
 
 I'm afraid that regular expressions are broken in Gerrit 2.2.1, see
 issue 1015 [1]. It was fixed with commit
 9161c709eefc0828a8af4d46f6e8409c307aea1e for Gerrit 2.2.2
 The correct syntax for your case would be ^refs/heads/linaro.*. This
 syntax is accepted by Gerrit 2.1.8 and current Gerrit master state,
 which will be Gerrit 2.2.2.

Thanks for confirming this issue and providingthe  bug reference, Edwin
- I tried to search about these issues, saw people raising questions
about /*, but somehow didn't see any reports of regexp problems.

I understand that right now is probably not the best time to ask for
this, but assuming that AOSP infrastructure is fully back up, is a new
Gerrit release somewhere in the near queue?

 
 You are right, that the backslashes in the examples are incorrect and
 the documentation needs to be fixed (I can do this as soon as the
 Android Gerrit server is back). The backslashes in the documentation
 occured due to an incompatible upgrade of args4j. The old version of
 args4j required certain characters to be escaped with a backslash.
 When we upgraded to the new args4j version all those backslashes that
 were used for escaping suddenly became visible...
 
 Best regards,
 Edwin
 
 [1] http://code.google.com/p/gerrit/issues/detail?id=1015
 

[]

-- 
Best Regards,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Gerrit refs regexp patterns don't work - usefully or at all

[Paul Sokolovsky]

Hello,

We're elaborating our Linaro Gerrit (2.2.1) set up, and would like to
enforce separation between upstream and our branches, to disallow
stray commits to upstream branches and keep them pullable from AOSP.
So, we'd like to limit review requests, pushes, etc. to
refs/heads/for/linaro* and refs/heads/linaro*.

Trying to enter exactly that into refs entries for All Project's ACL
lead to Invalid Name error. After looking at Gerrit's source, it
turns out that Gerrit expects *-using pattern to end with /*. Well,
why? Yes, it's nice idea to use hierarchical-like branch names.
Sometimes. But there're also good reasons to restrict branch name to
generic identifier. For example, to keep one-to-one mapping with
filenames (confined to some dirs), or database names (both useful for
CI for example). So, requiring slash present before * seems like
arbitrary restrictions.

Anyway, I wasn't too upset, knowing that arbitrary patterns can be
encoded using regexps, and that's where real surprises start. First of
all, looking at example regexps at
http://gerrit.googlecode.com/svn/documentation/2.2.1/access-control.html#_project_access_control_lists
there were suspiciously stray backslashes in pattern examples. Anyway,
I tried to input ^refs/heads/linaro.*, it was rejected with Invalid
Name error. Same for ^refs/heads/linaro.*. Then I just tried example
from the doc, both as is and with slashes stripped -
\^refs/heads/[a-z]\{1,8\}  ^refs/heads/[a-z]{1,8}. Same error.

Looking at the source, validation for regexp case is complicated (and
nothing points to backslashes being required): it seems to generate a
subject string which would match entered pattern, and test that simple
for being good refs syntax. Well, I thought, maybe UI validation
outslies itself, and commit changes directly to project.config of
refs/meta/config branch of All-Project. No avail. With config like:

[access ^refs/for/refs/linaro.*]
push = group Registered Users

it's not possible to submit review against any branch at all.

Thinking here would be that may be regexp library is not available, or
regexp syntax is not enabled by some option, but just searching reviews
with queries like below works just ok:

project:^platform/buil. status:open
project:^platform/buil.* status:open
project:^platform/buil.+ status:open


So, I'm stumbled here - what could be wrong, and where to look next? 

Thanks,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: Releasing Linaro-patched repo tool, was: Re: Tracking Android kernel tips and Android builds

[Paul Sokolovsky]

On Tue, 6 Sep 2011 17:34:11 +0300
Fathi Boudra fathi.bou...@linaro.org wrote:

 On 6 September 2011 17:28, Alexander Sack a...@linaro.org wrote:
 
  On Tue, Sep 6, 2011 at 4:25 PM, Fathi Boudra
  fathi.bou...@linaro.org wrote:
 
  On 6 September 2011 08:28, Fathi Boudra fathi.bou...@linaro.org
  wrote:
   On 6 September 2011 00:15, Alexander Sack a...@linaro.org
   wrote:
   On Mon, Sep 5, 2011 at 10:37 PM, Paul Sokolovsky
   paul.sokolov...@linaro.org wrote:
  
   On Mon, 5 Sep 2011 14:36:48 +0300
   Paul Sokolovsky paul.sokolov...@linaro.org wrote:
  
   Ok, patched repo is available as:
  
  
   http://android.git.linaro.org/gitweb?p=tools/repo.git;a=blob_plain;f=repo;hb=refs/heads/linaro-stable
   that file should be downloaded and named as repo.
   Apparently, it should be mirrored at download servers.
  
  
   Right. where shall we put it? i think for AOSP you get it from
   an android.git.k.o URL. do we want to do something equivalent
   (e.g. android.git.l.o) or just put it on releases.linaro.org?
  
   It should be treated as a released components: releases.l.o,
   update release wiki/website download links.
   If it could be provided as upstream does (on android.git.l.o),
   +1.
 
  the patched version is available on:
 
  http://releases.linaro.org/platform/linaro-n/android/11.08/repo/repo-linaro-1.7.5-2011.08.tar.bz2
 
  http://launchpad.net/linaro-android/11.11/11.08/+download/repo-linaro-1.7.5-2011.08.tar.bz2
 
  and linked from:
  http://www.linaro.org/downloads/
  http://wiki.linaro.org/Cycles/1108/Release#Android_Components
 
 
  hmm. the AOSP repo can be wgetted without unpacking ...you
  basically just download the lightweight wrapper script instead of a
  tarball. IMO we should offer the same on top of the whole tarball
  as a component.
 
 I don't see any difference between wget  chmod +x vs wget  bunzip2
 I don't have a strong opinion on how AOSP does vs how Linaro
 components does.

As pointed out by folks, it's rather expectable to fetch bootstrap
script and be running it directly. As to where to place it, we don't
have direct access to android.git.linaro.org, so either that needs to go
thru IS (James, could you handle this?), or I'd suggest putting it at
somewhere like

http://releases.linaro.org/platform/android/repo

(yep, non-milestoned meta-util).

 
  Also this is not a 1108 component. it's 11.09 if anything.
 
 Paul mentioned an 11.08 errata.

Yes, I meant that patched repo we release now is needed to properly
fetch previous release 11.08 (and likely, older too). So, for
11.08 release notes, errata should be issued. On asac's request, I'm
doing complete matrix testing of 11.08 fetchability, and will provide
detailed results a bit later.

-- 
Best Regards,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

[RFC] Upgrade Jenkins EC2 plugin to 1.13 on Android Build

[Paul Sokolovsky]

Hello,

We're running Jenkins EC2 plugin v 1.11 on android-build.linaro.org,
which is 2 releases behind the latest 1.13. Per ChangeLog, it fixes
slave label expression evaluation, which affected me once when I tried
to do more flexible slave selection for builds (we fortunately were
able to get past it by the fact that we use same 64-bit slave type for
both platform and toolchain builds).

So, I'd like to schedule an upgrade some time next week, to allow for
sandbox testing and feedback collection time.

-- 
Best Regards,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: Releasing Linaro-patched repo tool, was: Re: Tracking Android kernel tips and Android builds

[Paul Sokolovsky]

On Mon, 5 Sep 2011 14:36:48 +0300
Paul Sokolovsky paul.sokolov...@linaro.org wrote:

Ok, patched repo is available as:
http://android.git.linaro.org/gitweb?p=tools/repo.git;a=blob_plain;f=repo;hb=refs/heads/linaro-stable
that file should be downloaded and named as repo. Apparently, it
should be mirrored at download servers.


 Hello Fathi,
 
 On Fri, 2 Sep 2011 13:19:11 -0500
 Zach Pfeffer zach.pfef...@linaro.org wrote:
 
 []
 
   But we already seem to have decided to use patched repo, no??
  
  Seems to be the consensus.
  
  Would you write up where to pull Linaro's repo from and why its
  different? Make sure the release engineers are in the loop. Adding
  fabo.
 
 The patches are available for review at:
 
 http://review.android.git.linaro.org/155
 http://review.android.git.linaro.org/156
 
 As soon as they approved, I'll be bale to provide downlike link to
 make a release. Fathi, would it make sense for you to register in
 Gerrit, to be able to be added as reviewer for patches which may be of
 interest to you, to stay in loop of their lifecycle? If so, please
 follow
 https://wiki.linaro.org/Platform/Android/Gerrit#Creating_Gerrit_Account
 
 Also note that teh issue affects 11.08 release, so please be ready to
 update release notes, errata for  it.
 
 In the meantime, I drafted a description page, feel free to update it
 as needed: https://wiki.linaro.org/Platform/Android/PatchedRepo
 
 
 



-- 
Best Regards,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: Tracking Android kernel tips and Android builds

[Paul Sokolovsky]

Hello Loïc,

On Fri, 2 Sep 2011 23:18:33 +0200
Loïc Minier loic.min...@linaro.org wrote:

 On Fri, Sep 02, 2011, Zach Pfeffer wrote:
  repo bootstraps itself by syncing the repo guts from google, google
  signs the repo guts so that people know that they're using a trusted
  source. As our repo in not a trusted source, people may be reluctant
  to use it and will instead use Google's version  which won't work
  100% of the time for the reasons already discussed.
 
  I think there's an env var to disable the auto-update of repo; we
 could set it in our instructions or in build wrappers, and/or we
 could patch repo to update itself from linaro.org instead.

There's switch telling where to update from, it is set to the right
value on Android Build. There's actually even switch which disables
auto-update (or one which you'd think does that), but it doesn't work,
surprise (typical surprise with all those repo/gerrit tools though).



-- 
Best Regards,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: Code review request.

[Paul Sokolovsky]

Hello Vishal,

On Fri, 2 Sep 2011 17:36:54 +0530
Vishal Bhoj vishal.b...@linaro.org wrote:

[]
  I had question, Can we commit multiple projects into gerrit in a
 single commit so that review would be easy ?

Some people wonder if that possible at all either, but Zach said he did
it once ;-). So, up to you to try (but please post instructions if you
figure it out).

 
 http://review.android.git.linaro.org/#change,139
 http://review.android.git.linaro.org/#change,140
 http://review.android.git.linaro.org/#change,141
 http://review.android.git.linaro.org/#change,142
 
 
 
 Thanks and Regards,
 Vishal



-- 
Best Regards,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: Tracking Android kernel tips and Android builds

[Paul Sokolovsky]

On Thu, 01 Sep 2011 18:21:30 -0400
James Westby james.wes...@canonical.com wrote:

 On Thu, 1 Sep 2011 17:10:03 -0500, Zach Pfeffer
 zach.pfef...@linaro.org wrote:
  We've had two instances of this problem for all the builds we've
  ever done. One instance was trying to sync u-boot and the other was
  trying to sync the TI LT kernel. John Rigby suggested the branch
  approach and it seems to have worked, so I'd like to go with that.
 
 Paul is working on a change to make tags usable as well. It seems to
 me that we have a couple of options
 
   1) Use branches long term. Paul can continue to push the patch for
   correctness sake, but we don't plan to use it.
 
   2) Use branches for now. Paul fixes repo to make tags usable, at
 which point we allow people (e.g. Andy) to use those too.
 
 Which would you advocate?

But we already seem to have decided to use patched repo, no??

 
 Thanks,
 
 James


-- 
Best Regards,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: Tracking Android kernel tips and Android builds

[Paul Sokolovsky]

On Thu, 1 Sep 2011 13:23:37 +0200
Alexander Sack a...@linaro.org wrote:

 On Thu, Sep 1, 2011 at 1:05 PM, Christian Robottom Reis
 k...@linaro.orgwrote:
 
  On Wed, Aug 31, 2011 at 02:19:08PM +0300, Paul Sokolovsky wrote:
   Hello Christian,
  
   On Tue, 30 Aug 2011 12:43:40 -0300
   Christian Robottom Reis k...@linaro.org wrote:
  
On Tue, Aug 30, 2011 at 01:25:15PM +0300, Paul Sokolovsky wrote:
 Yeah, I have patch for that. But we cannot use before upstream
 accepts it (because people will get errors checking out tree)
 and I don't hold my breath for that at all.
   
Why wouldn't we provide our own version of repo that worked
around this issue?
  
   By the same reason we don't fork entire Android itself and fixing
   it to work right? ;-)
 
  Either I'm missing the point or you are. We fork Android and
  everything else all the time; we then proceed to send the patches
  upstream and help them through the process, and so for me the
  fork is more like a cooperative branch.
 
  Look, this is a weird conversation and I want to get out of it as
  soon as I can. But you guys are overblowing the issue -- I'm just
  suggesting that if the patch will take a while to go upstream, you
  can ship a separate repo tool. We do this all the time in Linaro
  (just look at www.linaro.org/downloads).
 
 
 I agree with kiko here. If the repo patch would have a clearer
 indication in gerrit by now that this is not acceptable upstream I

It seems that they're really not against it. My concern was that tag
fetching was omitted deliberately to save on traffic and they would be
reluctant to add it. But it turned out that's actually not that
easy to do that on git's side using raw git fetch, in particular, git
fetch --tags, like I patched it first, indeed fetches *only* tags (and
git docs are confusing in this respect). But they even suggested how to
do it right, which I just have tested to work for our case:

https://pastebin.linaro.org/220/
https://pastebin.linaro.org/221/
https://pastebin.linaro.org/222/

review.source.android.com is down now (hmm, is it hosted on the same
host as android.git.kernel.org ?), but I'll prepare new version of the
patch when it's up.

 would have agreed to think about a solution on the git branch policy
 side. But if the lack of --tag hurts us now badly we should work
 around somehow by patching repo etc. until that patch discussion
 gives us more assurance that adopting everyone's workflow is not just
 for the sake of a temporary bandaid.

Well, it's very easy for me to prepare a new repo branch and hand out a
download link to release managers if that's what we want. But as
it's just milestone start, let's hope it might land in upstream indeed.


-- 
Best Regards,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: Tracking Android kernel tips and Android builds

[Paul Sokolovsky]

Hello Christian,

On Tue, 30 Aug 2011 12:43:40 -0300
Christian Robottom Reis k...@linaro.org wrote:

 On Tue, Aug 30, 2011 at 01:25:15PM +0300, Paul Sokolovsky wrote:
  Yeah, I have patch for that. But we cannot use before upstream
  accepts it (because people will get errors checking out tree) and I
  don't hold my breath for that at all.
 
 Why wouldn't we provide our own version of repo that worked around
 this issue?

By the same reason we don't fork entire Android itself and fixing it to
work right? ;-) repo is kind of foundation of Android development,
axiom or something. It's like saying that someone can't do kernel
development because git is broken, so one must stop, fix git in
incompatible way and then distribute one's tree requiring that git
version. Hardly would work. Productive way is: 1) adjust to existing set
of axioms; 2) slowly push for them to be changed if adjusting caused
continued everyday pain.

-- 
Best Regards,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: Tracking Android kernel tips and Android builds

[Paul Sokolovsky]

On Tue, 30 Aug 2011 22:40:57 -0500
Zach Pfeffer zach.pfef...@linaro.org wrote:

[]
 The tag thing is a means to an end, to keep the sha's around. If we
 just tracked history trees we'd be fine, but all the rebasing causes
 refs to become unreachable. All trees in Android should be history
 trees so we shouldn't have a problem, but not everyone see's things
 that way so we have the current disappearing sha problem.

Well, asking integration (aka Landing) teams to stop using integration
trees (those which are rebased up and down), a legitimate and best
practice for their kind of usage, is for sure too high a price for
wanting to use SHAs in manifests.


-- 
Best Regards,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: Tracking Android kernel tips and Android builds

[Paul Sokolovsky]

Hello Andy,

On Mon, 29 Aug 2011 23:13:07 +0800
Andy Green andy.gr...@linaro.org wrote:

 On 08/29/2011 09:22 PM, Somebody in the thread at some point said:
 
  It's not enough if you still want to refer to it via SHA, due to
  repo peculiarities. It should be also reachable from one of the live
  branches (so, instead of a tag, a branch can be created right away).
 
 Sorry... this means for a rebase tree, we have to spawn a new branch
 per push to public git?  We already spawn a tag per push to keep a
 finger on the tree so it won't be garbage collected: no great
 problem, but a branch per push?

That's why I was talking about LT and Android team doing it in manual
sync (before release) for now. But yes, such transient branches
(instead of tags) are needed (repo fetched all branches, but only tags
directly accessible from those branches).

 
 Is it perhaps possible to improve repo instead?

Yeah, I have patch for that. But we cannot use before upstream accepts
it (because people will get errors checking out tree) and I don't hold
my breath for that at all.

 
 -Andy
 



-- 
Best Regards,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: Tracking Android kernel tips and Android builds

[Paul Sokolovsky]

On Mon, 29 Aug 2011 10:41:59 -0500
Zach Pfeffer zach.pfef...@linaro.org wrote:

 On 29 August 2011 10:13, Andy Green andy.gr...@linaro.org wrote:
  On 08/29/2011 09:22 PM, Somebody in the thread at some point said:
 
  It's not enough if you still want to refer to it via SHA, due to
  repo peculiarities. It should be also reachable from one of the
  live branches (so, instead of a tag, a branch can be created right
  away).
 
  Sorry... this means for a rebase tree, we have to spawn a new
  branch per push to public git?  We already spawn a tag per push to
  keep a finger on the tree so it won't be garbage collected: no
  great problem, but a branch per push?
 
 I think this can just happen as part of the build cycle. If we track
 the tree directly the build system can lay down a branch automatically
 after release.
 
 We could probably just update the branch after the automerge step. For
 those who are just getting their feet wet with CI the flow is:
 
 Sync build
 Apply patch
 Build
 Regress build
 on regress success, merge patch
 Save build, gen pinned-manifest
 
 Anyway, this isn't an issue with repo, its a sha1 reachability issue.
 repo 's just a foreach git tool.

Let's just look at it from different side - repo is not designed to
work with manifests containing raw SHA revs, google doesn't bless
that ;-)

 
  Is it perhaps possible to improve repo instead?
 
  -Andy
 
  --
  Andy Green | TI Landing Team Leader
  Linaro.org │ Open source software for ARM SoCs | Follow Linaro
  http://facebook.com/pages/Linaro/155974581091106  -
  http://twitter.com/#!/linaroorg - http://linaro.org/linaro-blog
 



-- 
Best Regards,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: Tracking Android kernel tips and Android builds

[Paul Sokolovsky]

On Mon, 29 Aug 2011 12:15:15 -0500
Zach Pfeffer zach.pfef...@linaro.org wrote:

[]
  We could probably just update the branch after the automerge step.
  What do you mean SHA1 reachability?  I can reach arbitrary
  HEADs using a hash even if they're not tagged so long as I didn't
  garbage collect.  If I tagged them they're guaranteed to not be
  garbage collected.  I can always reach them for checkout.  So
  what is this reachability issue?
 
  The way Paul described it, it sounds like a limitation with this
  repo script that it depends on specifically a branch has been
  checked out.
 
 All repo is doing with a pinned-manifest.xml is:
 
 foreach git in this manifest
 checkout sha1
 
 so as long as you can checkout the sha1 everything is cool. The reason
 we're using this is because we can automatically create a manifest
 with the sha1's of every sub git head that we built. This allows
 someone to reproduce the build exactly and allows us to ship what we
 test. If you can apply the same tag across all gits, which we can do
 now, and that'll keep the sha's around than that's what we should do.

Yes, and we also should use *that tag* in the manifest!

 
  Is it perhaps possible to improve repo instead?
 
  -Andy
 
  --
  Andy Green | TI Landing Team Leader
  Linaro.org │ Open source software for ARM SoCs | Follow Linaro
  http://facebook.com/pages/Linaro/155974581091106  -
  http://twitter.com/#!/linaroorg - http://linaro.org/linaro-blog
 



-- 
Best Regards,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: Tracking Android kernel tips and Android builds

[Paul Sokolovsky]

On Mon, 29 Aug 2011 18:42:29 +0200
Alexander Sack a...@linaro.org wrote:

 On Mon, Aug 29, 2011 at 3:22 PM, Paul Sokolovsky
 paul.sokolov...@linaro.org
  wrote:
 
  It's not enough if you still want to refer to it via SHA, due to
  repo peculiarities. It should be also reachable from one of the live
  branches (so, instead of a tag, a branch can be created right away).
 
 
 Paul, what happened to the repo patch we had that would also fetch
 tags? was that ever submit this to gerrit? on the mailing list we
 didn't receive any resistance to fix this. If its an easy landing
 upstream I would prefer that over adding create branch for
 everything policy.

It waited its turn in queue. Well, now here it is:
https://review.source.android.com/25843


-- 
Best Regards,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

[ANN] Android Build/LAVA Continuous Integration

[Paul Sokolovsky]

Hello,

Initial integration of Android Build and LAVA was launched in 11.07, so
works fore more than month now, but you couldn't pleasantly look at its
results. Thanks to efforts of the Validation team, now much improved UI
integration is launched, see Test results section at 
https://android-build.linaro.org/builds/~linaro-android/panda/#build=250
for example.

For me, this is important point - there're lot to fix, improve, and
extends yet, but finally it feels like we have advanced, powerful,
extensible testing platform straight in our hands.

Kudos to Validation team!

-- 
Best Regards,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: Tracking Android kernel tips and Android builds

[Paul Sokolovsky]

On Mon, 29 Aug 2011 08:08:17 -0500
Zach Pfeffer zach.pfef...@linaro.org wrote:

 Now that we have an Android build for every board and Gerrit and LAVA
 I'd like to unify how we handle kernels for each so that we can work
 more efficiently, start to unify the kernels and provide a means for
 external Android users to start to improve these trees.
 
 First, since we control the kernels that go into our Android builds
 I'd like to follow AOSP convention and have:
 
 kernel/common.git (john's tree)

Correction: kernel/common is AOSP upstream, John's tree is
kernel/linux-android .

 kernel/imx53.git
 kernel/omap.git
 kernel/origen.git
 kernel/snowball.git

These looks ok and in line with existing AOSP's naming conventions.

 
 (right now we have:
 
 panda, beagle
 remote name=linaro-other fetch=git://git.linaro.org//
 project path=kernel name=people/jstultz/android
 revision=linaro-android-3.0 remote=linaro-other/
 
 panda-leb
 remote name=linaro-other fetch=git://git.linaro.org//
 project path=kernel name=people/andygreen/kernel-tilt
 revision=tilt-jstultz-linaro-android-3.0 remote=linaro-other/
 
 leb-snowball
 remote name=linaro-other fetch=git://git.linaro.org//
 project path=kernel name=bsp/st-ericsson/linux-3.0-android-ux500
 revision=master remote=linaro-other/
 
 leb-origen
 remote name=linaro-other fetch=git://git.linaro.org//
 project path=kernel name=people/angus/linux-linaro-3.0
 remote=linaro-other revision=android/
 
 leb-imx53
 remote fetch=git://git.linaro.org/ name=linaro-other/
 project name=people/bernhardrosenkranzer/android-kernel-iMX53
 path=kernel remote=linaro-other
 revision=3d981d9418c53e3e1a079582088121c641588791/
 )
 
 I'd like these to be at git://android.git.linaro.org/. I'd like to
 not mirror.
 
 Each tree would accept patches via Gerrit and be maintainable through
 standard git by the tree maintainers. This should allow upgrades to
 each, without needing to push all the upgrade patches through Gerrit.
 
 Next, we'd like to point to a tip branch for each of these trees. This
 branch would be were development would be happening. Tracking tip is
 fundamental to continuous integration, if its broken then the primary
 job of everyone should be getting it going again. I'd like to suggest
 the branches be named the same and follow John's branch naming
 convention:
 
 linaro-android-3.0...etc
 
 Lastly, I'd like to request (and we may be able to automate this once
 all the kernels are co-located) that once a pinned-manifest.xml comes
 out, referencing a specific sha1, I'd like to lay a tag on that sha so
 it sticks around. 

It's not enough if you still want to refer to it via SHA, due to repo
peculiarities. It should be also reachable from one of the live
branches (so, instead of a tag, a branch can be created right away).

 Its better to tag after the fact because it saves
 having to do another build/test/qa cycle and will ensure that our
 pinned-manifest.xml continue to work.
 
 I suspect a few growing pains, but I think this is going to be great.
 Once the kernels are co-located we should be able to look at Gerrit
 extensions that allow easier upstream patch submission and tracking.
 We should also be able to more easily refactor things. Using the
 Gerrit flow and extending it to support Android upstreaming is exactly
 the thing Linaro was built for. Since Gerrit is such an integral part
 of Android development, extensions to allow patch propagation would
 allow a lot of the good work to flow back into the mainline kernel.
 
 -Zach



-- 
Best Regards,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

[MAINT] Android Build diskspace upgrade tomorrow

[Paul Sokolovsky]

Hello,

We're out of disk space on android-build.linaro.org, and I'd like to
schedule upgrade tomorrow, 17:00UTC. Estimated downtime duration 1hr.

Please let me know if that time doesn't work for you.

-- 
Best Regards,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: Update on Gerrit deployment

[Paul Sokolovsky]

Hello Zach,

On Thu, 25 Aug 2011 18:12:01 -0500
Zach Pfeffer zach.pfef...@linaro.org wrote:

[]
  I also updated Linaro Gerrit howto:
  https://wiki.linaro.org/Platform/Android/Gerrit , which now should
  have all info to have one started quickly with Gerrit, and cover
  all aspects of Gerrit setup (like upstream mirroring and permission
  settings). I'd appreciate review of that and letting me know if
  something is missing there.
 
 This looks really good. Please share this with the repo mailing list.
 Your great work has really helped other people trying to set up their
 own Gerrit instances.

I did so per your previous request, during LC.

 
  Finally few points we can continue with to elaborate our usage of
  Gerrit:
 
  1. Set up branch policy (naming, etc.) and enforce it on Gerrit
  level. This may require revamping branching in other toolchain/*
  components (upstreamed not from AOSP), but in the end we'll get
  really robust development setup.
 
 Agreed. One big thing that we need to work on is how we're going to
 handle kernel upgrades - I think some special branch-naming may be
 part of this solution.
 
  2. Turn off review bypass option which was available during
  transition process. I guess Android team if comfortable by now with
  new process (there're more than 80 patches passed thru review by
  now!), so once 11.08 release is out, it would be good time to do
  that.
 
 +1 for most. I think the only thing we have to watch out for is kernel
 maintainers needing to push big updates out-of-band.

Whenever I talk about Gerrit workflow, I mean Gerrit workflow for
Android platform components, skipping kernels ;-). There would be
apparently 2 different workflows, and we need to settled main Android
workflow and let kernel guys try and use Gerrit and see what's
comfortable for them (starting with complete git access). We already
have beginning of such setup, with John being in Kernel Hackers
group, which allows rebases and upstream pulling for
kernel/linux-android.


-- 
Best Regards,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Update on Gerrit deployment

[Paul Sokolovsky]

Hello,

Some time passed since last update on Gerrit deployment, that's
because work on complete AOSP mirroring to out tree took longer than
expected. All in all, following was done:

Revamped branching in our toolchain/* components, freed room for
upstream branches, mirrored them.

Mirrored AOSP kernel components. That was something I was putting
off until latest, knowing that it would bring enough burden, like
increasing storage space, increasing sync time, etc. Until last I wasn't
sure if they should mirrored, but something which turned scale is
recent talk about possibility to provide image for consumer phones from
Google (for which we may want to hack kernels as provided by AOSP).
Other point was just having complete AOSP mirror, and writing that
question off forever, freeing space for other work. So, I proceeded
with doing it, which soon led to OutOfMemory in Gerrit, so it's
probably good that it got uncovered during deployment, than later.
Thanks to IS, memory and Gerrit size were increased, and kernel imports
finished successfully.

That means that we have complete mirror of upstream AOSP tree, and out
tree is a proper superset of AOSP. The only workitem left is setting up
automated upstream syncing via cron (so far I've been doing this
manually), and we have nice tree set up with upstream at our fingertips
(without having availability issues during builds, etc.), and at the
same time, have all freedom to do any stuff on top of it (branching,
tagging, etc.)

I also updated Linaro Gerrit howto:
https://wiki.linaro.org/Platform/Android/Gerrit , which now should have
all info to have one started quickly with Gerrit, and cover all aspects
of Gerrit setup (like upstream mirroring and permission settings). I'd
appreciate review of that and letting me know if something is missing
there.


Finally few points we can continue with to elaborate our usage of
Gerrit:

1. Set up branch policy (naming, etc.) and enforce it on Gerrit level.
This may require revamping branching in other toolchain/* components
(upstreamed not from AOSP), but in the end we'll get really robust
development setup.

2. Turn off review bypass option which was available during transition
process. I guess Android team if comfortable by now with new process
(there're more than 80 patches passed thru review by now!), so once
11.08 release is out, it would be good time to do that.


-- 
Best Regards,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: Hi everyone, I'm glad to announce the Linaro Android image 11.08 RC for Samsung Origen board.

[Paul Sokolovsky]

On Mon, 22 Aug 2011 23:24:41 +0800
Botao Sun botao@linaro.org wrote:

 Hi everyone,
 
 As our release plan, you can get the 11.08 release candidate of Linaro
 Android image for Samsung Origen board:
 
 https://android-build.linaro.org/builds/~linaro-android/leb-origen-11.08-release/#build=2

Great work, Botao! Let me know if you'd like to add some description to
be shown on that page, like subset of the instructions you give below.

 
 After you download these 3 files (if you download them with wget in
 console, you may need to enable --no-check-certificate option),
 
 https://android-build.linaro.org/jenkins/job/linaro-android_leb-origen-11.08-release/2/artifact/build/out/target/product/origen/boot.tar.bz2
 https://android-build.linaro.org/jenkins/job/linaro-android_leb-origen-11.08-release/2/artifact/build/out/target/product/origen/system.tar.bz2
 https://android-build.linaro.org/jenkins/job/linaro-android_leb-origen-11.08-release/2/artifact/build/out/target/product/origen/userdata.tar.bz2
 
 flash them into a SD card with Linaro image tools (bzr branch
 lp:linaro-image-tools, if you're already a launch member):
 
 sudo ./linaro-image-tools/linaro-android-media-create --mmc /dev/sdx
 --dev smdkv310 --system system.tar.bz2 --boot boot.tar.bz2 --userdata
 userdata.tar.bz2
 
 You also may need to set boot arguments if you can't boot into the
 system (normally you don't need to do this):
 
 setenv bootargs console=ttySAC2,115200n8 root=/dev/ram init=/init
 rootwait ro
 setenv bootcmd fatload mmc 0:2 0x40007000 uImage; fatload mmc 0:2
 0x4200 uInitrd; bootm 0x40007000 0x4200
 saveenv
 
 This image hasn't lighted the LCD screen yet, this issue is related
 to the hardware driver and I'm working with my colleagues to try to
 solve it. I'm afraid it will miss the 11.08 release, sorry.
 
 The kernel version in this image is 3.0.0, and the busybox version is
 1.19.0, you can find it under /system/bin. This RC image was compiled
 by our 11.08 tool chain, RC build:
 https://android-build.linaro.org/builds/~linaro-android/toolchain-4.6-2011.08/#build=6.
 I will continue to work on the official release to ensure it can be
 done before 25th August 2011, 16:00 (UTC).
 
 Thank you all for your great efforts!
 
 
 BR
 Botao Sun



-- 
Best Regards,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: 11.08 Android toolchain RC is ready

[Paul Sokolovsky]

Hello Bernhard,

On Fri, 19 Aug 2011 23:47:26 -0700
Bernhard Rosenkranzer bernhard.rosenkran...@linaro.org wrote:

 Hi,
 the 11.08 Android toolchain RC is ready:
 
 https://android-build.linaro.org/builds/~linaro-android/toolchain-4.6-2011.08/#build=6
 https://android-build.linaro.org/jenkins/job/linaro-android_toolchain-4.6-2011.08/6/artifact/build/out/android-toolchain-eabi-linaro-4.6-2011.08-6-2011-08-19_20-41-31-linux-x86.tar.bz2
 
 The good news is that this build has been tested and seems to work
 fine for everything so far.

Have you guys worked all night - when I went to bed, android-build was
busy with the builds, and I woke up and it's busy either ;-). Great
work!

Did you have a chance to look at 4.5 build:
https://android-build.linaro.org/jenkins/job/pfalcon_toolchain-4.5-2011.08-linaro-master/2/parsed_console/
 ?
Or would you have one? Just in case, I'd like to discuss contingency
plan for 4.5 release either. 4.5 builds against last-month's toolchain
bundling:
https://android-build.linaro.org/jenkins/job/pfalcon_toolchain-4.5-2011.08-linaro-android-11.07-release/
Releasing 4.6  4.5 against different tags/branches of toolchain/* is
not ideal, but we could do that if needed (assuming it would be fixed
next milestone).

Thanks,
Paul

 The bad news is that we did that by reverting the switch from the
 arm-eabi to the arm-linux-androideabi target, losing support for
 OpenMP and friends. My theory is that the combination of an
 arm-linux-androideabi toolchain and the mess in the Android build
 system that works around the toolchain not knowing anything about the
 OS simply don't go well together. We should investigate this further
 for the next release.
 
 Other than that, this toolchain build seems to be ready for release.
 Let me know if you run into any problems.
 
 ttyl
 bero



-- 
Best Regards,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: Announcement:Linaro Android 2.3.5

[Paul Sokolovsky]

On Wed, 17 Aug 2011 11:00:32 +0200
Patrik Ryd patrik@linaro.org wrote:

 Hi,
 
 Linaro Android has now moved up to 2.3.5.
 
 The daily builds (https://android-build.linaro.org/index) are now
 based on the linaro_android_2.3.5 branch of the manifest.
 
 Please rebase any dev_branches you have to 2.3.5. The
 linaro_android_2.3.4 branch will no longer be supported.

And another quick reminder just in case somebody missed it before -
Linaro Android tree has moved to http://android.git.linaro.org/ , so if
you're still using old checkout, this is good timing to do fresh
checkout for 2.3.5 upgrade.

https://wiki.linaro.org/Platform/Android/GetSource has more info, as
usual.


-- 
Best Regards,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: [ANN] Linaro Android tree hosting switched to Gerrit

[Paul Sokolovsky]

Hello,

Further update on Gerrit assimilation:

1. LEB-panda build was fixed.
2. Our previous Android component forks were synced with upstream
(need to have extra pass on this to make sure nothing is missed).
3. Old tree is back at git.linaro.org/android/
4. Android team is well under way on setting Gerrit-based workflow.


Thanks,
Paul


On Wed, 10 Aug 2011 20:31:11 +0300
Paul Sokolovsky paul.sokolov...@linaro.org wrote:

 [originally sent from wrong email, so not sure if got thru]
 
 Hello,
 
 Linaro Android codebase migration to Gerrit, which was announced at
 Linaro Connect, happened today. From now, Linaro Android is available
 via:
 
 http://android.git.linaro.org/
 
 Accompanied by Gerrit frontend at:
 
 http://review.android.git.linaro.org/
 
 It is recommended to perform a fresh checkout of the tree. To do that,
 run:
 
 repo init -u git://android.git.linaro.org/platform/manifest.git \
   -b branch \
   -m manifest
 
 branch and manifest are those you used before. E.g. 
 
 repo init -u git://android.git.linaro.org/platform/manifest.git \
   -b linaro_android_2.3.4 \
   -m default.xml
 
 
 The official Linaro builds at https://android-build.linaro.org/ were
 converted to use new manifest location, and I'd like to ask other
 developers to convert their personal builds (I'm not trying to
 automate this so far, to make that everyone was in loop on what
 changed and how). To update, just change in a build config:
 
 MANIFEST_REPO=git://git.linaro.org/android/platform/manifest.git
 
 to
 
 MANIFEST_REPO=git://android.git.linaro.org/platform/manifest.git
 
 Old tree (git.linaro.org/android/*) was made inaccessible for the time
 being to help with updating all references to it. It should be back up
 shortly in read-only mode. (If there're immediate concerns, it's at
 git.linaro.org/android-old/ now and can be renamed back by anyone with
 git.linaro.org access).
 
 With the spirit of making one change at time, all developers still
 should have permissions similar to what they had before: anyone can
 still create branches and push changes directly to them (*1). However,
 once we finish updating build configs and docs for new tree location,
 the next step will be setting up a workflow based on mandatory code
 review, so I'd like to invite all developers to practice that right
 away. Details on how to submit change for review are given at
 https://wiki.linaro.org/Platform/Android/Gerrit (in particular, repo
 upload works now).
 
 (*1) The remote for such commits is different now of course, like
 this: ssh://pfal...@android.git.linaro.org:29418/platform/build .
 Replace pfalcon with you gerrit username and platform/build is the
 component you need.
 
 
 Please share any issues, concerns, and questions you may have related
 to this migration.
 
 



-- 
Best Regards,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: [ANN] Linaro Android tree hosting switched to Gerrit

[Paul Sokolovsky]

On Fri, 12 Aug 2011 15:13:39 +0300
Paul Sokolovsky paul.sokolov...@linaro.org wrote:

 Hello,
 
 Further update on Gerrit assimilation:
 
 1. LEB-panda build was fixed.
 2. Our previous Android component forks were synced with upstream
 (need to have extra pass on this to make sure nothing is missed).
 3. Old tree is back at git.linaro.org/android/
 4. Android team is well under way on setting Gerrit-based workflow.

Forgot big thing - it's important that Gerrit logins happened using
https://login.launchpad.net; SSO OpenID and there was no other OpenID
identities were attached to your account (including no
https://launchpad.net/~username). Please update instructions at
https://wiki.linaro.org/Platform/Android/Gerrit#Creating_Gerrit_Account
on how to check/fix this.



 
 
 Thanks,
 Paul
 
 
 On Wed, 10 Aug 2011 20:31:11 +0300
 Paul Sokolovsky paul.sokolov...@linaro.org wrote:
 
  [originally sent from wrong email, so not sure if got thru]
  
  Hello,
  
  Linaro Android codebase migration to Gerrit, which was announced at
  Linaro Connect, happened today. From now, Linaro Android is
  available via:
  
  http://android.git.linaro.org/
  
  Accompanied by Gerrit frontend at:
  
  http://review.android.git.linaro.org/
  
  It is recommended to perform a fresh checkout of the tree. To do
  that, run:
  
  repo init -u git://android.git.linaro.org/platform/manifest.git \
-b branch \
-m manifest
  
  branch and manifest are those you used before. E.g. 
  
  repo init -u git://android.git.linaro.org/platform/manifest.git \
-b linaro_android_2.3.4 \
-m default.xml
  
  
  The official Linaro builds at https://android-build.linaro.org/ were
  converted to use new manifest location, and I'd like to ask other
  developers to convert their personal builds (I'm not trying to
  automate this so far, to make that everyone was in loop on what
  changed and how). To update, just change in a build config:
  
  MANIFEST_REPO=git://git.linaro.org/android/platform/manifest.git
  
  to
  
  MANIFEST_REPO=git://android.git.linaro.org/platform/manifest.git
  
  Old tree (git.linaro.org/android/*) was made inaccessible for the
  time being to help with updating all references to it. It should be
  back up shortly in read-only mode. (If there're immediate concerns,
  it's at git.linaro.org/android-old/ now and can be renamed back by
  anyone with git.linaro.org access).
  
  With the spirit of making one change at time, all developers still
  should have permissions similar to what they had before: anyone can
  still create branches and push changes directly to them (*1).
  However, once we finish updating build configs and docs for new
  tree location, the next step will be setting up a workflow based on
  mandatory code review, so I'd like to invite all developers to
  practice that right away. Details on how to submit change for
  review are given at https://wiki.linaro.org/Platform/Android/Gerrit
  (in particular, repo upload works now).
  
  (*1) The remote for such commits is different now of course, like
  this: ssh://pfal...@android.git.linaro.org:29418/platform/build .
  Replace pfalcon with you gerrit username and platform/build is the
  component you need.
  
  
  Please share any issues, concerns, and questions you may have
  related to this migration.
  
  
 
 
 



-- 
Best Regards,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: Marking a toolchain or build releasable - for saving.

[Paul Sokolovsky]

On Thu, 11 Aug 2011 22:26:15 -0500
Zach Pfeffer zach.pfef...@linaro.org wrote:

 Paul,
 
 I was wondering if we could make a small change to android-build. I
 just recently tested:
 
 https://android-build.linaro.org/builds/~linaro-android/leb-panda/#build=166
 
 It works great and I'd like to move it to a first 11.08 release. Its
 based on toolchain:
 
 https://android-build.linaro.org/jenkins/job/linaro-android_toolchain-4.6-2011.07/8/artifact/build/out/android-toolchain-eabi-linaro-4.6-2011.07-0-8-2011-07-25_12-42-06-linux-x86.tar.bz2
 
 I'd like to simply mark this build as releasable and have it save
 the toolchain 

What do you mean by save the toolchain here?

 and commit the pinned-manifest.xml to 11.08.
 
 Any thoughts?

I guess I'm thinking like asac now, so Sounds good, worth being
blueprinted, let's see if it fits 11.09. Actually, I'd be able to
start with it even for 11.08, if there will be room between Gerrit
switchover and LAVA integration work.

 
 -Zach



-- 
Best Regards,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: Marking a toolchain or build releasable - for saving.

[Paul Sokolovsky]

On Fri, 12 Aug 2011 09:01:14 -0500
Zach Pfeffer zach.pfef...@linaro.org wrote:

 Oh, the other thing is to generate the pinned-manifest.xml before the
 build is made so that the build comes from the pinned-manifest.
 This'll save us a step.

One reliable way to do this is tagging, like I argued the other time.
We start build with tagging all components with (special) tag for this
builds number. Then checkout exactly that tag (that will be a bit more
complicated than usual with repo and its manifests), then do build,
then can reproduce it 100% without recoursing to raw SHA1 revids. If
one specific build is useful, we can re-tag it normal tags.
Otherwise, those special build tags will be expire after some time t
avoid pile-up.

 
 On 11 August 2011 22:26, Zach Pfeffer zach.pfef...@linaro.org wrote:
  Paul,
 
  I was wondering if we could make a small change to android-build. I
  just recently tested:
 
  https://android-build.linaro.org/builds/~linaro-android/leb-panda/#build=166
 
  It works great and I'd like to move it to a first 11.08 release. Its
  based on toolchain:
 
  https://android-build.linaro.org/jenkins/job/linaro-android_toolchain-4.6-2011.07/8/artifact/build/out/android-toolchain-eabi-linaro-4.6-2011.07-0-8-2011-07-25_12-42-06-linux-x86.tar.bz2
 
  I'd like to simply mark this build as releasable and have it save
  the toolchain and commit the pinned-manifest.xml to 11.08.
 
  Any thoughts?
 
  -Zach
 



-- 
Best Regards,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: Marking a toolchain or build releasable - for saving.

[Paul Sokolovsky]

On Fri, 12 Aug 2011 18:05:29 +0300
Paul Sokolovsky paul.sokolov...@linaro.org wrote:

 On Fri, 12 Aug 2011 09:01:14 -0500
 Zach Pfeffer zach.pfef...@linaro.org wrote:
 
  Oh, the other thing is to generate the pinned-manifest.xml before
  the build is made so that the build comes from the pinned-manifest.
  This'll save us a step.
 
 One reliable way to do this is tagging, like I argued the other time.
 We start build with tagging all components with (special) tag for this
 builds number. Then checkout exactly that tag (that will be a bit more
 complicated than usual with repo and its manifests), then do build,
 then can reproduce it 100% without recoursing to raw SHA1 revids. If
 one specific build is useful, we can re-tag it normal tags.
 Otherwise, those special build tags will be expire after some time t
 avoid pile-up.

Oh well, but that's complicated by the fact that we have read-only
intermediate mirror for build ;-\ .


-- 
Best Regards,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: Hacking Android from a Toolchain perspective

[Paul Sokolovsky]

Hello Michael,

On Thu, 11 Aug 2011 16:30:42 +1200
Michael Hope michael.h...@linaro.org wrote:

 Hi there.  One of our goals in toolchain is to give good support to
 the Android group.  I've written a page from the toolchain perspective
 on what is Android, how do you build it, and how you do common
 toolchainy tasks like reproduce a compiler fault:
  https://wiki.linaro.org/MichaelHope/Sandbox/AndroidAndToolchain
 
 Comments are welcome.  It needs sections on how the compiler is
 configured, running a program using adb, and basic debugging.

From the wiki page:

Grab the configuration from the page. As at 2011-08-10 this is:
MANIFEST_REPO=git://git.linaro.org/android/platform/manifest.git

Actually, from 2011-08-10, we switched to Gerrit for hosting and that
line should be:

MANIFEST_REPO=git://android.git.linaro.org/platform/manifest.git

(there was announcement with instructions on the list yesterday). 

I'm in the process of fixing references in the wiki, but it's important
that other people were in the loop of the change, so I'd like to ask
everyone who recently wrote docs referencing old
git.linaro.org/android/ location to update them. (It's important
because old tree will be still online, so whoever will be using it
will use old static code.)


Thanks,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: [ANN] Linaro Android tree hosting switched to Gerrit

[Paul Sokolovsky]

Hello Zach,

On Thu, 11 Aug 2011 00:23:00 -0500
Zach Pfeffer zach.pfef...@linaro.org wrote:

 This looks really great Paul. Thanks!
 
 Time to start pushing changes...

Actually, it would be nice for people to concentrate on updating their
build configs, docs, exercising build system, to make sure that our
existing infrastructure works ok (there're already known issues), before
moving to explore Gerrit opportunities.

Thanks,
Paul

 
 On 10 August 2011 12:48, Paul Sokolovsky paul.sokolov...@linaro.org
 wrote:
  On Wed, 10 Aug 2011 20:31:11 +0300
  Paul Sokolovsky paul.sokolov...@linaro.org wrote:
 
  [originally sent from wrong email, so not sure if got thru]
 
  []
  The official Linaro builds at https://android-build.linaro.org/
  were converted to use new manifest location, and I'd like to ask
  other developers to convert their personal builds (I'm not trying
  to automate this so far, to make that everyone was in loop on what
  changed and how). To update, just change in a build config:
 
  MANIFEST_REPO=git://git.linaro.org/android/platform/manifest.git
 
  to
 
  MANIFEST_REPO=git://android.git.linaro.org/platform/manifest.git
 
  I should also add that I updated manifests living at
  git://android.git.linaro.org/platform/manifest.git in
  linaro_android_2.3.4 and linaro-android-11.08-release branches.
  Manifests in other locations and branches need to be updated
  manually. Look at
  http://android.git.linaro.org/gitweb?p=platform/manifest.git;a=shortlog;h=refs/heads/linaro_android_2.3.4
  for details.
 
 
  --
  Best Regards,
  Paul
 
  Linaro.org | Open source software for ARM SoCs
  Follow Linaro: http://www.facebook.com/pages/Linaro
  http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog
 
  ___
  linaro-dev mailing list
  linaro-dev@lists.linaro.org
  http://lists.linaro.org/mailman/listinfo/linaro-dev
 



-- 
Best Regards,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: [ANN] Linaro Android tree hosting switched to Gerrit

[Paul Sokolovsky]

Hello,

Here's update on the migration process:

1. I've made first pass thru updating wiki with new Android tree
location.
2. LEB-Panda currently doesn't build. That's because it turned out that
we have none tags at all in our existing (forked) Android components,
and manifest of leb-panda appears to refer to one of them.

My plan for today is to investigate and fix LEB-Panda breakage and
work towards setting up automated upstream sync process.

Few people asked how they can help with migration, and the answer is to
update their jobs on android-build.linaro.org, making sure they build
ok, updating their docs in wiki or elsewhere which may contain
references to old location, prodding colleagues to do the same ;-).

It would be nice if we focused on this for couple of days, as it will
be more complicated if we'll discover some serious issue later or just
will need to deal with corner cases again and again.


Thanks,
Paul


On Wed, 10 Aug 2011 20:31:11 +0300
Paul Sokolovsky paul.sokolov...@linaro.org wrote:

 [originally sent from wrong email, so not sure if got thru]
 
 Hello,
 
 Linaro Android codebase migration to Gerrit, which was announced at
 Linaro Connect, happened today. From now, Linaro Android is available
 via:
 
 http://android.git.linaro.org/
 
 Accompanied by Gerrit frontend at:
 
 http://review.android.git.linaro.org/
 
 It is recommended to perform a fresh checkout of the tree. To do that,
 run:
 
 repo init -u git://android.git.linaro.org/platform/manifest.git \
   -b branch \
   -m manifest
 
 branch and manifest are those you used before. E.g. 
 
 repo init -u git://android.git.linaro.org/platform/manifest.git \
   -b linaro_android_2.3.4 \
   -m default.xml
 
 
 The official Linaro builds at https://android-build.linaro.org/ were
 converted to use new manifest location, and I'd like to ask other
 developers to convert their personal builds (I'm not trying to
 automate this so far, to make that everyone was in loop on what
 changed and how). To update, just change in a build config:
 
 MANIFEST_REPO=git://git.linaro.org/android/platform/manifest.git
 
 to
 
 MANIFEST_REPO=git://android.git.linaro.org/platform/manifest.git
 
 Old tree (git.linaro.org/android/*) was made inaccessible for the time
 being to help with updating all references to it. It should be back up
 shortly in read-only mode. (If there're immediate concerns, it's at
 git.linaro.org/android-old/ now and can be renamed back by anyone with
 git.linaro.org access).
 
 With the spirit of making one change at time, all developers still
 should have permissions similar to what they had before: anyone can
 still create branches and push changes directly to them (*1). However,
 once we finish updating build configs and docs for new tree location,
 the next step will be setting up a workflow based on mandatory code
 review, so I'd like to invite all developers to practice that right
 away. Details on how to submit change for review are given at
 https://wiki.linaro.org/Platform/Android/Gerrit (in particular, repo
 upload works now).
 
 (*1) The remote for such commits is different now of course, like
 this: ssh://pfal...@android.git.linaro.org:29418/platform/build .
 Replace pfalcon with you gerrit username and platform/build is the
 component you need.
 
 
 Please share any issues, concerns, and questions you may have related
 to this migration.
 
 



-- 
Best Regards,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

[ANN] Linaro Android tree hosting switched to Gerrit

[Paul Sokolovsky]

[originally sent from wrong email, so not sure if got thru]

Hello,

Linaro Android codebase migration to Gerrit, which was announced at
Linaro Connect, happened today. From now, Linaro Android is available
via:

http://android.git.linaro.org/

Accompanied by Gerrit frontend at:

http://review.android.git.linaro.org/

It is recommended to perform a fresh checkout of the tree. To do that,
run:

repo init -u git://android.git.linaro.org/platform/manifest.git \
  -b branch \
  -m manifest

branch and manifest are those you used before. E.g. 

repo init -u git://android.git.linaro.org/platform/manifest.git \
  -b linaro_android_2.3.4 \
  -m default.xml


The official Linaro builds at https://android-build.linaro.org/ were
converted to use new manifest location, and I'd like to ask other
developers to convert their personal builds (I'm not trying to
automate this so far, to make that everyone was in loop on what
changed and how). To update, just change in a build config:

MANIFEST_REPO=git://git.linaro.org/android/platform/manifest.git

to

MANIFEST_REPO=git://android.git.linaro.org/platform/manifest.git

Old tree (git.linaro.org/android/*) was made inaccessible for the time
being to help with updating all references to it. It should be back up
shortly in read-only mode. (If there're immediate concerns, it's at
git.linaro.org/android-old/ now and can be renamed back by anyone with
git.linaro.org access).

With the spirit of making one change at time, all developers still
should have permissions similar to what they had before: anyone can
still create branches and push changes directly to them (*1). However,
once we finish updating build configs and docs for new tree location,
the next step will be setting up a workflow based on mandatory code
review, so I'd like to invite all developers to practice that right
away. Details on how to submit change for review are given at
https://wiki.linaro.org/Platform/Android/Gerrit (in particular, repo
upload works now).

(*1) The remote for such commits is different now of course, like this:
ssh://pfal...@android.git.linaro.org:29418/platform/build . Replace
pfalcon with you gerrit username and platform/build is the component
you need.


Please share any issues, concerns, and questions you may have related
to this migration.


-- 
Best Regards,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: [ANN] Linaro Android tree hosting switched to Gerrit

[Paul Sokolovsky]

On Wed, 10 Aug 2011 20:31:11 +0300
Paul Sokolovsky paul.sokolov...@linaro.org wrote:

 [originally sent from wrong email, so not sure if got thru]
 
[]
 The official Linaro builds at https://android-build.linaro.org/ were
 converted to use new manifest location, and I'd like to ask other
 developers to convert their personal builds (I'm not trying to
 automate this so far, to make that everyone was in loop on what
 changed and how). To update, just change in a build config:
 
 MANIFEST_REPO=git://git.linaro.org/android/platform/manifest.git
 
 to
 
 MANIFEST_REPO=git://android.git.linaro.org/platform/manifest.git

I should also add that I updated manifests living at
git://android.git.linaro.org/platform/manifest.git in
linaro_android_2.3.4 and linaro-android-11.08-release branches.
Manifests in other locations and branches need to be updated manually.
Look at
http://android.git.linaro.org/gitweb?p=platform/manifest.git;a=shortlog;h=refs/heads/linaro_android_2.3.4
for details.


-- 
Best Regards,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: Why are our Android toolchains 32bit?

[Paul Sokolovsky]

On Wed, 10 Aug 2011 10:48:26 -0700
Bernhard Rosenkranzer bernhard.rosenkran...@linaro.org wrote:

 On 10 August 2011 09:20, Vladimir Pantelic vlado...@gmail.com wrote:
  fwiw, android GB and HC both build fine on 32 bit here...
 
 How so? Did you simply patch out the
 
 ifeq ($(BUILD_OS),linux)
 build_arch := $(shell uname -m)
 ifneq (64,$(findstring 64,$(build_arch)))
 $(warning
 )
 $(warning You are attempting to build on a 32-bit system.) $(warning
 Only 64-bit build environments are supported beyond froyo/2.2.)
 $(warning
 ) $(error
 stop) endif endif
 
 part of build/core/main.mk? (I never understood why they put it there,
 but never bothered to question it and patch it out).

I personally did. I understand that what comes out is nothing official,
but it helps to at least look at non-related build issues.

I don't have strong opinion on whether we should switch for Linaro
builds, but would like to see stronger motivation than it might be
slightly faster ;-). There're in particular bunch of ideas how to make
android-build quicker, but going for them w/o actual benchmarking might
be waste of time or lead to adverse effects...

 
 ttyl
 bero
 


-- 
Best Regards,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: Problems with linaro-android_toolchain-4.6-2011.07 rebuilds

[Paul Sokolovsky]

Hello Alexander,

On Mon, 8 Aug 2011 12:39:41 +0200
Alexander Sack a...@linaro.org wrote:

 ok spads from IS gave better suggestion than using umask in .bashrc.
 Now, we propose that you set alias for git like:
 
 alias git='UMASK=002 git'

I understand the logic here - set umask only for git, but would that
really work? I kinda get used that aliases are interactive session
thing, and man reads:

   Aliases are not expanded when the shell is not interactive,
   unless the expand_aliases shell option is set using shopt  (see
   the description of shopt under SHELL BUILTIN COMMANDS below).

I'm not sure how exactly git over ssh works though.


And whatever way of umask setting should be, did IS consider
implementing it via global /etc/profile or via profile templates clones
by adduser or similar tool, to alleviate that burden for the users?

 
 Please update accordingly.
 Thanks!
 
 On Mon, Aug 8, 2011 at 11:51 AM, Alexander Sack a...@linaro.org
 wrote:
  this should be fixed now. folks, please use:
 
  umask 002
 
  in your .bashrc - ssh git.linaro.org - change .bashrc there.
 
  I guess from now on we could consider to use gerrit for toolchain
  etc. too.
 
  Thanks!
 
  On Sun, Aug 7, 2011 at 8:16 PM, James Westby
  james.wes...@linaro.org wrote:
  On Sun, 7 Aug 2011 02:25:17 +0100, Zach Pfeffer
  zach.pfef...@linaro.org wrote:
  I'm seeing the same thing:
 
  $git push linaro  HEAD
  Counting objects: 5, done.
  Delta compression using up to 4 threads.
  Compressing objects: 100% (2/2), done.
  Writing objects: 100% (3/3), 454 bytes, done.
  Total 3 (delta 1), reused 0 (delta 0)
  error: insufficient permission for adding an object to repository
  database ./objects
 
  fatal: failed to write object
  error: unpack failed: unpack-objects abnormal exit
  To
  ssh://pfeff...@git.linaro.org/srv/git.linaro.org/git/android/toolchain/manifest.git
   !
  [remote rejected] HEAD - toolchain-11.07-release (n/a (unpacker
  error)) error: failed to push some refs to
  'ssh://pfeff...@git.linaro.org/srv/git.linaro.org/git/android/toolchain/manifest.git'
 
  Any ideas Paul?
 
  The issue is that someone is pushing to these trees with a UMASK
  that prevents others in the group from writing some files to them.
  If you are pushing something that contains an object that needs to
  go in a dir created by someone pushing with a restrictive UMASK
  you will see this.
 
  You can file an RT ticket to get a chmod -R g+w on these trees.
 
  Please also make sure that if you are pushing to git.linaro.org
  you set your UMASK on that system to allow group write on
  files/dirs that you create.
 
  Thanks,
 
  James
 
 
 
 
  --
 
   - Alexander
 
 
 
 



-- 
Best Regards,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: Switching to Gerrit for Android code hosting - last stage

[Paul Sokolovsky]

On Tue, 9 Aug 2011 17:05:16 +0300
Paul Sokolovsky paul.sokolov...@linaro.org wrote:

   I have followed (and updated) the instructions
   on https://wiki.linaro.org/Platform/Android/Gerrit .
   I can not log in with my launchpad account. I get the message The
   requested URL /OpenID was not found on this server.
  
  I can confirm this issue. Guess the gerrit config was not changed to
  the new review.android.git.linaro.org url but still refers to the
  old android.git.linaro.org host which has the git itself now.
 
 Cannot fix this myself, submitted
 https://rt.linaro.org/Ticket/Display.html?id=56 . In the meantime,
 it's still possible to login with manual URL munging in case it's
 needed urgently.

Fixed now, so we don't have blockers for tomorrow's cutover.


-- 
Best Regards,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: What are the chances of a phone based developer image

[Paul Sokolovsky]

Hello Taras,


We've recently had a Linaro Connect conference, and many developers
are still on the way from it, so more knowledgeable folks may add more
info later, and I'd like to highlight some points in the meantime.


On Thu, 04 Aug 2011 12:03:00 -0700
Taras Glek tg...@mozilla.com wrote:

 Hi,
 Recently we have been looking at how to squeeze more performance out
 of our toolchain for building Firefox on Android. Mike Hommey
 integrated GCC 4.6 into the android NDK and has been testing
 performance (with mixed results
 http://gcc.gnu.org/ml/gcc/2011-08/msg00096.html). I like how Linaro
 is doing regular arm benchmarking, ie
 https://wiki.linaro.org/Platform/Android/AndroidToolchainBenchmarking/2011-07 
 .
 Would you be interested in adding a Firefox-based benchmark? As a
 large application it is a good testbed for LTO, FDO and other
 aggressive optimizations.

That sounds like a great idea. Our validation team currently exactly
compiles list of tests which are useful to run as our validation and
benchmarking effort. We're still bootstrapping our continuous
integration system and working on low-hanging fruit (simple tests),
but for sure looking forward to add more elaborated testsuites,
especially for Android (which doesn't have much of variety). So, please
consider us among your users.

 We are also looking at setting a developer-friendly android ROM with 
 oprofile, perf, systemtap, gdb, debug symbols, etc. It might even be 
 beneficial for us to use newer kernels as we exlore options like 
 kernel-assisted ld.so relocations, etc. That seems to similar to what 
 Linaro provides in the evaluation ROMS.

We recently added busybox to our builds, as the default Android
environment indeed pretty limited. And I agree that it would be nice to
have more tools available. However, our aim at Linaro is to stay
sufficiently close to the upstream, and neither we currently have
resources to maintain normal and developer images.

One solution I personally see for this is breaking away from the ROM
outlook, and taking Android more as a normal Linux distribution. So,
anyone interested could easily rebuild Android with more packages
installed, or even better, have native package manager to install more
binary packages (something like opkg). That's forward-looking thinking
though, we unlikely get to it soon, but would be interested to see if
wider Android community has interest in that and help if we can.

 Is there any chance of Linaro 
 providing developer-friendly evaluation ROMs for retail phones like 
 the Nexus S?

Did you consider using a development board for development and
testing? That for sure is more comfortable and affordable solution for
sustainable development than a specific retail product (1). We at
Linaro exactly work on making high-quality base software (including
Android) available on low-cost devel boards, so different parties can
develop ARM software more easily and with higher quality. That's also
consistent with Linaro's aim of promoting ARM SoCs, not specific
products. So, at this time we don't have plans to support retail
devices, though that might change in the future. 

That's also one area where community may kick in. On our side, we're
considering what support we can provide for such different efforts,
which may include providing code hosting, using our build system,
validation farm, etc.


(1) Though I for sure agree that it would be nice to have Linaro
supported and optimized build for some retail device. Except that I
happen not to have Nexus S, so would vote for supporting my tablet
instead ;-)


 Thanks,
 Taras

-- 
Best Regards,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Switching to Gerrit for Android code hosting - last stage

[Paul Sokolovsky]

Hello,

Following today's work session preparing to switching Gerrit, everything
is ready for the cutover now:

First build from Gerrit repositories is finished successfully:
https://android-build.linaro.org/jenkins/job/pfalcon_beagle-gerrit/4

Gerrit Web UI is migrated to the final location:
http://review.android.git.linaro.org/

Gitweb is installed at
http://android.git.linaro.org/gitweb

Anon git access to repositories in Gerrit available via
git://android.git.linaro.org/...


It's too late to do the cutover now of course, so I'd like to propose
to do it on Wed 10th to be sure that all folks are back from the
Connect and final bits are settled.

Until then, please still use existing git as before, and feel free to
elaborate your Gerrit knowledge using the info at
https://wiki.linaro.org/Platform/Android/Gerrit


Thanks,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Running a short android-build - LAVA CI cycle

[Paul Sokolovsky]

Hello,

When testing Android-build to LAVA integration (not the builds
themselves), it's sometime beneficial to have quick build cycle which
build something (just anything) without error and submits that to LAVA,
to avoid ~1hr wait for the normal build.

One way to achieve that is to add MAKE_TARGETS=userdatatarball to the
build config, as exemplified with
https://android-build.linaro.org/builds/~pfalcon/lava-test/ . Build
then takes ~12mins, lower-bounded by repo checkout time.

Of course, that won't produce complete Android build, so validation in
LAVA will fail.


-- 
Best Regards,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: ADB/Android Screencast

[Paul Sokolovsky]

Hello,

On Wed, 3 Aug 2011 16:50:19 +0530
Sachin Kamat sachin.ka...@linaro.org wrote:

[]
  I assume most people have used ADB and had to create a udev rule to
  set permissions on their board. We have a wiki page
  (https://wiki.linaro.org/Platform/Android/ConfigureAndUseAdbOnPanda)
  with the rules for Panda/TI and Snowball/ST-Ericsson, but it would
  be nice if some of you could add the rules for the other
  boards/vendors too so everything's in one place.
 
 
 Updated udev rules for Origen (Samsung Exynos4 based) board on the
 wiki.

Thanks. So, consequently it's not ConfigureAndUseAdbOnPanda any longer,
but https://wiki.linaro.org/Platform/Android/ConfigureAndUseAdb

I also linked to it from
https://wiki.linaro.org/Platform/Android/ImageInstallation#After_Installation
(the official Linaro Android images install guide) which talked about
that issue (and also contains more ADB tips).

-- 
Best Regards,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: Changing default root file system to btrfs

[Paul Sokolovsky]

On Thu, 4 Aug 2011 12:46:58 +0100
James Tunnicliffe james.tunnicli...@linaro.org wrote:

 Hi,
 
 Our current default root file system, ext3, is proving to be a
 bottleneck for SD card performance. Not only does it take a long time
 to format the partitions, but it also takes a long time to write to.
 This slows down creating images on SD cards a lot. I just did a very
 simple experiment running linaro-media-create, writing an Ubuntu
 Desktop image to an SD card:
 
 ext3:
 139.85user 35.27system 44:03.58elapsed 6%CPU (0avgtext+0avgdata
 107360maxresident)k
 2876115inputs+7048200outputs (958major+1677659minor)pagefaults 0swaps
 
 btrfs:
 146.52user 34.48system 19:57.16elapsed 15%CPU (0avgtext+0avgdata
 107408maxresident)k
 4417521inputs+6542992outputs (138major+1779874minor)pagefaults 0swaps
 
 As I understand it, btrfs is considered OK for file systems running on
 systems that don't suffer from power failure, so for writing an image
 and testing it this should be fine.
 
 So, what do people think about switching?

There were few concerns already expressed, so I just add: is btrfs
supported out of the box by kernels in last ~3 Ubuntu releases? Because
if one can't look at/change contents produced on an SD card, that
undermines purpose of evaluation builds much.

Those ext3 vs btrfs results are very vivid though, but I wonder if it
makes sense to try to tweak ext3  mount options. And
after all, we could prepare partition image(s) on the local HDD and dd
them to a card...


-- 
Best Regards,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Please register a Gerrit account, reminder #2

[Paul Sokolovsky]

Hello,

Some time this week we're switching to Gerrit for Android source tree
hosting. If you committed anything to git.linaro.org/android/* , please
make sure you registered an account in Gerrit, by following the
instructions below.

Thanks,
Paul


Begin forwarded message:

Date: Fri, 22 Jul 2011 00:45:13 +0300
From: Paul Sokolovsky paul.sokolov...@linaro.org

Hello,

I'd like to invite all interested parties, Linaro Android team members
first of all, to register an account on the upcoming Linaro Gerrit
instance at http://android.git.linaro.org . You can find instructions
at https://wiki.linaro.org/Platform/Android/Gerrit .

[]

-- 
Best Regards,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog


-- 
Best Regards,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev