=== calculu5 is now known as calculus === calculu5 is now known as calculus === ynezz_ is now known as ynezz [08:47] The Google Samsung Chromebook has the same ARM chip in as the Nexus 10 - does that mean that I should technically be able to run the ARM versions of Ubuntu on the tablet? [08:51] kvarley: yes, doesn't mean it would have all the pheripherals functioning correctly though [08:52] pheripherals including but not limited to: display drivers (; [08:52] Tm_T: Hmm, true. Could I boot the 13.04 image with the android kernel though? [08:52] Tm_T: A patched driver has hit the 13.04 repos [08:53] kvarley: I suppose it would be worth trying, but I have no knowledge about the said chromebook [08:53] Or so Phoronix claims http://www.phoronix.com/scan.php?page=news_item&px=MTI5Mzg "The Ubuntu 13.04 repository just received ARM's new universal X.Org graphics driver, a.k.a. the xf86-video-armsoc DDX. This is a generic ARM SoC DDX driver for the X.Org Server originally derived from the xf86-video-omap driver." [08:54] Tm_T: I may have to read up on this. I think the stumbling block is having to include the video driver in the rootfs because I'll likely have no wifi access on the device [08:55] Hmm, the SoC is the same but the GPU is different [08:58] Hello. Can you help me remap arrow keys + Alt to End,PgUp etc... I think xmodmap can't help. [09:02] On Chromebook (: === doko_ is now known as doko [09:33] kvarley: 13.04 has most of things you need to get ubuntu running on chromebook [09:38] hrw: Out of the box? [09:38] kvarley: define 'out of box' [09:38] hrw: fresh install [09:38] define 'fresh install' [09:38] hrw: lol, as in the images published for the chromebook 13.04 [09:38] there will be no images for chromebook [09:38] no, there are no images [09:39] i wouldnt say "will be" ... [09:39] but currently there arent any [09:39] no one wanted to join in development of chromebook support and I am too lazy/occupied to work on it [09:39] i use my CB to much, else i would probably invest some time to make images [09:40] but creating the first set simply means a lot of reinstalls [09:40] hrw: Ok, if I took this image raring-preinstalled-desktop-armhf+ac100.tar.gz would it at least boot on the Nexus 10 if I booted with the Android kernel? [09:40] kvarley: nexus 10 != arm chromebook [09:41] hrw: I know, but they share the same SoC so the configuration would likely be similar [09:41] kvarley: ac100 share the same SoC as "LG 4xHD" cellphone - would ubuntu run on a phone? [09:42] kvarley: for nexus10 you may ask ubuntu touch guys do they have some image [09:43] hrw: ok, thanks [09:43] for nexus 4,7,10 and galaxy nexus there are touch images [09:43] kvarley: if you use ac100 image and boot it with default chromeos kernel it will start [09:44] no x11 probably but will start [09:44] it might even fall back to xfbdev ... who knows :) [09:49] anyway that reminds me that 3.4.0-7 is waiting for be built/uploaded [09:51] and I finally got microsd->sd adapters which do not stick out from chromebook [09:52] ogra_: http://dx.com/p/2-in-1-tf-card-to-sd-card-adapter-usb-card-reader-white-126299 [09:53] ogra_: cut usb part and it will not stick out [09:54] * ogra_ wonders why the CSS is so messed up [09:54] its unreadable here ... layers of text over layers of text [10:08] git-buildpackage + chromium-kernel git repo == problems ;d [10:13] good thing is that aptitude works now on armhf [10:15] pfft, aptitude ... [10:15] * ogra_ doesnt know anyone using it [10:16] pretty pointless to have two package DBs installed just for some commandline UI [10:16] ogra_: flash-kernel still does not have DT support? [10:17] i didnt add any ... and nobody sent patches [10:17] ask ppisati :) [10:17] ogra_: show me other useful APT UI for console and I may switch [10:17] aptitude is *not* an apt UI ... it has nothihng to do with apt at all [10:18] I use it as such ok? [10:18] it is its own package tool ... simply duplicating what apt does [10:18] just wastes extra disk space with an additional DB [10:19] * ogra_ stays with apt :) [10:20] I went dselect -> console-apt -> aptitude [10:20] well, except the gui part aptitude today has no features that apt doesnt provide also [10:21] (it used to in the past) [10:21] sure, but I use that UI part [10:21] yeah [10:22] i have better usage for teh several MB that wastes on my disk :) [10:22] ;D [10:29] hm. hacking flash-kernel does not have sense [10:29] it can guess where rootfs is from /proc/cmdline but can not where kernel is stored [10:30] in /boot indeed :) [10:30] along with the dtb [10:30] ogra_: will you package u-boot for chainloading? [10:30] i pull whatever linaro packages ... as usual [10:31] Linaro does not do any chromebook stuff [10:31] if i even have to pull ... i think jcrigby can just upload nowadays [10:31] linatro has the mainline branch as base for their packages ... so you could ask for a binary that goes into ubuntu i guess [10:32] I have no idea which ver of u-boot works for chainloading [10:33] * ogra_ neither [10:33] I use aptitude all the time, largely because of the UI - it is much easier to select packages from multiple choices or look at suggests and recommends manually using an interactive UI than trying to add things to the apt-get command line iteratively [10:33] though mainly on debian, and especially on minimal single-use embedded systems (instead of a desktop), so I guess the situation may look different from an Ubuntu desktop perspective... [10:34] Rjs: I doubt that ubuntu desktop comes with something similarly usable [10:36] well, especially on embedded i wouldnt use aptitude ... unless you have a lot of diskspace [10:37] yep [10:37] there are other tools to get rid of useless stuff [10:37] debfoster for example [10:37] ogra_: hmm, on embedded I've found that aptitude is the best way (for me) to keep the number of installed packages minimal and still have all features I need (I use it with auto-install recommends off and select manually perhaps around 70% of the recommends) [10:38] Rjs: what is your 'embedded' hardware? [10:38] i'm not talking about comfort :) [10:38] aptitude adds its own package database [10:38] in parallel to the apt one [10:38] hrw: mostly alix's embedded geode pc's (i.e. x86) and a few openmoko gta02's [10:39] Rjs: alix was nice hw. I used 1c for few years [10:39] ogra@chromebook:~$ du -hcs /var/lib/apt/lists/ [10:39] 95M /var/lib/apt/lists/ [10:39] if plain apt had an interactive UI with the features of aptitude, I'd probably switch to it, but I haven't found anything comparable... [10:39] hrw@krolik:/var/lib$ du -hs aptitude/ apt [10:39] 7,8M aptitude/ [10:39] 84M apt [10:39] it wont actually double that up but will definitely add a lot on top [10:40] -rw-r--r-- 1 root root 4046282 kwi 4 12:14 pkgstates [10:40] -rw-r--r-- 1 root root 4046326 kwi 4 12:13 pkgstates.old [10:40] that's all? [10:40] dunno, as i said, never using aptitude [10:41] I've found on my system that keeping auto-install recommends on (which I guess would be the only practical choice with a non-interactive UI) would add much more than that amount of diskspace, plus lots of services and background processes that I have no use for [10:41] so switch it off :) [10:42] but it's probably heavily dependent on the user preferences and what the systems are for (e.g., I have several desktop systems without gvfs or udisks or network-manager or all that complexity, but still a somewhat minimal and very usable X11 system for my purposes) [10:42] pfft, X11 .... Mir is the future [10:42] *g* [10:43] at least on arm [10:43] but not the present :) [10:43] well, i heard it works on nexus 4 and 7 already [10:44] the advantage is that it doesnt need any special drivers ... you can just use the android blobs [10:44] ogra_: http://paste.ubuntu.com/5676209/ - everything needed for device tree support? [10:45] hrw, dunno, as i said, talk to ppisati [10:45] ppisati: ping ^^ [10:46] * ogra_ has no clue at all how dtb stuff is implemented in our kernels [10:46] ogra_: s/dtb/DT/ [10:47] and given that nearly all future ubuntu arm development will be android kernel based .... [10:47] (except for server i guess) [10:48] ogra_: I heard rumours that s/eglibc/bionic/ is also planned [10:49] hrw, nope [10:49] that would have been an april fool :) [10:50] ogra_: there was such? :D [10:50] we do make heavy use of libhybris to bridge between the two [10:50] I was mostly travelling on 1st April [10:50] Saarbrücken -> FRA -> TXL -> home [10:51] yeah [10:51] i read g+ :) [10:53] hrw: dtb support for flash-kernel i suppose? [10:53] ppisati: yes [10:53] ppisati: just other way to identify machine [10:54] hrw: iirc we had another patch for dtb support from... marvin? [10:54] marvin24: ^ [10:55] it was similar iirc [10:55] 19:24 < marvin24> hi, I'm about to add http://paste.ubuntu.com/5602702/ to our version of flash-kernel [10:55] * ogra_ remebers it at least using the same path in /proc [10:55] that's not that [10:56] https://launchpadlibrarian.net/133791292/flash-kernel_3.0~rc.4ubuntu29_3.0~rc.4ubuntu29-tegra.diff.gz [10:56] also not that [10:56] he just added support for BT based Tegra board using FDT entry from /proc/cpuinfo [10:57] ~hail /lastlog marvin [11:38] ech, 3.4.0-6 has broken keyboard [12:13] hrw: what is BT based? [12:13] marvin24: DT? Google Snow (aka Samsung ARM Chromebook) [12:13] ppisati, hrw: my goal is to find a way to tell uboot which DT to load until we have full DT support in uboot [12:14] hrw: no, this is for ac100, but all tegra2/3/4 boards should be supported [12:14] btw, does the flash-kernel db support wildcards? [12:14] e.g. Machine: nVidia Tegra* (Flattened Device Tree) [12:15] marvin24: your change used name from /proc/cpuinfo while mine adds reading of model from DT [12:15] hrw: no, I use /proc/device-tree/model as you [12:15] you posted the link [12:16] https://launchpadlibrarian.net/133791292/flash-kernel_3.0~rc.4ubuntu29_3.0~rc.4ubuntu29-tegra.diff.gz [12:16] this is used to copy the device tree to /boot where uboot can find it [12:16] marvin24: you use /proc/device-tree/model to copy DTB but not to identify device in flash-kernel [12:16] hrw: sorry, but why is this necessary? [12:17] the kernel supports multi-soc [12:17] marvin24: Chromebook returns "SAMSUNG EXYNOS5 (Flattened Device Tree)" which covers also Andale which can not boot Chromebook kernel [12:17] marvin24: I have only 3.4 kernel for Chromebook [12:18] looks more like missing Andale kernel support for me - right? [12:18] marvin24: so my goal is to use DT model when cpuinfo reports DT device. this way same SoC devices may run other flavours [12:18] marvin24: I want to support *one* device as I do that in my free time [12:18] I also check for "grep -q 'Flattened Device Tree' /proc/cpuinfo " fiest [12:18] when Linaro kernel teams will get Andale into working condition then they will have 3.9-rc etc [12:18] *first [12:19] marvin24: moment... [12:19] hrw: are you also planing to copy the device tree to /boot ? [12:19] or just use the device tree from uboot [12:20] I don't know how far exynos support has grown [12:21] when user runs 'flash-kernel' script it checks /proc/cpuinfo for Hardware line and then do whatever it has to. For your Tegra work it is enough as you have one kernel for all devices + set of DTB files. So flash-kernel do what it has to and then kernel postinst runs your script to put proper DTB in /boot/ according to /proc/device-tree/model file. In my case on Exynos5 we do not have that luxury and different devices (so far) use different kernels so I need to hav [12:22] and Chrombook is using signed kernels... [12:24] marvin24: but I see how my patch may make your work harder [12:27] hrw: thanks for the explaination [12:27] http://paste.ubuntu.com/5676446/ may be better as allows to cover your usecase (one database entry for whole DT platform) and mine (many database entries per DT platform) [12:28] will require some comments in code to describe it [12:29] hrw: I don't see why your original patch should cause problems [12:30] marvin24: your entry from https://launchpadlibrarian.net/133791292/flash-kernel_3.0~rc.4ubuntu29_3.0~rc.4ubuntu29-tegra.diff.gz will be skipped as DT model name would be used [12:30] marvin24: http://paste.ubuntu.com/5676446/ checks /proc/cpuinfo, gets "NVidia Tegra DT" identifier. Checks database - o, we support it already - go. [12:31] marvin24: when there is no "This platform DT" in database it will read DT model name and search for it. [12:31] ah, machine is something like Toshiba AC100 again instead of common "Tegra20 ..." [12:31] yes [12:32] hrw: ok, so your latter patch should match the common device tree early [12:32] yes, if it is in flash-kernel database [12:33] now I got it - thanks! [12:34] marvin24, ppisati: http://paste.ubuntu.com/5676460/ - is this comment readable enough? [12:36] hrw: looks good to me [12:36] cool [12:37] now how can I get the db entry into offical flash-kernel? [12:37] marvin24: report a bug [12:37] with debdiff [12:38] ok, thanks again [12:38] marvin24: so on AC100 what is in /proc/device-tree/model and what is a name of dtb? [12:39] * marvin24 has to boot up first [12:39] cause on Chromebook it is 'Google Snow' + exynos5250-snow.dtb so your hook for copying DTB may not work [12:40] works [12:46] hrw: model is "Toshiba AC100 / Dynabook AZ" [12:46] thx [12:46] so this would match the old fastboot entry in the db [12:46] while /proc/cpuinfo gives "nVidia Tegra20 (F..D..T)" [12:47] * marvin24 needs to go to the car garage ... [12:48] Bug #1164484 [12:48] Launchpad bug 1164484 in flash-kernel (Ubuntu) "Add support for checking Device Tree model name" [Undecided,New] https://launchpad.net/bugs/1164484 [13:29] hrw, i dont think that patch will fly, you completely ignore the device DB [13:31] hrw, you rather want an entry for each supported DT device in the DB and tell it to use DT ... [13:32] instead of ignoring *all* checks by just runing "if ! check_supported "$machine"; then" [13:34] ogra_: I do not ignore DB [13:34] check_supported checks the DB [13:34] yes [13:35] you *want* that and a proper DB entry [13:35] ogra_: so for all Tegra devices you want DB entry? [13:35] imagine machines with DT and NAND ... or special bootloader setups [13:36] for now you only need one for the ac100 ... andf it needs to switch between the old and new ways [13:36] ok, I start to see [13:36] hangout now - be back [13:36] since the distro doesnt use marvins DT kernel yet [13:40] re [13:41] ogra_: if distro supports DT platform with one kernel - add DT entry. if with several ones - remove DT entry, add DTnames entries [13:42] or we can change check to: grab cpuinfo, check for DT, check for DTName = use if present, use DT if not [13:42] please add comment to the bug [13:43] hrw, yeah, second option sounds good [13:59] can we also add wildcards to the machine detection? or is this too dangerous? [13:59] currently, it seems we only detect exact matches: if [ $value = $machine ]; ... [13:59] i dont think the code can handle that === hggdh_ is now known as hggdh [14:01] something like [[ $value =~ $machine ]] [14:01] (don't know if dash handles this) === fabo_ is now known as fabo [14:19] arr, no regex in dash [14:24] dash lacks everything and more [14:25] I have no idea what you're talking about, but just in case this helps: all Bourne shells should support case which supports matching by glob patterns (not regexps) [14:25] e.g: case "$value" in foo-*) echo match ;; *) echo no match ;; esac [14:25] marvin24: grep -e? [14:28] hrw: maybe one should just replace dash by grep which has more features ;-) [14:32] ogra, marvin24, ppisati: http://paste.ubuntu.com/5676804/ then [14:32] "case" is I think the standard thing to use for wildcard matching in shell scripts, unless you specifically need regexps instead of glob patterns; grep is quite complicated to use in comparison (something like if echo "$value" | grep regexp >/dev/null 2>&1; then except if value begins with -, and I may have forgotten some other detail too) [14:33] Rjs: if [ -n "`echo something|grep`" ]; then ;D [14:34] I have it in one of my scripts... [14:34] lool, any opinion about hrw's patch ? ^^^ [14:35] the case equivalent would be something like: case "$machine" in *device tree*) machine="$(get_devicetree_model)" ;; esac [14:36] (though $(...) is also non-portable, should use `...` instead) [14:38] though if the script is complex enough to have user-defined functions, you could possibly consider just specifying /bin/bash and forgetting about portability :) (unless it's used somewhere where it's possible that only dash or e.g. busybox sh is available) [14:39] hrw, ogra_: still fine I think [14:40] I'll do some more tests in the next days [14:40] maybe I can also solve the regex problem ;-) [14:44] Bug #1164484 - v3 added [14:44] Launchpad bug 1164484 in flash-kernel (Ubuntu) "Add support for checking Device Tree model name" [Undecided,New] https://launchpad.net/bugs/1164484 [14:54] hrw, ogra_: Might be best to call this device_tree_model instead of machine [14:56] lool: and add zillion of 'if/else/fi' in code everywhere? [14:57] lool: machine is also wrong named then - should be proc_cpuinfo_hardware [14:58] hrw: machine is the historical name of it in the code and of the command-line override [14:59] lool: machine is also variable which tells which entry from deviceDB to use - right? [14:59] Yes; currently these are real Hardware names though [14:59] lool: it was Yes/No question [14:59] lool: so what my patch does is just expanding ways of checking for names [15:01] lool: otherwise we will go back into flash-kernel < 3 version where we had huge selects instead of database === NekoXP is now known as Neko [15:04] hrw: It's just that I'd rather grep the db for model entries [15:04] hrw: e.g. search for DeviceTree-Model: xyz in the db [15:05] good point as well [15:06] lool, yeah i think thats what i said above too === W1N9Zr5355 is now known as W1N9Zr0 [19:15] mmh, Xorg on raring crashes [19:16] paste.ubuntu.com/5677653 [19:16] I've seen something like this before [19:16] when pci is missing [19:22] indeed, pci probe [20:02] marvin24, hmm [20:03] segfaulting isnt nice though ... and it works on todays ac100 image [20:05] oh, indeed ... 3.8 ... [20:39] ogra_: do you have nexus7 with ubuntu desktop laying around? Would you please show me it's cmdline? [20:40] i dont ... [20:41] okay, no problem [20:41] it's just that the prebuilt boot.img has console=tty0 in cmdline, and the installer then changes it to tty1, and I'm not sure which one is correct [20:41] it is the cdmline the bootloader sets plus "root=/dev/mmcblk0p7 ro quiet splash" [20:42] doesnt matter [20:42] as long as its a tty [20:42] the prob is that the bootloader puts console= in [20:42] without any value [20:43] that confuses a few things [20:45] ogra_: I think we can fix it - just a moment [20:45] * marvin24 compiles new xserver on his ac100 [20:51] marvin24, give it to tjaalton in #ubuntu-x [20:51] (or mlankhorst if it takes until tomorrow) [20:51] ogra_: ok, thanks - will try [21:20] ogra_: no reply - I guess they will just point me to the bug tracker [21:21] basicly, a simple NULL pointer check is missing [21:21] yeah, i see it in the channel [21:21] i guess he went to bed already [21:21] yes, also time for me [21:21] ha, no, he didnt [21:22] dentist is waiting for me late in the night [21:22] oh [21:30] what's the gpu in a nexus 7? [21:31] and an n900? [21:31] I need to build a gles app and am wondering which way lies least pain [21:32] bloody gpu people are such a PITA, making everything painful [21:32] nexus7 is tegra [21:32] 3 [21:32] if yu use the ubuntu image you even have a proper driver preinstalled [21:32] n900 should be PVR ... no idea what version, no idea about drivers [21:33] I thought the ubuntu image used !X of some sort? [21:33] did you see this about tegra-drivers: http://www.phoronix.com/scan.php?page=article&item=nvidia_tegra_3d&num=1 [21:33] the desktop image uses X ... [21:33] we have two for the nexus7 [21:33] wookey_, https://wiki.ubuntu.com/Nexus7/Installation [21:33] thats for the desktop image [21:34] (i would do the manual install ... but make your choice) [21:34] right I read tha tpage yesterday - I didn't notice anything about two diff images [21:34] gildean, yeah [21:35] ogra_: didn't take them long, only like three years [21:35] OK and 'desktop install' means 'normalish ubuntu' [21:35] wookey_, https://wiki.ubuntu.com/Touch/Install ... thats the android based Ubuntu Touch [21:35] right, desktop means literally desktop :) [21:35] OK, just 'desktop on a small screen' [21:35] yep [21:35] sadly not scaling very well :) [21:36] so you'll still need a keyboard and mouse to do various things [21:36] yup [21:36] there is an onscreen kbd [21:36] OK. I was hoping that I could use the touch UI and make it work reasonably for the small set of about 3 programs I need to run [21:36] but for programming you want a real one or at least ssh [21:37] sure, use the touch image for that ... but that doesnt use X [21:37] but as you say with onscreen keyboard and unity and some tweaking maybe the desktop version can be OK [21:37] problem is that the main app uses wx and wx needs X (I think) [21:37] you have the choice :) [21:37] ah, yeah [21:38] that keeps you stuck on the desktop image [21:38] OK. that clears some things up anyway. [21:38] It does seem like the least-painful option for now [21:39] hopefully it'll be a bit less crufty than debian on an openmoko :-) [21:39] which was pretty damn crufty [21:41] heh [21:41] it is snappy and pretty usable actually [21:42] i used it as my living room tablet and as ebook reader ... worked fine for that [21:42] the stuck-mouse-button bug is still there unfortunatelly :/ [21:43] yeah, there is a fix upstream though [21:43] sadly apparently hard to backport [21:43] yeah, saw the discussion on launchpad [21:44] but from what I can understand from that bug entry, it is set as must-fix before raring release, right? [21:44] well, it was ... now touch came around ... [21:44] we'll see [21:44] hm, yeah, and mir [21:45] Mir wont enter the archive before release [21:46] no, but I suppose the nexus7 image doesn't have very high priority...or does this happen on all touchscreen devices, even PC? === rsalveti_ is now known as rsalveti