[00:20:04] --- haba has left [00:24:41] --- kaj has become available [01:03:29] --- abo has left [01:03:32] --- abo has become available [01:11:24] --- haba has become available [03:49:54] --- jaltman has left: Replaced by new connection [03:49:55] --- jaltman has become available [04:22:38] --- Simon Wilkinson has become available [04:25:04] --- mdionne has become available [04:25:56] --- haba has left [04:26:28] --- haba has become available [05:05:15] --- Simon Wilkinson has left [05:15:45] --- mdionne has left [05:23:35] --- meffie has become available [05:55:49] --- reuteras has left [06:17:48] --- Kevin Sumner has become available [06:54:12] --- Simon Wilkinson has become available [06:55:27] --- deason has become available [07:51:22] --- Simon Wilkinson has left [07:55:01] --- jaltman has left: Replaced by new connection [07:55:02] --- jaltman has become available [08:19:09] --- Simon Wilkinson has become available [08:19:44] --- Simon Wilkinson has left [08:25:16] I thought posix says open() should return EROFS for O_RDWR... but I'm a little confused by other calls like ftruncate apparently also allowing EROFS [08:26:12] I would've thought that wouldn't be possible, since you get EBADF/EINVAL if you try to ftruncate on O_RDONLY, and if you open O_RDWR you should've got EROFS earlier, for the open() [08:28:00] er. oh, i see. i missed jeff's question. [08:29:16] sorry, throw in a "jaltman: " prefixing what I said [08:29:18] > I thought posix says open() should return EROFS for O_RDWR it does. the question is "is a readonly volume a readonly filesystem". or, i guess, "would it always be proper to treat it as one" [08:30:38] like, we don't in afs_open treat writing as requiring an RW vol. if we do, who does it break? anyone? it's a behavior change [08:30:54] no, i just missed the context, is all [08:35:21] actually, at least in the sqlite case that brought this up, we do return EROFS on the open [08:36:02] and it opens it O_RDONLY afterward... my point was just that O_RDONLY and F_WRLCK is always supposed to fail, so it seems like we could do the check earlier/faster [08:36:35] (in the same sense that "O_RDONLY and write() is always supposed to fail") [08:39:46] well, O_RDONLY and F_WRLCK should get a local fix. but that fix is still required: as lon as we the readonlyServer code in the server, things may look writable but return EROFS. [08:40:00] like, the fix that's there is the simplest fix that covers all cases. [08:42:36] oh yes, sure [08:56:05] --- haba has left [09:00:36] --- abo has left [09:00:37] --- abo has become available [09:03:17] --- kaj has left [09:07:53] --- kaj has become available [09:24:55] --- Simon Wilkinson has become available [09:36:31] --- kaj has left [10:03:24] --- Simon Wilkinson has left [10:12:17] --- Russ has become available [10:19:10] --- Russ has left: Replaced by new connection [10:19:10] --- Russ has become available [10:49:59] --- kaj has become available [12:18:25] 1.5.74.1 doesn't build on Debian alpha. [12:19:15] make[4]: Entering directory `/build/buildd-openafs_1.5.74.1-1-alpha-y0Z7gr/openafs-1.5.74.1/src/des' gcc -fPIC -g -O -I/build/buildd-openafs_1.5.74.1-1-alpha-y0Z7gr/openafs-1.5.74.1/src/config -I/build/buildd-openafs_1.5.74.1-1-alpha-y0Z7gr/openafs-1.5.74.1/include -I. -I. -D_LARGEFILE64_SOURCE -c make_s_table.c In file included from make_s_table.c:14: des.h:20: error: expected specifier-qualifier-list before 'afs_uint32' In file included from conf.h:20, from des_internal.h:14, from make_s_table.c:15: [12:20:24] try origin/master? [12:21:26] I wonder if 1912 would help with that, though it doesn't appear to have touched those specific files... [12:21:41] --- abo has left [12:22:20] --- abo has become available [12:22:26] the analogous fix would help, since that's the problem. i just wonder how we broke it and didn't notice elsewhere [12:22:46] Ah, yeah, I bet this is the thing Simon just fixed. [12:22:54] * Russ just arrived at that same conclusion. [12:23:44] Hm, make_s_table already includes afsconfig.h first thing. [12:23:50] i'm not sure he fixed it. make_s_table won't include the needed thing? [12:24:44] make_s_table.c is already including afsconfig.h and then afs/param.h. [12:24:55] Somehow, that's not defining afs_uint32 on alpha. [12:25:03] And only alpha; it built fine on, say, amd64 and ia64. [12:26:11] stds.h unconditionally defines afs_uint32... [12:26:53] header guard collision? [12:27:28] I think afs/param.h must not be including stds.h somehow. [12:27:37] The way we include stds.h is really inobvious and should be fixed. [12:27:45] It's included as a side effect of grabbing afs_sysnames.h. [12:28:22] Aha. [12:28:31] *_linux22) AFS_PARAM_COMMON=param.linux22.h ;; *_linux24) AFS_PARAM_COMMON=param.linux24.h ;; *_linux26) AFS_PARAM_COMMON=param.linux26.h ;; [12:28:35] That doesn't work on Alpha. [12:28:48] oh, the stupid extra _ [12:28:49] @sys on Alpha is alpha_linux_26 for hysterical raisins. [12:29:02] Patch coming in a moment. [12:29:06] when you see phil moore, mock him [12:29:41] phil and peter thought it was a good idea. phil eventually apologized, to be fair [12:32:55] http://gerrit.openafs.org/#change,1915 [13:07:02] --- jaltman has left: Disconnected [13:29:17] --- mdionne has become available [14:23:47] --- Simon Wilkinson has become available [14:24:16] deason: Fixing the remainint use of AC_CHECK_TYPE was actually pretty easy :) [14:25:14] (see 1919) [14:26:45] well that's good [14:27:16] Does mean we can't regen on RHEL5 or earlier, but that's the world we're already living in. [14:27:44] (actually, the usage in intptr.m4 wasn't that bad - it's the two argument use that is really not recommended) [14:33:00] > but that's the world we're already living in. I've been thinking, perhaps not necessarily, though... we kinda added that requirement without realizing it; how terrible would adding our AC_U_S_E replacement be? [14:33:48] er, that reads kinda weird; "I've been wondering if we perhaps don't need to be living in such a world" [14:34:15] --- kula has left [14:34:20] Kind of, maybe, possibly, it could be the case that your feelings there might actually have some kernel of truth in them. [14:35:27] At the end of the day, the autoconf requirement only really impacts upon developers (and whatever the system Derrick makes the release tarballs on is) [14:35:43] I know, but it's still annoying for certain automations [14:36:09] Yes, but where do you draw the line? [14:36:14] I don't know if that annoyance is greater or less than not making 2.60 a requirement, hence the question [14:36:25] We really should test on RHEL4 - should we restrict ourselves to the autoconf available there? [14:36:36] (or even on RHEL3, which we notionally still support) [14:37:28] Autoconf 2.60 isn't exactly cutting edge - it was released nearly 4 years ago. [14:37:58] yeah, but people don't seem to upgrade autoconf very much apparently... [14:38:35] my point is, I know it's a small annoyance now, but is reimplementing AC_U_S_E also a very small annoyance? I don't know at all the logic/intricacies of it [14:38:57] that's the only thing we've seen break; RHEL4 for instance has been fine, I'm pretty sure [14:39:05] (pre U_S_E) [14:39:46] Well, the intptr stuff that I"m proposing removing went in because someone used the autoconf intptr tests without realising they weren't present in older autoconfs. [14:40:01] if all it does is -D a few symbols, requiring 2.60 seems a bit silly to me; but if it does some platorm detection etc for the proper symbols, then maybe not [14:42:34] It does some platform tests, and then some compilation checks. It's more complex than just #define. [14:47:55] then okay, I guess I'm fine with it, though it still bothers me that... > At the end of the day, the autoconf requirement only really impacts upon developers it may only affect devs, but we didn't really ask or tell them [14:48:06] (and I recognize that's my fault) [14:50:50] If it's something you're worried about, then maybe something should get sent to openafs-devel list pointing out the change before we go further down this route? [14:52:11] yeah [14:52:16] --- dwbotsch has left [14:53:23] --- dwbotsch has become available [15:02:06] --- Simon Wilkinson has left [15:23:01] * Russ wholeheartedly agrees with not being held back by the ancient Autoconf on RHEL 4. [15:23:18] If I had my way, I wouldn't even try to remain compatible with RHEL 5. RHEL releases way to slowly to be useful as a development platform. But that's just me. [15:23:35] too [15:24:58] --- steven.jenkins has left [15:25:55] --- steven.jenkins has become available [15:35:06] --- haba has become available [15:40:54] --- steven.jenkins has left [15:41:13] --- steven.jenkins has become available [15:43:37] --- phalenor has left [15:44:07] --- phalenor has become available [16:00:48] --- dwbotsch has left [16:01:34] --- dwbotsch has become available [16:11:32] --- deason has left [16:16:15] --- phalenor has left [16:17:12] --- phalenor has become available [16:17:52] --- mdionne has left [16:18:18] --- mdionne has become available [16:20:55] --- dwbotsch has left [16:21:51] --- dwbotsch has become available [16:30:19] --- haba has left [16:30:59] --- haba has become available [16:44:03] --- deason has become available [17:09:26] --- haba has left [17:12:57] --- kula has become available [17:35:10] --- meffie has left [17:46:47] --- jaltman has become available [17:58:00] --- mdionne has left [18:38:16] --- shadow@gmail.com/owlB71D23BD has left [19:21:11] --- shadow@gmail.com/owl50619EF6 has become available [19:41:22] > If I had my way, I wouldn't even try to remain compatible with RHEL 5. insert my well-known snarkiness about what debian stable means [19:45:01] "changing faster than RHEL" apparently. :) [19:45:17] changing != works [19:45:41] i don't get many 1.4.7 bug reports from rhel [19:46:01] Well, yes, because RHEL doesn't ship OpenAFS at all. [19:46:10] You don't get many bug reports from OpenBSD either. [19:46:44] i don't get any. the client basically doesn't work, unlike redhat [19:46:55] Yeah, that's basically my point. [19:47:06] You won't get any bug reports for something that's non-existent. [19:47:25] On Debian, there are two client distributions; on RHEL, because they don't include OpenAFS, there's only one. [19:47:29] the rpms work. [19:47:38] that's fair [19:47:47] On Debian you therefore get bug reports from both of them; on RHEL, you only get bug reports for the one. [19:47:53] i'd rather have one that works then two where the default one doesn't [19:48:13] Hm, I'm also seeing unhappiness from git.openafs.org: [kaduk@hysteresis /usr/devel/openafs/git/openafs]$ git fetch origin/master fatal: 'origin/master' does not appear to be a git repository fatal: The remote end hung up unexpectedly [19:48:26] i bet it's out of memory again [19:48:26] We could probably partly solve this by more aggressively advertising the backports.org versions. [19:48:43] Soon, that will be officially part of Debian, which will make that somewhat easier. [19:48:51] is it worth putting something on the release pages? [19:49:01] (and if so, what?) [19:49:10] What would be out of memory on git.openafs.org? [19:49:47] there's a resource limit on the jvm, i think? simon explained once. [19:50:00] That would be gerrit.openafs.org, no? [19:50:09] good point. [19:50:09] No errors in syslog from git-daemon. [19:50:17] --- Kevin Sumner has left [19:50:18] "I thought they were the same thing" [19:50:27] --- deason has left [19:50:30] actually. wait. why do you need an argument to git fetch? [19:50:50] Yeah, we should put on the release page something like "Current versions of the OpenAFS packages are available from backports.org, add blah blah blah to /etc/apt/preferences and blah to /etc/apt/sources.list to use those instead." [19:51:09] --- Kevin Sumner has become available [19:51:16] it's working for me. git clone git://git.openafs.org/openafs (in the past); cd openafs; git fetch [19:51:18] --- deason has become available [19:51:21] ==shadow; you mean ‘git fetch’ or ‘git fetch origin’. [19:51:31] I can come up with the blah blah bits. [19:51:39] don't lie to git and git won't lie to you [19:52:07] can we give people something which is a package or something which adds the source and the preferences? [19:52:17] --- abo has left [19:52:22] --- abo has become available [19:53:05] Not quite. There’s an /etc/apt/sources.list.d and /etc/apt/preferences.d, but (1) aptitude doesn’t support preferences.d yet for some reason and (2) preferences can only be set on an entire repository, not per-package. [19:53:17] ah, ok. drat [19:54:54] Preferences can be set per-package. [19:55:12] Huh, I didn't know aptitude didn't support /etc/apt/preferences.d. [19:55:26] I think we were the ones who asked for both that and sources.list.d originally. (Well, probably one of the ones.) [19:55:42] > Preferences can be set per-package. Yeah but they don’t work right. [19:55:51] How do they not work right? I use them all the time. [19:57:14] See http://www.xs4all.nl/~carlo17/howto/debian.html#errata “The Pin-Priority: has a different meaning when used…” [19:58:29] And http://bugs.debian.org/557580 for aptitude and /etc/apt/preferences.d. [19:58:44] My confidence in that page is somewhat injured by the fact that the very first bullet point is wrong. [19:59:38] *shrug* All I know for sure is that I couldn’t get it to work right, and I’ve heard complaints from lots of other people who couldn’t get it to work right, and this seemed like a plausable explanation.` [20:00:04] The section on Pin-Priority matches my understanding of how it works as well. [20:00:09] I'm not sure how this is broken. [20:00:26] It lets you do pretty much what we want for OpenAFS, at least, namely prefer the version from backports.org. [20:00:42] Unfortunately, you do need pin stanzas for each individual package, since wildcards aren't supported. [20:01:50] * Russ reads on. [20:02:09] Hm, no, actually, the behavior that he describes just isn't at all what actually happens, at least in Debian for the past two stable releases and currently in squeeze. [20:02:27] Although I haven't tried with priorities as high as he's using, which may be the difference. [20:02:35] 1100 is a pretty aggressively large priority. [20:03:38] shadow: Whereabouts would I put this documentation most usefully? The structure of the release pages doesn't seem to lend itself to an obvious spot. [20:04:07] yeah, that's the problem. (a script makes it. look at /afs/andrew/usr/shadow/make_www_release) [20:07:53] You also can use pins to prefer testing over unstable; you just have to do it the opposite way that he's doing it, and, unlike what he's saying there, that isn't actually the problem that he's trying to solve. He's trying to prefer a locally-installed package over unstable, which is a different problem. [20:09:18] Hm, I wonder if I should make a separate web page with all of the details and then have the script just add a link to it. [20:09:24] Alright, if this has become more possible since last time I tried it (which was admittedly a while ago and on Ubuntu), that makes me happy. [20:09:35] I'm pretty sure it has. [20:09:46] I definitely agree with him that the documentation sucks and that expressing things is very counterintuitive. [20:10:05] FWIW, I'm also getting the build error that Jan was reporting on freebsd-afs (patch may be forthcoming) [20:10:51] "the" build error? [20:11:25] The most recent one? (I think, I may not have actually looked very carefully.) [20:13:16] --- abo has left [20:13:53] well, the most recent one, locktype, someone sent a fix which was pushed. and it wasn't me despite the fact that i fixed it in my tree before pushing the bug :\ [20:34:04] Hm, sorry for the extra mail about the FBSD 8.1 and 9.0 entries. [20:34:59] http://gerrit.openafs.org/1924 has the base instructions. [20:38:13] --- dwbotsch has left [20:40:04] --- dwbotsch has become available [20:42:36] so "the error didn't change" except it did. good enough, pushed. [20:48:57] --- mho has left [20:48:57] --- kaj has left [20:57:06] Hm. /usr/ports/net/openafs-devel/work/openafs/src/afs/VNOPS/afs_vnop_flock.c:522: warning: implicit declaration of function 'osi_procname' [20:59:51] should be in osi_machdep.h [21:00:31] if nothing else, it can be #define osi_procname(procname, size) strncpy(procname, "", size); [21:00:55] but ideally it would be something like #define osi_procname(procname, size) strncpy(procname, curproc->p_comm, size) [21:15:39] --- kaj has become available [21:47:30] --- deason has left [21:53:43] I tried forcing my kernel to only use one CPU/core (with #1925, of course), and the client seems stable under my light testing. (I.e. I can both read and write files without things hanging.) [21:54:47] I wonder if it's worth packaging 1.5.74 with the caveat that it only is expected to work for the single-processor case. [21:55:48] While the client was running, though, I did get lots of spew on the console like this: May 7 00:31:52 hysteresis kernel: _end() at 0xffffff8000b77c00 May 7 00:31:52 hysteresis kernel: _end() at 0xffffff8000b77500 May 7 00:31:52 hysteresis kernel: _end() at 0xffffff8000b76e00 May 7 00:31:52 hysteresis kernel: rx_freePacketQueue() at rx_freePacketQueue May 7 00:31:52 hysteresis kernel: _end() at 0xffffff8000b6d400 May 7 00:31:52 hysteresis kernel: _end() at 0xffffff8000b73d00 May 7 00:31:52 hysteresis kernel: _end() at 0xffffff8000b6e200 May 7 00:31:52 hysteresis kernel: _end() at 0xffffff8000b70500 May 7 00:31:52 hysteresis kernel: _end() at 0xffffff8000b6fe00 (almost entirely _end()s) [22:11:06] --- reuteras has become available [23:31:50] --- kaj has left [23:56:16] --- Russ has left: Disconnected