[01:01:30] --- jaltman has left: Disconnected [01:06:22] --- Russ has left: Disconnected [04:31:16] --- haba has become available [06:54:36] --- deason has become available [07:10:13] --- reuteras has left [09:00:18] --- rra has become available [10:35:19] --- Simon Wilkinson has become available [10:37:50] Having just plugged rxgk and hcrypto into the tree, all I can say is that the sooner LWP dies, the better. [10:50:36] we could "kill" lwp. i already did lwp-api-as-pthreads once. the code is suitably licensed [10:51:14] it's not that hard to do once you figure out the scheduler fun [10:51:45] > lwp-api-as-pthreads Oh? Does it maintain the non-preemptive behavior of LWP on which many remaining LWP users depend? [10:52:08] yeah. because their locking sucks. [10:52:18] it does. [10:52:38] come on, you should remember this. i wrote it in the back of your saturn sedan on the way to dan root's family's house [10:53:34] I was busy driving. :-) [13:27:04] We have a guy here who's trying to build "1.4.12-1.1.2" on Fedora 13 and getting build errors. Did we not package an RPM for that version? [13:27:45] Er, did we not package 1.4.12.1 as an RPM? [13:28:42] Possibly. I've been a little busy with other things of late, and if nobody has nagged me, it probably hasn't been done. [13:29:27] Looks like we haven't. Not going to happen before Pilsen, either. [13:30:09] Okay. I guess I'll turn him loose on it, then. [13:31:39] makesrpm on the 1.4.12.1 tarball should work [13:32:01] * haba has had a nasty cold this week. However I think/hope to be OK Sunday evening for travel to Pilsen. Now I will go to bed and get well ASAP :<) [13:32:22] I just need to win my battle with the OpenAFS build system. [13:34:01] 1.4.12-1.1.2 isn't 1.4.12.1? what is it? [13:35:42] It's whatever patch sets are necessary to build on ... Fedora 13 [13:35:50] (it was built before 1.4.12.1 was cut) [13:36:18] So, I think kaduk's "guy here" is possibly mistaken. That SRPM builds on Fedora 13. I have the RPMs to prove it. [13:36:26] Hm, but it seems to be newer than the 1.4.12.1 tarballs on dl.openafs.org . [13:36:42] Note that Fedora 13 upgraded from kernel 2.6.33 to kernel 2.6.34 a few days ago. [13:38:30] I suspect that's the issue. [13:38:47] 1.4.12.1 has the fixes for 2.6.34. I suspect that our build system hasn't seen the new kernel modules yet. [13:40:25] --- haba has left [13:41:31] Is Edward ("guy here") going to be wasting his time if he tries to make 1.4.12.1 rpms, or would it be fairly straightforward? (Note I know little about rpms and am probably not using entirely the right terms.) [13:43:10] How urgently does he need them? [13:44:32] If he needs them next week, then makesrpm should just work, and then he can build them from there. [13:44:54] If he's prepared to wait till after that, then I should have a chance to update the buildfarm so we can produce them automatically [13:48:36] Maybe I should just get him on jabber ... [13:51:42] --- ezyang@mit.edu/barnowl has become available [13:51:59] Hello [13:52:03] hi [13:52:56] So, Ed, maybe you could describe a bit why you want to build for f13 and what your timeline goals are. [13:53:09] Yeah, sure! [13:54:25] So Scripts has been on Fedora 11 for a long time now, which has been EOLed. We've been really procrastinating on the Fedora 13 transition, but I finally found a chunk of free time to migrate everything to the new release. [13:55:02] (Scripts being scripts.mit.edu) [13:55:29] At this point, everything works except AFS. After we have things setup, we need to give users some time to test their scripts on the new platform before migrating. This means that earlier in term is better than later in term (when finals and final projects are happening) [13:55:43] That is, essentially, all of the timeline pressure we have. It's not much. :-) [13:55:56] --- mdionne has become available [13:56:49] Well, the situation is that we know that 1.4.12.1 works with the Fedora 13 kernel, because Marc did that work yonks ago. [13:57:04] * ezyang@mit.edu/barnowl nods [13:57:29] But I haven't yet had the time to let our build farm loose on it. And whilst that should be a 30 minute job, it might not be, and I don't have the time to spare right now if it isn't. [13:58:09] If you like, all of the tools we use to make srpms from tarballs are available. You should be able to do it yourself. [13:58:20] Oh, that's something improtant I missed. We don't need a build; just a source rpm would be fine. [13:58:42] (Since Scripts builds a patched client anyway.) [13:58:58] You can use our makesrpm script to produce your own SRPM. [14:00:10] (src/packaging/RedHat/makespm.pl) [14:00:20] er, makesrpm.pl [14:00:23] Yeah. I was just trying to get the git link to download it :) [14:00:31] *nod* I guess I can understand your reluctance to toss a source rpm up without building it first. [14:00:53] Feed it the bz2 versions of the src and doc tarballs, and the Changelog and RELNOTES files [14:01:00] it will spit out an RPM on the other side. [14:01:08] Ok, will do. [14:01:22] Let us know if you run into any problems. [14:01:47] (We have been know to break the RPM packaging that ships in the tarballs) [14:02:41] And now I'm going to get back to ranting about the number of Makefile rules you have to modify just to add one new object to the kernel build. Surely I should have better things to be doing on a Friday night. [14:02:44] --- meffie has left [14:03:10] --- meffie has become available [14:05:42] --- ezyang@mit.edu/barnowl has left [14:17:15] Simon Wilkinson: makesrpm.pl doesn't know how to get things like $afsversion anymore, based on the 1.5 tarballs, as they aren't git working dirs, and configure.ac doesn't have anything about version info anymore [14:18:02] Those changes haven't been back ported to 1.4.x, so I doubt it will be a problem in this case. [14:18:17] ah, he was only asking about 1.4? [14:18:24] Yeah [14:19:32] And I think Andrew Deason has fixed the other issues you mentioned. [14:20:08] (A whole series of changes, around gerrit 2640, merged September 2nd) [14:20:34] 346ccf51ddedadd7f6709276237c26b7871ffbaf [14:20:40] yeah, I see that [14:21:10] it still won't know how to get the version if you're not in a git checkout [14:21:17] so it will call it UNKNOWN [14:21:39] correct [14:21:40] --- meffie has left [14:22:01] which, for the 1.5 tar.bz2's, they're not git checkouts [14:22:24] which is the problem I had when trying to use makesrpm.pl with 1.5.77 [14:22:31] --- meffie has become available [14:22:48] Hmmm. I guess Derrick needs to use the updated release packaging tool that drops a .version file into the tarball. [14:23:44] or if you just want to put one in yourself, it should work after that [14:25:49] Of course, I can't now find the updated copy of that script, so maybe I forget that all-important step. [14:26:07] Anyhoo. Don't care right now. [14:42:25] --- ezyang@mit.edu/barnowl has become available [14:42:44] I'm running the makesrpm.pl script and getting a few errors, and I'm curious if they're harmless or not. [14:42:56] What are the errors/ [14:43:19] http://pastebin.com/tyJaCrEF [14:44:21] Definitely not expected. [14:45:14] Hm. [14:45:18] That looks like some kind of an I/O error whilst RPM was making the srpm. [14:45:35] So, I am doing this on Ubuntu, I can try running the script on a Fedora machine. [14:47:55] also, the script assumes bzip by passing -j and it probably could omit that flag and work better. [14:48:02] (I can send a patch for that) [14:48:38] Please do! [14:51:54] is it possible openafs-kernel-version is just not used to being run with something like dash? [14:51:59] (if dash is on that ubuntu machine) [14:52:22] That would be my guess. [14:52:23] Does makesrpm.pl run openafs-kernel-version ? [14:52:23] and I thought makesrpm.pl expected a .tar.bz2, don't we want a j? [14:52:45] daeson: it claims it wants .tar.gz [14:53:06] that's a bug in the usage message :) [14:53:09] Ah. rpm will run makesrpm.pl [14:53:14] It's fixed in 1.5.x, I think. [14:53:19] (the usage message, that is) [14:53:27] yeah, it is [14:53:57] And, I meant to say, rpm will run openafs-kerne-version.sh [14:54:49] So, what should I do? [14:55:12] Run it on a Fedora system. [14:55:14] I would guess running it on the fedora box you want this on would be more likely to work [14:55:25] Ok. [14:55:56] It seems to me there's not a terribly good reason to only accept bzipped tarballs [14:56:27] Probably not, no. If you fancy generalising the code, then please do so. [14:56:35] this script isn't exactly run by many people [14:57:02] --- meffie has left [14:57:02] Fair enough :-) [14:57:13] yeah, runs just fine on Fedora. [14:58:44] --- meffie has become available [15:06:11] --- deason has left [15:22:00] --- mdionne has left [15:48:34] --- deason has become available [16:00:29] --- mdionne has become available [16:20:36] --- mdionne has left [16:23:57] Ok, I think there's another bug with the usual packaging script, which is that it generates PACKAGE_VERSION instead of version macro references, which Fedora doesn't seem to do the right thing with. [16:25:07] That's a bug in the spec file, I think. I thought we'd fixed it, but perhaps that fix hasn't made it into the 1.4 tree yet. [16:30:59] Yeah, 0d0e7699c9f789214205fe6837cded1a4c95f9c0 on master [16:33:08] ok. Curiously enough, I think you guys have two RPMs for 1.4.12, for which one of them is fixed. [16:33:49] Yeah. IIRC, that's what the difference between 1.1.1 and 1.1,2 is. [16:35:15] "Should I submit a patch for this?" :-) [16:35:30] might be less work for you guys to just go and commit a fix yourself [16:47:18] --- mdionne has become available [17:35:00] --- rra has left: Disconnected [17:51:50] --- Russ has become available [18:42:08] --- jaltman has become available [20:09:51] --- mdionne has left