[08:19] <hrw> morning
[09:38] <cooloney> ogra: does USB EHCI of ES2.0 work with our Ubuntu daily live image?
[09:39] <ogra_ac> yep
[09:39] <ogra_ac> kbd and mouse work fine on 6 and 8 layer for me
[09:40] <ogra_ac> the NIC too (usb NIC)
[09:41] <hrw> nice
[09:42] <cooloney> ok, let me try again.
[09:42] <cooloney> thx, man
[09:42] <ogra_ac> do you have issues ?
[09:43]  * ogra_ac didnt try todays image, yesterdays worked fine
[09:46] <cooloney> ogra_ac: i am trying Sep 11 daily image
[09:46] <cooloney> but usb EHCI doesn't work
[09:48] <ogra_ac> weird
[09:49] <ogra_ac> cooloney, 6 or 8 layer ?
[09:50] <cooloney> ogra_ac: 8 layers
[09:51] <cooloney> ogra_ac: i tried EHCI ports before with maverick rootfs from rootstock
[09:51] <cooloney> it works on my 8 layers
[09:52] <ogra_ac> well, all i can say is that it works flawless here
[09:52] <cooloney> ogra_ac: if you think yours is working fine, never mind. maybe it's my bad.
[09:52] <cooloney> ogra_ac: ok, got it.
[09:52] <ogra_ac> with teh dsailsy it should just work for you too
[09:52] <ogra_ac> *daily
[09:53]  * ogra_ac recommends to zsync to the latest
[09:54] <ogra_ac> though there wasnt a kernel change between 11th and today afaik
[09:56] <ogra_ac> oh, wait
[09:56] <ogra_ac> the metapackage was screwed until teh 12th
[09:57] <ogra_ac> you might still have the old ES1.0 kernel on the image from the 11th
[09:57] <cooloney> oh, i'm just wanna zsync that
[09:57] <cooloney> ogra_ac: ok, i got it.
[09:57] <cooloney> ogra_ac: let me zsync it
[09:57] <ogra_ac> yeah, use todays
[09:58] <ogra_ac> intresting that it boots at all
[09:58] <ogra_ac> i think mine got stuck on teh 6 layer when i tried it with the old kernel
[09:58] <ogra_ac> during first boot
[10:01] <cooloney> ogra_ac: thanks for helping this. i'm zsyncing
[10:01] <ogra_ac> cool
[11:07] <lag> ogra: Is there any reason why the ES2.0 wouldn't boot with CONFIG_PM enabled?
[11:07] <ogra> lag, ask ndec
[11:07] <ogra> (if he returns)
[11:08] <ogra> lag, all i was told is that the HW doesnt support it yet
[11:08] <ogra> and wont for maverick
[11:08] <lag> k
[11:08] <lag> I've done some testing and it doesn't even boot
[11:08] <lag> No boot-up messages at all
[11:08] <ogra> but ndec should be able to tell you if it gets in our way
[11:09] <ogra> ah, so it does then :)
[11:09] <lag> I'll move on to something else for the time being
[11:09] <lag> Quite
[11:09] <ogra> you could fix some userspace bugs if you are bored :P
[11:09] <ogra> we have enough of them
[11:20] <ogra> lag, how about ASoC stuff ?
[11:21] <ogra> we still  have no working sound and TI wants to use asound.conf,getting the driver improved to not need that would be an awesome fix
[11:25] <lag> ogra: I though it worked?
[11:25] <lag> ogra: Or was that ES1.0?
[11:25] <ogra> HDMI might
[11:25] <ogra> no it never worked properly
[11:26] <ogra> for the normal system we should default to the earphone plug ... with an option to switch over to HDMI in the sound prefs
[11:26] <lag> prpplague was working on it
[11:26] <lag> I'm sure he submitted patches
[11:26] <ogra> in ES1.0 i saw the HW at least but couldnt switch (and i think with that sound came out of HDMI)
[11:27] <ogra> with ES2.0 i dont see a sound device at all atm
[11:27] <ogra> lag, he is working on a very raw implementation that requires asound,conf
[11:27] <lag> Create a bug
[11:27] <lag> And assign me
[11:27] <ogra> our audio team usually doesnt allow using that file
[11:28] <ogra> (though we'd do it as a workaround from jasper if we cant get it fixed, but if there is any opportunity to get it fixed properly that would be better)
[11:48] <lag> ogra: Have you reported a bug yet?
[11:48] <ogra> nop
[11:52] <ogra> lag, bug 637947
[11:52] <ubot2> Launchpad bug 637947 in linux-ti-omap4 (Ubuntu Maverick) (and 1 other project) "no sound devices on current ES2.0 boards (affects: 1) (heat: 8)" [High,New] https://launchpad.net/bugs/637947
[11:57] <lag> Ta
[12:06] <ogra> persia, i'm wondering if we couldnt just use a case statement for jasper cmdline parsing ... if anything is set we just dont touch it
[12:06] <persia> lag, I recall you and I discussing this about a month ago: it either needs proper quirking *OR* board-drivers.
[12:07] <ogra> persia, talking about sound or PW ?
[12:07] <ogra> err
[12:07] <ogra> PM
[12:07] <persia> Sound.
[12:07] <ogra> well, TI brought it up on friday and they say there is no time to fix it in driver on their side
[12:08] <ogra> so asound.conf would be our last resort
[12:08] <persia> Assuming you're talking about bug #605831, the issue with a case statement is that we only want to set things if they *aren't* present.  You'd have to track a lot of state.
[12:08] <ubot2> Launchpad bug 605831 in jasper-initramfs (Ubuntu Maverick) (and 1 other project) "Resolution should be taken from /proc/cmdline if provided (affects: 1) (heat: 73)" [Medium,Triaged] https://launchpad.net/bugs/605831
[12:08] <ogra> but i'D rather not use it if we can make it happen properly anyhow
[12:08] <persia> Those aren't the only choices (and asound.conf is a very poor choice).
[12:09] <persia> In addition to those two, we have 1) kernel quirking to hint various devices if they don't report properly (this is done *extensively* for Intel HDA, as an example).
[12:09] <ogra> well, feel free to make suggestions for fallbacks on the bug above
[12:09] <ogra> we can surely create an asound.conf from jasper as last resort ... any better solution is indeed preferred
[12:10] <persia> And 2) the extensible constructed ALSA configuration, which happens dynamically in /usr/lib/alsa-lib
[12:11] <persia> Please, please, don't create an asound.conf in jasper.
[12:11] <persia> If nothing else, that will likely break all USB audio.
[12:11] <persia> Potentially bluetooth as well.
[12:11] <ogra> well, all suggestions are welcome
[12:12] <ogra> if you have a better way we shoudl use that one
[12:12] <persia> Drop a conf fragment in /usr/share/alsa/ somewhere that only gets used for omap.
[12:12] <persia> We'll end up with broken support for omap boards other than those identified for testing, but it won't be more broken than an asound.conf, and will be much easier to fix.
[12:13] <persia> I *think* the best place is probably under /usr/share/alsa/init/omap or similar
[12:13] <ogra> k, can you add a comment on the bug
[12:14] <persia> sure
[12:14] <ogra> (make sure though thats its a fallback, preferred solution is still in kernel)
[12:15] <lag> persia: Yes we did
[12:15] <lag> prpplague: Are you here yet?
[12:19] <persia> ogra, please review that comment: I hope it's clear enough.
[12:19] <prpplague> lag: where is here?
[12:19] <persia> prpplague, In front of a device connected to IRC and viewing this channel :)
[12:19] <ogra> i guess he meant there :)
[12:19]  * prpplague is travelling today and be back in the office tomorrow
[12:19] <prpplague> hehe
[12:21] <prpplague> lag: whatcha working on now?
[12:22] <ogra> prpplague, i just created bug 637947 for him
[12:22] <ubot2> Launchpad bug 637947 in linux-ti-omap4 (Ubuntu Maverick) (and 1 other project) "no sound devices on current ES2.0 boards (affects: 1) (heat: 8)" [High,Confirmed] https://launchpad.net/bugs/637947
[12:22] <ogra> (which is why you got pinged i assume)
[12:23] <lag> prpplague: Hi David
[12:23] <lag> We were speaking about audio a few weeks ago
[12:23] <lag> I believe you were going to release some patches to make it work on the ES1.0
[12:24] <persia> A board driver?
[12:29] <prpplague> lag: yea there was a handoff, the announcement went on the pandaboard list
[12:29] <prpplague> lag: you can get the latest sources at gitorious/pandaboard
[12:29] <prpplague> lag: the L24.9 branches
[12:33] <lag> prpplague: And they will make sound work on the ES2.0?
[12:33] <lag> I believe we have the majority of L24.9
[12:50] <lag> prpplague: When you say the pandabaord list, do you mean on IRC, or is there a mailing list?
[12:57] <sebjan> lag: the last audio patches I pushed on my tree (for-ubuntu-2.6.35) are post L24.9, and are not in prpplague's tree
[12:58] <lag> sebjan: I have just fetched from your tree, which is building now
[12:58] <lag> :)
[12:58] <sebjan> lag: ok, cool :)
[12:58] <lag> :)
[13:02] <lag> cooloney: ping
[13:18] <prpplague> lag: there is a mailing list
[13:18] <lag> I've has a quick Google for it, but to no avail
[13:18] <lag> Would you be so kind as to link me to it please?
[13:22] <berco> lag: email: pandaboard@googlegroups.com
[13:22] <berco> lag: Link: http://groups.google.com/group/pandaboard
[13:24] <ndec> ogra: i just subscribed you to 587632. any chance this can be fixed for 10.10? the problem is that when gst-ugly is installed it will superseed gst-ffmpeg which works fine on arm.
[13:24] <ogra> bug 587632
[13:24] <ubot2> Launchpad bug 587632 in libmad (Ubuntu) "Sound very distorted on armel (affects: 2) (heat: 18)" [Undecided,Confirmed] https://launchpad.net/bugs/587632
[13:24] <lag> berco: I did find that
[13:24] <lag> berco: Is it just a matter of joining that group?
[13:26] <berco> lag: I think so
[13:26] <ogra> ndec, lets ask linaro if they want to work on a fix, else we can indeed build with -marm
[13:26] <berco> lag: honnestly I haven't tried yet
[13:26] <persia> Given the proximity to release, let's just use -marm
[13:26] <lag> I can't join
[13:27] <lag> You need to have a Google account
[13:28] <ndec> lag: yes you always need a google account to subscribe google groups I believe.
[13:28] <berco> lag: I believe so. I just tried with my google account and I'm now a member of the group
[13:29] <ndec> lag: you can create a new google account with an existing email address. in that case it would give you a google account without gmail.
[13:52] <mythripk> robclark:gm i saw some talk related to EDID ?
[13:52] <robclark> hi mythripk..
[13:53] <robclark> yeah..  but mpoitier doesn't seem to be around atm..
[13:53] <mythripk> hmm , I should be able to get the code with seperate edid.c by this weekend
[13:53] <robclark> same thing we were talking about the other day, about how to support EDID for DVI/other drivers..
[13:54] <robclark> ok, very cool
[13:54] <mythripk> ya with your patch for DVI as well , i have the old regular code for EEDID
[13:54] <robclark> ahh, hi mpoirier
[13:55] <ogra> speaking of the devil :)
[13:55] <robclark> indeed
[13:55] <mythripk> :)
[13:55] <robclark> finally mpoirier and mythripk in same channel at same time ;-)
[13:55] <ogra> we should remove europe ... that gets the timezones closer together :)
[13:56] <robclark> heheh, I'm not sure if it works that way..
[13:56] <mpoirier> ogra: but I like Europe...
[13:56] <mpoirier> great for vacation.
[13:56] <robclark> mpoirier: mythripk had mentioned: "hmm , I should be able to get the code with seperate edid.c by this weekend"
[13:56] <ogra> lol
[13:56] <mpoirier> robclark: cool - on what processor ?
[13:56] <rsalveti> mythripk: hm, also interested on that :-)
[13:57] <mpoirier> robclark: rsalveti is heading that project now.
[13:57] <mythripk> hmm k then let me send the code for review once im done
[13:57] <rsalveti> mythripk: cool
[13:57] <mythripk> would you like some heads up ?
[13:58] <mpoirier> mythripk: yes please.
[13:58] <rsalveti> mythripk: what you're planing to do for improving the edid code on omap4?
[13:58] <rsalveti> the edid parsing
[13:58] <robclark> mpoirier: I guess this would be on omap4 kernel, but we should start trying to apply some of the patches on both to align omap3 and omap4 code..
[13:58] <robclark> rsalveti: ^^^^
[13:59] <rsalveti> robclark: yep, that's what I was looking for
[13:59] <rsalveti> trying to integrate at least the parsing code
[13:59] <mythripk> create a seperate edid.c file which will handle all the edid and eedid code
[13:59] <robclark> yup
[13:59] <mpoirier> rsalveti: I can assist if need be.
[13:59] <rsalveti> and trying to use the common kernel api for it
[13:59] <rsalveti> mpoirier: cool
[14:00] <mythripk> hmm ive seen some changes on omap3 done by srinivas i could send out those patches...
[14:00] <robclark> rsalveti: just keep in mind, in some use cases you might have hdmi display, but no framebuffer, only v4l2 device..
[14:00] <mythripk> yup , it is independent of v4l2 or fb and tied to hdmi.c
[14:01] <mythripk> rsalverti, rob and mpoirier do you have any specific suggestions...
[14:02] <rsalveti> robclark: true, but it shouldn't be tied with fb
[14:03] <robclark> mythripk: just one... ideally somehow the edid parsing code could return a list/array of supported timings.  Because eventually we want omapfb to populate modedb table with all supported modes
[14:04] <mpoirier> mythripk: you are miles ahead of me on the topic - I'll let you run with it.
[14:05] <mythripk> robclark:hmm , i could add that but problem is there could be duplicates and problem with number of entries..
[14:05] <mythripk> becaue the 8 timing blocks timing data and the SVD block preferred timing data will overlap
[14:06] <mythripk> and for DVI the standard timing data also should be populated...
[14:09] <robclark> mythripk: probably most important is the # of distinct resolutions.. if you have multiple supported timings that are same resolution, maybe it doesn't matter so much which you pick
[14:10] <robclark> the use case is just letting userspace pick from available supported resolutions
[14:11] <mythripk> hmm ok then let me create a list and if the timing is valid , i shall populate all the values onto it...
[14:12] <robclark> mythripk: I guess it shouldn't hurt, tho, if you populate the list with multiple timings that are same resolution..  I guess either way would work
[14:14] <mythripk> robclark: yup not parsing for a duplicate , i shall populate if valid ... only thing i need to do is convert Short video descriptor to resolution string..
[14:15] <robclark> mythripk: I think it is ok to be a list/array/iterator of struct omap_video_timings
[14:18] <mythripk> ya but SVD info will only give CEA code so need to populate it into a timing
[14:18] <mythripk> k then time to head for my bus , i shall send the edid.c by this friday or so... good day
[14:18] <robclark> mythripk: I think you just need to loop thru the table of all timings, and see if it matches anything that we support?
[14:18] <robclark> ok, c-ya later
[14:20] <mythripk> yes ... all_timings[code] will do ...
[14:22] <ogra> lag, ogra@panda:~$ dmesg|grep -i under
[14:22] <ogra> [  424.812652] omapdss DISPC error: GFX_FIFO_UNDERFLOW, disabling GFX
[14:22] <ogra> [73202.197601] omapdss DISPC error: GFX_FIFO_UNDERFLOW, disabling GFX
[14:22] <ogra> got it twice since yesterday it seems
[14:22] <lag> That's the one!
[14:28] <lag> ogra: Which bootloaders are we using?
[14:28] <lag> ogra: I fixed this before by using the correct ones
[14:28] <ogra> lag, most recent linaro package
[14:28] <lag> Do you have back log on here?
[14:29] <ogra> this channel you mean ?
[14:29] <ogra> sure
[14:29] <lag> robclark> lag: do you have x-loader w/ DDR timings tweaks and 1gb support?
 without that, I don't think DSS gets enough memory bandwidth to feed a 1920x1080 hdmi monitor..
[14:29] <ogra> yes, we have that
[14:30] <ogra> x-loader is ours btw ... only u-boot comes from linaro
[14:36] <persia> lag, http://irclogs.ubuntu.com/2010/09/14/#ubuntu-arm.html is also available, in case you ever need backscroll and nobody here has it.
[14:39] <lag> persia: Bookmarked, thanks
[14:39] <persia> lag, that's just today's: you might want to bookmark something further up in the hierarchy :)
[14:39] <lag> persia: I did ;)
[14:39]  * lag is not just a pretty face :)
[14:40] <lag> Is there a searchable version?
[14:43] <persia> I don't know of one currently maintained, other than using site: restrictions in popular search engines.
[15:02] <rsalveti> mpoirier_: http://software-dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/gfxsdk/3_01_00_07//exports/OMAP35x_Graphics_SDK_setuplinux_3_01_00_07.bin
[15:02] <rsalveti> this is the original SDK "tarball"
[15:02] <ogra> heh
[15:02] <mpoirier_> rsalveti: let me take a look.
[15:02] <rsalveti> with the latest version you can just wget it
[15:02] <rsalveti> but it's huge, let me send you just the kernel source
[15:02] <rsalveti> 500MB
[15:03] <rsalveti> this is just in case you want to check where I got them
[15:03] <mpoirier_> rsalveti: is this about the GPled ?
[15:03] <rsalveti> mpoirier: https://code.edge.launchpad.net/~rsalveti/+junk/omap3-sgx
[15:03] <rsalveti> mpoirier: only the kernel part is gpl
[15:04] <rsalveti> mpoirier_: this is a package I created using m-a to test
[15:04] <rsalveti> using the same kernel sources, you can check my branch and see the GFX_Linux_KM directory
[15:05] <rsalveti> this is the directory they put the source of their kernel modules
[15:05] <mpoirier_> what exactly are we doing ?
[15:06] <rsalveti> mpoirier_: the idea of getting this source is to support the powervr sgx acceleration
[15:06] <ogra> mpoirier_, adding a 3D driver
[15:06] <rsalveti> to have opengles support
[15:06] <mpoirier_> ok, nice to know.
[15:09]  * persia idly wonders if the GPL module is extensible to also support other powervr sgx hardware
[15:10] <alf__> \
[15:12] <rsalveti> for omap 4 it's probably a different code/module
[15:12] <rsalveti> but not sure, never saw it
[15:14] <rsalveti> mpoirier_: http://paste.ubuntu.com/493659/
[15:15] <rsalveti> the build log, in case you need it
[15:15] <rsalveti> to check how I'm currently building
[15:17] <rsalveti> mpoirier_: rcn-ee also did some work on it, when integrating the sgx into his kernel, but adding at staging
[15:17] <rsalveti> http://bazaar.launchpad.net/~beagleboard-kernel/%2Bjunk/2.6.36-devel/files/head:/patches/sgx/
[15:17] <rsalveti> at http://bazaar.launchpad.net/~beagleboard-kernel/%2Bjunk/2.6.36-devel/annotate/head:/patch.sh#L126 you can see what patches are applied
[15:18] <mpoirier_> rsalveti: this is all very interesting.
[15:18] <mpoirier_> I'll start roaming through this stuff...
[15:19] <rsalveti> mpoirier_: cool
[15:19] <ogra> cool
[15:19] <rsalveti> remember that this is just for omap 3
[15:20] <mpoirier_> indeed
[15:35] <rsalveti> -etoomanyogras
[15:36] <GrueMaster> heh
[15:36] <rsalveti> still missing ogra_n900 :-)
[15:51] <jayabharath> ogra/rsalveti... the boot time for the 10.10 daily images is about 10 mins on ES2.0 panda's is that what you are seeing on your end?
[15:52] <rsalveti> jayabharath: for first boot (installer)?
[15:52] <rsalveti> or any other normal boot?
[15:52] <jayabharath> First boot
[15:52] <orbarron|nb> rsalveti: on first boot
[15:52]  * jayabharath thinks that it's trying to format SD card or something
[15:52] <orbarron|nb> take a few to get up and running
[15:52] <rsalveti> hm, the very first boot is the sd resizing
[15:53] <rsalveti> it shouldn't take that long
[15:53] <rsalveti> but it depends on your sd card size, I believe
[15:53] <rsalveti> and the sd card speed
[15:53] <jayabharath> 4GB is what we are using...
[15:53] <rsalveti> 4gb class 4 should take 2, 3 minutes
[15:53] <rsalveti> at least this is what I get here
[15:53] <rsalveti> GrueMaster: did you tested latest omap 4 image already?
[15:54] <orbarron|nb> rsalveti: do you get errors sometime when booting?
[15:55] <rsalveti> orbarron|nb: no errors, just resize the sd card, reboot, oem-installer (around 10 min) and then the usual netbook interface
[15:55] <GrueMaster> Just downloading todays.  Yesterdays worked fine.
[15:55] <rsalveti> the only messages I'm getting is regarding sound
[15:55] <orbarron|nb> hmm
[15:55] <rsalveti> there's a bug that sometimes the first boot identifies a broken partition
[15:55] <rsalveti> broken filesystem
[15:55] <orbarron|nb> ok
[15:57]  * orbarron|nb downloads today's image 
[15:57] <jayabharath> rsalveti: can you point me to the bug#
[15:57] <rsalveti> looking for it
[15:59] <rsalveti> hm, it sees that's a different issue, and with a quite old image: bug 613591
[15:59] <ubot2> Launchpad bug 613591 in jasper-initramfs (Ubuntu) "Jasper sometimes fails to resize root partition on omap4 (affects: 1) (heat: 104)" [Undecided,New] https://launchpad.net/bugs/613591
[16:00]  * rsalveti also downloading latest image to test
[16:00] <jayabharath> thanks ubot2/ rsalveti
[16:04] <rsalveti> argh, getting a lot of smsc95xx 1-2.1:1.0: usb0: kevent 2 may have been dropped at my xM
[16:20] <lag> sebjan: ASoC
[16:21] <sebjan> lag: ASoC ?
[16:22] <lag> sebjan: ASoC
[16:22] <lag> :)
[16:22] <lag> "asoc: no valid backend routes for PCM: SDP4430 Media"
[16:23] <sebjan> lag: did you try to use the config files I sent earlier today?
[16:24] <lag> Nope
[16:24] <lag> Where do they need to go?
[16:24] <lag> Oh, I've just seen what you've written
[16:24] <lag> Give me a second
[16:27] <lag> sebjan: Still nothing
[16:27] <lag> But I am using the 6 layer board?
[16:28] <sebjan> lag: I did not test myself with 6 layers but I have heard of issues with it. I tested on 8 layers.
[16:29] <lag> Who knows more about these issues?
[16:33] <rsalveti> orbarron|nb: resize went very fast, one minute or so
[16:33] <rsalveti> 4gb class 4
[16:35] <lag> sebjan: How did you test? Application/file type?
[16:36] <sebjan> lag: do you have access to a 8 layers?
[16:36] <lag> sebjan: Unfortunately not
[16:37] <sebjan> lag: you may ask on #pandaboard if some hw differences could explain a difference...
[16:38] <lag> sebjan: Done
[16:39] <lag> ogra: Can you make me a member of Ubuntu armel porters?
[16:39] <ogra> lag, done
[16:40] <lag> ta
[16:52] <Neko> E: genext2fs: not enough memory for filesystem ???
[16:53] <Neko> how much memory does this thing actually need?
[16:54] <ogra> Neko, exactly the size of the desired filesystem size
[16:54] <Neko> like real memory?
[16:54] <ogra> yes
[16:54] <Neko> holy crap
[16:54] <ogra> well, you can add swap
[16:54] <ogra> but that will be very very slow
[16:55] <ogra> i'D recommend not using the --no-root option unless you need to
[16:55] <mopdenacker> ouch, that's crazy!
[16:55] <ogra> then it will just use a loop mounted image
[16:55] <ogra> mopdenacker, it is
[16:55] <ogra> but thats the way genext2fs is designed
[16:55] <Neko> my concern is that my /tmp is tiny
[16:55] <ogra> it allocates the whole image size in ram before copying contents
[16:56] <Neko> I thought rootstock respected TMPDIR but it always makes the image in /tmp
[16:57] <mopdenacker> Could they do an mmap() on the output file instead of allocating RAM? This should be equivalent...
[16:58] <Neko> I'm just gonna hack this so BUILDDIR has a template...
[16:58] <ogra> mopdenacker, well, that no-root "feature" was only added for corner cases where people build on a big server but have no root access
[16:58] <mopdenacker> Thought they may not know how big the output is gonna be...
[16:58] <ogra> the size is a parameter genext2fs expects
[16:58] <ogra> so it knows
[16:59] <ogra> its just very old software written at a time where you wouldnt have had the idea to roll gigabyte big images
[17:00] <ogra> Neko, file a bug, that it should use TMPDIR
[17:00] <Neko> I thought this was already a bug
[17:00] <Neko> 532342
[17:00] <ogra> bug 532342#
[17:00] <ubot2> Launchpad bug 532342 in rootstock (Ubuntu) "rootstock-gtk does not allow to specify the target rootfs tarball file path (affects: 1) (heat: 19)" [Medium,Fix released] https://launchpad.net/bugs/532342
[17:00] <ogra> rootstock-gtk
[17:00] <ogra> hmm
[17:00] <Neko> my mistake but it's the same idea :D
[17:01] <ogra> well, rootstock-gtk surely respects it
[17:01] <Neko> the gui doesn't have enough options for me :/
[17:01] <Neko> for a start, it doesn't have maverick in the distros list :D
[17:01] <ogra> else it wouldnt be fix-released
[17:01] <rsalveti> but please file a bug for the cmd
[17:01] <rsalveti> or reopen it :-)
[17:02] <ogra> well, its fixed in the gui
[17:02] <Neko> okay it will have to wait until I have actually done what I wanted to do with it but I have a post-it note reminding me now
[17:02] <ogra> i dont get how i fixed it there without fixing it in the cli though
[17:04]  * rsalveti lunch
[17:05] <Neko> just need to change it to BUILDDIR=$(mktemp -d ${TMPDIR}/tmp.XXXXXXXX) or so right?
[17:05] <Neko> that's working here
[17:05] <ogra> erm, no
[17:05] <ogra> mktemp will use TPMDIR by default
[17:06] <Neko> maybe mktemp doesn't do local shell variables?
[17:06] <Neko> I have to really export it or something?
[17:06] <ogra> ah, there is the bug :P
[17:06] <ogra>  -t     interpret TEMPLATE as a single file name component, relative to a directory: $TMPDIR, if set
[17:06] <ogra> man mktemp
[17:06] <ogra> just add -t
[17:07] <Neko> mktemp -d -t ?
[17:07] <ogra> yep
[17:07] <Neko> do I still need to file a bug? :D
[17:07] <ogra> and file a bug so we dont forget to add it to the code
[17:07] <Neko> doing it now
[17:09] <rsalveti> Neko: bug and/or a patch
[17:09] <rsalveti> :-)
[17:09] <ogra> relly strange ... looking at #linaro i really dont get how they have so many probs with omap3
[17:10] <Neko> uhhhh mktemp -d -t did not fix it
[17:10] <Neko> it still made one in /tmp
[17:11] <ogra> how did you set TMPDIR ?
[17:11] <Neko> TMPDIR="/build/rootstock/tmp"
[17:11] <Neko> then I run rootstock in the next line of the script
[17:12] <Neko> should I be putting it in front of the script? I'm not entirely sure how or why bash mangles these things..
[17:12] <Neko> yep that fixed it
[17:13] <Neko> TMPDIR=whereveer rootstock blah blah blah works
[17:13] <Neko> TMPDIR=whatplace
[17:13] <Neko> rootstock blah blah does not :D
[17:13] <Neko> it's funny because when you bash -ex it, the output is identical
[17:14] <Neko> bug 638190#
[17:14] <ubot2> Launchpad bug 638190 in rootstock (Ubuntu) "rootstock cmdline does not respect TMPDIR (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/638190
[17:16] <Neko> ogra, what are all these omap3 probs they have? D
[17:16] <Neko> oh shit I have a ubquity bug as well
[17:16] <ogra> Neko, you ned to export TMPDIR if you dont use it on the same line
[17:17] <ogra> simple shell rule ;)
[17:17] <Neko> guys did you notice that when oem-config creates a user it does not put it in the audio group?
[17:17] <Neko> from the installer (or rootstock even it seems) you get audio, but as soon as you oem-config in a new user, that guy gets no boot sound
[17:17] <ogra> there is no audio group in ubuntu
[17:18] <ogra> since ... like ... three releases or so
[17:18] <ogra> its all handled via policykit and pulse
[17:19] <Neko> I just had to fix it in my first maverick rootfs.. users and groups advanced, add to the audio group?
[17:20] <ogra> if rootstock added users to the sudio group in lucid thats definitely a bug
[17:20] <ogra> (none we'll fix now though :) )
[17:20] <ogra> *audio group
[17:22] <Neko> maybe I am just overthinking it and mistaking the karmic demo image with the one I am working on :/
[17:22] <Neko> I did think it weird that the sd card from fsl did not have a user with rights to audio
[17:23] <Neko> but my first xfce on maverick.. no audio.. ohhh I remember..
[17:23] <Neko> somehow it had no audio devices
[17:23] <Neko> same symptom different problem
[17:23] <ogra> ah, you have one of the babbage boards with the preinstalled SD card images they hacked together ?
[17:23] <Neko> oh hell no
[17:24] <Neko> we have the efika mx smarttop and smartbook with a hacked, improved version of their preinstalled sd card image :D
[17:24] <ogra> heh
[17:24] <Neko> like no FSL proxy settings
[17:24] <Neko> I already complained profusely about how braindead it was. we also know the name of the system and the user who set it up. they did not clean it properly before shipping it.
[17:25] <ogra> oh, i just realize who you are :)
[17:25] <ogra> hi matt :)
[17:25] <Neko> hi :)
[17:27] <devilhorns> ogra, just to let you know, I received the bug assignment in my email this morning and will look into it today. May be a little difficult to test as I don't have the arm hardware yet, but I will read over the code and see if I can find the issue and get a fix for you
[17:27] <Neko> ogra, btw rootstock package cache confuses the crap out of me. how come it does not manage to get new packages that aren't in the cache?
[17:28] <Neko> if I save a cache and then try and re-use it again, but I've added a new package to the seed list, it will bomb
[17:28] <Neko> why would the cache override mirror usage? shouldn't it pull updates since it's using apt anyway?
[17:28] <ogra> devilhorns, you can test on x86
[17:29] <devilhorns> ogra, ok so it's not specific to arm then ?
[17:29] <devilhorns> (haven't read through the whole email yet)
[17:29] <ogra> devilhorns, the code we need ported already exists in the netbook-launcher package and needs to go into the netbook-launcher-efl code
[17:29] <ogra> right, its not arm specific
[17:29] <devilhorns> ah ok :)
[17:29] <ogra> actually we very rarely have arm specific stuff to do in the UI
[17:29] <ogra> if we get GL libs that might change
[17:30] <ogra> but up to now you can do all work on x86
[17:30] <devilhorns> I see ... ok fair enough :) I'll look into this today
[17:30] <Neko> ogra, we're going to look into that once we have a stable maverick for everyone internally to mess with
[17:30] <ogra> Neko, i should have called it --flight-mode ...
[17:31] <Neko> we have the GL lib source so we can build mx51 gl libs any way you like.. problem is mx51 is dropped and it needs our kernel (or at least, fsl 10.07)
[17:31] <ogra> its for moments where you *really* dont have network access ... like on a plane, but want to do multiple image rebuilds
[17:31] <ogra> (the package cache thing)
[17:31] <Neko> any chance for maverick+0.5 to have a package cache with networking?
[17:31] <ogra> if you have network access, just use a package proxy on localhost
[17:32]  * ogra recommends approx
[17:32] <Neko> that means I have to mirror 10GB
[17:32] <ogra> no
[17:32] <ogra> approx will onyl pull what you actually use
[17:32] <Neko> oh cool
[17:32] <ogra> ogra@osiris:~/Devel/packages$ du -hcs /var/cache/approx/*
[17:32] <ogra> 72M	/var/cache/approx/ubuntu
[17:32] <ogra> 2,0G	/var/cache/approx/ubuntu-ports
[17:33] <ogra> i'm using that for image builds since jaunty
[17:33] <Neko> quick setup instructions?
[17:33] <ogra> for a single image build for maverick it shouldnt be above 5-600M
[17:33] <ogra> apt-get install approx
[17:33] <Neko> yes that's done of course
[17:33] <Neko> but do I just pass rootstock this as a mirror?
[17:33] <Neko> or do I need to really configure it
[17:34] <ogra> edit /etc/approx/approx.conf
[17:34] <Neko> what I have here is a really decent internet connection but ports.ubuntu.com is like 60k/s slowpoo.
[17:34] <ogra> add: ubuntu-ports      http://ports.ubuntu.com/ubuntu-ports
[17:34] <ogra> at the top
[17:34] <ogra> thats it
[17:34] <Neko> cool
[17:34] <DanaG> http://www.engadget.com/2010/09/05/efika-mx-smartbook-now-on-sale-for-an-exceedingly-unattractive-p/
[17:34] <Neko> yes :)
[17:34] <ogra> and for rootstock use the --mirror option
[17:35] <DanaG> $350.
[17:35] <ogra> make sure to use your *external* ip there
[17:35] <ogra> not localhost
[17:35] <Neko> external == ifconfig eth0 ip address is okay?
[17:35] <DanaG> I'm more curious what 3D support there is.
[17:36] <DanaG> Any texture_from_pixmap support??
[17:36] <Neko> DanaG, none yet, but we're testing.. we found some serious performance snafu with the EGL X driver
[17:36] <Neko> no texture_from_pixmap is a braindead desktop opengl thing
[17:36] <Neko> you get that for free with embedded gl with EGLSurfaces
[17:37] <Neko> or something like that
[17:37] <Neko> to be honest I am from the braindead desktop gl world so embedded gl scares the crap out of me. I barely got used to not having a transformation pipeline.
[17:38] <DanaG> For me, I really want Compiz.  Anything that can't do compiz is a non-starter.
[17:38] <Neko> compiz is evil
[17:38] <DanaG> Well, kwin is acceptable, as well.
[17:39] <Neko> they do not care unless it is amd64 with the nouveau driver
[17:39] <DanaG> Compiz isn't evil, if you set it up right.  Things like "flaming windows" ARE stupid.
[17:39] <Neko> what we're going for is a cairo backend worth a damn
[17:39] <Neko> opengl accelerated gtk and firefox is just as good as wobbly windows
[17:40] <DanaG> How about "scale windows"?  And "lamp" animation (if you even have a taskbar)?
[17:40] <DanaG> Granted, my netbook (not my primary system) barely has room for much other than one active window.
[17:41] <ogra> Neko, yes, eth0 is fine, just not 127.0.0.1 or localhost
[17:41] <DanaG> And for now, unity is glitchy as all hell, both on intel and fglrx -- and kwin is glitchy on intel, as well.  Spazzes and flickers white with every animation.
[17:41] <Neko> there are simpler compositing systems that do apple expose-like fancy treats..
[17:42] <DanaG> I also have menus open and close with "vacuum", and windows open with "dream" and close with "sidekick".
[17:42] <DanaG> That "sidekick" animation is surprisingly satisfying.
[17:42] <Neko> we did have compiz working on a radeon 9200 with a 400MHz PPC once
[17:42] <Neko> it worked ridiculously well
[17:43] <Neko> wobbles and lamp minimize and the desktop cube and gravity and snap on windows..
[17:43]  * ogra doubts you will get compiz working on GLES 
[17:43] <Neko> what worries me is not the capabilities of the chip but the godawful compiz source
[17:43] <DanaG> That old "XGL" on top of GLES would be an interesting hack.
[17:43] <ogra> but there is work going on to get unity/clutter working at least
[17:43] <Neko> the cairo gles backend is disgusting
[17:43] <DanaG> Compiz 0.9 is slow, when 0.8 works fine.
[17:44] <Neko> we have already fixed the evas backend though, so we could gl accelerate netbook-launcher-efl
[17:44] <Neko> that would be sort of obtuse in a certain way but, it does work
[17:45] <DanaG> Some time later this week I'll try EGL on an R350.
[17:45] <Neko> DanaG, compiz 0.9 they removed reliance on texture_from_pixmap in favor of a slower way that didn't depend on broken binary driver implementations..
[17:45] <DanaG> 0.9 gets 30 fps, where 0.8 gets 45-60.
[17:45] <Neko> the idea being that you can copy a bitmap to a pci express 2.0 graphics card faster than you really need
[17:46] <DanaG> Last time I tried "mutter", the animations were confusing -- a minimize should NOT feel exactly the same as a close!
[17:46] <Neko> what really screws it over though is X is very liberal about it's refreshing
[17:46] <Neko> it just spams redraws that you don't need
[17:47] <DanaG> "Showrepaint" is useful, at least.
[17:48] <Neko> do I mean liberal or conservative? I dunno. it sends more repaints than you functionally need, and it seems up to the driver to work it out... but if you wanted to optimize it you at least have to queue all these repaints and then work out what to do, which may cause some nasty lags
[17:48] <Neko> QWS does the same thing, but then it's architecture is "subclass the paint engine and do it properly" and you have to do repaint management anyway, so..
[17:48] <DanaG> X also does this stupid readback from video memory when allocating a new or resized window.
[17:48] <Neko> I thought ajax fixed that
[17:49] <Neko> like last week
[17:49] <DanaG> Ah, hadn't checked it lately.
[17:49] <DanaG> I hope that's true.
[17:49] <Neko> oh wait no it may have been.. that guy with the name
[17:49] <DanaG> I found it was slow on radeon, intel, and nvidia (gf6150).... and slow as molasses on fglrx.
[17:49] <Neko> my grey matter is saying Tejun Heo but that's the ata guy.
[17:53] <Neko> I remember the discussion on it though and I am sure someone said they had fixed it
[17:54] <Neko> I'm hung up (pun intended) on this tcflush fix ajax tried the other day though
[17:54] <Neko> it stops my armel systems from using up 100% cpu in Xorg
[18:03] <Neko> sigh
[18:03] <Neko> ogra explain this approx thing again :/
[18:04] <Neko> it seems to just fail getting anything
[18:05] <Neko> oh shit. typo. 9999 not 999 :)
[18:06]  * Neko slinks back into a corner
[18:07] <ogra> heh, so it solved itself ?
[18:08] <Neko> MIRRORIP="http://$(ifconfig | grep inet | awk -F: '{ print $2 }' | awk '{ print $1 }' | grep --color=never 10.0.0):9999/ubuntu-ports"
[18:08] <Neko> I just missed a 9. it's fine now.
[18:36] <Neko> ooh that's annoyingly harmless
[18:36] <Neko> makedev sets up /dev/agpgart on arm?
[19:54] <Neko> eek
[19:54] <Neko> debconf: apt-extracttemplates failed: Illegal seek
[19:54] <Neko> Extracting templates from packages: 24%E: Could not open file /build/rootstock/tmp/linux-sound-base.template.54630 - open (2: No such file or directory)
[19:54] <Neko> E: Unable to write to /build/rootstock/tmp/linux-sound-base.template.54630 - ofstream::ofstream (2: No such file or directory)
[19:54] <Neko> E: Could not open file /build/rootstock/tmp/linux-sound-base.config.54631 - open (2: No such file or directory)
[19:54] <Neko> ???
[20:23] <Neko> ogra why is rootstock packages trying to write directly into BUILDDIR  for this stuff?
[20:41] <Neko> argh it passes tmpdir into the VM?
[21:22] <devilhorns> ogra, fixed the netbook-launcher-efl --add-favorite stuff
[21:22] <devilhorns> patches attached in launchpad
[21:22] <devilhorns> cause I am not sure of "proper procedure" around here, please be a little forgiving :)