As part of the Power Management Work Group, I have been developing a
new tool called PowerDebug which can show users/developers information
on regulators, senors and clock tree. Its time now to package it for
Ubuntu (since, Linaro will pick up the package from Ubuntu repo.). We
also plan to host a project in LaunchPad for this tool.
I am new to Ubuntu and debian way of packaging. Still, have given a
shot at packaging PowerDebug and have put it in my git tree hosted at
: git://git.linaro.org/people/amitarora/powerdebug.git in the branch
called "debian". The "master" branch has only the source code for the
tool.
If you have fare idea about .deb packaging, I will request you to
please review these files and suggest any changes that may be
required. I have also uploaded this under my ppa
(ppa:amitarora/pm-utils).
Thanks!
Regards,
Amit Arora
Greetings,
Enclosed you'll find a link to the agenda, notes and actions from the
Linaro User Platforms Weekly Status meeting dated November 10th held in
#linaro-meeting on irc.freenode.net at 13:00 UTC.
https://wiki.linaro.org/Platform/UserPlatforms/WeeklyStatus/2010-11-10
Status Summary:
- clutter 1.2 EGL_KHR_image_pixmap support for clutter and unity
finished and verified with omap4
- ux500 support landed for release in linaro-image-tools; ux500
release hwpack validated for all heads
- first set of blueprints of multimedia and graphics WG submitted for review
- public review of plans for multimedia WG on Nov 23; for graphics WG on Nov 19
- first experiments on a linaro-development image conducted
- ST-Ericsson succeeded to compile their multimedia pack with Linaro toolchain
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
I'd like to announce that Launch Control (the project) is being packaged
and separated into dedicated launchpad projects/code trees.
I managed to set up two PPAs to make everyone's life easier:
* linaro-infrastructure/launch-control
* linaro-infrastructure/launch-control-snapshots
The first one is designed to hold *releases*, currently it's empty as
there are no new releases yet and old releases are not packaged.
The second one (which I encourage you to use if you are interested in
launch-control) contains daily builds of the following packages:
* python-linaro-json
* python-linaro-dashboard-bundle
* launch-control-tool
The list of packages will grow as I get the whole server decomposed and
packaged. That's right, currently the "dashboard" is not available as a
debian package just yet.
Just as a quick reminder, if you want to add a PPA to your system from
command line you can use add-apt-repository, like this
$ sudo add-apt-repository ppa:linaro-infrastructure/launch-control-snapshots
$ sudo apt-get update
$ sudo apt-get install launch-control-tool
Thanks
Zygmunt Krynicki
Hi all,
thanks to the restless efforts of the User Platforms team and friends,
we have concluded our clutter/mutter/clutk/unity work for the previous
cycle. Although we didn't get to the point of providing an ultra smooth
user experience, this is still a great success and more than we hoped
for at the beginning of the cycle.
You can find all the related packages at ppa:asac/armel1.
For those who are wondering, the fact that Unity will now move to compiz
does not invalidate our efforts at all. Unity was just a means to an
end, a way to recognize some of the ingredients that are needed to
provide a smooth user experience on ARM (and GLES2.0 platforms in
general).
Some highlights from our efforts:
* We clearly communicated our technical and distribution related needs
to upstream clutter and contributed patches to support our goals. As
a result, clutter is progressively becoming more friendly to
distributions that need to ship multiple backends and perform runtime
selection.
* We standardized on and provided a proof-of-concept implementation
for accelerated WM compositing using the EGL_KHR_image_pixmap and
GL_OES_EGL_image extensions for EGL/GLES2.0. This is a critical
feature for providing a smooth user experience on GLES2.0 based
platforms.
* We provided vendors with a real-world test case that can be used
to exercise their drivers on.
For the next cycle we are moving away from active development on clutter
and mutter, but we will still keep an eye on them (esp. clutter). We may
even be able do some more work on them if we have the resources and
there is a high demand for it.
Thanks,
User Platforms team
Lee,
I created a page on how to package a kernel. There are some hacks
here that would not be appropriate when packaging a kernel for a real
upload but should work fine for landing team testing.
https://wiki.linaro.org/PackageYourOwnKernel
John
Hi Oliver,
Answers in-line below.
On 8 Nov 2010, at 15:12, Oliver Grawert wrote:
> hi,
>
> at UDS we discussed the possibility of using linaro kernels for some
> of
> the ubuntu ARM flavours (currently for omap3 images but there might be
> more to come) where we seem to have duplicated efforts in kernel team
> and linaro ...
>
> there were some open questions that require further discussion with a
> wider audience which i'd like to bring up in this mail:
>
> * linaro kernels used in ubuntu ARM would need to move to the
> supported
> package set (main) which makes them fall under all freeze restrictions
> the kernel team sets for ubuntu (only SRUs post kernel freeze, patches
> and changes all need to go through the ubuntu-kernel mailing list etc)
I think we can deal with the via the SRU process. We have already been
using the SRU process this cycle for kernel changes so its a non-issue.
> * configuration changes in the linaro kernels would have to happen to
> match the ubuntu distro kernel configs in all places where they do not
> match yet (this also implies that ubuntu sauce needs to be added to
> the
> linaro kernels for making all distro features available)
I'm not sure Linaro want to carry the Ubuntu sauce and match configs.
Linaro's continued effort to consolidate and stream-line kernels rather
than expand options to cover all eventualities may conflict, this would
need to be carefully investigated.
> * someone has to commit to do security support for these kernels to
> match the 18 months security support we provide for ubuntu images (can
> the ubuntu kernel team and the ubuntu security team commit to that ?)
This would be a problem for Linaro. Currently we have no support options
that look like what you describe above. The only option at the moment
would be for the Ubuntu Security Team to provide security support for
the
kernels once they come out of Linaro unless Linaro change their model.
> if not all of the above bulletpoints (please shout if i missed any
> that
> are obvious) can be fulfulled we can not take linaro kernels for our
> images and another solution needs to be found.
I would love to see the sharing of kernels here. We need to come up with
a good solution of which I don't have at the moment.
I've cc'd linaro-dev in to solicit more comments from the Linaro side.
> ciao
> oli
Regards,
Jamie.
Dnia niedziela, 14 listopada 2010 o 23:26:46 Michael Hope napisał(a):
> Hi there. I've been looking into updating the QT4 atomic operations
> as an alternative to working around it in GCC. There's ARM specific
> code in:
> There are bigger problems here though:
> * There's code in corelib/arch/armv6/qatomic*.c that may also being used
> * qatomic_armv6.h includes code for RVCT which should be updated for
> Thumb-2 by someone
> * The code may not work on multi-processor systems like Panda due to
> the lack of DMB instructions
This is also tracked in https://bugs.launchpad.net/ubuntu/+source/qt4-
x11/+bug/490371
Regards,
--
JID: hrw(a)jabber.org
Website: http://marcin.juszkiewicz.com.pl/
LinkedIn: http://www.linkedin.com/in/marcinjuszkiewicz
Hi there. I've been looking into updating the QT4 atomic operations
as an alternative to working around it in GCC. There's ARM specific
code in:
http://qt.gitorious.org/qt/qt/blobs/4.7/src/corelib/arch/qatomic_armv6.h
that should be updated to include IT instructions so that it can
compile in Thumb-2 mode.
There are bigger problems here though:
* There's code in corelib/arch/armv6/qatomic*.c that may also being used
* qatomic_armv6.h includes code for RVCT which should be updated for
Thumb-2 by someone
* The code may not work on multi-processor systems like Panda due to
the lack of DMB instructions
The better fix would be to replace everything with __sync_* primitives
similar to qatomic_avr32.h and require GCC 4.4 or higher. The same
probably applies to glib.
Thoughts? Any volunteers? It's mildly outside the Toolchain WG's mandate.
See also:
https://bugs.launchpad.net/ubuntu/+source/qt4-x11/+bug/673085
-- Michael
