For everyone who packages kernel trees:
I've had some questions about getting the source for linaro kernel
packaged, and it seems that this is still not straightforward:
Getting the debian package source (i.e., flat tarball) for a binary
kernel is possible, but only if it is a non-superseded version.
Working out which source package you need is non-obvious (You have to
check for installed kernel packages, and guess which source package
you need, based on that. Non-linaro folks may not understand the
difference between the various meta- and real kernel packages and may
get pretty confused along the way.)
Finding the git tree and the relevant commit to reproduce the source
(including that for superseded kernels) is hard or impossible. It
requires guesswork and/or specific knowledge about the way the
relevant team manages their trees. For some platforms, it looks like
there may be no single tree containing the packaged kernel at all, in
which case you would also need more guesswork and/or scripts or help
from the relevant landing team in order actually to reproduce a
release.
Am I correct in these conclusions?
If so, here's a proposal -- I welcome people's comments (and please do
say if any of these problems are actually solved already!):
For every binary kernel package (.deb) publicly released by any linaro
team, including those produced by the platform team and the landing
teams:
1) The source package's control file must contain a Vcs-Git entry
2) The Vcs-Git entry must reference a git tree which contains the
_exact_ source code which appears in the source package.
* Such a tree must exist and must be publicly readable. It does not
have to be on git.linaro.org (though this is the recommended place).
* Referring to git://git.linaro.org/ubuntu/linux-linaro.git is not
acceptable, unless that repo is populated with the real source for
that specific kernel as well as the packaging.
* Manufacturing the source package from the contents of multiple
repositories or branches at source package upload time is not
acceptable, unless the result is also recorded as a tagged commit in
the repository referenced by the Vcs-Git entry in the debian/control
file contained in that same commit. The commit must have full
history: importing tarballs directly into a repository for the purpose
of release tagging is not acceptable.
* Referring to a tree which does not contain the whole contents of
the debian source package (for example, debian/ and other packaging
files/dirs are missing) is not acceptable.
3) Tagging of packaged kernels must be done in a standard way.
* I recommend <source package name>_<package version>, matching the
Source field of debian/control and the version number of the most
recent debian/changelog entry respectively (which must both be present
in the repository as a consequence of (2)). If we want to avoid
namespace pollution, we probably want to add a prefix such as debian/
or ubuntu/ to the tag name to indicate that the tag describes the
source for a published .deb package. If so, we must standardise that
prefix so that it is identical in all out trees.
* Tree maintainers are of course free to add any other additional
tags for their own use if they want to.
All teams already do release tagging of some sort, but the lack of
consistency creates difficulties when anyone from outside the team
tries to understand that team's trees.
* We _could_ standardise the following, but it is not essential:
* ubuntu/<release>: The tagged source for the _original_ kernel
which was distributed in <release> (where <release> is a linaro
monthly release such as 11.12 or 12.01)
4) No specific branch naming requirements exist.
* Release tags do not necessarily need to appear on any branch.
* We _could_ standardise the following, but it is not essential:
* ubuntu/latest - the tagged packaged source for the most recent
kernel release made from this tree
(In the above, we could choose a diferent prefix instead of ubuntu/,
but as described in (3) ,this should be chosen globally and _not_ on a
per-tree basis).
Cheers
---Dave
Hey folks,
Just like to announce the Ubuntu LEB 12.01 RC images, and the pointers
for people that want to check the testing progress and such (or even
helping testing them).
Currently we're tracking our test cases at
https://wiki.linaro.org/Platform/QA/TestCases/Ubuntu (most of them
requires manual effort at the moment, but we're improving that with
LAVA in the following weeks). If you think about any other important
test case that we might be missing here, please let me know and we can
add it at our testing cycle.
You can find all the 12.01 RC builds (for all boards and image
flavors) at http://snapshots.linaro.org/oneiric/, with build id
20120123-1.
For our four main boards we also have a testing spreadsheet, were we
publish the official release testing, done by the dev plat engineers.
You can find the links at
https://wiki.linaro.org/Platform/DevPlatform/Testing (note that you
can find the bug reports from the test cases by looking at the QA page
tag links).
Fathi will be coordinating all respin requests in the next following
days at linaro-release m-l, and the final image will be published this
thursday, at releases.linaro.org.
Please also be sure to publish any bug report with the RC images
against https://launchpad.net/linaro-ubuntu, or just contact us at
#linaro @ freenode
(https://wiki.linaro.org/MeetTheTeam#Developer_Platform).
Thanks,
--
Ricardo Salveti de Araujo
Dear Linaro,
I am using the image from your staging distribution or ICS Android:
http://releases.linaro.org/11.12/android/images/staging-panda/
I would like to build the latest Streamline gator driver, and gatord daemon. I had a look at the GIT repo but I am afraid this is too complex for me to find what I need (http://git.linaro.org/gitweb).
(1) Could you please advise where I would find the matching kernel (a) sources and (b) config for Panda?
-----------
On a similar note, I am also running the latest Ubuntu (Panda) distribution. I was recently updated to kernel version v3.1.1.8 (linaro-lt-omap) using "update-manager".
(2) Could you also help me to find the sources for this version (or any version used in the Linaro Ubuntu distributions for that matter). If there is a way to apt-get the sources that would be very useful to know as well.
Any help would be much appreciated.
Best Regards,
Frederik Lotter
******************************************************************
Frederik Lotter, Application Engineer at ARM Ltd.
UK Support Team....: +44 (0)1223 400600
US Support Team....: +1 512 381 2928 110
Direct Dial........: +44 (0)1223 400549
Email..............: Frederik.Lotter(a)arm.com
******************************************************************
-- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
Hi All,
I'm excited to confirm that Linaro Connect Q2.12 will be held from 28 May -
1 June 2012 at the Gold Coast Hotel in Hong Kong.
This will be Linaro's first major event in Asia, and quite possibly the
largest Linux on ARM event to be hosted in that part of the world. As well
as being a convenient location for many of our Member engineers, its also in
good proximity to a number of ARM's leading Cortex-A licensees and reflects
the growing importance of that region to ARM open source software
development.
The event website is now available on our main Connect website, and when
registration and hotel bookings open I will send you an updated e-mail:
http://connect.linaro.org/events/event/linaro-connect-q2-12/
Thx
Stephen Doel
Chief Operating Officer
T: +44 1223 45 00 23 │ M: +44 77 66 014 247
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro/155974581091106>
Facebook | <http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog
Hello,
I'm Grégoire Gentil, the founder of Always Innovating. I intend to
participate to Linaro Connect Q1.12 though I'm not part of this
organization. I follow the work of Linaro and I find it very interesting
for our OMAP-based products such as the HDMI Dongle:
http://www.alwaysinnovating.com.
I don't know if it's the right forum or if such discussion has already
taken place, but there is one point that I would like to raise up:
release frequency. Linaro is currently on a one-month period, which is
very tight. To my mind, such small period presents two disadvantages,
long-term perspective and innovation:
- if there is a new release every month, it's hard to know which release
is *very* stable and should be used by an external company which might
not have the same frenzy to update all the time.
- Regarding innovation, Linaro might learn from the Ubuntu experience.
Mark Shuttleworth was a strong advocate of the strict Ubuntu short
release schedule and he admitted later that a too frequent period
prevents from innovating. When you are pressed by a schedule, it's hard
for the organization to step back and take the time to break-through on
a novel approach.
The point of my email is not to convince Linaro to change the current
situation but to bring an idea for a complementary approach at least for
the first point:
for instance, let's imagine a Linaro "super-stable once sometimes"
release. Right now, people are desperately looking for a "good" ICS
image - read Pandaboard groups if you are not convinced -, and ICS won't
change that much during the year. Perhaps there will be a 4.1 but when
you are doing a commercial product, you don't need the latest of the
latest and you certainly don't want to change your build process every
month. If there was a "good" ICS release today, I think that it would be
a major blockbuster for a lot of companies following Linaro. I'm
mentioning the Android example because it's what people want today, but
tomorrow it might be Meego or whatever. I'm not saying to stick to
Google schedule, it's just an example of what is trendy today and would
deserve long-term stable bits.
To go one step beyond in my thinking, I'm not advocating for a new
separate *strict* longer schedule. The idea might be more to have *A*
milestone release from time-to-time, after something major is out
(Android release, new ARM cortex), and Linaro decides that this next
monthly release should be a major one, very polished, very stable and
it's properly supported and advertised with clear wiki and updates for
security or critical problems.
The point of my email was not to criticize the very interesting work of
Linaro but to give an external point of view. Let me know if Linaro has
already done some thoughts about this topic, and if such discussion can
occur formally or informally at the coming Connect event.
Best regards,
Grégoire Gentil
Founder Always Innovating
http://www.alwaysinnovating.com
On Mon, 2012-01-23 at 18:28 +0100, Marcin Juszkiewicz wrote:
> Hi
>
> I am arriving on Saturday evening and wondered what to do on Sunday.
> Usually I spent time going to shops to buy some electronics but this
> time I think that will leave it for Amazon instead.
>
> That leaves me Sunday for sightseeing. According to Google Maps trip to
> Golden Gate bridge takes 2.5h by public transport or 40 minutes by car.
> But looks like there is no car rental in hotel ;(
>
> Is anyone interested in going for some tour? I think that San Francisco
> has some nice places to view.
Hello
please find below the summary of the status report for wk03.2012. The
full report with details is in
https://wiki.linaro.org/WorkingGroups/Middleware/Multimedia/WeeklyReport
Latest weekly meeting notes:
https://wiki.linaro.org/WorkingGroups/Middleware/Multimedia/Notes/2012-01-17
= Highlights =
- 12.01 release. Some statistics:
+ started with 16 Blueprints. Due to splitting the total number of
blueprints became 20 out of which:
+ Completed: 3 blueprints
+ In good progress - may finalise in 12.01: 5 blueprints
+ Rescheduled for 12.02: 6 blueprints
+ Moved back to backlog: 5 blueprints
+ Finally 1 Blueprint remains to be determined if it will go to
backlog or 12.02
Also worked on 1 extra technical debt blueprint (CMA Debug)
The development was plagued by lots of issues (see below), which
resulted in a lot of work in progress (team moving about trying to find
how to best proceed). Despite the statistics, the cycle was a success
since many of the issues were unearthed and pushed for fixing, hopefully
improving the chances for good future releases.
- Lots of troubleshooting for audio issues
- Completed CMA debug blueprint - technical debt from 11.12. One of the
issues there was that the CMA lava test is too long to run (> 3 hours),
which means short time to fix any issue (only 2-3 attempts are possible
each day)
- libjpeg-turbo: pulled in qualcomm 565 and 8888 updates, improved
skia_bench time by 100%, pushed to git, integrated in linaro Android
builds, knocked off open ubuntu libjpeg8 bugs, update pushed and in
archive, put together draft lava testcase for tjunittest
- For DRM : dri2video cleanup and patches
- Continued tinyalsa/tinyhardware work for UCM
- Continued e2eaudiotest - wrote tinyalsa based testfreq
- Libav AAC decoder optimisation in progress, NEON code reviews for
Libav and x264
= Issues =
- Bugs
+ #893402 is still an issue for end-to-end audio testing, it mostly
works with the right configuration but there should configuration fixed
on the rootfs and also there are cases where bus exceptions can appear
(see bug commentary)
+ #911860 Android NEON detection is busticated - Triaged
+ #912035 - Android: skia-bench segvs - Fix Committed
+ #898395 - jpegint.h missing in -dev package - Fix Committed
+ #889844 - Audio on HDMI is not working on trackin-panda - Fix
Released from Landing Team
+ #908957 - ICS: All arches: No aplay / arecord or equivalent
+ #880173 - Audio does not work on Upstream Panda
- Other issues
+ skia_bench timers inconsistent, it is difficult to evaluate
performance improvement
+ Remaining Realvideo work on hold pending completion of upstream
changes to decoder
+ LAVA: what is the best way to verify testcases?
Best regards,
--
Ilias Biris ilias.biris(a)linaro.org
Project Manager, Linaro
M: +358504839608, IRC: ibiris Skype: ilias_biris
Linaro.org│ Open source software for ARM SoCs
