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