Wednesday 3 Nov 2010
- Review action items from last meeting
- Linaro@UDS show-and-tell
- Reminder of 10.11 release candidate testing
- Spec drafting
Action Items from this Meeting
slangasek, JamieBennett to discuss concerns raised at ELC about the new armhf port
Action Items from Previous Meeting
- npitre to produce status from git about volume of Linaro kernel patch upstreaming
- slangasek to nudge Keybuk to review bootchart changes rather than redirecting to upstream, since Ubuntu and upstream are quite out of sync (DONE)
- everyone to look at the UDS schedule and subscribe to other sessions they're interested in attending (DONE)
Meeting opened by slangasek at 15:07
<slangasek> [LINK] https://wiki.linaro.org/Platform/Foundations/2010-11-03
<wookey_> slangasek: arm people pumpkin at 4:30 (i.e 1hr 20) for local UDS review meeting
<wookey_> hopefully we'll be done by then
<slangasek> yes, I'll try to make this a quick meeting
<slangasek> I've mixed up the agenda for a change; "blueprint status" is still on there, but in fact the blueprint status for 10.11 is what it is at this point - so if you have anything to bring up about your existing blueprints, feel free to, but I'm mostly focused on the output from last week
<slangasek> [TOPIC] Review action items from last meeting
Review action items from last meeting
<slangasek> * npitre to produce status from git about volume of Linaro kernel patch upstreaming
<slangasek> * slangasek to nudge Keybuk to review bootchart changes rather than redirecting to upstream, since Ubuntu and upstream are quite out of sync (DONE)
<slangasek> * everyone to look at the UDS schedule and subscribe to other sessions they're interested in attending (DONE)
<slangasek> npitre: do you know when you might have a chance to pull some statistics from git? (I'll get our meeting minutes out in a timely manner this week, so you have a reminder...)
<npitre> I did for anmar a while ago
<npitre> from memory this was something like 13 patches
<slangasek> oh, ok
<slangasek> could you bounce me a copy of that?
<npitre> I should check again with latest kernel, but nothing record breaking in any case
<npitre> sure, well I'll just redo the stat
<slangasek> ok, thanks
<slangasek> [TOPIC] Blueprint status; Linaro@UDS show-and-tell
Blueprint status; Linaro@UDS show-and-tell
<slangasek> so as I said above, rather than talking about the status of all current blueprints, I'd like everyone to talk a bit about last week - something they've learned, or some exciting thing they know we'll be working on this cycle that they want the team to know about
<slangasek> last week was busy for all of us, so I want to make sure we reconnect now and have a chance to share
<slangasek> $ echo $(shuf -e hrw npitre jcrigby dmart wookey slangasek ppearse JamieBennett aviksil)
<slangasek> JamieBennett slangasek wookey ppearse hrw jcrigby dmart npitre aviksil
<slangasek> JamieBennett: if you're still around and not sucked back into Plumbers doings
<JamieBennett> sorry, guys, not much to report, preparing for the release on the 10th in my main objective
<JamieBennett> Please test the images to death
<slangasek> I'll go next
<slangasek> so one of the exciting things we discussed last week was bringing up a new hardfloat ARM port
<wookey_> which is actually going back to the original 'arm' way of doing things in the old ABI -
<wookey_> just this time round there actually _is_ some FP hardware
<hrw> wookey_: when men were men and used NWFPE?
<slangasek> that will give measurable performance / responsiveness benefits over the current port - but won't work on all hardware, so we'll continue to see the armel port around for a while in parallel
<JamieBennett> slangasek: we need to carefully investigate the impact of switching to HF for the wider community
<hrw> slangasek: are there armv7a without fpu?
<ppearse> slangasek: I've been asked - what's your estimate of "a while"?
<ppearse> slangasek: I said two cycles.....
<slangasek> but particularly exciting is that, since we're bootstrapping a port from scratch, we will be able to make it natively multiarch-friendly from the start - i.e., an ELF loader path that we can guarantee won't conflict with (and will be coinstallable with) armel's
<slangasek> so we may be able to support soft migrations from armel to armhf in 11.11, for those who are interested in such things
<wookey_> that would be very nice...
<slangasek> ppearse: armhf will still be in the bootstrapping phase for 11.05, so armel will be around at least that long - whether it stays longer mostly depends on how much demand there is for it elsewhere
<ppearse> slangasek: Good practice for the next ARM architecture
<JamieBennett> slangasek: there was some concern at ELC about the switch
<wookey_> JamieBennett: from whom?
<slangasek> i.e., Canonical is more likely to continue carrying it in the archive and working on it for a couple of cycles if they have contractual demands for it
<wookey_> (I agree it's a big deal)
<JamieBennett> wookey_: Not sure who but Philippe has the details
<slangasek> JamieBennett: sounds like something we should discuss after the meeting?
<wookey_> I'd expect binary providers to have most issues
<JamieBennett> slangasek: right
<slangasek> [ACTION] slangasek, JamieBennett to discuss concerns raised at ELC about the new armhf port
slangasek, JamieBennett to discuss concerns raised at ELC about the new armhf port
<slangasek> wookey_: your turn
<wookey_> O, well you done armhf - except to say Debian sprint on subject is being organised, which should help cooridnate things
<wookey_> I Attemped remote attendenace of UDS -
<wookey_> not terribly satisfying experience due to networking outages (and a
<wookey_> flat batt), and people not necessarily reading IRC
<wookey_> But still got some useful input of cross-=building use cases and development direction
<slangasek> hrw: armv7a w/o fpu> maybe not... maybe everything Ubuntu currently supports will want to switch, I haven't looked closely yet
<wookey_> mostly I was at CELF (ELC-E)
<wookey_> Yocto is new Linux foundation build system. (appears to be OBS+bitbake). Will review to see if it is relevant.
<wookey_> lots of good stuff. met people making openJVM crossbuild properly and AC100 hackers,
<wookey_> won a pandaboard (coming 'soon') and intel black sand board
<hrw> wookey_: Yocto is more then just build system
<wookey_> flash filesystem benchmarks from Michael opdenaker very interesting - showed YAFFS to usually be fastest (unlike 2 years ago)
<wookey_> slangasek: I'm not totally clear on what users had to say about cross-uilding that we all agree was relevant
<hrw> personally I like Yocto - more visibility for Poky and OpenEmbedded + OE has more pushes to update/reorganize some things
<slangasek> wookey_: right - we can work together this week to distill that down and set our focus for this cycle
<wookey_> I mailed you and loic about it, which I guess is your opportunity to add input
<wookey_> I suspect multiarch stuff may be even more signifcant if we want to use it soon for armhf
<wookey_> might need to start there
<wookey_> Currently in middle of upgrading to maverick
<wookey_> and I think that's all for now
<slangasek> ok, thanks
<ppearse> OK - leaving aside tech stuff I was excited to (finally) realize what linaro is for.
<ppearse> Apologies to dmart who has heard all this before
<ppearse> If one is a large manufacturer (possibly named after a fruit) one can produce a set of gadgets that all draw from the same software stack
<ppearse> Providing your users with a warm fuzzy all my gadgets love each other feeling
<ppearse> But if your an individual OEM making say an MP3 player you've got to find that all somewhere.
<slangasek> I guess we won't put a "Who we are" explanation that involves fruit on www.linaro.org, though
<ppearse> I see Linaro providing the tools to allow individual manufacturesrs to pull frm the Ubuntu stack, whittle it down to fit and push it on to the market
<wookey_> are cherry still going?
<ppearse> Except to say we take the I out & put the you (U ubuntu) back
<hrw> ppearse: I skip Ubuntu from this
<ppearse> Ti seemed to like that anyway
<slangasek> ppearse: nice summary
<dmart> hrw: in principle, ARMv7-A without fpu is permitted but crazy. Nobody I've talked to has ever seen this.
<slangasek> ppearse: anything interesting on the technical side from last week?
<ppearse> That's me all ranted out
<hrw> dmart: so for now we can just assume that armv7a == vfp3 mostly with neon
<ppearse> hrw: We need to keep the linaro tools general enough to work on other distros....
<dmart> hrw: we can't assume NEON is present
<hrw> ppearse: exactly
<hrw> dmart: and we do not assume that
<wookey_> indeed. I worry about that too
<dmart> ...but it's sufficiently common that it's worth enabling optimisations for it, provided we don't break others
<ppearse> slangasek: Mainly I ended up with the eclipse potato
<dmart> (I'm sure this is what you meant, but just clarifying)
<hrw> ppearse: but aren't armltd people like eclipse?
dmart 's first Linux distro was Debian potato ... but I digress
hrw started from slink
<ppearse> hrw: As?
<slangasek> ppearse: alright
<slangasek> hrw: your turn
<hrw> ppearse: joking - DS5 presentation related
<hrw> ok, me then
<hrw> interesting things from uds... hardware part: smartbook and pandaboard went home with me
<hrw> I hope to get smartbook working state (with provided kernel) in 2 weeks - under natty.
npitre brought home only t-shirts ;-(
<hrw> kubuntu guys already shown some interest in how good with it work
<hrw> npitre: pandaboard got TI -> davidm -> JamieBennett -> uds -> me -> home just because TI has bad experience with sending hw to @canonical people
<hrw> pandaboard is up and running. need to get full 1GB ram working. works as build machine now (320GB sata disk)
<slangasek> hrw: it's a general problem with TI being able to ship overseas to individual addresses, not specifically Canonical people, AIUI
<hrw> did some performance tests for davidgiluk
<npitre> hrw: 1GB with 2g:2g split, not highmem
<hrw> npitre: thx
<hrw> when will solve router problems then Yao from toolchain wg will use my board for cortex-a9 tests
<hrw> software part:
<hrw> we agreed that Linaro armel crosscompilers will be provided for lts + current + current-1 (lucid, natty, maverick now)
<hrw> arm-linux-none will be provided for uboot builds
<hrw> arm-none-none (bare metal) for people with cortex-m chips
<wookey_> hrw: any prgress on doing all that in Debian too? I think that's important
<hrw> multilib will be checked and enabled if will work - so softfp/hardfp + vfp/neon
<hrw> wookey_: this is on my list too
<hrw> I added workitems to my blueprint: https://blueprints.edge.launchpad.net/ubuntu/+spec/other-linaro-n-cross-compilers
<ppearse> hrw: I got requests for ARMv7, no thumb, 2 here
<hrw> ~20 of them this time and list will probably change
<hrw> ppearse: doable when I will rewrite flavours support
<hrw> and tarball releases of toolchain are on a list too
<hrw> but for tarballs I would rather enable sysroot feature
<slangasek> hrw: anything else?
<hrw> done I think
<jcrigby> first uds was great because I got to put more faces with irc nicks
<jcrigby> the DS5 presentation reinforced an old problem I have
<npitre> wookey: the $5k debug solution from ARM
<jcrigby> ARM development suite base on eclipse
<ppearse> wookey: Developer Studio 5
<ppearse> jcrigby: Command line too
<slangasek> wookey_: find Pawel Moll and walk down the hall to his office for a demo
<hrw> jcrigby: it can be used without eclipse
<wookey_> ah. we want openOCD+jtagtiny for 60 euro
<ppearse> slangasek: He travels the globe for next two weeks
<jcrigby> it just seems a shame that ARM and all the SOC vendors duplicating work
<slangasek> jcrigby: an old problem - you mean "debugging", or something more specific?
<npitre> wookey_: cheers!
<ppearse> Don't knock it - it took seven years to persuade ARM we needed to profile software
<jcrigby> just an old rant of mine
<hrw> slangasek: Pawel is in boston
<npitre> jcrigby: your escape route is OpenOCD
<wookey_> jcrigby: maybe linaro can improve matters there?
<slangasek> hrw: right, so it's a bit longer of a walk
<hrw> slangasek: and can get wet
<ppearse> Not if Boston Lincolnshire UK
<jcrigby> on another front I think maybe Linaro could do something like AppNotes
<jcrigby> guidelines on how to approach a problem but not a complete solution
<ppearse> Suggest wiki/blogs are better solutions
<jcrigby> yes, wiki is fine
<dmart> We need to work hard to maintain the wiki
<slangasek> the wiki is certainly a good place to start, though
<dmart> Currently it's not very friendly to non-linaro users, and very hard to find what you're looking for
<ppearse> But not so hard as to publish an AppNote
<jcrigby> but my point is we need to be able to take time to do stuff that is not necessarily general enough for ubuntu or even linaro
<dmart> ... because ... an app note has to be self-contained and coherent
<jcrigby> the boot time discussion is what makes me say this
<jcrigby> lots of good ideas were shot down because they would not work on hw xyz
<wookey_> ah yes - CELF had a 0.7s boot into QT app on a MIPS board
<wookey_> nice piece of work to show what you can do with some (signifncant) effort
<wookey_> removing all the guff and optimsing carefully
<slangasek> jcrigby: I would be happy to see such wiki documentation included as a workitem for the boot performance spec
<jcrigby> slangasek, ok
<dmart> "removing all the guff" = distro work
<dmart> still not clear to me how much of that we expect to do
<npitre> boot time optimization is all about customization, this is not generic work much
<wookey_> very hard to do in a binary distro
<wookey_> npitre: exactly
<wookey_> we have to provide tools and info
<ppearse> We need the tools to reduce footprint
<slangasek> dmart: documentation is the better approach for us
<ppearse> or the wiki page with suggestions ....
<slangasek> and improvement of general solutions that make a better point of departure for anyone doing customization
<wookey_> wiki page with suggestions =='info'
<slangasek> so I think we're all in agreement here
<slangasek> jcrigby: anything else to add?
<jcrigby> not really
<slangasek> ok, thanks
<dmart> Much stuff has already been covered
<dmart> Worth summarising the memory footprint session though ...
<dmart> There were some useful suggestions, and it sounds like a useful direction for this cycle is to improve instrumentation and automated regression tracking
<dmart> As with the previous discussion, this may be the best approach so that users of linaro have the visibility to know how to optimise for their use case
<dmart> There were some good new suggestions too - such as tracking use of X resources
<dmart> yes (at least as a starting point)
<dmart> still haven't played much with it
<dmart> One slightly trivial point about UDS -
<dmart> It could be a good idea if the session leader appoints someone to watch IRC
<dmart> I didn't do this, but there were a couple of occasions where it took a long time for anyone to notice a contribution
<slangasek> definitely agreed
<ppearse> And rooms with quiet doors
<wookey_> yes. IRC is weak feedback at best of times
<ppearse> Is there a ubuntu page for these suggestions
<npitre> the IRC screen should blank a couple times when it receives some updates
<slangasek> in fast-moving sessions it can be hard to keep track of IRC as well, but it's important to involve folks who are remote
<wookey_> remove the timeliness and it's confusing
<dmart> Generally good discussions though
<hrw> ppearse: there will be survey
<slangasek> ppearse: there will be a survey sent out asking attendees for feedback, I believe
<wookey_> Oh, and fix gobby server
<slangasek> heck, fix gobby *client* to be able to reconnect properly :/
<dmart> wookey_: did you just take that action?
<ppearse> No I didn't just volunteer to fix gobby
<dmart> anyway, I think that's it for points not already made
<npitre> someone from TI is about to send me 4 patches to enable Panda in the linaro 2.6.35 kernel
<npitre> also contemplating a stable branch based on 2.6.36
<npitre> and I should kick linaro-next again
<npitre> that's about it
<aviksil> OK... attended few LDS sessions remotely
<aviksil> Mailed Nicolas and you regarding LTTng merge.
<aviksil> Updated Specification page for LTTng integration in wiki
<aviksil> Drafted preliminary specification for "Improve boot-time performance on ARM, from power-on to user-space" based on the gobby note
<aviksil> that's it
<slangasek> aviksil: can you incorporate the point about providing wiki documentation on customizing systems for fast booting to that spec?
<aviksil> slangasek: OK, i'll
<slangasek> great, thanks
<slangasek> [TOPIC] Reminder of 10.11 release candidate testing
Reminder of 10.11 release candidate testing
<slangasek> The scheduled release of 10.11 is a mere 7 days away
<slangasek> so please do what you can to help test, and report bugs that you find
<slangasek> JamieBennett covered the process in his email here: http://lists.linaro.org/pipermail/linaro-dev/2010-November/001419.html
<slangasek> [LINK] http://lists.linaro.org/pipermail/linaro-dev/2010-November/001419.html - RC testing process
http://lists.linaro.org/pipermail/linaro-dev/2010-November/001419.html - RC testing process
<aviksil> is there any way i can contribute to it, though i dont have any board?
<wookey_> aviksil: this is the ELC boot-time talk - some good stuff in there: http://elinux.org/images/f/f7/RightApproachMinimalBootTimes.pdf
<aviksil> wookey_: thanks
<wookey_> hmm, that's not right
<slangasek> aviksil: you could test the heads under qemu if you have that set up - but it's probably not worth the effort of getting qemu running just for this
<JamieBennett> aviksil: you can look at the maverick-propose queue at http://people.canonical.com/~ubuntu-archive/pending-sru.html and help test the ones that effect Linaro
<wookey_> oh, yes it is. There are a couple of others there too: http://elinux.org/ELC_Europe_2010_Presentations
http://elinux.org/ELC_Europe_2010_Presentations has many presentations from elc-e
<hrw> http://elinux.org/ELC_Europe_2010_Presentations has many presentations from elc-e
<hrw> I used it in the uds-n mornings to have a hand on news
<aviksil> ok, i'll go through it
<slangasek> btw, testing of the RC should be coordinated through http://qatracker.linaro.org/
<wookey_> the quality is generally very high. It's the most densely-useful conf I go to
<slangasek> I'm not sure that link was included in the announcement, had to dig a bit to find it
<slangasek> [TOPIC] Spec drafting
<slangasek> finally - as you all know, now that we've gotten wider input from UDS, we need to finalize our specs so that we can turn them into work plans
<slangasek> the deadline for all specs is next Friday - so please have your specs marked as ready for review by next Thursday at the very latest
<hrw> so far I added gobby notes into spec and created set of workitems + notes + rules
<slangasek> (mark a spec for review by setting the "definition" status in the blueprint to "review")
<wookey_> should we be putting in everything relevant or trying to size it to fit 1 cycle?
<wookey_> (sizing does of course depends how many others one has...)
<slangasek> you should all know by now which specs you're responsible for drafting, and you can find the list at https://blueprints.launchpad.net/~<launchpad-id>/+specs?role=drafter
<slangasek> if you're surprised by anything you find on that list, come talk to me
<slangasek> wookey_: I recommend putting everything relevant into the spec, but explicitly noting those things that are out of scope for this cycle
<wookey_> responsible for drafting isn't the same as 'stuff you mught be working on' though?
<slangasek> wookey_: correct - in many cases they're the same, but the drafter and assignee may be different
<hrw> wookey_: you can draft but someone can do
<slangasek> (and the "assignee" won't be responsible for all work items, since we have finer-grained control over this)
<wookey_> OK. So bascially 'necessary' and 'would be nice'
<hrw> slangasek: https://blueprints.edge.launchpad.net/ubuntu/+spec/packageselection-linaro-n-toolchain-selection should not be drafted by doko rather?
<slangasek> hrw: I prefer that we draft it and the Ubuntu foundations team approves it
<slangasek> that helps ensure we're on the same page
<slangasek> any other questions on drafting?
<slangasek> [TOPIC] AOB
<slangasek> or anything else to cover today?
<ppearse> Not from me
Meeting closed at 16:20
Platform/DevPlatform/Meetings/2010-11-03 (last modified 2011-03-11 11:33:40)