[00:33:47] --- pod has left [02:43:15] --- Simon Wilkinson has become available [03:20:19] --- pod has become available [03:24:00] --- Simon Wilkinson has left [06:21:39] --- sxw has become available [06:22:52] --- sxw has left [06:25:15] --- sxw has become available [06:35:13] --- sxw has left [06:38:54] --- meffie has become available [06:50:11] --- shadow@gmail.com/owl321E0B4E has left [06:54:14] --- shadow@gmail.com/owlAA60DA2E has become available [07:20:54] --- deason has become available [08:14:25] --- sxw has become available [08:15:24] --- sxw has left [08:18:49] --- Jeffrey Altman has become available [08:31:37] --- sxw has become available [08:32:34] I wonder if any of our code is so performance critical that building with -fPIC would actually be a problem. [08:35:36] on platforms where you can get away with it [08:36:01] i'm going to keep naggint about this: can't always put pic code in .a files you link as static libraries [08:36:20] I was under the impression that every platform supported -fPIC for statically linked code [08:36:36] we tried previously and lost. i don't have notes anymore [08:37:14] It's just that most platforms won't support non-PIC shared libraries (x86 is the notable exception) [08:37:55] Re mock - email me the configs. I'm away walking this weekend so may not be able to look till Monday. [08:38:27] linux sparc will. i wrote the missing fixups for the old ld.so [08:38:54] ok [08:39:06] Typically, the x86_64 problem is that you accidentally pull in i386 RPMs. There's a large exception list in the mock config - you probably need to add to that [08:39:06] well, we should be able to mock rhel6 i386 anyway [08:39:12] i have it. [08:40:06] Take a look at the installed rpm list in the build root, and see if there is anything out of place. If so, exclude it. Rinse, lather and repeat. [08:40:30] i may be excluding too much [08:40:47] Possibly, yes. What error are you getting? [08:41:12] hang on, i will tell you in a moment. i tweaked config, flushed root and am retrying [08:41:23] Okay [08:42:19] oh, this one will be back to "somehow we instyalled the wrong cc" because i fucked up and removed the exclusion list. [08:42:55] --- sxw has left [08:42:58] --- sxw has become available [08:43:06] in the last one, iirc i only allowed glibc, glibc-devel, and it wanted some perl shit too, which seems odd. [08:43:40] It will want everything that's in the install build group. That probably includes perl [08:44:23] no build groups yet. build group done by hand [08:44:31] (it yum installs that group, then installs your build requirements, then tries to build your package> [08:44:38] ah. Don't do that. [08:44:46] can't not. [08:44:48] Use the EPEL6 buildgroups [08:44:58] i'd love to. [08:45:22] You can download them from the Fedora koji [08:45:35] seemingly not. i tried. [08:45:53] when this run bombs i will look again [08:45:57] Hmmm. I have one in London that I downloaded a few weeks ago. [08:46:05] Sadly, my router hates me. [08:50:31] --- sxw has left [08:54:19] ah. the koji comps uses "build" instead of "buildsys-build" [09:14:56] --- reuteras has left [09:31:21] ok. well, there's more to it. yum groupinstall buildsys-build thinks it wants libcom_err.i686 for some reason [09:50:33] --- summatusmentis has become available [09:59:33] --- sxw has become available [10:00:23] That's not necessarily a bad thing, although it is surprising, just allow that through the exception list. [10:02:40] --- sxw has left [10:06:31] --- sxw has become available [10:10:26] --- sxw has left [10:17:00] --- rra has become available [10:23:45] --- Simon Wilkinson has become available [10:38:15] yeah, see, libcom_err (and lots of i686 stuff) require glibc i686. which is weird, that that's the error: i am allowing glibc. i am *not* allowing all the other stuff [10:39:47] What's the exact error that you are getting? [10:40:04] # /usr/bin/yum --installroot /var/lib/mock/epel-6-x86_64/root/ groupinstall bu ildsys-build Error: Package: libcom_err-1.41.12-3.el6.i686 (core) Requires: libc.so.6(GLIBC_2.4) Error: Package: 4:perl-libs-5.10.1-115.el6.i686 (core) Requires: libc.so.6 (and like 50 more) [10:41:33] Have you using koji mock-config to pull down the mock configuration that EPEL is using? [10:41:48] maybe i should. [10:42:35] I'm not sure if you need to be a fedora packager to be able to run that. If you do, then I should be able to do so, but possibly not from this machine (the VM with my keys on it is behind the uncooperative router) [10:42:52] you and your pesky keys issues [10:44:19] Yeah yeah yeah. At least I know the password for these :) [13:04:46] hmm, question: I wrote a patch for 1.4 that drops xvcache prior to afs_FlushVCBs, and now I see that a309e274 exists for master; the commit message suggests that just dropping xvcache is too difficult, with which I disagree... [13:05:12] any opinions on whether FlushVCBs'ing inline is desirable over dynamically allocating CBRs and handing the flushing to another thread as a309e274 does? [13:07:36] My recollection is that it _is_ too difficult, or at least more difficult than just dropping it, because it is actually important to block some other use. But I don't recall just at the moment. [13:07:59] cynically, patches for 1.4 are boring. in any case, what is the proposed patch? there are issues we discovered when playing with this previously, which possibly didn't get written down [13:08:49] As usual, we have far too little documentation on what the locks are supposed to be and what they protect, both in terms of actual data and correct sequencing. [13:09:48] I'm not sure what the issue could be; afs_FlushVCache callers need to handle the possibility of sleeping anyway [13:10:36] I just sleep in QueueVCB if cbrSpace is NULL, and reacquire xvcache after xvcb is dropped; QueueVCB gains a 'int *slept', and is set if we sleep [13:11:24] unless you want something in gerrit to discuss; but that's basically all it is [13:12:11] ok. then i need to find some time to look at it. but at the moment i am trying to deal with some other stuff. [13:12:36] but I was wondering if dynamically allocating the CBRs temporarily is desirable anyway; it makes it go a bit faster when we're pressured since we don't need to hit the net... but it makes the memory usage theoretially unbounded [13:13:39] and it only signals FlushVCBs by waking up afs_Daemon, so it make take 60 seconds for it to actually run, not to mention if one of the other daemon processes is holding it up [15:10:17] I have FreeBSD packaging prepared and basically ready to submit, but it is currently configured to actually build a working version, which means 1.6.0rc1. Do I want to change it so that what is committed will work with the released 1.6.0 before submitting? [15:26:03] does the patchset have the version number hardcoded? [15:39:27] --- deason has left [15:39:39] It has to know where to fetch the tarball, and also the name of the tarball (which contains the version number). Prerelease tarballs are in a different directory than release tarballs. [16:08:09] Packaging for other platforms is handled from within the build. A tagged git tree is checked out and the packages with the correct version numbers are generated from that. It sounds like your scripts do not work that way. [16:15:16] That's not entirely true. [16:15:31] In fact, I think that's only true (on Unix) of Mac OS X. [16:15:49] Everything else starts with the tarballs which are produced by Derrick running make_release [16:16:23] Yeah, the Debian stuff in the tree is there only as a convenience for other people and isn't what's used to build the actual Debian and Ubuntu packages. [16:16:51] I try to keep it in sync, but the packaging doesn't use it directly. [16:18:17] For RedHat, we take the tarballs that come from Derrick. By default, the make_srpm script pulls out the spec file from the tarball, and builds using that. But we fairly regularly discover packaging issues after the release has been tagged, and modify the specfile directly to resolve those. [16:22:18] --- summatusmentis has left [16:22:25] --- summatusmentis has become available [16:25:15] is it appropriate for the version information to be hard coded into the script? [16:25:27] or does it simply not matter? [16:27:23] It depends on what the script is going to be used for. Is it a reference, or designed to be used for creating new builds? [16:38:43] Oops, took a meatspace interrupt. "Anyone" using this packaging to do a build would be using the copy from FreeBSD's tree, which mostly makes this a reference. (That is, these files would need to be moved elsewhere on disk in order to do anything useful.) [16:39:12] The freebsd ports system is really set up to use tarballs generated from an upstream. [17:39:45] --- jaltman/FrogsLeap has left: Disconnected [18:43:14] --- Russ has become available [18:45:51] --- Simon Wilkinson has left [18:57:33] --- meffie has left [19:13:51] --- jaltman/FrogsLeap has become available [19:17:20] --- jaltman/FrogsLeap has left: Disconnected [19:17:47] --- jaltman/FrogsLeap has become available [21:32:24] --- Jeffrey Altman has left: Disconnected [23:24:00] --- Russ has left: Disconnected