[5524] in Moira
Re: Two patches
daemon@ATHENA.MIT.EDU (Evan Broder)
Mon Jan 4 15:15:47 2010
MIME-Version: 1.0
In-Reply-To: <07FBC978-EECD-48A0-9086-BA1033D86184@mit.edu>
Date: Mon, 4 Jan 2010 14:15:37 -0600
Message-ID: <178868c41001041215h4c2a6d89k7ec8fb1968d04636@mail.gmail.com>
From: Evan Broder <broder@MIT.EDU>
To: Garry P Zacheiss <zacheiss@mit.edu>
Cc: "moiradev@mit.edu" <moiradev@mit.edu>
Content-Type: multipart/mixed; boundary=00504502ad147bf7a2047c5c6285
--00504502ad147bf7a2047c5c6285
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On Mon, Jan 4, 2010 at 12:03 PM, Garry P Zacheiss <zacheiss@mit.edu> wrote:
> Comments in-line below.
>
> On Jan 2, 2010, at 6:33 PM, Evan Broder wrote:
>
>> Hi -
>> =A0 =A0I've attached two patches I put together as part of my work on
>> MacAthena, and one from Debathena
>>
>> First, ./configure sets a sysconfdir variable, intended for
>> system-wide configuration files (i.e. the configurable version of
>> /etc). respect-sysconfdir.diff causes the update_server to respect
>> sysconfdir when installing and looking for moira.conf.
>>
Sure, that works for me - I have no particular attachment to
/etc/athena/moira.conf vs /etc/moira.conf. From Debathena's
standpoint, I can be sure to add code to handle that transition, so
there's no trouble there. New patch attached.
>
> The Athena 9 build system set sysconfdir to /etc/athena, so this patch en=
ds up setting CONFIG_FILE to /etc/athena/athena/moira.conf in that case. =
=A0I think it would be more correct for CONFIG_FILE to get set to $(DESTDIR=
)$(sysconfdir)/moira.conf rather than sticking the random "athena" in there=
; I don't think the file ending up in /etc is wrong.
>
>> Second, OS X has a bizarro version of com_err. For whatever reason,
>> initialize_FOO_error_table() is a NOOP; unless you call
>> add_error_table(&et_FOO_error_table) instead, com_err doesn't have
>> access to the error tables and you get numeric error messages. Except
>> for libkrb5, where you need to build with -framework Kerberos to get
>> access to the error tables (but don't need to call add_error_table).
>> Like I said, bizarro.
>>
>
> Looks good, committed.
>
>> fix-os-x-comerr.diff updates both the build flags and
>> initialize_FOO_error_table calls to do the correct thing. Both patches
>> will only have any effect if Moira is being built on OS X. (The patch
>> to configure.in is based on r23277 I committed to Debathena a while
>> back).
>>
>> Finally, now Moira can be built as a shared library, but it's not
>> possible to build additional out-of-tree clients against it, because
>> the headers aren't currently installed. I'm particularly interested in
>> seeing the headers installed for my Python bindings to libmoira[1],
>> which Debathena is hoping to use in a series of more user-friendly
>> graphical Moira clients in the near future. install-headers.diff
>> installs <moira/moira.h>, <moira/mr_et.h>, <moira/krb_et.h>, and
>> <moira/ureg_err.h>. I put them under the moira/ subdirectory to avoid
>> any potential conflicts with krb_et.h, but if you'd prefer to see them
>> go directly into $(includedir), that's fine with me as well.
>>
>
> I dither about this one, not because of the content (putting headers unde=
r a moira subdir is fine), but because I'll admit I currently like the fact=
that there aren't really any clients outside of the canonical source tree.=
=A0In the specific case you're thinking about, I would be interested in ta=
king well-thought-out python bindings into the tree (to compliment the JNI =
code that's already there) if you'd be interested in seeing them incorporat=
ed; this is likewise true for any additional clients you're considering wri=
ting. =A0You should note that ISDA has been working on a new webmoira, so i=
f there's functionality you'd like, I'd also strongly consider seeing if th=
ey would include it there rather than writing something standalone.
I understand the hesitation. Honestly, though, I don't think the lack
of Moira client proliferation is connected to the impossibility of
building one. It's already possible to do whatever you need by
shelling out to the existing clients, especially when you count
mrtest/qy in your list of clients. And I really would expect that
anybody with the clue to write their own Moira client at all has the
clue to go find the headers.
Either way, though, I'd definitely be interested in seeing my Python
bindings incorporated into Moira itself. In fact, there are a few
things that I'll be able to do much more cleanly as a part of the
Moira tree (exposing error codes easily comes to mind). I'll see if I
can get you a patchset some time this week.
One thought I had was that, if I was doing Python bindings for
libmoira itself, it would also be really nice if we also had Python
bindings for libmrclient, so that apps using the Python modules
wouldn't need to duplicate code, but Python gets snippy if you try to
build extensions against statically linked libraries. Would you be
amenable to a patch to build libmrclient as a shared library as well
as libmoira?
- Evan
--00504502ad147bf7a2047c5c6285
Content-Type: application/octet-stream; name="respect-sysconfdir.diff"
Content-Disposition: attachment; filename="respect-sysconfdir.diff"
Content-Transfer-Encoding: base64
X-Attachment-Id: f_g41o3svl0
SW5kZXg6IHVwZGF0ZS9NYWtlZmlsZS5pbgo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSB1cGRhdGUvTWFrZWZpbGUu
aW4JKHJldmlzaW9uIDM5NDUpCisrKyB1cGRhdGUvTWFrZWZpbGUuaW4JKHdvcmtpbmcgY29weSkK
QEAgLTQsNyArNCw3IEBACiBAU0VUX01BS0VACiAKIENDPUBDQ0AKLUNQUEZMQUdTPUBDUFBGTEFH
U0AKK0NQUEZMQUdTPUBDUFBGTEFHU0AgLURDT05GSUdfRklMRT1cIiQoc3lzY29uZmRpcikvbW9p
cmEuY29uZlwiCiBDRkxBR1M9QENGTEFHU0AKIERFRlM9QERFRlNACiBBTExfQ0ZMQUdTPSQoQ1BQ
RkxBR1MpICQoQ0ZMQUdTKSAkKERFRlMpCkBAIC01MCw4ICs1MCw4IEBACiBpbnN0YWxsOiBhbGwK
IAkkKExJQlRPT0wpIC0tbW9kZT1pbnN0YWxsICQoSU5TVEFMTF9QUk9HUkFNKSB1cGRhdGVfdGVz
dCAkKERFU1RESVIpJChiaW5kaXIpCiAJJChMSUJUT09MKSAtLW1vZGU9aW5zdGFsbCAkKElOU1RB
TExfUFJPR1JBTSkgdXBkYXRlX3NlcnZlciAkKERFU1RESVIpJChzYmluZGlyKQotCSQoU1JDVE9Q
KS9ta2luc3RhbGxkaXJzICQoREVTVERJUikvZXRjL2F0aGVuYQotCSQoSU5TVEFMTCkgLW0gNjQ0
IG1vaXJhLmNvbmYgJChERVNURElSKS9ldGMvYXRoZW5hL21vaXJhLmNvbmYKKwkkKFNSQ1RPUCkv
bWtpbnN0YWxsZGlycyAkKERFU1RESVIpJChzeXNjb25mZGlyKQorCSQoSU5TVEFMTCkgLW0gNjQ0
IG1vaXJhLmNvbmYgJChERVNURElSKSQoc3lzY29uZmRpcikvbW9pcmEuY29uZgogCiB1cGRhdGVf
dGVzdDogJChDT0JKUykgJChNUl9MSUJERVApCiAJJChMSUJUT09MKSAtLW1vZGU9bGluayAkKEND
KSAtbyAkQCAkKExERkxBR1MpICQoQ09CSlMpICQoTElCUykKSW5kZXg6IHVwZGF0ZS9jb25maWcu
Ywo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09Ci0tLSB1cGRhdGUvY29uZmlnLmMJKHJldmlzaW9uIDM5NDUpCisrKyB1cGRh
dGUvY29uZmlnLmMJKHdvcmtpbmcgY29weSkKQEAgLTI2LDggKzI2LDYgQEAKIAogUkNTSUQoIiRI
ZWFkZXI6IC9hZnMvLmF0aGVuYS5taXQuZWR1L2FzdGFmZi9wcm9qZWN0L21vaXJhZGV2L3JlcG9z
aXRvcnkvbW9pcmEvdXBkYXRlL2NvbmZpZy5jLHYgMS43IDE5OTgtMDItMTUgMTc6NDk6MjcgZGFu
dyBFeHAgJCIpOwogCi0jZGVmaW5lIENPTkZJR19GSUxFCSIvZXRjL2F0aGVuYS9tb2lyYS5jb25m
IgotCiAvKiBWYXJpYWJsZXMgY3VycmVudGx5IHN1cHBvcnRlZDoKICAqIGNocm9vdCBkaXJlY3Rv
cnkJZGFlbW9uIHdpbGwgcnVuIGNocm9vdGVkIHRvIHRoaXMgZGlyZWN0b3J5CiAgKiB1c2VyIHVz
ZXJuYW1lCWRhZW1vbiB3aWxsIHJ1biB3aXRoIHRoaXMgdXNlcidzIHVpZAo=
--00504502ad147bf7a2047c5c6285--
