[OPEN-ILS-DEV] removing legacy json from autotools
In my previous patch, all of the objson code was removed from OpenSRF,
including the autotools bits that compiled objson. This patch removes the
remaining autotools bits, in particular giving the user the choice of whether
to build legacy json.
-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
Index: configure.ac
===
--- configure.ac (revision 1375)
+++ configure.ac (working copy)
@@ -80,19 +80,6 @@
AM_CONDITIONAL([BUILDPYTHON], [test x$OSRF_INSTALL_PYTHON = xtrue])
AC_SUBST([OSRF_INSTALL_PYTHON])
-# create the legacy JSON headers and .so file for backwards compatibility?
-AC_ARG_ENABLE([legacyjson],
-[ --disable-legacyjsondisable the legacy json headers and .so file for backwards compatibility],
-[case ${enableval} in
-yes) OSRF_LEGACY_JSON=true ;;
-no) OSRF_LEGACY_JSON=false ;;
- *) AC_MSG_ERROR([please choose another value for --disable-legacyjson (supported values are yes or no)]) ;;
-esac],
-[OSRF_LEGACY_JSON=true])
-
-AM_CONDITIONAL([BUILDJSON], [test x$OSRF_LEGACY_JSON = xtrue])
-AC_SUBST([OSRF_LEGACY_JSON])
-
# enable debug?
AC_ARG_ENABLE(debug,
@@ -293,12 +280,6 @@
AC_MSG_RESULT([OSRF install python?:no])
fi
-if test $OSRF_LEGACY_JSON = true ; then
-AC_MSG_RESULT([OSRF install legacy json?: yes])
-else
-AC_MSG_RESULT([OSRF install legacy json?: no])
-fi
-
AC_MSG_RESULT(Installation directory prefix: ${prefix})
AC_MSG_RESULT(Tmp dir location:${TMP})
AC_MSG_RESULT(APXS2 location:${APXS2})
Index: bin/osrf_config.in
===
--- bin/osrf_config.in (revision 1375)
+++ bin/osrf_config.in (working copy)
@@ -21,16 +21,12 @@
function showInstalled {
[EMAIL PROTECTED]@
[EMAIL PROTECTED]@
- [EMAIL PROTECTED]@
if test $JAVA = true; then
echo OSRF_JAVA
fi
if test $PYTHON = true; then
echo OSRF_PYTHON
fi
- if test $JSON = true; then
- echo OSRF_LEGACY_JSON
- fi
}
function showAll {
[OPEN-ILS-DEV] Re: removing legacy json from autotools
Looks good to me Kevin On Mon, 2008-07-28 at 09:33 -0400, Bill Erickson wrote: In my previous patch, all of the objson code was removed from OpenSRF, including the autotools bits that compiled objson. This patch removes the remaining autotools bits, in particular giving the user the choice of whether to build legacy json. -b
Re: [OPEN-ILS-DEV] Thinking about receiving
On Sunday 27 July 2008 11:19 Mike Rylander wrote: On Sun, Jul 27, 2008 at 9:51 AM, Bill Erickson [EMAIL PROTECTED] wrote: On Thursday 24 July 2008 8:54 David J. Fiander wrote: [snip] 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. Learning/stealing from Vandelay, we could add an identifier boolean to acq.lineitem_attr_definition, and simply search all of these attrs as an exact-match from a single search box. Add ISBN, ISSN, UPC, po number (as a vendor attribute), ASN id, etc. We'd also want to search the barcode on lineitem_detail for detecting shelf-ready items. I like this approach. It will certainly make the interface more streamlined. -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
[OPEN-ILS-DEV] Re: removing legacy json from autotools
On Monday 28 July 2008 9:35 Kevin Beswick wrote: Looks good to me Committed. Thanks for the eyes, Kevin. -b Kevin On Mon, 2008-07-28 at 09:33 -0400, Bill Erickson wrote: In my previous patch, all of the objson code was removed from OpenSRF, including the autotools bits that compiled objson. This patch removes the remaining autotools bits, in particular giving the user the choice of whether to build legacy json. -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] Thinking about receiving
On Thursday, July 24, 2008 7:55 PM, David J. Fiander wrote: 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. The system would need some way of dealing with duplicate (reused) ISBNs or items with no ISBN. Bryan Baldus Cataloger Quality Books Inc. The Best of America's Independent Presses 1-800-323-4241x402 [EMAIL PROTECTED]
Re: [OPEN-ILS-DEV] Thinking about receiving
Bryan, You're absolutely right, and I'd already thought of dealing with items without ISBNs, at least. But for the initial development, I think we need to focus on the simplest and most common case of items with unique ISBNs. On Mon, Jul 28, 2008 at 10:13 AM, Bryan Baldus [EMAIL PROTECTED] wrote: On Thursday, July 24, 2008 7:55 PM, David J. Fiander wrote: 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. The system would need some way of dealing with duplicate (reused) ISBNs or items with no ISBN. Bryan Baldus Cataloger Quality Books Inc. The Best of America's Independent Presses 1-800-323-4241x402 [EMAIL PROTECTED]
Re: [OPEN-ILS-DEV] Simplifying Ubuntu install documentation (was:Installing on Ubuntu7.10 - ejabber problem)
Hello Dan S., I think this sounds like a great idea. I know the instructions have not kept up with Evergreen installation best practices, but I have been hesitant to rewrite them, since they do (mostly) work. Ejabberd in particular has always been a problem area, and I have only just recently realized that clearing the Mnesia spool is a quick and dirty way to solve many of them, but if we leave ejabberd listening at localhost I think the worst problems will just go away. I have already moved out the old page to the Older Versions archive and added a promise of new things to come in its place, so feel free to deliver on that promise when you get the chance :) If you go ahead and copy over the Debian instructions and make the changes you already know about, I will be happy to run through with an attempted Ubuntu newbie mentality to help make them as bullet-proof as possible. Thanks, DW Dan Scott [EMAIL PROTECTED] 7/26/2008 11:52 AM Hi Dan Wells: 2008/7/26 Dan Scott [EMAIL PROTECTED]: 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. I really appreciate all of the work you did in finishing off the Ubuntu install documentation way back when - but based on the ongoing complications people experience using FQDN throughout various config files, would you mind horribly if I replaced the Ubuntu 7.10 install documentation with a copy of the Debian Etch install instructions, modified slightly to reflect the minor differences for Ubuntu? The primary differences would be: * the use of Makefile.install to eliminate all of the prerequisite install steps * keeping localhost throughout to simplify the network setup * modifying the opensrf user's environment variables rather than modifying the autogen.sh and osrf_ctl.sh scripts (as the latter approach doesn't hit all of the scripts that need to be modified and is likely to be forgotten during upgrades) One benefit to the project of making the install documentation for Debian and Ubuntu consistent would be that it would help keep the configuration of the various systems in the wild relatively similar so that it would simplify our attempts to troubleshoot problems. -- Dan Scott Laurentian University
Re: [OPEN-ILS-DEV] Thinking about receiving
David, This sounds like a lot of thought has been put into the process. One question about the invoice #. Many times we only receive a packing list with the books/media that are being received. Would we then have to wait for an invoice? If so, that could really slow things down. As far as receiving one copy at a time vs. keying in numbers. To fit multiple needs it would be good to have the option. There are also times when an item has been ordered on multiple POs. If that is the case it would be good to have a prompt that asks which copy is being received. (It isn't always the first copy that was ordered.) Good luck Carri
Re: [OPEN-ILS-DEV] Fines in Evergreen
Hi, John. Fines are generated by passing the parameter 1 (for true) to the OpenSRF function open-ils.storage.action.circulation.overdue.generate_fines(), generally referred to as the 'fine generator'. Fortunately, there's a Perl script that comes with the Evergreen source distribution that you can just set up as a cron job to do this on a daily basis. When you run it for the first time, it will 'catch up' with all the outstanding circulations that should have outstanding fines on them, but don't yet. In the source distribution, you can find it at $EVERGREEN_SOURCE_DIRECTORY/Open-ILS/src/support-scripts/fine_generator.pl. In the installed system in our cluster, that file ended up in /openils/bin, but I think it was moved there manually. If you are running a VMWare image, I can't say what they did with it, since I've never used the VMWare images. You can also take a look at the current release's version of the fine generator in svn -- http://svn.open-ils.org/trac/ILS/browser/tags/rel_1_2_2_1/Open-ILS/src/support-scripts/fine_generator.pl?rev=9816 Hope this helps! ~B Quoting John van Rassel [EMAIL PROTECTED]: I was wondering if there was a good place to look to figure out how fines work? We are working on getting all of our data to work under Evergreen, and this is my next area to tackle. We have lots of items in the system that show overdue, but no fines are being generated. Is there something I have to do to enable the fines? As always, thanks John == 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] Simplifying Ubuntu install documentation (was:Installing on Ubuntu7.10 - ejabber problem)
That's awesome, Dan! If you could add the Mnesia spool-clearing to a troubleshooting section of the wiki, I'm sure that would help lots of people out (versus the current draconian dpkg --purge ejabberd approach). I'll let you know when I've updated the docs so you can wrap a Kevlar vest around them - thanks a bunch! Dan 2008/7/28 Dan Wells [EMAIL PROTECTED]: Hello Dan S., I think this sounds like a great idea. I know the instructions have not kept up with Evergreen installation best practices, but I have been hesitant to rewrite them, since they do (mostly) work. Ejabberd in particular has always been a problem area, and I have only just recently realized that clearing the Mnesia spool is a quick and dirty way to solve many of them, but if we leave ejabberd listening at localhost I think the worst problems will just go away. I have already moved out the old page to the Older Versions archive and added a promise of new things to come in its place, so feel free to deliver on that promise when you get the chance :) If you go ahead and copy over the Debian instructions and make the changes you already know about, I will be happy to run through with an attempted Ubuntu newbie mentality to help make them as bullet-proof as possible. Thanks, DW Dan Scott [EMAIL PROTECTED] 7/26/2008 11:52 AM Hi Dan Wells: 2008/7/26 Dan Scott [EMAIL PROTECTED]: 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. I really appreciate all of the work you did in finishing off the Ubuntu install documentation way back when - but based on the ongoing complications people experience using FQDN throughout various config files, would you mind horribly if I replaced the Ubuntu 7.10 install documentation with a copy of the Debian Etch install instructions, modified slightly to reflect the minor differences for Ubuntu? The primary differences would be: * the use of Makefile.install to eliminate all of the prerequisite install steps * keeping localhost throughout to simplify the network setup * modifying the opensrf user's environment variables rather than modifying the autogen.sh and osrf_ctl.sh scripts (as the latter approach doesn't hit all of the scripts that need to be modified and is likely to be forgotten during upgrades) One benefit to the project of making the install documentation for Debian and Ubuntu consistent would be that it would help keep the configuration of the various systems in the wild relatively similar so that it would simplify our attempts to troubleshoot problems. -- Dan Scott Laurentian University -- Dan Scott Laurentian University
Re: [OPEN-ILS-DEV] Thinking about receiving
Carri, The packing slip doesn't have an invoice # on it? If that's the case, perhaps MIke's idea about using the PO # is better. I'm a bit concerned about shipments containing odd mixtures of items from various POs; it seems more likely that a shipment will match an invoice than that it will match a PO. As far your second paragraph about multiple copies, this is exactly why I got fuzzy in my original thinking. Thanks for the suggestions. -David On Mon, Jul 28, 2008 at 10:43 AM, Carri L. Oviatt [EMAIL PROTECTED] wrote: David, This sounds like a lot of thought has been put into the process. One question about the invoice #. Many times we only receive a packing list with the books/media that are being received. Would we then have to wait for an invoice? If so, that could really slow things down. As far as receiving one copy at a time vs. keying in numbers. To fit multiple needs it would be good to have the option. There are also times when an item has been ordered on multiple POs. If that is the case it would be good to have a prompt that asks which copy is being received. (It isn't always the first copy that was ordered.) Good luck Carri
Re: SPAM: Re: [OPEN-ILS-DEV] SPAM: OpenSRF autotools update
Noticed a small error in src/gateway/Makefile.am Here is the fix Kevin On Sun, 2008-07-27 at 23:58 -0400, Dan Scott wrote: 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! Index: src/gateway/Makefile.am === --- src/gateway/Makefile.am (revision 1376) +++ src/gateway/Makefile.am (working copy) @@ -21,8 +21,8 @@ $(APXS2) -c $(DEF_LDLIBS) $(options) @srcdir@/osrf_http_translator.c install-exec-local: - $(APXS2) -i -a @srcdir@/osrf_json_gateway.c - $(APXS2) -i -a @srcdir@/osrf_http_translator.c + $(APXS2) -i -a @srcdir@/osrf_json_gateway.la + $(APXS2) -i -a @srcdir@/osrf_http_translator.la clean-local: rm -f @srcdir@/osrf_http_translator.la @srcdir@/osrf_http_translator.lo @srcdir@/osrf_http_translator.slo @srcdir@/osrf_json_gateway.la @srcdir@/osrf_json_gateway.lo @srcdir@/osrf_json_gateway.slo
Re: [OPEN-ILS-DEV] Thinking about receiving
David Fiander [EMAIL PROTECTED] 7/28/2008 9:40 AM Carri, The packing slip doesn't have an invoice # on it? --Sometimes, but not always. I do like the idea of tying the receipt to an invoice. Especially since many of our invoices are electronically downloaded. Will there be some way of automatically verifying that all items on an invoice have been received? If that's the case, perhaps MIke's idea about using the PO # is better. I'm a bit concerned about shipments containing odd mixtures of items from various POs; it seems more likely that a shipment will match an invoice than that it will match a PO. --You are right about this. How feasible is it to have a PO, Vendor (for mixed POs), or Invoice option? As far your second paragraph about multiple copies, this is exactly why I got fuzzy in my original thinking. Thanks for the suggestions. -David On Mon, Jul 28, 2008 at 10:43 AM, Carri L. Oviatt [EMAIL PROTECTED] wrote: David, This sounds like a lot of thought has been put into the process. One question about the invoice #. Many times we only receive a packing list with the books/media that are being received. Would we then have to wait for an invoice? If so, that could really slow things down. As far as receiving one copy at a time vs. keying in numbers. To fit multiple needs it would be good to have the option. There are also times when an item has been ordered on multiple POs. If that is the case it would be good to have a prompt that asks which copy is being received. (It isn't always the first copy that was ordered.) Good luck Carri
Re: SPAM: Re: [OPEN-ILS-DEV] SPAM: OpenSRF autotools update
Applied - thanks! Dan 2008/7/28 Kevin Beswick [EMAIL PROTECTED]: Noticed a small error in src/gateway/Makefile.am Here is the fix Kevin On Sun, 2008-07-27 at 23:58 -0400, Dan Scott wrote: 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
