Wednesday 29 Sep 2010

People Present

  • slangasek
  • JamieBennett

  • hrw
  • jcrigby
  • ppearse
  • wookey
  • npitre
  • aviksil
  • lool


  • dmart on holiday


  • Welcome Avik Sil
  • Review action items from last meeting
  • Blueprint status
  • Blueprint





    ARMv5, ARMv6 cross-compiler PPAs nearing completion; work on package cross-compile fixes ongoing; current challenge: gobject-introspection



    done for maverick; now providing preliminary simple backports to 10.04 LTS


    npitre, jcrigby

    work in progress to push patches upstream before the next merge window



    Dave Martin on holiday, no update this week



    Ubuntu kernel security testsuite now enabled on armel; SECCOMP and /dev/mem security both implemented, but not looking for a freeze exception for the 10.11 kernel



    u-boot 2010.09 rc1 in the archive; DT-enabled u-boot tested with a hacked beagle kernel, revised u-boot patches sent upstream



    xdeb, multistrap, pdebuild-cross fixes pending sponsorship. Current results of trying to build ALIP with xdeb and pdebuild-cross:

  • blueprint drafting time coming soon

Action Items from this Meeting

Action Items from Previous 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'
  • 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

Status Reports

Peter Pearse


  • arm-m-ael-alip-evaluation
    • armel-cross-toolchain-base builds & installs with modified gcc (armv5 vfp no thumb)

    • PPA for armv5 vfp no thumb gcc source set up
    • Built more packages straight from Ubuntu with xdeb
      • 45 of 82 packages in the original alip-ael can be built now
  • Versatile Express display fix tested OK
  • arm-m-ael-alip-appman-ext
    • None this week


  • Somewhere to put flavoured binaries & associated host toolchain binaries


John Rigby

Kernel Packaging

  • Fixed the broken kernel release from the previous week.


  • Started debugging ARM FDT support using hacked Beagle Kernel
  • Still had some issues using Linaro toolchain with -next u-boot.

Next Week

  • Continue debugging ARM FDT support un U-Boot
  • Work with Frederick on getting U-Boot flashed on my ST-E UX500 HW
  • Submit debugged U-Boot ARM FDT code to mailing list

Nicolas Pitre

  • Implementation of protection against /dev/mem misusage after discussion with Kees Cook.
  • Help Bryan Wu and Ricardo Salveti de Araujo in the investigation of an highmem issue affecting OMAP4 where a native kernel compile would generate imprecise aborts. Turns out that the issue is visible even with highmem turned off and the 2G:2G split active. Some SMP race is suspected.
  • The above led me to fix a bunch of VMALLOC_END definitions in the kernel which were wrong. This prevented proper 2G:2G usage on OMAP.
  • Posts to the ARM kernel mailing list of a bunch of patches I've produced in the last weeks.
  • Usual misc (meeting attendance, mailing list monitoring, etc.)

Jamie Bennett

This Week



  • Reviewed documentation from the team which will be part of a 'welcome pack' sent out prior to Linaro@UDS.
  • Provided input for an ARM blog post that will be published on Maverick release day.
  • More work on project management and tracking improvements that could be incorporated into Launchpad.



  • Meeting with Kate the Ubuntu Release Manager to co-ordinate. Also talked at length about bug tracking and image breakages. Need to help give input for manual team<->packages relationship which will give each package a team that can be prodded if bugs happen.

  • Meeting with Stephen to discuss the schedule for next cycle.
  • Meeting with Anmar to discuss Linaro@UDS and sponsored attendees.
  • Meeting with Steve and Kate to discuss the extra month Linaro has post Ubuntu Maverick release. This process needs documenting somewhere on the wiki for future reference.
  • Meeting with Oliver and David to discuss any impact Linaro could have on the ARM team deliverables post-Maverick. The ARM team most probably will need some u-boot-linaro changes as they are using Linaro's uboot. Other packages that could change (x-loader-ompa4, linux-ti-omap4) may need changes but do not affect Linaro.
  • Weekly Foundations, Linaro Release and Ubuntu Release meetings.


  • Sponsored attendee's of Linaro@UDS related admin.
  • Vacation Friday.


  • More work on bug-track.
  • Write-up of post-Maverick process.
  • Send out call for weekly testing.

Marcin Juszkiewicz

armel cross toolchain things

  • merged Steve's changes
  • fixed linux-libc-dev version
  • 1.50 got released
  • fixed libgcc1-dbg mangling - bug 646729


  • played with bug 615765 (strip)
  • tested patch for bug 598389


Meeting Log

Meeting opened by slangasek at 15:04

  • <slangasek> [TOPIC] Welcome Avik Sil

Welcome Avik Sil

  • <slangasek> we have a new face around the channel today! :)

    <JamieBennett> welcome aviksil

    <aviksil> :)

    <aviksil> thanks!

    <slangasek> Avik Sil is joining us from IBM on Foundations, and is going to be helping us with a variety of work centered around the kernel-userspace interface

    <slangasek> so be nice to him, or he'll break your tools ;)

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

Review action items from last meeting

  • <slangasek> * 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: 85)" [Medium,New]

    <slangasek> * lool to solicit toolchain WG input on bug #615765

    <slangasek> * hrw,ppearse to discuss possible versioning problem blocking PPA uploads

    <slangasek> * dmart to test that linux-linaro-tools package in maverick DTRT

    <slangasek> * "marketing" to write a 'what is linaro for dummies'

    <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> lool: did you get a chance to ask toolchain WG about 615765?

    <slangasek> hrw: the bot says your action item is still outstanding :)

    <slangasek> jcrigby: any feedback from dmart about linux-linaro-tools?

    <jcrigby> no

    <hrw> right

    <slangasek> hrw: did you talk with ppearse about his PPA versioning issue?

    <hrw> slangasek: we got it fixed iirc

    <lool> slangasek: OTP

    <slangasek> was the conclusion last week that does the job for "linaro for dummies" or not?

    <slangasek> we obviously don't have a marketing team, so if we need improvements, somebody will have to step up to do it :)

    <lool> slangasek: I did get feedback from Mark Mitchell that it *is* a binutils bug

    <lool> but didn't make progress

    <JamieBennett> slangasek: I think this is probably still needed, anmar seems a good candidate ;)

    <JamieBennett> or me if need anmar is too busy

    <slangasek> JamieBennett: can you ask Anmar to take it, then?

    <JamieBennett> slangasek: sure

    <slangasek> [ACTION] JamieBennett to ask Anmar about improving

JamieBennett to ask Anmar about improving

  • <slangasek> there, that's a much better action item :)

    <hrw> 18:11 < hrw> ppearse_late_aga: catch me tomorrow for that versioning talk ok?

    <hrw> 18:11 -!- ppearse_late_aga is now known as ppearse

    <hrw> 18:12 < ppearse> hrw: OK but I seem to have it solved now - dch --newversion 4.4.4-14ubuntu4-armv5vfp works lots better than dch --newversion 4.5.2arm5vfp1 <hrw> 18:12 < hrw> ok

    <hrw> 18:13 < ppearse> hrw: Examples incorrect but the point was I wasn't using - correctly....

    <hrw> so we got it done

    <lool> slangasek: I pinged linaro-toolchain@ again on LP #615765

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

    <slangasek> lool: ok, thanks

    <slangasek> hrw: excellent - there's an action item we can cross off the list this week!

    <slangasek> [TOPIC] Blueprint status

Blueprint status

  • <hrw> arm-m-cross-compilers is DONE

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

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

    <slangasek> aviksil: don't worry, you have no blueprints so you won't be put on the spot to talk :)

    <slangasek> jcrigby:

    <jcrigby> u-boot:

    <aviksil> slangasek: nice!

    <jcrigby> been work last couple of days actually testing arm device tree with hacked beagle kernel

    <jcrigby> found some bugs and I am submitting what I hope is my last patches to list today

    <slangasek> DT> awesome!

    <jcrigby> mergewindow for u-boot 2010.12 opened yesterday

    <jcrigby> kernel:

    <slangasek> how hacked is that kernel - anything yet that other people can be pointed at for testing/playing?

    <jcrigby> slangasek, no, but I may work on a proper beagle dt kernel now that I know what I am doing

    <slangasek> cool

    <jcrigby> as time permits

    <jcrigby> it is time for another kernel release to fix the various bugs that have accumulated since last one

    <jcrigby> and that is about it

    <jcrigby> no it isn't

    <jcrigby> I have some st-e tasks

    <jcrigby> pushing latest patches from fgu

    <slangasek> kernel package release, you mean? If we defer that a week or so, we can do it as an SRU in parallel with the Ubuntu kernel team's day-0 kernel SRU

    <jcrigby> slangasek, that sounds fine to me if there are no bugs that can't wait

    <slangasek> AIUI there are some security fixes going in, not all of which are x86-specific, so that's probably most effective

    <slangasek> jcrigby: I haven't heard of any can't-wait kernel bugs, have you?

    <jcrigby> no

    <npitre> nothing remotely exploitable has come up

    <slangasek> I think that's the best way to go, then

    <slangasek> JamieBennett:

    <JamieBennett> No blueprints but working on automated bug tracking, weekly image testing, Linaro@UDS planning, bugs triage, and branch reviewing amongst other things.

    <JamieBennett> Weekly image testing tomorrow so please test if you have hardware available

    <JamieBennett> Even if no test plan is available yet, just report bugs as normal

    <hrw> omap3 beagleboard c3 counts as hardware?

    <JamieBennett> qatracker will be setup for the images tomorrow morning UTC

    <JamieBennett> hrw: sure

    <JamieBennett> EOF

    <hrw> - Lucid amd64 cross compiler packages available on p.c.c. - not tested for things more complicated then 'hello' package -

    <hrw> - during playing with coreboot/seabios I found a bug in binutils - bug 648895 and upstream. Provided files to reproduce bug

    <ubot2> Launchpad bug 648895 in seabios (Ubuntu) (and 2 other projects) "cannot move location counter backwards (from 0000000000118000 to 0000000000004000) (affects: 1) (heat: 6)" [Undecided,New]

    <ubot2> bug 12066 in ld "cannot move location counter backwards (from 00000000000067e0 to 0000000000000000)" [Normal,Assigned]

    <slangasek> yes, testing those images is important - we've got a long way to go between beta and RC and we need to make sure we're staying on top of any regressions!

    <JamieBennett> slangasek: right

    <hrw> for Lucid I will also build i386 versions one day - but also on p.c.c. so no signed repository (PPA will take more then 2h) <hrw> OpenEmbedded project (where from I joined Canonical/Linaro) has our gcc-4.4 now. gcc-4.5 is added as set of patches from our repository

    <slangasek> hrw: very glad to see those lucid builds; having this available for the LTS is going to be very helpful

    <hrw> 4.5 is maintained by Khem Raj (we interviewed him some time ago)

    <hrw> slangasek: that was done for Nokia people to make support a bit easier

    <slangasek> hrw: have you told the toolchain WG the good news that their toolchain is being picked up?

    <slangasek> hrw: yep - they're not the only ones who will benefit, though, to be sure

    <hrw> slangasek: it is not used yet as default and in tests now - will write mail to linaro-toolchain@

    <slangasek> hrw: ok :)

    <hrw> slangasek: nokia will get separate set of packages - they asked for /opt/linaro/ prefix

  • slangasek nods

    <slangasek> dmart on holiday

    <slangasek> wookey: is ppearse around the office today?

    <wookey> yes - I'll poke

    <slangasek> slangasek:

    <hrw> I also filled bug 649810 for my fixes of cdebconf-terminal package - I just took it from ftfbs list and got it build

    <ubot2> Launchpad bug 649810 in cdebconf-terminal (Ubuntu Maverick) (and 1 other project) "fix for FTFBS (affects: 1) (heat: 8)" [High,Triaged]

    <slangasek> still no change on multiarch this week

  • hrw ended

    <slangasek> y'all are keeping me busy elsewhere ;)

    <wookey> poked

    <slangasek> hrw: oh sorry, didn't mean to cut you off

    <hrw> slangasek: for natty you will drop multiarch on me or others ;D

    <slangasek> hrw: I think I saw lool forwarding 649810 upstream to Debian, are you working with him on that?

    <ppearse> apolgies for late attendance

    <ppearse> /lg/log/

    <hrw> slangasek: did not noticed that

    <slangasek> I'd give you a Debian bug number, but bugs.d.o isn't talking to me <hrw> slangasek: basically any work on getting it into repo is fine for me

    <slangasek> ppearse: no worries! I think the only action item we gave you is that you're responsible for rolling the release candidate images next month - you're ok with that, right? ;)

    <slangasek> hrw: ack :)

    <slangasek> npitre:

    <hrw> debian bug #598281

    <ubot2> Debian bug 598281 in cdebconf-terminal "Needs porting to vte 0.26" [Wishlist,Open]

    <ppearse> slangasek:Ha ha

    <npitre> I completed the last task on the ARM security blueprint which was /dev/mem security

    <npitre> I started pushing a bunch of patches upstream and collecting comments on them

    <npitre> the goal is to have all those patches merged in RMK's tree before the merge window opens

    <npitre> also the DT "acceptability" has come up again on the lak mailing list

    <slangasek> yes, kees has pinged me about running the testsuite against the /dev/mem fix, I need to get my board booted off the other SD card so he can play :)

    <npitre> RMK wants to see a complete implementation of DT on something else than a development board to validate the whole thing on "real" targets

    <hrw> lool: linked your debian bug in ubuntu one

    <slangasek> hmm, what does he consider a real target?

    <slangasek> handset?

    <wookey> that was my thought <slangasek> maybe we could do it on a guruplug :)

    <npitre> real target == not a development board

    <hrw> guruplug is not devboard

    <slangasek> is a guruplug a dev board? :-)

    <npitre> guruplug is not supported by Linaro as being ARMv5

    <slangasek> heh, ok

    <wookey> same iwth cirrusplug is cheaper version of guruplug ;D

  • <hrw> is cheaper version of guruplug ;D

    <npitre> and.. frankly, DT for a guruplug is not _that_ interesting <wookey> how mnay armv7 products are out there that are not devboards?

    <hrw> npitre: there are small amount of armv7 hackable customer devices

    <slangasek> npitre: do you have a suggestion for hardware we could use in targeting, then?

    <slangasek> or anyone else

    <npitre> those are very simple devices configuration wise

    <hrw> nokia n900 is armv7

    <wookey> surely DT worksd pre- v7 too?

    <slangasek> also, we don't *have* to prototype with the maverick repo for this

    <slangasek> if necessary, we could use e.g., the Debian armel port, which supports armv5 <npitre> I think that we shouldn't target mainline merge of DT too quickly

    <npitre> gcl is maintaining a git tree with DT stuff

    <slangasek> ok

    <npitre> until it is sufficiently advanced, it is best to concentrate on a parallel tree for DT

    <slangasek> fair enough - so you think we can defer the question of "real" targets for now?

    <npitre> and even for the ARM devel boards, DT currently doesn't manage lots of things yet

    <slangasek> yep

    <npitre> from my own point of view, DT tasks are probably understaffed

    <npitre> and since there is not so many people working on it makes it in practice not a high priority it seems

    <slangasek> npitre: are there particular areas you think we're currently missing, or is it just about getting critical mass?

    <wookey> maybe people avoid it to avoid an argument :-)

    <npitre> well, the fact that people _can_ avoid DT makes DT not esseltial either

    <npitre> so we go in circle

    <npitre> essential*

    <slangasek> ok; sounds like this is an area that needs further discussion

    <npitre> at some point we'll have to really weight the benefits of having DT on ARM (in the context of an architecture that can manage without it already) vs the cost of making DT actually useful on ARM

    <slangasek> npitre: do you want to email some thoughts to the list about this? <npitre> because right now we don't have critical mass for DT to really make good progress

    <npitre> I think that might be a good topic at LDS too

    <hrw> speaking of LDS...

    <slangasek> npitre: agreed, but let's not wait for LDS before starting the discussion - please mail the list and we can pick it up from there

    <slangasek> hrw: ?

    <hrw> we need to organize list of sessions in a way that wookey and emdebian people could participate remotely. best would be to have most important ones on first days

    <hrw> as later ELC-E will take those guys busy

    <slangasek> hrw: yes, this is being kept in mind :)

    <hrw> slangasek: just wanted to remind <slangasek> wookey: your turn

    <wookey> pdebuild-cross and multistrap new patchsets filed - waiting for steve to upload.

    <wookey> Now builds 34/73rds of ALIP. All failures appear to be packaging/build system bugs not pdebuild-cross bugs.

    <wookey> Status on that steve?

    <npitre> slangasek: I'll cogitate DT issues a bit more and post something at large to the ml

    <wookey> Issues with apt authentication in v0.8 (hacked around for now - will mail deity list)

    <wookey> xdeb working much better with 2 major bugs fixed. will check in current status today for upload.

    <ppearse> wookey: Whohe "apt authentication"?

    <slangasek> wookey: I have one more round of review comments on the pdebuild-cross changes, including some things that I consider blockers; will have those to you right after the meeting; sorry for being so slow on this

    <slangasek> wookey: and then I'll look at multistrap :/

    <wookey> ppearse: erm, what?

    <slangasek> wookey: the apt authentication hack in particular is one I'm not willing to upload to the arctchive

    <ppearse> wookey: I don't understand what "apt authentication" might be

    <slangasek> archive, either

    <wookey> the issue is that new 0.8 apt seems tricter than old apt on key config so trying to download authenticated stuff in a chroot doesn;t work any more, even though it used to

    <ppearse> slangasek: A very cold archive?

    <hrw> wookey: you mean signed repositories with lack of apt keys? <wookey> No, 'noauth' now works OK, but if you try to use auth it all fails

    <ppearse> /me understands now

    <wookey> unless you --force-yes all over the place

    <slangasek> ppearse: archive uploads of packages in universe that don't touch any Ubuntu release images are still permitted right now, as long as they're bugfix-only... so we just need to follow our own Linaro freeze guidelines right now

    <slangasek> ppearse: oh, 'arctchive', I see :-)

    <wookey> xdeb working much better with 2 major bugs fixed. will check in current status today for upload.

    <slangasek> you weren't talking about freezes at all :)

    <wookey> Check in to bzr or post patches to bugs? or both?

    <ppearse> \me sorry <slangasek> ppearse: my kvm sometimes sputters extra characters into the input stream :P

    <ppearse> \me blast

    <slangasek> recommendations for reliable 4-way KVMs with VGA+HDMI welcome...

    <wookey> slangasek: how do you want xdeb changes presented?

    <hrw> slangasek: zyga uses one - ask him

    <slangasek> wookey: commit to branch is fine, then ping me to pull&upload?

    <wookey> OK

    <wookey> Still penty of brokenness. 8/73rds of ALIP build directly.

    <wookey> But 29 it just decides there is no need (even with --force-rebuild) and most of those probably would work if it tried. <wookey> And 6 failed due to dbus being uninstallable in a chroot - I'll file a bug about that.

    <hrw> wookey: does my p.c.c. repo or PPA is in use by any of tools?

    <wookey> NNeed to check if it broke in pdebuild-cross as well or not.

    <wookey> hrw: it is until steve uploads the new version...

    <ppearse> hrw:Mine

    <wookey> (of multistrap)

    <wookey> For the builds that got as far as building cross-errors matched pdebuild-cross, which is good.

    <wookey> Curent status at:

    <wookey> Will update cross-building wiki for when current tools reach maverick

    <hrw> I want to be able to clean ppa as is is getting old and breaks upgrades

  • ppearse will cope

    <wookey> hrw - updating it is too hard?

    <slangasek> well, multistrap ought to get in today

    <wookey> Actually PPA is not used - old ~hrw repo is

    <hrw> ok, will clean ppa then

    <wookey> so you can bin it if you like

    <wookey> one query: Where is the right place for xdeb cross-build discussion?

    <slangasek> linaro-dev?

    <hrw> wookey: did you saw document?

    <wookey> debian-embedded normally most appropriate but maybe not with xdeb not in debian yet.

    <wookey> And some stuff may be different in ubuntu?

    <wookey> Or I can bore linaro list with it...

    <slangasek> it's very on-topic for linaro-dev

    <wookey> hrw I don't have permission for that

    <slangasek> and Linaro "owns" xdeb upstream

    <hrw> wookey: hm

    <wookey> (as

    <wookey> slangasek: OK. I have rather involved questions but I'll try linaro-dev

    <hrw> wookey: maybe?

    <wookey> hrw that works

    <hrw> wookey: wookware@ added

    <slangasek> wookey: thanks. anything else?

    <wookey> you probably want to put that on our sheet...

    <wookey> nope that's all

    <slangasek> ppearse:

    <wookey> Oh actually:

    <wookey> Supposed to be on hols next week but have failed to arrange yet (or

    <wookey> even choose destination beyond 'warm'). It may slip a week...

    <slangasek> toolate ;) <slangasek> ah :)

    <wookey> to be honest I think that'll work better

    <ppearse> Ready to open up armv5, armv6 toolchain PPAS

    <slangasek> wookey: does that mean you are or aren't going next week? or not yet decided?

    <wookey> not decided. 30/70 this/next

    <ppearse> Hitting more packages with xdeb

    <wookey> will tell when I know myself

    <ppearse> Currently trying to get gobject-introspection out of the way

    <slangasek> ppearse: is still in limbo; Anmar has confirmed it's on his watchlist with IS, but still no ETA

    <hrw> slangasek: linaro version of p.c.c.? <slangasek> hrw: yes

    <hrw> cool

    <wookey> or .d.o

    <wookey> useful

    <ppearse> I have a launchpad FAQ outstanding - might be possible to store binaries in a PPA with broken source.....

    <slangasek> ppearse: gobject-introspection> anything interesting in that particular failure?

    <slangasek> binaries with broken source - hmm; I doubt that will work cleanly

    <wookey> tries to compile python to wrong arch before running it on binaries

    <wookey> If it just used pythong prob wouldn't arise

    <hrw> (szafa-maverick-64bit)test@home:~/xdeb$ xdeba gobject-introspection

    <slangasek> wookey: eep

    <ppearse> Complexity - builds some target (should be build host) tools to run on the installed libraries to rebuild more target binaries

  • slangasek nods

    <hrw> ../Include/pyport.h:694: error: #error "LONG_BIT definition appears wrong for platform (bad gcc/glibc config?)."

    <hrw> thats xdeb python - 32bit != 64bit problem

    <slangasek> so - cross-compiling continues to be fun :)

    <ppearse> Also uses standard debian stuff so gobject-introspection/debian/rules is almost empty. I know that's how it should be - but I can hack it easier when the package rules do almost everything ;-(

    <hrw> slangasek: no, cross compiling under ubuntu is not fun. it is pain in the ass <wookey> you OE tyes are spoilt

    <wookey> types

    <ppearse> Should keep me busy for rest of this week

    <slangasek> ppearse: I don't consider cdbs "standard debian stuff", fwiw :)

    <slangasek> it's "typical GNOME in Debian stuff", but not standard

    <hrw> "bitbake whole-gnome with lot of apps and software" == cross compilation of all that in few hours ;D

    <hrw> no hands ;D

    <slangasek> ppearse: did you ever get a chance to try the mesa blacklisting that lool suggested? I noticed that's been carried over for a few weeks

    <wookey> hrw - we can make that work in Debian too....(eventually)

    <ppearse> If you speak bitbake.....

    <hrw> wookey: one day

    <lool> mesa > I'd also like to note that I don't think it's enough; it only helps a bit IIRC, but that was a while ago

    <wookey> which 'it'?

    <ppearse> No - I believe it's working anyway since xorg built with no problems last time I tried and there are mesa entries in the xdeb config. I'll drop it for now

    <slangasek> ok

    <slangasek> anything else?

    <ppearse> That's all from me

    <slangasek> alright, thanks :)

    <wookey> cheers

  • wookey gets coffee

    <slangasek> [TOPIC] blueprint drafting time coming soon

blueprint drafting time coming soon

  • <slangasek> this topic mostly speaks for itself :)

    <slangasek> just wanted to give y'all a heads-up that as we get closer to UDS, we're going to be doing some preliminary drafting of blueprints so we know what it is we need to talk about at UDS

    <slangasek> so you'll start getting emails informing you that you're assigned to blueprint drafting

    <slangasek> and then once we have blueprint entries, we'll sort out all the scheduling to make sure we have the right things scheduled at the beginning of the week :)

  • ppearse ducks

    <slangasek> [TOPIC] AOB


  • <JamieBennett> Test test test tomorrow :)

    <slangasek> :)

    <slangasek> any other other business?

    <hrw> poor beagleboard...

    <ppearse> none here

    <slangasek> #endmeeting

Meeting closed at 16:16

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