Hello,
There were some improvements to the Linaro Android Build Service (aka
linaro-cloud-buildd), https://android-build.linaro.org/ . The Jenkins
EC2 plugin was upgraded to the latest version 1.11, which should
improve EC2 instance management. There was also fixed a bug which caused
unreliable build process in case an instance was reused to build
different configurations.
While working towards completely disposable build instances (which
would require patching Jenkins/EC2 plugin), these changes should allow
for sustainable build reliability in the meantime. There were around a
dozen builds since these changes, and none of them showed
infrastructure failures. I hope it now will be easier to concentrate on
actual build failures where they happen.
The Android Build Service documentation is available at
https://wiki.linaro.org/Platform/Android/LinaroAndroidBuildService
Thanks,
Paul
Not sure who to send this to so including Nicolas and Linus.
make u8500_defconfig
make uImage
produces some undefined reference errors. Tail of the build log attached.
Thanks,
John
Hi folks,
I've been working on this app[1] (based on Patchwork) to track patches
submitted/accepted upstream by Linaro engineers. It's still a work in
progress and we're waiting for IS to deploy it but I wanted to show you
what I have so far and ask for feedback, so I've deployed it on an ec2
instance:
http://ec2-184-73-78-92.compute-1.amazonaws.com/
As you'll notice, that's the same front page you get on a regular
Patchwork instance, which allows you to browse the patches of every
project. You probably won't have to use that often, as everything you
need to deal with should be on the page below:
http://ec2-184-73-78-92.compute-1.amazonaws.com/user/submitted/
This one contains all patches you submitted that haven't received
feedback yet. We want that to reflect reality to make sure our metrics
are accurate, so we already have a script to mark the ones that are
committed upstream and may use a similar approach to track
rejected/superseded ones, but for now we'll need to manually mark the
rejected/superseded ones.
The script mentioned above will scan a git repo for each project and
update the state of patches that are found to be committed there, but
it's not running yet as first I need to know the git (http works too)
URL of every project listed there. if you know it for any of them,
please do let me know.
Finally, the page below has some basic metrics to demo how we'll be
using this data
http://ec2-184-73-78-92.compute-1.amazonaws.com/metrics/
Some things to notice:
- This is a temporary deployment, so don't bother making changes (other
than those when playing around) as those will probably be lost
- Login via OpenID using the Launchpad login service, so there's no need
to register
- Not all of your patches may be shown under /user/submitted. if that's
the case, make sure all your email addresses are registered in Launchpad
as we're sucking that data from there periodically and the next time we
do so we'll merge all your email addresses under a single user
- Some numbers in /metrics are skewed because of patches that have
multiple versions; you'll be asked to flag superseded versions so that
they're not included in the counts, and you're encouraged to do so for
some of them to see how it works, but given that changes will be lost,
don't bother doing it for more than a few
- The other-unknown project is where we put patches for which we can't
guess a project.
- in some cases this is because the patches are sent only to
patches(a)linaro.org so they need to be manually moved to the
appropriate project (there's a form at the bottom of every patch
list which allow you to do that).
- in other cases it's because we're missing a project in patchwork. if
that's the case we can register that project and there's a script
which runs periodically and will move these patches to the new
project
[1] https://wiki.linaro.org/Platform/Infrastructure/Specs/PatchTracking
--
Guilherme Salgado <https://launchpad.net/~salgado>
Hello!
Given the increasing numbers of CPUs on low-cost servers as well as
the appearance of SMP hand-held battery-powered devices, Linux Plumbers
2011 will feature a Scaling track, with topics including the following:
- What can the kernel do to help applications perform and scale better?
- What can applications do to help the kernel perform and scale better?
- Memory footprint:
+ 100MB here, 100MB there, pretty soon you are talking real memory!
+ Improving performance by decreasing icache and dcache footprint.
- Limits to scalability:
+ Technological limitations, especially hardware.
+ Complexity/maintainability limitations.
- Handling of non-CPU computational hardware (GPGPUs, crypto HW, etc.)
+ Can the kernel make good use of non-CPU computational hardware?
+ How best to enable user applications to use them?
- Dealing with the numerous remaining "little kernel locks"
The intended audience is developers interested in performance and
scalability throughout the Linux plumbing.
The deadline is April 30th. Please submit your proposals, whether to
Scaling or to other microconferences, at:
http://www.linuxplumbersconf.org/2011/ocw/events/LPC2011MC/proposals
The general track is also open for submissions until April 30th:
http://www.linuxplumbersconf.org/2011/ocw/events/LPC2011/proposals
Either way, we look forward to seeing your submissions!
Thanx, Paul
Hi All,
Not really sure how this is being discussed in the Multimedia WG. But
do we yet have a standardized kernel driver framework for video
acceleration?
A bit investigation showed a chaos in this area:
1. Different SoC vendors are using their specific APIs
2. The freescale case, there is a proposed driver from Sascha using V4L2
interface, yet our analysis showed some issues with this API to support
a full featured usage, and the API itself doesn't just seem to be right for
this (thanks for Jason for a detailed analysis)
3. XvMC (obsolete I believe)
4. nVidia's VDPAU, which is supported by XBMC and many others though
5. VA API (Intel proposed and currently available on Intel graphics), can
use VDPAU as a backend
6. XvBA - AMD is proposing this for the ATI video HW
- eric
U-Boot wrapped dtbImage; useful for testing DT with an unmodified U-Boot.
Signed-off-by: Stephen Warren <swarren(a)nvidia.com>
---
This patch is based on:
git://kernel.ubuntu.com/jk/dt/linux-2.6.git dtbimage
However, I actually developed and tested it only on:
git://git.secretlab.ca/git/linux-2.6 devicetree/test
plus the following commits from jk's dtbimage branch:
4c2eddb89542f73fe626813e3cdafc789f931aec
arm: dtbImage support
4cb80ac96489220554d28f6fde527aeef83e628b
arm/dtbimage: copy dtb blob to offset from image base
I wonder if rather than simply applying my patch below to jk's dtbimage
branch, perhaps it would be better to cherry-pick the two commits I
mentioned above into the devicetree/test tree, after which I can submit
the original change I wrote there?
arch/arm/Makefile | 2 +-
arch/arm/boot/Makefile | 8 ++++++++
2 files changed, 9 insertions(+), 1 deletions(-)
diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index dab066a..3ce1751 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -264,7 +264,7 @@ archprepare:
# Convert bzImage to zImage
bzImage: zImage
-zImage Image xipImage bootpImage uImage dtbImage: vmlinux
+zImage Image xipImage bootpImage uImage dtbImage dtbuImage: vmlinux
$(Q)$(MAKE) $(build)=$(boot) MACHINE=$(MACHINE) $(boot)/$@
zinstall install: vmlinux
diff --git a/arch/arm/boot/Makefile b/arch/arm/boot/Makefile
index c608c98..a8f4251 100644
--- a/arch/arm/boot/Makefile
+++ b/arch/arm/boot/Makefile
@@ -66,15 +66,19 @@ quiet_cmd_uimage = UIMAGE $@
ifeq ($(CONFIG_ZBOOT_ROM),y)
$(obj)/uImage: LOADADDR=$(CONFIG_ZBOOT_ROM_TEXT)
+$(obj)/dtbuImage: LOADADDR=$(CONFIG_ZBOOT_ROM_TEXT)
else
$(obj)/uImage: LOADADDR=$(ZRELADDR)
+$(obj)/dtbuImage: LOADADDR=$(ZRELADDR)
endif
ifeq ($(CONFIG_THUMB2_KERNEL),y)
# Set bit 0 to 1 so that "mov pc, rx" switches to Thumb-2 mode
$(obj)/uImage: STARTADDR=$(shell echo $(LOADADDR) | sed -e "s/.$$/1/")
+$(obj)/dtbuImage: STARTADDR=$(shell echo $(LOADADDR) | sed -e "s/.$$/1/")
else
$(obj)/uImage: STARTADDR=$(LOADADDR)
+$(obj)/dtbuImage: STARTADDR=$(LOADADDR)
endif
$(obj)/uImage: $(obj)/zImage FORCE
@@ -97,6 +101,10 @@ $(obj)/dtbImage: $(obj)/dt/dtb FORCE
$(call if_changed,objcopy)
@echo ' Kernel: $@ is ready'
+$(obj)/dtbuImage: $(obj)/dtbImage FORCE
+ $(call if_changed,uimage)
+ @echo ' Image $@ is ready'
+
PHONY += initrd FORCE
initrd:
@test "$(INITRD_PHYS)" != "" || \
--
1.7.1
IMPORTANT: If you have your own instance of 0.3 deployed from .debs
please read on.
Hello.
This email contains upgrade instructions for 0.3~c9 -> 0.3~c10 upgrade.
The upgrade process is not automatic due to django-debian maintainer
script backwards-incompatible change. This had to be done because of
design bug I discovered while attempting to implement south support.
UPGRADE INSTRUCTIONS:
0) Optional step: backup your database (pgdump or copy the sqlite file)
1) Backup database settings:
/etc/dbconfig-common/launch-control.conf
/etc/launch-control/default-database.conf
2) Upgrade maintainer script support library from the PPA.
Install 0.5~c1 of django-debian and python-django-debian
3) Upgrade launch-control to transitional 0.3~c10 from the PPA.
First install 0.3~c10 of launch-control and launch-control-$backend
(where backend is sqlite or pgsql)
Maintainer script will ask you if you want to reinstall database, SAY NO
here. At this stage your database settings are lost due to,
unfortunately mandatory, django-debian redesign (due to design flaw).
4) Recover two files you backed up earlier. Just copy them over.
5) Reconfigure launch-control.
Run sudo dpkg-reconfigure launch-control, this should not ask anything,
syslog should have a lot of details about what's happened.
6) Remove legacy configuration directory:
rm -rf /etc/django-debian/
Verify that everything works as before.
If you encounter any problems please let me know, thanks
Best regards
Zygmunt Krynicki