Hey folks
So I've been animating a small team of people under the label "Landing
Teams" to experiment with the whole Landing Teams concept. Torez Smith
has been working on Texas Instruments OMAP3 boards and Matt Waddel on
ARM Versatile Express with quad-A9 tile. These two have been busy for
some months now, trying to improve the support for these boards in
Linaro!
I've recently uploaded past meeting notes to the wiki and will send out
minutes after our 3 weekly calls. Please find today's minutes and last
week's activity reports below.
Cheers,
== Notes from call ==
=== Attendees ===
* Loïc Minier
* Matt Waddel
* Torez Smith
* Mounir Bsaibes
=== Agenda ===
* New wiki pages for meetings
* New meeting format
* Action items from last meeting.
* Progress reports
* OMAP3
* Versatile Express
=== Action Items ===
* Loïc to find a replacement XM for Torez
* Loïc to check what to do with broken boards
* Torez to add boards to Internal/Hardware wiki page
=== Action Items from Previous Meeting ===
* Torez to file a bug for LCD issue on IGEP
=== Minutes ===
* New meeting format
* New wiki pages
* Actions items from previous meeting
* Torez to file a bug for LCD issue on IGEP
. DONE just now LP #633338
* Accomplishment / progress reports
* Vexpress - Matt
* Sent reworked u-boot patches; expect these will be rejected because they need to be rebased on upstream u-boot-next branch
* Some initrd issues seem to creep in, mouse stopped working; seems to be initrd not loading the driver anymore LP #633253
* MMC and USB don't work together; if you use an USB rootfs, MMC stops working; LP #632798; Matt is talking to Vinod and Pawel on this bug, might be fixed in 2.6.36
* Loïc mentioned http://hudson.dooz.org/ to help testing upstream kernels for the above issue
* OMAP3 - Torez
* Opened a bunch of bugs to track things to make sure we can install Linaro on OMAP3 boards: linaro-media-create support, network support, kernel upgrades, xorg support etc.; tested mostly on XM
* General observation is that generally linaro-media-create works, but flash-kernel ususally doesn't
* Tom has a different XM revA02 while Torez has a A01; flash-kernel seems to work for Tom
* IGEP flash-kernel seems to always work fine
* XM revA01 is clearly unstable, need to stop working on that one
* Checked with ogra, and seems it can't be helped
. ACTION Loïc to find a replacement XM for Torez
. ACTION Loïc to check what to do with broken boards
* Network: worked on XM all the time; IGEP: still working the issues out
. ACTION Torez to add boards to Internal/Hardware wiki page
* Flash-kernel: had to install extra packages to achieve that; LP #628848
* LCD: still an issue on IGEP
== Activity reports ==
=== Matt Waddel ===
==== this week ====
* validated new vexpress headless images
* found bug in u-boot causing initrd problems
* found problem with flash mtd mounting (thx lool and scottb)
* several changes to linaro-media-create script for vexpress
* closed outstanding linaro-media-create bugs assigned to me
* qatracker deploy instructions
* re-formated u-boot patches - will submit tomorrow
==== next week ====
* US holiday
* push u-boot changes before merge window opens
* bug fixing on vexpress - memory issue, initrd on command line
* flash-kernel implementation
* try Lorenzo's vexpress arm device-tree
* Start mmc u-boot device driver
--
Loïc Minier
The weekly report for the Linaro Infrastructure team may be found at:
Status
report:https://wiki.linaro.org/Platform/Infrastructure/Status/2010-09-09
Burndown
chart:http://people.canonical.com/~pitti/workitems/maverick/linaro-infrastr…
The burndown chart is showing that number of work items has remained
constant from last week, and a small number of work items have been
completed. This has shown that the number of work items to complete is
slipping further behind the trend line.
* Submitted first pass of dashboard plugin for Abrek, with setup
command to handle server/auth configuration
* Reviewed some branches
* Got a first usable version of hwpack-create, with most of it
reviewed.
* Pushed additional RPC methods for review (put,get,bundles,streams).
* Pushed lc-tool.py command counterparts for review
* Started writing deployment instructions for apache and cherokee
* (arm-m-image-building-console): Several work items in progress
Please let me know if you have any questions.
Kind Regards,
Ian
Greetings,
Enclosed you'll find a link to the agenda, notes and actions from the
Linaro User Platforms Weekly Status meeting dated 9/08 held in
#linaro-meeting at 13:00 UTC.
https://wiki.linaro.org/Platform/UserPlatforms/WeeklyStatus/2010-09-08
Regards,
Tom (tgall_foo)
User Platforms Team
The minutes of the weekly call can be found at:
https://wiki.linaro.org/WorkingGroups/PowerManagement/Meetings/2010-09-08
Attendees:
Linaro: Amit Kucheria, Amit Arora, Yong Shen, Vishwanath Sripathy
ARM: Robin Randhawa, Srinivas Kalaga, Bobby Batacharia
Regards,
Amit
----- End forwarded message -----
Hey!
10 days ago, I met with John and Nicolas and with the help of Steve we
discussed how an "upstreamish" release process for u-boot-linaro and
linux-linaro would look like.
I'm sorry for sending the notes out to late, please find them below.
Thanks
== Attendees ==
Nicolas
John
Steve
Loic
== Minutes ==
* Releases every month
* Release announcement on linaro-announce@
* Would we release both -next and -stable? even if no change was done?
* Probably an upstream stable release every week or so
* Between releases, merge upstream stable updates as they show up; before release, verify that we have the latest stable release
* John wonders whether we need the Ubuntu changes?
* AppArmor went upstream
* aufs isn't used in Linaro
* but we might want to be the upstream for the Ubuntu ARM team, so it makes sense to have the Ubuntu changes in our Ubuntu packages
* We don't really need to test the Ubuntu changes in our dailies; simpler to just build daily zImages
* We should include Ubuntu patches in ubuntu, but not in daily builds
* What's the kernel PPA for? Is it for staging and testing, or an overlay?
* The .debs are kind of specific to Ubuntu and distros in general, and we already integrate with Ubuntu
* Should we produce .debs in a PPA or something before doing a kernel release, or just before upload to Ubuntu?
* Kernel team is producing vanilla .debs, would be possible to do the same?
* How would we test a new kernel, .deb is simpler than modules.tgz, zImage with hardcoded modules is easier to test though
* Nicolas would prefer testing zImage; easier this way
* Configs would differ though, and might regress either way
* Linaro KCWG and Linaro .debs would use different configs
* We're doing releases for users, and they mostly expect .debs, but also .rpms
* Conclusion:
* Daily zImage with everything compiled in, no need to worry about modules
* Daily .deb builds that have modules split out, but no Ubuntu patches
* Monthly release of the above
* Monthly integration of that tree into Linaro Platform if possible
* linux-linaro-next + linaro-linaro-stable, same thing
Can add stuff progressively, starting without zImage
Align a monthly release with the 6-monthly release, e.g. kernel release at the same time as platform release for 10.11
* u-boot: same thing, except we don't have Ubuntu configs and we don't have the modules problem; could even do a single daily built
* Nicolas would ensure that we have builds for linux trees, and John for u-boot, and each of them would post to the tracker
* Then send Call for testing to people with the hardware, report bugs, and if we have everything tested, release it
* How do we test?
* u-boot?
* just loading a kernel probably
* perhaps recovery procedure: make sure we have a way to load a kernel from an external source
* loading a kernel from SD (for platforms which have it)
* loading a kernel from the network
* could test network
* linux?
* boots
* display output
* network
* SD R/W
* USB: storage at least
* NAND: shows up in /proc/mtd if supported
* user platforms should push for other test cases like audio if needed on some boards
* what rootfs to test on?
* for now use our minimal image, or the installed system
* future: a small initramfs with static busybox
ACTION slangasek to talk to ppearse and tgall to see how we could do that
* John: The current configs are way too large, we need to have something smaller for Linaro
* Needs at least to support everything on the board
* Need some template for the common kernel config parts
ACTION jcrigby to discuss with Frederik ideas about default/common configs
ACTION nico to create a minimal config using the kernel system
ACTION lool to send Ubuntu kernel checker over email
ACTION lool document release process on the wiki
--
Loïc Minier
Hi
== Attendees ==
* Scott Bambrough
* Loïc Minier
* Yves Vandervennet
== Minutes ==
* build and provide a downloadable Android toolchain
* base it on our toolchain as soon as possible
* provide a Linaro Android distribution, with a set of git trees for
Android components
* should use the Google trees when we don't modify them
* could use either a set of mirrored trees, or only host modified
trees, not sure which option is best; the former allows changing
the base URL from the start (at the time of repo init), the latter
would mean changing the URL at the time of repo sync
* need a build infrastructure
* need a way for people using the Linaro output to replicate the
build infrastructure for daily builds, Hudson would probably do
* wont be able to watch multiple git repos with hudson
* need a kernel tree
* want a consolidated linux-linaro-android tree, just like
linux-linaro
* should track at least the Android kernel tree
* can't target Android development tree because it's not public
* do we want to rebase on newer linux kernels, i.e. newer than
Android provides?
* main use case would be the devicetree stuff; that one is really
easy to backport, so might not be a good idea to move Android
forward
* Freescale's needs are mostly on the multimedia side, with the
OpenCore framework in particular, since it seems like a poor fit for
hardware accelerators
* mostly interested in basing on a regular Android build, and trying
to swap OpenCore with something else, or integrate existing stuff
into OpenCore
* are there some needs with current architecture which need to complete
* SMP safety of bionic library; might be a good topic
* hard-float? NEON? is this well supported in Android? probably
just in isolated places, in isolated libraries
* dalvik would probably break with hard-float
* what kind of licensing constraints should we operated under?
* Freescale didn't get any pushback on GPL stuff from OEMs so far; at
least not on u-boot
* are there needs to extend the Android architecture to cover new type
of hardware in upcoming SoCs? e.g. new type of hardware accelerators
or something like that?
* apparently, not that much in the pipe; everything seems covered by
Android already
* are TSCMs interested mostly looking at phones or tablets?
* mostly tables and not phones in the case of Freescale
* what's more important? improving the runtime or improving the
development experience and services?
* a faster build would be nice; that is, compilation is really slow
* the overall process is too long between the time where people start
cloning and the time they have builds
* could improve source code overlays
* could provide pre-built Android parts
* could provide infrastructure to fork source trees into multiple
projects and do fast server-side builds
* not clear how the development experience would look like with
remote builds; would help in download and build time, but might be
clumsy
* can use adb with local builds to push modified files directly
* which devices do we need to cover?
* beagleboard -- would probably work in QEMU
* google nexus one
* should probably cover vexpress and imx51 babbage
* should we do intel builds? might not be a good idea for an ARM
group :-) Freescale didn't need to do any Intel builds at least
* main advantage is that they work on more hardware and so support
more devices etc.
* should enable more people to build for their devices rather than
doing it all ourselves
* strong desire to see the Android kernel patches upstreamed
* performance is probably the biggest thing which vendors care about,
not infrastructure or features; in particular boot time and power
management and execution speed
* middleware
* web browser
* accelerated rendering: leveraging the GPU for page rendering
* telephony
* graphics stack
* should probably explore with other vendors and TSCMs, especially
company selling *phones* with android
* improving the Android architecture is more of a topic for later
Cheers,
--
Loïc Minier
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hello guys.
I'd like to ask for your advice in for implementing authentication
mechanism for the XML-RPC interface to the dashboard. I believe this
problem has two aspects: user needs and client program needs. I was
about to implement HTTP Digest authentication that will authorize the
user against the Django user database. James pointed out that we should
discuss this topic more. I'd like to know what you think.
What users need to have.
========================
I think that for our internal use cases a best option would be launchpad
integration. We don't mind using launchpad, we already have accounts
there. We could use oauth for authentication. I'm not an expect on oauth
so I'm not sure what kind of impact it has on the API itself, if any (do
we need to pass some special argument to each call?). I suspect it has a
negotiation phase where the client and oauth provider exchange some
messages after which the client can authenticate by providing some extra
header in each request. In any way that's one option.
For a centralized installation this would be pretty good. For ad-hoc
installations it could be difficult to setup but I'm just guessing here.
Other options are (off the top of my head):
- - Basic/Digest HTTP authentication. Digest is pretty good (or so
wikipedia tells me) and has a very nice property of not requiring any
changes to the API. User identity is provided as out-of-band HTTP header.
- - Custom authentication via special XML-RPC methods and some
user/pass/token/whatever arguments. This is IMHO pretty ugly as it
affects the interface. The upside is that we can build any
authentication options we like.
- - No authentication at all. All XML-RPC interfaces are public and anyone
may call them. Surprisingly this is not such a bad option. Since all
request would be anonymous all the users would be allowed to do is
upload data to public "directories". All other interaction would have to
be performed via the website or the administration panel.
What clients need to implement.
===============================
So this is about everyone who has to interact with the API, currently
that's just dashboard itself (we have a command-line client that can use
each exposed method) and of course abrek. While I don't mind changing
the API or security method to make it better we need to consider that
each client will have to adapt as well. Worse, if one client has to
interact with two servers it may be required to discover/negotiate
supported authentication before we can even connect.
Thanks
Zygmunt
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQEcBAEBAgAGBQJMgnSeAAoJEKkR4hQBRI+lvRUIAKs90kr/238PoltUbb+ET5ti
qnEgQA0UYR1ocykxlL+8gkNhDLroQuSE6HpFBlVXZb2kLc1wqb5ggK0XpwViuzwo
qr7aZ2HfkL6gMBQNhdW1OOSK7RxI1Z731vG6dFAo3UTCX737lCitYW6ipkqA//h3
slbIn5Voh43cbBKneRZvpIeHJbd6oKW4HKLeEVAzheuprXtjvhyXkg1qjUVH3V+Y
FHRp7V1fVAYvTlObhVVW2j95OEyVJK+7dbdpmwQ/8vai2WiDXdDlqJqpO2PuZNuy
mu8C0gBdZsP+ZYB2AER5RKbhZIPISf2l1fmwem79yVaxstFmHU+/KwO7AeWCR3I=
=h4TW
-----END PGP SIGNATURE-----