[05:44] <lilstevie> so what was the result of the whole discussion with srwarren? are the r16 libs getting fixed?
[08:27] <marvin24> lilstevie: it will be fixed, but maybe not in time
[08:33] <bizulk> just a question about makefile : I export a CFLAGS variable for a target that configure gstreamer. The configure step is passes but when compiling I get a bunch of errors. What I found is that at the compile step the CFLAGS have been passed with the "..." so that compiler (libtool) that this as a file. When I call the configure the same way in the shell everything is ok. So how do we avoid such export error in makefile ?
[08:36] <bizulk> infinity: but kernel installation are not overriden, right ? So after updating the new kernel will be selected. If I want to fallback I'll just have to update the symlink to uImage (BB xM)
[08:38] <dmart> bizulk: for your makefile question, do you have a log you can share?
[08:38] <bizulk> dmart: Yes give 2 minutes to make a pastbin
[08:47] <lilstevie> marvin24, hm ok
[08:47] <lilstevie> marvin24, is there a package that works with precise though?
[08:54] <bizulk> dmart: http://pastebin.com/GS5W1sCZ
[08:55] <bizulk> dmart: I tried $() ${} , always getting error at compile time
[09:00] <dmart> bizulk: Hmmm, I'm not sure exactly why that ends up quoted
[09:01] <dmart> bizulk: What happens if you put the flags in the environment instead of on the configure command line
[09:01] <dmart> bizulk: i.e.
[09:01] <bizulk> well I'll try it now
[09:02] <dmart> bizulk: hang on, forget that for a moment -- do you have the Makefile?  I'm wondering whether it adds inappropriate quoting to the make variables corresponding to GSTREAMER_CFLAGS and GSTREAMER_LDFLAGS
[09:03] <bizulk> well it does not work
[09:04] <bizulk> You mean the gstreamer Makefile ?
[09:05] <dmart> bizulk: yes... or were the lines at the top of your log part of the Makefile?  I had assumed they were shell commands issues before typing make
[09:05] <bizulk> I'll post the whole makefile
[09:07] <bizulk> http://pastebin.com/KaKeasVU
[09:07] <bizulk> maybe I am messing the configure step with my GLIB custom makefile. I trying to make a diff
[09:10] <dmart> bizulk: Normally people do not put quotes directly in Makefile variable assignments, because Make doesn't need them and they become part of the variable
[09:11] <bizulk> dmart: you mean when I export ? I thought I needed them because of space
[09:15] <ogra_> lilstevie, i think i'll upload a package with the broken libs, the direver works fine without them and we can then SRU the fixed libs
[09:17] <dmart> bizulk: Make generally doesn't use quotes at all
[09:17] <bizulk> dmart: you're right I've just been inspecting the gstreamer generated Makefile
[09:17] <dmart> bizulk: but rule commands may need them because those are executed by the shell
[09:17] <dmart> Maybe something like this:
[09:17] <dmart> http://pastebin.ubuntu.com/1257570/
[09:17] <lilstevie> ogra_, ok cool, I do find I care more about the driver than the libs anyway
[09:18] <ogra_> yeah, not many gles apps around yet and unity is broken with the nvidia driver anyway
[09:18] <bizulk> dmart: right. I got it working now but I don't know why. So I'll use your models
[09:19] <lilstevie> ogra_, even with r16?
[09:19] <ogra_> infinity, would you let the tegar package in even with broken libs (to make SRUing the fix easier) ?
[09:20] <ogra_> lilstevie, apparently, though the reports i had were from precise ... with luck quantal unity works better (though i doubt it)
[09:20] <lilstevie> shame
[09:21] <bizulk> dmart: ok it seems to be compiling. Variable assignement rule is using the whole line after ' = ' and not quote then.
[09:21] <ogra_> the patches should be largely the same in both, just that they are upstream in quantal
[09:21] <dmart> yes
[09:21] <lilstevie> you would have thought they would have fixed it though, seeing as their test env is now a 12.04 armhf image
[09:21] <ogra_> which still falls back to unity2d
[09:22] <ogra_> when i asked them last they were convinced unity works ... turned out in the end that they looked at 2d :)
[09:22] <lilstevie> yeah, but it doesn't fall back with the tegra driver (although it might with broken libs)
[09:22] <ogra_> yeah. not anymore
[09:24] <lilstevie> hm
[09:24] <bizulk> dmart: Thanks for help
[09:25] <lilstevie> I'm not quite satisfied with our r16 kernel anyway
[09:25] <dmart> bizulk: no problem
[11:21] <ogra_> janimo, !
[11:21] <ogra_> janimo, could it be that you changed the config wrt usb-storage in the last kernel ?
[11:21] <ogra_> people arent finding the USB key during install anymore
[11:23] <janimo> ogra_, you mean the very  last kernel which was supposed to be the NVAVP change?
[11:24] <ogra_> janimo, dunno, is that in already (meta ?) whartever is on todays image doesnt find a /dev/sda1 anymore in the installer initrd
[11:24] <ogra_> USB plug events are seen
[11:24] <ogra_> that smells like usb-storage moved from =y to =m
[11:25] <ogra_> (the initrd is built without any modules due to size issues if you remember)
[11:26] <janimo> sure. I do not remember touching usb-storage though
[11:26] <janimo> I'll check
[11:26] <ogra_> yeah, might be marvin24 changed it
[11:26] <ogra_> that would break everyone who runs rootfs on USB though
[11:26] <janimo> I do not use defconfig so not sure how marvi could have affected this though
[11:27] <ogra_> ah, k
[11:27] <janimo> but yes, thatwas it. storage is modular :(
[11:27] <ogra_> heh
[11:27] <janimo> part of the first r16 kernel upload
[11:27] <janimo> where I actually did merge with defconfig
[11:27] <janimo> I hate this crap (kernel packaging)
[11:28] <ogra_> funny, i thought that made it onto beta2
[11:28] <ogra_> you wanted it :)
[11:28] <janimo> I was young and stupid
[11:28] <ogra_> i wuld have kept it (and maintained it in tarballs) ... now its in git .... else i'd take it back :P
[11:29] <janimo> I think it is better for it to be in git, as it is - in theory at least - easier to team-maintain
[11:29] <janimo> right now the lack of interest not of git is the blocker
[11:29] <janimo> ogra_, but really git is winning , sooner or later you will have to use it
[11:29] <janimo> so why not now ;)
[11:30] <ogra_> enough other stuff on my plate :)
[11:30] <ogra_> i'm happy if i can git pull, the rest i stay away from
[11:32] <marvin24> janimo, ogra_, sorry folks that I broke it
[11:32] <janimo> well it has an annoying hurdle at the beginning of the learning curve, but it pays off later
[11:32] <janimo> marvin24, np, this is error-prone and boring  stuff
[11:32] <marvin24> pc distros prefer all modules
[11:32] <marvin24> and load them in the initrd stage
[11:33] <marvin24> I wonder why this doesn't work on ARM
[11:33] <ogra_> it does
[11:33] <ogra_> just fine
[11:33] <janimo> it's not ARM but our ac100 initrd
[11:33] <ogra_> its just that there are no modules to load
[11:33] <ogra_> since we dont include any in the initrd on ac100
[11:34] <ogra_> else it would get to big
[11:34] <suihkulokki> people are just too lazy in ARM world to do things in the generic way and just take vendor trees and build everything in the kernel
[11:34] <ogra_> suihkulokki, its not that :)
[11:34] <suihkulokki> it is :P
[11:34] <ogra_> its a constraing of the dveices bootloader we have to obey to
[11:35] <suihkulokki> but it is changing with the unified kernels and device trees etc
[11:35] <ogra_> your initrd cant be bigger than 2.5M or so
[11:35] <ogra_> or even 2M ... i dont remember the exact value
[11:36] <ogra_> if i want to use a standard ubuntu initrd i have to cut down size massively due to setting other defaults for initramfs-tools
[11:36] <ogra_> ogra@panda:~$ ls -lh /boot/initrd.img-*
[11:36] <ogra_> -rw-r--r-- 1 root root 4.6M Sep 26 17:37 /boot/initrd.img-3.5.0-211-omap4
[11:36] <ogra_> ogra@panda:~$
[11:36] <ogra_> that would be the normal size
[11:37] <ogra_> no way to fit that into the ac100
[11:39] <ogra_> s7due to/through/
[11:41] <ogra_> janimo, oh, you are not in #arm anymore on the other server :(
[11:42] <janimo> ogra_, oh that's because that channel used to say 'closing. move along' or similar half a year ago
[11:42] <janimo> and it was inactive
[11:42] <janimo> did I miss something lately?
[11:43] <ogra_> well, the channel has still 35 residents :)
[11:43] <janimo> ogra_, but are they alive?
[11:43] <ogra_> and we occasionally talk there
[11:43] <ogra_> rarely :)
[11:43] <ogra_> i just didnt want to talk in #canonical ... and you arent in#distro either
[11:44] <janimo> ogra_, well, I thought those too were kind of quiet
[12:15] <marvin24> janimo: it seems you were right a few weeks ago ...
[12:15] <marvin24> there is significant work towards multi arch kernel on arm
[12:15] <marvin24> or better multi cpu
[12:16] <marvin24> I wonder how they will solve the errata problem
[12:16] <ogra_> devicetree needs to learn about them
[12:16] <janimo> marvin24, tegra in 3.7 seems quite nice (from a codebase point of view, not sure how it actually works)
[12:17] <janimo> ogra_, but still checking for them incurs runtime overhead even for unaffected hw
[12:17] <marvin24> yes, seems tegra is the first platform to kill board files
[12:17] <janimo> unless some live patching is done at bootup, which may not be that hard on ARM as it is on x86. No idea
[12:18] <ogra_> janimo, you dont check for anything thats not in your DT database for the HW you run on
[12:18] <ogra_> thats the purpose of DT
[12:19] <janimo> ogra_, I mean errata code is inside #ifdef
[12:19] <janimo> and not built unless selected for the particular target in config
[12:19] <ogra_> that needs changing indeed
[12:19] <janimo> so if you want to support all boards you make the checks at runtime
[12:19] <janimo> so some overhwead
[12:19] <ogra_> which would be a part of "devicetree needs to learn about them"
[12:20] <janimo> or decree you go one stepo further and ARM kernels will not only not accept machines that are not DTbaserd, but not accept machines that have hardware bugs
[12:20] <janimo> would make arm kernel maintenance so much easier
[13:40] <bizulk> I am compiling glibc against arm2009q1 (code sourcery), and gstreamer, for BB xM. But when calling for gst-inspect I have this error : "/lib/libglib-2.0.so.0: /lib/libc.so.6: version `GLIBC_2.9' not found (required by /lib/libglib-2.0.so.0)". I can't understand as I did install the libc from the toolchain dir.
[13:41] <bizulk> How can glib ask for a glibc version later than the one it has been compiled with (what a headache !)
[13:41] <ogra_> ugh, why do you use such an outdated toolchain
[13:45] <bizulk> I was using the last one but because I could have tidspbridge support (still not sure about the reason) I fallback to the one my colleagues are actually using
[13:45] <bizulk> Actually the glib version is "glib-2.24.1"
[13:46] <bizulk> why did I choose this one ? Maybe because I wanted to use same gstreamer version as the gst-dsp project and that it is compiled with this version og glib
[13:49] <bizulk> I'll cry if I have to recompile the whole stuff (BSP and userspace) with another toolchain
[14:06] <ogra_> bizulk, you recompiled ubuntu ?
[14:07] <ogra_> note that the whole ubuntu userspace is compiled with gcc 4.7
[14:07] <ogra_> i_m not even sure that old toolchain you use has proper armhf support
[14:07] <bizulk> no that standalone stuff (I have to) , I am using ubuntu as "witness test". I'm wondering If I can generate minimal FS with ubuntu
[14:08] <ogra_> use debootstrap
[14:08] <ogra_> or qemu-debootstrap for cross building a chroot/rootfs
[14:08] <ogra_> (note that this will be compelertly unconfigured though)
[14:17] <TerrorCon> can anyone help me with Qt's audio classes under ubuntu for pandaboard
[14:17] <bizulk> ogra_: I'll take an eye one it. infortunately I have to be base on the one I receive and populate it with the builds I make
[14:44] <bizulk> ok I recompile with a more recent kernel arm-2012.03-57-lite
[14:45] <ogra_> s/kernel/compiler/ ?
[14:45] <bizulk> I hope one day we'll adopt OE/Ubuntu u
[14:45] <bizulk> compiler
[14:45] <ogra_> urgs
[14:45] <ogra_> thats like saying for the desktop you want a merge of gentoo and ubuntu
[14:46] <ogra_> ubuntu isnt an embedded OS ... dont use it as one
[14:46] <bizulk> so why port on a omap ?
[14:46] <ogra_> we needed to start somewhere
[14:47] <ogra_> ompa support is a legacy we only carry on because we get it for free from te mainline kernel
[14:47] <ogra_> *omap
[14:47] <ogra_> focus in on cortex-a9 and beyond
[14:48] <ogra_> which are systems that are capable of running a general purpose desktop distro
[14:51] <ogra_> bug 1028905
[14:51] <ubot2> Launchpad bug 1028905 in debian-installer-utils "cdrom-detect in quantal omap4 hangs trying to look for install media on an extended partition" [High,Fix released] https://launchpad.net/bugs/1028905
[16:51] <ogra_> janimo, did you include the fuse fix as well in your ac100 upload (changelog doesnt talk about it )
[16:52] <janimo> ogra_, I rebased on marvin's branch so it should be there
[16:52] <ogra_> good
[16:52] <janimo> I have a LP buglink which should point to that
[16:52] <ogra_> just wanted to make sure
[16:52] <janimo> but indeed, forgot to mention it otherwise
[16:52] <janimo> I am not sure of anything now, so let's see who yells when it builds :)
[16:52] <ogra_> hopefully thats the last upload :)
[16:53] <ogra_> yeah
[16:53] <ogra_> theoretically it should be good now
[16:54] <infinity> Can I just yell for the sake of yelling?
[16:54]  * ogra_ plugs his ears 
[16:54] <janimo> infinity, always
[16:54] <ogra_> GO ON !
[16:54] <ogra_> :)
[16:55] <infinity> Well, that's no fun.
[16:57] <infinity> dannf: Around?
[16:57] <dannf> infinity: yeah
[16:57] <infinity> dannf: Can you re-do your qemu-linaro SRU with the patch headers actually being sane? :P
[16:58] <infinity> dannf: They include ufilled boilerplate, a reference to an unrelated bug, etc.
[16:58]  * dannf looks
[16:59] <infinity> dannf: Err, oh, I see the problem.  There's a debian-changes patch in there.
[16:59] <infinity> dannf: So, yeah.  Fix that, please. :P
[16:59] <infinity> dannf: That debian-changes patch looks like maybe a mistake while fiddling?  Can't see why you'd want to remove the stdint.h include.
[17:00] <infinity> dannf: http://launchpadlibrarian.net/117670218/qemu-linaro_1.0.50-2012.03-0ubuntu2_1.0.50-2012.03-0ubuntu2.1.diff.gz
[17:00] <infinity> dannf: (Always pays to debdiff and cruft-check before upload)
[17:00] <ogra_> debdiff ++
[17:00] <infinity> dannf: Rejecting that one, give me something gooder.
[17:02] <dannf> infinity: ok - i don't see those changes in my branch.. did i post this debdiff?
[17:02] <infinity> dannf: That's the diff generated in the queue from the package you uploaded...
[17:02] <dannf> i didn't upload a package
[17:02] <infinity> Oh.  Did someone else sponsor that?
[17:02] <dannf> except to my ppa (i don't have ubuntu upload rights)
[17:03] <dannf> here's my changes: https://code.launchpad.net/~dannf/qemu-linaro/highbank
[17:03]  * dannf remembers hallyn poking me last week while i was travelling about qemu-linaro - i'd forgotten about that & never got back to him
[17:04] <infinity> dannf: Check, I'm chastising the wrong person.  I didn't check the signature to see who sponsored it. :P
[17:04] <dannf> infinity: np - thanks for working on this
[17:05] <infinity> Looks like it was mvo who broke it.  That's surprising.
[17:05] <infinity> I so wanted it to be you.
[17:05] <infinity> *sniff*
[17:05] <infinity> I'll re-do this and upload.
[17:07] <dannf> heh - sometimes i wonder if i should try and get upload rights.. then i remember the blame that comes w/ privilege :)
[17:09] <infinity> Oh, curious, mvo's debian-changes patch unapplied Colin's FTBFS fix.
[17:09] <infinity> Weird.
[17:09] <infinity> Aaaanyhow.  Reuploading a less broken version.
[17:26] <infinity> dannf: Alright, fixed version uploaded, double-checked that the diffs are now clean, and accepted into -proposed.
[17:27] <dannf> yay!
[18:38]  * xnox is playing with ac100 android install before reinstalling it with ubuntu
[19:29]  * xnox ac100 no tarball found hm =/
[21:44] <GrueMaster> xnox: Why would you reinstall that piece of vile vomit back on the AC100?  It isn't even true Android, but a hackified version (similar to the nook, only not as nice).
[21:46] <fly-away> lolwhat
[21:49] <GrueMaster> fly-away: The Toshiba AC100 came preloaded with a heavily modified version of Android (2.3 iirc).  Very ugly and not as easy to use as true Android.
[21:50] <GrueMaster> The system could have been very good if it had more memory and a real OS out of the box.
[21:51] <fly-away> that preinstalled Android pretty close to original
[21:51] <fly-away> one annoying thing - android is for touchscreens now
[21:51] <fly-away> keyboard really unusable
[21:53] <GrueMaster> It felt a lot different than the android I worked with on other systems.  At any rate, there was a lot missing from that system, both hardware and software.
[21:53] <prpplague> well that version of android is pretty old and had "hacks" for keyboard/mouse support
[21:54] <GrueMaster> true.
[21:56] <fly-away> in that android video plays with subtitles very smoothly
[21:56] <fly-away> if you remember)