| === stgraber_ is now known as stgraber | ||
| === XenGi is now known as XenGi_ | ||
| cobalt60_ | Anyone install Ubuntu on the Lenovo Yoga? | 02:46 |
|---|---|---|
| lilstevie | cobalt60_, I'm assuming you are referring to the yoga 11 given the room we are in | 03:01 |
| lilstevie | to which the answer will be, no, nobody will have installed ubuntu on it, because of secureboot | 03:01 |
| cobalt60_ | Yes the 11. Thats too bad... | 03:12 |
| cobalt60_ | any other ARM netbook with a touchscreen running Ubuntu? | 03:13 |
| === zz_chihchun is now known as chihchun | ||
| hrw | cobalt60_: asus transformer line of tablets + keyboard dock | 08:18 |
| lilstevie | however ubuntu probably could run a little bit better on them :p | 08:22 |
| hrw | no idea how it works on those ;D | 08:23 |
| marvin24 | <ogra_> marvin24, you mean to your kernel package, not flash-kernel, right ? | 08:33 |
| marvin24 | ^ no - I decided to use flash-kernel | 08:33 |
| marvin24 | it seemed more appropriete to me | 08:33 |
| marvin24 | in fact, the scripts gets called on every kernel install | 08:34 |
| marvin24 | arrr, it failed to upload again | 08:36 |
| === yofel_ is now known as yofel | ||
| suihkulokki | plan to use nano-sized usb stick as ubuntu rootfs on chromebook foiled by the fact that usb support is in modules... | 09:54 |
| phh | and then you discover initramfs... | 09:56 |
| phh | and realize than on most x86 distribs, everything is in module, either sata or usb or pata or whatever storage you use. including the FS | 09:56 |
| suihkulokki | unfortunately the chromebook firmware doesn't support initrd | 10:19 |
| hrw | suihkulokki: I think that we need to switch to chainloaded uboot | 10:20 |
| hrw | a bit overhead but easier support | 10:20 |
| hrw | no kernel signing | 10:20 |
| suihkulokki | sticking to sd card booting for now | 10:31 |
| suihkulokki | the sd card is anyways 5x faster than the cruzer fit I bought | 10:31 |
| hrw | sd ends at ~20MB/s in chromebook | 10:36 |
| hrw | my samsung does 20MB/s read and 8MB/s write | 10:36 |
| ogra_ | USB 3.0 FTW :) | 10:37 |
| hrw | ogra_: 76MB/s from old harddrive | 10:44 |
| hrw | ogra_: 135MB/s from new one but this one is in use with other machine normally | 10:44 |
| ogra_ | yeah, i'm still looking for a micro USB 3.0 key for my chromebook | 10:51 |
| * ogra_ doesnt like things that stick out of the case to much | 10:51 | |
| suihkulokki | that was kind of the idea of the cruzer | 10:53 |
| hrw | suihkulokki: and you know that default bootloader do not check usb3 port when you press ^u? | 10:54 |
| suihkulokki | hrw: no I didn't.. | 10:55 |
| hrw | probably no xhci support in u-boot for that | 10:56 |
| suihkulokki | most likely | 10:58 |
| ogra_ | ppisati, have you seen marvin24's patch to flash-kernel to support dtb ? would that work generically enough for our own kernel packages too ? | 11:04 |
| ppisati | ogra_: didn't see it, where is it? | 11:04 |
| ogra_ | http://paste.ubuntu.com/5602702/ | 11:05 |
| ogra_ | marvin24, hmm, line 9 looks wrong btw | 11:06 |
| ogra_ | i guess you meant $x | 11:06 |
| ogra_ | and line 3 shouldnt use if ... | 11:06 |
| ogra_ | grep -q 'Flattened Device Tree' /proc/cpuinfo || exit | 11:07 |
| ogra_ | (and it should rather exit gracefully instead of "exit 1" if there is no device tree, we still have many kernels that dont ship it) | 11:09 |
| marvin24 | ogra_: ok, thanks for comment | 11:26 |
| ogra_ | hmmm, disregard the last one ... i'm not completely awake today :) | 11:27 |
| marvin24 | I wonder how it worked with $z at all ... | 11:27 |
| ogra_ | heh | 11:27 |
| marvin24 | yes, line 3 checks that already | 11:28 |
| ogra_ | right | 11:28 |
| ogra_ | i just need ppisati to confirm it works with the other dtb kernels too, then we can pul it into raring | 11:28 |
| ogra_ | *pull | 11:28 |
| marvin24 | I used flash-kernel, because the scripts in /etc/kernel/* seems to come from various packages, but linux-image provides none | 11:28 |
| marvin24 | ogra_: cool - that would be nice | 11:29 |
| ogra_ | i thougth it provides the postinst.d bits | 11:29 |
| marvin24 | tegra needs also to be added to the db | 11:29 |
| marvin24 | ogra_: flash-kernel does, but not the linux-image package itself | 11:29 |
| ogra_ | k | 11:30 |
| ogra_ | ogra@anubis:~$ dpkg -S /etc/kernel/postinst.d/*| grep linux | 11:31 |
| ogra_ | ogra@anubis:~$ | 11:31 |
| ogra_ | yeah | 11:31 |
| === XenGi_ is now known as XenGi | ||
| === XenGi is now known as XenGi_ | ||
| === Jack87|Away is now known as Jack87 | ||
| ogra_ | xnox, hmm, did you replace compiz with metacity ? it just struck me that i didnt have a single chrash during my test install | 16:11 |
| xnox | ogra_: no, i did not. | 16:13 |
| xnox | but there was a compiz / unity update recently?! | 16:14 |
| ogra_ | yeah, several over the last week | 16:16 |
| ogra_ | (2 at least i think) | 16:16 |
| ogra_ | seems to have fixed the world :) | 16:16 |
| ogra_ | or i was just lucky | 16:16 |
| === XenGi_ is now known as XenGi | ||
| === XenGi is now known as XenGi_ | ||
| === XenGi_ is now known as XenGi | ||
| === prp^2 is now known as prpplague | ||
| mjrosenb | is there an armel compiler available for armhf systems? | 19:20 |
| djvj | need info on how to install armel GCC onto an armhf installation (raring) | 19:30 |
| djvj | online info seems kind of sparse on this issue. tried dpkg --add-architecture armel and apt-get updating, but update simply complained about there not existing armel repos | 19:31 |
| NekoXP | mjrosenb, you can compile armel stuff with the armhf compiler. the tuple is just a ridiculous packaging kludge. | 19:38 |
| NekoXP | -mfloat-abi=softfp and it'll generate the right binaries (you may need to drag in armel multiarch/lib dependencies first though) | 19:39 |
| NekoXP | alternatively if you need the tuple to be right, just install gcc-arm-linux-gnueabi{,-4.7} or so (version dependent on your ubuntu, maybe don't need the version at all to get the right package) and it'll do the right thing. | 19:43 |
| infinity | NekoXP: gcc-arm-linux-gnueabi is a cross-compiler. | 19:44 |
| NekoXP | djvj, same info to you I think.. the right things should be there, I don't think you have to add-architecture if raring is really multiarch compliant. | 19:44 |
| infinity | djvj: Just install g++-multilib and use -mfloat-abi=soft (or softfp, depending on your target) | 19:44 |
| NekoXP | infinity, on ARM? not really, just a compiler built to different defaults.. | 19:44 |
| infinity | NekoXP: That package doesn't exist on ARM. | 19:45 |
| djvj | infinity: thx | 19:45 |
| NekoXP | huh did it get removed | 19:45 |
| infinity | NekoXP: It never existed on ARM. | 19:45 |
| NekoXP | it installs fine on quantal armhf... that said maybe I have some linaro ppa floating around | 19:45 |
| infinity | NekoXP: All the gcc-triplet packages are cross-compilers. | 19:45 |
| infinity | NekoXP: At least, in the archive. | 19:45 |
| infinity | djvj: As to why the add-architecture bit didn't work for you, that's because raring has no armel anymore. We dropped the arch. | 19:46 |
| djvj | mjrosenb: I think my issue is not in particular with the compiler. it's that the object is built with the appropriate -mfloat-abi and -msoft-float args, but then it attempts to build the final binary without passing those. | 19:46 |
| infinity | djvj: But if your goal is just to compile a soft-float binary for some reason, g++-multilib will DTRT. | 19:46 |
| djvj | infinity: oh.. what was the reasoning behind the drop? | 19:46 |
| infinity | djvj: We had no compelling reason to support it. Every platform we target can use armhf. | 19:47 |
| infinity | djvj: Which also leads to the question of why you're compiling soft-float binaries, but maybe you have a reason. | 19:48 |
| NekoXP | here's the real question, why would you bother compiling for softfloat anyway on an ARM box running armhf? If you've got to have that capability use an x86 box and use a cross-compiler.. is it just that there's some native packaging requirement that dpkg-cross doesn't handle? | 19:48 |
| djvj | infinity: Actually now that you mention it, I'm not sure. Lemme ask.. | 19:51 |
| infinity | mjrosenb: Oh, and I didn't notice you'd asked the very same question. apt-get install g++-multilib and use -mfloat-abi=soft (or softfp, if your target supports that). | 19:54 |
| djvj | infinity: Well, no answer yet, but I'm trying to build spidermonkey on ARM. I think its JIT uses the armel ABI for float ops. | 19:59 |
| infinity | djvj: Well, if it's also going to depend on any system libraries other than libc/libstdc++, that's just plain not going to work. | 20:00 |
| infinity | djvj: If the intent is to run it on armhf somehow. | 20:00 |
| infinity | djvj: If the intent is to build and run it on armel, just use Debian/armel, since targetting a non-existent Ubuntu armel seems silly. | 20:01 |
| infinity | djvj: (And, more to the point, if it fails with armhf, perhaps fixing it would be smarter than working around, as all modern armv7 distros are going/gone hard-float) | 20:01 |
| djvj | infinity: it should be possible to just set up a chroot environment and target debian repos inside that, no? | 20:02 |
| infinity | djvj: You can debootstrap a sid/armel chroot on raring, sure. | 20:03 |
| infinity | debootstrap --variant=buildd --arch=armel sid chroot-sid | 20:03 |
| djvj | infinity: I'm just getting my feet wet on ARM related stuff, so I can't really defend one vs the other at this point.. | 20:03 |
| infinity | djvj: There is no one versus the other. All modern ARM distros are armhf, period. Some people sort of support armel on older hardware (Debian and Fedora), but it's not anyone's focus. | 20:04 |
| infinity | djvj: And with the exception of Debian, no one supports full multiarch between ABIs. | 20:04 |
| infinity | djvj: So, if your stuff depends on anything outside the base toolchain, it's just plain not going to work. | 20:04 |
| infinity | djvj: So, yes, the only sane way forward is to make your stuff work on armhf, IMO. | 20:05 |
| mjrosenb | I remember coming in here a while ago, and hearing that the hardfp compiler with --mfloat-abi=softfp was *not* equivalent to using an armel compiler through and through. | 20:05 |
| infinity | mjrosenb: The only difference is the default CPU target (which you can also set). | 20:06 |
| infinity | mjrosenb: Whoever told you it was otherwise different was mistaken. | 20:06 |
| infinity | mjrosenb: But see above. If you depend on other libraries, such attempts will fail anyway, since we only give you a base toolchain with the armel ABI. | 20:06 |
| mjrosenb | *nod* | 20:07 |
| infinity | Still, same recommendation as I gave djvj, moving to armhf wholesale is the sane way forward, rather then entrenching workarounds. | 20:08 |
| infinity | We're the only distro that provides multilib toolchains that actually work, Debian is the only distro that provides armel/armhf multiarch, everyone else has moved to armhf entirely, except for Fedora's old armv5/armel port not quite being dead yet. | 20:08 |
| infinity | Targetting the old ABI just isn't worth it in the long run. | 20:09 |
| infinity | Besides, if I decide to break or drop the multilib toolchain in the future, I'd rather not have people whining about it because they expected it to work forever. :P | 20:10 |
| infinity | I do look forward to a day (soon, I hope) where I can just drop all soft-float support, must as we did for OABI. | 20:11 |
| infinity | s/must/much/ | 20:11 |
| mjrosenb | infinity: so we have no issues supporting hardfp | 20:11 |
| infinity | I also look forward to a day where I can drop i386. | 20:11 |
| infinity | Not sure when either of these days may actually come. :P | 20:11 |
| mjrosenb | infinity: the problem is that we're using this to test our jit for android | 20:11 |
| mjrosenb | and android only supports softfp these days | 20:11 |
| mjrosenb | so for testing purposes, we need to be able to run softfp code. | 20:12 |
| infinity | mjrosenb: That's untrue, there are hard-float Android builds. But yes, by default, you're right. And I'd recommend just using a Debian chroot if you're looking for a soft/softfp environment. | 20:12 |
| mjrosenb | infinity: if you can convince android to switch to hardfp, I won't even look back. | 20:12 |
| infinity | Or use Android itself. :P | 20:13 |
| infinity | I saw some interesting bits in HK last week about Linaro folks making Android self-hosting. | 20:13 |
| mjrosenb | infinity: the problem i've always had is running gdb on android | 20:15 |
| mjrosenb | and our test harness that is written in python. | 20:15 |
| infinity | Ahh, yeah, those may still be issues. I've not played with their attempts to make Android pretend to be a real build system to see how far it is. | 20:16 |
| infinity | Anyhow, Debian or Fedora chroots are likely a reasonable compromise. | 20:17 |
| infinity | Or quantal/armel. | 20:17 |
| infinity | Which was our last armel release. | 20:17 |
| mjrosenb | infinity: evidently fedora doesn't do the whole cross compiling thing? | 20:17 |
| mjrosenb | and they build all of their arm packages on arm machines. | 20:17 |
| infinity | They do everything natively, yes. | 20:17 |
| infinity | Then again, so do we. | 20:18 |
| infinity | We just ALSO provide cross toolchains. | 20:18 |
| infinity | But this isn't about cross anyway, is it? | 20:18 |
| mjrosenb | infinity: djvj is trying to do it natively, I've been using cross (from amd64) for several years now. | 20:18 |
| infinity | Ahh. ;) | 20:19 |
| infinity | Well, same arguments. We ship a cross that works for biarch/multilib just fine, but if you need access to multiarch libs to link against, you're SOL past quantal. | 20:19 |
| infinity | Not much I can do about that. I fought to save armel, I was one of the few. We just didn't have a compelling enough argument to keep it. | 20:20 |
| infinity | Then again, precise should be a good enough base for people to keep doing stuff against for another four years, and we can hope armel is dead by then. | 20:21 |
| mjrosenb | sadly, our new arm dev machines are chromebooks, which you *really* want to be running raring on. | 20:22 |
| infinity | Sure, but not chroots. | 20:23 |
| infinity | It's just the kernel and alsa and such that you want raring for. | 20:23 |
| djvj | yeah chroots should serve fine, up until such a point where libs get too old for the kernel, which hopefully shouldn't be for a while | 20:24 |
| infinity | djvj: Or ever... | 20:25 |
| infinity | djvj: About the only kernel/userspace mismatches that ever matter are with udev (which shouldn't be running in chroots) and glibc (which occasionally bumps required kernel version, but the kernel doesn't break glibc by revving) | 20:26 |
| infinity | djvj: So you should be fine with, say, precise/armel chroots on your raring (and beyond) systems. | 20:26 |
| djvj | infinity: good to know. thanks for the help btw. I just built with hardfp and can replicate the issue I'm trying to track down. | 20:29 |
| mjrosenb | infinity: the kernel occasionally breaks glibc by revving | 20:34 |
| mjrosenb | infinity: but it has happened like twice | 20:34 |
| === chihchun is now known as zz_chihchun | ||
| === zz_chihchun is now known as chihchun | ||
| lilstevie | mjrosenb, infinity fedora most certainly does have some cross-compiler bits | 22:35 |
| lilstevie | $ arm-linux-gnu-gcc --version | 22:36 |
| lilstevie | arm-linux-gnu-gcc (GCC) 4.7.1 20120606 (Red Hat 4.7.1-0.1.20120606) | 22:36 |
| === XorA is now known as XorA|gone | ||
| sbaugh_ | Is Bluetooth working now on the Nexus 7 image? I am seeing conflicting reports. Does it perhaps require a workaround? | 23:19 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!