[08:01] <ogra_> infinity, ah, great, i thought they were disabled by higher order or some such ... my bamboo-feeder tests every new omap3 server image that comes down the drain automatically now so we can see about 1h later if it is installable, at least vm testing is constantly covered with that for omap3
[08:05]  * ogra_ sighs about gvfs .... the archive skew killed all arm builds, fun
[09:03] <suihkulo1ki> meh
[09:04] <xranby> rsalveti: ogra_: http://paste.ubuntu.com/1169507/ - pvr-omap4      dkms/pvr-omap4 fails to compile
[09:04] <xranby> during installation of the pvr-omap4 package
[09:04] <ogra_> what release ?
[09:05] <xranby> quantal
[09:05] <suihkulokki> can ubuntu still accept the patch from bugs.debian.org/676533 for the 12.10 release ?
[09:05] <ogra_> wrong pvr version ;)
[09:05] <ogra_> xranby, 1.9 was uploaded on the weekend, you want that one
[09:06] <ogra_> not sure where its stuck ... probably sitting in binary NEW
[09:06] <xranby> ah
[09:06] <xranby> i thought it had been processed by now
[09:07] <ogra_> suihkulokki, i dont see why not, can you file a bug ?
[09:09] <lilstevie> ogra_, your bamboo feeder is awesome I must say :p
[09:09] <ogra_> heh, thanks
[09:10] <ogra_> i just finished a virtual version that uses oamp3 qemu VMs
[09:10] <ogra_> once i'm done i'll package that as an arm testing suite
[09:10] <ogra_> xranby, https://launchpad.net/ubuntu/+source/pvr-omap4/1.9.0.5.1.1-0ubuntu1/+build/3742590 ... waits for libdri2
[09:11] <xranby> which version of libdri2 ?
[09:11] <xranby> there is a libdri2-1 in the archive
[09:12] <xranby> and a libdri2-dev
[09:12] <ogra_> lets see
[09:13]  * ogra_ gives the pvr build back
[09:13]  * lilstevie wishes there was a qemu tegra
[09:16] <xranby> ogra_: thats really odd. why do your builders fail to find libdri2-1 when i can install it on my panda..
[09:16]  * xranby checking /etc/apt*
[09:17] <ogra_> might be that pvr needs it in main
[09:18] <ogra_> iirc restricted doesnt allow using universe b-deps
[09:40] <xranby> ogra_: i tested a manual build of the sourcepackage: pvr-omap4_1.9.0.5.1.1-0ubuntu1_armhf.deb  pvr-omap4-dbg and pvr-omap4-dev     got built fine
[09:40] <xranby> and they install correctly
[09:41] <xranby> i am still missing libegl1-sgx-omap4  and libgles2-sgx-omap4      that did not got produced from the build
[09:41] <xranby> by the build
[09:43] <xranby> well from the looks of it.. this new package should not build those two package..
[09:43]  * xranby are still puzzled why es2_gears fails
[09:55] <suihkulokki> ogra_: https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1042162
[09:55] <ubot2`> Ubuntu bug 1042162 in openssl "Please enable arm assembler optimisations in openssl " [Undecided,New]
[09:56] <ogra_> suihkulokki, merci :)
[11:28] <sveinse> How can I find the changes from mainstream kernel to the ubuntu modified one? Point is; I have a custom 2.6.37 omap kernel and I'm looking for the ureadahead patch.
[11:28] <ogra_> there are no arm specific changes for omap3 afaik
[11:28] <ogra_> we just use what mainline provides
[11:29] <sveinse> and ureadahead works and has meaning?
[11:29] <ogra_> only omap4 and ac100 use custom kernels
[11:29] <ogra_> ureadahed doesnt support Sd cards yet so makin it work would be moot
[11:30] <ogra_> (and i dont think there are any non mainlined kernel changes required for ureadahead)
[11:30] <sveinse> oh, what is there to support? I mean being a block device like all other block devs
[11:31]  * sveinse admitting not fully knowing what ureadahead really does
[11:34] <sveinse> The goal is to reduce the bootup time. In our product, the kernel is booted within 4 secods. But the main (qt4/qws) app fires up 30 seconds after that. All this time is spent in initramfs and booting, so I'm looking for optimizations ...
[11:35] <sveinse> I was under the impression that precise could boot very quickly (due to ureadahead), and this is what I'm hunting for
[11:59] <ogra_> well, did you try bootchart ? did it show anything obvious?
[12:05] <jimerickson> how come the Aug-27 image of armhf-omap4 is only 22 MB?
[12:05] <sveinse> ogra_, working on it
[12:06] <ogra_> jimerickson, messed up buildds
[12:06] <ogra_> just sotiung it with the IS team
[12:06] <jimerickson> ok thanks
[12:24] <janimo> ogra_, are the live image build logs somewhere public?
[12:24] <janimo> I remember getting mails last  year with links to some but I forget where they pointed at
[12:37] <sveinse> ogra_: You have experience running omap3, right. How is the X performance in OMAP3515? Do you know FH?
[12:37] <ogra_> http://people.canonical.com/~ubuntu-archive/cd-build-logs/ubuntu/quantal/ and http://people.canonical.com/~ubuntu-archive/livefs-build-logs/quantal/
[12:38] <ogra_> janimo, ^^^
[12:38] <ogra_> sveinse, no idea, i havent run omap3 desktop in a long time
[12:38] <janimo> ogra_, thanks
[12:42] <sveinse> We're currently running framebuffer Qt/QWS on a VGA screen. There's a discussion internally if we gain something by running a single window Qt on X. E.g. video support and such
[13:07] <hrw> sveinse: 30s boot is long indeed
[13:07] <hrw> sveinse: tried with other card or usb storage for rootfs?
[14:12] <sveinse> Perhaps a stupid question, and totally OT here. But how do I cross compile for i386 on amd64? I'm used to using arm-linux-gnueabi-gcc, but there is no such i386-linux-gnu-gcc AFAICS
[14:13]  * ogra_ would just use a chroot
[14:14]  * lilstevie uses pbuilder (so chroot like ogra_ said)
[14:17] <sveinse> thanks. Not as trivial as I'd hoped, since you must move everything inside the chroot for it to work. But ok
[14:20] <sveinse> pity. I hoped it was possible to bind mount a directory from the main FS into the chroot there a second... But naah.
[14:20] <ogra_> sure you can
[14:20] <lilstevie> I don't see why you couldn't
[14:21] <lilstevie> unless something has changed recently
[14:21]  * ogra_ does bind mount /dev in his chroots all the time
[14:21]  * lilstevie used to bind mount ~/image_patches when modifying omap images for the tf101
[14:21] <ogra_> no reason why you shouldnt be able to user other dirs ...
[14:21] <ogra_> *use
[14:22] <sveinse> ogra_ very true. I do the same when I come to think of it. I think it might be my chroot script which is too "intelligent" in respect of mount...
[14:25] <sveinse> You're going to frown, but is it possible to create a arm chroot and replace gcc & binutils & make (etc.) with arm-linux-gnueabi-gcc toolset from the host?
[14:26] <ogra_> yeah, people call that OBS :P
[14:26] <sveinse> I mean with binfmt+qemu I there is no principal difference from running i386 vs armel as long as all libs are available
[14:26] <ogra_> right, thats what opensuse build serivce does :)
[14:26] <janimo> lilstevie, do you know if the sensors on the transformer require some android specific userspace binaries to work well? It seems they need at least some ioctls to get started
[14:26] <ogra_> but using self rolled gcc's for everything
[14:27] <lilstevie> janimo, I would have no clue, I really do not see much point for most sensors under ubuntu
[14:27] <janimo> well, at least screen orientation via accel would be nice
[14:27] <janimo> also light sensor for screen dimming
[14:27] <janimo> at least some x86 laptops have the latter
[14:27] <lilstevie> janimo, however I do believe the mpl stuff should work without much userspace interaction
[14:28] <janimo> but probably using platfrom specific code
[14:28] <lilstevie> eh, autobright would be nice
[14:28] <janimo> lilstevie, mpl or mpu?
[14:28] <lilstevie> but accel is a lot of effort from past experience with xorg and accelerometers
[14:28] <lilstevie> mpl
[14:28] <lilstevie> that is the brand
[14:28] <janimo> ah
[14:29] <janimo> I thought Motion Processing Unit as that's how the gyro+accel are referred to in many places
[14:29] <janimo> I have no experience with X and accel, no idea if it works on x86 or some exisiting ubuntu hw  at all
[14:29] <lilstevie> janimo, years ago we tried it with the iPhone 3G
[14:29] <janimo> indeed no use in sensor capabilities if userspace support is not here
[14:29] <lilstevie> but that was karmic
[14:30] <lilstevie> and it was horrible
[14:30] <janimo> there's no unified accel interface/low level lib in linux either
[14:30] <janimo> only platform specifics in each app afaik
[14:31] <lilstevie> but I mean I guess if you could hook it in with xrandr it might be a little bit more bearable
[14:47] <penguin42> can someone try bug 501277 on ARM, it looks fixed on other archs, but I notice the arm* files look like they're missing
[14:47] <ubot2`> Launchpad bug 501277 in gdb "gdb "catch syscall" doesn't work, missing syscalls/amd64-linux.xml" [Undecided,Fix released] https://launchpad.net/bugs/501277
[15:06] <ogra_> janimo, there seems to be a kernel fix for the vm.min_kbytes issue with USB WLAN ... might be good to have that in the ac100 kernel
[15:14] <janimo> ogra_, did not know about that bug, is it in marvin24 branch?
[15:14] <janimo> if so I plan on tracking  that close to release time anyway
[15:14] <ogra_> janimo, huh ?
[15:14] <janimo> ogra_, vm.min_kbytes fix for USB WLAN
[15:14] <ogra_> we added the sysctl.d file so often in the past that i'm surprised you dont remember it
[15:15] <janimo> oh, it was not me who added it I guess
[15:15] <janimo> or if so, it is one of those ugly things I force myself to forget
[15:15] <infinity> Heh.
[15:15] <ogra_> well, its the issue where you get oopses in demsg all the time ...
[15:15] <janimo> anyway I certainly did not know it relates to USB WLAN
[15:15] <infinity> It relates to some drivers, ish.
[15:15] <ogra_> iirc you added it for mx5 :)
[15:16] <infinity> But apw did express concern with the way it was "fixed" in that driver in the ac100 tree.
[15:16] <janimo> I think  I forgot all my mx5 dealings altogether
[15:16] <ogra_> right, and someone (ericm or cooloney) has a fix for that by setting the right value from the kernel
[15:16] <ogra_> infinity, so i have an intresting morning with celbalrai
[15:16] <janimo> I will certainly add it to ac100 if there's a patch already
[15:16] <ogra_> s/have/had/ all fixed now
[15:17] <infinity> ogra_: Yeah, you nick hilighted me in passing, I went and read a bit of it.
[15:18] <ogra_> seems we accidentially ended up with an armel chroot ... at the same time the new live-build grew support for building foreign arches in qemu-static chroots ... guess what happened when the machine reported armel to live-build :)
[15:18] <infinity> ogra_: It was always an armel chroot, which was a non-issue until today.
[15:18] <infinity> ogra_: Or, rather, until livecd-rootfs 2.76.
[15:19] <ogra_> well, until new live-build i guess then
[15:19] <infinity> ogra_: Thanks for hunting that down.
[15:19] <ogra_> well, i wanted images :P
[15:19] <infinity> Passing --architecture to live-build as a result of -A is definitely not what we want. :/
[15:20] <ogra_> yep
[15:20] <infinity> Or maybe it's that --architecture is DTWT.  Pick one.
[15:20] <infinity> But we can worry about that later.  Thanks for fixing for now.
[15:23]  * ogra_ twiddles thumbs waiting for the publisher
[15:24] <ogra_> ubuntu@panda:~$ apt-cache madison libdri2-1|grep main
[15:24] <ogra_> ubuntu@panda:~$
[15:24] <ogra_> *twiddle*
[15:24] <infinity> Hrm?
[15:24] <infinity> Was there an MIR when I wasn't looking?
[15:24] <ogra_> mterry has moved it it seems
[15:25] <ogra_> bug 1042151
[15:25] <ubot2`> Launchpad bug 1042151 in libdri2 "MIR: libdri2 needs to be in main for pvr-omap4 (restricted) to build" [High,Fix committed] https://launchpad.net/bugs/1042151
[15:25] <infinity> Ahh, I was going to work with rsalveti on that today, I guess he got impatient.
[15:25] <infinity> Oh, or you got impatient.
[15:25] <ogra_> and yeah, i added a MIR :) not sure you looked though
[15:26] <infinity> And no, mterry can't move things.  "Fix Committed" is the cue for someone (like me) to fix it. ;)
[15:26]  * infinity fixes.
[15:26] <ogra_> just waiting for it to move so https://launchpad.net/ubuntu/+source/pvr-omap4/1.9.0.5.1.1-0ubuntu1/+build/3742590 can finally build
[15:26] <ogra_> aha
[15:26] <ogra_> i thoguht the MIR team did the actual movin too nowadays
[15:27] <infinity> Well, if the team member who approves happens to be an AA, sure.
[15:27] <infinity> But not all of them are.
[15:27] <ogra_> ah
[15:27] <ogra_> yeah, i know asac isnt
[15:27] <ogra_> not that he does many MIR reviews lately :)
[15:28]  * ogra_ wonders why lubuntu-desktop takes so much longer than ubuntu-server ... the resulting image is 200MB smaller
[15:29] <ogra_> likely more suqashfs fiddling
[15:29] <infinity> Yeah, but desktoppy crap has all those irksome postinsts and triggers that, like... Do stuff.
[15:29] <ogra_> oh, yeah that too
[15:30] <janimo> I am looking forward to lubuntu on the ac100. Had not used lxde before but if it is snappier than unity-2d was I am all for it
[15:31] <ogra_> i was playing with it over the weekend and ended up with a completely new desktop due to playing around :)
[15:32] <ogra_> my test machine is now running a funny awn setup +openbox and pcmanfm
[15:32] <ogra_> htop shows below 100M used right after boot :)
[15:33] <ogra_> intrestingly i needed xcompmgr to get awn working .... t does seem to work realyl fast and flawless
[15:33] <ogra_> ven better than metacitys builtin compositor
[15:33] <ogra_> *even
[15:33]  * ogra_ sighs about his typing
[15:35] <ogra_> infinity, so what do we do to get pvr installed by default (i'm not even sure that works with dkms packages) ... ?
[15:35] <ogra_> we cant just depends on it with ubuntu-desktop ...
[15:36] <ogra_> we could add it to ship and set the "install third party drivers" box in ubiquity by default, but that will also pull in other stuff
[15:36] <infinity> ogra_: We can't install it by default, see the tech-board decision about the "install non-free" checkbox.
[15:36] <infinity> ogra_: But I really have no idea what we can/should do, given that nothing works without it. :/
[15:36] <ogra_> infinity, well, the desktop wont start if we dont have it
[15:36] <ogra_> and the license seems to even permit it
[15:38] <ogra_> infinity, that decision was for flash though ... i cant imagine they would block us if its for a driver
[15:39] <ogra_> bug 723831 btw
[15:39] <ubot2`> Launchpad bug 723831 in ayatana-design "Installer – The option to 'install third-party software' when installing Ubuntu should be selected by default (aka "make Youtube work")" [High,Confirmed] https://launchpad.net/bugs/723831
[15:40] <ogra_> ",We have always made some clearly stated concessions for hardware drivers (graphics, wlan) which http://www.ubuntu.com/project/about-ubuntu/licensing points out. But we unanimously feel that Flash does not at all fall into this category"
[15:40] <infinity> ogra_: The decision has to do with freeness, not flash specifically.
[15:40] <ogra_> pitti in comment #19
[15:40] <infinity> ogra_: Though, I can sort of see the "maybe we can hand-wave drivers past this" thing.
[15:41] <ogra_> yeah
[15:41] <infinity> I haven't even looked at how the drivers-common thing works, since it's replaced jockey.
[15:41] <ogra_> i implemented the arm bits
[15:42] <ogra_> it checks /proc/cpuinfo and works down a list of possible drivers
[15:42] <ogra_> but that doesnt help in the installer
[15:42] <ogra_> it wont run before the desktop is up
[15:42] <ogra_> catch22
[15:44] <infinity> Right.  Well, we could just add it to the squashfs, then, in the subarch section.
[15:44] <infinity> Same place we add the u-boot variant and kernel.
[15:44] <ogra_> how would dkms handle that ?
[15:45] <ogra_> i.e. would we end up with a reboot trigger in the squashfs etc
[15:45] <ogra_> does the build work at all ...
[15:45] <infinity> Dunno, never tried to dkms in a chroot, but I suspect it'll just pick the highest-versioned kernel installed in the root and be happy.  Maybe.
[15:45] <ogra_> hehe, high hopes
[15:45] <infinity> Reboot triggers end up in the livefs anyway, that's nothing new.
[15:45] <infinity> They get cleared at boot.
[15:45] <ogra_> but yeah, i guess putting it into livecd-rootfs is the best
[15:46] <infinity> As long as it doesn't fall over on trying to guess anything about the running kernel (which, if it does, is a bug in dkms anyway, I'd say), it should DTRT, ish.
[15:47] <ogra_> well, lets just add it once pvr is there
[15:47] <ogra_> and see what happens
[15:47] <ogra_> preferably at a time where lamont is up to recover the machine though :)
[15:48] <infinity> I don't see how it would break the builder.
[15:48] <ogra_> well, i dont know how qemu did it on the weekend either ...
[15:48] <ogra_> fact is celbalrai was dead for two days
[15:49] <ogra_> lubuntu-armhf-ac100 on celbalrai.buildd finished at 2012-08-27 15:46:44 (success)
[15:49] <ogra_> yay
[15:56] <infinity> ogra_: FTBFS.  Enjoy.
[15:56] <infinity> https://launchpadlibrarian.net/113731856/buildlog_ubuntu-quantal-armhf.pvr-omap4_1.9.0.5.1.1-0ubuntu1_FAILEDTOBUILD.txt.gz
[15:57] <ogra_> bah
[15:57] <infinity> Missing an entry in pvr-omap4.dirs, I assume.
[15:57] <ogra_> must be a buildd error  :P
[15:57] <ogra_> the buildd  tarball should just ship /build/buildd/pvr-omap4-1.9.0.5.1.1/debian/pvr-omap4/usr/lib/pvr-omap4-egl/ld.so.conf
[15:58] <ogra_> :P
[15:58] <infinity> Uh huh.
[15:58] <ogra_> rsalveti, https://launchpadlibrarian.net/113731856/buildlog_ubuntu-quantal-armhf.pvr-omap4_1.9.0.5.1.1-0ubuntu1_FAILEDTOBUILD.txt.gz
[15:58]  * ogra_ defers friendly :)
[15:58] <infinity> Oh, I'll just fix it. :P
[16:02] <ogra_> hrm, the only thing i realyl dislike about lubuntu is that it defaults to chromium
[16:02] <ogra_> which is broken on arm for 2/3 of a cycle
[16:24] <infinity> ogra_: Test-build successful and uploaded.
[16:24] <infinity> rsalveti: ^
[16:31] <infinity> ogra_: And built just in time, should hit this upcoming :03 publisher run, if you want to play with it.
[16:48]  * rsalveti back on-line
[16:48] <rsalveti> infinity: what was the issue?
[16:49] <infinity> rsalveti: http://launchpadlibrarian.net/113734702/pvr-omap4_1.9.0.5.1.1-0ubuntu1_1.9.0.5.1.1-0ubuntu2.diff.gz
[16:50] <rsalveti> hm, that's interesting, that rules didn't change from previous driver
[16:50] <rsalveti> and built fine when I tested with pdebuild
[16:50]  * rsalveti checking the diff again
[16:53] <rsalveti> yup, nothing changed at that perspective from the previous one, which built fine as well
[16:55] <rsalveti> might be a result of the new compat/source version
[16:55] <infinity> rsalveti: Weird.  Was that directory in pvr-omap4.dirs before?  Or maybe made in another target and the build-arch/build-any split broke you?
[16:55] <rsalveti> infinity: thanks anyway, sorry for not catching it before
[16:56] <rsalveti> not so sure, will try to investigate it more to try to understand what happened there
[17:04] <rsalveti> infinity: ogra_: I also pushed 2 fixes at the xserver and modesettings driver this weekend, so it should finally work fine at this point
[17:04] <rsalveti> the video-omap one should work out-of-the-box and the pvr will be enabled once the pvr-omap4 package is installed
[17:18] <ogra_> oh, curious, why did my panda not have the headers instaled
[17:19] <rsalveti> ogra_: with which kernel?
[17:19] <ogra_> 3.5
[17:20] <ogra_> came with a dist upgrade
[17:20] <ogra_> rsalveti, hmm, ouch
[17:20] <rsalveti> who installs it by default?
[17:20] <ogra_> seems you still depend on dos2unix ... thats still in universe
[17:20] <rsalveti> we can fix that in a patch if needed
[17:20] <rsalveti> let me check that
[17:21] <rsalveti> so we don't need another mir
[17:21] <rsalveti> ogra_: but can you at least try to see if it all works for you?
[17:24] <ogra_> rsalveti, on it, thoguht where was that compiz PPA again ?
[17:25] <rsalveti> we requested the team to publish it for arm as well, don't know if that was done, and we'd also need to change it to use the official branch
[17:25] <rsalveti> which I'm not that sure it happened already
[17:26] <rsalveti> ogra_: check if you're at least able to run es2gears or glmark2-es2
[17:26] <ogra_> k
[17:27] <rsalveti> ogra_: infinity: talking about glmark2, got a patch to fix the ftbs with the latest mesa: bug 1040895
[17:27] <ubot2`> Launchpad bug 1040895 in glmark2 "FTBFS when building against latest mesa (9.0 based)" [High,In progress] https://launchpad.net/bugs/1040895
[17:27] <rsalveti> mesa updated the abi (actually fixing the abi)
[17:27] <rsalveti> but one function was changed to return int to void, which broke glmark2
[17:32] <infinity> rsalveti: Sure, I can sponsor that.
[17:33] <rsalveti> and I'm actually afraid of other issue that might happen with latest mesa
[17:33] <rsalveti> they updated the headers for most of the standards
[17:33] <rsalveti> we'll probably know easily in a rebuild
[17:34]  * infinity throws it at sbuild.
[17:35] <ogra_> rsalveti, hmm, didnt look great
[17:35]  * ogra_ reboots the panda 
[17:35] <rsalveti> ogra_: what happened?
[17:35] <rsalveti> ogra_: if you built the new module, a reboot is needed
[17:35] <ogra_> some dri message "couldnt open pipe window" or some such
[17:36] <ogra_> why ?
[17:36] <ogra_> cant you just make dkms modprobe it ?
[17:36] <rsalveti> did you have the older one installed already?
[17:36] <ogra_> nope
[17:36] <rsalveti> hm, then I believe it was supposed to work
[17:36] <ogra_> was a virgin milestone install, just upgraded regulary until unity-2d was removed
[17:36] <rsalveti> can you provide your xorg.log and the output at your console?
[17:37] <ogra_> hmm, i rebooted already, i dont think xorg keeps a backup
[17:37] <rsalveti> yup, there's a 1.log
[17:37] <ogra_> thats for display 1
[17:38] <rsalveti> the log.old actually
[17:38] <ogra_> but there is a .old ;)
[17:38]  * ogra_ saves it
[17:38]  * rsalveti trying to get his brain started, didn't sleep at the plane
[17:38] <ogra_> oh, where are you ?
[17:38] <infinity> SD.
[17:38] <rsalveti> going to plumbers, at Washington atm
[17:39] <ogra_> ah
[17:39] <rsalveti> got a 4 hours delay at the first flight
[17:39] <infinity> Oh, almost in SD. :P
[17:39]  * ogra_ is envious
[17:39] <infinity> rsalveti: Why a day early?
[17:39] <rsalveti> infinity: 1k $ less
[17:39] <infinity> Ahh.
[17:39] <ogra_> jetlag :P
[17:39] <infinity> It was cheap here, regardless.
[17:39] <infinity> Though a day early wouldn't have hurt my feelings.
[17:40] <rsalveti> I believe there might be some other conferences and stuff to do tomorrow as well
[17:40] <ogra_> OMAP: Failed to load module "omap_pvr" (module does not exist, 0)
[17:40] <ogra_> hmpf
[17:41] <rsalveti> ogra_: check your dkms log
[17:41] <rsalveti> or rebuild the module/reinstall pvr-omap4
[17:41] <ogra_> and lsmod agrees
[17:41] <ogra_> ok
[17:42] <rsalveti> maybe this issue with the lack of headers interfered with your module
[17:42] <rsalveti> getting dkms to skip the build part of it
[17:42] <rsalveti> or similar
[17:42] <infinity> Well, yeah, it won't build unless you have headers installed.
[17:42] <infinity> That's a bit of a no-brainer.
[17:42] <ogra_> well, it wasnt an "issue" theyjust came in when i installed omyp4pvr
[17:42] <ogra_> god !
[17:42] <infinity> But installing the headers SHOULD cause DKMS builds.
[17:42] <ogra_> this kbd is really not for my fingers it seems
[17:43] <infinity> "oh my 4" seems like an appropriate subarch name.
[17:44] <ogra_> haha
[17:45] <infinity> rsalveti: Is the "de $Place" appelation on the end of names still really common down there, or do you just like to show off and have a longer name? :P
[17:46] <infinity> I'd totally be "Adam Conrad of Calgary", but it sounds stupid in English.
[17:48] <rsalveti> infinity: lol
[17:49] <rsalveti> it's still common to have sur names from both families
[17:49] <rsalveti> but the father part is the last
[17:49] <infinity> Ahh.  So, not the placename bit, like in some cultures.
[17:50] <rsalveti> well, we have kind of everything around here hehe :-)
[17:50] <infinity> ;)
[17:50] <ogra_> infinity, oh, btw, riku asked about bug 1042162 do we have any objections ? (i assume not)
[17:50] <ubot2`> Launchpad bug 1042162 in openssl "Please enable arm assembler optimisations in openssl " [Undecided,New] https://launchpad.net/bugs/1042162
[17:51] <rsalveti> hm, interesting
[17:54] <ogra_>  (EE) OMAP: Failed to load module "omap_pvr" (module does not exist, 0)
[17:54] <ogra_> hmm, no go
[17:55] <rsalveti> ogra_: is pvr-omap4 installed?
[17:55] <ogra_> indeed it is
[17:55] <rsalveti> that comes from the pvr-omap4 package
[17:55] <rsalveti> which the video-omap one tries to load
[17:57] <ogra_> ubuntu@panda:~$ dpkg -L pvr-omap4|wc -l
[17:57] <ogra_> 14
[17:57] <rsalveti> try starting X by hand, and give me the output
[17:57] <ogra_> not much in there
[17:57] <rsalveti> Xorg -verbose 10
[17:57] <ogra_> in fact only ld.so.conf, alt_ld.so.conf and copyright
[17:57] <ogra_> is it supposed to be like that ?
[17:58] <rsalveti> nops
[17:58] <ogra_> ubuntu@panda:~$ apt-cache show  pvr-omap4|grep Installed
[17:58] <ogra_> Installed-Size: 47
[17:58] <ogra_> YAY
[17:59] <rsalveti> maybe some other issue with infinity's change
[17:59] <ogra_> the new was of space saving
[17:59] <ogra_> way
[17:59] <rsalveti> but at least it seems the video-omap is loaded automatically already
[18:00] <ogra_> oh, probaby i shoudl remove that xorg.conf i created when testing -omap a month ago :P
[18:00] <rsalveti> yup, there's nothing at the pvr-omap4 package
[18:00] <rsalveti> please :-)
[18:00] <ogra_> still loads OMAP :)
[18:01] <ogra_> so that side is fine ;)
[18:01] <orated> Hello! What is the right method to use qemu-user-static and chroot for compiling/installing packages offline like an emulator. I'm trying to compile OpenCV from source on BeagleBoard XM and its taking long. Which one is right method here - http://paste.ubuntu.com/1170326/ ?
[18:02] <rsalveti> ogra_: weird, some other issue is happening with this driver
[18:02] <ogra_> yeah, 47 bytes doesn definitely not look right
[18:04] <ogra_> orated, after installing apt-get install qemu-user-static just use the qemu-debootstrap command ... after bootstrapping everythinng behaves like any other chtoor in the world
[18:05] <ogra_> i really wouldnt try to build on an SD card (as 2.) seems to suggest) ... just do it in a chroot on the host
[18:06]  * ogra_ is out ... if there is anything to sponsor later i'll drop in for a moment 
[18:07] <orated> One moment ogra_ ... I'd like to confirm the steps please
[18:07] <orated> apt-get install qemu-user-static
[18:07] <orated>    cp /usr/bin/qemu-arm-static
[18:07] <orated> qemu-debootstrap
[18:07] <orated> ?
[18:08] <orated> I've not done bootsrapping before
[18:08] <rsalveti> ogra_: there's a way to use tofrodos instead of dos2unix, which is already in main
[18:08] <rsalveti> ogra_: should have a patch later in the day, and will test with my panda again
[18:12] <infinity> rsalveti: What are you using dos2unix for?
[18:13] <rsalveti> infinity: pvr build system is using it to generate the build files
[18:14] <infinity> rsalveti: Just to strip ^M or something?
[18:14] <infinity> rsalveti: Pretty sure that can be done with something as simple as tr.
[18:14] <GrueMaster> Seems like it could just use tr or something.
[18:14] <GrueMaster> I might even have an old shell script for that.
[18:15] <rsalveti> afaik it was using during it while generating a few files, so not just a simple convert thing
[18:15] <rsalveti> need to dig at the dirty pvr build system
[18:16] <GrueMaster> Ah, here we go.  "tr -d '\015' <$1 >$2"
[18:16] <infinity> rsalveti: Well, it might also be sane to tr the files in question during the package build and ship them translated, and patch out the part where it does it during the module build.
[18:16] <infinity> rsalveti: Shipping icky DOSy files in the package seems wrong.
[18:16] <infinity> GrueMaster: What do you have against '\r'? :)
[18:17] <rsalveti> yup, but it's a pain to maintain as a package patch
[18:17] <rsalveti> as it changes mostly at every update
[18:17] <infinity> rsalveti: No, I mean do it in debian/rules during binary-arch.
[18:17] <GrueMaster> Nothing.  Like I said, old script (i.e. 1996 from my AIX days).
[18:17] <infinity> rsalveti: Don't mangle the source package, just the results in debian/pvr-whatever
[18:18] <rsalveti> sure, but would also need a patch to remove the dos2unix calls
[18:18] <infinity> rsalveti: So what's shipped in the binary packages is sane and reasonable (and readable).
[18:18] <infinity> rsalveti: Yeah, but removing the dos2unix bits is at least maintainable. ;)
[18:18] <infinity> rsalveti: And you have to patch those bits one way or the other.
[18:18] <rsalveti> hurricanes and earthquakes, sounds like a perfect timing to visit us
[18:19] <rsalveti> infinity: yup, agree
[18:22] <rsalveti> something to do at my next flight
[18:24] <rsalveti> bbl
[18:25] <orated> Hi infinity! When I was searching for offline package compilation/installation I found old log - http://irclogs.ubuntu.com/2012/06/23/%23ubuntu-devel.txt - and as you can see, step1 here -http://paste.ubuntu.com/1170326/ -is based on your reply in the log. Could you please guide me which method is right so that I can complete OpenCV source compilation and other relevant installations?
[18:27] <infinity> orated: Assuming you have a rootfs (like ubuntu-core), then those directions seem fine.
[18:28] <infinity> orated: If your goal is package building, though, I recommend mk-sbuild from ubuntu-dev-tools, and just using sbuild/schroot.
[18:33] <orated> infinity: Umm, before someone suggested bootstrapping and now mk-sbuild ;) I'm really confused now. I've only done basic chroot before from liveUSB/CD. I'm not aware of bootstrapping or sbuild/schroot. I'm having difficulty completing source installation of OpenCV on BB XM, that I thought of trying emulator. What's the difference in trying -
[18:34] <orated> apt-get install qemu-user-static, cd /media/rootfs, cp /usr/bin/qemu-arm-static usr/bin/,  cp /etc/resolv.conf etc/resolv.conf, chroot . ?
[18:35] <infinity> orated: mk-sbuild will end up using debootstrap on the backend.  Most of these tools do.
[18:35] <infinity> orated: But yeah, if you have a rootfs unpacked in /media/rootfs (like ubuntu-core, for instance), then those quick and dirty directions work fine.
[18:37] <orated> infinity: Well, then could you explain a bit more how to use mk-sbuild in my case?
[18:38] <infinity> https://wiki.edubuntu.org/SecurityTeam/BuildEnvironment <-- A good writeup.
[18:39] <infinity> http://wiki.debian.org/mk-sbuild <-- A bit less verbose
[18:40] <orated> Thanks, I'll try that