Re: [OPEN-ILS-DEV] Hours for Org units
Hi Mike, Perhaps a more general approach would be to add a 'Next day' checkbox to the closing time entry. Another possibility is to ask for 'next day' if the entered closing time is earlier than the opening time. Cheers, Faiz Ishaq -Original Message- From: Mike Rylander [EMAIL PROTECTED] To: Evergreen Development Discussion List open-ils- [EMAIL PROTECTED] Date: Sat, 26 Jul 2008 21:26:24 -0400 Subject: Re: [OPEN-ILS-DEV] Hours for Org units On Wed, Jul 23, 2008 at 11:50 AM, Frances Dean McNamara [EMAIL PROTECTED] wrote: I am setting up some test Circulation for our installation. I want to set up some hours for our Libraries. During the regular school year the libraries are open from 8 AM to 1 AM the next day. Will that be a problem for Evergreen? During the summer we close earlier but when I went to set up one set of hours, it made me wonder if the 1 AM closing will be an issue. This won't work today. The first thought that came to mind was to be able to supply a hours after midnight offset to be applied when the closing time is 00:00. This would touch a few deep places, though, and would require a significant effort to make sure everything works as expected (though it would likely be a relatively small change to the code). Suggestions for alternate approaches would be appreciated! :) -- Mike Rylander | VP, Research and Design | Equinox Software, Inc. / The Evergreen Experts | phone: 1-877-OPEN-ILS (673-6457) | email: [EMAIL PROTECTED] | web: http://www.esilibrary.com
Re: [OPEN-ILS-DEV] Installing on Ubuntu7.10 - ejabber problem
Hi Dan and Ryan,
Thanks for your responses. I will try using 'localhost', as advised, and
also run Open-ILS/src/support-scripts/settings-tester.pl on Monday and
post the results.
Cheers, Faiz Ishaq
-Original Message-
From: Dan Scott [EMAIL PROTECTED]
To: [EMAIL PROTECTED], Evergreen Development Discussion List open-
[EMAIL PROTECTED]
Date: Sat, 26 Jul 2008 11:46:47 -0400
Subject: Re: [OPEN-ILS-DEV] Installing on Ubuntu7.10 - ejabber problem
Hi Faiz:
2008/7/26 Faiz Ishaq [EMAIL PROTECTED]:
Hello!
Totally new to Evergreen, I am trying to get it to run on Ubuntu.
Started
with Edubuntu 7.10 install and carried out the steps as given in the
pre-install and install text files. Everything worked fine until step
27,
finalizing the OPAC, using the command:
sudo -u opensrf ./autogen.sh /openils/conf/opensrf_core.xml
It gives 'Unable to connect to Jabber server' errors. The ejabber log
file
has 'Accepted Connection' entries.
Just a wild guess - you followed the Ubuntu install instructions and
changed hostnames from localhost to your fully-qualified domain name
in various configuration files (including ejabberd.cfg)?
For what it's worth, the development team recommends keeping all of
the entries (except for the hosts entry in opensrf.xml) as
localhost unless you're dealing with a system spread over multiple
servers. I'll start a new thread to talk about replacing the existing
Ubuntu instructions.
ejabber log file entries:
=INFO REPORT 2008-07-26 12:28:46 ===
I(0.1052.0:ejabberd_listener:90): (#Port0.1007) Accepted
connection
{{10,0,0,214},54018} - {{10,0,0,214},5222}
It looks like your IP address is resolving to 10.0.0.214. Does the
hostname that you registered the ejabberd users with, and the
hostnames you used for the Jabber user entries in opensrf_core.xml,
resolve to this address?
Have you tried running Open-ILS/src/support-scripts/settings-tester.pl
to check the setup of your various configuration files?
--
Dan Scott
Laurentian University
Re: [OPEN-ILS-DEV] Simplifying Ubuntu install documentation (was: Installing on Ubuntu7.10 - ejabber problem)
2008/7/27 Faiz Ishaq [EMAIL PROTECTED]: Hi Dan Dan, Good idea! I will be happy to do the testing of the Ubuntu install doc. I am looking for a reproducible installation procedure before actually deploying Evergreen as a solution. We may start with the new Ubuntu 8.04 as base since it is a LTS release. Hi Faiz: Ubuntu 8.04 will be a little bit of a bit of a challenge as it comes with PostgreSQL 8.3 - and that is not yet supported with Evergreen (due primarily to changes in the full text search API). Debian Etch (4.0) is still the recommended server distribution for Evergreen. However, if you're comfortable compiling PostgreSQL 8.2 from source, or installing a backport package, then Ubuntu 8.04 may work for you. For what it's worth, I do my Evergreen development work on Ubuntu 8.04. Also note that the xulrunner client in Ubuntu 8.04 is known not to work properly with Evergreen, so you'll have to use a staff client on Windows or another version of Linux to connect to Evergreen. -- Dan Scott Laurentian University
Re: [OPEN-ILS-DEV] Hours for Org units
On Sun, Jul 27, 2008 at 2:18 AM, Faiz Ishaq [EMAIL PROTECTED] wrote: Hi Mike, Perhaps a more general approach would be to add a 'Next day' checkbox to the closing time entry. Another possibility is to ask for 'next day' if the entered closing time is earlier than the opening time. This would work. I also thought of another mechanism last night: instead of a close time, gather an open time and an open interval. Frances' hours of operation would open be 8am, open for 17 hours. Changing all uses of the close fields so that the calendar time is calculated in one addition would be simpler than testing for a separate flag and adding a day, I think. --miker Cheers, Faiz Ishaq -Original Message- From: Mike Rylander [EMAIL PROTECTED] To: Evergreen Development Discussion List open-ils- [EMAIL PROTECTED] Date: Sat, 26 Jul 2008 21:26:24 -0400 Subject: Re: [OPEN-ILS-DEV] Hours for Org units On Wed, Jul 23, 2008 at 11:50 AM, Frances Dean McNamara [EMAIL PROTECTED] wrote: I am setting up some test Circulation for our installation. I want to set up some hours for our Libraries. During the regular school year the libraries are open from 8 AM to 1 AM the next day. Will that be a problem for Evergreen? During the summer we close earlier but when I went to set up one set of hours, it made me wonder if the 1 AM closing will be an issue. This won't work today. The first thought that came to mind was to be able to supply a hours after midnight offset to be applied when the closing time is 00:00. This would touch a few deep places, though, and would require a significant effort to make sure everything works as expected (though it would likely be a relatively small change to the code). Suggestions for alternate approaches would be appreciated! :) -- Mike Rylander | VP, Research and Design | Equinox Software, Inc. / The Evergreen Experts | phone: 1-877-OPEN-ILS (673-6457) | email: [EMAIL PROTECTED] | web: http://www.esilibrary.com -- Mike Rylander | VP, Research and Design | Equinox Software, Inc. / The Evergreen Experts | phone: 1-877-OPEN-ILS (673-6457) | email: [EMAIL PROTECTED] | web: http://www.esilibrary.com
Re: [OPEN-ILS-DEV] [RFC] Price (or percent thereof) as max fine amount.
On Saturday 26 July 2008 10:52 Mike Rylander wrote: We've had requests in the past for the ability to use an item's price as the max fine amount on a circulation, instead of a predefined amount. Because of how rules are defined and chosen in Evergreen today, the solution to this request had not presented itself in a clear and consistent manner. However, John Craig of Alpha-G Consulting (another firm getting into the Evergreen support and migration biz) was wondering about a specialization of this idea and how it might be implemented. He has had a request to be able to use a percentage of the item price as the max fine amount -- and this, it turns out, is the twist that finally made the solution stand out, bright as day as if it had always been right there, as a consistent and general extension of the existing framework. John and I went to our separate corners and dummied up a plan for this, and it turns out that we both saw the same solution. Here attached is an implementation of that solution, which works thusly: * The config.rule_max_fine table gets a new boolean column called is_percent which defaults to false * The IDL (and, for good measure, the storage server's ancient equivelant) is taught about this new field * OpenILS::Circ::Circulate::build_checkout_circ_object inspects this field on the chosen rule for truthiness, and finding a positive result: - gets the item price from the copy and - if that's null (not allowed yet, but will be in 1.4) attempts to find an org_unit-appropriate default item price (also used for LOST fee) - or, if price == 0 and the charge default on 0-price org unit setting is true, attempts to find an org_unit-appropriate default item price (also used for LOST fee) - and now, having found an appropriate full price for the item, interprets the max fine amount as a percentage value, scaling the full price as specified - and finally, uses that amount as the max fine amount, instead of a specific value As an example, say you have an item being checked out and the max fine rule chosen for this circulation looks like this: name = up_to_half_of_price amount = 50.00 is_percent = true and the item price is 20.00. The max fine for that circ would be set to 10.00 ... Another example with the same rule, but the copy has a null (in 1.4) price or a price of 0.00 and charge default on 0-price org unit setting is in effect, and that default price is 25.00. The max fine would be set to 12.50. And, finally, if the max fine amount is 100.00, the full price of the copy or the default price (the original request) would be used. We have come full circle. Thoughts? I think it's a great addition. I eyeballed the patch and it looks good. (comment: instead of redefining isTrue, we can use $U-isTrue). One addition to consider is adding an org-setting cache (just a local data structure) for default item price and charge-on-0 to reduce network calls. That can come later, though. Good work, guys. -bill -- Bill Erickson | VP, Software Development Integration | Equinox Software, Inc. / The Evergreen Experts | phone: 877-OPEN-ILS (673-6457) | email: [EMAIL PROTECTED] | web: http://esilibrary.com
Re: [OPEN-ILS-DEV] problem during installation of evergreen
Hi Vijay: 2008/7/27 vijay kumar [EMAIL PROTECTED]: Dear Member; I am getting some error during installtion of Evergreen-ILS-1.2.2.3 I am using postgre-8.3 on Ubuntu-Hardy Evergreen does not yet support PostgreSQL 8.3; we're working on it, but we do not expect to officially support 8.3 until Evergreen 2.0. If you're familiar with the changes in PostgreSQL 8.3, we'd love your help in making the required adjustments to Evergreen. Otherwise, you will need to install PostgreSQL 8.2 on Hardy and supply the corresponding connection information at config time to be able to run Evergreen on this Linux distribution. -- Dan Scott Laurentian University
Re: [OPEN-ILS-DEV] removing of objson from opensrf
On Friday 25 July 2008 12:23 Bill Erickson wrote: This patch is running on acq.open-ils.org... also, so far so good. If there are no objections, I'll commit soon. Committed. http://svn.open-ils.org/trac/OpenSRF/changeset/1373 -b -- Bill Erickson | VP, Software Development Integration | Equinox Software, Inc. / The Evergreen Experts | phone: 877-OPEN-ILS (673-6457) | email: [EMAIL PROTECTED] | web: http://esilibrary.com
Re: [OPEN-ILS-DEV] On the merits of init scripts...
On Sun, Jul 27, 2008 at 9:05 AM, Dan Scott [EMAIL PROTECTED] wrote: 2008/7/16 Scott McKellar [EMAIL PROTECTED]: --- Aaron Joyner [EMAIL PROTECTED] wrote: snip -- about a system init script, at least for simple cases Any init script should respect the distinction between OpenSRF (a generic infrastructure layer) and Evergreen (a specific application built on top of OpenSRF). In principle it should be possible, and preferably easy, to run OpenSRF for other things besides Evergreen, or even without Evergreen at all. The separation between those layers is still not completely clean, but hopefully it will be some day, and in the meanwhile we should at least maintain the pretense of independence. So I would suggest two init scripts. The first one would initialize OpenSRF. The second one would either call the first one or verify that OpenSRF was already up and running, and then initialize the pieces specific to Evergreen. I've been thinking about this a little bit. Given that Evergreen is an OpenSRF application, I'm not sure what it would mean to initialize OpenSRF without initializing the pieces specific to Evergreen; opensrf.xml defines the OpenSRF services that should be started up as part of start_perl / start_c. I suppose you could have a opensrf init script that just performed the equivalent of stop/start/restart[routerperlc] (along with dependency checking to ensure postgresql / ejabberd is running), and an evergreen init script to stop/start/restart clark-kent.pl / SIP server / assorted other daemons, and make opensrf and apache as dependencies. That separation would buy us the ability to restart the daemons without restarting the router/c/perl services. I definitely like the idea of a universal init script. It's going to be most useful for single-server systems, of course; if you've moved Apache and PostgreSQL and ejabber and memcached off to separate servers for scaling purposes, the scripts will obviously have to be tweaked. But at that point you're in a different realm than just I have a spare server and want to try out Evergreen in the simplest possible fashion :) Another thing to consider (in the pros column for separation) is that we will eventually be able to address each service independently for start/stop/restart. I was hoping this would happen for 1.4, but 2.0 is more likely. Still, separating now will make things easier down the road. -- Mike Rylander | VP, Research and Design | Equinox Software, Inc. / The Evergreen Experts | phone: 1-877-OPEN-ILS (673-6457) | email: [EMAIL PROTECTED] | web: http://www.esilibrary.com
Re: [OPEN-ILS-DEV] Thinking about receiving
On Thursday 24 July 2008 8:54 David J. Fiander wrote: Receiving needs to be efficient, since it's most definitely a materials handling process above everything else. Imagine that the staff have opened a box and dug out the packing slip / invoice. Once they've checked that against the contents of the box against the slip, they're ready to start checking materials into the system. They go to the receiving screen, which comes up with today's date, which will be used as the actual received date in the acqlids that are updated. In order to properly track things, the acqlid should probably have an invoice # field. On the receiving screen, there will be a field at the top into which the staff member enters the current invoice number, which will then be applied to all the acqlids that are updated. The primary field on the receiving screen is an ISBN input field. The staff scan the ISBN barcode on each item, which pulls up the corresponding JUB. This seems like a reasonable approach. I guess this screen will also have a box for ISSN, etc. I think it would also be good to support using the PO as the receiving entry point. Assuming the PO number is included with the invoice, staff can pull up the PO by ID and mark all items or individual items as received. Dan S. also submitted a work flow at http://open-ils.org/dokuwiki/doku.php?id=acq:scenarios:receiving_monographs -b -- Bill Erickson | VP, Software Development Integration | Equinox Software, Inc. / The Evergreen Experts | phone: 877-OPEN-ILS (673-6457) | email: [EMAIL PROTECTED] | web: http://esilibrary.com
Re: [OPEN-ILS-DEV] [RFC] Price (or percent thereof) as max fine amount.
On Sun, Jul 27, 2008 at 8:52 AM, Bill Erickson [EMAIL PROTECTED] wrote: On Saturday 26 July 2008 10:52 Mike Rylander wrote: [snip] * The config.rule_max_fine table gets a new boolean column called is_percent which defaults to false * The IDL (and, for good measure, the storage server's ancient equivelant) is taught about this new field * OpenILS::Circ::Circulate::build_checkout_circ_object inspects this field on the chosen rule for truthiness, and finding a positive result: - gets the item price from the copy and - if that's null (not allowed yet, but will be in 1.4) attempts to find an org_unit-appropriate default item price (also used for LOST fee) - or, if price == 0 and the charge default on 0-price org unit setting is true, attempts to find an org_unit-appropriate default item price (also used for LOST fee) - and now, having found an appropriate full price for the item, interprets the max fine amount as a percentage value, scaling the full price as specified - and finally, uses that amount as the max fine amount, instead of a specific value [snip] I think it's a great addition. I eyeballed the patch and it looks good. (comment: instead of redefining isTrue, we can use $U-isTrue). One addition to consider is adding an org-setting cache (just a local data structure) for default item price and charge-on-0 to reduce network calls. That can come later, though. Next question is ... how far back do we backport this. I would lobby for 1.2.3.0, but not to strongly. -- Mike Rylander | VP, Research and Design | Equinox Software, Inc. / The Evergreen Experts | phone: 1-877-OPEN-ILS (673-6457) | email: [EMAIL PROTECTED] | web: http://www.esilibrary.com
Re: [OPEN-ILS-DEV] [RFC] Price (or percent thereof) as max fine amount.
On Sunday 27 July 2008 11:24 Mike Rylander wrote: On Sun, Jul 27, 2008 at 11:21 AM, Mike Rylander [EMAIL PROTECTED] wrote: On Sun, Jul 27, 2008 at 8:52 AM, Bill Erickson [EMAIL PROTECTED] wrote: On Saturday 26 July 2008 10:52 Mike Rylander wrote: I think it's a great addition. I eyeballed the patch and it looks good. (comment: instead of redefining isTrue, we can use $U-isTrue). I don't see the definition for isTrue anywhere in the OpenILS:: namespace Arg, sorry, the Perl code is mostly non-camel-case: $U-is_true -b -- Bill Erickson | VP, Software Development Integration | Equinox Software, Inc. / The Evergreen Experts | phone: 877-OPEN-ILS (673-6457) | email: [EMAIL PROTECTED] | web: http://esilibrary.com
Re: [OPEN-ILS-DEV] [RFC] Price (or percent thereof) as max fine amount.
On Sunday 27 July 2008 11:21 Mike Rylander wrote: On Sun, Jul 27, 2008 at 8:52 AM, Bill Erickson [EMAIL PROTECTED] wrote: On Saturday 26 July 2008 10:52 Mike Rylander wrote: Next question is ... how far back do we backport this. I would lobby for 1.2.3.0, but not to strongly. Well, you've done the hard part! 1.2.3.0 seems reasonable to me. -b -- Bill Erickson | VP, Software Development Integration | Equinox Software, Inc. / The Evergreen Experts | phone: 877-OPEN-ILS (673-6457) | email: [EMAIL PROTECTED] | web: http://esilibrary.com
Re: [OPEN-ILS-DEV] [RFC] Price (or percent thereof) as max fine amount.
On Sun, Jul 27, 2008 at 11:21 AM, Mike Rylander [EMAIL PROTECTED] wrote: On Sun, Jul 27, 2008 at 8:52 AM, Bill Erickson [EMAIL PROTECTED] wrote: On Saturday 26 July 2008 10:52 Mike Rylander wrote: [snip] * The config.rule_max_fine table gets a new boolean column called is_percent which defaults to false * The IDL (and, for good measure, the storage server's ancient equivelant) is taught about this new field * OpenILS::Circ::Circulate::build_checkout_circ_object inspects this field on the chosen rule for truthiness, and finding a positive result: - gets the item price from the copy and - if that's null (not allowed yet, but will be in 1.4) attempts to find an org_unit-appropriate default item price (also used for LOST fee) - or, if price == 0 and the charge default on 0-price org unit setting is true, attempts to find an org_unit-appropriate default item price (also used for LOST fee) - and now, having found an appropriate full price for the item, interprets the max fine amount as a percentage value, scaling the full price as specified - and finally, uses that amount as the max fine amount, instead of a specific value [snip] I think it's a great addition. I eyeballed the patch and it looks good. (comment: instead of redefining isTrue, we can use $U-isTrue). I don't see the definition for isTrue anywhere in the OpenILS:: namespace ... --miker One addition to consider is adding an org-setting cache (just a local data structure) for default item price and charge-on-0 to reduce network calls. That can come later, though. Next question is ... how far back do we backport this. I would lobby for 1.2.3.0, but not to strongly. -- Mike Rylander | VP, Research and Design | Equinox Software, Inc. / The Evergreen Experts | phone: 1-877-OPEN-ILS (673-6457) | email: [EMAIL PROTECTED] | web: http://www.esilibrary.com -- Mike Rylander | VP, Research and Design | Equinox Software, Inc. / The Evergreen Experts | phone: 1-877-OPEN-ILS (673-6457) | email: [EMAIL PROTECTED] | web: http://www.esilibrary.com
Re: [OPEN-ILS-DEV] [RFC] Price (or percent thereof) as max fine amount.
On Sun, Jul 27, 2008 at 11:34 AM, Bill Erickson [EMAIL PROTECTED] wrote: On Sunday 27 July 2008 11:21 Mike Rylander wrote: On Sun, Jul 27, 2008 at 8:52 AM, Bill Erickson [EMAIL PROTECTED] wrote: On Saturday 26 July 2008 10:52 Mike Rylander wrote: Next question is ... how far back do we backport this. I would lobby for 1.2.3.0, but not to strongly. Well, you've done the hard part! 1.2.3.0 seems reasonable to me. Done. :) (Local implementation of isTrue, for now.) -- Mike Rylander | VP, Research and Design | Equinox Software, Inc. / The Evergreen Experts | phone: 1-877-OPEN-ILS (673-6457) | email: [EMAIL PROTECTED] | web: http://www.esilibrary.com
Re: [OPEN-ILS-DEV] Hours for Org units
Or you could gather times in a special bogus format - For a library open 8AM - 2AM, you could specify open hours as 08:00 to 26:00:00, and make anything that checks open hours comprehend this magic incantation. I have vague recollections that at least one Prominent (North American?) Enterprise ILS Vendor (PNAEILSV?) handled the problem this way, though maybe it's not what we're striving for. Neither of these solutions handles the case that some smaller libraries have, with multiple open intervals per day. Or -- stated alternately -- an open interval with gaps. Since we've ripped the gyprock (or, 'drywall' to Americans) off the wall with the open hours plumbing, do we want to include this reno while we have the wall open? :) ~B Quoting Mike Rylander [EMAIL PROTECTED]: On Sun, Jul 27, 2008 at 2:18 AM, Faiz Ishaq [EMAIL PROTECTED] wrote: Hi Mike, Perhaps a more general approach would be to add a 'Next day' checkbox to the closing time entry. Another possibility is to ask for 'next day' if the entered closing time is earlier than the opening time. This would work. I also thought of another mechanism last night: instead of a close time, gather an open time and an open interval. Frances' hours of operation would open be 8am, open for 17 hours. Changing all uses of the close fields so that the calendar time is calculated in one addition would be simpler than testing for a separate flag and adding a day, I think. --miker Cheers, Faiz Ishaq -Original Message- From: Mike Rylander [EMAIL PROTECTED] To: Evergreen Development Discussion List open-ils- [EMAIL PROTECTED] Date: Sat, 26 Jul 2008 21:26:24 -0400 Subject: Re: [OPEN-ILS-DEV] Hours for Org units On Wed, Jul 23, 2008 at 11:50 AM, Frances Dean McNamara [EMAIL PROTECTED] wrote: I am setting up some test Circulation for our installation. I want to set up some hours for our Libraries. During the regular school year the libraries are open from 8 AM to 1 AM the next day. Will that be a problem for Evergreen? During the summer we close earlier but when I went to set up one set of hours, it made me wonder if the 1 AM closing will be an issue. This won't work today. The first thought that came to mind was to be able to supply a hours after midnight offset to be applied when the closing time is 00:00. This would touch a few deep places, though, and would require a significant effort to make sure everything works as expected (though it would likely be a relatively small change to the code). Suggestions for alternate approaches would be appreciated! :) -- Mike Rylander | VP, Research and Design | Equinox Software, Inc. / The Evergreen Experts | phone: 1-877-OPEN-ILS (673-6457) | email: [EMAIL PROTECTED] | web: http://www.esilibrary.com -- Mike Rylander | VP, Research and Design | Equinox Software, Inc. / The Evergreen Experts | phone: 1-877-OPEN-ILS (673-6457) | email: [EMAIL PROTECTED] | web: http://www.esilibrary.com == Brandon W. Uhlman, Systems Consultant Public Library Services Branch Ministry of Education Government of British Columbia 605 Robson Street, 5th Floor Vancouver, BC V6B 5J3 Phone: (604) 660-2972 E-mail: [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: [OPEN-ILS-DEV] 1.4 release: switching locales in the OPAC and staff client
On Saturday 26 July 2008 9:57 Mike Rylander wrote: On Tue, Jul 22, 2008 at 5:35 PM, Mike Rylander [EMAIL PROTECTED] wrote: On Tue, Jul 22, 2008 at 2:40 PM, Dan Scott [EMAIL PROTECTED] wrote: [snip] After supposing for a few days, here are 2 patches which remove the normalization (there was less than I thought) sprinkled throughout the code. No more lowercasing, but we do change '_' to '-' in the core stored procedure that does the translated value lookup. With these patches in place (they're not yet), it's required that ALL locales be assembled in the ll-LL format (that's not strictly true ... there's just no fudge factor in locale case anymore). Eyeballs apreciated, since they touch python and java in addition to my areas. The Java and Python bits look good. -- Bill Erickson | VP, Software Development Integration | Equinox Software, Inc. / The Evergreen Experts | phone: 877-OPEN-ILS (673-6457) | email: [EMAIL PROTECTED] | web: http://esilibrary.com
Re: [OPEN-ILS-DEV] Rewrite of build-db.sh
Many thanks for this patch - I have applied it, with one minor change (006.data.permissions.sql no longer exists in trunk). Sorry for the delay in testing and committing... dang holidays! Dan 2008/7/15 Aaron Joyner [EMAIL PROTECTED]: Whoops. :) File actually attached... Aaron S. Joyner On Tue, Jul 15, 2008 at 10:54 PM, Aaron Joyner [EMAIL PROTECTED] wrote: Round 2! This adds the following changes to the previously described list: - remove database version entirely from the user interface, down to build-db.sh. This makes minor removals from: - install.sh - config.sh - install.conf.default - Open-ILS/src/Makefile - Open-ILS/src/extras/import/build-oils-db.sh - implement automatic detection of PostgreSQL database version - abort if we can not detect the db version, providing the user with our best guess (it's probably not going to be, but oh well) - maintain fallback in the case of missing fts-config.sql for specific db version, with big shiny warnings adapted to the autodetection - abort if no fts-config.sql files exist Let me know if you have any other handy ideas for making this part of the build process simpler. Have vim, will code. Aaron S. Joyner -- Dan Scott Laurentian University
Re: SPAM: Re: [OPEN-ILS-DEV] SPAM: OpenSRF autotools update
2008/7/25 Bill Erickson [EMAIL PROTECTED]: On Friday 25 July 2008 11:43 Kevin Beswick wrote: Updated patch to reflect the changes since the revision that just happened in trunk (r1372). Working for me, FWIW. I had to munge the patch a bit more to deal with the removal of the objson API compat layer, but have committed this to the OpenSRF repository. Thanks Kevin! -- Dan Scott Laurentian University
