[00:00] any operation that matches '^apt-get remove.*libc' is probably a bad idea. [00:01] uh-oh [00:02] so installing libc6-armel-dbgsym failed because libc6:armel was already on the system [00:02] but now apt is kind of stuck because it won't uninstall libc6:armel since another operation is pending [00:03] mjrosenb: Oh, didn't realise you had libc6:armel installed. Whee. [00:04] mjrosenb: You should be able to just "dpkg -P libc6:armel" unless other things depend on it. [00:04] infinity: yeah, armel programs ran just fine, but I couldn't debug them without the debug symbols. [00:04] infinity: a few things do, I'll nuke them with apt after libc6-armel-dbgsym is installed [00:04] While I normally recommend multiarch as the way and the light, it doesn't make much sense for armhf/armel, since we dropped armel more recently. [00:05] infinity: I'm assuming this repo also has a libstdc++-armel-debugsym as well? [00:05] infinity: incredibly annoying is the fact that on arch linux, an armel binary will load just fine [00:06] and run great, unless you happen to be making library calls involving floats. [00:06] Well, I assume arch isn't armhg. [00:06] armhf* [00:06] infinity: it is only armhf. [00:06] Then I call bullshit on armel binaries running. [00:06] Unless they install a full multilib setup. [00:06] anyhow. dpkg failed because things depend on libc, I'm assuming I can just add those to the command line? [00:06] Which isn't "only armhf". [00:07] Or, you could not install libc6-armel, if you had things depending on libc6:armel [00:08] And instead install libc6-dbgsym:armel [00:08] * infinity shrugs. [00:09] wookey, is it hardware accelerated? [00:13] infinity: 'testing a new strain of superheroine' sounds entertaining [00:14] wookey: With or without the spelling error? [00:14] well, either I guess but with is more wholesome [00:14] That depends on the testing... [00:15] we'd better stop this before someone points out that our project is full of casual sexism and bans us :-/ [00:16] wookey: I blame you. I was all about the hard drugs before you came along. [00:17] I've been to the pub. I blame drugs too [00:17] And now I need to write my talk for paris debconf [00:18] In French? [00:26] no [00:52] libhfstdc++6-4.6-dbg-armel-cross [00:52] what. [02:38] infinity: is there a similar package for libstdc++, since I had to remove libstdc++ when I pulled out the old libc :-/ [02:39] mjrosenb: Erm, no. Like I said up there, if you have a bunch of stuff depending on that libc, maybe removing it isn't the sanest option., [02:39] mjrosenb: Though, really, why do you have so many armel binaries you care about? [02:40] I have one. [02:41] I'm debugging our javascript shell, and it is supposed to run on android, so in order to avoid the pain of debugging on android, I'm getting a linux enviroment as close as I can to android [02:41] which is armel. [02:41] Might I suggest an armel chroot would be much less painful? [02:41] And perhaps a distro that still supports armel, like Debian. [02:42] debootstrap --arch=armel --variant=buildd sid my-sid-armel-chroot [02:42] maybe I should just investigate installing debian fulltime on my boards :-/ [02:43] I installed ubuntu on here *shortly* before ubuntu made the switch to armhf. [02:44] https://wiki.debian.org/PandaBoard [02:44] hahah [02:44] Install instructions [02:44] missing [02:45] Yeah, you're better off running an Ubuntu base on a Pandaboard. [02:45] But chroots are how I do all my development, using the base system to muck around in is usually asking for trouble anyway. [02:45] So, a Debian armel chroot on an Ubuntu armhf base is perfectly reasonable. [02:46] yeah. I did this on a tegra already [02:46] but that machine is just a *royal* pain to work with. [02:47] if I can set up sshd to run inside the chroot, I *probably* don't care [02:47] although, I think the thing that I like the least about it is the set of things that randomly don't work in the chroot [02:47] iirc, oprofile works outside of the chroot, not inside of it. [02:48] * mjrosenb tries a chroot on the pandaboard [02:49] There shouldn't be much of anything that doesn't work in the chroot, unless you miss mounting some filesystems. [02:49] (you'll want devpts, dev, sysfs, and proc) [02:49] infinity: things that modprobe kernel modules are finnicky. [02:49] since the host and target don't share the same kernel usually. [02:49] mjrosenb: Not if you install the same kernel deb in the chroot. ;) [02:50] mjrosenb: Or bindmount /lib/modules/$version into the chroot. [02:50] yeah, I think one problem was it was a custom ubuntu from nvidia, and they had some packages that debian just did not know about. [02:52] The program 'debootstrap' is currently not installed. You can install it by typing: [02:52] :-o [02:52] I can't remember the last time I had to install debootstrap === chihchun_afk is now known as chihchun === doko_ is now known as doko === chihchun is now known as chihchun_afk === zz_anmar is now known as anmar === satellit_ is now known as satellit_e === anmar is now known as zz_anmar === zz_anmar is now known as anmar === anmar is now known as zz_anmar === zz_anmar is now known as anmar === anmar is now known as zz_anmar === zz_anmar is now known as anmar === anmar is now known as zz_anmar