Wednesday 16 Feb 2011
- Wednesday 16 Feb 2011
- Meeting opened by slangasek at 16:01
- Review action items from last meeting
- Blueprint status
Action Items from this Meeting
slangasek, JamieBennett to shake the tree for developer image testing
- slangasek to prod archive admins about rejected kernels
Action Items from Previous Meeting
JamieBennett to come up with test assignments for the new developer image: carried over
- jcrigby to write up landing team u-boot, kernel workflows and send for review after first draft is done: carried over
- wookey to work with tgall_foo to get the linaro-nano image building
tgall_foo and JamieBennett to get linaro-desktop building in Offspring
- slangasek and fturgis to decide whether or not to move to more recent version of systemtap
- ppearse to investigate how libtool does ldopen for GObject Introspection work
- Upstream link-time discard versus SMP_ON_UP problem still not fixed. More discussion with Russell: expect this to converge on some kind of solution within the next week or 2. In the meantime, I may suggest temporary merging of my workaround patch in linaro.
- omap3/4 Thumb-2 compatiblity patches re-posted. Did some power management testing to exercise the code: power off suspend _may_ work on Beagle xM, but this board is hit by an erratum which makes it hard to test. Weirdly, this problem only strikes when the kernel is built in Thumb-2, but I can find no actual bug so far. Tony Lindgren has picked up my tree and my try to test this this.
Methodology proposal now agreed with Steve Langasek, with a couple of minor modifications: https://wiki.linaro.org/Platform/DevPlatform/Specs/MemoryFootprintMethodology
- Spent some time helping debug boot partition layout generated by linaro-media-create on OMAP.
- Tidy up the proposal for link-time section discard avoidance and report.
- Discuss prioritisation for outstanding kernel tasks.
- Write up the output from the Freescale i.MX BSP review discussion, and post for comment.
- Worked on building lttng-modules and ltt-control for ARM. Got kernel oops on running lttctl on ARM, which was reported to Mathieu Desnoyers. The workaround for this, as suggested by Mathieu was also tried but did not work. Will continue working on this issue.
- Built debian packages for ltt-bin and associated libraries from ltt-control source archive.
- Took off on February 8.
- Polishing python 2.6
Checked with Debian Java Maintainers re tracking the Debian Orbital Alignment Team bug http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=587742 (Move to eclipse helios)
- Started working with latest DS-5
- eclipse packages in natty do not support cross building of applications
- DS-5 having problems in VMPlayer
More Natty cross builds & propose merges
- Assist ARM internal cross build of LAMP stack
- Agree new work items with Steve
- Check DS-5 outside VMPlayer, possibly raise bug on VMWare problems
- Import existing projects
- Build eclipse with xdeb
- Tue 1st March
- Wed 2nd March
- Merging of suggested review Changes into meego packages
- Contextkit changes to compat 7 with dh rules
- Looking at kwin build
- Released new version based on upstream v2011.03-rc1 and with packaging now in bzr
- Committed to ST-E Landing Team to start upstreaming (slowly) support for U8500. This will be one upstream release behind the dates in the upstreaming blueprint but better to start one release late than the next Ubuntu cycle.
- Released new version including two new platforms
Finished first draft of https://wiki.linaro.org/Resources/HowTo/LandingTeamUBootAndKernelWorkflows which has pointers to my existing https://wiki.linaro.org/Resources/HowTo/PackageYourOwnKernel and a new u-boot packaging page https://wiki.linaro.org/Resources/HowTo/BSPUBootPackagingWithGIT. The later is git based at the request of Landing Team members I surveyed. It does have a note at the beginning stating that the preferred way is how
u-boot-linaro does it with bzr packaging of upstream git. The work flow doc also has a pointer to page that will soon describe the packaged linux-linaro kernel. Right now it only has headings but no contents.
==== Next week ===
- Do enough clean up on core U8500 functionality to submit it upstream.
- Do a new release on new 2.6.38-rc? based linux-linaro which should be happening soon.
- Finish stuff necessary for applying for Ubuntu per-package uploader status
- linaro-nano - was blocked by germinate bug 717879, bugfix pushed upstream, posted testing results yesterday, no feedback yet. good discussion with wooky on approaches, the whittling has started.
- linaro-headless - fix pushed for 712031 (localhost bug)
- linaro-development - added powerdebug - bug 718871
- linaro-netbook - moving to utilize ubuntu's netboot by reference - in progress
- linaro-alip - fixed localhost bug 712031, fixed gksu sudo-mode bug 708123, tho something isn't quite right, the system doesn't like password-less sudo even with the entry in the sudors and true in right place for gksu. Set a pw and things are fine.
- kwin - discussed priorities with Jesse, Jammy and Kunal last night. 1) kwin 2) chromeos WM 3) meego
- libjpeg-turbo, libjpeg62-neon - pending discussion now with Sachin and Jesse.
- meego - postponded
- chromOS window manager - no action
Meeting opened by slangasek at 16:01
<slangasek> [LINK] https://wiki.linaro.org/Platform/DevPlatform/2011-02-16
<slangasek> let's get to it
<slangasek> [TOPIC] Review action items from last meeting
Review action items from last meeting
<slangasek> * JamieBennett to come up with test assignments for the new developer image: carried over
<slangasek> * jcrigby to write up landing team u-boot, kernel workflows and send for review after first draft is done: carried over
<slangasek> * wookey to work with tgall_foo to get the linaro-nano image building
<slangasek> * tgall_foo and JamieBennett to get linaro-desktop building in Offspring
<slangasek> * slangasek and fturgis to decide whether or not to move to more recent version of systemtap
<slangasek> * ppearse to investigate how libtool does ldopen for GObject Introspection work
<slangasek> JamieBennett: I've seen the test assignment proposal; any uptake there?
<JamieBennett> slangasek: no response as yet
<JamieBennett> I'll push again
<slangasek> [ACTION] slangasek, JamieBennett to shake the tree for developer image testing
slangasek, JamieBennett to shake the tree for developer image testing
<slangasek> I think the previous action item can be considered done, anyway
<jcrigby> work flows doc done and moved to /Resources/HowTo
<slangasek> and we have a linaro-nano image building now, so that's good
<slangasek> jcrigby: great!
<slangasek> [LINK] https://wiki.linaro.org/Resources/HowTo/BSPUBootPackagingWithGIT
<slangasek> jcrigby: is that the right link?
<slangasek> hmm, no
<slangasek> "This method is NOT recommended"
<tgall_foo> linaro-desktop morphed into a discussion based on two needs 1) where compiz and GLES support is (it's not done) and related what the fallback scenarios are like and 2) instead of being dependent on the ubuntu desktop be dependent on the ubuntu netbook seed
<jcrigby> thats a different doc
<slangasek> jcrigby: which is the right one?
<slangasek> [LINK] https://wiki.linaro.org/Resources/HowTo/LandingTeamUBootAndKernelWorkflows
<slangasek> tgall_foo: will you take care of converting our linaro-desktop seed to a minimal overlay on the ubuntu-netbook metapackage?
<tgall_foo> slangasek, yup .. in progress already
<slangasek> ok, great
<dmart> hi all, sorry I'm a bit late!
<slangasek> systemtap> still being discussed, carry over
<wookey> I gave tgall a braindump on emdebian busybox experience. Not sure how useful that waqs to him. We seem to be largely in agreement about how things should be done, but I'm letting him get on with it (I'm full)
slangasek waves to dmart
<slangasek> fturgis: hi there
wookey multitasks with builder on phone
<slangasek> wookey: great, thanks
<tgall_foo> wookey, I'd say it was very useful
<slangasek> (builder on phone.. that's a strange place to run a builder!)
<slangasek> ppearse: had a chance to look into libtool's ldopen?
<wookey> I do physical building too (starting 6th march I was just told)
<ppearse> Just a peek - didn't seem to be what we want, I'll look deeper this week.
<ppearse> repeat the action please
<fturgis> steeve, I am in a 1 or 2 hour call where I am only needed 10 minutes so I shall be able to follow in parallel....
<slangasek> fturgis: sounds good
<slangasek> [TOPIC] Blueprint status
<slangasek> [LINK] http://status.linaro.org/linaro-foundations.html
<slangasek> so we have these nice workitem status charts that show us where we are in the cycle and I think we should use them more
<hrw> why foundations when we are developerplatform now?
<JamieBennett> hrw: launchpad naming
<slangasek> hrw: legacy naming and I haven't filed a bug to change it
<JamieBennett> slangasek: we can rename, would break a bunch of things though
<JamieBennett> slangasek: needs investigating
<slangasek> yep - I'm not in a hurry
<tgall_foo> slangasek, and by use them I suspect thatdoesn't mean folding them into paper airplanes
<slangasek> tgall_foo: no, it means look at the 'status by assignee' table and check how you're doing against the release schedule
<JamieBennett> the toolbar at the top lets you dig down to individual data
<tgall_foo> indeed ... big swing of todo / completion with the megoo | kwin swizzle in priorities
<slangasek> $ echo $(shuf -e hrw jcrigby dmart wookey slangasek ppearse JamieBennett aviksil tgall_foo kunal fturgis)
<slangasek> aviksil wookey dmart kunal tgall_foo jcrigby ppearse JamieBennett hrw slangasek fturgis
<slangasek> aviksil: how's it going?
<aviksil> slangasek: going well
<aviksil> built lttng-linaro kernel, lttng-modules and ltt-control for armel and used on beagle board
<aviksil> generated trace which could be viewed in lttv on the host
<aviksil> built debian packages for ltt-bin and associated libraries from ltt-control source archive.
<aviksil> worked on generating lttv package for armel. generated packages are yet to be installed and executed
<aviksil> slangasek: did you see my mail today?
<slangasek> aviksil: yes - I thought lttv used to be bundled with ltt-control source, I guess maybe this has changed?
<aviksil> slangasek: it's separate in upstream itself
<slangasek> aviksil: we can take that up via email; if it's a separate upstream, we should have a separate package
<aviksil> slangasek: ok
<aviksil> that's all from my side
<slangasek> ok, thanks!
<wookey> Been suffering from lurgy since thursday, limiting effectiveness, seems to be improving, but slowly.
<wookey> Tutted at by steve for insufficient upstreaming, so sorted out the xdeb patches and pushed a couple of branches. One more ready to go, one more still needs work.
<wookey> Just need to test before asking for merges.
<wookey> Found out a lot about apache/apr/apr-utils build process which manages to break cross-building and is unhelpfully complicated. Short version is 'multiarch will make it work better', but there is still an issue of arch-specific (build)-config scripts, which we can't put in /usr/bin
<wookey> Getting sprint sorted - mail should go out later today with list of priorities and some timings.
<wookey> Did some multiarch wiki editing as a job that didn't require too much hard thinking.
<wookey> I think that's about it
<wookey> Oh and have a dpkg-cross patch and a libtool patch to send in
<wookey> got some info from guilhereme on xdeb refactoring
<tgall_foo> aviksil, how soon do you anticipate wanting to add lttng support to the developer image ?
<hrw> wookey: xapt is going to be killed or kept?
<slangasek> aviksil, tgall_foo: we'll need to have the package in the archive by feature freeze (Feb 24) - we can put it in the seed later, but why wait
<wookey> unless/until we add per-binary functionality to xdeb
<hrw> wookey: can it be improved to have "xapt -a armel update/install" commands?
<wookey> I believe that's already in experimental version
<slangasek> tgall_foo: actually, I guess ltt-control is already packaged and we should go ahead with seeding it?
<wookey> but I haven't checked
<wookey> that would make it a useful apt-cross replacement (which is badly needed IMHO)
<slangasek> wookey: apr config scripts... so we need to go the whose $(DEB_HOST_GNU_TYPE)-apr-config route?
<tgall_foo> slangasek, it could be done ... just the kernel support isn't turned on yet... thus the q to aviksil
<hrw> wookey: I have local apt cache/proxy so it does not hurt so badly but fetching indexes each time suxx
<wookey> slangasek: that could work
<slangasek> tgall_foo: the kernel support may or may not land in all kernels, but from talking with npitre I think we'll have this in the mainline kernel for feature freeze - please go ahead with seeding it regardless
<wookey> but at the moment they also end up with the wrong stuff in them
<slangasek> the kernel bits are sold separately anyway
<slangasek> wookey: oh, fun
<wookey> It works OK if you use apache's internal apr-config
<wookey> but that ignores the fact that they are separate source packages in debian
<slangasek> wookey: well, keep us posted on your travails there
<tgall_foo> slangasek, k
<wookey> I';ve used it as a way of encouraging people to try multiarch and see how much that helps
<dmart> been working on kernel this week
<wookey> that should all become clearer after spring next week
<dmart> the saga of Thumb-2 on omap continues ... but on the + side, kevin hilman was able to get a positive test result for power management in Thumb-2. A few bits of code need to be built as ARM so they interoperate with the non-Thumb-capable OMAP firmware
<wookey> hrw: talk about that next week with neil
<hrw> wookey: xapt? ok
<slangasek> dmart: neat!
<dmart> npitre also picked up my patches
<dmart> I will roll a final version of my patch set, and then hopefully we can turn this on properly
<slangasek> and then you guys start dropping ARM insn support from the Cortex-A series?
<dmart> I also investigated briefly whether we can modify the module vermagic for Thumb-2 kernels. Currently, you can probably get away with loading ARM modules into a Thumb-2 kernel, but it's known not to be safe.
<hrw> slangasek: no, that will be in Cortex-M8
<slangasek> hrw: but Linaro won't run on a Cortex-M, so that's uninteresting
<hrw> slangasek: who knows how powerful M8 will b
<dmart> slangasek: ARM support isn't going away (unless you want to run on M-class CPUs)
<dmart> no MMU is the main constraint for full-blown Linux
<dmart> anyway, that's a bit off topic ...
<slangasek> dmart: how's today's porting jam from your perspective?
<dmart> slangasek: didn't seem to be very many people active -- were we expecting more?
<slangasek> dmart: probably not for today; short notice, etc. Next week should be better
<slangasek> oh yes - for those who missed the mail, we're running weekly porting jams on IRC, 1400-1800 UTC in #linaro
<dmart> From my pov it was useful to follow up on some of those old issues -- good to see that alignment faults got fixed to raise SIGBUS etc.
<slangasek> so you're all welcome to participate there, before and after this meeting
<slangasek> not so much welcome as encouraged
<slangasek> and depending on my mood, possibly 'drafted' as well
<tgall_foo> heh ... definitely a good activity
<dmart> slangasek: was the idea to assign bugs to people from the queue?
<slangasek> dmart: that will be part of it also
<slangasek> though not the main focus of the weekly jam
<slangasek> anyway, moving ahead with status
dmart also wonders whether it would be better to have a separate channel, but this might reduce visibility and confuse people
<dmart> no further update from me on foundations.
<slangasek> kunal sends his regrets this week; tgall_foo's turn
<slangasek> dmart: I'd like to give it a couple weeks on #linaro, we can reconsider then
<tgall_foo> linaro-nano - was blocked by germinate bug 717879, thanks to slangsek for his assistance, suggested bugfix pushed upstream no feedback yet. good discussion with wooky on approaches
<ubot2> Launchpad bug 717879 in germinate "germinate should not examine all components in PPAs" [Undecided,New] https://launchpad.net/bugs/717879
<tgall_foo> linaro-headless - fix pushed for 712031 (localhost bug)
<dmart> slangasek: sure
<tgall_foo> linaro-development - added powerdebug - bug 718871
<tgall_foo> linaro-netbook - moving to utilize ubuntu's netboot by reference - in progress
<tgall_foo> linaro-alip - fixed localhost bug 712031, fixed gksu sudo-mode bug 708123
<ubot2> Launchpad bug 718871 in linaro-seeds "add powerdebug to the seeds" [Undecided,Fix committed] https://launchpad.net/bugs/718871
<ubot2> Launchpad bug 712031 in linaro "alip: can't look up localhost.localdomain" [Medium,Fix committed] https://launchpad.net/bugs/712031
<ubot2> Launchpad bug 708123 in linaro "alip: /apps/gksu/sudo-mode is set to false" [High,Fix committed] https://launchpad.net/bugs/708123
<tgall_foo> kwin - discussed priorities with Jesse, Jammy and Kunal last night. 1) kwin 2) chromeos WM 3) meego seems to be the consensus
<slangasek> tgall_foo: I guess that bugfix is enough to let us germinate locally, right? so you can do test runs, push to your ppa and ask for a package copy?
<tgall_foo> chromOS window manager - no action
<tgall_foo> slangasek, right ... I'm not blocked and it's working
<tgall_foo> libjpeg-turbo, libjpeg62-neon - where are we at on the PPA discussion on this so that we can get libjepg-turbo added to the multimedia build ?
<slangasek> localhost> yay, in my queue for reviewing this morning
<tgall_foo> slangasek, gksu fix as well ... that's "refix" is golden
<slangasek> tgall_foo: so I'm actually confused about what PPA discussion that is and needed to ask you. I thought this was left that there were some changes to integrate into the git packaging tree, and once that's done libjpeg-turbo should be pushed to the overlay archive
<slangasek> and an open question about what usr/lib/libturbojpeg.so is for
<slangasek> can we discuss after the meeting?
<tgall_foo> slangasek, well let's take this offline ... we should probably be clear where WIP should be vs completed stable packages
<slangasek> tgall_foo: if meego is deprioritized, should we postpone those workitems? I don't imagine you guys are going to get through all of kwin *and* meego this cycle
<tgall_foo> slangasek, yup already marked as postponed in the blueprint
<slangasek> hmm? not I
<slangasek> but if it's done, so much the better
<JamieBennett> Can I jump in with my report, have to run and its short one?
<tgall_foo> JamieBennett, yup I'm done
<slangasek> oh, yes
<slangasek> jcrigby: then you
<JamieBennett> so as I've moved teams I'm doing more and more non-dev platform stuff
<JamieBennett> This week has been mostly defining the release cycle going forward
<JamieBennett> still working with the mngt team on that
<JamieBennett> Also capturing lots of metrics for mngt
<JamieBennett> writing code to automate all this too
<JamieBennett> status is continuing to evolve and we should get more improvements in time
<slangasek> fturgis: how's your call going? Should I give you one of the next slots so we make sure you get a chance to go?
<fturgis> let's try
<slangasek> JamieBennett: any metrics we want to rig from our side to make ourselves look better?
<jcrigby> fturgis, I'll go after you
<JamieBennett> heh, mostly operational ones
<JamieBennett> slangasek: https://wiki.linaro.org/Metrics has a list of what we are capturing
<slangasek> fturgis: ok, please go ahead if you're free
<fturgis> I went back to official setup now that I know which package to install -> could compile basic systemtap scripts after installing kernel headers (begin, end probes, no vmlinux=no kernel probe)
<fturgis> encountered some issues to create image on my desktop (/dev/pts related), I had to go to another console. Weird, pseudo-terminials do not like me
<slangasek> fturgis: systemtap> great - anything else that you think still needs to be tested, or should we consider that work item done?
<slangasek> pseudo terminals are fickle friends
<fturgis> it is not enough to say it is ok
<fturgis> I tried kernel 1003.6 by apt-get install + flash-kernel. Kernel boot failed around end. This is what may block me
<slangasek> fturgis: ah
<fturgis> as .ddeb is for 1003.6
<slangasek> fturgis: do you want to post a log for the boot problem to linaro-dev, or pastebin and work through it on IRC? I guess jcrigby would like to know about boot failures on omap with the new kernel
<fturgis> OK I'll do
<fturgis> I want to push the patch I have seen for systemtap with my previous tests and we could sy that .ddeb stuff is another story
<fturgis> just FYI, understood how to work-around v1.4 issues (compiler warning=error): there is a stfu-kbuild-i-know-better option
<slangasek> fturgis: did I already point you to this documentation about requesting sponsorship of patches into Ubuntu? https://wiki.ubuntu.com/DistributedDevelopment/Documentation/SeekingSponsorship
<fturgis> yes, you sent a mail
<slangasek> ok - let me know if you have any trouble getting that systemtap patch pushed
<slangasek> anything else?
<fturgis> I also need to test more scripts, I have seen few issues but I also have them internally in TI. I guess this can be another activity.
<fturgis> that's all. 1 week holidays in 1.5 week
<slangasek> ok, thanks
<jcrigby> ok me now
<fturgis> by the way, am I doing correctly for kernel 1003.6 ?
<slangasek> jcrigby: yes please
<jcrigby> did a new u-boot release based on latest upstream -rc
<slangasek> fturgis: 1003.6 should be the target, yes
<slangasek> fturgis: when you get a chance, please record your holiday plans on the "Linaro Leaves" google calendar
<jcrigby> also new kernel with two new platforms added but the new platforms are in the rejected queue
<fturgis> once I have my password reset
<slangasek> jcrigby: I haven't seen any response yet on those rejected kernels, have you?
<jcrigby> no, I have not
<jcrigby> just checked that they are still in rejected
<slangasek> [ACTION] slangasek to prod archive admins about rejected kernels
slangasek to prod archive admins about rejected kernels
<jcrigby> the promised landing team work flow doc is done but pretty short. It does however point to some other useful docs I did as well
<jcrigby> one more doc to do that describes the linaro packaged kernel so people can cross build it themselves when they need a tweaked one (config or patches)
<slangasek> too soon to say how it's working for the LTs, I guess?
<wookey> jcrigby: did the kernel packages get fixed for cross-building yet?
<jcrigby> I suspect the current members have gone through the pain but as there are new lt members it will be usefull for rampup
<jcrigby> wookey, I proved to myself that using xapt I could get enough -dev stuff installed to make the tools cross build
<jcrigby> still need to fix the other issue, of the binaries in scripts need to be built twice once for host and once later for target using previously host built bins
<wookey> Right. OK. Is there a biug for that somewhere?
<slangasek> I noticed when going through armel-tagged bugs that someone had raised that previously
<slangasek> not on our kernel packages, but on one of the others in the archive
<wookey> one of the other kernel-packages in the archive?
<jcrigby> ahh, I have not seen that
<wookey> it should be the same everywhere, debian too
<slangasek> wookey: yes, the linux or linux-ti-omap4 package maybe
<slangasek> bug #666267
<ubot2> Launchpad bug 666267 in linux-ti-omap4 "Cross compiled headers package breaks DKMS compilation" [Medium,New] https://launchpad.net/bugs/666267
<slangasek> we can take a task on that
<slangasek> jcrigby: can you add a linux-linaro-mx51 task to that bug?
<jcrigby> yes, doiing that right now
<hrw> took m.hope makefile and edited it to produce tarballs with toolchain. works fine
<hrw> available in lp:~hrw/+junk/cross-build branch
<slangasek> ppearse: shoot, lost track of position order thanks to all the queue-jumping, sorry - you can go next
<hrw> added -dbgsym support into cross binutils. need to convince doko to merge it
<hrw> bug 711523
<ubot2> Launchpad bug 711523 in armel-cross-toolchain-base "dbgsym packages generated during build, but not uploaded" [Undecided,In progress] https://launchpad.net/bugs/711523
<slangasek> has he been reluctant to merge it?
<hrw> once it will get merged/released I will release new armel-cross-toolchain-base with it
<hrw> slangasek: we need to discuss it and it will be in.
<hrw> did some random cross toolchain builds to check some bugs or ideas
<hrw> ppearse: can you confirm that bug with cross ncurses as fixed? forgot number
<hrw> bug 704005
<ubot2> Launchpad bug 704005 in armel-cross-toolchain-base "segfault crossbuilding ncurses" [Undecided,Incomplete] https://launchpad.net/bugs/704005
<ppearse> With your 1.44 from natty it's OK
<hrw> marked as fix released then
<hrw> also cursed a bit in TI direction due to panda shutdowns
<hrw> next week - emdebian sprint where I will discuss future of cross toolchain packages in debian/ubuntu
<hrw> before and after multiarch
<hrw> I have first versions working under debian but very very very very ugly
<hrw> thats all from me
<slangasek> hrw: thanks
<ppearse> arm-m-ael-alip-evaluation: Shiny new cross python2.6 ready for review.
<ppearse> Creeping up on qt4 - I've reached libtools so I can look at the dlopne again...
<slangasek> ppearse: incidentally, when you click 'resubmit this branch', it does discard the previous merge request history, which I know you were hoping to avoid :/
<ppearse> other-linaro-n-eclipse-cdt: Installed Helios DS-5.
<slangasek> (I'm assuming that's what happened to it as I saw a new merge request)
<ppearse> Back & forth between my Maverick host & natty VMWare
<ppearse> Problems with models, ARM case raised, internal investigations afoot.
<ppearse> slangasek: Yes - I think the history should remain so reviewer can check their points have been covered.
<slangasek> ppearse: yep; so pushing updates to a branch should be fine, as long as you don't click on the 'resubmit' button
<ppearse> I see - I'll try that next time.
<slangasek> anything else?
<ppearse> Thinking about changing the other-linaro-n-eclipse-cdt work items to reflect versioning & DS-5.
<slangasek> that just leaves me, doesn't it?
<slangasek> started getting the arm porting queue effort going
<slangasek> which you're all invited to participate in on #linaro after this meeting
<lool> This is great BTW, thanks!
<slangasek> great leaps forward on multiarch, though this mostly just serves to remind how tall that mountain is
<slangasek> draft proposal for new directory names here: http://wiki.debian.org/Multiarch/Tuples
<slangasek> thanks to wookey, lool for reviewing
<slangasek> will be submitted to the LSB WG today
<slangasek> ppa containing multiarchified library packages here: https://launchpad.net/~vorlon/+archive/multiarch/+packages
<slangasek> due to the change in library paths vs. the preliminary multiarch support that was already in eglibc, there's a two-stage bootstrapping process to build everything for multiarch
<slangasek> first turn the new paths on in gcc; then use the paths in eglibc; then rebuild gcc to install libgcc to the new path
<slangasek> and I found a great new way to break a ppa
<wookey> erk, painful
<slangasek> if there's a new upload of eglibc to the main archive that replaces yours, and libstdc++ disappears from the system path as a result, apt-cache doesn't work so well anymore
<wookey> is that all in the package scripts, or a manual effort currently?
<slangasek> so I'm actually currently rebootstrapping the libraries there, but that will be done today and in the future I'll have the good sense to move packages around instead of doing a rebootstrap from scratch each time eglibc updates
<hrw> what if I will have own ld.so.conf?
<lool> slangasek: maybe you'd have less pain with backports to maverick? it seems there is a bit of both in the PPA
<slangasek> hrw: eglibc for each arch installs /etc/ld.so.conf.d/$arch.conf; as long as your ld.so.conf has the include line, it will work
<slangasek> lool: transient pain, I've learned my lesson, and this stuff should all be fast track for inclusion in natty once the paths are settled
<slangasek> so I'm not going to backport
<slangasek> wookey: sorry, package scripts vs. manual effort, I don't follow?
<slangasek> each lib package needs a patched debian/rules to DTRT
<slangasek> anyway, dpkg support for *installing* multiarch packages side-by-side isn't in that ppa; that's still being worked on upstream, good progress, still planning to get something in the archive before feature freeze
<slangasek> and I've been finding and filing bugs against the apt multiarch implementation now that there's something to run it against
<slangasek> so yeah, generally converging
<slangasek> any questions, now that I've overrun us another 10 minutes?
<slangasek> [LINK} http://wiki.debian.org/Multiarch/Tuples
<slangasek> [LINK] https://launchpad.net/~vorlon/+archive/multiarch/+packages
<wookey> we could talk about multiarch roadmap for ages, but not here, now
<slangasek> [TOPIC] AOB
<slangasek> anything else before we all go back to porting (hint,hint)?
<ppearse> Not from me
Meeting closed at 17:22
Platform/DevPlatform/Meetings/2011-02-16 (last modified 2011-03-16 15:22:29)