[03:46] ogra_: Do you have a non-ES Panda that I could get you to install a natty kernel on for me to experiment with? [03:47] janimo: Or you? [03:47] GrueMaster: Or you, if you still have a bunch of hardware collecting dust. [03:52] infinity: I have one [03:54] stgraber: \o/ [03:54] stgraber: Could you install a fresh natty headless on it and give me root? [03:54] stgraber: And maybe attach a USB disk, so I don't go insane? [03:56] stgraber: One way or another, I'm going to fix this &^#$% mono/armel thing. But, after my last round of fixes, I can no longer break it on my PandaES. :/ [03:56] stgraber: (So, I'm blaming the natty kernel, until I can prove otherwise) [03:56] infinity: installing natty should be easy, finding a usb disk will be trickier ;) [04:00] the only usb storage I have around is my n900, not sure it's going to be a lot faster than the sdcard :) [04:01] stgraber: If the SD is big enough to build mono on, that'll work, I suppose. [04:02] stgraber: Unless you have an NFS server you could cut me a slice of. [04:02] sure, nfs is easy [04:02] Anything's better than SD. ;) [04:03] Some sort of tiny-magnets-over-IP would do. [04:04] * infinity knew he shouldn't have given Andy his old Panda. [04:04] /dev/mapper/external-adam 3.7T 56G 3.5T 2% /data/external/adam [04:04] ^ should be enough for mono [04:05] I should hope so. [04:05] infinity: got IPv6 over there? [04:05] No, I live in the past. [04:05] I should fix that. [04:05] But not this evening. [04:05] ok, I'll have to do some old school natting then... [04:06] Well, I could install that ghetto tunelling thingee. [04:06] Whatever it's called... [04:06] Right, miredo. [04:06] I can do that. [04:09] ... waiting on sdcard ... [04:09] Welcome to the life of an ARM porter. [04:09] It's amazing how well you learn to multitask when you're always waiting on slow hardware. [04:10] now that we have PXE in uboot I should really just make a kernel + initrd that lets me boot from nbd :) [04:10] That would work. Not sure if natty would do that, though. [04:10] precise should. [04:10] (But I need natty today, so that doesn't help) [04:12] booting [04:21] infinity: getting nfs on the board and it'll be good to go [04:21] stgraber: \o/ [04:30] infinity: ssh ubuntu@sateda.stgraber.org -p 9922 [04:30] infinity: you should have password less sudo working on it [04:31] infinity: and the nfs in /data [04:31] infinity: I didn't apply any update but I reboot tested the current install, so if you need you should be able to upgrade, reboot and get ssh working again :) [04:32] stgraber: I'll be working in quantal chroots anyway, don't care if the base system is up-to-date, except for kernels. [04:32] Though, yeah, updating the kernel to a newer natty one might happen. :) [04:33] Dear NFS, 4294967294 might not be a valid UID, please to be checking your integer operations. [04:34] oh, fun... [04:37] infinity: looks like I was missing nfsvers=3 [04:37] stgraber: Oh, should I stop what I'm doing and let you remount? [04:37] infinity: yeah, I think it's best [04:38] Go nuts. [04:38] infinity: fixed, uids look good now [04:38] And now it's sticky! Yay, giant tmp. [04:38] (Not that I care) [04:39] infinity: is it? it's 777 but I don't see the sticky bit here [04:39] Oh, that's just ls --color confusing me. [04:40] The coloring for 777 and sticky are awfully similar. [04:40] (But not identical, when I look closer) [04:44] stgraber: Do you have a local mirror of ports? ports.u.c seems a bit slow from your network. [04:44] (I'll quit whining and just wait longer) [04:45] infinity: nope, not enough ARM hardware around to justify it... though that means it's getting into squid now, so will be fast next time I want to get a quantal armel chroot ;) [04:46] Heh. [04:47] * infinity notes that almost every computer in his house except two relies on ports. [04:48] * infinity notes that it's also a bit nerdy to say "every computer except two", as if everyone has more than two... [04:49] infinity: as for speed, for some reason Canonical's network is badly routed tonight... let me see if I can fix that quickly [04:49] stgraber: It's always badly-routed for me. I bounce through a GRE tunnel in San Jose to "fix" it. [04:49] stgraber: Which is just hilariously silly. [04:50] yeah, I'm trying to "fix" it by getting it over IPSEC to my server in Germany [04:51] much better! let me quickly apply that to ports now :) [04:52] Your bad routing looks less crap than my bad routing. [04:52] You at least get what looks like a clear path through L3. [04:52] I end up deep in some reeeeeealy old as6809.net links in the Netherlands. [04:55] I guess teksavvy has some load issue with some of their IPv4 peers... The new "route" goes over IPv6 to Germany, then back over IPv4, that should workaround that problem. [04:58] hmm... looks like IS hasn't investigated that routing weirdness I've had for 2 weeks now in Germany... [04:58] basically, half of the Canonical subnet gets routed from Germany to the US (Boston IP) then back to London, increasing the latency quite a bit [04:59] That's pretty fun... [04:59] Also, I think you broke my routing mid-debootstrap. [04:59] I just realised it's been downloading util-linux for the last few minutes. [05:00] Oh well, squid should make a retry fast. [05:00] Oh! [05:00] Or you broke MY routing to YOU. [05:00] Oh, no. [05:01] It was the former. [05:02] yeah, I guess wget doesn't like the route changing in the middle of a download [05:02] No, there's actually a bug open about that. [05:02] wget seems to fail miserably at timing out. [05:03] infinity: routes from Germany => http://paste.ubuntu.com/1056968/ (at least it's "only" adding 80ms when going through the US) [05:04] Haha. Oops. [05:05] I suspect that falls firmly in the "BGP is haaaard" bucket. [05:06] well, I'm not sure how Canonical's BGP is setup, but Boston should only announce the local subnet with a weight of 0 and bump the weight of the London subnets quite a bit to avoid that kind of weirdness [05:07] Ideally, yes. [05:07] But, for all the people who know how BGP works, it's remarkably rare to meet people who know how to implement it correctly. [05:08] I consider it a minor miracle that the Internet mostly functions, most days. [05:08] After having working for some T1 carriers. [05:09] hehe :) [05:09] Maybe things have improved since I worked for PSInet in the late 90s, but man, it was a hilarious mess back then. [05:09] And the revelation that routing is pretty much a massive exercise in trust was frightening. [05:10] well, I know most AS still allow all prefixes from their peers which leads to "interesting" things happening from time to time [05:10] Which has led to fun foibles, like when Shaw advertised too broadly, and half of the traffic for the west coast of the US and Canada all jammed through one router in Vancouver. [05:10] Turns out that was unpleasant. [05:11] at least people must have noticed pretty quickly :) [05:12] Oh, we noticed in a hurry. [05:12] it's really easy to mess up a whole network that relys on bgp [05:12] As did MCI/UU, and a few others. [05:12] The guy I talked to at Shaw's NOC said the phones lit up about 30 seconds after he answered my call. [05:14] This is what happens, I suppose, when you let cable companies play on the Internets. [05:15] It still shocks me how quickly Shaw went from "TV operator" to "operating one of the most reliable backbones in North America". [05:15] But they still mess up peering on a regular basis. Cause they're just that awesome. [05:17] :) [05:17] infinity: and other isp's still peer with them? [05:17] gildean: They're all idiots these days, from what I can tell. [05:17] gildean: They've become much more forgiving. :P [05:18] and i guess if they own enough actual cable, there's little choice [05:18] The halcyon days of UUnet (err, MCI, err, Worldcomm, err, whoever they are now), PSInet, and Sprint owning 99% of the North American traffic and ruling with an iron fist are LOOOONG over. [05:19] Honestly, if people are still willing to peer with Cogent, that's kinda proof that they'll peer with anyone who has customers. [05:20] ... he says from a server sitting on a Cogent link (it's hard to argue with cheap). [05:22] and these days it's quite easy to work around isp's routing problems, just open up a ipv6-tunnel [05:22] as long as you got a point of precense somewhere near, it shouldn't rise the latency more than a couple of ms [05:23] and the route to the pop actually works (and doesn't get bounced around) [05:24] s/and/if [05:31] yeah, I quite like he.net for that ;) they have a pretty good network and a lot of points of presence so that's usually low latency too [05:31] though nowadays I've got native IPv6 pretty much everywhere (most of them still using HE.net for transit though) [06:05] stgraber: no native ipv6 from my isp [06:05] sucks balls [06:06] i use a sixxs tunnel, they had a pop righ near to me [06:06] ping to pop is about 13ms === gmpff_ is now known as gmpff === gmpff_ is now known as gmpff [11:59] <_raven> hi [12:00] <_raven> do you have some experience with linux on Raspberry PI? [12:08] _raven: topic === Guest70898 is now known as Termana [12:26] is there a armhf deb floating around yet for nvidia-tegra drivers? [14:59] infinity: Still need a panda? [18:15] GrueMaster: Nope, stgraber hooked me up. === calculu5 is now known as calculus