[09:51] <JamieBennett> Anyone around to take a look at a boot chart output from the ARM live-cd? Casper is the obvious cause of major slowness and I've documented it at https://wiki.ubuntu.com/ARM/LiveCDSpeedup#Casper, after Casper I can't see many worth-while wins though. Link - https://wiki.ubuntu.com/ARM/LiveCDSpeedup#BootChart
[09:53] <ogra> looks like adduser and the keyboard stuff are the worst
[09:54] <JamieBennett> ogra: yeah, all due to debconf-communicate
[09:54] <ogra> adduser is taking 10sec !
[09:54] <ogra> err
[09:54] <ogra> 30, sorry
[09:55] <persia> JamieBennett: Did you ever track down precisely why debconf-communicate is acting so slow?
[09:55] <ogra> JamieBennett, try adding a sscript that calls debconf-coomunicate
[09:55] <JamieBennett> ogra, persia: done and the findings are on the wiki page I liked to.
[09:55] <ogra> something that sets only one value and see if that also uses 30sec
[09:56] <ogra> i suspect thats a fixed value we see there
[09:56] <persia> JamieBennett: Hrm?  In the "Conclusion" section, or somewhere else?
[09:56] <ogra> i.e. each call to debconf adds 30sec
[09:56] <persia> I'm seeing clear indication that it *is* debconf-communicate, but I still don't understand why there is a performance skew when compared to other architectures.
[09:57] <JamieBennett> ogra: each call to debconf-communicate takes 4 seconds due to loading templates.dat via perl code
[09:57] <ogra> what about the other 26 ?
[09:57] <JamieBennett> ogra: where are you getting 30 secs from?
[09:58] <ogra> oh, i only looked at the kbd stuff, adduser simply calls it multiple times
[09:58] <JamieBennett> Yes - https://wiki.ubuntu.com/ARM/LiveCDSpeedup#19keyboard
[09:58] <ogra> well, twice actually
[09:59] <JamieBennett> ogra - 5 times - casper-preseed calls debconf-communicate
[09:59] <ogra> i only see it twice in adduser
[09:59] <ogra> at least in the chart
[10:00] <persia> ogra: The detailed breakdown of the adduser case is above.
[10:00] <ogra> above what ?
[10:00] <persia> a 7-sec call to debconf-communicate, wondering about in user-setup-apply (which talks to debconf a lot), and then a final 4 seconds in another debconf-communicate.
[10:00] <persia> Above the chart on the wiki page.
[10:01] <JamieBennett> ogra: are you talking adduser or keyboard?
[10:01] <ogra> adduser
[10:01] <ogra> only looking at the bootchart
[10:01] <JamieBennett> ah, yes thats two calls
[10:01] <JamieBennett> keyboard is 5
[10:01] <ogra> the chart shows only one very long one
[10:02] <persia> JamieBennett: Are you *sure* there's no debconf-communicate in user-setup-apply?  I thought I remembered a fair bit.
[10:02] <ogra> for kbd
[10:02] <JamieBennett> persia: maybe, I can investigate.
[10:02] <asac> ogra: persia: so continuing discussion on the our ACTION to document what needs to be backported from .32
[10:02] <ogra> right
[10:02] <asac> to .31 kernel
[10:02] <ogra> i see aufs and apparmor as critical
[10:02] <persia> JamieBennett: What I'm most curious about is *why* perl is so slow at reading that cache on armel.  I suspect there's a deeper bug that would be nice to address with lots of improvements all over.
[10:02] <asac> how should we do this
[10:02] <asac> ?
[10:03] <asac> do we already know the areas where we need backports?
[10:03] <ogra> make a list of kernel features we knoe
[10:03] <ogra> *know
[10:03] <asac> akk?
[10:03] <asac> all?
[10:03] <asac> that feels bad ;)
[10:03] <ogra> no
[10:03] <JamieBennett> persia: lool had some thoughts about perl slowness, I'll talk to him to see if he has investigated it at all
[10:03] <ogra> all that are developed inhouse
[10:03] <asac> ok brainstroming :)
[10:03] <asac> you say aufs and apparmor ...
[10:03] <persia> Could we simply compare the kernel-generated header files for .31 and .32, and backport stuff where the API has changed?
[10:03] <asac> i remember persia mentioned ureadahead or something
[10:04] <ogra> ogra@osiris:~/Desktop/uboot/package/uboot-imx-2009.08$ ls /lib/modules/2.6.31-14-generic-pae/kernel/ubuntu/
[10:04] <ogra> aufs  compcache  dm-raid4-5  drbd  iscsitarget  lenovo-sl-laptop  lirc  misc  ndiswrapper  rfkill
[10:04] <persia> Mine were more userspacey, like ALSA and bluetooth.
[10:04] <ogra> i guess we can ignore the lenovo stuff :)
[10:04] <ogra> and ndiswrapper
[10:04] <asac> so why are we looking at kernel/ubuntu only?
[10:05] <ogra> we dont
[10:05] <persia> asac: How do you mean?
[10:05] <ogra> but thats the easy and obvious part
[10:05] <asac> yeah
[10:05] <asac> ok
[10:05] <ogra> we surely need to add stuff that happens inline in the kernel, plus what persia said
[10:06] <ogra> though i think the alsa HW specific stuff isnt that intresting
[10:06] <ogra> we dont need intel fixes on arm :)
[10:06] <persia> What is interesting is keeping sync between userspace and kernelspace interfaces.
[10:06] <asac> persia: we could check the header approach, and see if we get useful results.
[10:06] <ogra> right
[10:06] <persia> I don't care about the individual bits of hardware, but I do care if something moved in ALSA, and sound doesn't work.
[10:07] <persia> Most ARM hardware should be using ASoC anyway.
[10:08] <persia> asac: To do that, should we generate linux-headers-2.6.31-foo out of the ARM kernel sources, or do you think there are other sources of API changes?
[10:08] <asac> hmm. are linux-headers really the headers exported to userspace?
[10:09] <asac> not linux-libc-dev ?
[10:09] <persia> Well, both are exposed, actually.
[10:09] <asac> really?
[10:09]  * persia goes to read up on stuff
[10:09] <asac> i thought linux-headers was just for kernel modules
[10:10] <asac> apt-cache show linux-libc-dev
[10:10] <ogra> stop ...
[10:10] <persia> Right.  Sorry.  I was confused by "linux-kernel-headers" which was an old name for linux-libc-dev
[10:10] <asac>  This package provides headers from the Linux kernel.  These headers
[10:10] <asac>  are used by the installed headers for GNU glibc and other system
[10:10] <asac>  libraries. They are NOT meant to be used to build third-party modules for
[10:10] <asac>  your kernel. Use linux-headers-* packages for that.
[10:10] <ogra> we had that discussion multiple times
[10:10] <ogra> thats a kernel team job
[10:11] <asac> ogra: what do you mean?
[10:11]  * ogra tries to find the mail with the discussion about linux-headers vs libc-dev
[10:12] <ogra> asac, armel is a special case
[10:12] <ogra> and it took us weeks to agree on a specific setup everybody was happy with
[10:13]  * persia isn't entirely convinced it's safe to special-case headers against which userspace is built.
[10:13] <ogra> i know apw summarized it, i cant find it atm
[10:14] <ogra> persia, i think we need to use linux-kernel-headers-*SoC* for our stuff iirc
[10:15] <ogra> but i need the notes
[10:15] <apw> the email was titled
[10:15] <apw> Subject: arm headers issue
[10:15] <persia> apw: To which list was it sent, and about when?
[10:15] <persia> Anyway, I thought linux-libc-dev *replaced* linux-kernel-headers some time back.
[10:16] <apw> it was sent to a few people direct
[10:16] <persia> Ah, tricky those.
[10:16] <ogra> apw, gracias, got it
[10:16] <ogra> asac, forwarding to you
[10:16] <apw> i don't recall it being contentious, just not interesting to the general reader in the raw form it was
[10:17] <ogra> yeah
[10:17] <ogra> but important knowledge if you work on armel
[10:17] <ogra> and surely important to know for asac who became our fearless tech lead now ;)
[10:17] <persia> But the summary was that there are linux-kernel-headers-${SoC} packages being built that are just like linux-libc-dev except for the different ARM kernels?
[10:18] <ogra> persia, forwarded to you too
[10:18]  * persia likes smart search tools that automatically update
[10:20]  * persia is still confused
[10:20] <persia> Is this just about arm-specific headers, or *all* headers?
[10:21] <ogra> arm
[10:21] <apw> its presumably about apps needing vile arm specific driver headers
[10:21] <persia> That's completely different from what I'm looking for.  Let's call that solved for now (for all that I think it's a bit of a mess)
[10:21] <ogra> right
[10:22] <persia> I was looking to compare linux-libc-dev from the SoC kernels to linux-libc-dev in the master kernel.
[10:22] <persia> Where those differ, we have a candidate problem.
[10:22] <ogra> persia, that counts in SoC specific userspace API libs
[10:22] <persia> Right, I don't care about backporting any of that stuff.
[10:22] <ogra> right, you cant
[10:22] <persia> right :)
[10:23] <ogra> since linux-libc-dev on armel comes from the main source
[10:23] <apw> linux-libc-dev for armel ... what he said
[10:23] <persia> Right, so like I said, shall we have the SoC kernel sources provide linux-libc-dev-${SoC} for comparison purposes?
[10:23] <ogra> apw, hmm, how do you handle that with the .32 vs .31 issue btw ?
[10:23] <persia> And then if we find discrepancies, backport what we need.
[10:23] <ogra> persia, no
[10:23] <persia> Why not?
[10:23] <ogra> read the mail :)
[10:24] <ogra> colin will slay you
[10:24] <apw> ogra, we don't
[10:24] <persia> This is *completely* unrelated to the mail.
[10:24] <persia> The mail is about SoC-specific headers.  I'm talking about general headers.
[10:24] <persia> I don't expect them to be used by anything: I just want them for reference.
[10:24] <persia> If anything builds against them, we failed.
[10:24] <ogra> apw, evil ... what if vendors build stuff based on linux-libc-dev ? it will likely be boroken
[10:25] <persia> We can put ***DON'T USE THIS***  **YOUR APPLICATION WILL FAIL*** in the description.
[10:25] <apw> arm is in a world of pain by refusing to be at the same version as the rest of the system
[10:25] <apw> we are assuming some level of compatibility between releases and literally crossing everything
[10:25] <persia> apw: Well, we're hoping to avoid some of that with backporting.  For instance, backporting ALSA should be relatively painless.
[10:26] <apw> its already backported for non-arm so i assume so
[10:26] <persia> Right :)
[10:26] <ogra> apw, well, i'm more concerned about things like aufs
[10:26] <persia> The trick is to determine what needs to be backported to avoid pain.
[10:26] <ogra> we need it for image builds
[10:27] <apw> i don't think there is any headers for aufs
[10:27] <ogra> how about apparmor
[10:27] <persia> ogra: So, what objection do you have to comparing the generated linux-libc-dev for each kernel type?
[10:27] <apw> included in the linux-libc-dev package
[10:27] <ogra> persia, there is no linux-libc-dev for each kernel type
[10:27] <persia> But there could be :)
[10:27] <apw> not sure we include those either
[10:27] <ogra> ther is only one and that comes from the upstream source
[10:28] <ogra> and the archive admin team is strictly against having more than one
[10:28] <persia> Fine.
[10:28] <ogra> read the IRC discussion in the mail
[10:28] <apw> we can't have more than one, as the archive can only be built for one armel form
[10:28] <persia> I did.  You aren't understanding what I'm saying.  I'm not talking about the same thing from the mail.
[10:28] <apw> and its that process that consumes the package
[10:28] <persia> But I don't care to argue that: I'll find a workaround.
[10:29] <apw> have we hit an issue with our assumptions here, or are we worryng about the future
[10:29] <persia> apw: We've lost track of the discussion.
[10:29] <persia> The agenda item was to try to identify what shoud be backported into .31 kernels to make sure lucid works with them.
[10:30] <persia> Our inital guess was  aufs  compcache  dm-raid4-5  drbd  iscsitarget  lirc  misc rfkill + alsa + bluetooth
[10:30] <ogra> whateve misc is
[10:30]  * ogra takes a look in the dir
[10:31] <ogra> /lib/modules/2.6.31-14-generic-pae/kernel/ubuntu/misc/fsam7400.ko
[10:31] <ogra> description:    SW RF kill switch for Fujitsu Siemens Amilo M 7400
[10:31] <apw> my understanding is that aufs is 'compatible' between the two semantically
[10:31] <ogra> not for us
[10:31] <apw> apparmor userspace i believe is aware it may be using two differenet kernels
[10:32] <persia> apw: We've had a lot of issues with aufs version skew in the past, and have little trust.
[10:32] <ogra> apw, right, but we need to make sure that all the inhouse developed features the kernel team develops work
[10:32] <ogra> thats why my main issues are aufs and apparmor ... but you answered for both, so i personally am happy
[10:32] <ogra> compcache and dmraid are surely also important to have working
[10:33] <ogra> not sure about lirc rfkill or iscsitarget
[10:33] <persia> rfkill is likely useful, as lots of devices have wireless.
[10:34] <ogra> but do they have the HW that supports rfkill ?
[10:34] <persia> lirc falls into the alsa/bluetooth category for me: if we don't do it, classes of devices won't work.
[10:34] <ogra> the babbage doesnt have wireless per se
[10:34] <ogra> and we actually only talk about babbage here
[10:34] <ogra> dove is on .32
[10:35] <ogra> did we lose asac ?
[10:36]  * persia installs wireless-tools to see if rfkill works on at least one i.MX51-based device
[10:37] <asac> no
[10:37] <asac> reading thta long mail atm ;)
[10:37] <asac> so from what i understand comparing headers doesnt make sense
[10:38] <asac> its supposed to be not broken in that way
[10:38] <asac> so lets focus on the core ideas we had:
[10:38] <asac> a) figure out which "ubuntu" features were added in .32/lucid
[10:38] <asac> -> review and make a list of what parts we want from those
[10:39] <persia> Erm, what?
[10:39] <ogra> right
[10:40] <asac> b) try to find some good targets to look closer:
[10:40] <asac>  e.g. what kernel improvements were done for boot perf.
[10:40] <ogra> which of them didnt go upstream
[10:40] <asac>  -> and check if we need those ->
[10:40] <ogra> we surely do
[10:41] <ogra> unless we stop caring about bootspeed suddenly
[10:41] <asac> ogra: didnt go upstream in .31 ... given that we had .31 in karmic, nothing went upstream for us (fsl)
[10:41] <asac> that was done in lucid
[10:41] <ogra> right
[10:42] <asac> i double checked with dtchen back at UDS ... he said, that sound wont be a problem in that we will see regressions over karmic experience
[10:42] <asac> ...however, we might not see improvements obviously ...
[10:42] <asac> but i think we can live with that
[10:42] <ogra> yeah
[10:42] <ogra> as long as noise still comes out of the speakers :)
[10:42] <asac> so lets scratch sound from the backporrting candidates unless we find real bugs
[10:42] <asac> right
[10:43] <asac> QA would hopefully catch that
[10:43] <persia> Note that he has already backported the latest ALSA stuff to .31 in a PPA, so it should be fairly painless to integrate.
[10:43] <asac> if fixes are available we are probably happy to pull them in
[10:43] <asac> -> lets note that as an option/action
[10:44] <asac> do we know anything besides boot performance kernel changes and sound?
[10:44] <ogra> apw, what looks important to me wrt bootspeed are the patches from csurbhi
[10:44] <ogra> apw, do you see any issues with these to go into a .31 tree ?
[10:45] <asac> cooloney: there?
[10:45] <asac> cooloney: what ubuntu specific kernel stuff that is in .32 wont be in our .31 kernel?
[10:46] <asac> maybe we automatically get everything?
[10:46] <apw> ogra, those were pretty simple patches, but do we have a bootspeed issue on arm?
[10:47] <ogra> apw, bootspeed is always an issue, yes
[10:47] <persia> Well, looking at the bootchart we were discussing earlier, we're running at somewhere under 195 seconds right now.
[10:47] <ogra> apw, if we have any improvement in the main distro they should definately go into arm
[10:47] <ogra> persia, thats livefs :)
[10:47] <persia> ogra: So? :)
[10:47] <ogra> my babbage boots lucid in about 50sec
[10:47] <persia> Still, a fairly long time.
[10:47] <ogra> or 45
[10:47] <ogra> yes, but not 195 :)
[10:48] <ogra> lets stay with apples vs apples
[10:48] <persia> But yeah, we'd like that faster.
[10:48] <asac> i agree that the kernel tweakage currently done for i386 is not really our major concenr
[10:49] <asac> but i hope we get the big time consumers removed and then it might be more important
[10:49] <ogra> asac, even if it gains us several seconds in bootspeed ?
[10:49] <asac> so being prepared is good
[10:49] <persia> My concern is things not working because of kernel/userspace interface changes, more than small improvements.
[10:49] <ogra> bootspeed is definately a vendor concern we har all the time
[10:49] <persia> Small improvements are nice, but the kernel is outdated, and deserves to suffer a bit.
[10:49] <ogra> *hear
[10:50] <asac> persia: i dont think we can understand that up-front fully.
[10:50] <asac> we can only figure that out through bugs later on
[10:50] <asac> ogra: yes. but we have 195 secdons. most of that is probably not related to anything done in the .32 kernel
[10:51] <asac> which is tuning it to get the last few seconds removed from i386
[10:51] <ogra> asac, yes, but the 195sec are live images
[10:51] <ogra> asac, has nothing to do with this discussion
[10:51] <persia> asac: Well, hrm.  I have suspicions about stuff like bt, alsa, lirc, ieee1394, etc.  We had lots of issues with intrepid when the version skewed unexpectedly.
[10:51] <persia> But I'm not sure our test coverage is broad enough to catch all that (because it wasn't for i386 for intrepid)
[10:51] <asac> persia: dtchen said alsa isnt a problem for older kernels
[10:51] <ogra> asac, the 45-50 sec for instealled systems *are* an issue for this discussion though
[10:52] <asac> ogra: yes. but live image is similarly important. thats the first impression users get
[10:52] <persia> asac: Does that presume a separate alsa-modules package?
[10:52] <asac> ogra: not really sure where the problem is. i am all for looking at what was done and what can be pulled into .31 for bootspeed
[10:52] <ogra> asac, but they are no kernel related issues
[10:53] <ogra> asac, right ... i'm only talking about the installed system here ... the live issues are all casper related
[10:53] <asac> ogra: right. but did we analyze our 45 seconds on installed images yet?
[10:53] <ogra> nope
[10:53] <asac> maybe its half of the time in something similar
[10:53] <ogra> nope
[10:53] <persia> Um, those two "nope"s are mutually exclusive: without analysis there's not enough information for the second answer.
[10:53] <asac> you say that userspace is well tuned?
[10:53] <ogra> we dont call things like debconf-communicate anywhere in installed systems
[10:54] <asac> ogra: still. for me its currently a blackbox
[10:54] <asac> also on liveimages only 50 seconds or so are deconf-communicate
[10:54] <ogra> http://people.canonical.com/~ogra/babbage2-karmic-20090916-3.png
[10:54] <ogra> there is a karmic bootchart
[10:55] <persia> Well, more than that.  there's about 35 seconds in just 10adduser and 19keyboard
[10:55] <ogra> speed issues there are totally unrelated to the speed issues on the live boot
[10:55] <asac> anyway. thats not the point
[10:55] <persia> No.
[10:55] <ogra> right
[10:55] <ogra> but what i say is that we want kernel improvements backported if they can gain us a few secs
[10:55] <asac> ogra: how can you say that its unrelated without having analysed it
[10:56] <asac> anyway, as you might know JamieBennett is our boot speed master this cycle ;)
[10:56] <persia> I think we should be focusing on SoC-specific performance enhancements with SoC-specific kernels, rather than worrying about backporting.
[10:56] <ogra> i.e. if we can get from 41 to 31 secs through them ... plus gain another 5 secs through ureadahead that is definately something we want
[10:56] <JamieBennett> :)
[10:56] <asac> so maybe he should take the action to work on it ... including figuring what kernel parts would be beneficial
[10:56] <ogra> asac, ++
[10:56] <asac> ok. lets do that then. doesnt make sense to speculate
[10:56] <persia> Indeed.
[10:57] <ogra> asac, i have analyzed it in so far that i took bootcharts every release
[10:57] <ogra> but didnt have any time to look for possible improvements or to dig deeper
[10:57] <persia> Do we run any perl during boot?
[10:57] <asac> so bootspeed is covered ;) ... JamieBennett will work with whoever want to peer on that on a) identifying kernel patches to backport, b) identifying userspace bottlenecks in both: install and live image
[10:58] <JamieBennett> OK
[10:58] <JamieBennett> /me scrambles to read backchat to see what I have volunteered to do
[10:58] <ogra> JamieBennett, so please talk to csurbhi, if it makes sense to backport their patches to us
[10:58] <asac> JamieBennett: basically the last line i said ;)
[10:58] <ogra> s/their/her/
[10:58] <JamieBennett> ogra: OK
[10:58] <asac> 11:57 < asac> so bootspeed is covered ;) ... JamieBennett will work with whoever want to peer on that on a) identifying kernel patches to backport, b) identifying  userspace bottlenecks in both: install and live image
[10:58] <persia> JamieBennett: IN summary: analyse bootspeed of installed armel systems, compare against other architectures, and optimise.
[10:58] <JamieBennett> yep
[10:58] <ogra> thats a tough comparison :)
[10:58] <persia> Yep :)
[10:59] <ogra> given your HW is likely slowing it down
[10:59] <ogra> like disk etc
[10:59] <ogra> but well
[10:59] <persia> Well, but simple HW issues scale, but if most stuff is 2x and one thing is 10x, that thing needs attention.
[10:59] <ogra> lets go back to the actual discussion
[10:59] <asac> i dont think we can really compare it
[10:59] <asac> maybe to identify stuff that takes relatively long
[10:59] <asac> ok ... so lets move on ... bootspeed is covered ;)
[10:59] <persia> Right.  That's the extent of the potential for comparison.
[11:00] <asac> now ... areas of potential userspace breakage:
[11:00] <asac> mentioned were:
[11:00] <persia> For *-modules, we just have to make sure that it can be built properly.
[11:00] <ogra> as apw said, aufs and apparmor should just work
[11:00] <asac> alsa, bt,  lirc, ieee1394
[11:00] <ogra> dmraid
[11:01] <asac> i can take the action to sync with jdstrand on what innovation we might want for apparmor
[11:01] <asac> (and whoever does that on kernel side )
[11:01] <ogra> compcache (very important)
[11:01] <asac> whats your concerna bout compcache?
[11:01] <persia> rfkill drdb ?
[11:01] <asac> general breakage i presume?
[11:01] <ogra> yes
[11:02] <asac> we are currently at "user space brekage";)
[11:02] <ogra> we should have the same upstream version in .31 lucid as in .32 lucid x86
[11:02] <asac> isnt compcache covered by kernel/ubuntu investigation?
[11:02] <ogra> since the live images 100% rely on it working
[11:02] <ogra> yes, its in kernel/ubuntu
[11:02] <asac> which i had hpoed we could put on cooloney's plate ... mission: get as many goodies for ubuntu specific stuff from .32 to .31 as possibe
[11:02] <ogra> right
[11:03] <asac> ok .... so lets assign this action to him.
[11:04] <asac> a) make a list of stuff that changed for kernel/ubuntu in .32
[11:04] <ogra> ok, that only leaves sound and apparmor
[11:04] <asac> apparmor i took the action to check what innovation we might want
[11:04] <ogra> right
[11:04] <persia> sound is likely mostly safe to leave alone.  People who *really* care can get modules separately.
[11:04] <asac> sound was already covered imo, but i can also check with dtchen directly what he thinks should be done
[11:05] <asac> if he has patches ready for consumption that are safe, i dont see why we should not pick them
[11:05] <persia> Heh.  590 headers files differ between linux and linux-fsl-imx51
[11:05] <asac> ;)
[11:06] <ogra> right, so: bootspeed->Jamie, kernel/ubuntu -> cooloney, sound-> dtchen, apparmor -> asac ...
[11:06] <ogra> anything we forgot ?
[11:06] <persia> Lots of drm changes: we don't care about any of that, right?
[11:06] <ogra> unlikely
[11:06] <persia> bt, lirc
[11:06] <ogra> lirc is in kernel/ubuntu
[11:06] <asac> ogra: sound -> asac (with dtchen)
[11:06] <ogra> right
[11:06] <ogra> persia, so do yu take bt ?
[11:07] <persia> Sure, although I'm going to be limited to source-inspection.  I may have to lean on others to help with any testing.
[11:07] <ogra> well, grab a kernel guy for help :)
[11:07] <asac> for now we want to investigate
[11:07] <asac> and then we meet after alpha-2 to discuss the final actions i guess
[11:08] <asac> and present results
[11:08] <ogra> yep
[11:08] <ogra> well, some bits need to happen pre A2
[11:08] <asac> is there any area that we know is currently breaking us?
[11:08] <ogra> at least aufs needs to work
[11:08] <ogra> no, we dont
[11:08] <asac> e.g. is anthing of the above urgent for a2
[11:08] <ogra> since we havent seen te3h .31 kernel yet
[11:08] <asac> ok... aufs is kernel/ubuntu
[11:08] <asac> anything else?
[11:09] <ogra> we can do definitive stuff only if we actually have the new kernel
[11:09] <asac> ogra: why arent we seeing issues with aufs now if its needed for a2?
[11:09] <ogra> well, as apw said, it shouldnt have issues
[11:09] <asac> for now, lets hope that stuff that works atm, will work with the new kernel
[11:09] <asac> right
[11:10] <ogra> but you cant say until you see the real thing :)
[11:10] <asac> we are talking about actions and urgencies, so fixing aufs is not urgent until we know its broken :)
[11:10] <asac> sure
[11:10] <ogra> we are talking about hypothetical stuff atm
[11:10] <persia> Seems that linux-fsl-imx51 headers are rather different for bluetooth :(
[11:10] <asac> but i would hope that all stuff urgent enough for a2 target would be breakage of images
[11:10] <asac> and would be covered by all other mechanims
[11:11] <asac> ogra: yes. thats why i dont think that anything of the stuff we talked about has to happen for a2 atm
[11:11] <persia> I'd agree that urgent stuff would be covered in other ways.
[11:11] <asac> until we get to know of breakage ;)
[11:11] <ogra> right
[11:11] <persia> This is more that we need to be solid pre-beta, and need a head start.
[11:11] <asac> what we are doing here is an proactive effort to improve the overall quality of our final release
[11:11] <asac> yep
[11:12] <asac> persia: want to send out actions we deferred from this with me/ogra/jamie CCed?
[11:12] <asac> and colooney
[11:13] <persia> Why CC, rather than addressee?
[11:13] <asac> hehe
[11:13] <asac> yes. TOed
[11:13] <persia> Sure, although I want to dig out of my current stack of stuff first.
[11:14]  * asac wonders what that is ;)
[11:14]  * ogra hands persia a ladder
[11:14] <asac> my current stack of stuff == all the clothes that wait for a laundry here ;)
[11:15] <asac> or rather: my board buried under heaps of dirty socks ;)
[11:15]  * persia has ~20 windows opened during this discussion that need to be closed after extracting the key bits while knowledge is fresh: actions are logged in lots of places to grab in some minutes.
[11:15]  * ogra fights with uboot
[11:15] <asac> most likely those 20 windows opened on the sharp thing ;)
[11:15] <ogra> lol
[11:16] <persia> No, only 4 windows on the Netwalker during the past hour discussion :p
[11:16] <persia> (mostly terminals to check stuff)
[11:19] <asac> anyone running lucid already?
[11:19] <asac> on main desktop?
[11:19] <asac> is sound working?
[11:19]  * asac scared that voip/softphone will be completely brokenish when i upgrade now ;)
[11:19] <persia> Should be: lots of people report that it is.
[11:20] <persia> Try a liveCD first :)
[11:20] <ogra> asac, cjwatson upgraded on monday i think
[11:21] <ogra> no idea if he uses any VoIP though
[11:25] <asac> most likely not. i have the feeling i am the only one, given how broken all softphones are ;)
[11:25] <asac> at least for real callout voip
[11:25] <asac> most apps seems to close the sound stream and open quickly when the call gets dispatched ... this yields random on/off for output/input for the final connection
[11:26] <asac> if you use pulse
[11:26] <persia> ogra: Am I reading backscroll correctly that you're not researching anything?
[11:26] <asac> ogra will be peer for boot performance and the kernel/ubuntu stuff
[11:26] <ogra> i said i didnt
[11:26] <persia> asac: pulse and ekiga always work nicely together for me.  Dunno which softphone you use.
[11:26] <ogra> simply because it was to late in the former releases to do anything about it anyway
[11:26] <JamieBennett> asac: lucid killed my laptop yesterday
[11:26] <asac> persia: ekiga is really really busted ;)
[11:27] <JamieBennett> won't boot now
[11:27] <ogra> we had no kernels until mid release
[11:27] <asac> persia: are you doing callout?
[11:27] <persia> asac: Define "callout".
[11:27] <ogra> persia, i'm happy to help researching this round
[11:27] <asac> odd. then its probably sound chip related
[11:27] <asac> ekiga also crashes regularly
[11:27] <asac> also i cannot tell ekiga to use a stun server
[11:28] <asac> just doesnt have that config field
[11:28] <persia> Odd.  It worked for me last I tried it, which was a bit ago.
[11:28] <persia> You can get to that through the config wizard.
[11:28] <asac> stun?
[11:28] <asac> thats not there
[11:28] <asac> for sure
[11:28]  * ogra considers breakfast a good thing and tries to find some food
[11:28] <persia> But each and every sound chip (and subcomponent of sound chips) acts differently weirdly, so yes, likely :)
[11:28] <asac> i wasted so much time in ekiga/linphone/twinkle that i am quite sure you cannot confiugre a stun server in ekiga
[11:30] <persia> http://wiki.ekiga.org/index.php/Ekiga_behind_a_NAT_router
[11:30] <persia>  gconftool-2 -s /apps/ekiga/general/nat/stun_server stun.ekiga.net --type=string
[11:31] <persia> (replace with your faviorite stun server :) )
[11:31] <asac> hmm. so they have the stun server hard coded
[11:31] <asac> ok
[11:31] <persia> Not hard coded, just not exposed in the UI.
[11:31] <asac> thats hard coded in my book ;)
[11:31] <asac> gconf default without UI
[11:31] <asac> similar to using hexedit to edit the binary ;)
[11:31] <persia> Well, it's *lots* easier to change than when something is behind an #ifdef :)
[11:32]  * persia has played with far too many foo-default-settings packages to completely agree with that.
[11:32] <asac> at least gconf doesnt forget your changes on upgrades ;) ... which hexedit often fails to do
[11:35] <persia> asac: See, you're supposed to hexedit the .deb, and remember to set epoch 47 :p
[11:38] <armin76> ogra: what wifi does the babbage has?
[11:41] <armin76> asac: ^
[11:45] <asac> armin76: baa
[11:45] <persia> armin76: ogra said before " the babbage doesnt have wireless per se", so I presume nothing by default (but add what you like via USB)
[11:45] <asac> board-as-antenna ;)
[11:45] <persia> asac: Do we have a driver for that?
[11:46] <armin76> oh
[11:46] <asac> thats hardware hacking ;)
[11:46] <asac> no driver needed
[11:46] <asac> just jump on a usb wifi dongle and try to wire the antenna up with the board for best results ;)
[11:46] <persia> Ah, so you modulate the local EM potentials to inject data streams directly?
[11:47] <asac> yes, in practice results are much better than the old way of having two antennas in the chassis ;)
[11:47] <asac> its not injecting data streams directly
[11:47]  * persia goes back to kernel archeology
[11:47] <asac> just physical vibration that helps deal with interference ;)
[11:48] <asac> only works if you put the board on your external usb drive ;)
[11:48] <asac> which will soon be the standard
[11:49] <armin76> ojn: did your board got wifi?
[11:49] <armin76> lool: and the lange has wifi?
[11:50] <persia> armin76: What's wrong with USB WiFi off-board, as opposed to on-board?
[11:50]  * persia suspects any consumer device with a battery will likely also have WiFi
[11:51] <persia> Probably USB WiFi, but on-board :)
[11:51] <persia> (given previous reports of USB SATA, onboard, etc.)
[11:51] <armin76> persia: nothing, i'm just asking
[11:51] <armin76> the efika mx has wifi...i'm not sure if it was usb or not...let's see...
[11:52] <armin76> it doesn't work though(thats why i'm asking)
[11:52] <persia> Those are temping little boxes.
[11:52] <persia> armin76: Which device is it?
[11:52] <asac> what else would it be if not usb?
[11:53] <persia> asac: GPIO?
[11:53] <persia> Or even native (although I'd prefer a subprocessor for that sort of thing)
[11:53] <shenki> SDIO
[11:54] <armin76> persia: wifi device you mean?
[11:54] <persia> armin76: Yeah.
[11:54] <armin76> oh, i'm stupid
[11:54] <armin76> well, i just woke up, its expected :P
[11:54] <shenki> that's the direction olpc has taken with the 1.5, the first revision used USB but USB takes too long to come out of suspend
[11:54] <armin76> its a ralink 3070usb
[11:54] <armin76> so yes, its usb :P
[11:54] <armin76> persia: thanks for asking *g*
[11:55] <persia> armin76: Not the one I have a driver for then.  Sorry.  I have ks79xx_sdio
[11:55] <persia> Which reminds me, SDIO is *much* more likely than GPIO.
[11:57] <persia> armin76: http://wiki.debian.org/rt2870sta claims to support 148F:3070, so there might be something extractable.
[11:57] <persia> Dunno if it works properly on armel :)
[11:58] <armin76> persia: the kernel is 2.6.31, and has support for the 2870, and thats what i built
[11:58] <armin76> it detects it and stuff, but doesn't find any ap
[12:01] <persia> That's extra annoying.
[12:02] <armin76> well, i consider more annoying that if you do a reboot, it halts, and if you do a halt, it reboots :P
[12:04] <asac> armin76: running ubuntu?
[12:04] <asac> ;)
[12:04] <armin76> it came with ubuntu yes, but mkfs.ext3 is my friend :P
[12:04] <asac> the wifi worked in ubuntu?
[12:04] <armin76> didn't try
[12:04] <asac> debian is known to not care much about wifi ;)
[12:04]  * asac *cough*
[12:05] <armin76> Hostname: efikamx - OS: Linux 2.6.31-ER1/armv7l - Distro: Gentoo 1.12.13 - CPU: ARMv7 rev 1 (v7l) - Processes: 78 - Uptime: 12d 15h 45m - Users: 3 - Load Average: 2.46 - Memory Usage: 109.81MB/470.49MB (23.34%) - Disk Usage: 22.61GB/461.20GB (4.90%)
[12:05] <asac> try our kernel
[12:05] <asac> oh wait ;)
[12:05] <asac> hehe
[12:05] <asac> armin76: are you using NM+wpasupp?
[12:06] <armin76> wifi is not a priority for me, i love eth0
[12:06] <armin76> asac: no desktop at all
[12:06] <asac> NM works well without desktop
[12:06] <armin76> i simply tried iwlist wlan0 scan
[12:06] <asac> i use it for that
[12:06] <asac> as root ;)?
[12:06] <asac> j.k.
[12:07] <asac> i would suggest to try wpasupplicant with nl80211 driver
[12:07] <asac> if thats supported by rt....
[12:09] <asac> JamieBennett: MIRs... how are things blocked atm?
[12:10] <JamieBennett> ok
[12:10] <JamieBennett> ...
[12:10] <asac> all fine?
[12:10] <JamieBennett> 2 MIR's unassigned
[12:10] <asac> you said some MIR was rejected?
[12:10] <JamieBennett> Embryo has concerns from pitti, basically we need to commit to supporting it
[12:10] <asac> whats embryo?
[12:11] <JamieBennett> a package used by edhe
[12:11] <JamieBennett> edje
[12:11] <asac> will it need as much attention as a real baby later ;)?
[12:11] <asac> JamieBennett: i mean: whats its purpose/use-case
[12:11] <JamieBennett> Its a VM that only edje uses
[12:12] <asac> how is that used from a high level perspective? e.g. for what is that used in our launcher stack?
[12:12] <JamieBennett> Upstream says its essential
[12:12] <JamieBennett> its used by edje which is an essential part of our launcher
[12:12] <persia> Isn't that the interpreter for the widget defintions?
[12:13] <JamieBennett> (its part of the design and layout bit)
[12:13] <JamieBennett> themes e.t.c
[12:13] <asac> well. thats not the perspective i mean :)
[12:13] <asac> i want to undersatnd why we need a VM ;)
[12:13] <asac> ah
[12:13] <JamieBennett> FOR EDJE
[12:13] <asac> so what persia said
[12:13] <JamieBennett> ;)
[12:13] <asac> edje doesnt really explain whats it used for ;)
[12:13] <persia> asac: E17 is all about being able to create really cool interfaces.  It takes modularity to a mind-numbing level.
[12:14] <asac> so they invented a scripting language?
[12:14] <persia> For widgets.
[12:14] <JamieBennett> persia: indeed and edje is responsible for all theme, layout, image and font definitions
[12:14] <JamieBennett> to allow layout and animations
[12:14] <persia> Imagine a .desktop file on steroids, and then distill for a few years.
[12:15] <asac> lol
[12:15] <asac> ok
[12:15] <asac> i think i figure
[12:15] <JamieBennett> We also have code concerns about some pacakges
[12:15] <asac> JamieBennett: does that thing have a make check testsuite?
[12:15] <asac> is that run during build time?
[12:15] <JamieBennett> asac: no and upstream aren't planning on one
[12:15] <asac> what are the code concerns?
[12:16] <persia> An embedded turing-complete VM?
[12:16] <JamieBennett> recasting pointers, tty manipulation, the comments are on the MIR bugs
[12:16] <JamieBennett> let me bring them up
[12:17] <asac> thx
[12:17] <JamieBennett> https://bugs.edge.launchpad.net/ubuntu/+source/edje/+bug/489359 - edje
[12:17] <ubot4> Launchpad bug 489359 in edje "[MIR] Main inclusion request for edje" [Undecided,Incomplete]
[12:17] <JamieBennett> https://bugs.edge.launchpad.net/ubuntu/+source/evas/+bug/488923 - evas
[12:17] <ubot4> Launchpad bug 488923 in evas "[MIR] Main inclusion request for evas" [Undecided,Fix committed]
[12:19] <persia> The second one looks done, just waiting for the dep to show up.
[12:19] <JamieBennett> Albin (lutin) is an ubuntu developer as well as upstream
[12:20] <JamieBennett> persia: Albin has expressed concern that he will fix some issues but the code base is moving and may introduce more errors
[12:21] <asac> JamieBennett: so integrating embryo as a pkglib into edje sounds like a feasible approach
[12:21] <asac> like pitti suggested
[12:21] <JamieBennett> could be
[12:22] <JamieBennett> not sure what the best option
[12:22] <persia> I'd be more comfortable following Debian on this, as Debian has close upstream involvement.
[12:22] <persia> If we start significant change in packaging, we may end up out-of-sync in some awkward way.
[12:22] <asac> well. pitti is right
[12:22] <armin76> and debian has asac :D
[12:23] <persia> armin76: Well, yes, but not for E17
[12:23] <asac> persia: we wouldnt drpo the package from universe
[12:23] <asac> just duping code in edje
[12:23] <asac> so edje can go to main
[12:23] <persia> asac: Right, but the duplicated code ends up 1) causing security headaches, and 2) causing a merge lag.
[12:23] <asac> is albin the debian guy?
[12:23] <asac> JamieBennett: ?
[12:23] <JamieBennett> asac: yes
[12:23] <JamieBennett> lutin on freenode
[12:23] <asac> persia: security headaches are worse with it being a public api
[12:24] <asac> i will talk to him ;)
[12:24] <asac> debian shouldnt have this either ;)
[12:24] <asac> as they support everything
[12:24] <JamieBennett> k
[12:26] <asac> in worst case i dont see a big problem with internalizing it
[12:26] <asac> we have a commitment to support it
[12:26] <asac> obviously
[12:48] <ogra> asac, huh ? the babbage only has a mini pci slot you can attach a wlan card to, nothing wlan related on board
[12:49] <asac> ogra: did you read a bit more context ;)?
[12:49] <persia> ogra: There's miniPCI?
[12:49]  * persia is impressed at the growing number of available bus options
[12:49] <asac> pci feels like news to me. previously i was told arm doesnt have busses ;)
[12:49] <persia> ARM has busses, just not usually PCI.
[12:50] <persia> That said, my Orion server has PCI-e, so it's not impossible.
[12:50] <asac> yeah. thats what it boiled down to
[12:50] <asac> we have USB ;)
[12:50] <persia> and SDIO
[12:50] <ogra> persia, well, a mini pci socket ...
[12:50] <ogra> its in fact USB in the backend
[12:50] <ogra> .oO(or are these thigs called micro PCI ? )
[12:50] <ogra> right, i was talking about the socket form factor
[12:51] <persia> ogra: But what *kind* of socket.  You can do either SDIO or USB in a socket.
[12:51] <persia> (and lots of other stuff too)
[12:51] <asac> ogra: miniPCIe is better
[12:51] <ogra> i have the same thing in one of my x86 laptops
[12:51] <ogra> but there its attached to PCI
[12:51] <asac> all wifi cards for notebooks are PCIe nowadays
[12:52] <persia> Um, no.
[12:53] <persia> I purchased a notebook in 2008 with SDIO wifi
[12:53] <persia> And another one in 2009
[12:53] <asac> yes. but no miniPCI (which was the point)
[12:54] <ogra> persia, if i plug in the wifi card i get an usb device in dmesg
[12:54] <ogra> right, miniPCIe is it then
[12:54] <ogra> right
[12:54] <ogra> just a special socket for USB
[12:54] <persia> Well, again no.  The Panasonic toughbook line is *still* miniPCI
[12:54] <persia> miniPCIe != USB
[12:57] <ogra> persia, SATA != USB ...
[12:57] <ogra> persia, still the babbage has both sockets attached to the USB controller
[12:58] <persia> ogra: Sure.  I'm just saying "right, miniPCIe is it then"..."just a special socket for USB" doesn't make sense.
[12:58] <persia> If there's hardware to convert, that's fine.
[12:59] <ogra> well, i have these sockets, but effectively they only offer USB devices
[13:00] <persia> But what kind of socket are they?  What's the line protocol?
[13:01] <ogra> no idea ... i can only judge by the plug :)
[13:01] <persia> how many pins?
[13:02] <ogra> 18+8
[13:03] <ogra> or 36+16 if you count that the board you plug in is double sided
[13:03] <persia> That does sound like miniPCIe.  Odd to stick a PCIe controller on a USB bus.
[13:03] <ogra> well, as odd as sticking a SATA socket on a USB bus
[13:04] <ogra> the board simply has only that one controller
[13:04] <persia> Actually, that makes  a lot more sense.  I use SATA over USB regularly on lots of machines.
[14:36] <armin76> persia: which server is that? :)
[14:40] <asac> what kind of devices are ARMv4 without T?
[14:40] <asac> armin76: ?
[14:40] <asac> does debian support that?
[14:41] <armin76> asac: ARMv4 without T = arm
[14:41] <armin76> armel = eabi, which requires thumb interworking
[14:41] <armin76> which is what T means
[14:41] <asac> k
[14:41] <asac> but what i am interested in is if someone would want to support that for lets say firefox?
[14:42] <armin76> what devices...well, old stuff: netwinder, cats
[14:42] <asac> so probably not
[14:42] <asac> what specs are we talking about there?
[14:42] <armin76> nailboard
[14:42] <armin76> the netwinder is 133mhz/128mb
[14:43] <armin76> Hostname: coral - OS: Linux 2.6.25/armv4l - Distro: Gentoo 2.0.0 - CPU: StrongARM-110 rev 4 (v4l) - Processes: 41 - Uptime: 283d 20h 46m - Users: 1 - Load Average: 0.08 - Memory Usage: 18.36MB/124.01MB (14.80%) - Disk Usage: 15.37GB/35.82GB (42.92%)
[14:43] <armin76> oh
[14:43] <armin76> HP Jornada stuff as well
[14:44] <armin76> the netwinder was a nice device back in 2003
[14:44] <armin76> err, wait
[14:44] <armin76> its 275mhz, not 133 :)
[14:47] <armin76> asac: http://dev.gentoo.org/~armin76/arm/armhw.xml
[14:49] <asac> thx
[14:50] <armin76> thats just a list of hardware ppl at #gentoo-embedded have, its definitely not a list of all ARM hardware
[14:51] <armin76> asac: but anyway the most important armv4 devices are the netwinder, cats, and HP Jornada, but they're pretty old as of now, and debian has deprecated support for it anyway
[14:52] <asac> ok. thats more than enough for now ;)
[14:52] <asac> lets look at the future!
[15:23] <armin76> asac: teh omgz, hows that ubuntu doesn't have latest pixman?! :D
[15:23] <asac> thats X topic
[15:24] <armin76> asac: quick!
[15:26] <armin76> asac: btw i'm not sure if you guys are going to have trouble with pixman on dove, as it gets built with -mcpu=cortex-a8 and -mfpu=neon
[15:26] <armin76> i'm no expert though
[15:27] <armin76> afaik it would fail it if gets built on a dove
[15:28] <asac> it also fails on bbg
[15:28] <asac> we dont use NEON enabled kernels atm
[15:28] <armin76> fails to build or?
[15:28] <armin76> no point in using neon enabled kernels if dove isn't neon :)
[19:36] <ojn> Too bad they didn't announce any kind of dates. But sure, they were first to print a press release: http://www.marvell.com/armada/quadruple_core_arm_instruction_set/release/1363/
[19:39] <armin76> ojn: does your board have wifi? :)
[19:39] <ojn> armin76: which board?
[19:39] <armin76> ojn: nettop
[19:40] <ojn> well, yeah. and it worked in jaunty but not with karmic
[19:40] <ojn> haven't had time to debug it, still have visiting family and a bunch of stuff going on at work
[19:41] <armin76> ojn: ah, i see, i remember about your dmesg :)
[20:49] <tmadsen> Hi. I am using Ubuntu ARM as testing platform on a QEMU emulator. The emulator has 256MB of RAM, but I'm wondering: what are the minimum requirements for running Ubuntu ARM? (CLI only)
[21:10] <Martyn> Afternoon all
[21:10] <Martyn> Who here is most familiar with the PL340 (arm DRAM controller?)
[21:49] <armin76> asac: chromium+v8 built on armv7a, but it still fails on armv5te, i built the latter with debug, this is what it says: http://dpaste.com/141828/
[22:11] <Martyn> armin76: Are you familiar with how to bring up the DRAM controller?
[22:11] <Martyn> the PL340?
[22:15] <ojn> Martyn: Doesn't ARM have the configuration sequence in their documentation?
[22:16] <armin76> Martyn: i wish :/ sorry i can't help
[22:16] <Martyn> ojn : It does, but I'm looking for the code that does so in the linux kernel and not finding it
[22:17] <Martyn> ojn : I'm starting to think the only time the DRAM controller gets touched is during early system boot, in the bootloader...
[22:36] <ojn> well, yeah
[22:36] <ojn> it's hard to configure the memory underneath yourself
[22:36] <ojn> especially since you need DRAM up to load and run linux
[22:36] <ojn> Some ports do re-tuning of parameters, but that's a pretty scary thing to do (OMAP sometimes changes timings)