Wednesday 10 Nov 2010

People Present

  • slangasek
  • JamieBennett

  • dmart
  • hrw
  • jcrigby
  • ppearse
  • wookey
  • npitre
  • aviksil


  • Review action items from last meeting
  • Happy release day!
  • Blueprint status
  • Spec drafting

Action Items from this Meeting

  • jcrigby to register a linaro blueprint for this cycle's ux500 uboot mainlining work
  • aviksil to put amitarora in touch with hrw on powerdebug packaging

Action Items from Previous Meeting

  • slangasek, JamieBennett to discuss concerns raised at ELC about the new armhf port

Status Reports

Peter Pearse


  • arm-m-ael-alip-evaluation
    • Built more packages
      • 70 of 82 packages in the original alip-ael can be built now
  • other-linaro-n-eclipse-cdt
    • Installed eclipse & eclipse-cdt on amd64

    • tried installing eclipse on efika SmartBook, fails due to versioning

    • tried building eclipse on efika SmartBook - ran out of memory.

  • general
    • - Various UDS debriefing meetings with ARM Ltd. personnel


  • armel eclipse does not install - version differs from that in AMD64/i686, won't build on efika SmartBook


Meeting Log

Meeting opened by slangasek at 16:03

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

Review action items from last meeting

  • <slangasek> *

    <slangasek> * slangasek, JamieBennett to discuss concerns raised at ELC about the new armhf port

    <slangasek> carry over; been busy with releasing :)

    <slangasek> [TOPIC] Happy release day!

Happy release day!

  • <JamieBennett> \0/

    <wookey_> taa-daa

    <slangasek> speaking of releasing, thanks to everyone for their help getting the final images / hwpacks in place and validated for release

    <hrw> yez,yez,yez (etc, etc)

    <JamieBennett> slangasek: and thanks to you too !

    <hrw> btw - who uses handset-plasma image?

    <slangasek> if you haven't tried the final release out yet, I encourage you to do so ;) under qemu, if nothing else

    <slangasek> it's too late for any feedback that will affect the 10.11 images, but we're already planning how to make 11.05 better!

  • <JamieBennett>

    <slangasek> hrw: define "uses"? :) That image comes from User Platforms work - asac and alf_ worked on it mostly, I think

    <hrw> JamieBennett: for 11.05 please prepare dirs with alpha1, alpha2 etc where you will put images to test

    <hrw> easier then triple checking which exactly versions are needed

    <JamieBennett> hrw: OK

    <JamieBennett> hrw: the directories were there for 10.11 too

    <slangasek> hrw: probably better is to fix the qa tracker to be able to link directly to the images

    <JamieBennett> on releases

    <slangasek> which the tracker has general support for, but doesn't work for linaro images currently

    <hrw> would be nice to have to use ubuntu sso - one registering less

    <hrw> and bigger field for comment - current one needs to be resized each time

    <slangasek> hrw: please send these comments by email - it's a bit awkward to do a post mortem on the qatracker here, especially since AIUI JamieBennett is still putting the final touches on the release announcing

    <hrw> sure, will collect set of notes

    <JamieBennett> hrw: right, I can work with ara to get these changes in

    <slangasek> [TOPIC] Blueprint status / Spec drafting

Blueprint status / Spec drafting

  • <hrw> JamieBennett: can I get code to hack somehow? may be faster even

    <JamieBennett> I'm sure its in launchpad somewhere bit it will need deploying

    <JamieBennett> talk to ara

    <hrw> thx

    <slangasek> as last week, I know there's little blueprint "status" to call out yet since we're done with 10.11 and still going through blueprint sign-off on 11.05

    <slangasek> please make sure you have the specs for your blueprints drafted by tomorrow and set to 'review', so we can get this all done this week!

    <wookey_> dumb question: the spec goes on the spec page but the liust of tasks still goes in the whiteboard, right?

    <hrw> wookey_: right

    <wookey_> OK, just checking it hadn't got any cleverer :-)

    <slangasek> wookey_: yes - the list of workitems doesn't have to be in by tomorrow, though if you can make a start at those that's great to have

    <aviksil> wookey_:

    <JamieBennett> slangasek: I will be setting the our Linaro tracker up tomorrow so if we can get work items in soon that would be great

    <wookey_> ah, OK. I was assuming both were wanted. I'll do it anyway, at least to start with

    <slangasek> JamieBennett: sure - I'm expecting early next week to have those all in

    <hrw> wookey_: is unwanted child in LP family - each time when I speak with LP devs they prefer to not touch it too much

    <slangasek> let's go around the "table", then for a quick status check; any concerns you have on blueprint drafting, interesting developments over the last week, etc

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

    <slangasek> JamieBennett slangasek wookey npitre jcrigby dmart ppearse aviksil hrw

    <slangasek> JamieBennett: so, any interesting developments this week? ;)

    <JamieBennett> sorry OTP, please come back to me

    <slangasek> ack

    <slangasek> my turn

    <slangasek> been working with JamieBennett to get everything in place to let us roll final images from maverick-updatesl, via the Ubuntu SRU process

    <slangasek> got a little late of a start on it, but it came together - I think we've proved this process works and should keep it for next cycle

    <slangasek> had to do a last-minute upload of linaro-image-tools to maverick-proposed, which may or may not be accepted for SRU... this cycle we need to make sure that lands at the appropriate time into the archive so we don't have to point all our users at a bzr branch for installing images (especially since there's a spec this cycle about rewriting linaro-media-create)

    <slangasek> EOF

    <slangasek> wookey_:

    <wookey_> nothing much here. I'm reasonablyhappy with my spec coming together

    <wookey_> I am worried about how we are going to deal with partial-multiarch deps

    <wookey_> ie some deps are multiarhc, some arent

    <wookey_> so both paths will be in use

    <wookey_> each package kjnows where it is but the one the depends on it will have to look in both places and I think that'll just be breakage

    <slangasek> do you have an example of this? Most things are expected to just use the path

    <wookey_> I can't see a clear path to make a continuous transition work...

    <wookey_> it might be OK but I think libtool will just do the wrong thing all over the place

    <slangasek> yes, we know we'll need to beat on libtool

    <wookey_> if we can fix it in libtool (and things use it) then hopefully that'll be enough

    <wookey_> basically we don;t know yet...

    <wookey_> happy to proceed on that basis :-)

    <slangasek> ack

  • JamieBennett is back

    <wookey_> I guess that's it from me

    <slangasek> multiarch dpkg is moving forward now, so I hope soon we'll get some real-world experience with these questions

    <slangasek> wookey_: thanks

    <hrw> we have multiarch apt now iirc - right?

    <wookey_> oh - when do we get some build-space?

    <slangasek> JamieBennett: you can go net then

    <slangasek> hrw: yes

    <JamieBennett> OK

    <slangasek> wookey_: build space for what?

    <wookey_> for a cross-builder

    <wookey_> to chrn through everything listing breakage

    <JamieBennett> Last week for me was plumbers, I was a little disappointed on the content of the talks but hey, some people enjoyed it

    <wookey_> I could just use my account

    <wookey_> if I fixed my login

    <JamieBennett> Obviously the release has been taking a lot of my time as well as other projects I can't talk about

    <JamieBennett> Upcoming is getting the tracker working for this cycle

    <JamieBennett> Working on secret projects

    <JamieBennett> and trying to improve our reporting methods

    <JamieBennett> via scripting and new tools

    <slangasek> wookey_: I'm not expecting us to allocate any central resources this cycle to set up a cross-building buildd - we are nowhere near having that working inside of Launchpad

    <JamieBennett> EOF

    <wookey_> slangasek: I want to make it independet of launchpad - it should work for debian and ubuntu the same

    <slangasek> JamieBennett: thanks

    <wookey_> I just need some disk sapace, web space and ability to install stuff

    <slangasek> wookey_: yes, by all means any tools we work on should be as general-purpose as possible, but the upshot is that we aren't going to be setting such a thing up centrally in the Canonical DC, which is where our IS resources lie

    <wookey_> and there is no way we can provide logins the way Debian does?

    <slangasek> disk space + web space ==; ability to install stuff !=

    <slangasek> npitre:

    <slangasek> npitre: around?

    <slangasek> we'll come back to npitre in a bit, then

    <slangasek> jcrigby:

    <jcrigby> working on kernel packaging spec and work items, no problems

    <npitre> there, sorry

    <slangasek> npitre: no problem, we'll come back to you in a minute

    <jcrigby> we had an informational session on kernel and u-boot trees and we came up with work items for it

    <jcrigby> does it also need a spec?

    <slangasek> jcrigby: not to mention a nice piece of last-minute work to get us a working imx51 hwpack for 10.11 - thanks!

    <jcrigby> slangasek, np

    <slangasek> jcrigby: if you think it's sufficiently self-explanatory and the work items are short (less than a week of work altogether), we can forego the spec

    <jcrigby> ok, good

  • hrw waits for freescale 2.6.35 codedrop and then genesi kernel upgrade for smartboot/smarttop

    <jcrigby> and just one more thing, I have no where to put my u-boot development tasks

    <jcrigby> mainlining ux500 uboot that is

    <slangasek> jcrigby: please register a blueprint under the linaro project for this, and point me at it when you have it there

    <jcrigby> slangasek, ok thats easy, didn't no mere mortals could create blueprints:)

    <slangasek> [ACTION] jcrigby to register a linaro blueprint for this cycle's ux500 uboot mainlining work

jcrigby to register a linaro blueprint for this cycle's ux500 uboot mainlining work

  • <jcrigby> thats it

    <slangasek> jcrigby: if you find that you can't, kick it back to me - but I'm pretty sure there's no acl on them

    <jcrigby> ok

    <slangasek> jcrigby: btw, where did things get to as far as trying to have a minimal mainline omap4 kernel?

    <slangasek> I saw omap4 patches being merged, but I guess we didn't spin a hwpack for this

    <jcrigby> there is a kernel in the kernel ppa and it boots to a shell prompt

    <jcrigby> linaro-maintainers/kernel ppa that is

    <jcrigby> no network

    <jcrigby> no framebuffer

    <slangasek> JamieBennett: should we create an omap4 mainline hwpack today and do a quick QA round, so we can publish this for 10.11?

    <slangasek> (if a little late)

    <JamieBennett> its a little late

    <slangasek> it is, yes

    <JamieBennett> we can try, I don't think its that important

    <slangasek> JamieBennett: can you check with kiko on this? He was very keen to have some mainline omap4 hwpack this cycle, knowing well the limitations

    <JamieBennett> sure, but we have made the release now

    <slangasek> I think if we could get something up within a week of the release, and without too much extra effort, it would still be to our advantage, honestly

    <slangasek> please discuss it with kiko, though

    <JamieBennett> slangasek: will do

    <slangasek> npitre: back to you :)

    <npitre> working on a linaro-2.6.36 kernel branch at the moment, with most of the latest ARM specific stuff from latest mainline

    <npitre> the landing teams are being created, and workflow questions are coming up

    <npitre> so I'll have to figure out with them the best way to move forward

  • slangasek nods

    <npitre> also, the Ubuntu ARM kernel should switch to the Linaro kernel, which might require some adjustments on both sides too

    <hrw> npitre: Lee Jones (lag) asked today: "What is our current route 'upstream'? inaro-next -> linux-linaro -> ..."

    <npitre> hrw: yes, that's part of my figuring out best way forward with them

    <hrw> npitre: should I point him to your or Mathieu on next such questions?

    <npitre> hrw: already in conversation with them

    <hrw> npitre: thx, will not bother you then

    <slangasek> npitre: anything else to mention?

    <npitre> I posted what I think is the Linaro stance wrt relation with the Ubuntu kernel on linaro-dev

    <npitre> got private feedback only so far

    <npitre> they are like "let's hope this view is shared across all the Linaro organization"

    <slangasek> there are a lot of different threads involved with the Ubuntu kernel that we need to keep a handle on; I'll post my own thoughts to the list :)

    <slangasek> dmart:

    <npitre> nothing else to mention

    <slangasek> npitre: ack, thanks

    <dmart> been drafting some blueprints, but still need to discuss with lool what tasks to define around BSP investigations

    <dmart> since changes to hit 2.6.38 will need to go on the ARM linux kernel list pretty soon, I've also started with Thumb-2 kernel building

    <dmart> A few patches are needed, but I can now build a Thumb-2 kernel on vexpress from 2.6.37-rc1

    <dmart> I'll be posting the patches soon, then I'll try to sync up with linaro-next/linaro-2.6.36

    <slangasek> nice! :)

    <dmart> The kernel "works" too... but I haven't built a comprehensive set of modules yet...

    <dmart> That's pretty much it for now

    <slangasek> ok, thanks

    <slangasek> ppearse:

    <ppearse> More crossing....

    <ppearse> Have pmake producing different binaries to standalone building at present.

    <slangasek> pmake? how does that wind up in your dependency tree?

    <ppearse> Made a flavoured cross chain for wookey but the PPA builder wont upload the binaries I get messages of form Unable to find source package armel-cross-toolchain-base/1.50 in maverick

    <slangasek> hum, probably libedit; weird

    <ppearse> Just joining the launchpad list to ask why....

    <slangasek> wouldn't think libedit would fail to build with GNU make :P

    <slangasek> ppearse: which ppa?

    <ppearse> slangasek: No libedit uses pmake and somwhere inside the pmake call the binaries go wrong - all the save temps identical.;-(

    <slangasek> well, that's no fun

    <ppearse> Remember - some of us have different definitions of fun....

    <slangasek> heh

    <hrw> ;DD

    <slangasek> ppearse: if you can point me at the ppa with the error, I may be able to use my LP dowsing rod to give you a quick answer, rather than waiting for the mailing list

    <hrw> 2 weeks long builds for 20 devices across 5 archs, 12 subarchs... was fun and took 160GB of storage

    <slangasek> ppearse: anything else?

    <ppearse> or similar

    <slangasek> ok

    <ppearse> nope - that's enough

    <slangasek> aviksil:

    <aviksil> Investigated boot-time performance improvement on ARM for writing the spec. Studied kernel's async framework.

    <aviksil> and tried merging LTTng tree into linaro-next locally. Got 71 merge conflicts.

    <aviksil> btw, today Amit Arora of PM WG asked me how to put his powerdebug package into Natty and Linaro. I could not answer him satisfactorily

    <hrw> aviksil: let he contact me. I will make a package

    <aviksil> hrw: OK

    <slangasek> [ACTION] aviksil to put amitarora in touch with hrw on powerdebug packaging

aviksil to put amitarora in touch with hrw on powerdebug packaging

  • <aviksil> thats all from my side

    <hrw> so my time

    <slangasek> aviksil: what's the plan of attack for the LTTng merge conflicts?

    <aviksil> I'm walking through the conflicts

    <aviksil> so far not sure about plan though

    <slangasek> at this point I suppose they're all issues that need to be fixed on the lttng side, since linaro-next is close to mainline

    <aviksil> ok

    <slangasek> aviksil: I recommend talking to upstream, as he may already be dealing with some of these conflicts

    <slangasek> aviksil: Mathieu Desnoyers <>

    <aviksil> slangasek: ok, i'll

    <slangasek> thanks

    <slangasek> hrw: yes, your time :)

    <hrw> wrote spec for other-n-cross-compilers, defined workitems. will split bare-metal part into separate blueprint as this is considered lowest priority by toolchain wg. wrote spec for 'linaro gcc in natty' blueprint. started work on workitems (first want to make ppa for maverick/lucid)

    <hrw> other work: efika mx smart[book|top] support for flash-kernel (based on Genesi work), smartbook kernel update (will provide packages in unsigned repo or by armel ppa)

    <hrw> looked at kde4/armel status in natty - waits for doko to decide on -Wa,-mimplicit-it=thumb option to be like in gcc-4.4 or not. rebuilt whole kde4 on panda but it segfaults terribly on efika

    <slangasek> hrw: can you do the split of the bare-metal compiler blueprint this week?

    <hrw> slangasek: in theory I ended work 8 minutes ago for this week.

    <hrw> slangasek: but I can

    <slangasek> hrw: ah - you mentioned un-taking off Friday, did that not succeed?

    <hrw> slangasek: no, decided to keep it. we have some family stuff ongoing

    <slangasek> ok

    <slangasek> anything else?

    <hrw> so thats all fro me

    <slangasek> [TOPIC] AOB

AOB - how-to-set-up-your-beagle-board video

  • dmart was made to do it ;P

    <dmart> heh

    <slangasek> :)

    <ppearse> It has a great backing track

  • slangasek pops some popcorn and settles in to watch the video

    <hrw> dmart: I think that you made Ira happy with it

    <slangasek> #endmeeting

Meeting closed at 17:10

Platform/DevPlatform/Meetings/2010-11-10 (last modified 2011-03-11 11:33:51)