Wednesday 22 Sep 2010

People Present

  • slangasek
  • wookey
  • dmart
  • hrw
  • lool
  • ppearse
  • jcrigby
  • npitre
  • rsalveti
  • JamieBennett


  • Review action items from last meeting
  • Blueprint status
  • Blueprint





    setting up PPA for cross-compilers targeted at other ARM versions; work on package cross-compile fixes ongoing



    cross compiler packages uploaded to fix installability and FTBFS issues; all installable and working now in maverick archive


    npitre, jcrigby

    spec completed; ongoing work tracking bugfixes, preparation of the next "next" tree



    results of compiling with -Os:; benchmarks show this angle is worth further investigation



    Ubuntu kernel security testsuite now enabled on armel; feature complete except for /dev/mem, which is in progress; SECCOMP patch implemented, submitted to upstream



    u-boot 2010.09 rc1 in the archive; continuing to apply fixes as needed for panda, per Ubuntu Mobile team



    xdeb cross-resolution of dependencies in progress. Current results of trying to build ALIP with xdeb and pdebuild-cross:$



    archive delivery postponed, peripheral work ongoing

  • TBA

Action Items from this Meeting

  • hrw to target bug #615765 to debhelper instead of binutils, with explanation
  • lool to solicit toolchain WG input on bug #615765
  • hrw,ppearse to discuss possible versioning problem blocking PPA uploads
  • dmart to test that linux-linaro-tools package in maverick DTRT
  • "marketing" to write a 'what is linaro for dummies'

Action Items from Previous Meeting

  • slangasek to post DebConf 10 gobby notes publically

  • slangasek to nudge Keybuk to review bootchart changes rather than redirecting to upstream, since Ubuntu and upstream are quite out of sync
  • wookey to close out bug #623478 in LP: DONE
  • slangasek to talk with zumbi about proposed emdebian/linaro worksession: DONE


  • TBA

Status Reports

Peter Pearse


  • arm-m-ael-alip-evaluation
    • Alip running on VersatileExpress

    • Cross compiler packages build OK
    • Packages install from internal repositories
  • arm-m-ael-alip-appman-ext
    • None this week


  • Versatile Express display breaks up under load - bug 633417
  • Cross compiler packages fail to upload via reprepro


  • arm-m-ael-alip-evaluation
    • Continue work item "Use cross-compiler binaries with xdeb"
      • Tryout Loic's black listing suggestion for mesa
    • Upload modified native compiler source & rebuild cross-compilers (rather than modifying locally installed source)

    • Set up PPA with modified compiler source & investigate flavour of resulting armel binaries

    • Tag existing cross bugs
  • arm-m-ael-alip-appman-ext
    • Produce new scripts

Nicolas Pitre

  • Review and comments on fgu's Linaro Kernel Config Policy work.
  • New patch to fix LP bug #620611 and posted the result to lak for comments.
  • Implementation of SECCOMP for ARM.
  • Fixed a race in the alignment trap handler and posted the patch on lak for comments.
  • Pulled the above and more fixes in the Linaro stable kernel tree to be included before the kernel freeze date.
  • Misc (meeting attendance, mailing list monitoring, etc.)

Jamie Bennett

This Week

  • Lots of bug triage from all Linaro projects and chasing the team to make sure we are on top of existing bugs. Fortunately bugs are being squished at a good rate.


Hardware Enablement
  • More hardware pack discussions, now we have hardware packs they will need testing extensively.

  • Received a patch for the work item tracker from Ian Smith late in the week. Didn't get around to reviewing it, will do early next week.

  • Meeting with Mounir to discuss his Blueprint presentation and to go over general documentation that will be needed for next cycle. Mounir's blueprint explanation will be combined with my "Planning and Executing the Linaro Release" presentation and sent out to interested parties. Wiki pages that are linked from the documents will then contain the in-depth information.
  • Weekly Foundations, Linaro Release and Ubuntu Release meetings.
  • Project Management in Launchpad call with james_w. The infrastructure team is tasked with making Linaro's tools better for next cycle and on the project management side, some Launchpad changes would make like a lot easier.
    • My initial requirements for a project management aware Launchpad can be found at JamieBennett/MeetingNotes/2010-09-16. Note that these goals are 'in a perfect world' so implementing just some of these ideas would be great.

  • Took a look at several project management and bug reporting solutions including redmine, trac, fogbugz and others to get a good idea on what Launchpad *could* replicate in order to have project management built in.
  • ARM have made a request for a release day blog post for the Ubuntu Maverick release. This will not be Linaro specific and will contain some 'future-gazing'.


  • Lots of bug triage and blueprint tracking.
  • Blog post for ARM on the Maverick release.
  • Review Ian Smiths work item tracker patch.

John Rigby

Unscheduled Stuff

  • All day Tuesday chasing U-Boot/X-Loader mismatch
  • All day Friday chasing (and finding) a bad bug in u-boot-next. Want to add arm devtree stuff to -next but it would not boot for me. Found the problem which is toolchain related. Sent comment to u-boot list and later linaro toolchain list.

Kernel Packaging

  • Released a new kernel with tools on and broke the build.


  • Released new u-boot package with the help of my ever so patient boss.
  • Asked Grant Likely for help with fdt testing. He said he would send pointers to how to hack a beagle kernel.

Next Week

  • Will try (again) to get u-boot devtree stuff tested with hacked beagle kernel from Grant Likely.

Dave Martin


  • Posted some metrics from building with -Os. It looks like alarger-scale investigation into the performance impact of -Os may be worthwhile, especially on the whole system.
  • See

  • Michael Hope is also adding more automated metrics to help monitor toolchain performance.


No progress this week.


Essentially done for maverick. Outstanding items are being worked on and will merge in maverick+1:

  • npitre finished up SECCOMP support;
  • npitre may progress /dev/mem protection. (To be discussed with kees.)


* Started discussing the i.MX51 BSP investigation output with Jason Hui.


  • Resurrect the bootchart memory charting conversation.
  • Start exracting memory usage profile info from linaro beta filesystem.

Meeting Log

Meeting opened by slangasek at 15:03

  • <slangasek> [TOPIC] Review action items from last meeting

Review action items from last meeting

  • wookey poked ppearse

    <slangasek> wookey: thanks :)

    <slangasek> * slangasek to post DebConf 10 gobby notes publically

    <slangasek> * slangasek to nudge Keybuk to review bootchart changes rather than redirecting to upstream, since Ubuntu and upstream are quite out of sync

    <slangasek> * wookey to close out bug #623478 in LP

    <ubot2> Launchpad bug 623478 in xdeb (Ubuntu) "PKG_CONFIG_LIBDIR needs to be set by xdeb (affects: 1) (heat: 8)" [High,Fix released]

    <slangasek> * slangasek to talk with zumbi about proposed emdebian/linaro worksession

    <slangasek> DebConf 10 gobby notes> I still have to reconcile my notes with the wiki page, but thanks to wookey we do have something up now

    <wookey> I uploaded dobconf notes to

    <wookey> I think steve may have a little more to add

    <wookey> I closed bug

    <slangasek> I still haven't talked to Keybuk... but now that ureadahead is fixed, maybe I can without messing up his priorities too much :)

    <slangasek> wookey: during the meeting, as I recall - thanks :)

    <dmart> slangasek: ok

    <wookey> Did you check to see if we have more recent text or if that is it? Should i just ask aurel?

    <slangasek> worksession> I spoke with zumbi; he's going to get me a concrete proposal of what folks would be working on at this worksession, so that we can see if it makes sense for us to send people to

    <slangasek> wookey: I do have more recent text

    <wookey> yes - I poked him last thur too

    <wookey> I think it really wants to be an 'arm' session, rather than emdebian.crossbuilding

    <wookey> as there is plenty to talk about/work on

    <slangasek> sure; I just want some specifics of what's going to be worked on before I go asking for money from management :-)

    <wookey> essentialy a much longer version of the debconf BOF

    <slangasek> [TOPIC] Blueprint status

Blueprint status

  • <slangasek> $ echo $(shuf -e hrw npitre jcrigby dmart wookey slangasek ppearse JamieBennett)

    <slangasek> wookey hrw ppearse npitre dmart slangasek jcrigby JamieBennett

    <wookey> erk

    <wookey> Built all of alip with pdebuild-cross and xdeb:

    <slangasek> wookey: stand and report :-)


    <wookey> Now merged with ppearses list:


    <slangasek> "built" or "tried to build"?

    <wookey> tried

    <slangasek> ack

    <wookey> out of 82 packages 39 build with pdebuild-cross, 26 with xdeb

    <wookey> Currently classifying failure types - there are patterns which may be

    <wookey> helpful

    <wookey> Filed bug to upload new pdebuild-cross: 645147

    <wookey> (that's the version 've been using)

    <wookey> Need to upload multistrap config now that toolchain available in maverick proper - hrw - is that all working now?

    <wookey> or is PPA still best?

    <hrw> wookey: cross toolchain in maverick works and is installable

    <wookey> Fixed using cross-arch dependencies in xdeb,

    <wookey> except getting different

    <wookey> behaviour on build machine (fails to build valid URL for wgetting). Debugging.

    <wookey> hope to have an upload imminently

    <lool> wookey: Is there some kind of public script you use to exercize xdeb and pdebuild-cross?

    <slangasek> wookey: not that it matters much in this case since the bug was opened 3 hours before the meeting, but you didn't subscribe anyone to that bug to get it uploaded for you, which I assume is the intended next step?

    <wookey> and I'd like to set up an autobulding for crossbuilding

    <wookey> slangasek: yes - I wasn't sure if I should assign it to you?

    <wookey> is that best procedure?

    <slangasek> wookey: the convention is subscribe rather than assign

    <hrw> wookey: you do tests on i386 or amd64?

    <slangasek> but if you assign it to me, I won't yell :)

    <wookey> right. assign felt a bit 'much'

    <wookey> hrw: amd64

    <wookey> I have no i386 machines :-)

    <hrw> wookey: I will give you binutils-arm-linux-gnueabi package to test after meeting

    <wookey> So, do we have a machine I can set up a buiolic autobuilder on?

    <hrw> wookey: I have 3 i386 machines (use none of them)

    <wookey> public

    <slangasek> wookey: the xdeb fix is also in a bug report, or just committed to the repo

    <slangasek> ?

    <wookey> currently not committed as it didn;t work when packaged and moved over to build box

    <slangasek> ok

    <wookey> And now I've filled my brnach with printfs

    <slangasek> so "hope to have an upload imminently" - the action is still on your side, you're not blocked on sponsorship

    <wookey> nope, not yet

    <slangasek> ok, please poke us on IRC when it's ready :)

    <wookey> I'll hassle you when I am :-)

    <slangasek> anything else?

    <wookey> Only the quesry about where to install autobuilder stuff

    <slangasek> install it?

    <wookey> I could use one of my machines, or emdebian (but that's quite busy)

    <lool> host?

    <wookey> yes host. I notice you have ahudson instance lool - that might do?

    <wookey> not sure how easy to make it do cross-stuff. I was initially thnking buildbot

    <lool> Hudson isn't really good at building a random collection

    <lool> it could work, just a bit weird

    <slangasek> why would you use anything other than sbuild for an autobuilder?

    <wookey> yeah - shall I just experiment locally and we'll work out where to put later?

    <wookey> because I want shiny web output

    <lool> and my specific instance will not scale to all the things we'd like to do; but it could certainly extend over EC2 or something

    <slangasek> wookey: you also presumably want successful package builds

    <slangasek> so I would use sbuild :)

    <lool> I suspect a sbuild run in an ec2 vm would be fine

    <wookey> OK.

    <wookey> I'll look.

    <wookey> that's all

    <slangasek> thanks

    <slangasek> hrw:

    <hrw> ok, my turn

    <hrw> cross compilers in universe are installable and works. Big kudos to Steve for sponsoring packages and also to Matthias for helping me with cleaning deps

    <wookey> wahey!

    <hrw> bug 615765 got some testing and looks like strip.single is doing proper work when it corrupts files

    <ubot2> Launchpad bug 615765 in binutils (Ubuntu Maverick) (and 2 other projects) "Host strip corrupts cross-built armel archives (affects: 1) (heat: 90)" [Medium,New]

    <hrw> checked around bug 598389 - I have one change to binutils which may help here

    <ubot2> Launchpad bug 598389 in ncurses (Ubuntu) (and 5 other projects) "Cross build needs rpath with xdeb (affects: 1) (heat: 48)" [Undecided,Fix released]

    <hrw> will give amd64 package for tests - I built dbus and ncurses fine with it

    <hrw> I gave up on using beagleboard C3 for any armel work. too unstable and too many wires for usable config

    <wookey> hrw: we should compare notes dbus failed for me (linking foreign libs)

    <slangasek> hrw: 615765> so we can't have strip.single check the ELF architecture field and bail out if it doesn't match?

  • <hrw>

    <hrw> slangasek: for strip.single it matched. [elf32-little] is what it see

    <hrw> slangasek: elf can be also non arch it looks

    <slangasek> oh, the machine field is blank on the object! ok

    <hrw> wookey: install this package and do test - more things will build or not

    <wookey> OK.

    <slangasek> hrw: what's the next step wih that bug, then?

    <hrw> wookey: I built dbus with "xdeb --only-explicit dbus"

    <hrw> slangasek: I think that resolution: ISNOTABUG apply + suggestion to isntall binutils-multiarch

    <wookey> we need to decide if we intend to make thins work with/without binutils multiarch

    <slangasek> hrw: ok; I'm not altogether happy with having to use binutils-multiarch, maybe we should instead fix things to know to call the correct strip

    <wookey> that would be best, but may be quite a big job

    <slangasek> ppearse_late_aga: when you ran into bug #615765, was that as a result of dh_strip, or something deep in an upstream build rule?

    <ubot2> Launchpad bug 615765 in binutils (Ubuntu Maverick) (and 2 other projects) "Host strip corrupts cross-built armel archives (affects: 1) (heat: 90)" [Medium,New]

    <hrw> slangasek: to know which strip to call you need to have strip for other architectures installed (configure will find out usually) or have multiarch one

    <slangasek> hrw: you're cross-building, isn't strip part of binutils-cross?

    <hrw> it is

    <slangasek> right, so that shouldn't be a problem in practice

    <hrw> 17:28 hrw@home:~$ arm-linux-gnueabi-strip --version

    <hrw> GNU strip (GNU Binutils for Ubuntu)

    <slangasek> randomly running strip against foreign objects is not a prevailing use case :-)

    <ppearse_late_aga> slangasek:dh_strip

    <hrw> so ISNOTABUG or want me to make more research on that beast called objcopy.c + libbfd?

    <slangasek> hrw: can you re-target the bug against the debhelper package instead of binutils, and explain why?

    <hrw> slangasek: I think that next time bintuils-cross will get dependency on binutils-multiarch - saves time for developers

    <hrw> slangasek: ok, make it an action

    <slangasek> [ACTION] hrw to target bug #615765 to debhelper instead of binutils, with explanation

hrw to target bug #615765 to debhelper instead of binutils, with explanation

  • <ubot2> Launchpad bug 615765 in binutils (Ubuntu Maverick) (and 2 other projects) "Host strip corrupts cross-built armel archives (affects: 1) (heat: 90)" [Medium,New]

    <lool> dh_strip should already run cross-strip before host-strip

    <hrw> I also played with xdeb and have to admit that it is hard to use tool

    <wookey> yes - I thought we already fixed that?

    <lool> I'd like the toolchain wg folks to comment on the corruption; it does sound like something we should fix

    <hrw> wookey: "xdeb sqlite3" fails with sth like "conflicted build deps: tcl8.4 tcl8.4-dev"

    <slangasek> lool: will you take the action to solicit their input?

    <lool> Ok

    <slangasek> lool: seeing that the object has an empty machine type, I don't know how binutils should know not to strip it; but maybe they have better ideas

    <hrw> wookey: do you have a wiki page where you collect build errors? I can add some xdeb failures + successes there

    <slangasek> [ACTION] lool to solicit toolchain WG input on bug #615765

lool to solicit toolchain WG input on bug #615765

  • <ubot2> Launchpad bug 615765 in binutils (Ubuntu Maverick) (and 2 other projects) "Host strip corrupts cross-built armel archives (affects: 1) (heat: 90)" [Medium,New]

    <wookey> hrw: yes see top of meeting - google spreasheet link

    <hrw> wookey: ok

    <hrw> I am waiting for personal Pandaboard - will work more on ftfbs then.

  • hrw ended

    <slangasek> have TI given you an ETA for your panda?

    <hrw> slangasek: ~half of october

    <slangasek> ok

    <slangasek> ppearse_late_aga: your turn

    <hrw> finally working platform for my TV mediaplayer project;d

    <slangasek> lool, wookey: FWIW, I notice that bug #615765 was filed by ppearse_late_aga the very same day that debhelper was merged from Debian; maybe a fix got dropped

    <ppearse_late_aga> Mainly setting up a |PPA for gcc source of different flavours for cross compile toolchain packages to use

    <ubot2> Launchpad bug 615765 in binutils (Ubuntu Maverick) (and 2 other projects) "Host strip corrupts cross-built armel archives (affects: 1) (heat: 90)" [Medium,New]

    <ppearse_late_aga> Also tested the VersatileExpress display fix.

    <ppearse_late_aga> Back to individual packages tomorrow....

    <slangasek> lool, wookey: n/m, just looked at the dh_strip code and it's trivially correct; bah

    <ppearse_late_aga> Thats'all from me

    <dmart> dmart: me?

    <slangasek> ppearse_late_aga: you have hrw's latest toolchain packages, and they're working ok (or at least building ok) for your PPA?

    <hrw> ppearse_late_aga: slangasek means a-c-t-base 1.50 + gcc-4.5-armel-cross 1.38

    <ppearse_late_aga> slangasek: They build OK - problems are in getting them uploaded. I believe partly due to bad versioning by me

    <dmart> I guess it's my turn now...

    <dmart> I got some metrics from building with -Os for a few packages:


    <hrw> ppearse_late_aga: can we discuss versioning problem later? I have hints probably

    <ppearse_late_aga> hrw: OK

    <dmart> There could be some interesting follow-up on this--- -Os makes surprisingly little performance difference from the default in some cases

    <dmart> oprofile/perf - no special progress

    <dmart> jcrigby: did you manage to get linux-tools packages building from the linaro kernel?

    <slangasek> [ACTION] hrw,ppearse to discuss possible versioning problem blocking PPA uploads

hrw,ppearse to discuss possible versioning problem blocking PPA uploads

  • <hrw> thx

    <jcrigby> dmart, yes but I noticed only one file in the resulting deb

  • hrw just crosscompiled linux-linaro with my packages

    <dmart> do we know what the problem is?

    <slangasek> jcrigby: /usr/bin/perf_2.6.35-1006 - is there anything else needed in the package?

    <jcrigby> slangasek, I don't know

    <jcrigby> slangasek, I just thought tools meant more than one:)

    <dmart> possibly

    <dmart> It looks like linux-tools-common contains all the manpages etc.

    <dmart> and the "default" perf binary

    <dmart> So probably the kernel-specific perf binary is the only thing which should get build for the kernel-specific linux-tools packages

  • dmart just guessing here

    <dmart> jcrigby: is that package in the archive? I could try it out.

    <slangasek> and linux-linaro-tools depends on the same linux-tools-common, no versioned dep... so I guess this works the same as (and as well, or not well, as) the existing linux-tools packages

    <slangasek> dmart: arrived in the archive this morning

    <jcrigby> dmart, yes it is in

    <dmart> ok, I'll give that a try at some point.

    <dmart> Other that that, there's been some ongoing work in the kernel wg relating to the imx BSP

    <slangasek> [ACTION] dmart to test that linux-linaro-tools package in maverick DTRT

dmart to test that linux-linaro-tools package in maverick DTRT

  • <dmart> And a bit of work related to armel ubuntu bugs

    <dmart> Currently, I'm working on resuming the arm-m-memory-footprint activities - but I don't have much to report yet.

    <dmart> slangasek: "DTRT"?

    <slangasek> dmart: "does the right thing"

    <dmart> ah :)

    <dmart> ...

    <dmart> anyway, that's all from me

    <slangasek> doesn't Thumb-2 implement that instruction? ;) (along with "DWIM")

    <dmart> hmmm

    <slangasek> dmart: thanks

    <hrw> and LITS?

    <slangasek> npitre: you're up

    <dmart> SWINE is a good instruction

    <slangasek> hrw: I don't know that one :)

    <hrw> Leave It To Steve^WSomeone

    <slangasek> heh

    <npitre> I created a new patch for bug #620611 and posted it upstream for comments

    <ubot2> Launchpad bug 620611 in linux-linaro (and 1 other project) "Unable to backtrace out of vector page 0xffff0000 (affects: 1) (heat: 6)" [Medium,Fix released]

    <npitre> I created a patch to implement SECCOMP on ARM, and posted it upstream for comments

    <slangasek> yay :)

    <dmart> npitre: did you get any feedback on what needs to be done for /dev/mem? I don't have the answers to that...

    <npitre> merged all the above into the linaro stable 2.6.35 kernel

    <slangasek> if the kernel is patched for bug #620611, should the 'Linaro GDB' task be marked invalid, or is there a userspace bit that needs to be done yet?

    <ubot2> Launchpad bug 620611 in linux-linaro (and 1 other project) "Unable to backtrace out of vector page 0xffff0000 (affects: 1) (heat: 6)" [Medium,Fix released]

    <npitre> started working on /dev/mem security, asked for more info and got no feedback so far (expected from Kees mainly)

    <dmart> ok

    <npitre> I also should start thinking about pushing as much as I can upstream before the next kernel merge window opens

    <npitre> I also want to resume my work on DT issues (follow up to some discussions I initiated myself)

    <slangasek> upstream> yes, please! :)

    <npitre> that's about it for me

    <slangasek> thanks

    <slangasek> npitre: I'll see kees today, and will ping him about /dev/mem if I get the chance

    <slangasek> but please also follow up on your side as appropriate

    <npitre> slangasek: I asked him last night so I'll give him a bit of slack ;)

    <slangasek> ok :)

    <slangasek> jcrigby:

    <jcrigby> ah

    <npitre> slangasek: but you can ask him anyway ;)

    <slangasek> well, I guess I'm first, but my status is unchanged - multiarch isn't landing in maverick during final freeze :P

    <jcrigby> ok, pushed new u-boot

    <jcrigby> went well after a bug in ar was fixed

    <jcrigby> thanks to slangasek

    <jcrigby> looks like there are some omap4 pinmux issues

    <slangasek> so I hear - working with sakoman on that?

    <jcrigby> yes, the patch is in his tree

    <slangasek> do you think you'll have that ready for upload today?

    <jcrigby> I'll slangasek remind me after meeting the sru stuff needed

    <jcrigby> yes, easy

    <slangasek> and is there an open bug report for the issue?

    <jcrigby> I'll make sure there is

    <jcrigby> I think ogra asked rsalveti to enter one

    <slangasek> shouldn't need any SRU stuff; SRU is after the Ubuntu release, and this is a strict bugfix upload so all we need is to upload and get the release team to review it

    <jcrigby> oh, ok

    <rsalveti> sure, just an exception

    <jcrigby> did some experimenting with u-boot-next which has arm relocation stuff in ti

    <rsalveti> sru is now needed just for kernel

    <slangasek> everything ok on the kernel side, now that we got it built?

    <jcrigby> rsalveti, thanks

    <slangasek> bug #645167 is the one, btw

    <ubot2> Launchpad bug 645167 in u-boot-linaro (Ubuntu Maverick) (and 2 other projects) "omap4: u-boot overrides pin-muxing settings from x-loader (affects: 1) (heat: 10)" [High,New]

    <jcrigby> I think the kernel has an issue with dss on igep

    <slangasek> jcrigby: I'd advise you to subscribe to bug mail for the u-boot-linaro package:

    <jcrigby> I saw an sru request on that for ubuntu

    <jcrigby> slangasek, good idea

    <jcrigby> so once ubuntu has the fix in can we piggy back on the same sru?

    <hrw> jcrigby: there was a fix for igep display

    <slangasek> ah, so that's an additional dss fix on igep that isn't what we already got in just past the wire?

    <slangasek> jcrigby: yes - please open a task on that SRU bug for the linux-linaro package, so that the SRU team can explicitly acknowledge it

    <jcrigby> slangasek, ok

    <slangasek> (and then close the bug in the linux-linaro changelog when uploading)

    <jcrigby> right

    <slangasek> anything else?

    <jcrigby> found a problem in u-boot-next that was toolchain related

    <jcrigby> dmart was very helpful in answering questions for WD

    <slangasek> WD?

    <jcrigby> wolfgang denk

    <jcrigby> god of u-boot

    <dmart> and no flame war (yet)

    <slangasek> ok, great :)

    <slangasek> JamieBennett: you have the last word :)

    <JamieBennett> heh. OK, me. Working on lots of Image building tracking and building, UDS planning, documentation, tracking stuff with the Ubuntu Release Manager, but I now have my coding hat on for a few tasks so I'm happy :) On my plate is making editmoin work with attachments, work with kate on some bug metrics, some bug stat scripts of our own, and some work item tracker patches.

    <JamieBennett> busy, busy ;)

    <slangasek> :)

    <slangasek> [TOPIC] AOB


  • <slangasek> what's hot this week in Linaro? :)

    <hrw> questions from external projects users about Linaro

    <hrw> 10:02 < ericben> if one day you can ask linaro's marketing to write a what is linaro for dummies, this would be great as I still don't understand the goals of this project

    <wookey> 'making stuff work'

    <wookey> (faster)

    <slangasek> [ACTION] "marketing" to write a 'what is linaro for dummies'

"marketing" to write a 'what is linaro for dummies

  • <ppearse_late_aga> for arm

    <hrw> and taking over the world

    <JamieBennett> hrw:

    <slangasek> :)

    <npitre> I admit having peoblems explaining Linaro to half-clued people too

    <npitre> JamieBennett: sure, but that's a bit abstract

    <hrw> JamieBennett: I got asked by company (Bug Labs) which produce omap3 hardware and they want to use our uboot/kernel/toolchain/devtools for next release

    <hrw> JamieBennett: and about page does not mention uboot/kernel etc

    <slangasek> ok, I don't think we're solving the Linaro branding question in the Foundations meeting... take this back to #linaro for further discussion? :)

    <hrw> yep

    <wookey> :-)

    <slangasek> #endmeeting

Meeting closed at 16:10

Platform/DevPlatform/Meetings/2010-09-22 (last modified 2011-03-11 11:32:44)