Greetings,
Enclosed you'll find a link to the agenda, notes and actions from the
Linaro User Platforms Weekly Status meeting dated October 13th held in
#linaro-meeting on irc.freenode.net at 13:00 UTC.
https://wiki.linaro.org/Platform/UserPlatforms/WeeklyStatus/2010-10-13
Regards,
Tom (tgall_foo)
User Platforms Team
"We want great men who, when fortune frowns will not be discouraged."
- Colonel Henry Knox
w) tom.gall att linaro.org
w) tom_gall att vnet.ibm.com
h) tom_gall att mac.com
All,
The weekly report for the Linaro Infrastructure team may be found at:-
Status report:
<https://wiki.linaro.org/Platform/Infrastructure/Status/2010-10-14>https://wiki.linaro.org/Platform/Infrastructure/Status/2010-10-14
Burndown
chart:http://people.canonical.com/~pitti/workitems/maverick/linaro-infrastr…
The Infrastructure related blueprints, of which currently there are 4
active ones are showing that there are 14 tasks in progress (12 last
week) , and 12 tasks to undertake (18 last week).
arm-m-validation-dashboard; 2 work items completed from last
week; 4 in progress; 8 to do
arm-m-image-building-console; no change in status from last week; 8
in progress; 3 to do
arm-m-automated-testing-framework; 2 work items completed since last
week; 1 in progress; 0 to do
arm-m-testsuites-and-profilers; no change in status from last week;
1 in progress; 1 to do
In arm-m-image-building-console, 7 items are awaiting review before they
can be completed.
Preparations for UDS are occupying more of the team's time, with more
tasks related to UDS being undertaken and completed that are not in
blueprints.
Specifics accomplished this week include:-
* 5 tests were successfully submitted to the dashboard from abrek
(Automated Test Framework) on Beagle boards, with more tests being
added in the next few days
* Fixed LP658917 (uploading bundle from abrek fails to deserialize)
* Changes to summit.ubuntu.com to include plenaries in the
linaro-only view and to identify Linaro related blueprints
Please let me know if you have any comments or questions.
Kind Regards,
Ian
Hi there. I'm confused about how we nominate and schedule things for
the upcoming summit. I've got a bunch of tr-* TR blueprints and a
related set of engineering blueprints. Some of these blueprints are
too big for one session and some need to be bundled up to fill up a
session. No matter what, summit blueprints need the
other-linaro-n-foo naming convention to work.
What should I do? My best guess is create other-linaro-n-foo
blueprints for scheduling's sake and add the TR and engineering
blueprints as dependencies.
BTW, I've written up my understanding of the workflow at:
https://wiki.linaro.org/MichaelHope/Sandbox/SummitWorkflow
-- Michael
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
W dniu 13.10.2010 19:52, James Westby pisze:
> On Wed, 13 Oct 2010 12:35:54 -0300, Guilherme Salgado <salgado(a)canonical.com> wrote:
>> I think we can use existing libraries (python-oauth and
>> lazr.authentication) and follow the examples of Canonical django
>> projects that support OAuth, to support OAuth on launch-control.
>> However, given that the deadline is very close, the alternative you
>> propose above might be acceptable if the API is served over HTTPS.
>
> lazr.authentication is fairly nice, but also fairly minimal. What is
> missing from the combination of python-oauth and lazr.authentication is
> the models for storing tokens etc. via the Django ORM.
>
> We could extract those parts from canonical-identity-provider in to a
> new app, which would be of use to everyone that wants to do this.
>
> What I like about the lazr.authentication solution is that it integrates
> with the Django auth system in that you just get a request.user that you
> can check as you like. Plain django-oauth and django-piston don't seem
> to have that, and I'd like to keep that separation of concerns if
> possible.
>
> I think that given that most of the code for the lazr.authentication
> based solution already exists we could deliver something by Tuesday, but
> we still don't have an answer to the question of external dependencies.
If we work together we might do that. Don't worry about external
dependencies yet. If it works we'll worry about solving that problem.
> Zygmunt, have you discussed that question with Spike? Does anyone else
> know what IS would prefer there?
No but that's a good idea. I'll talk with him about this today.
Thanks
ZK
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQEcBAEBAgAGBQJMtreHAAoJEKkR4hQBRI+liZAIAMInd8ClTX6NB7LJS+3nDM52
WHkKEvRCCGWft/xWeib7NTMyaOW6xJD4rWBc6nFYjn4HByjo+Y/v8gxJHtN6e2TA
UjRzn0OEG1Twz17emvfnx/SzoP3VtpFfUIGEYlyRjbyDR2gZc1o3C1hOwgon9cs+
27gimWPP2sxyD7v7uxNb8hnhhR7R1v9STInohQkYp+wdYrQNFRgpLY0QllvNFzqC
xg1/ewbWwplkotzLRWuLlTocuqIpYTZbAcFZHMS+Mvfc3F019FwIwOysLJSdNk/s
8v3JBzjn5Nm17nB50Gyvu/YVcxg2Ubpuv4W27xPlsLEN6v0cK790XTA4wIvBYYk=
=P9pt
-----END PGP SIGNATURE-----
Hi,
Today marks the third week of "Weekly Linaro image testing" and as
usual this is a call for help. If you have supported hardware and are
willing to test the images, please make your way to:
http://wiki.linaro.org/Releases/DailyBuilds
for an explanation on how to test and submit your results to the QA
tracker at:
http://qatracker.linaro.org
In the past week we have been squishing bugs and making the tools to
create images better, hopefully you will see this in your testing.
Another notable change is that these images enable the maverick-proposed
repository, sucking in all the goodness that is coming in from the SRU
process. Please try to verify if any SRU changes have adversely affected
the images in any way.
Happy Testing !
Regards,
Jamie.
--
Linaro Release Manager
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi.
As you know we've been trying to deliver an authenticated interface for
the dashboard for quite some time now without success. Recently we've
decided to add oauth support to the current XML-RPC interface we have.
James implemented a rough support for this here [1] but it's not clear
that we should accept this work yet. To quote James there are some
issues with it today:
1. This relies on an external project that is unpackaged at this time.
2. That external project ships a patched embedded copy of python-oauth,
though I don't know what the patches are for.
3. That project requires consumers to be pre-registered, and I'm not
sure we want that. It would be possible to work around it, but would
require some work.
4. I'm not sure I have the Resource stuff correct in this branch.
5. I'm not convinced that I have thought through all the corners and so
there may be security holes.
6. There is nothing so far for the view to know if the request is oauth,
which consumer it is etc., and no support for differing token access
levels. We won't need any of that right away, but if we want that then
django-piston may be the way to go rather than adding all of that.
All in all those issues make me think that it's not as easy as we
assumed and we should pursue another path. Before we do that let's
summarize our current needs and priorities:
1) We need to allow users to authenticate before we allow them to upload
test results (bundles) to certain directories (bundle streams) in a
simple and efficient manner (client side code matters)
2) Currently our only client is abrek
3) We'd like to offer this very quickly, definitely before the UDS
Having said that let's look at the options we have:
A) Continue hacking oauth in good faith that it'll work as intended
without falling apart/being insecure/being hard to deploy/missing deadlines.
B) Fall back to one of the B-plans:
B1) use something other than oauth (like HTTP digest authentication)
B2) use something entirely different like:
B2.1) django-piston
B2.2) lazr.restful
B2.1 (piston) cannot directly replace our current API as it does not
support named methods (it only has CREATE/READ/UPDATE/DELETE). The
upsides are that is seems to support oauth out of the box. The downside
is that it's not packaged (at least properly on lucid which we target).
We'd also have to pick a client-side library to use (lazr.resful most
likely but I'm not sure really). We're also not sure if they work
together out of the box.
B2.2 (lazr-restful) might work but I don't know anything about it.
Some other points to consider:
1) Offspring nee lexbuilder also has an XML-RPC interface (cody, please
correct me if I'm wrong) and we should align the technology if possible
2) We're not sure if we need full API but we're not sure that we don't
need it either. Currently our _only_ requirement is to "allow people to
submit test results" in whatever means necessary.
3) Having looked at various "web APIs" it seems that passing an API key
is a common practice. While not as fancy as oauth perhaps we should
consider this.
Having said that I'd like to propose my opinion:
1) Postpone oauth for UDS milestone (7 days left)
2) Work on alternative scheme that can be integrated with abrek easily
in time for release
3) Continue on oauth path in a longer cycle (while retaining current
interface).
Thanks
ZK
[1]
https://code.edge.launchpad.net/~james-w/launch-control/oauth/+merge/38013
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQEcBAEBAgAGBQJMtKqqAAoJEKkR4hQBRI+lRzAIAJGtprqkZqdbP7+bOLar2JNM
N9Q1vWHcGfp7BLhG/Cvu30w5jBvyQ0+CKfVUbyBBE8Ig3v2/jbGfZRC5c4t38c0B
9WD7i6COk/KiMN2rPzv6PPgoLhiA7tpxhajNA/rzYQJU3HIDIe1O12rnC+xCBdfp
FuzqeKISIuUBKGSI/TUdZx1z0PTIE9bEr+6Cr1es+6XRZvav+vkbIotIqJWJfxmj
oxUbfYU92Q7VzxpxMuxZQz8a1DFMuckkIRT4Goh17WFXZYcFgr9jMLgKwiJWytos
WIGQLZWJXo++GZC83585yGd2yMlzyP0iF0KocDPQtwPW9bZCVxyYMBK55PLUJw4=
=OKuR
-----END PGP SIGNATURE-----
Hi Alexander,
I'm using lp:~linaro-maintainers/linaro/live-helper.config.maverick.headless
to build the rootfs image for imx51, and running into the following
problems.
- Need --force-yes apt option
I have to get APT_OPTIONS="--yes --force-yes" in common to keep the
build going, otherwise it will end up with the following error.
E: There are problems and -y was used without --force-yes
Build log is attached for your checking.
- OMAP build binding
The current config is binding to OMAP build without hwpack. What is
the plan to support hwpack build and other platforms like imx51 as far
as I'm concerned right now?
--
Regards,
Shawn
Hi, I have a request for some testing on a few images that have been
produced in a different build farm. The goal of this testing is not really
to validate the images themselves, but to make sure that we aren't seeing
anything broken that looks like it was due to the new build environment.
One thing to note, is that the test images I have for this are from
20101006, so I don't expect to see significant differences from the weekly
testing on the 7th, last week.
For convenience, I set up a milestone on the Linaro QA Tracker [1] under the
heading "New build farm" to track the results of this testing. I would
greatly appreciate if someone has a few spare cycles and can help by loading
a few of these images on the boards they have available, and give it a quick
try.
The images for testing are located at:
http://people.canonical.com/~plars/linaro/images/
Instructions for installing these images are the same as for the ones that
we've produced in the past. For reference, those instructions are posted
at: http://wiki.linaro.org/Source/ImageInstallation.
Thanks,
Paul Larson
[1] http://qatracker.linaro.org/
Hi,
On Wed, Oct 13, 2010 at 2:32 PM, Dave Martin <dave.martin(a)linaro.org> wrote:
> On Wed, Oct 13, 2010 at 2:27 PM, Loïc Minier <loic.minier(a)linaro.org> wrote:
>> On Wed, Oct 13, 2010, Dave Martin wrote:
>>> As far as I can make out, the partition must be an exact number of
>>> "cylinders", must have enough sectors for a FAT32 filesystem and must
>>> start at sector 63. This gives a minumum size is 5 cylinders (80262
>>> sectors), which seems to work OK.
>>> Anything else causes the ROM to print out the characters "60" and
>>> halt, at least on my board.
>>
>> Is this the ROM or x-loader?
>
> No X-Loader banner (or anything else) is printed before the "60", so
> I'm assuming it's the ROM.
>
>> What's your board again? if beagle, are you pressing the user button?
Note, I've been playing with *xM* A2, not Beagle A2.
Is MLO the same thing as X-loader?
Interestingly, holding down the user button when there is no boot
sector at sector 63, causes just "60" to be printed out instead of the
X-loader banner and "empty boot sector" mesages.
Cheers
---Dave
Greets,
As a side project I've created a fairly simple performance improvement
for the linaro-media-create tool. Basically the copying of the root_fs
happens earlier in the process such that hwpack and a number of other
steps are done in parallel and then at the end there's one last rsync
to make sure adjusted files, further installed files are correctly
copied.
The code is located here : lp:~tom-gall/linaro-image-tools/rsync-speedup
I'm still testing so use with caution.
>From what I've been able to accomplish thus far, the 67M
linaro-headless + hwpack sees the following speed up collected with
time:
Normal:
real 10m0.596s
user 2m2.670s
sys 0m9.820s
Parallel:
real 7m58.790s
user 2m3.170s
sys 0m11.950s
Feedback gladly accepted,
Regards,
Tom
