[03:05] <Neko__> ogra, does anyone know why mono doesn't install on armel (especially in qemu?)
[03:18] <persia> It's a qemu bug.
[03:18] <persia> directhex got Mono working cleanly on the EfikaMX for maverick.
[03:18] <persia> (even moonlight)
[03:19] <persia> If you're using rootstock, don't install Mono until you've booted on the real hardware.
[03:21] <persia> (unless someone made rootstock work unemulated for native builds, in which case it ought be no issue)
[03:21] <persia> kmargar, Hey.
[03:22] <Neko__> persia, I just saw there were tons of bugs in Mono for mx51 (but not dove!) for some reason, and ogra was involved
[03:23] <Neko__> testing at least
[03:23] <Neko__> directhex is one of the guys we sent boards to?
[03:23] <Neko__> the mono guy?
[03:23] <Neko__> did he have to fix anything or was it just working out of the box at release?
[03:23] <persia> Indeed.  mono on the i.MX51x was exceedingly painful for a while, but is now sorted.
[03:23] <Neko__> okay great
[03:23] <Neko__> so what's the qemu bug :D
[03:23] <persia> He had to fix something.  There was a blog post.
[03:23] <Neko__> it would be great if that was fixed
[03:24] <persia> Well, qemu doesn't support some huge chunk of stuff (you'll see lots of unsupported syscall and unsupported ioctls pass in stdout).
[03:24] <Neko__> once I finish this next rootstock I am done with it and will start messing with livecd-rootfs
[03:24] <persia> And something in that unsupported stuff is enough to wedge Mono.
[03:25] <persia> The impression I have is that nobody wants to fix it, instead switching from qemu-versatile to qemu-omap to collect a separate set of issues, but one that can easily be compared against hardware.
[03:25] <persia> Whether using qemu-omap is enough to install Mono is not clear to me: there may be more involved.
[03:25] <Neko__> I saw his post about moonlight and firefox ABIs today
[03:25] <Neko__> nothing about Mono proper though
[03:26] <persia> He got Mono working back in Jaunty, but only for some things.  It's a steady progress to test all the corner cases.
[03:26] <Neko__> I'm impressed that Moonlight is working..
[03:26] <persia> Moonlight is rather demanding on the CLI, and exercises it fairly well.
[03:27] <Neko__> I don't understand about this codec pack though
[03:28] <Neko__> anyway brb Patch Tuesday
[03:31] <persia> For those lurking, the above is another demonstration why it's handy to run Ubuntu :)
[08:22] <doko_> ogra: the hint for tar --numeric-owner is missing in your README
[08:23] <persia> doko_, Please file a bug :)
[08:33] <lag> Morning
[08:33] <lag> ogra: Are you around yet?
[08:35] <hrw> moin
[09:12] <vstehle> ogra, ogra_ac: Hi, how are you? I am "fighting" with the "install extras" icon right now; we think that universe & multiverse have not been enabled in the preinstalled image, which make installing our "extras" a bit difficult...
[09:19] <ndec> ogra: lag: hey! questions for the PPA: I see that the builders are idle, however our builds don't get started. is that expected?
[09:20] <persia> vstehle, Take a look at your /etc/apt/sources.list to verify universe and multiverse are enabled.
[09:21] <lag> ndec: This isn't something I deal with - perhaps ogra or persia can help?
[09:21] <persia> Best to ask the launchpad folk (in #launchpad).  My guess would be that it had something to do with natty opening, but there's a high chance I'm wrong.
[09:24] <persia> ndec, I'm happy to lead the discussion, if you'd prefer, but please also join to provide any support information :)
[09:24] <ndec> persia: ok
[09:25] <persia> ndec, Just to confirm, which PPA?
[09:25] <ndec> persia: well, our private OMAP ppa
[09:26] <ndec> persia: and I got a 'waiting 11 hours' for an arch all package using an i386 builder...
[09:26] <vstehle> persia: Well, /etc/apt/sources.list _is_ the problem :) We have those of the preinstalled image. And they don't include multiverse and universe "out of the box".
[09:27] <persia> vstehle, Aha!  I suspect it's one of the preinstalled vs. performing the install things.  Please file a bug against jasper-initramfs, and we'll sort it.
[09:27] <vstehle> persia: Hum. Can you "fix" the images on the website? I thought they were released and "frozen" now.
[09:28] <vstehle> persia: I thought our only options were fixes in the PPA packages, and documentation.
[09:28] <persia> No, but we can 1) fix jasper to not do this next time images are produced, and 2) brainstorm about ways to work around it.
[09:29] <persia> There's also bugfix uploads: won't affect the images, but can affect user experience once the user updates.
[09:29] <vstehle> persia: Ok, I'll file a bug on LP for (1). I am very interested in (2) right now :)
[09:29] <persia> We'll use the one bug for both.
[09:30] <persia> Just with two tasks.
[09:31] <persia> ogra, Did you implement the special software channel as a separate package, or as part of jasper?
[09:33] <vstehle> persia: Bug #659754
[09:33] <ubot2> Launchpad bug 659754 in jasper-initramfs (Ubuntu) "Universe & multiverse are not enabled on OMAP4 preinstalled image (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/659754
[09:34] <persia> Great.  Now to wait for the confirmation of the implementaiton, and we can get started on fixing it :)
[09:37] <vstehle> persia: I tell you: I am not really worried about the fix for future distributions. What worries me is that users will d/l the OMAP4 preinstalled image, click on the icon and get an error message.
[09:38] <vstehle> persia: We are thinking about documenting an extra step like "enable multiverse/universe manually" on a website somewhere. Or even more nasty: do some hacks in the ubuntu-omap4-extras package (break the deps on other real packages, perform hacks in postinst scripts). What do you think?
[09:48] <persia> There's an API to enable universe/multiverse, so we oughtn't have to go to the extreme of a nasty hack.
[09:49] <persia> Just a matter of determining where/how to drop it in place.
[09:50] <persia> But I really don't think it's wise not to worry about the fix for future releases: firstly, the SRU process requires "fixed in current development" as a prequisite for an SRU.  Secondly, if we don't fix it in both places, we'll just end up in this state again in six months.
[09:50] <persia> That said, I very strongly suspect we can get a solution ready for testing within the next 24 hours, and probably within the next 6-8.
[09:55] <vstehle> persia: Would your solution require an extra user step? Or are you thinking of doing stuff in preinst?
[09:56] <persia> I was thinking a postinst: just have to think about where.
[09:56] <persia> But, ideally, the user experience would be nothing other than a regular update.
[09:59] <persia> For the future, the planned jasper rewrite *should* cover it, and we can do a quick python-apt hack to force-enable for the short-term.
[10:00] <persia> Ideally, ogra implemented the omap4-special software channel in a separate package, so we can just update that package: this has the lowest chance of affecting others.
[10:00] <persia> But I'm not precisely certain how that was implemented, which is the main deciding factor for not fixing it now.
[10:01] <ogra> persia, it is just implemented through a .desktop file containing an aptulr
[10:01] <ogra> *url
[10:01] <persia> ogra, No package then?  Darn.
[10:01] <ogra> nope
[10:01] <persia> Any suggestions on where we can stick a postinst fragment to enable universe/multiverse?
[10:01] <ogra> the postinst of the meta needs to be easily able to just rebmove it
[10:02] <ogra> a package would have gotten in our way
[10:02] <persia> Aha.  I'll call that excessively layered hackery, but I understand why it was done that way.
[10:03] <persia> So, what do we have that would only hit preinstalled folk and can enable universe?
[10:03] <ogra> a package would either have to be seeded or be a dep of jasper
[10:03] <ogra> in the seed way it would always come back
[10:03] <ogra> and with jasper it would have been removed with oem-config
[10:03] <persia> Let's not discuss that implementation now: we can do that in the jasper-rewrite discussion.
[10:03] <ogra> thanks to the live seed
[10:03] <persia> Let's talk about how we can SRU a fix.
[10:04] <ogra> well, first of all livecd-rootfs needs a fix
[10:04] <persia> Because a pre-jasper-rewrite natty fix is a trivial python-apt call.
[10:04] <persia> No.
[10:04] <ogra> it apparently misbehaves
[10:04] <persia> The model is that the live environment has universe disabled, and it's enabled during install.
[10:05] <persia> The rationale is to save space for the universe Packages file in the live environment.
[10:05] <ogra> it writes the sources.list and obviously doesnt write the same default one that ubiquity sets up by default
[10:05] <persia> And livecd-rootfs does this.
[10:05] <persia> Right.  Jasper should take care of that.
[10:05] <persia> (and it's trivial).
[10:05] <ogra> jasper isnt SRUable
[10:05] <persia> But the hard question is what to do for maverick.  What can we update that is only going to affect jasper-installs.
[10:05] <persia> I know/.
[10:06] <persia> The only reason to add the hack to jasper is to justify the SRU of something else.
[10:06] <ogra> and we have no package that would just do it
[10:06] <persia> We have nothing that is only on preinstalled images?
[10:06] <ogra> nothing apart from jasper
[10:06] <persia> That makes this tricky :)
[10:07] <ogra> right
[10:07] <persia> Do we have any programmatic way we can distinguish a preinstall from an install?
[10:07] <ogra> not from an oem install, no
[10:07] <ogra> well, you can check if jasper is installed, but only until oem-config was removed
[10:08] <ogra> you can also check if the ppa enablement files exist
[10:08] <persia> Do we do an apt-get upgrade before that happens?
[10:08] <ogra> no
[10:08] <ogra> update-manager is supposed to care for upgrades
[10:08] <persia> Ah, right.  The PPA enablement files are probably a good test.
[10:09] <persia> Let me rephrase then: do we invoke a python-apt cache update prior to oem-config?
[10:09]  * persia really doesn't care *how* the apt-cache is updated, but whether it is updated
[10:09] <ogra> the prob here is that either oem-confir doesnt run apt-setup at all or that livecd-rootfs doesnt enable what it should
[10:09] <ogra> i'm still tending to blame the latter
[10:09] <persia> livecd-rootfs is supposed to leave universe and multiverse disabled.
[10:10] <ogra> why ? thats nonsense
[10:10] <persia> This is by design for all live environments building from main.
[10:10] <persia> It saves several megabytes from the CDs.
[10:10] <ogra> since we enable it by default and give no opportunity to override that
[10:10] <ogra> ??
[10:10] <ogra> why would it
[10:10] <persia> Packages.gz
[10:10] <ogra> sources.list is setup at a point where that doesnt matter
[10:11] <ogra> hmm, k
[10:11] <persia> Yes, but you need an accurate apt-cache to be able to run things like the codec installer from within the live environment...
[10:11] <ogra> i wouldnt think Packages.gz is that big
[10:11] <persia> Anyway, it7s not a livecd-rootfs bug.
[10:11] <ogra> it is
[10:11] <ogra> for future images we should just enable whats needed in the preinstalled path
[10:11] <ogra> that wont touch the livefs
[10:12] <persia> 5MB on my mirror for maverick.
[10:12] <ogra> nah
[10:12] <ogra> it gets compressed again
[10:12] <ogra> wont be 5MB
[10:12] <persia> Yes, for packages.bz2  Packages.gz is seven and a half.
[10:12] <persia> Yes it will.
[10:12] <ogra> well, if you say so
[10:13] <persia> Maybe 4.5, because squashfs is lzma, but anyway...
[10:13]  * ogra wont debate that since we'll be adding several 100 anyway in natty
[10:13] <ogra> no squashfs involved for preinstalled
[10:13] <persia> Oh, then 7.5 because that's gz.
[10:13] <persia> Anyway, doesn't matter.  Let's get back to the point.
[10:14] <ogra> right, whats your suggestion ?
[10:14] <persia> So, it's trivial to enable universe/multiverse in current jasper by calling into python-apt.
[10:14] <persia> And we'll use apt-setup to do it with rewritten jasper.
[10:14] <persia> So natty is sorted.
[10:14] <ogra> jasper is not SRUable
[10:14] <ogra> what about maverick
[10:14] <persia> Yes.
[10:14] <ogra> i know what to do about natty
[10:14]  * persia is getting there, and requests a bit of patience for a summary
[10:15] <ogra> and i wont do it in jasper there since that enfoces a network connection at oem-config time
[10:15] <persia> No, it doesn't.
[10:15] <persia> The idea is to use the same sequence of stuff used for normal installs.
[10:15] <ogra> how do you get the package cachje without network if not at image buildtime ?
[10:16] <persia> You fail to get it if there's no network, and you set it up to be a request for it in software-sources, so that next time update-manager does a regularly scheduled run, it pulls them.
[10:16] <persia> And update-manager automatically doesn't do that if there's no network, so you end up doing it the first time the user *has* a network, which is the right time.
[10:17] <persia> Anyway, can we get back to maverick?  We've agreed natty is easy.
[10:17] <ogra> k
[10:17] <persia> So, we can detect that we're in a preinstall because of the PPA enablement files.  And we can detect that universe/multiverse are not enabled, and use python-apt to request enablement.
[10:18] <persia> What we need is some package to which we can attach the script that does that.
[10:18] <persia> And that has to *not* be jasper, but something that we can usefully SRU.
[10:18] <persia> And I don't care about delayed-enablement, because the user has a network connection to download the SRU anyway.
[10:19] <ogra> k
[10:19] <ogra> is there a way to enforce u-m directly after login ?
[10:19] <ogra> without much hackery indeed
[10:19] <persia> It's already set to run the first time there is both a logged in admin user and a network.
[10:19] <persia> So we get that for free.
[10:20]  * ogra has never seen that
[10:20] <ogra> and by rules of mpt it should only run after 7 days for the first time
[10:20] <persia> Try doing a networkless install about three months after release sometime, and you'll see it.
[10:20] <ogra> but i might be wrong
[10:20] <persia> You can test with a networkless install of lucid today, if you like.
[10:20] <ogra> it changed between lucid and maverick
[10:21] <ogra> mvo told me it has to wait 7 days now
[10:21] <ogra> no matter what
[10:21] <persia> It runs 7 days after the last run.  ubiquity tries to do an update at install time.  If ubiquity fails to do an update, the last run timestamp is the image creation date, which is more than 7 days ago.
[10:21] <persia> Unless the implementation changed massively, we ought still get free updates.
[10:21] <ogra> not my experience and not what i was told for maverick, but if you say so
[10:22] <ogra> so where would we put it ? we dont have any special packages installed
[10:23] <persia> Maverick might be different.  Dunno.  We'll check if we find a victim.
[10:23] <persia> Yeah, the where to put it is the tricky bit.
[10:23] <persia> Don't we have a kernel SRU pending that's specific to certain hardware?  Could we add it to that?
[10:24] <persia> (noting that anywhere we put it will annoy the SRU team, so there's no better/worse place)
[10:24] <ogra> ubuntu-netbook-efl-default-settings ... ?
[10:24] <ogra> thats quite freely hackable
[10:25] <ogra> for us at least
[10:25] <ogra> it will only be installed on arm by default (there is a switch in the netbook seed)
[10:25] <persia> I think the default-settings package is probably better.  Same argument with the SRU team, but won't block the kernel if it gets sticky.
[10:26] <ogra> you will never get it on anything but arm
[10:26] <persia> That's not true.
[10:26] <ogra> (nothing depends on it on other arches)
[10:26] <persia> But you won't get it *by default*, and we can guard it with the appropriate preinstall check.
[10:26] <ogra> only if you explicitly install it by hand you will get it
[10:27] <ogra> ubuntu-netbook doesnt pull it in, nor does any other dep
[10:27] <persia> Right.  We have to also consider that case, but I think we're safe if we check for the PPA enablement files in the postinst.
[10:27] <ogra> yes
[10:27] <ogra> well, that wont solve omap3
[10:27] <ogra> i'd say we do an arch check
[10:28] <persia> Why?
[10:28] <ogra> check arch, check sources.list, if universe is missing and arch matches, enable universe
[10:28] <ogra> because omap3 doesnt have a ppa
[10:28] <persia> If someone decides, for reasons we'll never understand, to use livecd-rootfs to create an i386 preinstall and has this issue, we ought sort it for them as well.
[10:29] <ogra> that would mean he has to change seeds too
[10:29] <persia> Unless you want to SRU jasper.
[10:29] <ogra> an x86 preinstall would still not pull in -efl
[10:29] <ogra> and jasper on x86 would do nothing wrt ppa
[10:29] <persia> Oh right, and at that point, it becomes a case of "the bug was reported, and you should have backported the fix from natty".
[10:29] <ogra> it does an arch check
[10:30] <persia> OK.  I hate arch checks on general principles, but I think it's probably the least bad option at this point.
[10:30] <persia> And it's only the omap3 and omap4 images that are broken.
[10:30] <ogra> it wouldnt do much at all in fact, just enable oem-config and the default session (the latter would be a bug on x86)
[10:30] <persia> Why would it be a bug on x86?
[10:31] <ogra> because the efl session cant exist there
[10:31] <persia> Why not?
[10:31] <ogra> not from livecd-rootfs
[10:31] <ogra> because the seed doesnt pull it in, on x86 it defaults to unity
[10:31] <persia> Different definition of "can't".  Right.  I agree.
[10:31] <persia> Do you want to summarise the above in the bug, or shall I?
[10:31] <ogra> it would require massive seed hackery that would make the netbook CD size explode
[10:32] <ogra> would you ?
[10:32] <persia> No, but we don't care, because it's large enough to be derivative at that point.
[10:32] <persia> I'm happy to: let's just recap quick to make sure we agree.
[10:32] <ogra> tell that to didrocks :P
[10:32] <persia> 1) Long-term fix is jasper-rewrite
[10:32] <ogra> he forced -efl off the x86 installs because of size
[10:32] <persia> 2) short-term natty fix is python-apt hack in jasper
[10:33] <persia> 3) maverick fix is -default-settings postinst hack with arch guard.
[10:33] <persia> Look right to you?
[10:33] <ogra> (which got us in the awkward situation of unity sessioons coming back all the time, since he hardcodes a switch of the session towards unity in his -settings postinst)
[10:33] <persia> Right, netbook-efl for x86 is only interesting if one drops unity.
[10:34] <ogra> looks good to me
[10:34]  * persia updates the bug
[10:35]  * ogra just did an update on x86 and glares at the (felt) 2mx2m sized button in update-manager "restart now"
[10:35] <ogra> geez, thats huge !
[10:35] <ogra> i wonder how that looks on a small screen, it must have 60px padding around the text
[10:36] <persia> ogra, Could you quickly accept jasper/natty and -default-settings/maverick tasks and reject the other two for bug #659754 ?
[10:36] <ubot2> Launchpad bug 659754 in ubuntu-netbook-efl-default-settings (Ubuntu) (and 1 other project) "Universe & multiverse are not enabled on OMAP4 preinstalled image (affects: 1) (heat: 10)" [Undecided,New] https://launchpad.net/bugs/659754
[10:36] <ogra> oh, why are you not allowed to ?
[10:36]  * persia isn't core-dev
[10:37] <persia> I'm still writing up the issue, etc.
[10:37] <mopdenacker> Hi! I'm trying to make a few changes to the uInitrd of pre-installed images, to support installation on the Blaze's eMMC storage. However, the kernel says "failed to execute /init" when my modified uInitrd is used. Here are the steps I took:
[10:38] <mopdenacker> dd if=../uInitrd of=initrd.lzma bs=1 skip=64
[10:38] <mopdenacker> mkdir initrd
[10:38] <mopdenacker> cd initrd
[10:38] <mopdenacker> lzcat ../initrd.lzma | cpio -id
[10:38] <mopdenacker> <make changes: just adding "set -x" in some scripts>
[10:38] <mopdenacker> find . -print -depth | cpio --quiet --dereference -o -H newc | lzma -c > ../initrdnew.lzma
[10:38] <ogra> persia, hrm, doesnt work
[10:38] <mopdenacker> cd ..
[10:38] <mopdenacker> mkimage -A arm -O linux -T ramdisk -C none -a 0 -e 0 -n initramfs -d ./initrdnew.lzma ./uInitrdnew
[10:38] <mopdenacker> Do you see anything wrong?
[10:38] <persia> ogra, Ugh.  Maybe accept everything, and we can set somethings to Invalid?
[10:38] <persia> !paste | mopdenacker
[10:38] <ubot2> mopdenacker: For posting multi-line texts into the channel, please use http://paste.ubuntu.com | To post !screenshots use http://tinyurl.com/imagebin | !pastebinit to paste directly from command line | Make sure you give us the URL for your paste - see also the channel topic.
[10:38] <ogra> persia, sounds better
[10:39] <ogra> mopdenacker, thats not the right way, chroot into the filesystem and run update-initramfs (and make sure /proc is mounted ... and unmounted before you leave the chroot)
[10:39] <mopdenacker> ubot2: ok, I thought this was short enough, but I got it wrong. Will do it in the future...
[10:39] <ubot2> mopdenacker: Error: I am only a bot, please don't think I'm intelligent :)
[10:39] <lag> ogra: persia: Explain to me what the default.pa file does for _us_
[10:40] <lag> ! mopdenacker | lol
[10:40] <ubot2> Factoid 'mopdenacker' not found
[10:40] <persia> lag, Ask me again in 10 minutes.
[10:41] <lag> I just want a short explanation for my write-up
[10:41] <ogra> lag, imho it gets constantly in our way :P
[10:41] <ogra> (but dont put that in your summary )
[10:41] <lag> ogra: That's not helpful
[10:42] <lag> Why do we need it?
[10:43] <lag> ogra: You contradicted yourself
[10:43] <lag> 1. HDMI doesnt get initialized and exposed to pulse
[10:43] <lag> 2. its fine and i saw hdmi exposed in it
[10:43] <ogra> lag, when hacking default.pa
[10:43] <ogra> you pulled that out of context :)
[10:44] <ogra> we cant hack default.pa because it breaks all other arches
[10:44] <persia> ogra, Note that Kubuntu is also affected.  Do you know if the PPA enablement stuff works there?
[10:44] <ogra> persia, no idea
[10:44] <mopdenacker> ogra: I kind of disagree. It never hurts to understand the lowlevel formats. Would you still go through elaborate scripts (which could go wrong in multiple ways) to make a quick change to an initramfs if it was just a plain compressed tar archive?
[10:44] <lag> ogra: But I thought that was the solution until UCM comes along
[10:44] <ogra> mopdenacker, yes, always
[10:45] <ogra> lag, what ? editing default.pa ? no, thats no solution to anything
[10:45] <ogra> lag,  as i undrestood we'll get a pulse profile that will fix that
[10:45] <lag> What's the difference between default.pa and the Pulse profile?
[10:46] <ogra> they live in different places and the profile can be card specific
[10:46] <persia> ogra, Please *accept* the maverick task.
[10:46] <lag> Ah, that clears a lot up
[10:46] <lag> I thought they were the same thing
[10:46] <lag> What's the Pulse profile called? And where does it live?
[10:46] <vstehle> persia: I am not sure I understand all the outcomes of your discussion with ogra; what will the end-user see after all? D/l preinstalled image, receive "magical" update due to "older than 7 days", then click icon and everything ok?
[10:46] <lag> /usr/share/pulseaudio/alsa-mixer/profile-sets?
[10:47] <ogra> persia, invalidated the jasper bug for maverick and accepted both tasks
[10:47] <lag> Oh, that's what the default.conf is?
[10:47] <persia> vstehle, That's the idea.  If nothing else, the apt cache update to get the PPA stuff ought get the universe stuff as well.
[10:47] <mopdenacker> ogra: I'm still not sure I will go this way. But thanks for your answers anyway :-)
[10:47] <lag> !help
[10:47] <ubot2> Please don't ask to ask a question, simply ask the question (all on ONE line and in the channel, so that others can read and follow it easily). If anyone knows the answer they will most likely reply. :-)
[10:47] <ogra> mopdenacker, at *least* make sure you pack the initrd the exact same way update-initramfs uses
[10:48] <lag> !commands
[10:48] <ubot2> The linux terminal or command-line interface is very powerful. Open a terminal via Applications -> Accessories -> Terminal (Gnome), K-menu -> System -> Konsole (KDE), or Menu -> Accessories -> LXTerminal (LXDE). Guide: https://help.ubuntu.com/community/UsingTheTerminal
[10:48] <vstehle> persia: But how could you change the apt-cache update in the preinstalled image?
[10:48] <lag> !stupid-bot
[10:48] <ubot2> Factoid 'stupid-bot' not found
[10:48] <lag> !factoids
[10:48] <ubot2> Hi! I'm #ubuntu-arm's favorite infobot, you can search my brain yourself at http://ubottu.com/factoids.cgi | Usage info: http://ubottu.com/devel/wiki/Plugins | Bot channels and general info: https://wiki.ubuntu.com/IRC/Bots
[10:48] <ogra> vstehle, with the update to the -sessings package
[10:48] <persia> vstehle, We don't: when the user updates the apt-cache, the update will show: when they install the update, it will then cause universe to be enabled for the *next* apt-cache update.
[10:49] <ogra> vstehle, on first boot, forst thing the user sees will be update-manager
[10:49] <vstehle> ogra: I don't see that.
[10:49] <ogra> with installing the update, universe and multivers get magically enabled
[10:49] <ogra> vstehle, thats hardcoded
[10:49] <vstehle> ogra: I am testing the preinstalled image on a Panda right now. I never saw the update manager.
[10:50] <persia> Might have to wait until the 17th to see it.
[10:50] <persia> That 7 days thing.
[10:50] <ogra> right
[10:50] <lag> LOl
[10:50] <lag> !sound
[10:50] <ubot2> If you're having problems with sound, click the Volume applet, then Sound Preferences, and check your Volume, Hardware, Input, and Output settings.  If that fails, see https://help.ubuntu.com/community/Sound - https://help.ubuntu.com/community/SoundTroubleshooting - http://alsa.opensrc.org/DmixPlugin - For playing audio files,  see !players and !mp3.
[10:50] <ogra> u-m checks for timestamps
[10:50] <persia> Right.
[10:50] <lag> There's our answers
[10:50] <ogra> you will see it earlier
[10:50] <ogra> the final image for omap4 was built on the 7th
[10:51] <ogra> tomorrow or thursday it shoudl start to show up
[10:51] <persia> But if the apt-cache gets updated for any reason (and there are several things that do this), u-m will notify the user of the updates without waiting.
[10:51] <ogra> right
[10:51] <vstehle> Ok, suppose I am now 7 days later. I install, I am prompted to do the updates, I accept, this adds universe+multivers. Then I click the icon, hopefully this does update the sources _again_ and it works. right?
[10:51] <lag> !botsnack
[10:51] <ubot2> Yum! Err, I mean, APT!
[10:51] <lag> :)
[10:52] <ogra> it does run apt-get update
[10:52] <ogra> it has to, since it enabled a new source
[10:52] <persia> vstehle, That's the idea.
[10:52] <vstehle> Ok, I get it. Thanks!
[10:52] <persia> ogra, No it doesn't: it will only update the apt-cache if the network is on (although the chances of this are astronomically high during SRU application)
[10:53] <ogra> well, it will update the cache once you enable universe
[10:53] <ogra> and it will do that again once you enable the ppa
[10:54] <persia> lag, So, the big things we get out of our specialised default.pa are 1) automatic configuration restoration, 2) automatic detection of devices, 3) bluetooth support, 4) legacy overrides to work around the idea that pulse and alsa and oss somehow compete,
[10:55] <lag> I thought we weren't touching *.pa?
[10:55] <lag> I thought we were using *.conf
[10:55] <ogra> we dont touch default.pa beyond whats there already
[10:55] <persia> 5) cleaner audio load/unload for suspend/resume, 6) integration with console-kit so we don't have to fuss with the audio group and other stuff, 7) positionally meaningful events for cooler integration with libcanberra
[10:56] <ogra> all arch specific changes we do now have to happen elsewhere
[10:56] <persia> Right.  We don't touch default.pa for the special sdp4430 stuff, but that's what the Ubuntu default.pa is configured to "give us"
[10:56] <lag> k
[11:14] <persia> ogra, Are you preparing fixes for this, or do you want patches to review?
[11:14] <ogra> do you have patches ? i'm currently trying to get crimsuns fixes to work
[11:14] <ogra> we need to get rid of the alsactl init
[11:14] <persia> You go work on sound: that's HW dependent, so I can't do it.
[11:14] <ogra> ok
[11:15] <persia> I'll prepare some patches.  Worst case, they'll be ready when you wake tomorrow.
[11:15] <ogra> but first ... coffee
[11:15] <ogra> ok
[11:15] <ogra> this week is key
[11:15] <persia> I'm not going to do the final natty jasper fix now: that needs to be part of the rewrite.
[11:15] <ogra> yep
[11:15] <persia> This week is not an issue.
[11:15] <ogra> well, i wouldnt actually call it a rewrite :)
[11:15] <persia> Just "tonight" is uncertain.
[11:16] <ogra> the main issue is splitting out most of jasper into packages
[11:16] <ogra> the things it does are mostly ok, just not the way
[11:16] <persia> You can continue not to call it a rewrite as long as you like.  I have a huge desire to rearchitect it to such a degree that I expect to retain 0 lines of code.
[11:16] <ogra> thats impossible
[11:17] <ogra> the resizing bit wont be doable anywhere else
[11:17] <ogra> the setup script i agree .... but even that will still need one line (teh enablement of oem-config cant be done anywheer else)
[11:18] <persia> Oh, I might reuse some of the resizing code, actually, but likely nothing else.  Enabling oem-config will happen there, but in an entirely different way.
[11:19] <ogra> you need the rootfs mounted to enable oem-config
[11:19] <ogra> cant happen in jasper_growroot
[11:19] <persia> I know.
[11:19] <berco> hello
[11:20] <persia> Doesn't mean I won't try to do it as d-i controllers anyway.
[11:20] <persia> Hey berco
[11:20] <berco> when an upstart script is installed from a deb package, does it require a posinst script?
[11:20] <berco> I get lintian warning script-in-etc-init.d-not-registered-via-update-rc.d
[11:21] <berco> but i'm confused as the upstart script goes into /etc/init and not /etc/init.d
[11:21] <persia> upstart scripts don't belong in /etc/init.d/ : they belong in /etc/init
[11:21] <berco> so lintian is complaining for nothing?
[11:21] <persia> Are you using dh_installinit?
[11:22] <berco> not specifically
[11:22] <persia> Are you using debian/package.upstart?
[11:22] <berco> persia: yes
[11:22] <berco> but in the rules file, I see "dh $@"
[11:22] <persia> That's fine.
[11:23] <persia> Do you have a manual postinst script for the package?
[11:24] <berco> persia: no
[11:25] <ndec> persia: berco: isn't that better to use cdbs in this case? less chance to get errors, no?
[11:25] <ogra> dh should do the right thing
[11:25] <persia> ndec, No.  Actually, just means one has to know lots more make and slightly less perl to track down the same errors.
[11:25] <berco> ndec: that's what I usually use but not my initial package. I can change it though if needed
[11:26] <persia> But the extra perl for dh(1) is kinda trivial when compared with the perl one needs for dh_* anyway.
[11:27] <berco> persia: ogra: so is this fine to ignore this lintian warning?
[11:27] <persia> berco, Could you paste the output of dpkg --contents foo.deb ("No" is an acceptable answer, but then I want the package name)
[11:27] <ndec> ok. wasn't sure if dh_installinit would be called with just dh $@
[11:28] <ogra> ndec, yes, it is if the file is properly named
[11:28] <persia> dh $@ should call all of them.
[11:28] <ogra> it looks for .init or .upstart
[11:28] <persia> If there's something missing from the sequence, well want it added.
[11:28] <ogra> and puts them in the right places
[11:28] <persia> ogra, Or .default
[11:28] <ogra> .default doesnt go into an init dir
[11:29] <persia> No, but dh_installinit is responsible for installing it anyway.
[11:29] <persia> Puts it in /etc/default/package
[11:29] <persia> Anyway, berco, about those contents?
[11:44] <lag> bug 652035
[11:44] <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
[13:49] <rsalveti> morning
[14:54] <berco> ogra: persia: any issue with launchpad? Impossible to upload or fetch from TI 3PA
[14:55] <ogra> works fine for me
[14:56] <berco> argh
[14:56] <berco> maybe network issue on our side then :(
[14:58] <berco> ndec: does it work for you? try apt-get source tisyslink for e.g
[14:59] <ndec> berco: it's downloading.
[14:59] <ndec> berco: what's the exact problem? any log?
[15:03] <berco> ndec: Err https://private-ppa.launchpad.net/tiomap-dev/private-release/ubuntu/ maverick/main tisyslink 0.24.9.2-0ubuntu7 (tar)
[15:03] <berco>   gnutls_handshake() failed: A TLS packet with unexpected length was received.
[15:03] <berco> Failed to fetch https://berco:xxx@private-ppa.launchpad.net/tiomap-dev/private-release/ubuntu/pool/main/t/tisyslink/tisyslink_0.24.9.2.orig.tar.gz  gnutls_handshake() failed: A TLS packet with unexpected length was received.
[15:03] <berco> E: Failed to fetch some archives.
[15:03] <berco> ndec: was working a few min ago
[15:03]  * berco should have pastebin this log
[15:06] <lool> berco: Looks like a network issue
[15:07] <ndec> lool: but I am sitting less than 3 meters away from berco and it works for me ;-)
[15:09] <rsalveti> ndec: do you need proxy in your network?
[15:09] <rsalveti> maybe it's missing something
[15:10] <lool> ndec: At so it's a PBCAK
[15:10] <lool> ;-)
[15:15]  * berco damned. corkscrew killed and everything goes back to normal
[15:51] <mpoirier> GrueMaster: good morning
[15:54] <GrueMaster> mpoirier: good morning.
[15:55] <mpoirier> GrueMaster: a couple of weeks ago you gave me a command that plays sound, alternating from one speaker to another.
[15:55] <mpoirier> I noted it somewhere but to save my life, can't find it anymore.
[15:55] <GrueMaster> speaker-test -c 2 -t wav
[15:55] <mpoirier> yes, thanks.
[15:56] <GrueMaster> This will play directly through the hardware.
[15:56] <GrueMaster> No pulse.
[15:57] <mpoirier> I'm getting *nothing*...
[15:57] <GrueMaster> On which platform?
[15:58] <mpoirier> I'm panda, I'm testing the new patches sent by Irg
[15:58] <ogra> mpoirier, they are not complete
[15:58] <ogra> and you also need to make sure to have no state file
[15:59] <mpoirier> state file ? please expand.
[15:59] <GrueMaster> /var/lib/alsa/asound.state I believe.
[15:59] <mpoirier> hold on, checking.
[15:59] <ogra> right, you need to disable its creation
[15:59] <ogra> else you wil always get the same state
[16:00] <mpoirier> indeed I have such file.
[16:00] <mpoirier> how to I prevent its creation ?
[16:02] <mpoirier> Irg: good morning - I have your patches live on my card.
[16:02] <ogra> for the init file you need to call alsactl init manually after boot
[16:03] <lrg> mpoirier: morning
[16:03] <mpoirier> ogra: i did.
[16:03] <mpoirier> Irg: is there something you'd like me to check ?
[16:04] <mpoirier> Irg: I have all 4 patches, the new 00main and omap4.
[16:04] <lrg> mpoirier: ok, have you ran alsactl init ?
[16:04] <mpoirier> Irg: I also manually ran alsactl init
[16:04] <mpoirier> yes.
[16:05] <lrg> ok, does audio work at this point
[16:05] <lrg> ?
[16:05] <mpoirier> I tried "speaker-test -c 2 -t wav" without results.
[16:05] <mpoirier> I get clear silence.
[16:05] <lrg> ok, what does cat /proc/asound/cards show ?
[16:06] <mpoirier> that's the first thing I checked and it seems right to me.  Hold on.
[16:06] <mpoirier> mpoirier@panda:~$ cat /proc/asound/cards
[16:06] <mpoirier>  0 [Panda          ]: OMAP4 - Panda
[16:06] <mpoirier>                       TI OMAP4 Board
[16:06] <mpoirier> mpoirier@panda:~$
[16:06] <lrg> ok, cool :)
[16:06] <mpoirier> yes, at least that works.
[16:06] <mpoirier> any sound control you're interested in ?
[16:07] <ogra> that lookd fine
[16:07] <ogra> *looks
[16:07] <lrg> what about aplay -Dplughw:0,0 -f dat /dev/urandom
[16:07] <mpoirier> Irg: yes, success.
[16:08] <lrg> ok, the ABE uses some non standard formats
[16:08] <mpoirier> please expand.
[16:08] <lrg> everything has to go via alsaplugins atm
[16:08] <lrg> well it uses S32_LE instead of S16_LE for PCM format
[16:09] <mpoirier> Irg: educate me: what makes you say that ?
[16:10]  * rsalveti lunch
[16:10] <lrg> mpoirier: it's all in the TRM
[16:11] <mpoirier> Irg: ok, I'll check it out.
[16:11] <lrg> the plugin converts wav S16_LE to ABE S32_LE
[16:11] <lrg> for playback
[16:11] <lrg> and vice versa for capture
[16:13] <mpoirier> Irg: should I understand my test results aren't a surprise to you ?
[16:13] <ogra> lrg, i dont think your omap4 file can work
[16:13] <ogra> lrg, as i understand, the init files need to use dB values, you use absolute numbers everywhere
[16:14] <lrg> ogra: iirc, thay can use both since some drivers do not export dB info
[16:15] <ogra> well, when i tested, absolute values didnt work
[16:15] <ogra> but i'm happy to be proven wrong :)
[16:15] <lrg> ogra: ok, I'll ping Abraham as he craeted the file
[16:15] <ogra> did he test it ?
[16:15] <lrg> I did, on SDPand it worked for me
[16:15] <ogra> ok
[16:16] <ogra> then it shoudl work on panda too
[16:16] <lrg> I'm pretty sure I removed the old state file too - but it was quite late at night though
[16:16] <ogra> you also need to disable its recreation
[16:17] <ogra> it comes back with every boot and is executed immediately on device init by a udev rule
[16:17] <ogra> move /etc/init/alsa-mixer-save.conf to /etc/init/alsa-mixer-save.conf.old
[16:18] <lrg> ogra: ok thanks, I'll check this after some food
[16:18] <lrg> abduenas: morning Abraham
[16:18] <abduenas> hi
[16:19] <lrg> abduenas: ogra has some questions about the config file
[16:19] <ogra> abduenas, hey, i didnt get the init file to work when i used absolute numbers and had to use dB instead
[16:19] <lrg> abduenas: I have to go, will be back in 30m
[16:20] <abduenas> hmm really? it work for me with those numbers
[16:20] <ogra> back last week when i created the first version of it which is attached to the bug
[16:20] <ogra> liam said it works for him too
[16:20] <ogra> so it was probably a temporary glitch on my side
[16:20] <ogra> just wanted to know if you are sure one can use absolute numbers too
[16:22] <abduenas> yes i used to manually set to zero then alsactl init and then check the status on alsamixer it was resotred properley
[16:22] <ogra> oki
[16:22] <ogra> thanks
[16:22]  * ogra takes a break too and will then test the alsa-lib fix
[16:22] <abduenas> no prob... i can try your dB also if you want
[16:23] <ogra> i havent tested the new file yet
[16:23] <ogra> so dont worry
[16:23] <abduenas> oki
[16:25] <berco>  pushed my source package 30min ago and since then launchpad says it will start in 1min... is it blocked in some ways?
[16:35] <berco> abduenas: haven't tested yet your file. still busy w/ today release
[16:38] <abduenas> berco: no prob
[16:48] <oOSkar> Hi
[16:49] <oOSkar> I need little help on Ubuntu on my Beagleboard
[16:49] <oOSkar> I don't have any username-password after using https://wiki.ubuntu.com/ARM/OMAPMaverickInstall
[16:49] <oOSkar> system boots perfectly but i'm blocked at login
[16:50] <GrueMaster> oOSkar: Which image did you use?
[16:51] <oOSkar> I used ubuntu-netbook-10.10-preinstalled-netbook-armel+omap.img.gz
[16:52] <GrueMaster> Did it run the firstboot scripts that resize the root partition?  It should have been on the display.
[16:53] <oOSkar> i did not see any firstboot script
[16:53] <oOSkar> display was : orange (beagleboard boot) then black (linux booting on serial) and finally ubuntu purple login
[16:54] <oOSkar> i've rewritten the SD card to try again but still no script running
[16:54] <GrueMaster> Reboot but this time hold down the user button while the board resets.  This will load the boot loader from the sd card.
[16:55] <GrueMaster> You should not see an orange background while this boots.
[16:56] <oOSkar> trying
[16:57] <oOSkar> no change
[16:57] <GrueMaster> Is this a beagle C4?
[16:57] <oOSkar> yep
[16:58] <GrueMaster> Note that this image will be at the edge of what can run on that board.  256M memory is very limiting.
[16:59] <GrueMaster> There are special directions for C4 on the wiki, below the BeagleXM & Panda instructions.
[16:59] <GrueMaster> You need to have a serial console open to run a uboot script.
[17:00] <oOSkar> i have the serial console
[17:00] <oOSkar> i don't see any instruction for C4 on the wiki
[17:01] <ogra_ac> it falls under "older beageboards"
[17:01] <GrueMaster> Look for the "older beagleboards" section.
[17:01] <oOSkar> (note that this step is only necessary if you have a NAND and the system does not default to reading boot.scr)
[17:01] <oOSkar> hum, i may have read it too fast
[17:01] <oOSkar> as the system was booting i tought it would have been unnecessary
[17:02] <ogra_ac> the image wont be much fun on an old C4
[17:02] <oOSkar> it's not that old
[17:02] <ogra_ac> it will swap a lot and be reather slow
[17:03] <oOSkar> but i agree that boot is quite slow
[17:03] <ogra_ac> the images are built for HW with 512M
[17:03] <oOSkar> i've used debian on it previously but wanted to try some more hardware
[17:03] <ogra_ac> it will run indeed but dont expect speed
[17:03] <oOSkar> but i can remove a lot of the stuff from that ubuntu version manually
[17:04] <ogra_ac> sure
[17:04] <ogra_ac> if you are patient enough to finish the install :)
[17:04] <oOSkar> script is running now, thx :)
[17:04] <ogra_ac> its all graphical
[17:05] <oOSkar> "setting up swap" oO
[17:05] <ogra_ac> yeah, that will take a while
[17:05] <oOSkar> i don't want swap on a 4Go microSD card :/
[17:06] <ogra_ac> you do
[17:06] <ogra_ac> else the installer wont run
[17:06] <oOSkar> that's quite a strenge choice
[17:06] <ogra_ac> choice?
[17:06] <oOSkar> *stange
[17:07] <oOSkar> you mean that the installer would need more than 256Mo of RAM ?
[17:07] <ogra_ac> the image is built for beagle XM or panda boards
[17:07] <GrueMaster> X and gnome use a lot.
[17:07] <ogra_ac> right
[17:07] <ogra_ac> well, actually they dont once everything is up
[17:08] <ogra_ac> htop on my ac100 here shows only 162M used
[17:08] <ogra_ac> and i have firefox and xchat open
[17:09] <oOSkar> did i read "ac100" ?
[17:09] <ogra_ac> yes
[17:09] <oOSkar> i was thinking about buying one
[17:09] <oOSkar> but still hesitating vs tablets
[17:09] <ogra_ac> what would you do with a tablet ?
[17:10]  * ogra_ac really doubts their usability if yuo actually want to type etc ....
[17:10] <oOSkar> surfing, email, programming, sys admin over ssh
[17:10] <ogra_ac> programming ?
[17:10] <ogra_ac> on a virtual kbd ?
[17:10] <oOSkar> with usb keyboard they might be quite usable no ?
[17:10] <ogra_ac> yeah, that might work if you like to carry around a stand to put the tablet on
[17:11] <oOSkar> what do you think about the ac100 ?
[17:11] <oOSkar> everything working on ubuntu ?
[17:11] <ogra_ac> but before i carry a USB kbd plus a tablet plus a stand i rather use an ac100 :)
[17:11] <ogra_ac> no, not everything
[17:11] <ogra_ac> but getting there
[17:12] <ogra_ac> the only kernel they provide is 2.6.29 so much stuff isnt as gooc supported as it could be
[17:13] <ogra_ac> and things like powermanagement are completely done by a proprietrary tool
[17:13] <ogra_ac> same goes for sound
[17:13] <ogra_ac> its nvidia after all
[17:14] <oOSkar> ok
[17:14] <oOSkar> that's sad
[17:15] <ogra_ac> well, its good enough for working
[17:15] <GrueMaster> oOSkar: If you want to customize the beagle image, you could use rootstock or you could try installing from the net with the untested netboot install image from http://ports.ubuntu.com/dists/maverick/main/installer-armel/20100211ubuntu29/images/omap/netboot/omap/
[17:16] <oOSkar> thx GrueMaster ;)
[17:16] <oOSkar> i finally see the config graphic screen
[17:16] <GrueMaster> cool
[17:16] <oOSkar> you would have guessed it, it's quite very very slow
[17:16] <ogra_ac> GrueMaster, btw, there is a shorter url for netboot now :)
[17:17] <ogra_ac> http://cdimage.ubuntu.com/netboot/maverick/
[17:17] <GrueMaster> ogra_ac: That lists links to what I just pasted.
[17:18] <oOSkar> thx for these links, look quite interesting :)
[17:18] <ogra_ac> right
[17:23] <oOSkar> do you know where i can change the bootargs environment variable ? is it on the SD card or using the bios from the beagleboard ?
[17:24] <GrueMaster> It is in the boot.scr on the first partition.  You can change it by editing the /boot/boot.script on the rootfs and running sudo flash-kernel.
[17:25] <GrueMaster> THis is the easiest method.
[17:25] <oOSkar> ok thx
[17:26] <oOSkar> @ogra_ac : do you still have good autonomy without power management ? is there only sound missing ?
[17:27] <ogra_ac> well, under android the ac100 has about 7h, on ubuntu its 4-5 depending on what i do
[17:28] <oOSkar> ok
[17:28] <oOSkar> and how is the android ? still usable for a hacker ?
[17:28] <ogra_ac> havent tried how long it lasts with wifi off and 3g on yet
[17:28] <ogra_ac> android is completely unusable imho
[17:29] <ogra_ac> its a great phone OS but should stay there
[17:29] <ogra_ac> might be usable on tablets but surely not for netbooks
[17:29] <oOSkar> ok
[17:30] <ogra_ac> try an ac100 at a dealer and you will understand :)
[17:30] <oOSkar> if i find one ^^
[17:30] <oOSkar> i've seen the videos and it looked strange, but wasn't sure
[17:39] <oOSkar> thanx for all your advices ;)
[17:39] <oOSkar> see ya !
[17:42] <GrueMaster> ogra_ac: http://www.engadget.com/2010/10/13/specs-released-for-advent-vega-the-249-android-tegra-tablet/
[17:44] <ogra_ac> looks like an ac100 without kbd :P
[17:57] <berco> ogra_ac: what's wrong with the build machines?
[17:57] <berco> I'm waiting for more than 2 hours...
[17:58] <ogra_ac> berco, ask #soyuz or #launchpad
[17:58] <berco> ogra_ac: thx
[19:28] <ogra> lrg, lag, berco ... (and who else is involved in panda sound) i tested the alsa-lib fix and updated bug 637947 ... please someone provide a kernel package with the other changes so i can test the other init file
[19:28] <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] https://launchpad.net/bugs/637947
[19:28]  * ogra vanishes into his evening again
[19:30] <rsalveti> GrueMaster: can you check the x-loader build date from the released image?
[19:31] <GrueMaster> Sure in a few minutes.  (currently hobbled with bad knee).
[19:31] <rsalveti> ouch, np
[19:33] <rsalveti> ogra_ac: at http://cdimage.ubuntu.com/ubuntu-netbook/ports/releases/10.10/release/, preinstalled USB image
[19:34] <rsalveti> it should be sd image, I believe
[19:34] <ogra_ac> rsalveti, yeah
[19:34] <ogra_ac> we need to fix that for natty
[19:35] <ogra_ac> .img files are by default set to USB image in the scripts
[19:35] <rsalveti> ogra_ac: oh, ok
[19:35] <rsalveti> ogra_ac: and when are we getting natty images?
[19:36] <ogra_ac> i want an SD card icon too :)
[19:36] <ogra_ac> not sure
[19:36] <rsalveti> yup :-)
[19:36] <ogra_ac> they wont be usable anywy before alpha 1
[19:36] <rsalveti> true, but just to know
[19:36] <ogra_ac> so dont worry about image now
[19:36] <ogra_ac> we'll start building them after UDS
[19:37] <ogra_ac> as soon as there is an archive :)
[19:37] <ogra_ac> toolchain and basic packages usually take a week to ten days
[19:38] <rsalveti> cool
[19:39] <ogra_ac> the sound seems to sort itself now too
[19:39] <ogra_ac> seems we have all bits
[19:40] <rsalveti> nice, still need to read the backlog and emails about it
[19:40] <ogra_ac> we had a very fruitful meeting yesterday thanks to lag :)
[19:40] <ogra_ac> he got all involved parties together
[19:41] <rsalveti> nice
[19:41] <ogra_ac> and even more imprtant, the issue with alsactl init was actually a alsa-lib bug
[19:41] <ogra_ac> fix is already pending for SRU
[19:41] <rsalveti> oh, so it was really a bug :-)
[19:41] <ogra_ac> yeah
[19:42] <ogra_ac> Bug #652035
[19:42] <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
[19:44] <GrueMaster> rsalveti: Texas Instruments X-Loader 1.41 (Oct  6 2010 - 17:27:48)
[19:45] <GrueMaster> I don't think that is the right one.
[19:45] <lag> I'll post my email onto the LP bug so people not involved can read
[19:45] <lag> Give me a moment
[19:45] <ogra_ac> lag, no hurry
[19:46] <ogra_ac> would be good to get lrg's patches too there
[19:46] <lag> ;)
[19:46] <lag> There's nothing stopping you ;)
[19:46] <ogra_ac> yeah, there is alwas tomorrow ... i wont go upstaris again today, testing the alsa-lib stuff was enough at that time
[19:47] <rsalveti> GrueMaster: cool, thanks
[19:47] <rsalveti> GrueMaster: that should be the one
[19:47] <GrueMaster> I'm redownloading from the above link for comparison.
[19:47] <rsalveti> for some reason I flashed the wrong image
[19:47] <lag> rsalveti: bug 637947
[19:47] <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] https://launchpad.net/bugs/637947
[19:47] <GrueMaster> Ah
[19:50] <rsalveti> GrueMaster: for some reason when I got the rc instead of the release when using zsync
[19:50] <rsalveti> probably lack of coffee
[19:50] <GrueMaster> Oops.
[19:50] <rsalveti> so I was surprised when I saw x-loader from september hehe
[19:51] <rsalveti> ooops
[19:51] <ogra_ac> yeah, we need to make sure the coffee is compiled in in the future so you dont need it additionally
[19:52] <lag> Kaffine?
[19:52] <ogra_ac> sounds like it would depend on QT
[19:53] <rsalveti> argh...
[19:53] <rsalveti> qt doesn't taste good
[19:54] <ogra_ac> heh
[19:55] <mpoirier> ogra_ac: I just read your email.
[19:55] <mpoirier> ogra_ac: you need a kernel with the 4 patches suplied by Irg ?
[19:56] <ogra_ac> mpoirier, yeah, tomorrow though
[19:56] <ogra_ac> wont test today anymore
[19:56] <ogra_ac> but his patch names the card based on the board
[19:56] <mpoirier> ogra_ac: yes,
[19:56] <ogra_ac> to test the switching init file we need the name
[19:57] <mpoirier> ogra_ac: cat /proc/asound/cards does yield panda
[19:57] <lag> mpoirier: I'm assuming you mean lrg? :)
[19:57] <mpoirier> lag: Irg yes
[19:57] <lag> No lrg
[19:58] <ogra_ac> like a small L
[19:58] <ogra_ac> :)
[19:58] <lag> :)
[19:58] <mpoirier> ogra_ac: are you looking for a .deb ?
[19:59]  * GrueMaster hobbles back out to the couch where laptop & ice pack awaits.
[19:59] <ogra_ac> mpoirier, right
[19:59] <mpoirier> you'lll have a link in you inbox tomorrow.
[19:59] <mpoirier> I'll get to it by the end of my day.
[20:00] <ogra_ac> sweet !
[20:00] <ogra_ac> thanks a lot
[21:02] <sguiriec> mpoirier:if you want to have more data about OMAP4 ABE paths you can look at the next link  (http://www.omapzoom.org/wiki/File:Omap_abe.jpg http://www.omapzoom.org/wiki/File:ASoC_OMAP4.jpg). first one is mainly Audio Back End path. The second one is mapping the kernel audio controls on the graph.
[21:03] <sguiriec> mpoirier: I hope it will be the missing part for your understanding
[21:04] <mpoirier> sguiriec: this is very cool thanks - at first glance there is a fair a mount of things that are new to me.
[21:05] <sguiriec> mpoirier: OMAP4 audio is very different from OMAP1/2/3. ABE and McPDM introduce new functionalities.
[21:06] <mpoirier> ya - someone else (can't remember who) in TI told me the same.
[21:07] <sguiriec> mpoirier: May be berco
[21:07] <mpoirier> probably yes.
[21:07] <mpoirier> he was the first person to enlight me in this matter
[21:11] <lag> mpoirier: I didn't think you were working on this anymore?
[21:12] <sguiriec> mpoirier: I am still working and helping on the driver
[21:12] <mpoirier> lag: I was waiting for that info - now I can move forward.
[21:12] <mpoirier> lag: it has a lot of the missing peices we were talking about.
[21:17] <lag> I was under the impression that all the outstanding tasks have been already issued
[21:17] <lag> What needs to be done that I am unaware of?
[21:19] <lag> mpoirier: ?
[21:19] <mpoirier> lag: yep
[21:19] <lag> --^
[21:20] <mpoirier> lag: sorry - I had not seen your post.
[21:20] <mpoirier> lag: everything has been covered.
[21:20] <mpoirier> I peeled the sdp4430.c and twl6040.c a couple of weeks ago.
[21:21] <mpoirier> but there was something missing,
[21:22] <mpoirier> those two files we setting forth the BE and FE but again, the path between them was incomplete.
[21:22] <mpoirier> I was specifically interested to know how berco came up with the setting of the alsamixer.sh file
[21:22] <mpoirier> that file was bridgin ABE, BE and FE together.
[21:23] <mpoirier> I was missing part of the puzzle.
[21:23] <sguiriec> mpoirier: Nomally should be more clear for you now.
[21:23] <mpoirier> sguiriec just painted the missing part.
[21:24] <mpoirier> lag: there was a grand scheme I couldn't see - and you could not have deduce the information from the TRM or the schematics.
[21:24] <mpoirier> drove me nuts.
[21:25] <lag> Okay
[21:25] <lag> So it was more a quest for information
[21:25] <mpoirier> yes, 'cause we are bound to do this again...
[21:25] <mpoirier> whenever another omap4 board gets spun off.
[21:26] <lag> I don't believe that to be the case
[21:26] <mpoirier> the more we know, the better we can point out problems and work with TI.
[21:26] <lag> Well ...
[21:26] <lag> Maybe
[21:27] <lag> So, are you happy that all the tasks have been addressed for Panda -> Maverick?
[21:27] <mpoirier> I have nothing more to requets
[21:27] <lag> Okay
[21:28] <lag> Try not to spend any more time on it, testing not withstanding
[21:29] <lag> If you believe we have missed something, let me know and I will endeavour to address it asap