[06:17] <devilhorns> ogra, around/awake yet ? :)
[06:18] <persia> He's typically a couple more hours.
[06:18] <devilhorns> persia, ahh ok, thanks :)
[06:20] <persia> Find yourself at a loss during the pause-between-cycles?
[06:21] <devilhorns> persia, not at all :) plenty todo wrt unity-efl
[06:21] <devilhorns> persia, but, I do need to discuss something with him
[06:21] <persia> Ah, I can't help with that then.
[06:21] <devilhorns> hehe yea
[06:45] <devilhorns> ogra, when you get online, please drop me a PM. Need to discuss a few things with ya, thanks :)
[07:49] <lag> sebjan: Do you know who Misael Lopez Cruz is?
[08:07] <sebjan> lag: he is a TIer working on audio (don't know if he still works on audio, but at least he used to)
[08:07] <lag> sebjan: Does he still work for TI?
[08:08] <lag> sebjan: I'm wondering if it's worth asking him to the session
[08:11] <sebjan> lag: I don't know... best to ask Liam or Margarita
[08:11] <lag> Sure, thanks
[08:33] <hrw> ehlo #
[09:08] <ndec> ogra: hi... fyi: just sent you an email...
[09:47] <lool> vstehle: http://gitorious.org/croco
[10:11] <suihkulokki> vstehle what do you want to know about it?
[10:46] <kornel`> hi
[10:47] <kornel`> does anyone has some experience of encoding video to h264 on arm processor. with ffmpeg or any other solution (which may use dps as well if necessary, etc) ?
[10:48] <persia> kornel`, What question would you ask if someone replied "Yes" to that?
[10:49] <kornel`> is it possible to encode  a live stream with an arm (with neon) processor realtime? and if so, what quality?
[10:50] <hrw> depends on cpu, method used
[10:50] <kornel`> i would use arm cortex a8
[10:51] <kornel`> how much does dsp matters?
[10:51] <persia> I'm not sure our encoders are NEON-enabled
[10:51] <hrw> kornel`: there is no such cpu as "arm cortex a8"
[10:51] <persia> kornel`, DSP only matters if there are kernel drivers or encoder-specific drivers for that DSP.
[11:01] <ogra> ndec, and i answered it :)
[11:02] <kornel`> ok thanks for answers
[11:02] <persia> kornel`, Just as summary, it's known possible for some chips, at some resolutions.  It's unlikely we have a wide-enough body of experience to tell you whether any specific combination works.
[11:03] <kornel`> persia: right i will buy some and triing :) thanks!
[11:04] <persia> kornel`, Good luck.  My recommendation is to get one from a vendor that has open encoders that are known to meet your application requirements.  The SoC vendors usually are happy to explain just how cool each chip is.
[11:38] <armin76> persia: yeah, like nvidia saying they don't need neon because their soc is awesome :P
[11:39] <persia> armin76, might be though: doesn't it support CUDA or something?
[11:39] <armin76> cuda on arm? weird
[11:40] <vstehle> lool: Thanks!    suihkulokki: I want to try croco on top of qemu/pbuilder, to speedup armel builds on PC. I would like to use the cross-compiler on the PC transparently instead of the qemu/armel gcc. This is to build Ubuntu packages. I have had no luck so far with xdeb. Google did not return much about croco, that's why I asked.
[11:44] <hrw> vstehle: distcc will do work
[11:45] <vstehle> hrw: I thought about that; less setup on PC, but more intrusive on package (need to override the compiler command, I guess).
[11:48] <hrw> or add one dir to PATH
[11:49] <persia> armin76, Why?  the code runs on the GPU anyway: CPU architecture ought be irrelevant.
[11:57]  * hrw -> food
[12:00] <persia> amitk, I had a chance to play with your kernel sources this weekend, but unpacking the 2.6.28 /proc/config.gz and `make oldconfig` still asked me *lots* of questions, including some about which boards to support.  Do you have any recommendations for the config for a Netwalker?
[12:00] <lool> vstehle: You can use the hardening-wrapper trick to workaround this limitation
[12:01] <amitk> persia: start with mx51_defconfig and add compile-in support for the efikamx
[12:01] <persia> amitk, So I don't care about any of the options that were set on the Netwalker for the old kernel/
[12:01] <persia> s:/:?:
[12:02] <amitk> persia: since all the HW doesn't yet work, no we don't care about the netwalker options ATM.
[12:03] <persia> Heh, fair.  I'll try it with the mx51_defconfig, and see what works or doesn't.  if I have screen, keyboard, WiFi, MTD,  and SD, I'm sufficiently happy.
[12:07] <amitk> persia: you'll get serial and ethernet now. The linaro kernel might get the mmc/sd patches too. Wifi is WIP.
[12:08] <persia> Oh.  Since my hardware has no serial or ethernet, that's not very useful.
[12:10] <armin76> persia: what wifi does it have?
[12:14] <persia> armin76, I'm not sure precisely: something that uses "ks7010_sdio"
[12:16] <armin76> yuck
[12:16] <persia> Why?
[12:16] <armin76> just curious
[12:16] <persia> No, why "yuck"?
[12:16] <armin76> ah, its a renesas chipset
[12:17] <persia> And this is bad because ... ?
[12:17] <armin76> oh, because it didn't ring a bell at all
[12:17]  * persia doesn't usually see "yuck" used to mean "never heard of it" and wanders off, no longer concerned
[12:17] <armin76> didn't know that renesas did wifi chips :)
[12:18] <hrw> persia: ks7010_sdio is kernel module?
[12:18] <persia> hrw, No, kernel module is ks79xx_sdio
[12:19] <persia> amitk, Actually, before I give up, are there any tests that I could perform using your kernel that you'd find useful, given no ethernet and no serial?
[12:20] <amitk> persia: probably not, just wait some more to get the rest of the patches in place..
[12:21] <persia> amitk, OK.  Please let me know if I can help with testing, as I'll be able to make time for it fairly freely between now and the beginning of April.
[12:53] <armin76> ogra: does the ac100 have a temperature sensor?
[14:55] <lool> Hmm
[14:56] <lool> I've been looking whether extras.ubuntu.com is disabled on ARM or not
[14:56] <lool> it seems not
[14:56] <lool> does someone confirm that extras.ubuntu.com shows up in sources.list after an Ubuntu install on ARM?
[14:56] <GrueMaster> It isn't in the preinstalled images sources.list, just the live images.
[14:57] <GrueMaster> And yes, I see it on dove.
[14:58] <lool> GrueMaster: Does it work when you apt-get update?
[14:58] <lool> GrueMaster: I'd expect some APT errors
[14:59] <GrueMaster> Yes, I get errors.
[14:59] <lool> GrueMaster: ah, is this reported somewhere already?
[14:59] <GrueMaster> Apparently, it isn't limited to armel.  It was discussed a few days ago on #u-release.
[14:59] <lool> I checked this morning, and saw that the keyring was built on armel, seeded on armel, and that the apt-setup/extras setting was off unless preseeded to true, which is the case in all desktop images
[14:59] <lool> GrueMaster: Ok thanks
[15:00] <lag> o/
[15:00] <ogra> lag, isnt it in 1h ?
[15:01] <lag> UTC != GMT
[15:01] <ogra> (unless date -u lies to me)
[15:01] <ogra> oh, you sheduled it for GMT ?
[15:01]  * ogra thought he read UTC
[15:01] <lag> Same thing
[15:01] <ogra> It will be hosted in #ubuntu-arm on freenode @ 15:00 UTC.
[15:01] <lag> I forget we're in GMT+1
[15:02] <ogra> ogra@osiris:/var/build/images$ date -u
[15:02] <ogra> Di 12. Okt 14:01:59 UTC 2010
[15:02] <ogra> right
[15:02] <lag> Bloodly British and their stupid saving hrs
[15:03] <ogra> heh
[15:52] <ogra> lag, do you have a build with the changes from liam ?
[15:53] <devilhorns> ogra, you get my email ?
[15:53] <lag> ogra: Nope
[15:53] <lag> Bit late to ask now
[15:58] <ogra> devilhorns, yes, need to talk with davidm
[15:58] <devilhorns> ogra, ok, no problem :)
[16:00] <lag> Let's try this again ...
[16:00] <lag> o/
[16:01] <mpoirier> o/
[16:01] <diwic> o/
[16:01] <berco> o/
[16:01] <sebjan> o/
[16:01] <amitk> \o
[16:01] <lag> We have an intruder
[16:01] <lag> ;)
[16:01] <amitk> ;)
[16:01] <lag> lrg: ?
[16:02]  * ogra is here
[16:02] <lrg> lag: here
[16:02] <lag> Then we shall begin
[16:02] <lag> Firstly we need to get everyone up to speed
[16:03] <lag> I'm guessing lrg knows the most about this
[16:03] <lag> Care to give us a rundown?
[16:03] <ogra> do we have rama here ?
[16:03] <lag> Not seen
[16:03] <rsrimushnam> Here
[16:04] <lag> rsrimushnam: Welcome
[16:04] <ogra> perfect :)
[16:04] <lag> ...
[16:04] <lag> ogra: Care to start us off?
[16:06] <ogra> well, we dont really know ehere the issues lie yet, it is clear that sound currently doesnt work at all on the panda (or other omap4 platforms)
[16:06] <lag> I thought we had sound via ALSA?
[16:06] <ogra> there are a) the backend routes not properly set by default
[16:06] <ogra> b) alsa seems to have issues
[16:07] <ogra> (i discussed with crimsun last night and he pointed me to a bug i noted into our bug)
[16:07] <ogra> b might be solved by the SRU crimsun plans
[16:07] <ogra> lag, we do but thats just through a slightly better hack
[16:07] <lag> I know there as been a tussle with userspace and kernel with regard to who's problem it is - has this been answered yet?
[16:08] <lrg> ogra: care to expand on (b)
[16:08] <ogra> though as i understand it, my hack will turn into the default in future alsa (using the init subdir)
[16:08] <lag> (b) is a libalsa issue is it not
[16:08] <lag> Do you have the bug number to hand?
[16:08] <ogra> lrg, i cant expand much more than whats written on the bug, he just told me it would very likely improve things
[16:08] <ogra> bug 652035
[16:08] <ubot2> Launchpad bug 652035 in alsa-lib (Ubuntu) "libasound2 not finding usb sound card (affects: 1) (heat: 6)" [Medium,In progress] https://launchpad.net/bugs/652035
[16:09] <ogra> seems some of the parsing isnt done right
[16:09] <ogra> there is an upstream fix and an additional fix crimsun added
[16:09] <ogra> i wish he could be here now, since he does most of the ubuntu alsa maintenance
[16:09] <lag> It sounds like there are more issues than meets the eye
[16:09] <ogra> but it sadly collides with his work hours
[16:10] <lag> Why do these work on other systems and not OMAP4?
[16:10] <ogra> lag, well, the bug only explains why i have to call alsactl init manually
[16:10] <ogra> which is anyway not the target we want to achieve
[16:10] <berco> Is alsa-utils script call at all? It seems this script resets alsa values and has some cases based on platforms
[16:11] <ogra> berco, yes, it is called properly
[16:11] <ogra> and as i said above, the future of alsa seems to be to use these init scripts
[16:11] <berco> but I don't know if it is called before SDP4430.conf is read...
[16:11] <berco> it could overwrite SDP4430, right?
[16:12] <ogra> berco, i didnt use SDP4430.conf at all
[16:12] <ogra> after boot i have the right mixer settings using my way
[16:12] <diwic> looking at crimsun's patch for 652035 (which I believe I saw upstream as well), it's about not quitting early when finding gaps/holes in the list of subdevices
[16:12] <ogra> but no sound until i call aslactl init
[16:12] <ogra> diwic, so that could be the reason why the extra alsactl init is needed then
[16:13] <ogra> i.e. my scrip should work fine with that fix
[16:13] <ogra> but thats only half the solution
[16:13] <berco> ok. so do we want to fix your way first ogra? or is the purpose of the brainstorm to move away from this method and use SDP4430.conf file?
[16:13] <persia> ogra, Which init script is your script?
[16:13] <ogra> persia, the one attached to our bug
[16:13] <ogra> https://bugs.edge.launchpad.net/ubuntu/+source/linux-ti-omap4/+bug/637947/comments/24
[16:13] <ogra> and
[16:13] <ubot2> Launchpad bug 637947 in linux-ti-omap4 (Ubuntu Maverick) (and 1 other project) "no sound devices on current ES2.0 boards (affects: 2) (dups: 1) (heat: 26)" [High,Confirmed]
[16:14] <ogra> https://bugs.edge.launchpad.net/ubuntu/+source/linux-ti-omap4/+bug/637947/comments/25
[16:14] <ogra> berco, well, my script has two probs
[16:14] <ogra> a) these scripts want more info which the driver doesnt expose atm so we cant really differ between different omap4 boards
[16:15] <ogra> which is indeed bad unless the blaze uses exactly the same setup
[16:15] <persia> Ah, OK.  I thought it was something different :)
[16:15] <ogra> and b) more seriously HDMI doesnt get initialized and exposed to pulse
[16:15] <ogra> imho b) is only solvable through SDP4430.conf
[16:15] <ogra> but that could be a massively simpler one if it goes hand in hand with my init script
[16:16] <ogra> since we dont need to set volumes from the .conf
[16:16] <ogra> for a) we would need to extend the driver to expose more than just the card name
[16:17] <ogra> if you look at /usr/share/alsa/init/hda you can see how you can set different mixers based on the board
[16:18] <ogra> but we would need a mixername
[16:18] <ogra> note that i also havent tried the fix from bug 652035 yet, all this is based on assumptions
[16:18] <lrg> ogra: I could also add the machine name etc SDP4430/Panda/Blaze into the card name for (a)
[16:18] <ubot2> Launchpad bug 652035 in alsa-lib (Ubuntu) "libasound2 not finding usb sound card (affects: 1) (heat: 6)" [Medium,In progress] https://launchpad.net/bugs/652035
[16:18] <persia> Is b) only soluable through SDP4430.conf?  Can't we hint it by providing more inputs to pulse's module-udev-detect?
[16:18] <ogra> lrg, yeah, that would be good
[16:19] <abduenas> I have HDMI working from PA
[16:19] <ogra> persia, its about outputs :)
[16:19] <diwic> so for exposing HDMI to pulse, first - do we want one output at a time or is the hardware capable of multiple independent streams?
[16:19] <abduenas> it's justa a matter of creating a PA profile (which I'm working on at this moment)
[16:19] <persia> ogra, Right, so we expose more data in /sys/ that udev and pulse use to set the outputs.
[16:19] <persia> abduenas, We're looking at autodetection solutions only.
[16:19] <ogra> we want either a selectable output in the audio prefs (with a default to analog) or a mirrored output
[16:19] <ogra> i'd say
[16:20] <persia> I think the regular pulse output UI is fine.  Let's not fuss with that.
[16:20] <ogra> abduenas, we cant touch pulse config
[16:20] <ogra> persia, yes, its fine and i saw hdmi exposed in it
[16:20] <diwic> persia, there are already mixer profiles for other cards in the default config
[16:20] <abduenas> PA profile has nothing to do with touching pulse default.pa config
[16:20] <ogra> thats what i mean by selectable output
[16:20] <rsrimushnam> ogra: we need to be able to support discrete streams on different outputs -- not just mirrored
[16:20]  * jayabharath wonders if davidm is back in town... need to send a platform to hrw...
[16:21] <ogra> rsrimushnam, right, so selectable with default to analog it is
[16:21] <persia> rsrimushnam, We can do that, but we don't tend to expose the UI for that by default.  Interested folks are usually directed to install pavucontrol
[16:21] <diwic> persia, upstream ships with files for e g native-instruments-audio8dj.conf and a few others
[16:21] <persia> diwic, Yep.
[16:21] <tw_> Hate to bother you people but were would I go to get some help installing ubuntu on the BeagleBoard.  I have tried http://testcases.qa.ubuntu.com/Install/ARM/PreinstalledImage but it won't boot.
[16:22] <persia> tw_, Are you able to wait ~45 minutes?
[16:22] <lag> tw_: #beagleboard
[16:22] <lag> tw_: #beagle
[16:22] <lag> Even
[16:22] <tw_> Yes
[16:22] <tw_> Why?
[16:22] <persia> tw_, If the folks in #beagle can't help, ask us again then, and we'll help.
[16:22] <ogra> thats bad
[16:23] <ogra> dont point him to #beagle
[16:23] <ogra> they dont use ubuntu usually
[16:23]  * persia will help tw elsewhere: please continue the sound meeting
[16:23] <lag> tw_ I'll talk to you via other means - bear with me
[16:23] <tw_> btw:  I am using one of the new BB_xm boards.
[16:23] <diwic> anyway, it all comes down to, either we adjust the mixer names (in the driver) so pulseaudio can autodetect the profile, or we take abduenas PA profile when it's ready
[16:24] <ogra> where would that pa pfrofile go ?
[16:24] <diwic> /usr/share/pulseaudio/alsa-mixer/profile-sets
[16:24] <diwic> and an udev rule to go with it
[16:24] <persia> Let's do the former.  There's a high likelihood that we'll see lots more boards use this SoC, and we need per-board stuff in the driver anyway.
[16:24] <ogra> hmm
[16:24] <lrg> diwic: PA autodetection is wrong, we must be more explicit
[16:25] <ogra> diwic, how do you make sure that doesnt collide with the already existing udev rule ?
[16:25] <persia> Did anyone ever get module-udev-detect working?  Last I saw, folks were still hardcoding the modules for pulse.
[16:25] <diwic> lrg, can you elaborate?
[16:25] <ogra> persia, yes, my init script works without any extras
[16:25] <ogra> but with the above limitations
[16:25] <persia> With regular default.pa?
[16:25] <ogra> yes
[16:26] <persia> Oh, cool.
[16:26] <ogra> no changes to pulse at all
[16:26] <ogra> just the one line change to 00main and the script in place
[16:26] <lrg> diwic: auto detection depends on PA making guesses about the underlying audio hardware.
[16:26] <ogra> and the nasty extra alsactl init call
[16:26] <persia> Ah, so comment 13 wasn't wrong after all.
[16:26] <berco> ogra: it's one line in 00main + one omap4 file, right?
[16:27] <ogra> persia, yes, thats what made me develop that script
[16:27] <ogra> berco, xactly
[16:27] <ogra> no further changes
[16:27] <persia> berco and I had thought that was wrong after some experimentation, leading to the SDP4430.conf route
[16:27] <diwic> lrg, so then we must trace down where PA guesses wrong and evaluate what to do in each particular case
[16:27] <ogra> if you then call aslactl init at some point after boot sound works fine through analog
[16:27] <berco> wondering if we don't want to use udev as much as possible to avoid multiple conf files to maintain
[16:28] <ogra> udev does its job already
[16:28] <lrg> diwic: the answer is UCM when it's ready, this way PA does not need to do nasty probing on each PCM that it does now.
[16:28] <ogra> with the init scrip the mixers are all set properly right after boot (and without asound.state file in place)
[16:28] <persia> diwic, We'd do that in /usr/share/pulseaudio/alsa-mixer/paths/*, right?
[16:29] <persia> lrg, Do we expect UCM by February?
[16:29] <ogra> well, as i understood crimsun UCM is whgat these init scripts are
[16:29] <ogra> or at lest the start of UCM
[16:29] <lrg> persia: yes,  we are pshing Jaroslav to move it to his master branch ins alsa-lib.git
[16:29] <diwic> persia, those provide input for the probing as well as being a poor man's UCM, yes
[16:30] <persia> Let's design a UCM-based solution then, and use that for Natty then.
[16:30] <lrg> persia: please everyone feel free to mail Jaroslav on UCM progress on alsa-dev. this may speed up progress
[16:30] <ogra> persia, we need a solution this week
[16:30] <diwic> lrg, but UCM or not, having uniform control names is still a good thing
[16:30] <persia> And provide a pulse profile for maverick users.
[16:30] <ogra> persia, i dont care about natty
[16:31] <ogra> the SRU needs to be in before friday
[16:31] <persia> ogra, But you will, so I'll care for you today :)
[16:31] <ogra> natty is well ... natty
[16:31] <lrg> diwic: uniform control names can apply to some audio hardware but unfortunately not all :(
[16:32]  * persia owns some hardware that would have difficulty with uniform control names
[16:32] <diwic> lrg, so if this particular hardware can't have standard control names, we write a pa profile to compensate?
[16:33] <diwic> lrg, assuming UCM is not available
[16:33] <lrg> diwic: yes, agreed
[16:34] <persia> So, pulseaudio-profile for maverick and UCM for natty?
[16:34] <ogra> hrm
[16:34] <persia> We'll still have 652035 though.
[16:34] <persia> Has anyone tried the proposed SRU on an omap4 board with the alsa init script?
[16:35] <ogra> not yet
[16:35] <ogra> will the pulse profile help to initialize the right backend routing ?
[16:35] <abduenas> nop
[16:35]  * ogra doesnt belive it scratches more than the surface 
[16:35] <ogra> right
[16:36] <persia> The pulse profile will tell pulse the control names to use.
[16:36] <ogra> so that doesnt help at all
[16:36] <persia> Are you saying the HDMI out isn't even initialised with the init script?
[16:36] <ogra> oh, you mean only for adding HDMI ?
[16:36] <ogra> i understood as a general solution for the problem
[16:37] <diwic> I think there is some confusion about the "backend routing", what is that really about?
[16:37] <persia> Right.  Complete maverick solution is 652035 fix + alsa init script + pulse profile
[16:37] <ogra> diwic, adding the right codec to the control
[16:37] <persia> Natty solution would be UCM-based and may or may not need a pulse profile depending on whether we can categorise the hardware sensibly in shipping products.
[16:37] <ogra> persia, ah, now i understand
[16:39] <hrw> kgilmer: hi here
[16:39] <ogra> diwic, currently alsa device 0,0 points to a null sink
[16:39] <ogra> by default
[16:39] <diwic> ogra, can all subdevices be used in parallel?
[16:40] <ogra> i dont know
[16:40] <diwic> or does the hw just support one stream at a time?
[16:40] <ogra> i'm really no audio guy, only worked into that during last week :)
[16:40] <ogra> i think it shoudl support more
[16:40] <diwic> lrg, ^
[16:40] <persia> HW supports multiple streams
[16:40] <Guest56473> Hi i just recentñy buy a DevKit8000 and i want to run Ubuntu on it, i have already read the wiki. But when i boot from the SD the boot hang out
[16:40] <persia> rsrimushnam, Can you confirm that?
[16:40] <ogra> but one of lrg or rsrimushnam should be able to answer
[16:40] <rsrimushnam> It can support more than one stream.  But not necessarily all simultaneously.
[16:41] <persia> rsrimushnam, Do we need to worry about how many it can support at once?
[16:41] <Guest56473> at kjourlald
[16:41] <lrg> ogra: UCM will export this multiple stream info to PA too
[16:41] <abduenas> PA profile can also tell PA about the other hw devices
[16:42] <rsrimushnam> worry from what respect?
[16:42] <diwic> abduenas, that was my thought as well
[16:42] <persia> rsrimushnam, Limit the number of simultaneous streams in the UI or something.
[16:43] <kgilmer_> hi hrw :)
[16:43] <rsrimushnam> I guess the way we had visualized this, PA would route audio to the different available sinks on the driver and handle mixing streams to a single sink there.  So from the UI POV, this should be transparent, I would think,
[16:43] <kgilmer_> hrw, i'm curious how rootstock differs from oe?  does rootstock run entire build on arm via qemu?
[16:44] <persia> rsrimushnam, That's easlier then.  Thanks.
[16:44] <hrw> kgilmer_: it just uses packages from feeds  + some mangling
[16:44] <diwic> so does the driver "probe" the codec and construct devices appropriately? Or are the subdevices hard-coded in the driver?
[16:45] <persia> The subdevices appear to be constructed by the alsa init script
[16:45] <berco> Going back to "Complete maverick solution is 652035 fix + alsa init script + pulse profile". rsrimushnam: are you going to provide us the PA profile?
[16:46] <rsrimushnam> Yes.
[16:46] <berco> so are we sure "652035 fix + alsa init script + pulse profile" will be enough? no need for a sdp4430.conf file or else?
[16:46] <rsrimushnam> abduenas is working on it now.
[16:46] <abduenas> actually the PA guys are willing to include that on PA package, as native-instruments-audio8dj.conf
[16:46] <diwic> persia, the init script as posted in comment #25 does not add any subdevices?
[16:47] <kgilmer_> hrw, packages = binary packages?
[16:47] <persia> berco, I think ogra said that he didn't need SDP4430.conf with the init script.
[16:47] <diwic> persia, could you point me to that init script?
[16:47] <berco> abduenas: ok, I see. That's fair
[16:48] <persia> diwic, Then I'm mistaken.
[16:48] <ogra> persia, right
[16:48] <hrw> kgilmer_: yes
[16:48] <mpoirier> diwic, the scripts simply connect backends to frontends.
[16:48] <ogra> diwic, its attached to the bug
[16:48] <berco> persia: I agree. Just wanted to make sure we discard this approach of SDP4430.conf
[16:48] <kgilmer_> where do the binary packages get generated hrw?
[16:48] <diwic> ogra, so it is the #25 comment attachment?
[16:48] <ogra> diwic, right together with the change to 00main
[16:48] <ogra> (from 24)
[16:49] <hrw> kgilmer_: ah that your gentoo roots...
[16:49] <diwic> so then I'll reask my question: does the driver "probe" the codec and construct devices appropriately? Or are the subdevices hard-coded in the driver?
[16:49] <ogra> they are apparently not since oyu need that script
[16:49] <mpoirier> nothing is hardcoded in the driver.
[16:49] <hrw> kgilmer_: in debian (and derived) binary packages are built by builddeamons
[16:49] <mpoirier> they FE and bE are initialised and left for userspace to connect.
[16:50] <diwic> mpoirier, who decides that 0,0 is a null sink and 0,7 (?) is HDMI?
[16:50] <diwic> e g
[16:50] <kgilmer_> hrw, ah ic.  those biuld daemons are running on target architecture or they are cross compiling?
[16:50] <berco> ogra: so for the init script, will it be a udev rule?
[16:50] <hrw> kgilmer_: target - only native builds are done
[16:50] <ogra> berco, there is a udev rule already
[16:51] <mpoirier> diwic:the null sink is simply the first on the list.  I beleive moving it down would put another sync as the default
[16:51] <kgilmer_> interesting hrw
[16:51] <lrg> diwic: the pcm mappings are done in the machine driver
[16:51] <lrg> have a look at sdp4430.c
[16:51] <ogra> berco, you only need to dump the script into /usr/share/alsa/init/
[16:51] <berco> ogra: oops, sorry. Thought alsactl init was still missing
[16:51]  * kgilmer_ sees a chicken and egg problem.
[16:51] <ogra> berco, right
[16:51] <hrw> kgilmer_: you mean "bootstrap" problem?
[16:52] <ogra> berco, but thats only to actually init, the mixers are all set right already and properly routed
[16:52] <kgilmer_> yeah hrw
[16:52] <ogra> berco, the hope is that the aösa-lib fix solves the needed init
[16:52] <berco> ogra: missed that one :). Now I understand the #652035 need :)
[16:53] <ogra> :)
[16:53] <berco> so just waiting for rsrimushnam profile and we can test :)
[16:54] <berco> rsrimushnam: when do you think you can provide us a profile-set to test?
[16:54] <berco> sorry, most likely to be abduenas
[16:54] <rsrimushnam> we have something started already but we are still having issues with it. abduenas can elaborate
[16:54] <berco> who provides this file
[16:54] <hrw> kgilmer_: both distros did bootstrap long time ago
[16:55] <rsrimushnam> fyi:  I need to drop off in 5 minutes...
[16:55] <berco> rsrimushnam: abduenas: I think we just need to get a rough idea of the timeframe
[16:55] <abduenas> i'm just missing the udev rule in /lib/udev/rules.d/90-pulseaudio.rules to be able to read omap3.conf
[16:55] <abduenas> but i'm udev nubee
[16:56] <ogra> abduenas, ugh, a udev rule for pulse ?
[16:56] <diwic> So the problem is then: that PA should switch subdevice on the fly (i e when user switches from "Headset" to "HDMI")  in a way it currently can't do?
[16:56] <abduenas> sorry meant to say omap4.conf (or wahtever)
[16:56] <berco> abduenas: don't hesitate to come to this channel and ask for help. If we can we will help
[16:56] <persia> diwic, Why does it need to be different than what we do for headset/HDMI for anything else?
[16:56] <lrg> lag: are you taking a note of any actions here btw ?
[16:57] <lag> I wasn't no
[16:57] <persia> (irclogs.ubuntu.com can help if it's not being done in realtime)
[16:57] <ogra> abduenas, are you sure that is used at all when pulse runs on a per user base ?
[16:57] <berco> ogra: this udev rule already exists.
[16:57] <lrg> persia: I'm forgetful ;)
[16:57] <ogra> (which is the default in ubuntu)
[16:57] <lag> I don't think we have a meeting bot in here
[16:57] <diwic> persia, current PA structure is either switch between different cards, or switch "connector" (which it does by setting volume controls, not by switching subdevice)
[16:57] <ogra> berco, right, but i think only if pulse runs as a system daemon it is used
[16:58] <berco> ogra: I see.
[16:58] <persia> lag, We don't.  I don't want to have enough meetings here to add one, but I'm willing to be convinced.
[16:58] <ogra> berco, i'm not sure though
[16:58] <ogra> berco, abduenas, that should be heavily tested
[16:58] <persia> diwic, Aha.  OK.  I guess I've not actually used PA with my harder-to-define cards.
[16:58] <abduenas> i'm able to use it on per-user basis
[16:58] <lag> persia: No, it's okay :)
[16:59] <ogra> abduenas, thanks that helps :)
[16:59] <lag> I we'll have to have a wash-up when the meeting has finished
[16:59] <lag> Who's doing what etc
[16:59] <ogra> so who is fixing the driver side ?
[16:59] <persia> lag, It's also worth separating into two discussions moving forward: maverick hacks and natty solution.
[17:00] <lrg> ogra: what part of the driver ?
[17:00] <ogra> to expose the board name
[17:00] <lrg> the name ?
[17:00] <lrg> ah, ok - me :)
[17:00] <ogra> :)
[17:00] <berco> cool :)
[17:00] <ogra> like in the hda init file
[17:00] <ogra> i'm happy to add my init file to alsa-libs in an SRU
[17:00] <ogra> and the one line change to 00main
[17:00] <diwic> persia, the question is if that can be worked around in the pa profile, and it might be if the subdevices are stable
[17:00] <abduenas> i'm working on the PA profile for SDP4430/OMAP4
[17:01] <ogra> abduenas, will you test on all available omap4 hw ?
[17:01] <ogra> (panda, blaze tablet)
[17:01] <persia> diwic, For the small number of devices to be fixed for maverick, I think we can find a way to fake that.  We'll need a richer interface for natty.
[17:01] <abduenas> i have a blaze but no panda... although i can borrow one ... i think
[17:01] <Neko> hey guys what's the procedure for cross compiling a package
[17:02] <persia> Neko, We try to avoid it at all costs.
[17:02] <ogra> (though i guess we can be a bit ignorant about tablet since it uses a different kernel anyway)
[17:02] <armin76> haha
[17:02] <persia> Neko, That said, there's a cross-toolchain package in the archives
[17:02] <Neko> yes but consider I have a nice fast box here to cross compile xserver or so....
[17:02] <Neko> I have the toolchain
[17:02] <berco> abduenas: if you have something to be ready for test, let me know. I can run the test on my panda to help
[17:02] <Neko> but if I dpkg-build it's gonna use native right?
[17:02] <persia> Right.
[17:02] <abduenas> berco: roger that
[17:02] <ogra> lag, so was that enough as a summary for your notes ?
[17:02] <persia> And lots of packages are packaged in a way that means they can't be cross-compiled.
[17:02] <berco> abduenas: also good to be able to reproduce
[17:02] <ogra> (who -> what)
[17:03] <Neko> I guess the answer is, then, don't bother..
[17:03] <persia> That's what we devided, yeah.
[17:03] <ogra> Neko, so i found the issue to your gdm vs oem-config bug
[17:04] <hrw> Neko: "xdeb -a armel --apt-source packagename"
[17:04] <lag> ogra: Sure
[17:04] <ogra> great :)
[17:04] <persia> Neko, hrw is the local cross-compilation expert if you really want to dig: just be warned it's not as trivial as just expecting dpkg-cross to actually work.
[17:04] <lag> Unless there's anything else anyone wants to add?
[17:04]  * ogra is fine as long as sound works on friday :)
[17:04] <hrw> Neko: it may fail (probably will). next step is adding "--only-explicit" to xdeb call. this also may fail
[17:04] <Neko> ogra, amazing what is the problem?
[17:04] <Neko> I didn't get a bug update
[17:05] <Neko> hrw, thx maybe I will look into it.. for now though, native, since this seems like it may fail
[17:05] <ogra> Neko, because the bug is invalid ... its the way rootstock rolls the tarball
[17:05] <hrw> Neko: last step is "dpkg-buildpackage -b -aarmel" as xdeb steps should give you build deps
[17:05] <diwic> abduenas, you're also welcome to contact me if you need someone to discuss PA profiles with
[17:05] <Neko> ogra, argh?
[17:05] <abduenas> diwic: thnx!
[17:05]  * berco thinks it "sounds" better than an hour ago :)
[17:05] <hrw> Neko: debian and derived are not cross compilation ready
[17:05] <Neko> so maybe update the bug as invalid with a comment that rootstock rolls the tarball badly? :)
[17:05] <Neko> hrw, I know, nothing is.. :(
[17:05] <ogra> Neko, if you just use tar, uid's and gid's will be taken from /etc/passwd and group of the host system
[17:06] <persia> Neko, Just build faster boxes :)
[17:06] <ogra> Neko, rootstock needs to use --numeric-owner to make sure owners of the files dont change
[17:06] <Neko> hmm has this been patched already?
[17:06] <ogra> Neko, thast something you will only hit of you build newer releases on older boxes
[17:06] <ogra> not yet, i need to discuss with rsalveti once he is back
[17:06] <Neko> yeah I was building maverick on lucid...
[17:07] <Neko> but also building lucid on lucid broke like that
[17:07] <ogra> (public holiday at his place today)
[17:07] <lag> In case there is any doubt
[17:07] <lag> [END MEETING]
[17:07] <lag> Thank you everyone
[17:07] <lag> I'll be in touch
[17:07] <diwic> thanks, bye
[17:07] <Neko> basically because on x86 and armel the user ids not necessarily the same...
[17:07] <ogra> Neko, well, as long as there is a diff between host and VM
[17:07] <ogra> right
[17:07] <ogra> not even between two x86 boxes thats guaranteed
[17:07] <hrw> Neko: OpenEmbedded allows to cross compile big amount of stuff in automated way
[17:07] <ogra> the system users are created by the packages
[17:08] <mpoirier> sguiriec: were you able to bet me docs for the complete audio path we talked about ?
[17:08] <ogra> so it only depends on the order
[17:08] <ogra> (in which the packages are installed)
[17:08] <Neko> hrw yes and opensuse build service manages too.. the big trick is use qemu
[17:08] <Neko> but installing a full system then qemu then build is overkill
[17:09] <ogra> opensuse does some very nasty things though
[17:09] <Neko> yep I know
[17:09] <ogra> injecting x86 libs and binaries
[17:09] <sguiriec> mpoirier:I have prepare a picture. Need to make minor correction
[17:09] <Neko> I got my "I contribute" t-shirt for reporting tons of bugs :]
[17:09] <mpoirier> sguiriec: cool.
[17:09] <Neko> okay.. so...
[17:09] <Neko> ogra, if I hack my rootstock to have this --numeric-owner stuff it will magically start to work better?
[17:09] <persia> sbuild can run over qemu as well: the results were not as exciting as initially thought...
[17:10] <sguiriec> mpoirier: sorry a little bit busy on other stuff. Will try to push it today
[17:10] <hrw> Neko: OE does cross only - qemu is used only for generation of glibc l10n packages (and can be disabled)
[17:10] <hrw> Neko: but thats #ubuntu not #oe
[17:10] <mpoirier> sguiriec: that's ok, I've been elsewhere too.
[17:10] <ogra> Neko, it should, i haent tested it yet but hit the exact same issue as you with a tarred up rootfs that i repacked on different boxes
[17:10] <ogra> Neko, so finding all tar calls in rootstock and adding --numeric-owner should solve it
[17:11] <Neko> hrw, I have some experience with OE, but I quit using it about 18 months ago
[17:11] <persia> Neko, Did you never have success with livecd-rootfs and debian-cd?
[17:12] <sguiriec> mporier: I will give you the link as soon as I have done the update.
[17:12] <Neko> persia, I never got to try it
[17:12] <Neko> I am stuck doing kernel stuff
[17:13] <Neko> but since mav got released....
[17:13] <Neko> I am building rootstocks
[17:13]  * ogra would also recommend livecd-rootfs over rootstock if you want to release images
[17:13] <Neko> I need a rootstock first before I can do that though
[17:13] <ogra> rootstock is great for home use
[17:13] <Neko> chicken-egg really
[17:13] <persia> Ah, OK.  I'll hope you have a chance to switch before natty, as rootstock isn't tested well, and mostly meant for hacking about rather than working systems.
[17:13] <ogra> but nothing for doing official releases
[17:13] <Neko> these rootstocks right now are for *me* only
[17:14] <Neko> we have released on a board already but.. it was a hateful solution
[17:14] <persia> For now, stick with what you have.  When you have a few hours, come back, and we'll help you switch.
[17:14] <hrw> have a nice rest of day
[17:14] <Neko> maybe in 6 weeks? :D
[17:15] <ogra> Neko, will you be at UDS ?
[17:15] <persia> Neko, 6 weeks sounds about perfect, sure.
[17:15] <Neko> no but Konstantinos will be
[17:15] <Neko> (markos, armhf debian)
[17:15] <ogra> we could sit down one evening and fix :)
[17:15] <Neko> unfortunately UDS happens during the school year so it's impossible for me to take time out to do it
[17:54] <berco> ogra: do we also need to add the user to audio&pulse groups?
[18:00] <Neko> yay, ogra, made a little fix for rootstock, worked :D
[18:00] <Neko> so that numeric-owner thing is exactly it
[18:01] <Neko> (oem-config still nukes on exit though, I gotta work out how to fix that, but we have a new uboot series coming out.. which will make flash-kernel work better...)
[18:01] <Neko> btw is the flash-kernel package owner in here
[18:07] <kgilmer_> ogra, where can i get more info on livecd-rootfs?
[18:07] <kgilmer_> the default google search isn't very enlightening.
[19:15] <TAsn> Hey guys, I can't find the SmartQ v7 in https://wiki.ubuntu.com/ARM/DeviceSupport but I remember reading somewhere (sorry, lost the link) that it does in fact work. Is this true? So, is there support? If so, in the form of a repository hosted somewhere? or do I have to compile everything on my own? Thanks.
[19:43] <ogra> berco, no
[19:44] <ogra> berco, console-kit cares for that since lucid
[20:55] <playya_> what are the minimum disk requirements for an arm ubuntu with a tiny window manager (matchbox, unity) ?
[21:06] <Neko> for the whole unity desktop?
[21:07] <playya__> i have to recreate my lvm partitions and maybe i can get enough space for an ubuntu
[21:07] <playya__> but not high priority
[21:51] <playya_> is ogra's build-arm-rootfs still usable for maverick?
[21:53] <ogra_ac> playya_, better use qemu-debootstrap --arch armel
[21:53] <playya_> ok
[21:53] <ogra_ac> oh, wait, build-arm-rootfs ?
[21:54] <playya_> yes
[21:54] <ogra_ac> no, use rootstock
[21:54] <playya_> i think the resulting image might be to big and the pre's kernel is quite old (2.6.24)
[21:55] <playya_> maybe i should wait for the pre plus
[22:41] <ogra_ac> doko, new ac100 image up if you want
[22:41] <ogra_ac> (with the battery spam patched out of the kernel now)
[22:45] <Neko__> battery spam? :)