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/ReleaseNot…
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/Linarohttp://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog
Petr,
On 19 January 2016 at 18:34, Petr Vorel <petr.vorel(a)gmail.com> wrote:
> Hi there,
>
> what is the development state of lava-android-test?
> * last development happen year ago, last tag 2014.01
> * not in Linaro's patchwork (https://patches.linaro.org/)
> * no Debian package (there is empty git repo pkg/lava-android-test.git)
> * last build isn't in PyPi (well other packages seems to be even pulled from
> PyPi).
>
> Is it considered as done, or just abandoned? (if yes, why?)
It's not used any more. The main reason (from my perspective) was
inability of matching the test results to executed tests. The test
that were important to us were migrated to lava-test-shell. Second
reason for dropping support for lava-android-test was increasing
difficulty in maintaining lava-android-test dependencies on LAVA
servers deployed in our LAB. This solution didn't scale well and was
abandoned. We have legacy support for lava-android-test in multi node
environment if someone still wants to use this code. However my
personal recommendation is to move to lava-test-shell.
milosz
>
> I'm considering to use it for testing Android firmware builds, it looks nice...
>
> Thanks for info.
>
> Kind regards,
> Petr
>
> PS: I'm sorry to posting to both lists, not sure which one is the right one.
> _______________________________________________
> linaro-validation mailing list
> linaro-validation(a)lists.linaro.org
> https://lists.linaro.org/mailman/listinfo/linaro-validation
Hi there,
what is the development state of lava-android-test?
* last development happen year ago, last tag 2014.01
* not in Linaro's patchwork (https://patches.linaro.org/)
* no Debian package (there is empty git repo pkg/lava-android-test.git)
* last build isn't in PyPi (well other packages seems to be even pulled from
PyPi).
Is it considered as done, or just abandoned? (if yes, why?)
I'm considering to use it for testing Android firmware builds, it looks nice...
Thanks for info.
Kind regards,
Petr
PS: I'm sorry to posting to both lists here and linaro-validation) as I'm not sure which
one is the right one.
Hi,
I'm running into a problem on Android 5.1 when using keyboard to move
input focus among different application icons. It seems that the
problem may be related to how application icon is highlighted when it
gets input focus. On customer's system, the application icon will be
highlighted with a blur effect around it. As a comparison on hikey, I
found that the icons gets highlighted with a square block around them.
The attached pictures demonstrate the differences there.
I guess that such input focus highlighting effect should be done by
GPU. But the customer's system runs a same version Mali DDK as Hikey.
So I'm wondering if this different behavior is caused by Android level
of configuration. That's why I'm asking help from Android mail list.
Any comment or hint about how this different behavior comes will be
much appreciated. Thanks.
Regards,
Shawn
Hi, Bero
Any idea why the size of the binaries compiled from the same source files
are different between the flounder version and the flo version?
10:29:01 liuyq: marshmallow$ ll
out/target/product/{flo,flounder}/system/bin/libstagefright_mp3dec_test
-rwxrwxr-x 1 liuyq liuyq 231360 Nov 2 10:29
out/target/product/flo/system/bin/libstagefright_mp3dec_test*
-rwxrwxr-x 1 liuyq liuyq 124684 Nov 2 10:28
out/target/product/flounder/system/bin/libstagefright_mp3dec_test*
10:29:39 liuyq: marshmallow$
The binaries are 32bit static linked version compiled with the attached
Android.mk
And the size of libc.so files are different as well.
10:37:13 liuyq: marshmallow$ ll
out/target/product/{flo,flounder}/system/lib/libc.so -h
-rwxrwxr-x 1 liuyq liuyq 659K Oct 29 15:34
out/target/product/flo/system/lib/libc.so*
-rwxrwxr-x 1 liuyq liuyq 540K Oct 19 18:32
out/target/product/flounder/system/lib/libc.so*
10:37:21 liuyq: marshmallow$
Some features are not compiled into the libc.so on the flounder platform?
--
Best Regards,
Yongqin Liu
---------------------------------------------------------------
#mailing list
linaro-android(a)lists.linaro.org <linaro-dev(a)lists.linaro.org>
http://lists.linaro.org/mailman/listinfo/linaro-android
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/Linarohttp://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog
Hi,
My name is Javier Romero and live in Buenos Aires, Argentina.
I'm an electronic technician and teach Android OS in an IT institute, also
work as a Linux Sysadmin.
Would like to know if there is something where I can help with, on the Linaro
Mobile Group.
I appreciate your kind attention.
With my Best regards,
*Javier Romero*
*E-mail: xavinux(a)gmail.com <xavinux(a)gmail.com>*
*Skype: xavinux*
Hello,
The latest Jenkins LTS release, 1.625, requires Java7 to run (to give
some context, Java9 is in beta now, Java7 is many years old). As
learned with some pain on ci.linaro.org, which already upgraded, this
requirement applies not just to a Jenkins master, but also to build
slaves, just to run slave agent to be connected to a master.
We install both Java6 and Java7 on android-build.linaro.org slaves, but
the default is still Java6, "for compatibility with older Android
versions", as a comment says.
Is Java6 being a default still relevant? The easiest way to accommodate
the upcoming upgrade is just to switch default to Java7. If there're
issues expected with that, we can follow an alternative way of adding
adhoc version overrides for slave startup.
--
Best Regards,
Paul
Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linarohttp://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog
On Sun, Nov 1, 2015 at 10:07 PM, YongQin Liu <yongqin.liu(a)linaro.org> wrote:
> On 2 November 2015 at 11:59, John Stultz <john.stultz(a)linaro.org> wrote:
>>
>> You can try to objdump -d the files and diff the output.. That might
>> help narrow down where things are different.
>
> Sorry, I can not find out anything from the output.
>
> Not able to read the objdump output:(
>
> Attached the binaries and objdump output files here, in case if someone
> likes to check the binary file.
Sorry. Yea, objdump isn't super useful after the symbols have been
stripped out. Might try to build w/ symbols and try again?
thanks
-john