[11:52] <ppisati> for anyone with a real beaglexm: can you try today's daily quantal image?
[11:52] <ppisati> http://cdimage.ubuntu.com/ubuntu-server/daily/current/quantal-server-armhf+omap.img
[11:52] <ppisati> thanks
[12:08] <bizulk> ppisati: have you updated kernel config with tidspbridge support ?
[12:57] <ppisati> bizulk: nope, busy dpoing other things
[12:57] <ppisati> bizulk: which kernel version are you running?
[12:57] <ppisati> bizulk: 3.2 or 3.5?
[12:58] <bizulk> ppisati: 3.2.30
[12:58] <ppisati> bizulk: uhm ok
[12:58] <ppisati> willing to test quantal?
[12:59] <ppisati> bizulk: beagle right?
[12:59] <ppisati> http://cdimage.ubuntu.com/ubuntu-server/daily/current/quantal-server-armhf+omap.img
[12:59] <bizulk> ppisati: is quantal 12.10 ?
[12:59] <ppisati> bizulk: yep
[12:59] <bizulk> ppisati: yes if the tidspbridge is installed. Cause that would be the only reason I would be a"allowed" to.
[13:00] <bizulk> ppisati: I am also experiencing some network init issue on the 12.04 : nm-applet does not apply configured profile
[13:02] <ppisati> bizulk: well, nm is userspace
[13:02] <ppisati> bizulk: if ifconfig shows the interface, we are good
[13:02] <ppisati> bizulk: actually i was looking for someone willing to do some testing on real hw
[13:02] <ppisati> bizulk: since we are facing a problem with usb
[13:03] <bizulk> ppisati: I have a BB xM. But as I am in the office I 'can' only work on the dspbridge stuff, u know
[13:04] <bizulk> ppisati: what's your PB with USB ? it seemed to work well (using a powered usb hub in my case)
[13:04] <ppisati> bizulk: ack
[13:04] <ppisati> bizulk: it's broken since 3.5
[13:04] <ppisati> bizulk: still broken in 3.6
[13:04] <ppisati> but i wanted someone else to double check it
[13:05] <ppisati> actually booting a precise 3.2 kernel everthing is ok
[13:05] <ppisati> so...
[13:05] <ppisati> bizulk: anyway, remind me your lp bug
[13:05] <ppisati> bizulk: i'll do the config changes now
[13:05] <bizulk> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1058022
[13:05] <ubot2> Launchpad bug 1058022 in linux "no tidspbridge support in kernel." [Medium,Triaged]
[13:07] <bizulk> ppisati: I experience USB pb on standalone 3.6 kernels, but I thoughed It was because of my power supply (usb always restarting, until the CPU itstelf resets)
[13:13] <ppisati> bizulk: does it generate a /dev entry? which one?
[13:14] <bizulk> /dev/DspBridge
[13:14] <bizulk> ppisati: crw-rw-rw- 1 1000 1000 251, 0 2011-08-31 13:24 rootfs/dev/DspBridge
[15:06] <marvin24> janimo: is the "tegra hw video decoder config bug" already fixed in some ac100 kernel image?
[15:08] <marvin24> ah, just saw http://kernel.ubuntu.com/git?p=jani/ubuntu-ac100.git;a=shortlog;h=refs/heads/packaging-3.1
[15:08] <marvin24> sorry
[15:08] <marvin24> but still kinda wrong - did this even compile?
[15:09] <janimo> marvin24, I think the deb built fine
[15:09] <janimo> marvin24, I was told later that this change is not enough
[15:09] <marvin24> mmh, I think we also need CONFIG_TEGRA_AVP_KERNEL_ON_MMU
[15:09] <marvin24> ok
[15:09] <marvin24> I tested a kernel with both options enabled only
[15:09] <janimo> can someone build the package and provide the right config option changes?
[15:10] <marvin24> I will ...
[15:10] <marvin24> just a few secs ;-)
[15:10] <janimo> cloning the repo, fdr clean, fdr editconfigs, debuild
[15:10] <janimo> where fdr is fakeroot debian/rules and debuild the cross-build line
[15:10]  * ogra_ would if it wouldnt take ages to pull the source package on my loaded line
[15:10] <marvin24> or use a script I wrote some time ago ;-)
[15:11] <janimo> ogra_, that is why you should keep the git tree checked out and updated frequently :)
[15:11] <janimo> you have a beefy machine, no excuse for not building kernels anymore
[15:11] <ogra_> pfft, i still stay away from git if i can
[15:11] <janimo> ogra_, in this case you only need git clone, if you just want to check new stuff or do custom builds
[15:11] <ogra_> and i have a local mirror ... so i can just use source packages usually ... but not for univers
[15:11] <ogra_> e
[15:12] <ogra_> if marc has a local branch he will surely be faster
[15:12] <marvin24> ogra_: I have one
[15:13] <marvin24> but building without ccache is hell
[15:13] <marvin24> janimo: did you found out how to enable it?
[15:13] <ogra_> what are you building on ?
[15:13] <marvin24> x86_64
[15:13] <ogra_> well, same here
[15:13] <janimo> marvin24, I have a not-too fast core duo, which builds in maybe 30 minutes
[15:14] <marvin24> same here :-(
[15:14] <ogra_> i use to do heavy builds in ramdisks though, that speeds up things a lot
[15:14] <janimo> not sure if that qualifies as 'hell' for you though :)
[15:14] <marvin24> with ccache it takes less than 2 minutes
[15:14] <ogra_> without ccache it takes around 10 for me ...
[15:14] <janimo> marvin24, I believe you. Not sure why I never looked at why ccache did not work
[15:15] <marvin24> must have something to do with fakeroot
[15:29] <xnox> ogra_: picking up AC100 tomorrow 112GBP (139 EUR)
[15:29] <ogra_> hah, cool !
[15:41] <marvin24> ogra_: did akon reached you regarding the library name problem?
[15:41] <ogra_> marvin24, nope, i was one at 1:30 when he pinged me
[15:41] <marvin24> (sorry I'm just catching up with the backlog because of short time holidays)
[15:41] <ogra_> waiting for him to re-appear thugh
[15:42] <ogra_> you took a long weekend ?
[15:46] <ogra_> infinity, mind helping to explain the nvidia ld issue to srwarren (from nvidia) ?
[15:46] <srwarren> infinity, could you detail the technical issues that the incorrect soname in the NVIDIA Tegra R16 libs?
[15:46] <ogra_> i fear i'm not as accurate as you can be :)
[15:46] <srwarren> I know the names are wrong and what needs to be changed; I'm just trying to understand the exact implication of the current incorrect names
[15:47] <ogra_> it boils down to "that it currently works if you put the libs into /usr/lib is sheer luck)
[15:47] <marvin24> ogra_: yep, I measured the circumference of the Edersee
[15:47] <ogra_> if you put the libs into any different path thatrs not hardcoded in ld only ld.so.cache will be used ... in which we have the wrong SONAME
[15:47] <srwarren> For ldconfig, I think what will happen is that if libfoo.so's soname is libfoo.so, presumably ldconfig would simply not create any symlink since the file is already present under the expected name and move on
[15:48] <infinity> srwarren: The libraries end up being uncacheable by ldconfig because the filenames and SONAMEs can't match.
[15:48] <ogra_> if they live in /lib or /usr/lib ld falls back to walk the path and actually look at the links too
[15:48] <infinity> srwarren: This is a problem given that ld.so uses the cache to find libraries.
[15:48] <marvin24> janimo: kernel without CONFIG_TEGRA_AVP_KERNEL_ON_MMU crashed hard on video decode here
[15:48] <infinity> srwarren: And yes, if things are in the "built-in" paths, then they get found the slow (cache-missed) way.
[15:49] <infinity> srwarren: So, the best way to look at it is that it's a performance hit.  The worst way to look at it is that all the SONAMEs are wrong, and that's just plain, well, wrong. ;)
[15:49] <marvin24> janimo: it is also enabled in tegra_defconfig and I want to stay as close as possible to downstream
[15:49] <srwarren> With the current sonames, don't the filenames and sonames always match? Oh, I guess you're renaming the files in the Ubuntu package so that apps with DT_NEEDED=libfoo.so.1 can actually find the library?
[15:49] <infinity> srwarren: Yeah, everything with a NEEDED it looking for the correct SONAME, which isn't in the library.
[15:50] <infinity> srwarren: So, we get a cache miss, then start walking the filesystem.
[15:50] <ogra_> srwarren, no, we put the libs into /usr/lib/nvidia-tegra and the SONAMEs end up in the cache ...  i.e. libEGL.so ... GLES apps are built to look for libEGL.so.1
[15:50] <infinity> srwarren: It's not about us renaming them.  It's about the fact that they need to exist by those names. :P
[15:50] <srwarren> OK, so the entries in /etc/ld.so.conf.d (or whatever the file is) only get used to build the cache, and not as part of the fallback searching
[15:51] <ogra_> right
[15:51] <infinity> srwarren: Right, because parsing a conf.d directory when loading every single binary on your system would be, well, dumb.
[15:51] <ogra_> srwarren, but even if that wouldnt be an issue ... the first GLES app you would build on a system with the drivers installed would have completely broken linking
[15:52] <srwarren> right, that's the part I already understood
[15:52] <infinity> srwarren: Anyhow, I'm trying to decide which bit you're asking me to explain.  If you want to know why the SONAMEs are wrong, or why attempts to work around it suck?
[15:52] <ogra_> afaik for libEGL.so as well as for libGLESv2.so the sonames are actually standadized
[15:52] <ogra_> rsalveti, might know :)
[15:52] <srwarren> I know exactly why the SONAMEs are wrong; I was trying to understand what practical impact that had. I'd only deduced the application-compilation issue so far, not the searching issue
[15:53] <infinity> Ahh, yes.
[15:53] <infinity> So, yeah.  If we ship everything in /usr/lib, is kinda works due to the cache-miss->directory-walk thing.
[15:53] <srwarren> infinity, so when the files aren't found in the cache, and ld.so falls back to searching e.g. /usr/lib, how does it find the files even then, if they still have the wrong soname and filename?
[15:54] <janimo> marvin24, I agree with staying close to defconfig downstream. Just that I not always sync up with defconfig in the package, at least some bits are not needed or incorrect in ubuntu (lzo) so I tend to drop more
[15:54] <ogra_> srwarren, it doesnt :)
[15:54] <infinity> srwarren: Because we symlink the correct SONAME to them.
[15:54] <infinity> srwarren: And then it find them by filename.
[15:54] <srwarren> ok, that makes sense - there's a workaround to make it work
[15:54] <infinity> ogra_: Don't ask me to explain things and then jump in with contradictory statements. ;)
[15:54] <ogra_> oh, i misread
[15:54] <ogra_> lol, sorry
[15:55] <ogra_> didnt mean to, i just read something completely different
[15:55] <infinity> srwarren: Yes, our workaround for now is to symlink stuff from /usr/lib (or something else on the path)
[15:55] <ogra_> but thats nothing we can do in a package
[15:55] <infinity> srwarren: But that's still pretty wildly less than ideal, if you guys can actually fix the SONAMEs.
[15:55] <infinity> ogra_: Well, we *can*... We really shouldn't.
[15:56] <ogra_> yes
[15:56] <infinity> (And I probably won't accept it in the archive...)
[15:56] <infinity> But, y'know.  You can upload it.
[15:56] <marvin24> janimo: that's fine, but you can check my paz00_defconfig against the latest you used for the last package
[15:56] <srwarren> I guess this is because the multi-driver co-existence stuff is based on putting entries into the ld.so cache-building path list, rather than using the alternatives system on the .so filenames themselves
[15:56] <marvin24> janimo: that should be a pretty short diff
[15:57] <infinity> srwarren: Using alternatives on .so doesn't make much sense, since we don't install .so files except with -dev packages...
[15:57] <srwarren> Well, *.so.1
[15:57] <stuw> marvin24, janimo - https://bugs.launchpad.net/ubuntu/+source/linux-ac100/+bug/1059866
[15:57] <ubot2> Launchpad bug 1059866 in linux-ac100 "video hw acceleration still dont work" [Undecided,Confirmed]
[15:58] <infinity> srwarren: And yeah, we use alternatives on the ld.so.conf instead of on the files.  Correct.
[15:58] <infinity> srwarren: Which is actually much more manageable.  If all the libraries work. ;)
[15:58] <srwarren> yes, I can see that scales a lot better with multiple libs
[15:58] <infinity> Just a lot less error-prone, really.
[15:59] <infinity> Adding and removing alternatives and slaves for a ton of stuff makes people go cross-eyes, no matter how awesome the syntax-hilighting.
[15:59] <infinity> s/cross-eyes/cross-eyed/
[16:02] <bizulk> ppisati: hi. I saw my bug update. As soon as possible I take a look at this
[16:07] <janimo> marvin24, stuw ok I'll have a look. It's just that yesterday's suggestion was a one line diff as well but was not enough
[16:08] <janimo> it's just that I do not use the ac100 and have testcases to check various features so I will mostly blindly do whatever I am asked by others who actually use the machine :)
[16:09] <janimo> ideally those people would take care of kernel packaging too but I am asking too much (hint hint)
[16:09] <janimo> ;)
[16:10] <ogra_> janimo, well, it was discussed on and off in #ac100 what options need to be on :) you could have fished it out of your backlog
[16:10] <stuw> janimo, http://paste.ubuntu.com/1256243/ - .config after make ARCH=arm paz00_defconfig
[16:11] <janimo> ogra_, I haven't logged in ac100 in many months, also as a cosequence of it mostly being low signal to noise for what I was interested in back then
[16:11] <ogra_> well, that changed
[16:12] <ogra_> there is still a lot of noise but currently thats all ac100 noise
[16:13] <marvin24> ogra_: not noice, hifi sound!
[16:13] <marvin24> *noise
[16:13] <ogra_> oh, yeah, compared to the last 6 months this current hype is hifi
[16:14] <infinity> Hahaha.
[16:15]  * marvin24 still wonders why people are still interested in 2 years old machines
[16:16] <infinity> Likely due to the lack of decent ARM netbooks.
[16:16] <ogra_> yeah
[16:16] <infinity> I just want a reasonably speedy one with a non-Android en_US keyboard.  Some day...
[16:16] <ogra_> you can still buy it and its still cheap
[16:16] <lilstevie> I like my transformer for that reason, running ubuntu it makes a nice ARM netbook
[16:17] <ogra_> and with the 1280x720 display and the internal UDB disk its now gotten really uasble
[16:17] <ogra_> *USB
[16:17] <infinity> lilstevie: Yeah, but the transformer keyboard makes me die a little inside.
[16:17] <ogra_> oh yeah
[16:17] <ogra_> not just a little
[16:17] <lilstevie> infinity, why?
[16:17] <infinity> lilstevie: Well, (a) Android layout, and (b) it's just not a nice keyboard to type on.
[16:17]  * ogra_ also doesnt like the shape ... since i have my zatab i use that more than my transformer 
[16:18] <ogra_> less sharp corners on the case etc
[16:18] <ogra_> even though the zatab is classes slower
[16:18] <lilstevie> infinity, old style or new though, android layout is a pity, but I don't really look at the keys, and I have altered the keymap
[16:18] <ogra_> (these A10's are really not made for multitasking)
[16:18] <lilstevie> typing though I find it a bit better than my macs bt keyboard
[16:19] <lilstevie> the tf101 keyboard was nowhere near as nice though
[16:19]  * ogra_ really likes the ac100 kbd
[16:19] <ogra_> the low resolution bothered me for actual work, but i fixed that :)
[16:20] <lilstevie> I wish the tf201 was a bit higher resolution
[16:20] <lilstevie> 1280*800 is nice, but it could be better
[16:20] <ppisati> bizulk: fix was committed, when the next kernel is but i'll be in
[16:20]  * ogra_ is happy with 1280x720
[16:20] <infinity> I'd probably pay the Thinkpad brand premium for an ARM netbook with a Lenovo keyboard.
[16:20] <ppisati> bizulk: *kernel is cut
[16:21] <bizulk> ppisati: sorry you mean "next kernel is built I keep you informed" ?
[16:21] <lilstevie> infinity, I wonder whatever happened to that Lenovo transformer like T3 tablet
[16:23] <ppisati> bizulk: no, it means next Precise kernel upload will contain the fix
[16:23] <bizulk> ppisati: How can I know when it's done ?
[16:24] <ppisati> bizulk: sudo apt-get update upgrade
[16:24] <bizulk> opps sorry
[16:25] <bizulk> with update-alternative cmd I can select the kernel release I want (including the unofficial one) ?
[16:26] <infinity> kernels don't use alternatives, no.
[18:59] <ogra_> janimo, do you actually look over the linux-ac100 buglist sometimes ?
[19:00] <ogra_> bug 961302 seems valuable if you dont want to upload for a single config change :)
[19:00] <ubot2> Launchpad bug 961302 in linux-ac100 "[AC100] Request HID Waltop kernel module for Waltop tablet" [Undecided,New] https://launchpad.net/bugs/961302
[19:21] <janimo> ogra_, no I did not look at the buglist recently
[19:22] <janimo> I'll look into them
[19:22] <janimo> I added some more modules in a recent upload but still far from what stock ubuntu kernel has
[19:22] <janimo> ogra_, git has a bright future
[19:22] <janimo> just sayin ;)
[21:42] <marvin24> janimo: I fixed the fuse cannot be loaded bug
[21:42] <marvin24> https://bugs.launchpad.net/ubuntu/+source/linux-ac100/+bug/1060050
[21:42] <ubot2> Launchpad bug 1060050 in linux-ac100 "Can't mount ntfs volume" [Undecided,New]
[21:42] <marvin24> you may pull my tree again
[21:42] <ogra_> \o/
[21:42] <janimo> marvin24, ok
[21:42] <ogra_> such a wondeful bug
[21:42] <ogra_> really deserves a printout and a frame :)
[21:42] <ogra_> (not the LP bug, the code issue indeed)
[21:43] <marvin24> in fact, renaming arch/arm/mach-tegra/fuse.c fixed it
[21:44] <ogra_> haha
[21:44] <marvin24> if a kernel parameter is created
[21:44] <marvin24> a file in /sys/module/<filename>/parameters/... is created
[21:44] <marvin24> where filename is "fuse" in this case
[21:45] <marvin24> so the filesystem fuse driver cannot register anymore, because the sysfs entry is used already
[21:45] <marvin24> took some time to find this ...
[21:47] <ogra_> yeah, great catch
[22:00] <atc3030> could someone aid me in porting ubuntu to the tf700
[22:05] <VarmVaffel> anyone used linux target image builder here?
[22:05] <VarmVaffel> or LTIB as it's called
[22:05] <VarmVaffel> I'm wondering how I can set the --build parameter there
[22:05] <VarmVaffel> or mach type
[22:06] <VarmVaffel> on the make
[22:06]  * ogra_ never heard of it
[22:06] <VarmVaffel> Freescale uses it for their CPUs