=== Ursinha-afk is now known as Ursinha [04:12] and here I am!! \o/ [04:13] hey guys [04:13] and gals [04:13] anyone been using Ubuntu on CuBox? [04:13] ok... what about on raspberry pi? [04:14] UG802 maybe? [04:14] ok, so what about Nexus7? anyone? [04:15] n7. works good [04:15] gotta get mine in one week tho] [04:16] so far I've only ubuntu running on CuBox [04:16] UG802 will get by here any day [04:16] ptl, from the topic "If you have a Pi, try #raspbian ! " [04:16] workin on minimal ubuntu build process for n7 [04:16] lilstevie: I was just trying to start a thread. I don't have a raspberry pi... [04:17] live-build rox, just a lot of docs to read [04:17] "start a thread"? [04:17] isn't the build process already in place at canonical? [04:17] i couldnt find configs or anything re: build process other than how to create the images [04:18] ah... [04:18] which is fairly trivial [04:18] will you make it public? homepage and such [04:18] ptl, canonical does not support the cpu architecture that the raspberry pi uses [04:19] https://github.com/ngharo/ubuntu-nexus7-minimal-livebuild here's the repo. I'll be fleshing it out more on tuesday [04:19] lilstevie: isn't the kernel unifying the ARM architectures right now? [04:19] this will dump out a tarball, which you'd need to massage a bit for n7 [04:19] * ngharo is going to tweak makefile to do the massaging soon [04:19] ngharo: thanks. It will not have any use to me now, until I get my hands on the Nexus7. Do you think it might work in other devices? [04:20] like, not tablets [04:20] ptl, that doesn't matter, even once the kernel unification is done, the raspberry pi is a different cpu architecture to what canonical support [04:20] yeah probably, it should work on any armhf arch device [04:20] humm... do you know if canonical supports the Marvell Armada? [04:20] just would need to remove the n7 packages from the config [04:20] that's what my cubox uses [04:20] ptl, ubuntu-arm is built on armv7+ with hardfloat support. the raspberry pi is armv6 [04:21] armv7l [04:21] ah [04:21] I never got the gist of these ARM types and variants [04:22] I'll wait for my second CuBox and maybe make it a highly available cluster using drbd [04:22] ptl, the difference is the evolution of the processor, they work differently, mostly they are backwards compatible, but older versions cannot run stuff for newer versions due to lacking support for the instructions [04:24] lilstevie: that's why I did not buy a Pi! :) CuBox, yeah. I thought about buying a D2plug but it was too expensive [04:25] there are many reasons not to buy a pi [04:25] armv6 is just one of them [04:26] does the ubuntu on nexus 7 supports multi-touch? [04:27] afaik it is limited [04:28] on the tf201 I get multitouch, but how it can be used is still fairly limited [04:28] what is a tf201? [04:28] ah [04:28] transformer prime [04:28] did you install ubuntu on it? [04:29] yes [04:40] how it works compared to the one in nexus7? better? worse? or more or less of the same? [04:41] I don't have a nexus 7 [04:43] thought you had === zz_chihchun is now known as chihchun [05:12] ngharo: you have a "configure" script but no config.ac / Makefile.am ? [05:13] *configure.ac [07:47] good morning [10:15] ptl: configure.ac may also reside in separate subdir [10:19] hrw, so that missing dri support seems to be quite an issue in the armsoc driver, any idea how to get around that ? (see the build log) [10:21] ogra_: plan to work on it after vacations [10:21] looks like configure(.ac) needs fixing [10:22] I was supposed to be on streets of Palamos enjoying last sun. instead sitting with laptop in a building ':D [10:22] well, even if i force DRI=yes in there ist doesnt build any armsoc_dri.so (which it looks for according to Xorg.0.log) [10:22] oh. get out then ! [10:23] ogra_: first have to reply to interesting email [10:28] ogra_: chromium os also lacks dri driver [10:28] ogra_: can you check is there dri driver for omap boards? [10:28] do you have the same message in your Xorg.0.log there ? [10:28] there is a dri2 one but that doesnt land in the search path the driver uses [10:29] also did you note that there is a link in the source to ../xf68-driver-omap or so ? [10:30] armsoc is a continuation/fork of omap/armsoc one [10:30] yep, i know [10:30] i was just wondering if anything from that link is used during build [11:08] anyone else notice that network-manager-applet doesn't work properly on the first boot of the nexus 7? [11:10] brendand, yep, we need a rebot after setting the hostname, there is a bug open somewheer iirc [11:10] *reboot [11:11] is there a way to flash a bigger rootfs to nexus 7 with fastboot? Everything bigger than ~700M seems to just hang the fastboot (I guess it doesn't fit to memory or something) [11:15] kulve, there is the -S option buut it is slightly unreliable which is why we stopped using it [11:15] ogra-cb_: -S option to what..? [11:15] ffastboot flash [11:17] hmm.. Is that documented somewhere? "fastboot --help" doesn't show it [11:19] it does here [11:20] http://paste.ubuntu.com/1352881/ [11:20] see the last line [11:21] ah, true. I was checking in a different Android env assuming that it would the the same.. [11:23] do you happen to know what that does in practice..? I don't understand what the word "sparse" means in that context.. [11:27] it chops file it flashes into pieces of the size you define and re-assembles it during write [11:27] so you can define chunks that fit in ram [11:50] ogra-cb_: thanks. Sounds exactly what I need (even if it wouldn't work 100%). I somehow thought that the option was for something else [12:14] marvin24, hmm, do you remember if we pulled zram separately into the ac100 tree ? [12:15] i'm looking at 3.4 mainline atm (for chromebook) and zram has a depends: X86 in Kconfig here [12:16] ogra-cb_: no, I cherry picked it [12:16] ah [12:16] thx [12:16] in 3.4, it was disabled for !x86 [12:17] which was fixed in 3.5 or 3.6 or so [12:17] right, just dropping the dep breaks it [12:18] ogra-cb_: nivdia made a new kernel release [12:18] this has nothing to do with the video drivers [12:18] just a kernel service release [12:18] yeap, i know but i assume the drivers will follow [12:19] since they are currentlly heavily broken [13:14] ogra_: ogra-cb: looking at bug 771736 what exactly does it need in the initramfs? [13:14] Launchpad bug 771736 in nilfs-tools (Ubuntu Oneiric) "please include nilfs2 in hook-functions" [Medium,Confirmed] https://launchpad.net/bugs/771736 [13:14] the gc daemon? [13:14] yeah [13:14] there was an initramfs snippet already somewhere [13:15] also the module needs to be pulled into the initrd [13:15] i dont think we have that yet [13:16] I see the snippet to pull module, don't see one for any daemons.... [13:34] xnox, i can imagine that cleanerd cant be restarted safely once it runs, so it is omitted for the initrd [13:35] (indeed stateful re-exec in upstart should fix that) [13:38] ok. let me try stuff then. [13:39] stuff is good :) [13:39] * ogra_ tries more coffee-stuff [13:39] lol [13:40] * xnox remembers about the cheese and toast stuff [14:01] victorp, ! [14:07] ogra_, !? === dmart_ is now known as dmart === karim is now known as Guest78743 [15:28] heh, with that 'Disable "glx"' tweak the shaded keyboard comes up fairly quickly [15:28] well, it eats one of your CPUs then though [15:29] software rendering doesnt come for free sadly :) [15:30] ogra_, oh right. it *is* only sw rendering [15:31] ogra_, what needs to happen for hw rendering? [15:31] brendand, i assume onboard needs to use gles instead of gl functions [15:31] havent looked much at the code yet [15:32] ogra_ - oh it's onboards problem specifically? [15:32] well, its a prob of app using plain GL instead of the GLES subset [15:33] if you use any GL functions that arent in the GLES subset it will try to use SW renerind [15:35] Hello [15:36] Someone in there ? [15:36] no, just 165 people idling here [15:36] :) [15:36] Great ! [15:37] I'm looking for information about Ubuntu for Android [15:38] I've bought the PadFone from Asus and I would love to have ubuntu running on it when docked ! [15:38] ogra-cb: you've said that I really should not flash different boot image on my nexus7 every time I wanna switch android<->ubuntu, because of the mmc load [15:38] but the /data partition must get several times higher io load, no? Is the boot partition somehow different? === NekoXP is now known as Neko === Neko is now known as NekoXP [15:40] tassadar, flashing means you always write to the same place (i.e. dd), there is no filesystem layer [15:40] while using a rootfs you have an additional layer that cares for wear levelling [15:41] diablotin, i dont think there are any public versions of U4A yet, its still being worked on [15:41] ogra-cb: even an alpha ? beta ? [15:42] nothing public i know of [15:42] But is U4A gonna be downloadable or we'll have to buy it with the phone ? [15:42] Ok [15:43] hmm, right, thanks [15:53] datasheet of kingston emmc memory chips (the ones used in nexus 7) says that these chips have static wear-leveling [15:54] all MMCs have that [15:55] robclark, do you happen to know anything about the armsoc driver ? [15:55] * ogra-cb wonders what to do to make it not complain about dri.h not being compilable [15:56] and "the internet" tells me that eMMC is NAND chip with controller, which handles the wear leveling and bad block management, among other things [15:56] does dd bypass that? [15:56] no, its HW, nothing you can bypass [15:57] ogra-cb, well, armsoc was branched off the omap driver.. I think hrw made some patches to fwd port it to latest xorg.. [15:58] right [15:58] and ir works quite well hwen copzing the GLES/EGL and mali libs [15:58] so it is not using the same cell over and over again, and each cell should endure 1k-3k overwrites [15:59] but it still complains about dri.h during build and i.e. unity doesnt seem to be accelerated [15:59] that gives me the impression it is not that bad [15:59] it will shorten the lifetime of the MMC nontheless and its really dangerous, i wouldnt use flashing if i dont have to [16:00] if you crash in the middle your device turns into a brick and you have to completely reinstall [16:00] yeah, I'd like to use the kexec, but I can't get it working by myself - it is simply too low-level [16:01] I tried applying the kexec-hardboot patches, but I've got stuck on reseting of the CPU via watchdog [16:02] the patches were made for different CPU, and well, there is no datasheet for tegra 3 available [16:02] robclark, https://launchpadlibrarian.net/122595562/buildlog_ubuntu-raring-armhf.xf86-video-armsoc_0.4.0-0ubuntu4_BUILDING.txt.gz see the dri.h complaint ? i can force DRI=on but dont get different results in behavior of the binary [16:06] ogra_, so what is the best method to put up a notice at package install and have it ignored at image build time? I remember debconf notice (or note?) being discouraged [16:07] well, note is discouraged, but probably the best you can use [16:07] have a look at the sun java package [16:08] ogra-cb, hmm, /usr/include/xorg/dri.h looks like dri1 stuff.. I suspect armsoc shouldn't be looking for that [16:09] janimo, during all aem image builds we export FLASH_KERNEL_SKIP=true ... so only show the note/message/whatever if thats not set [16:09] hmm, that said, xf86-video-omap does too.. I'm not entirely sure why you see that issue but I don't.. maybe try building xf86-video-omap the same way? [16:09] robclark, ah, awesome, so i can just rip that out [16:09] thst the info i was missing :) [16:09] I think so.. at least that is what I'd try first [16:11] well, it already works fine for es2gears or glmark ... its just unity thats very slow [16:11] though hrw doesnt use the alternatives system, might be that the current driver ends up with a mishmash of mesa and mali [16:11] hi [16:12] yeah, sounds a bit like it [16:12] ogra-cb: I have crhomium-opengles package which handle egl for mesa stuff [16:12] hrw, oh ! [16:12] but it requires binaries [16:12] and I do not think that libmali* has license for re-distribution [16:12] the loibs we manually copy i guess [16:13] yeah [16:13] * ogra-cb was fearing that [16:14] ogra-cb: http://tygrysek.juszkiewicz.com.pl/~hrw/ubuntu/chromebook/ [16:14] ogra-cb: fetch tar.xz, add libmali and build [16:15] * ogra-cb will try that later today [16:16] ogra-cb: cgpt, kernel signing and kernel is what left on my list [16:16] I gave up on xf86-input-cmt - too many deps [16:16] and really no need for it [16:17] yep [16:17] i have my touchpad working exactly as on cros here [16:17] it feels a bit delayed in reaction, but i blame X here or unity [16:18] but two finger scrolling, two three and four finger taps etc, all work [16:26] janimo, bug 1068182 was just pointed out to me [16:26] Launchpad bug 1068182 in linux-ac100 (Ubuntu) "Regression: several kernel modules now missing in 12.10 3.1.0-6-ac100 kernel compared to 12.04 3.0.27-1 kernel" [Undecided,Confirmed] https://launchpad.net/bugs/1068182 [16:46] checking whether to include DRI support... checking for /usr/include/xorg/dri.h... yes [16:46] checking for /usr/include/xorg/dristruct.h... yes [16:46] checking whether to include DRI support... [16:49] nice [16:50] autoconf suxx [16:50] heh, ++ [16:51] and headers which no longer include required headers suxx too [16:51] dri.h requires 1, dristruct.h 4 [16:54] http://paste.ubuntu.com/1353543/ [16:54] thats whole configure.ac patch [16:59] how do I create a sparse file system image suitable for fastboot flash -S? [17:02] kulve, you use make_ext4fs [17:03] bye [17:03] kulve, from android-tools-fsutils (in raring) [17:03] ah, thanks. Was just about to ask [17:03] kulve: it's also available in a ppa for quantal and precise [17:04] in the install ppa owned by ~ubuntu-nexus7 [17:04] ah, right, forgot the ppa [17:04] ;) [17:04] * xnox blogged about it on ubuntu-planet surely everyone saw it =) [17:05] * ogra-cb did, but forgot about the ppa nontheless :) [17:10] weird. I have debian stable, so I took the package from debian unstable and recompiled. But for some reason that doesn't have -fsutils, even though the ubuntu version with the exact same version number does.. [17:12] the ubuntu package has an ubuntu1 version [17:12] that means it carries one change change thats not in debian [17:12] guess which one :) [17:13] -change [17:14] no man page.. Is -l for the whole rootfs size? Like 13GB or something like that? [17:14] yeah [17:14] ypu want -l and -s iirc [17:16] kulve: I did forward the debdiff to debian bug 692851 [17:16] Debian bug 692851 in android-tools "android-tools: please package the rest of the fs tools" [Normal,Open] http://bugs.debian.org/692851 [17:16] you can recompile with that patch..... [17:18] I already compiled the ubuntu version. I guess debian wants also man pages always? Maybe that's why make_ext4fs was removed from the packaging? [17:18] fastboot doesnt have a manpage either [17:19] so it seems [17:19] while thats a bug i dont think it is a blocker anzmore [17:21] kulve: the point is there is no upstream build system, and makefiles were written for "interesting" tools at the time (fastboot). Now that it's possible to fasboot flash ubuntu/debian, the fsutils became "interesting" so I wrote a few more makefiles to compile them. [17:21] kulve: so just ongoing evolution of packaging bits of android tools git forest. [17:21] I didn't even know that there are such things outside android until yesterday [17:23] hmm.. fastboot taking 100% and 600MB of memory (and increasing) [17:23] are you sure your device is in flash mode and properly connected and detectet ? [17:24] at leaste "fastboot erase userdata" worked.. [17:28] still more questions. What should the last parameter "directory" actually contain? At least is doesn't seem to like having a /dev in there.. [17:29] http://newscenter.ti.com/2012-11-12-New-OMAP-5-processor-based-modules-spur-easier-faster-industrial-designs [17:33] I figured out why the fastboot went into a leaking busyloop (or something else weird). I forgot the "M" after "-S 256".. [17:33] great, now seem that on miniITX boards please so we finally build arm desktop PCs [17:33] s/seem/sell/ [17:59] Calling hook nilfs [17:59] Adding module /lib/modules/3.5.0-17-generic/kernel/fs/nilfs2/nilfs2.ko [17:59] are the raring panda images working? [17:59] I guess I need to add partman-nilfs to complete the circle. [18:00] then the next question will be "will it fit" in the panda/ac100/nexus initramfs. [18:00] and whether it is built.... [18:20] xnox, panda has no restrictions [18:20] only fastboot based bootloaders do [18:21] and iirc it did fit into ac100 last time i tried [18:21] nexus shouldnt differ much [18:21] ogra-cb: good. [18:21] are the raring panda images working? Will try to do partman-nilfs module for the installer. [18:22] i havent tried one yet [18:22] ok =) I will tomorrow. [18:22] i usually started that with A1 preparation [18:22] i guess i have to make up some personal schedule now :) [18:22] lol. well x86 desktop are borked because of secure-boot, but colin fixed it, so tomorrow should be better =) [18:22] "opt-in milestones" [18:23] heh, yeah [18:23] technically this is second week since UDS, such that we should have a fully working set by thursday..... [18:23] well, i doubt i can do it wrt nexus until thu [18:23] still no kernel [18:26] which is interesting since kernels don't need much review to go through. [18:27] and we just had ppc kernel whizz through.... [18:28] Any hints why my nexus fails to mount the fs that create with "sudo make_ext4fs -s -l 4G rootfs.img build/" and flash with sudo fastboot flash -S 256M userdata rootfs.img"? [18:29] xnox, well, the nexus kernel sits in the queue longer, i watched the ppc one go bz whiule reloading the queue page over the weekend [18:29] kernel just tells that it failed to mount it as ext2/3/4/etc, shows the list of the partitions and reboots after 10sec [18:29] *by [18:30] kulve, sounds like your initrd isnt used [18:30] * ogra-cb needs to try something ... brb [18:31] ogra-cb: yeah, I'm trying to manage without it. It did manage to create "normal" ext4 and mount that, but it had the space limitation [18:33] hrw, wow, that touchpad snippet helps a lot !! [18:34] ogra-cb: xorg.conf one? [18:34] ogra-cb: thanks should go to ojn not me [18:35] it makes it so much more sensitive [18:41] [ 24.541] (EE) AIGLX error: dlopen of /usr/lib/arm-linux-gnueabihf/dri/armsoc_dri.so failed (/usr/lib/arm-linux-gnueabihf/dri/armsoc_dri.so: cannot open shared object file: No such file or directory) [18:41] [ 24.541] (EE) AIGLX: reverting to software rendering [18:42] hrw, from your Xorg log [18:42] so i guess ripping out dri1 completely is actually needed [19:04] ogra_, can you give me the exact config diff you use to talk to cbc_multi? When I switched the android out and also made things modular the kernel did not build - the same cable_somthing error you saw too [19:40] ogra_: fun is that it looks that dri1 is not even used in code - only in configure [19:52] ogra@chromebook:~$ /usr/lib/nux/unity_support_test -p|grep supported [19:52] Unity supported: yes [19:52] ogra@chromebook:~$ grep rendering .xsession-errors [19:52] compiz (core) - Info: Unity is not supported by your hardware. Enabling software rendering instead (slow). [19:52] i dont get that [19:52] it works fine on the nexus [20:30] ogra-cb: what is the return core from /usr/lib/nux/unity_support_test ? [20:30] hm, but by the message the limitation is inside compiz [20:30] lack of extension? [20:30] remember that this is a different driver :-) [20:30] so different kind of fun [22:54] hey guys, any support for the AMLOGIC 8726M?