On Mon, Sep 27, 2010, Tim Gardner wrote:
> The packages that are directly maintained by the kernel team should
> all be in main. I suspect linux-linaro _should_ be in universe since
> it is not strictly subject to SRU criteria and it is not maintained
> by the kernel team.
This is how I felt as well, but I recall some people argued in favor of
having linux-linaro in main; not sure why anymore. It might have been
asac, Cc:ing him.
(I had also passed this demotion proposal to Jamie and John, but I'm
not sure they got the chance to comment yet.)
--
Loïc Minier
Hi,
I've recently changed l-m-c to take an hwpack, which is installed before
the image is built. To keep that change simple I had to unpack the
binary tarball into a tmp directory, install the hwpack, repack the
tarball and then continue with the image generation. This extra
unpacking/repacking of the binary tarball is obviously not ideal, so I'm
now refactoring l-m-c to make it possible to avoid it when installing an
hwpack.
The one thing I'm not sure about is whether I should
a) unpack the binary tarball to a tmp dir, install the hwpack (which
may cause lots of data to be written) and then move that to the SD card
or
b) unpack the tarball straight into the sd card (as is done currently)
and then install the hwpack
I'm leaning towards a) because of the poor write speed of SD cards, but
if anybody knows of any reasons why I should go with b) now's the time
to tell me. :)
Cheers,
--
Guilherme Salgado <https://launchpad.net/~salgado>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hello.
I'd like to discuss my plans for 0.2 release for the validation
dashboard a.k.a. launch control.
I would like to have a roughly two-week development cycle. This will
ensure that we don't get carried away with large features taking lots of
time without planning them ahead of time. I would also like each release
to feature some user-visible improvements (features or bug fixes) as
well as backend infrastructure improvements (better tests, better
internals, new feature elements that take >1 cycle to develop).
I would like to reuse the proposal laid out by James Westby that defines
how the infrastructure team plans future work and mix it a little with
the original blueprint for the dashboard. What this means in practice is
that each release should bring us closer to the feature set outlined in
the blueprint _and_ introduce features/changes requested via the
stakeholder process. I think this will work fine until we finish all of
the features originating in the blueprint.
For the upcoming 0.2 release (currently scheduled exactly two weeks
after 0.1) I'd like to focus on the following topics:
* Support for migrations south. South allows us to change the database
on upgrades and plays nice with distributed version control. South is
like rails migrations and is in general a very good thing. Without it we
will soon start rolling out upgrade scripts that are just an ugly
reimplementation of the idea.
* Support for background (asynchronous) bundle processing. Currently the
bundle is deserialized immediately during the put() request. This does
not scale very well and we should really do this in the background.
There are several solutions on how to implement background processing
for Django apps and I'd like to select something _really_ simple until
it is obvious we need more. There is a project called django-chronograph
that essentially allows to use cron-like tasks inside django.
Chronograph itself is triggered from cron (or some other external
cron-like program) and then proceeds to process jobs defined within
django apps. For this cycle I'd like to add chronograph dependency and
move deserialization into a periodic task.
* Better information about failed bundle imports. Currently there are
some issues with the way databrowse application works (it seems to choke
on OneToOne fields and GeneralRelation fields. This makes it impossible
(AFAIR) to navigate to bundle deserialization information from the
bundle itself and in general makes it hard to know what went wrong. I'd
like to provide a basic set of views that show streams and bundles and
provide a clear indication of deserialization errors there. This would
be based on existing work on bundle stream views so it should fit in
this cycle.
* Better unit tests for django views. As discussed with James Westby we
should have several approaches to each view we offer. We should test for
the contents of the django rendering context (the data that goes in the
template) _and_ scrub some of the HTML output to see we didn't make a
typo in the template or other similar issue. In general we should add
the front-facing view tests and I'd like to spend some time on this.
* Initial work for JSON validator. There is a branch with generic JSON
schema validator. I'd like to finish this branch (add several missing
validators we need) and make it possible to include this validator in
0.3. It would change how we do deserialization from JSON to the
database. It would no longer require us to use launch_control.models.*
(so less dependency on client side code, something we wanted to have to
be able to release them separately in the future). It would also
dramatically improve the error messages. I would not merge the branch
into trunk yet but rather merge several extra branches into the
.json-schema branch itself and get those reviewed as usual.
* Initial support for user authentication. I would like to add
sign-in/sign-out elements to the web UI. This will allow us to have
private/team streams and while not exciting in the short term it is a
required step to getting full support for private (and non-anonymous)
test data in the system.
A roughly identical list of planned changes is also here in my redmine
instance: http://suxx.pl/redmine/projects/launch-control/roadmap
That is all. Please tell me what you think.
Best regards
Zygmunt Krynicki
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQEcBAEBAgAGBQJMnwZ1AAoJEKkR4hQBRI+lXmQIAJ+JUlYfz1bHWbEc47GqNZ/I
w1JwFHDpmKNsDRvNAeYgYC1IRFSIhf8XiKOgCwWya4HHePmL5gTDA8AaTCz3R5zj
mgNHOqawYLnx5reaffYDAKY8L4mDFknScUV5M416YIBvy//Cgfn4yJ4oY0e+3Lkv
6Z1fP607mokZzZNGYb1GOel51JZ4JpCnZqI+UJSOaIvLv2S2zyVtB9dhzNNCWNlf
cFwtacwBEG7lTrftB98NzzkvHRkD76Qwt596wEpdaQqHe4oiqP2fUC+9+0X7XPkW
XYJzRTKMA6M5dJNohtC5PChqhfR2JohSTiV+LMFyMh/smWqg1k4IrslsC69kXqI=
=ZWBF
-----END PGP SIGNATURE-----
Hi
Notes from today's Landing Teams call; also at
https://wiki.linaro.org/LandingTeams/Meetings/2010-09-24
Cheers,
=== Attendees ===
* Loïc Minier
* Scott Bambrough
* Torez Smith
* Mounir Bsaibes
* Matt Waddel
=== Agenda ===
* Action items from last meeting.
* Achievements / progress reports
* OMAP3
* Versatile Express
* AOB
=== Action Items ===
* Torez to talk to james_w to create an IGEP hwpack
=== Action Items from Previous Meeting ===
* Matt to post LTP results for Vexpress on linaro-dev@ or on the wiki
* Matt to close uInitrd u-boot-linaro bug (LP #627843)
=== Minutes ===
* Action items from last meeting.
* Matt to post LTP results for Vexpress on linaro-dev@ or on the wiki
. DONE
* Matt to close uInitrd u-boot-linaro bug (LP #627843)
. DONE
* Achievements / progress reports
* OMAP3
* LCD corruption has a fix; Torez needs to test and then Nicolas needs to merge and John needs to upload
* eth0 is working out of the box now
* wifi support for igep: should definitely be a hwpack at this point; Torez will talk to james_w to see how to create one
* Paul handed a XM to Torez and Stephen sent a new one to Torez
* Loic will ship an EVM to Torez
* Torez can check with ndec (Nicolas Dechesnes) for PowerVR drivers
* Versatile Express
* Worked on LTP testing
* ALSA was working on Vexpress
* flash-kernel changes committed to bzr, not uploaded yet though
* Will drop Monday meetings as they are too close to the Friday meetings and don't add much value
--
Loïc Minier
Hi,
I've recently changed l-m-c to take an hwpack, which is installed before
the image is built. To keep that change simple I had to unpack the
binary tarball into a tmp directory, install the hwpack, repack the
tarball and then continue with the image generation. This extra
unpacking/repacking of the binary tarball is obviously not ideal, so I'm
now refactoring l-m-c to make it possible to avoid it when installing an
hwpack.
The one thing I'm not sure about is whether I should
a) unpack the binary tarball to a tmp dir, install the hwpack (which
may cause lots of data to be written) and then move that to the SD card
or
b) unpack the tarball straight into the sd card (as is done currently)
and then install the hwpack
I'm leaning towards a) because of the poor write speed of SD cards, but
if anybody knows of any reasons why I should go with b) now's the time
to tell me. :)
Cheers,
--
Guilherme Salgado <https://launchpad.net/~salgado>
Hello!
Please see below for my rough notes from the kernel consolidation,
and please reply to the group with any errors or omissions.
Thanx, Paul
------------------------------------------------------------------------
Attendees: Arnd Bergmann, Dave Martin, Jeremy Kerr, John Stultz,
Mounir Bsaibes, Nat Waddell, Nicolas Pitre, Steve Sakoman,
Paul E. McKenney.
o Kernel Consolidation -> Kernel. Job 1 will of course continue
to be kernel consolidation, but will continue to take on other
kernel work.
o Kernel requirements
(https://wiki.linaro.org/Internal/TSC/MinutesToBeAgreed)
o Virtualization requirements
(https://wiki.linaro.org/Internal/TSC/MinutesToBeAgreed)
Arnd Bergmann, Dave Martin. Discussion of implementation
strategy -- full virtualization vs. paravirtualization.
TrustZone.
o Requirements schedule
o Requirements discussion, mostly in TSC.
o Discussion and refinement at Orlando.
o Blueprint generation in the 2-3 weeks following Orlando.
o Round table:
o Arnd Bergmann: BKL work mostly submitted. Looking into
I/O spaces and SoCs -- address-space annotation.
o Dave Martin: One perftools patch to be pushed to mainline.
John Rigby working on build of perftools.
o Jason Hui: iMX51 work on device trees. Need assignment.
Reviewed BSP review, need to send results to Loïc et al.
o Jeremy Kerr: Device tree response to review comments, API.
Adding more platforms into device tree -- use device-tree
properties.
o John Stultz: OMAP emulation environment work -- preparation
for clock consolidation. Networking is not working.
First revision of POSIX clock RTC patch, working second
revision.
o Mounir Bsaibes: New presentation for blueprints, almost
done. Working on howto for writing specifications.
Tracking mechanism.
o Nat Waddell: Several Versatile Express bugs fixed last
week, especially frame-buffer tearing problem. Lorenzo's
kernel built and boots, but cannot get frame-buffer display
working. Device-tree problem? [Follow up with Lorenzo.]
o Nicolas Pitre: Merge bug fixes for ARM, including some
GDB vector-page-backtrace problems (related to atomic
operations). Pulled upstream patches from mainline.
SECCOMP support -- syscall restrictions for untrusted
code.
Q: /dev/mem protection from Kees Cook? A: Might.
o Paul McKenney: TSC meeting. RCU bugs, priority boosting.
o Steve Sakoman: Expansion-board detection in uboot for
OMAP3, save environments for eMMC for boards lacking
flash memory, bring Panda support to latest 8-layer
boards just appearing (about 12 patches required).
Expect to submit upstream later this week.
o Dave Martin on holiday Thu through next week.
Hi there,
I've followed the instructions on
<https://wiki.linaro.org/Source/ImageInstallation> to generate a qemu
image using linaro-media-create and although the image was generated
fine, I got the following error when trying to run it:
qemu: hardware error: no boot device found
CPU #0:
R00=00000000 R01=00000000 R02=00000000 R03=00000000
R04=00000000 R05=00000000 R06=00000000 R07=00000000
R08=00000000 R09=00000000 R10=00000000 R11=00000000
R12=00000000 R13=00000000 R14=00000000 R15=400140a4
PSR=400001d3 -Z-- A svc32
Aborted
That was using today's daily headless tarball, btw.
Any ideas what's wrong?
--
Guilherme Salgado <https://launchpad.net/~salgado>
