Hi.
I was wondering if anyone would object to namespace cleanup of our
python projects.
Here is my proposed list of changes:
For "linaro-django-pagination"
This project is a fork of dead/unmaintained django-pagination. The
upstream author has rejected my requests to hand over ownership.
Proposed names:
-> django-good-pagination
-> django-linaro-pagination
For "linaro-django-xmlrpc"
This project is a generic-purpose, written-from-scratch, XML-RPC
component for django. There are numerous similar projects out there,
including django-xmlrpc
Proposed names:
-> django-secure-xmlrpc
-> django-web-api (if we include JSON-RPC/ajax in the future)
-> django-linaro-xmlrpc
For "linaro-json":
This project started as a huge collection of tools for JSON but was
later on refocused on one important thing - schema validation.
Proposed names:
-> json-schema-validator
-> json-schema (still unused on pypi :-)
For "linaro-dashboard-bundle"
This is the library that encapsulates the official dashboard bundle
(that sounds important) schema and assorted tools. Since now we have
LAVA I wanted to take the chance and give it a better name
Proposed names:
-> lava-bundle
-> lava-dashboard-bundle
-> lava-test-container
I would like to know what you think. If I missed anything please let me
know.
Thanks
ZK
As you might know already, Linaro is moving to a monthly release of
technology preview for most of the components being worked on. This
obviously includes the kernel, so some coordination amongst all people
involved is required.
It was decided that those releases would happen on the last Thursday of
each month, so for the 11.06 release this is June 30th.
To give a chance for the kernel to be stable by that time, I'll
effectively freeze it one week earlier i.e. on June 23rd for the 11.06
release. The last week before the actual release should be dedicated to
testing and bug fixing only.
So... what this means is that you need to send me any patches and/or
pull requests for the Linaro kernel at least _8_ DAYS BEFORE THE
RELEASE. Obviously, you can send me patches way before that deadline as
well, which would be highly appreciated. Today is June 14th, meaning
that there are less than 9 days left (less so if you don't include the
weekend).
We also hope that everyone will try to perform a bit more testing than
usual during the last week, and also get involved in bug fixing
activities until the release.
If you have some concerns about this please let me know so we can find
ways to improve things. Hopefully we'll get up to speed with this pace
and there won't be any major problems.
Nicolas
Hi Arnd,
These are a number of trivial-and-simple patches that have been reviewed on
the LAKML mailing list. They are independent patches that are mostly
self-descriptive.
The clock added for TWD play with a patch that will be merged out-of-order
with this one, that makes the timer core reschedule events on the localtimer
when the CPU changes frequency. Marc Zyngier is carrying that patch as
part of the localtimer consolidation attempt.
There might be more coming, but this is good to pull in as a base for
the soc tree.
The following changes since commit 56299378726d5f2ba8d3c8cbbd13cb280ba45e4f:
Linux 3.0-rc4 (2011-06-20 20:25:46 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-stericsson.git
for-arnd
Linus Walleij (8):
mach-ux500: add HREFv60 Kconfig option
mach-ux500: fix HREFv60 regression
mach-ux500: correct MMC/SDI parameters
mach-ux500: activate USB in the U8500 defconfig
mach-ux500: complete regulator constraints for MOP500 board
mach-ux500: register a clock for the SMP TWD
mach-u300: cleanup clockevent code
mach-u300: set apropriate FIFO trigger levels
Mattias Wallin (1):
mach-ux500: iomap PRCMU TCDM memory
arch/arm/configs/u8500_defconfig | 6 +++-
arch/arm/mach-u300/spi.c | 4 +-
arch/arm/mach-u300/timer.c | 33 ++++++-----------
arch/arm/mach-ux500/Kconfig | 8 ++++-
arch/arm/mach-ux500/board-mop500-regulators.c | 9 ++++-
arch/arm/mach-ux500/board-mop500-sdi.c | 42 +++++++++++++++------
arch/arm/mach-ux500/board-mop500.c | 3 ++
arch/arm/mach-ux500/clock.c | 48 +++++++++++++++++++++++++
arch/arm/mach-ux500/cpu-db5500.c | 1 +
9 files changed, 116 insertions(+), 38 deletions(-)
W dniu 21.06.2011 07:30, Michael Hudson-Doyle pisze:
> Hi guys (who else should I be emailing this sort of thing to?),
>
> After making rapid progress on the scheduler last week, today I've hit a
> bit of a stumbling block. Basically, we're implementing a queue in SQL
> with this sort of pseudo-code:
>
> 1) look for a job we could run
> 2) mark it as running
> 3) commit
>
> There's an obvious race condition here if two requests overlap which
> could result in the same job running on two boards. I know how to
> prevent this in two ways for postgres:
>
> 1) This way: http://johtopg.blogspot.com/2010/12/queues-in-sql.html
> 2) Relying on SERIALIZABLE isolation level and retrying request that
> fail to commit (this is what Launchpad does)
3) I never tried this solution and I don't know how this is different
from 2) but let's try this. Hopefully it would still work on SQLite.
A Queue has to operations: get() and put(). Put appends an item to the
queue, get removes an item from the front of the list.
CREATE TABLE queue
id PRIMARY KEY,
aid UNIQUE INTEGER,
...
Put is trivial, as in the code you linked to, just insert, keep the
helper 'aid' (allocation ID) NULL.
Get is trickier as we need to make sure that no two consumers allocate
the same queue item. Regardless of isolation levels you use a unique
constraint will always work, only one client would succeed in getting
the UPDATE query below to work. The other will get an IntegrityError and
can try again (to fetch another item).
# First we need to get an allocation id. We could use something
different here (like a sequence or some other good identifier). In this
example I'll just take next largest existing 'aid'.
SELECT IFNULL(MAX(aid)+1, 1) AS new_aid FROM QUEUE;
# Then we need to allocate a row for processing. We do that by trying
# to update it with the 'aid' we computed above. We only update one row
# - the oldest one (here designated by a row with the smallest ID) that
# is still not allocated.
UPDATE queue
SET aid=new_aid
WHERE
id=(SELECT MIN(id) FROM queue WHERE aid IS NULL);
> The problem is that in tests we run against SQLite, and I don't know if
> either technique really applies to django+sqlite (the first approach has
> postgres specific syntax and for the second, django appears to really
> really want to run in autocommit mode).
Fortunately django almost never runs in autocommit mode. There is an
implicit transaction around the whole request. It is easy to control the
transaction processing around a piece of code, see [1]. On PostgreSQL we
also need to properly implement handling of IngegrityError as it differs
significantly from SQLite [2]
> This will probably work out OK, but we won't be able to test the
> postgres variant.
The test script that was in dashboard tree tested the app in sqlite and
postgresql. If you want to test that the queue is indeed working let's
move it to a dedicated app (django reusability :-) setup a small
instance on postgress and bombard it with queries.
> Does this sound sane to you guys?
I would rather have a single solution for both databases if possible. If
not then perhaps SQL is not the right way to implement a queue but that
would significantly complicate our work.
CCing to linaro-dev, somebody might be interested.
Best regards
ZK
[1]:
https://docs.djangoproject.com/en/dev/topics/db/transactions/?from=olddocs#…
[2]:
https://docs.djangoproject.com/en/dev/topics/db/transactions/?from=olddocs#…
Hi Eric,
I recently saw your mail to Dajun, on your people eagerness to get the patches upstream soon. We also hold the same vision to get the patches upstream as quick as possible.
In this regard we like to have a discussion so please let us know your convenient time. Please note that as of now we do not have any technical issues on patches but there is a need to understand the patch submission process so we can focus our discussion accordingly.
Regards,
Ashish
+91-9869402911
Hi Gang,
In the past few days I've received a few requests to allow community
members access to our Mumble server.
I don't feel comfortable adding in the large and open linaro-community
team so I am considering making a linaro-community-mumble team to
allow for access. Right now you have to be in ~linaro to have access
to Mumble.
1) I'd like to hear your comments on this, especially if you have
alternative suggestions.
2) If there are community members who should have mumble access, can
you please send me their Launchpad IDs so I can start assembling a
list.
Thanks,
Joey
Hello list,
I am not sure if android-platform@ is the right place to discuss
licensing terms in Android or not. Please ignore the post if it was
mistaken.
Recently, we at Linaro are trying to integrate gcc-linaro[1] into
Android build system as the optional toolchain optimized for latest
ARM cores. We encounter some unknown prelinker issues, and it is an
opportunities for us to look into the implementations of relevant
utilities in Android. However, I am a bit confused about the
licensing terms of some packages.
libelfcopy[2], derived from some parts in binutils, provides the
facilities about DWARF/ELF, and it is quite obvious that libelfcopy is
licensed under GNU GPL version 2+ as the file "MODULE_LICENSE_GPL"
denotes. There are three system tools depending on libelfcopy:
- isprelinked
- soslim
- apriori
build/tools$ grep -r libelfcopy *
apriori/Android.mk:LOCAL_STATIC_LIBRARIES := libelfcopy libelf libebl #dl
isprelinked/Android.mk:LOCAL_STATIC_LIBRARIES := libelfcopy libelf
libebl libebl_arm #dl
soslim/Android.mk:LOCAL_STATIC_LIBRARIES := libelfcopy libelf libebl
libebl_arm #dl
These tools are linking libelfcopy statically, which explicitly
complies with the licensing terms of GNU GPL. But, after checking the
source files (*.[ch]), no license term is claimed.[3] The proper
declaration should put file "MODULE_LICENSE_GPL" into individual
directories at least.
Is my understanding correct?
Sincerely,
Jim Huang
Android Team, Linaro
[1] https://launchpad.net/gcc-linaro
[2] http://android.git.kernel.org/?p=platform/external/elfcopy.git;a=summary
[3] http://android.git.kernel.org/?p=platform/build.git;a=summary
Hi,
http://irclogs.linaro.org/
Logs are now kept from our public channels so that you can refer back to
previous converations and catch up on things that happened while you
were away if needed. They can also come up in google searches which can
be useful.
If you would like a channel added/removed from the logging then please
file an RT ticket by emailing <linaro(a)rt.canonical.com> and explaining
your request. Note that only public channels can currently be logged.
Thanks,
James