Wednesday 18 Aug 2010
- Review action items from last meeting
- Feature Freeze exceptions?
- Blueprint status for linaro 10.11 beta
v5 & v6 compilers working; running their way through the stack now
toolchain patches merged into the archive last week
waiting for upstream feedback on final patch
working to fix vexpress image so it boots; imx51 being added to the prebuilt images
bootchart changes awaiting feedback from Ubuntu; getting beagleboard up for testing
setting CONFIG_COMPAT_BRK=n to see if exec ASLR already works
refining package output to work on non-OMAP targets (imx51, vexpress)
xdeb 0.6 can now resolve/build only the specified packages (using --only-explicit) but needs support for grabbing Packages files for the correct arch (n progress)
pending LSB discussion of pathnames; dpkg support uncertain
Action Items from Previous Meeting
slangasek to look into getting a MootBot for #linaro-meeting: DONE
- slangasek to upload xdeb today: DONE
- jcrigby to send out a call for testing of the u-boot-linaro ppa package: DONE
- slangasek to sponsor u-boot-linaro into maverick
- jcrigby, lool, hrw, slangasek to further discuss how to provide fast and frequent kernel builds
- slangasek to help wookey with FFe bug filing for pdebuild-cross in maverick
- slangasek, wookey to discuss multistrap
- dmart, npitre to work out verification of exec ASLR on armel
- jcrigby turn CONFIG_COMPAT_BRK=n on
- ask Ubuntu kernel team about dropping linux-fsl-imx51 from maverick
- dmart to email Keybuk about bootchart changes
- dmart to email npitre clarifying final status of oprofile kernel patch
Started to gather Linaro metrics at Metrics for easier reporting.
Produced lots of release wiki pages, all accessible from Releases.
- Much wiki tidying up.
Started gathering upstream project information to monitor patches at UpstreamTrees.
Attended LinuxCon the whole week. Much chatting with people interested in Linaro, learning about cool projects and seeing Boston.
- Got to chat to Kate, the new Ubuntu release manager and we ironed out ways of collaborating. Weekly call set up.
- Take input from the status page meeting and hack scripts to better suit our needs.
- Implement per-person burndown charts for the Linaro teams.
- Current release status summary.
- Analysis of requirements to deliverables for the 10.11 release cycle.
- Reliable build process for cross compiler binaries in place. Needs work to co-operate with xdeb
- Changed spec to attempt to reduce the package lists produced.
- Running out of space in lucid VM
Awaiting VersatileExpress board
- Start work item "Use cross-compiler binaries with xdeb"
- Test Tom Gall's "alip-ael" image on Versatile Express
- Test John Rigby's U-Boot on Versatile Express
- Produce new scripts
- linaro TSC has approved license for contribution to bootchart, pybootchartgui (GPLv3)
- Uploaded bootchart changes (waiting for maintainer to be available to discuss)
- Kicked off some builds to compare images sizes with -Os versus default optimisation.
- Extended pybootchartgui to graph overall memory usage in a simple way - needs tidying up and discussing the the package maintainers
- One critical patch for getting symbol offsets right needs more work and is not upstream yet.
See https://bugs.launchpad.net/ubuntu/+source/linux/+bug/608775 for detail on current status (waiting for feedback from upstream developer)
- Tried out some of John Rigby's U-Boot builds. For imx51, it turns out that an extra build step is needed to wrap images for loading by the on-SoC ROM.
- Get a standard-ish linaro platform in place (probably OMAP3) and extract some numbers from the bootchart measurements.
- Summarise output from the -Os measurements
- Finished a new linux-linaro kernel based on a merge of Nico's latest arm-next and latest Ubuntu. This time I did it in a day so I'll getting better at this.
- Finished a linux-linaro-meta package.
- Worked on changes to ARM device tress support based on feedback I got from U-Boot mailing list.
- Continued consulting with Steve Sakoman, Matt Waddel on their patches.
- Was introduced to ST-E U-Boot developer Michael Brandt by Alexander.
- Spent some time helping Torez with a U-Boot boot script problem
- Finish and resubmit the reworked U-Boot ARM device tree patches.
- Do new U-Boot release based on new Steve Sakoman patches and new upstream.
- played with the base OMAP4 Git branch provided by TI in the hope of merging it into the Linaro kernel, to finally decide against it due to OMAP configs not building anymore (and 333 patches is hard to review)
- created and published a linaro_merge_100811 kernel tree
- discussion with Richard Earnshaw about the scheduling of inline assembly blocks by gcc which might have performance issues as they get used to implement runtime patched code alternatives in the kernel
- investigation for the exec ASLR security feature
- the usual mailing list monitoring
Meeting opened by slangasek at 15:08
<JamieBennett> (even mootbot is here ;))
<slangasek> [LINK] https://wiki.linaro.org/Platform/Foundations/2010-08-18
<slangasek> [TOPIC] previous action items
previous action items
<slangasek> * dmart to post details of commit unbreaking debug symbol extraction to the bug in launchpad
<slangasek> * slangasek to look into getting a MootBot for #linaro-meeting
<slangasek> I think dmart's item was done last week already, just not reflected in last week's notes page?
<JamieBennett> slangasek: great and yours has been done
<slangasek> appears so
<dmart> Ummm, yeah it's in the launchpad bug
<dmart> Do you have the bug number?
<JamieBennett> I got us MootBot-UK for its extra abilities though
<slangasek> dmart: bug #608775
<slangasek> there were some other action items from last week that also didn't get recorded in the notes, let me fish quickly
<dmart> slangasek: that's the one
<slangasek> * slangasek to upload xdeb today
<slangasek> * jcrigby to send out a call for testing of the u-boot-linaro ppa package
<slangasek> * slangasek to sponsor u-boot-linaro into maverick
<slangasek> * jcrigby, lool, hrw, slangasek to further discuss how to provide fast and frequent kernel builds
<slangasek> first one's done
<slangasek> second one also done
<slangasek> 4th one... ongoing? somewhere there's an email thread that needs followed up to
<slangasek> 3rd one is outstading
<JamieBennett> slangasek: uboot-linaro has vexpress changes in it?
<JamieBennett> i.e. we can have a uboot-vexpress binary?
<slangasek> JamieBennett: according to the mail, one is being built already (called "ca9x4_ct_vxp")?
<slangasek> would it be better to use common names for the binaries?
<JamieBennett> slangasek: yes
<JamieBennett> although with vexpress there are different boards so ?
<JamieBennett> all called vexpress something
<slangasek> jcrigby: can you make that change, or are there reasons to prefer the current uboot package names?
<jcrigby> thats the name in u-boot
<ppearse> That's a correct name - Versatile Express may have other core tiles (ct)
<JamieBennett> OK, I can live with the obscure name
<jcrigby> but we can call the resulting blob in the .deb anything we want but may cause confusion
<jcrigby> nix what I just said
<ppearse> Added to that already caused by "versatile"
<JamieBennett> slangasek: where is the mail you refer to? linaro-dev?
<slangasek> JamieBennett: yep
<JamieBennett> [LINK] http://lists.linaro.org/pipermail/linaro-dev/2010-August/000398.html
<slangasek> [TOPIC] Feature Freeze exceptions?
Feature Freeze exceptions?
<JamieBennett> wookey had something here
<slangasek> I have email from wookey about some FFes - wookey, do you want to summarize?
<wookey> I've got pdebuild cross working in maverick-under maverick
<wookey> so we do now have a working cross-build tool
<wookey> I'd like to stick it in as a fall back until xdeb gets smarter
<wookey> eventually we can put xdeb inside pdebuild-cross for best of all worlds
<wookey> (system insulation/repeatable builds) and the fancy dep-chain breaking
<JamieBennett> slangasek: what is your take on allowing this change to the archive?
<slangasek> archive-wise I see very little risk; it's an entirely new package for Ubuntu
<JamieBennett> slangasek: agreed
<wookey> they are ultimately compliomentary. pdebuild-cross is currently using xapt to do the cross-downloading, which is stupid-but-effective
<wookey> I can;t see it breaking anything
<slangasek> so approving this into maverick should be trivial, we just need to file an appropriate FFe bug requesting it. I'll work with wookey on this
<JamieBennett> slangasek: great
<JamieBennett> I see an action item
<slangasek> [ACTION] slangasek to help wookey with FFe bug filing for pdebuild-cross in maverick
slangasek to help wookey with FFe bug filing for pdebuild-cross in maverick
<wookey> we do have to decide whether to update multistrap to 'latest' or patch the existing 2.1.5
<slangasek> wookey: you also wrote about multistrap; but I don't understand why multistrap is needed at all, we don't seem to have any "multi" requirements presently?
<wookey> (pdebuild-cross uses multstrap to makes it's cross-building chroots)
<wookey> the multi bit is packages from maverick and toolchains from marcin's repo
<wookey> and for anyone making actual images for arm they usually want a few packages from their local repo too
<wookey> (but I guess we are currently recommending some other tool for that?)
<slangasek> frankly, I would prefer to see us patch pdebuild-cross to use vanilla debootstrap, which is actually tested against the Ubuntu archive, and apply the toolchain packages as a dist-upgrade after editing sources.list
<wookey> we could do that, but the whole clever bit is that you don;t need to fiddle with your chroot afterwards - you just make one with the right stuff in it up front
<wookey> and we do already have multistrap in the archive, probably largely unusued at this point
<slangasek> particularly for chroots, disk space is not at a premium and I'd rather use the known reliable tool than use something that's not widely tested to save a bit of download time / initial disk space
<wookey> it not to save space - its to save users typing mysterious runes
<slangasek> wookey: let's talk about this one further after the meeting?
<wookey> but OK, we can go that way if you like.
<slangasek> [ACTION] slangasek, wookey to discuss multistrap
slangasek, wookey to discuss multistrap
<slangasek> anyone else have feature freeze exceptions in this vein that they'd like to discuss?
<slangasek> [TOPIC] Blueprint statusfor linaro 10.11 beta
Blueprint status for linaro 10.11 beta
<slangasek> team = ['dmart', 'JamieBennett', 'jcrigby', 'hrw', 'npitre', 'ppearse', 'slangasek', 'wookey']
<slangasek> import random
<slangasek> order = team[:]
<wookey> btw - marcin's repo seems to be missing g++. Do we know when that'll change? I guess not
<slangasek> >>> print ', '.join(order)
<slangasek> npitre, hrw, jcrigby, JamieBennett, dmart, wookey, slangasek, ppearse
<slangasek> wookey: really? that seems like an oversight; I hadn't checked for this previously
<slangasek> npitre: blueprint status to report?
<wookey> I only noticed when I tried to install full toolchains
<npitre> about exec ASLR
<slangasek> wookey: can you shoot him an email about this and cc: me?
<npitre> I _think_ it might just work already
<slangasek> npitre: without any patching? do we have a plan for verifying this?
<npitre> there is nothing for it in the kernel at all, so it looks like PIE executable might be stored in the heap which is already randomized
<dmart> npitre: ought to be easy to test... should PIE eexcutables get rebased to random locations? Should be easy to observe if so.
<npitre> I'm currently strugging with hardware to be able to actually verify this
<dmart> dmart: I can try to test if you like.
dmart is talking to himself again
<slangasek> [ACTION] dmart, npitre to work out verification of exec ASLR on armel
dmart, npitre to work out verification of exec ASLR on armel
<dmart> npitre: I can try to test if you like
<slangasek> npitre: anything we can help with regarding the hardware?
<npitre> well, it is just self incompetence at the moment
<npitre> dmart: if you can quickly test that I would be glad
<npitre> btw, we need CONFIG_COMPAT_BRK=n in our kernel builds for this stuff to work, but this is not the default
<dmart> npitre: which kernel version do I need?
<slangasek> jcrigby: are you turning CONFIG_COMPAT_BRK=n on?
<npitre> dmart I'll send you an email after the meeting
<slangasek> npitre: should we make that the default in the linux-linaro tree?
<jcrigby> I can if wanted
<dmart> npitre: OK, thanks
<slangasek> jcrigby: I think we want to test our bleeding-edge security features, so please do
<npitre> jcrigby: I think that would be a good idea
<jcrigby> [ACTION] jcrigby, turn CONFIG_COMPAT_BRK=n on
<slangasek> [ACTION] jcrigby turn CONFIG_COMPAT_BRK=n on
jcrigby turn CONFIG_COMPAT_BRK=n on
<slangasek> npitre: should it also be turned on by default in the linux-linaro tree?
<slangasek> jcrigby: your turn
<npitre> this option is set to y by default in Kconfig
<npitre> and this is not ARM specific
<jcrigby> ok not much to report
<slangasek> npitre: ok
<jcrigby> kernel version alignment
<jcrigby> changed flavour names in the kernel package to linaro-omap and linaro-vexpress
<jcrigby> changed naming in kernel meta package to use naming change in kernel package and to work with livehelper with no change
<jcrigby> currently vexpress flavour does not boot, mattman is working on that, it is a config issue
<jcrigby> need to add mx51
<jcrigby> that is on my todo list
<jcrigby> on u-boot
<jcrigby> continued working on dev tree based on reviews from list
<jcrigby> got feedback on u-boot package in ppa
<jcrigby> current version does not produce to right output for some targets
<jcrigby> mx51 has a special target that adds header
<jcrigby> vexpress needs the elf not the bin
<jcrigby> easy to fix
<jcrigby> just need per flavour make targets and installs
<slangasek> jcrigby: has analysis been done on the differences between freescale's uboot tree and the mainline one?
<jcrigby> currently helping bring ST-E's u8500 uboot upto current upstream
<jcrigby> not yet
<jcrigby> dmart tried to test but found I was distrubuting the raw .bin instead of the prefixed one
<jcrigby> I have an mx51 now so I can test as well
<dmart> imx51 requires a weird extra wrapping step--- I wasn't aware of it before either
<jcrigby> once I finish this ST-E thing I will do the updated u-boot package
<slangasek> speaking of turning on imx51 for the kernel, it seems there's still a linux-fsl-imx51 package in maverick inherited from lucid... I should check with the kernel team whether that should be dropped in favor of ours
<slangasek> [ACTION] ask Ubuntu kernel team about dropping linux-fsl-imx51 from maverick
ask Ubuntu kernel team about dropping linux-fsl-imx51 from maverick
<jcrigby> on blueprints I think all the remaining ones except the mx51 should be deferred to Maverick+1
<slangasek> jcrigby: that's referring to the work items for uboot?
<jcrigby> the performance ones
<slangasek> there are a number of them still outstanding that are unrelated to performance - we can talk about these later today
<slangasek> jcrigby: thanks for the update
<JamieBennett> I'll be working on, amongst other things, making sure the vexpress effort culminates in daily and then release images so expect me to me prodding people for status and asking dumb questions. lexbuilder will be set up and images will happen soon I hope.
<JamieBennett> Other than that I'm working on things outside the blueprints but involves reporting on them so again, there may be questions
<JamieBennett> if for any reason asac and I are unable to make a release milestone image, https://wiki.linaro.org/Releases/MakeARelease documents how to do it
<JamieBennett> [LINK] https://wiki.linaro.org/Releases/MakeARelease
slangasek seeds that url into his firefox awesomebar
<wookey> [how does one find out the mootbot commands?]
<JamieBennett> there are shown when you start the meeting, scroll back up
<dmart> Uploaded bootchart changes (waiting for keybuk to be available
<dmart> to discuss)
<dmart> Kicked off some builds to compare images sizes with -Os versus default optimisation for a few typical packages. Not urgent, but it will be useful to have these data points.
<JamieBennett> Commands Available: [TOPIC], [PROGRESS REPORT], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
<dmart> Getting a beagleboard up and running so I can examine the memory consumption on a real-ish linaro system.
<dmart> Waiting for upstream feedback on the final patch
<dmart> npitre: do you know whether you got the final patch? It's currently sitting in the perf-tools branch of Will Deacon's tree.
<slangasek> dmart: "waiting for Keybuk to be available" - should I see if we can set up a phone call with him?
<npitre> dmart: I think you told me at some point that a new one was coming
<slangasek> have you succeeded in catching him on IRC?
<npitre> dmart: don't know which one I have
<dmart> slangasek: haven't seen him for a while on irc... I could send a mail but I haven't done that yet.
<dmart> npitre: I'll send a mail clarifying it
<slangasek> dmart: I recommend taking that next step; he sometimes ignores his email too when he's on a project, but it's better than waiting for him to show up
<dmart> slangasek: ok
<slangasek> [ACTION] dmart to email Keybuk about bootchart changes
dmart to email Keybuk about bootchart changes
<dmart> I think that's all from me for now
<slangasek> [ACTION] dmart to email npitre clarifying final status of oprofile kernel patch
dmart to email npitre clarifying final status of oprofile kernel patch
<slangasek> dmart: thanks
<wookey> OK, you've had the good stuff already
<wookey> pdebuild-cross in squeeze-under-maverick 'just worked' so I decided to persue that for a few days
<wookey> fixed up multistrap to make maverick+toolchain chroots
<wookey> got pdebuild-cross building things in maverick under maverick
<wookey> Asked if release manager will consider putting it in
<wookey> Only remainig issue is that procps fails to install if underlying machine is Debian. multistrap ought to divert upstart/init binaries to fix this class of problem (and/or package ought to be more graceful). See bug 619783 (can I change a bug title in launchpad? - the debootstrap bit is wrong)
<wookey> Next I'll upload either as-is or modify to use debootstrap, then get back on xdeb case.
<wookey> I'll do some more building next week as there seem to be various cross-build bugs in things. Do we have a tag to put on such bugs in ubuntu?
<wookey> Also spent a bit of time with ppearse on where he's at so we can co-ordinate a bit better.
<wookey> snaffled an imx51 board from dmart for when I need some hardware
<wookey> but that's what I wrote down
<dmart> If there's no tag already, how about "cross" ?
<wookey> fine. I don;t even know if the concept means anything in launchpad
<slangasek> wookey: there's a yellow pencil "edit" button next to the bug title, I think everyone has access to it
<wookey> doh - so there is. I even looked and failed to see
<slangasek> I would suggest using "cross-build" as a tag for clarity
<slangasek> "cross" may mean something else to folks outside the ARM space, I don't know
<slangasek> wookey: anything else?
<slangasek> no significant progress on multiarch over the last week
<slangasek> dpkg support for maverick remains in jeopardy
<slangasek> I still have an action item to discuss path standardization at the LSB
<slangasek> should get to that in the next week
<ppearse> arm-m-ael-alip-evaluation: Use cross-compiler binaries with xdeb
<ppearse> have v5 & v6 compilers working.
<ppearse> One is on xorg - reached mesa.
<ppearse> Other is on the way to gstreamer, reached openssl
<ppearse> Should be pushing some bugs soon. wookey is helping with reportbug
<slangasek> reportbug for bug reporting?
<wookey> do cross-bugs in ubuntu have 'wishlist' status same as in debian BTW?
<wookey> cross-build bugs
<ppearse> Should I list the bugs as individual work items so they get release oriented?
<ppearse> reportbug for debian bugs
<slangasek> reportbug sends bugs to Debian, not to Ubuntu; that's a rather long way to go for a bugfix, are you also submitting them to Ubuntu so you're not blocking on a long turnaround?
<slangasek> wookey: I would say 'low' for Ubuntu
<ppearse> Yes both - but they should go to debian eventually
<slangasek> ppearse: please link the bugs to the blueprint, yes
<slangasek> ppearse: agreed - just as long as you're not blocking
<slangasek> anything else?
<ppearse> That's all this week....
<JamieBennett> thanks slangasek
<slangasek> [TOPIC] Activity reports
<slangasek> very briefly
<JamieBennett> ah, theres more
<slangasek> some people have been very diligent in getting these to me on a weekly basis... and some people less so
<slangasek> please write yourselves whatever reminders you need to in order to make this part of your weekly routine
<JamieBennett> slangasek: do you want them emailed or added to the wiki or both?
<slangasek> end-of-week or beginning-of-week, whichever suits you better
<wookey> Oh yeah - forgot about that
npitre raise hand as guilty
<slangasek> JamieBennett: emailed, preferably; then I can stick them in the wiki page for the meeting as a batch
<ppearse> email better for me - I can forward to ARM
<JamieBennett> slangasek: OK
<wookey> doesn't this IRC meeting suffice as a log ?
<slangasek> [TOPIC] AOB
<slangasek> anything else we need to cover?
<ppearse> Not for me
<wookey> Is the archive going to stay separate?
<wookey> ie ports and archive?
<slangasek> wookey: there's a tendency for the meeting to cover "stuff that needs doing" and not cover all the "stuff that's been done" - so weekly reports are still valuable
<slangasek> wookey: the archive is separate for the foreseeable future
Meeting closed at 16:08
Platform/DevPlatform/Meetings/2010-08-18 (last modified 2011-03-11 11:31:47)