[00:05:52] --- dev-zero@jabber.org has left [01:02:29] --- dev-zero@jabber.org has become available [02:10:33] Hopefully Apple will solve the strain relief problems with the Magsafe connectors and bricks. I've had two blow up on me now... [02:59:03] --- reuteras has left [05:56:02] yeah, i've considered doing my own strain relief. it kinda sucks [06:04:18] you've had two blow up on you? [06:04:33] I hat no idea this was even a problem [06:05:09] google magsafe melting, or somesuch. you will find pictures [06:07:57] They're not fun. If you're lucky, it doesn't take out the side of your Macbook, too. [06:53:43] --- dmontuori has become available [07:08:47] --- tkeiser@sinenomine.net/owl has become available [07:48:22] --- matt has become available [08:42:49] --- SecureEndpoints has left: Replaced by new connection [08:44:11] --- SecureEndpoints has become available [09:40:52] --- dev-zero@jabber.org has left [10:14:02] --- Simon Wilkinson has left [10:22:49] --- Moose has become available [10:23:06] anyone alive? [10:32:11] dead? [10:32:49] Apparently not. I hope their power supplies didn't melt and blow them all up ;-> (reference to this morning's conversation in the chat) [10:34:22] with an earth shattering KABOOM?!? [10:37:04] Look, if Apple's laptop power supplies include Illudium Q-36 Explosive Space Modulators, they really ought to disclose that to the public. Although it would explain the behavior of said power supplies. [10:41:13] I am, I think. [10:41:41] Alive or dead, Matt? [10:42:11] Alive, I would have said. [10:43:33] that's good [10:44:03] I think I'm alive too, but parts of my lower back apparently disagree. [10:44:09] ug [11:16:13] derrick: from earlier, magsafe melting: dear god [11:16:18] moose, I'm alive [11:20:25] alive, dead, whatever [11:36:18] so today's crazy question is -- can you salvage a partition full of shadows, or do we need to hack the salvager? :) [11:36:59] that...never came up over there before? [11:37:17] Well, gee, that depends on what you think shadows are. IIRC, last time we tried to tell you how it worked, it turned out you had some local wrapper thing that did something different. [11:37:58] That said, 'vos shadow' just copies a volume. The copy is a perfectly ordinary volume as far as the server is concerned; it just doesn't show up in the VLDB. So yes, you can salvage it like anything else. [11:38:29] if you do vos listvo on a partition of shadows here, you get nothing [11:38:40] we hacked vos so you have to say "vos listvo -forceshadows" to see 'em [11:38:52] so if you can't l istvo the partition how can the salvager find the volumes [11:39:33] so, does salvager see what listvol prints, or not? [11:41:34] i dunno [11:42:47] I don't either,but I think the umich shadow stuff sounds useful--don't jump on me, jhutz... [11:43:07] it's pretty nifty [11:43:34] in t heory if we blow a machine up we can get things online as fast as "vos syncvldb -forceshadows" can run on ~15k volumes [11:43:43] A defined behavior for salvag(er|server) would seem to be required [11:49:15] In other news, do I remember that there's some current nits with RHEL & 1.4.latest, or am I smokin da crack again? [11:50:03] moose: do you know how the shadow volumes being filtered out of the "vos listvo" output? do you have access to the patches? [11:52:06] The patches are all in the head, iirc [11:52:21] they've at least been accepted, or so dan claimz [11:54:50] that is a nice thought but there is no -forceshadow command on the vos listvol in the cvs head [11:57:34] I think the umich shadow stuff sounds umich-specific, and that we can't offer useful information about how it works. And I wish they hadn't used the word "shadow"; "vos shadow" was intended to be a building block for creating that sort of thing, but calling something you built on top of it "shadows" is just confusing. [11:59:23] --- Russ has become available [11:59:40] graarrr [12:00:17] lemme see if i can find patches [12:03:14] Also, the idea of 'vos listvol' not reporting exactly what is actually on the server is alarming to me. Note that even being able to do that means there is something strange umich does to create their "shadows", because a volume created by 'vos shadow' is indistinguishable from the original [12:04:31] ok, it looks like my coworker has an interesting definition of "accepted" [12:04:35] http://rt.central.org/rt/Ticket/Display.html?id=64267 [12:05:06] yeah, he added something to the volume to flag it as a shadow. it becomes live by removing said flag. or so i've been told. [12:05:41] really i gotta learn to stop listening to him when he says anything about outside of umich [12:05:47] [12:09:45] Right, so he made protocol and on-disk-format changes without talking to anyone. And who knows what else. [12:10:10] What I heard, is he made as few changes as possible to effect a result. And sent to lists. [12:10:32] he did, iirc, email the dev list a few times at least [12:10:37] That I recall reading myself. [12:10:49] i'm not sure why you're getting all bent outta shape, jeff [12:10:57] it's not like he rewrote your code completely :-P [12:15:40] moose: the problem is that when a wire protocol change is made it results in the potential of incompatibilities between implementations. at some point folks on the afs3-stds list may want to alter those protocol messages and the changes they come up with might bite umich hard in the ass. [12:16:48] We'd probably rather work things out. [12:17:37] how would you know to work things out? the code is only known to umich and by the time umich notices there is a conflict we could already be in production. [12:17:54] I don't recall the discussion you're talking about, matt, but that doesn't mean it didn't happen. And I don't object to the feature. [12:18:40] I never remember any discussion of wire protocol changes in the shadows discussion on openafs-devel [12:18:42] It wasn't much of a discussion at the time IIRC, but Dan sent the files over to devel. [12:19:22] I _think_ it's more a behavioral change than anything on the wire, I'm probably missing something. Definitely stole a bit on disk. [12:19:59] SecureEndpoints> your point is taken, we've begun a discussion. [12:20:22] The thing for umich to have done that would have let them deploy the feature they wanted and yet avoid potential future interop problems would have been to define a new RPC rather than changing the semantics of an existing one. Getting a number would not have been hard (and really, we should set aside a range of private-use RPC numbers for each service) [12:21:45] MIT is what I've been using for all but the afsrdr/kernel and afsrdr/npdll code which is BSD [12:21:52] Heh. I bet if it was suggested that $coworker completely reimpliment this mess, $boss would HAVE A HEIFER [12:22:07] ugh, that was meant to be private. oh well [12:22:19] Apparently getting this to a production stage took forever [12:22:27] computers are hard :-P [12:22:35] I don't recall the actual patch for openafs to be large. [12:22:46] --- dmontuori has left [12:22:52] --- dmontuori has become available [12:23:03] It would be larger with new RPC, still doesn't sound like a large project. [12:23:13] there were multiple patches. some parts were accepted and others are in RT unaccepted [12:23:53] Stealing a bit on disk is poor, but probably wouldn't cause major interop problems; it would just require umich to rewrite the headers of the affected volumes before upgrading to code which uses that bit for something else. But they also steal the last free afs_int32 in struct volIntInfo, and to hold a 1-bit value at that, and two bits in the flags arguments to AFSVolSetFlags() [12:24:34] I'm only looking at the patch moose pointed to. What was submitted that was accepted? [12:25:25] i wonder if i can get simmons to get his ass on here [12:25:34] you can search RT for other patches from Dan. They were patches to related portions of code (if I remember correctly) which negatively impacted the feature changes [12:25:39] (he's not hte architecht of the mess but better understands) [12:38:25] the nsis installer needs to build its own msi for the runtime library for checked builds [12:42:46] o-tay [12:57:22] SecureEndpoints: were you speaking of conditional packaging of MSVCRT and friends in vcruntime.wxs? [12:57:58] yes [12:58:38] There is already conditional packaging for vs2008, actually. In fact, I borrowed it for the wix installer. [12:58:50] great. [12:59:12] I wonder if it works [12:59:20] I'm going to try it :) [13:00:00] (the wix variant in fact does work) [13:16:47] drat, it actually doesn't work--seems to install runtime in an incorrect location [13:54:38] --- dev-zero@jabber.org has become available [14:14:46] --- dev-zero@jabber.org has left: Replaced by new connection [14:14:47] --- dev-zero@jabber.org has become available [14:33:05] --- dmontuori has left [14:53:42] ok time to kill [14:53:45] --- Moose has left [14:55:51] time to kill what? [14:56:15] cow orkers or gatekeepers, i'd guess [14:59:24] SecureEndpoints: ok, the situation is that 1.5.55 installers, both NSIS and wix, are correct wrt vs2008, but my results are, with HEAD, neither NSIS nor wix installs the vc runtime correctly [14:59:59] so diff head and 1.5.x? [15:00:03] Indeed. [15:00:12] I think I know the issue, and fortunately, someone already solved it. [16:50:42] --- matt has left [17:19:15] --- matt has become available [17:20:23] --- matt has left [20:36:55] shadow versus shadows - do I wanna know? [20:54:05] --- summatusmentis has left [21:05:07] --- summatusmentis has become available [21:05:29] --- summatusmentis has left [21:05:34] --- summatusmentis has become available [21:11:02] i had nothing to do with it [21:13:51] derrick: have you looked at all at porting OpenAFS to android? [21:17:32] i have no android. it should be pretty simple tho, the n810 port is mostly "it" [21:20:10] well, the reason I ask is, afaik, there's no root access on newest versions, so I'm not sure about permissions [21:20:28] yeah, probably boned [21:21:09] there was a time when i would have said "put one in my hands and i care". now i care regardless but don't have the time even if one appears in my hand [21:26:20] I wish I knew more about reverse engineering stuff, then I could spend time on it [21:33:18] although, it's very possible one could get it working one of the unlocked dev phones [23:05:46] --- Russ has left: Disconnected