Hello everyone.
I wrote dh_splitpackage, a helper script that unambiguously splits the
files of a binary package into multiple packages based on a
configuration file.
The configuration file may point the primary package (the one that gets
leftover files by default) as well as any number of additional packages
with any number of inclusion and exclusion patterns.
The new script can be called instead of dh_install (assuming all the
files you are interested in are already in debian/tmp/) or afterwards.
The biggest advantage compared to existing tools is clear and
not-that-error-prone classification of files to packages. Any file that
would be classified to more than one package (hitting patterns in both
files) is clearly reported and prevents the package from building
properly. In addition running the script displays each file from
debian/tmp and the package it was classified to.
Using this script could greatly simplify many packages that currently
rely on numerous *.install files and custom dh_install overrides in
debian/rules.
You can find the code at lp:~zkrynicki/+junk/dh_splitpackage (tag:
release-0.1) The source tree also includes debian packaging that makes
use of the new script.
Best regards
Zygmunt Krynicki
Enclosed you'll find a link to the agenda, notes and actions from the
Linaro Developer Platforms Weekly Status meeting held on June 1st
in #linaro-meeting on irc.freenode.net at 15:00 UTC.
https://wiki.linaro.org/Platform/DevPlatform/Meetings/2011-06-01
New Actions:
* suihkulokki and rsalveti to discuss how to work with gles packages
with oneirc (update-alternatives? conflict/provide/replace? new
solution?)
* Dr_Who to check with help from wookey if debian is planning to
package the chromium bits
* aviksil to follow up SMARTT and create a wiki page giving more
details about the tool, how to install and how to run it
* aviksil follow up smartt with kurt to see where would be the
official place to put the code and make releases
* everyone, go over
http://status.linaro.org/natty/linaro-foundations.html and
close/postpone remaining items
Carried Over Actions:
* hrw and rsalveti to discuss with michaelh1 about a possible merge of BPs
Regards,
Tom
Developer 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
IRC) Dr_Who, tgall_foo
The Engineering Resources team has just updated information on
blueprints in the wiki. The page is the same:
https://wiki.linaro.org/Process/Blueprints
Before going further I want to clarify: The changes *do not* add
additional work to anyone. The goal was to make everyone's life a little
_easier_.
The changes were driven by feedback, experience, and discussions at UDS.
So let me first answer the "what's in it for me" question:
* consistency - in the past, information wasn't totally consistent.
The new pages should be consistent in content and also consistent
with what you here when you ask around about things.
* clarity - Linaro uses blueprints for more than one purpose and in the
past we haven't been that clear on this matter.
* one less blueprint - Linaro has sort of done 3 types of bp's:
1) Engineering Blueprint
2) Tech Requirement Blueprint
3) Session Scheduling Blueprint
The 3rd type isn't always needed now, and we've clarified when you
would need this. This will be in my yearly review as "a 50%
reduction in blueprints" :)
Summary of changes:
* the old Blueprints page you remember is now mostly contained in:
https://wiki.linaro.org/Process/Blueprints/EngineeringBlueprint
* the new main page shows you the two types of bp's and helps lead you
to the proper page in the wiki that you are needing information on.
* a new page for Tech Requirement Blueprints:
https://wiki.linaro.org/Process/Blueprints/TRBlueprint
* scheduling sessions at UDS:
https://wiki.linaro.org/Process/Blueprints/SchedulingBlueprint
* two new pages based on Mounir's past work:
https://wiki.linaro.org/Process/Blueprints/ImplementationWorkflowhttps://wiki.linaro.org/Process/Blueprints/DefinitionWorkflow
Feedback/Comments/Complaints are always welcome.
-andy
An ifdef in drm.h expects to be compiled with full-fledged Linux
toolchain, but it's common to compile kernel with just bare-metal
toolchain which doesn't define __linux__. So, also add __KERNEL__
check.
Signed-off-by: Paul Sokolovsky <paul.sokolovsky(a)linaro.org>
---
include/drm/drm.h | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/include/drm/drm.h b/include/drm/drm.h
index 4be33b4..45435e3 100644
--- a/include/drm/drm.h
+++ b/include/drm/drm.h
@@ -36,7 +36,7 @@
#ifndef _DRM_H_
#define _DRM_H_
-#if defined(__linux__)
+#if defined(__KERNEL__) || defined(__linux__)
#include <linux/types.h>
#include <asm/ioctl.h>
--
1.7.1
Please check the status report in th wiki
https://wiki.linaro.org/WorkingGroups/Middleware/Multimedia/WeeklyReport
for more information and links.
== Team Highlights ==
11.05 release: libjpeg-turbo and smartt released. Smartt not a tarball
yet but we may get some help to get this released via a launchpad
project for this work. Need to get the individual patches from the
team sent out, in order to get feedback. Sending to patches(a)linaro.org
in order to get our patches counted to the Linaro metrics (this is
important for libjpeg-turbo as there is no libjpeg-turbo wide
community for now - we need to investigate about the upstreaming of
jpeg-turbo). Patches are right now being added to git.linaro.org.
Getting ready for the mini-summit, team has been asked to look through
the summit topics and give feedback.
Those who will not be able to attend in person, should try to get on
the conference line, and check the recorded meeting to review what was
discussed.
Suggestions for topics not covered in the agenda for the mini summit
- obviously OMX vs not-OMX vs something else
- gstreamer (0.11 or 1.0) in order to address some of the
challenges that we and other vendors have seen. Parsers
- Android work related to OMX work and the consolidation work that
the group is targeting could also be another point for the mini-summit
discussion - Kurt to discuss with Zach also on the Android pain points
and what Android folks would need to have fixed.
- Related to the Memory Management activities - 0-copy is the area
of interest in Multimedia. We will review the list of work items in
the mini-summit. As for the impact of the work to other components -
eg EGL API for video related images/surfaces may affect userspace
gstreamer APIs (or other multimedia framework) - to what extent
remains to be seen
Validation tasks (Mandeep) - looking at some new techniques for
analyzing code during optimization.
Worked on the gst-openmax with video raw format mapping
Putting together some documentation notes for the interface issues with OMX.
Uploaded the multimedia test content for 5 codecs (as indicated in
meeting minutes from 31.05.2011) - is the list of video codecs
sufficient or do we need more?
BR,
*************************************
Ilias Biris,
Aallonkohina 2D 19, 02320 Espoo, Finland
Tel: +358 50 4839608 (mobile)
Email: ilias dot biris at linaro dot org
Skype: ilias_biris
*************************************
Hi Marek,
Thanks for your review.
On Friday 03 June 2011 11:23 AM, Marek Szyprowski wrote:
> Hello,
>
> On Friday, June 03, 2011 7:07 AM Tushar Behera wrote:
>
>> EHCI requires that USB support be enabled in kernel config.
>> Selecting USB_SUPPORT with S5P_DEV_USB_EHCI fixes the problem.
>>
>> Signed-off-by: Tushar Behera<tushar.behera(a)linaro.org>
>> ---
>> arch/arm/plat-s5p/Kconfig | 1 +
>> 1 files changed, 1 insertions(+), 0 deletions(-)
>>
>> diff --git a/arch/arm/plat-s5p/Kconfig b/arch/arm/plat-s5p/Kconfig
>> index e98f5c5..c7e7419 100644
>> --- a/arch/arm/plat-s5p/Kconfig
>> +++ b/arch/arm/plat-s5p/Kconfig
>> @@ -87,6 +87,7 @@ config S5P_DEV_CSIS1
>>
>> config S5P_DEV_USB_EHCI
>> bool
>> + select USB_SUPPORT
>
> IMHO this is not the best way to solve this issue. The main problem is
> the fact that usb-phy.c file depends on CONFIG_USB_SUPPORT not it's own
> Kconfig entry. Please check arch/arm/mach-exynos4/Makefile. To match the
> style of other helper functions, usb-phy.c should be renamed to
> setup-usb-phy.c and get it's own Kconfig entry like
> CONFIG_EXYNOS4_SETUP_USB_PHY. Also the machine that uses it should select
> this new entry. This is really not related to CONFIG_USB_SUPPORT at all
> (one might want to have a kernel without USB support for some reason).
>
>
Ok. I will re-submit the patch.
>> help
>> Compile in platform device definition for USB EHCI
>>
>> --
>
> Best regards
--
Tushar Behera
== Weekly Status report ==
https://wiki.linaro.org/WorkingGroups/ToolChain/Status/2011-06-02
== Weekly Meetings minutes ==
https://wiki.linaro.org/WorkingGroups/ToolChain/Meetings/2011-05-30https://wiki.linaro.org/WorkingGroups/ToolChain/Meetings/2011-06-02
== Summary ==
* Public plan review complete
* More investigation into hot functions in SPEC 2006
* EEMBC benchmarks have arrived
* Dave is profiling the memcpy() variants across the benchmarks
* Planning on the sync primitives is under way. Backwards compatibility is
the hard one.
* Peter has started pushing the OMAP2 patches upstream, which starts to
clear the backlog
* Other performance work is going on:
* Working on vectoriser widening multiplication
* Improving auto increment/decrement for memory accesses
* Talked with ARM's RVDS group re: sharing benchmarks and infrastructure
Regards,
Mounir
