On Wed, Oct 6, 2010 at 10:11 AM, Alexander Sack <asac(a)linaro.org> wrote:
> On Wed, Oct 6, 2010 at 4:43 PM, Tom Gall <tom.gall(a)linaro.org> wrote:
>> I haven't tested without hwpacks. I'm not sure that's a valid test
>> anymore with the removal of flavors and so on from the builds. Outside
>> of using an old linaro image, is it valid anymore to call
>> linaro-media-create without passing hwpacks?
> I think its still useful in general to have this feature in l-m-c;
> someone might run their own builds with kernel included for
> convenience. But you are right. as discussed in UP meeting we should
> at least spit out a warning or even do a fast-fail check if there is a
> kernel in /boot/.
Ok. I'll test that variation, adjust the rsync call and unless something else
comes up submit a merge proposal.
We have only 43 (or 42 depending on your timezone) days until the Linaro final release  and
as we get closer, the need for more structured testing is essential. An idea that has been
incubating for some time is to have a weekly 'test day' where individuals can spend a couple
of hours downloading, installing and testing a Linaro image on their hardware. Which image(s)
you can test will obviously depend on the hardware available but currently we produce:
* OMAP3 Headless
* OMAP3 ALIP
* OMAP3 Plasma Handset
* OMAP3 EFL Netbook
* Versatile Express Headless
* UX500 Headless
and in conjunction with a hardware pack from:
* OMAP4 Headless
* iMX51 Headless
* OMAP3 X11 Base
Starting this Thursday (30th) I propose that each and every Thursday leading up to the final
release is a 'Linaro Image Test Day'. If you have any of this hardware available, please
spend a little time testing and reporting bugs. As an experiment, we will be setting up the
Linaro qatracker each Thursday morning, UTC, with the information for that days images. If
you find it useful, please report your testing results at:
For information on how to install the images on your hardware please take a look at:
Linaro Release Manager
In case someone missed this in the last call, or missed the udpated
invite, this is a quick reminder that the Kernel WG calls were moved to
line 26344 17169#.
Talk to you there!
The daily linaro-alip snapshots which can be found at :
http://snapshots.linaro.org/10.11-daily/linaro-alip/ are now to a
reasonable point where I'd be most appreciative of any and all
feedback to improve the image in ways that would be useful to you or
anticipated users of the linaro-alip when 10.11 is released.
Feel free to either copy the list or email me directly
(tom.gall(a)linaro.org) or grab me on irc, tgall_foo or Dr_Who.
At this point I believe the next steps are mostly along the lines of
slimming down the image size, removing things that just aren't needed.
The image as is currently 460Megs of gz'd tarball is a bit hefty.
Linaro User Platforms
"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
The weekly report for the Linaro Infrastructure team may be found at:
The burndown chart shows that a number of work items were completed this
week, and a number of new work items added. Some work items will need
deferring to the next cycle, and some should be completed following
reviews being completed by external teams. Of the work items being
deferred, some are associated with the additional work from the new
Infrastructure Stakeholder process, and the hardware pack development,
planning QA resources, interviewing, as well as some items being more
complex than originally anticipated.
* released Launch Control 0.1.1 to fix a configuration issue
* linaro-media-create was refactored to better integrate with
* Infrastructure team stakeholder meeting held, and outlines of
proposals were drafted
* Hardware pack scripts packaged and included in the tools PPA.
* arm-m-image-building-console: Three branches landed
* Some code was added to make abrek give more output during test
execution, with an option to mute this
Please let me know if you have any comments or questions.
This patch series has some clean up in OMAP3 sleep code.
Patches have been rebased to latest kevin's pm branch.
Vishwanath BS (2):
OMAP3 PM: move omap3 sleep to ddr
OMAP3 PM: sleep code clean up
arch/arm/mach-omap2/pm34xx.c | 9 +-
arch/arm/mach-omap2/sleep34xx.S | 377 ++++++++++++++---------------
arch/arm/plat-omap/include/plat/control.h | 2 +
3 files changed, 190 insertions(+), 198 deletions(-)
I was trying to improve my work flow and I finally used bzr-pipeline for
change management. I have prepared a rather big pipeline with 13
different patches that collectively add some of 0.2 features, some minor
enhancements, bug fixes etc.
I did not know what to expect of pipeline plug-in so the patches I
produces directly reflect my old development style (hack until glad with
result) rather than some carefully planned design.
I'd like to ask you for advice on how to propose all of this for
merging. I used bzr sync-pipeline to publish all of the pipeline
components on launchpad (as lp:~zkrynicki/launch-control/stable.pipe).
Should I just mark each one as ready for review? I could also export the
whole pipeline as a series of patches (I like that but it's somewhat
against our nice review system on lp.net). I have no experience with
this yet, so if anyone knows of a better way feel free to point me out
PS: IMHO pipeline is a really good tool and I hope we can continue using it.