Re: [OPEN-ILS-DEV] Call for Evergreen translations
2008/11/20 Brandon W. Uhlman [EMAIL PROTECTED]: Also FYI, Sitka has committed to preparing a Canadian English (en-CA) translation. Long live the multilingual library catalog(ue)! That's great, Brandon. You might want to collaborate on this with John Fink, who had contributed an early version of en-CA support for the OPAC last year. I haven't updated the en-CA strings recently, but could check an updated version into SVN if you're serious, eh? -- Dan Scott Laurentian University
Re: [OPEN-ILS-DEV] Crashing problem with 1.2.3.1
2008/11/21 Garry Dunn [EMAIL PROTECTED]: To all, We (the Innisfil Public Library) are in need of some help. We've been running Evergreen (for real!) for about 40 days and continue to have unpredictable crashes (on average once or twice a day). It's done it from day one (and did it once on the test system before going live), but it's difficult to reproduce. I run a third test system (much smaller in terms of memory/CPU) but I and can't make it crash. I only have 1 or 2 staff clients connected at a time so it's much lower volume of activity. All three systems (1 live and 2 test) are loaded with the same data.). Here are some details: 1) to fix the problem, we simply issue the stop_all command, then run the 3 start commands (start_router/start_perl/start_c) and everything is fine for a while. We never have to touch PostGres or Apache. 2) the system is running on 1 server (memcache/ejabber/apache/opensrf/postgres/...). Debian Etch OS with Evergreen 1.2.3.1. Postgres 8.1. 4G of RAM on a new Dell PowerEdge server (lots of hard drive space on RAID). The server is not running anything else--just Evergreen. 3) It tends to happen when staff is dealing with a patron who has a lot of holds/books out/fines, although that's not a guarantee. Once the system is restarted, staff can go back to the problem patron and do what they'd like and it will be fine. We've got lots of logs captured from when it happens and I can provide snippets of those if interested. The only thing I see in the logs is a message similar to this, approaching each failure: In osrfsys.log: [2008-11-12 12:15:21] open-ils.circ [ERR :17229:CStoreEditor.pm:86:12265090521716244] editor[1|11434] error starting database transaction [2008-11-12 12:15:21] open-ils.circ [ERR :17229:CStoreEditor.pm:269:12265090521716244] CStoreEditor lost it's connection!! The logs show quite a few error messages like this leading up to the complete crash (sometimes hours before the actual crash). We've been thinking it's a performance issue so we've played a bit with Dan's tweaks for PostGres (found here: http://www.coffeecode.net/archives/156-Tuning-PostgreSQL-for-Evergreen-on-a-test-server.html). It doesn't seem to make a difference (but we've only tried a couple of different combinations). If anyone can provide some guidance about how to further examine/resolve the problem, we'd greatly appreciate it. Hi Garry: Wow, that sounds nasty. I should note that for a production system we would normally recommend running PostgreSQL 8.2 (it's pretty straightforward to configure and compile it from source), but let's not jump yet. I haven't seen this kind of an issue before, but I also haven't been running a system in production like you. That said, here are a few stabs in the dark: Can you monitor the processes to see if there is any strange accumulation over time (like dozens and dozens of postgres backend processes)? And/or monitor system load in general to see if anything strange is going on. Do you have logging turned on at the PostgreSQL level? The PostgreSQL logs might have some interesting information to poke through. It also might be worthwhile running a recent version of settings-tester.pl to give us a sanity check on the versions of all of the prerequisite Perl modules. -- Dan Scott Laurentian University
Re: [OPEN-ILS-DEV] New fr-CA translations
Many thanks for the updated translation, Warren! I also backported the patch to rel_1_4. I did notice that a number of the strings have been marked fuzzy, which means that they won't result in French output when we transform them. In rel_1_4, I did my best for the obviously correct translations, but there are still many strings that need an actual translation; some that need a minor update; and some that might be okay but for which it's beyond my French capabilities to feel confident removing the fuzzy flag. Would you be able to take a look at the fr-CA po files in an editor like POEdit and flip through the fuzzies? There is also a librarian at the University of Ottawa who volunteered to help, if time is tight for you. Dan 2008/11/25 Warren Layton [EMAIL PROTECTED]: Attached is a patch (from svn/ILS/trunk) for the new Evergreen fr-CA translation strings. Most files are now complete although there are a handful of strings for which I'll need to consult a proper translator. Warren (on behalf of NRCan) Developer's Certificate of Origin 1.1 By making a contribution to this project, I certify that: (a) The contribution was created in whole or in part by me and I have the right to submit it under the open source license indicated in the file; or (b) The contribution is based upon previous work that, to the best of my knowledge, is covered under an appropriate open source license and I have the right under that license to submit that work with modifications, whether created in whole or in part by me, under the same open source license (unless I am permitted to submit under a different license), as indicated in the file; or (c) The contribution was provided directly to me by some other person who certified (a), (b) or (c) and I have not modified it. (d) I understand and agree that this project and the contribution are public and that a record of the contribution (including all personal information I submit with it, including my sign-off) is maintained indefinitely and may be redistributed consistent with this project or the open source license(s) involved. Signed-off-by: Warren Layton [EMAIL PROTECTED] -- Dan Scott Laurentian University
Re: [OPEN-ILS-DEV] Yet another function for uescaping UTF-8
On Thu, 2008-11-27 at 21:31 -0800, Scott McKellar wrote: A few days ago I submitted some experimental code for formatting UTF-8 characters into JSON. It was a drop-in replacement for the buffer_append_uescape function, and produced almost identical results. Now I have a new version of that code. Since the first version is not in the repository trunk, I am attaching a full file rather than a patch. The associated header file doesn't need to change. Very cool, Scott. I'll drop it into a local build and give it a run in the current OpenSRF / Evergreen trunk environment. This new version differs in the following way: When it encounters a code point too big to fit into 16 bits (after stripping out the packaging bits), it formats it into a surrogate pair of four hex digits each, rather than a single set of five or six hex digits. In addition, this new version no longer uses buffer_fadd() to format hex values. The code for constructing surrogate pairs is a slightly simplified version of a code snippet found at: http://www.unicode.org/faq/utf_bom.html The code snippet seems to come from a pretty authoritative source. and my modifications were minimal, consisting mostly of collecting a couple of constant expressions into constant values. In the case of the G clef character (U+1D11E), I verified that my code translates it to the correct surrogate pair (\uD834\uDD1E). Unfortunately that's the only character for which I know both the code point and the corresponding surrogate pair. My Google fu has failed me. If someone can provide a sample of code points and the corresponding surrogate pairs, I can do some more testing to make sure that I'm getting the right answers. I started generating some examples for you using Python; maybe the attached script will be helpful to you in generating other ranges, but here's a snippet of what the script generates for the Ancient Greek Numbers range (http://www.utf8-chartable.de/unicode-utf8-table.pl gives lots of alternate representations): 65856 \ud800\udd40 GREEK ACROPHONIC ATTIC ONE QUARTER 65857 \ud800\udd41 GREEK ACROPHONIC ATTIC ONE HALF 65858 \ud800\udd42 GREEK ACROPHONIC ATTIC ONE DRACHMA 65859 \ud800\udd43 GREEK ACROPHONIC ATTIC FIVE 65860 \ud800\udd44 GREEK ACROPHONIC ATTIC FIFTY 65861 \ud800\udd45 GREEK ACROPHONIC ATTIC FIVE HUNDRED 65862 \ud800\udd46 GREEK ACROPHONIC ATTIC FIVE THOUSAND 65863 \ud800\udd47 GREEK ACROPHONIC ATTIC FIFTY THOUSAND 65864 \ud800\udd48 GREEK ACROPHONIC ATTIC FIVE TALENTS 65865 \ud800\udd49 GREEK ACROPHONIC ATTIC TEN TALENTS 65866 \ud800\udd4a GREEK ACROPHONIC ATTIC FIFTY TALENTS 65867 \ud800\udd4b GREEK ACROPHONIC ATTIC ONE HUNDRED TALENTS 65868 \ud800\udd4c GREEK ACROPHONIC ATTIC FIVE HUNDRED TALENTS 65869 \ud800\udd4d GREEK ACROPHONIC ATTIC ONE THOUSAND TALENTS 65870 \ud800\udd4e GREEK ACROPHONIC ATTIC FIVE THOUSAND TALENTS 65871 \ud800\udd4f GREEK ACROPHONIC ATTIC FIVE STATERS 65872 \ud800\udd50 GREEK ACROPHONIC ATTIC TEN STATERS 65873 \ud800\udd51 GREEK ACROPHONIC ATTIC FIFTY STATERS 65874 \ud800\udd52 GREEK ACROPHONIC ATTIC ONE HUNDRED STATERS 65875 \ud800\udd53 GREEK ACROPHONIC ATTIC FIVE HUNDRED STATERS 65876 \ud800\udd54 GREEK ACROPHONIC ATTIC ONE THOUSAND STATERS 65877 \ud800\udd55 GREEK ACROPHONIC ATTIC TEN THOUSAND STATERS 65878 \ud800\udd56 GREEK ACROPHONIC ATTIC FIFTY THOUSAND STATERS 65879 \ud800\udd57 GREEK ACROPHONIC ATTIC TEN MNAS 65880 \ud800\udd58 GREEK ACROPHONIC HERAEUM ONE PLETHRON 65881 \ud800\udd59 GREEK ACROPHONIC THESPIAN ONE 65882 \ud800\udd5a GREEK ACROPHONIC HERMIONIAN ONE 65883 \ud800\udd5b GREEK ACROPHONIC EPIDAUREAN TWO 65884 \ud800\udd5c GREEK ACROPHONIC THESPIAN TWO 65885 \ud800\udd5d GREEK ACROPHONIC CYRENAIC TWO DRACHMAS 65886 \ud800\udd5e GREEK ACROPHONIC EPIDAUREAN TWO DRACHMAS 65887 \ud800\udd5f GREEK ACROPHONIC TROEZENIAN FIVE 65888 \ud800\udd60 GREEK ACROPHONIC TROEZENIAN TEN 65889 \ud800\udd61 GREEK ACROPHONIC TROEZENIAN TEN ALTERNATE FORM 65890 \ud800\udd62 GREEK ACROPHONIC HERMIONIAN TEN 65891 \ud800\udd63 GREEK ACROPHONIC MESSENIAN TEN 65892 \ud800\udd64 GREEK ACROPHONIC THESPIAN TEN 65893 \ud800\udd65 GREEK ACROPHONIC THESPIAN THIRTY 65894 \ud800\udd66 GREEK ACROPHONIC TROEZENIAN FIFTY 65895 \ud800\udd67 GREEK ACROPHONIC TROEZENIAN FIFTY ALTERNATE FORM 65896 \ud800\udd68 GREEK ACROPHONIC HERMIONIAN FIFTY 65897 \ud800\udd69 GREEK ACROPHONIC THESPIAN FIFTY 65898 \ud800\udd6a GREEK ACROPHONIC THESPIAN ONE HUNDRED 65899 \ud800\udd6b GREEK ACROPHONIC THESPIAN THREE HUNDRED 65900 \ud800\udd6c GREEK ACROPHONIC EPIDAUREAN FIVE HUNDRED 65901 \ud800\udd6d GREEK ACROPHONIC TROEZENIAN FIVE HUNDRED 65902 \ud800\udd6e GREEK ACROPHONIC THESPIAN FIVE HUNDRED 65903 \ud800\udd6f GREEK ACROPHONIC CARYSTIAN FIVE HUNDRED 65904 \ud800\udd70 GREEK ACROPHONIC NAXIAN FIVE HUNDRED 65905 \ud800\udd71 GREEK ACROPHONIC THESPIAN ONE THOUSAND 65906 \ud800\udd72 GREEK ACROPHONIC THESPIAN FIVE THOUSAND 65907 \ud800\udd73 GREEK ACROPHONIC DELPHIC FIVE MNAS 65908 \ud800\udd74
Re: [OPEN-ILS-DEV] Upgrading - 1.2.3.0 to 1.4.0.0-RC1
Hey Brandon: 2008/11/28 Uhlman, Brandon EDUC:EX [EMAIL PROTECTED]: Hi, all. I'm in the process of completing a hybrid new install/upgrade of Evergreen 1.4.0.0-RC1. I release that RC2 is out now, but I had RC1 mostly installed from a while ago, and figured that the 1.2-to-1.4 leap is bigger than the leap within RC2, and that I might as well finish what I started. By 'hybrid' installation, I mean that I'm completing a fresh install of Evergreen 1.4.0.0-RC1 using the 'new install' instructions on a new server, but I'm pointing at a legacy dataset from Evergreen 1.2.3.0 sitting on a separate server. I ran eg_db_config.pl to do the bootstrapping stuff, and ran src/sql/Pg/1.2.3-1.4-upgrade-db.sql, but I notice a (metric) ton(ne) of stuff seems to be still missing from the DB schema - notably, orgunit lassos from 005.schema.actors.sql, and all the in-db i18n stuff, from a multitude of files. Yeah. This is one of the reasons we needed RC2 - the upgrade SQL script in RC1 was not at all ready for upgrades (other than a few of the minor schema changes that I had introduced). We need to be more clear when we push out a release candidate whether it's intended to support migration or just give people a chance to try out new features. Is there an unwritten step that I should be doing? Go directly to RC2. Do not stop at RC1; do not collect $200. -- Dan Scott Laurentian University
[OPEN-ILS-DEV] PostgreSQL 8.3 testing of trunk
Over the past few days I've been going through the install and configure steps with PostgreSQL 8.3 and so far, so good - I used Vandelay to import a set of records successfully and can retrieve them via the staff client. Lots more to test out, of course, but just wanted to say yay so far. -- Dan Scott Laurentian University
Re: [OPEN-ILS-DEV] buffer_chomp()
Hi Scott: 2008/12/1 Scott McKellar [EMAIL PROTECTED]: The other day I noticed the new buffer_chomp function. It removes the last character of a growing_buffer, and returns the new length. snip I can incorporate these two changes into my next patch to utils.[ch] -- which will probably be soon, because I want to get rid of the new buffer_append_uescape function in favor of the newer function buffer_append_utf8(). Oh, uh - I think I already checked in that change, including the required change to osrf_json_object.c and the Makefile, as part of changeset 1516 (http://svn.open-ils.org/trac/OpenSRF/changeset/1516). -- Dan Scott Laurentian University
Re: [OPEN-ILS-DEV] Client Build Question
2008/12/2 Melissa Lefebvre [EMAIL PROTECTED]: Hi, I'm new to Evergreen and am trying to get up a test server using 1_4_0_0-rc2, on Debian Etch. I've followed the instructions to install EG, corrected the errors that I came across when running the settings-tester.pl, am able to srfsh on the server with no errors, the OPAC page loads within a browser (although I can't actually do anything like login to My Account – I get a javascript void error) Sounds like autogen.sh hasn't been run. You might as well stop here and fix this problem first (probably should add a check for that to settings-tester.pl). but my question is how do I connect my Evergreen Staff Client on a Windows machine to the server? I tried the instructions located at http://open-ils.org/dokuwiki/doku.php?id=evergreen-user:installing_and_running_the_staff_clients=staff Which staff client did you download or set up on your Windows machine? What instructions on that page did you follow? and it seems to have done something (no errors or warning messages) but when I try to connect via the staff client I can't get passed the testing server stage (message There was an error testing this hostname). I am not sure what I am missing although I have a feeling it's something really simple and obvious. Does the hostname need to have a particular path listed or just the hostname? I've tried just the hostname and also just the server's IP. Are you entering http://hostname; or hostname? The latter is what you need to enter. Perhaps we should add a check in the client for :// to warn about invalid hostnames, or to ignore the protocol part. As a side note, I can get to the Local System Administration via a browser on a windows machine, so I think EG is install correctly. That's a positive sign, at least. -- Dan Scott Laurentian University
Re: [OPEN-ILS-DEV] problem importing
Hi Grant: What version of XML::LibXML and XML::LibXSLT are reported by settings-tester.pl? There were known problems with XML::LibXML 1.66, 1.69 (the most up to date version from CPAN) is recommended. And geez, what are you doing importing into 1.2.2.0? Dan 2008/12/5 Grant Johnson [EMAIL PROTECTED]: Hey all, I can't import a set of records in EG 1.2.2.0. Works fine in 1.2.2.3 VM. # perl marc2bre.pl seems to generate the .bre sucessfully ... but I get the following when I run # perl direct_ingest.pl Any solutions? Couldn't process record: Undefined namespace prefix xmlXPathCompiledEval: evaluation failed /*--S bre--*/[null,null,null,null,null,t,now,1,f,now,1,null,608862,IMPORT-1228505905.86601,record xmlns:xsi=\http://www.w3.org/2001/XMLSchema-instance\; xsi:schemaLocation=\http://www.loc.gov/MARC21/slim http://www.loc.gov/ standards/marcxml/schema/MARC21slim.xsd\ xmlns=\http://www.loc.gov/MARC21/slim\;leader01357nam 2200325 a 4500/leadercontrolfield tag=\001\PM004006/controlfieldcontrolfield tag=\003\VaCvNLX/controlfieldcontrolfield tag=\005\20081117132346.0/controlfieldcontrolfield tag=\006\m d/controlfieldcontrolfield tag=\007\cr a m /controlfieldcontrolfield tag=\008\081117s2008vaufs eng d/controlfielddatafield tag=\020\ ind1=\ \ ind2=\ \subfield code=\a\9781570855092 (web)/subfield/datafielddatafield tag=\040\ ind1=\ \ ind2=\ \subfield code=\a\VaCvNLX/subfield/datafielddatafield tag=\041\ ind1=\0\ ind2=\ \subfield code=\a\ger/subfield/datafielddatafield tag=\041\ ind1=\0\ ind2=\ \subfield code=\a\dut/subfield/datafielddatafield tag=\100\ ind1=\1\ ind2=\ \subfield code=\a\Spinoza, Benedictus de,/subfieldsubfield code=\d\1632-1677./subfield/datafielddatafield tag=\245\ ind1=\1\ ind2=\0\subfield code=\a\Benedict de Spinoza, opera /subfieldsubfield code=\h\[electronic resource]./subfield/datafielddatafield tag=\246\ ind1=\1\ ind2=\ \subfield code=\a\Spinoza, opera/subfield/datafielddatafield tag=\260\ ind1=\ \ ind2=\ \subfield code=\a\Charlottesville, Va.:/subfieldsubfield code=\b\InteLex Corporation,/subfieldsubfield code=\c\2008./subfield/datafielddatafield tag=\490\ ind1=\1\ ind2=\ \subfield code=\a\Past masters/subfield/datafielddatafield tag=\506\ ind1=\ \ ind2=\ \subfield code=\a\Access restricted by license agreement./subfield/datafielddatafield tag=\520\ ind1=\2\ ind2=\ \subfield code=\a\The InteLex Past Masters database Benedict de Spinoza is the complete electronic edition of the complete works of Spinoza in Latin and Dutch based on a corrected version of the authoritative edition of Carl Gebhardt./subfield/datafielddatafield tag=\534\ ind1=\ \ ind2=\ \subfield code=\p\Transcribed from:/subfieldsubfield code=\a\Spinoza, Benedictus de/subfieldsubfield code=\t\Opera, im auftrag der Heidelberger akademie der wissenschaften herausgegeben/subfieldsubfield code=\c\Heidelberg: C. Winter, 1925./subfield/datafielddatafield tag=\538\ ind1=\ \ ind2=\ \subfield code=\a\Mode of access: World Wide Web./subfield/datafielddatafield tag=\650\ ind1=\ \ ind2=\0\subfield code=\a\Philosophy./subfield/datafielddatafield tag=\650\ ind1=\ \ ind2=\0\subfield code=\a\Ethics./subfield/datafielddatafield tag=\690\ ind1=\ \ ind2=\ \subfield code=\a\Research Database/subfield/datafielddatafield tag=\700\ ind1=\1\ ind2=\ \subfield code=\a\Gebhardt, Carl./subfield/datafielddatafield tag=\830\ ind1=\ \ ind2=\0\subfield code=\a\Past masters/subfield/datafielddatafield tag=\856\ ind1=\4\ ind2=\0\subfield code=\u\http://rlproxy.upei.ca/login?url=/xtf/view?docId=spinoza_la/spinoza_la.xml/subfieldsubfield code=\z\Access this ebook via InteLex/subfieldsubfield code=\y\Access this ebook via InteLex/subfield/datafielddatafield tag=\901\ ind1=\ \ ind2=\ \subfield code=\a\PM004006/subfieldsubfield code=\b\System/subfield/datafield/record,null,null,System,PM004006]/*--E bre--*/ *** F. Grant Johnson Systems Coordinator Robertson Library University of Prince Edward Island -- Dan Scott Laurentian University
Re: [OPEN-ILS-DEV] problem importing
2008/12/5 Grant Johnson [EMAIL PROTECTED]: Sorry... 1.2.2.3 in a 1.2.2.0 Open-ILS folder... I think... :-) XML::LibXML version 1.66 XML::LibXML::XPathContext version 1.66 XML::LibXSLT version 1.59 Yup, install the updated versions from CPAN and you should be a lot happier. As root: cpan XML::LibXML XML::LibXSLT -- Dan Scott Laurentian University
Re: [OPEN-ILS-DEV] url syntax
On Sun, 2008-12-07 at 20:31 -0400, Grant Johnson wrote: I know I've asked before ... and working with Dan and Godmar we were able to get LibX configured for Evergreen. Is there a list of acceptable/required parameters and what they are? For example: http://islandpines.roblib.upei.ca/opac/en-US/skin/roblib/xml/rresult.xml?rt=keywordtp=keywordt=artl=4d=0f=av=3 l = level t = search text rt = search type tp = search type d = depth ??? av = f = I put the notes from that session on the wiki at: http://open-ils.org/dokuwiki/doku.php?id=opac:dynamic_api This could definitely stand to be extended and reformatted (probably into a table). Dan
[OPEN-ILS-DEV] Translations status (was: Call for Evergreen translations)
Hi all: I'm back after a one-month hiatus and interested in the state of the various translation efforts. I'm especially interested in submissions of updated or new translations; we want to have a chance to test building, bundling, and running Evergreen with your language. We'd much rather have early access to a partial translation, so we can catch potential problems with our build process or tools in time to make a difference for the final release. I should note that we have updated a handful of strings since the call for translations to fix some problems that we found; also, we added a few new strings where we found hardcoded strings that had been missed in the templates. At this time we have in the repository: * Armenian - hy-AM (full translation, with the exception of updates since September) * English (United States) - en-US (full translation) * English (Canada) - en-CA (full translation) * French (Canada) - fr-CA (full translation, with the exception of a few updates since late November) People have indicated they are working on the following translations: * Brazilian Portugese - pt-BR * Czech - cs-CZ * Georgian - ka-GE * Simplified Chinese - zh-CN If you have run into any problems with the tools or the PO files, please let me know and I will try to help resolve the problem(s). If you missed the first call and would like to contribute to a different language, that's great - just let me and/or the list know! If you want to help out with one of these languages, I'll be happy to try to coordinate efforts with the other translators. When you contribute a translation, partial or full, please include the Developer's Certificate of Originality (http://open-ils.org/documentation/contributing.html#DCO) in your email. Thanks! Dan 2008/11/19 Dan Scott deni...@gmail.com: Evergreen 1.4.0.0, release candidate 2, was made available for download from http://evergreen-ils.org/downloads.php today. This release marks the culmination of a significant effort to enable translation in every public and staff interface in Evergreen - and at this point, the Evergreen development team plans to minimize any further changes to translatable strings before the 1.4.0.0 final release. We would like to invite new translations. Evergreen currently includes the following translations: * Armenian - hy-AM * French (Canadian) - fr-CA However, as new interfaces such as the MARC importer/exporter have been developed and existing interfaces have been enhanced, these translations are in need of an update. Evergreen maintains all translatable strings in GNU gettext (POT/PO) format. If you would like to contribute a new translation: 1. Download and extract the files from Evergreen 1.4.0.0 RC2 (http://evergreen-ils.org/downloads.php) 2. Create a new set of PO files based on the POT files in the build/i18n/en-US/ directory 3. Use a gettext-aware editor like POEdit (http://www.poedit.net/ for Windows or Linux) to translate the files 4. Send the translated files to the Evergreen Development mailing list (http://evergreen-ils.org/listserv.php) with a Developer's Certificate of Origin (DCO - http://open-ils.org/documentation/contributing.html#DCO) in the body of your email. If you just want to translate the public interface (catalogue), you only need to translate the files opac.dtd.pot and db.seed.pot. If you have any questions about the translation process, or notice problems, please send a message to the Evergreen Development mailing list and we'll do our best to answer your question or correct our mistakes. Thank you, in advance, for helping Evergreen enter a multilingual world! -- Dan Scott Laurentian University -- Dan Scott Laurentian University
Re: [OPEN-ILS-DEV] more fun with import_demo
2009/1/14 Dan Scott deni...@gmail.com: I would _swear_ there used to be a db_port option in marc2bre.pl, but I'll remove it from import_bibs.sh. That'll fix up your problem (and the problem of anyone else running the import demo). I swore in vain - it was never there. I have now added the db_port option to marc2bre.pl in trunk. -- Dan Scott Laurentian University
Re: [OPEN-ILS-DEV] nevermind: re import_demo
2009/1/14 John Fink john.f...@gmail.com: Hey folks, Judicious removal of the deprecated db_port flag resulted in everything going ahead nicely, after Dan knocked some sense into me by letting me know that the import demo should be run on the database server directly. As always, Dan saves the day. Recommended changes to import_demo trunk -- remove db_port references, make explicit the need to run on the db server if db and frontend are on different boxes. I'll submit a new version if it'll help. :) Heh, right beside you - I added the db_port option to marc2bre.pl instead, and did update the import demo README with some words about loading sample_marc.sql and friends directly on the database server. I've also updated the tarball for the import demo with the new versions of all the files. Thanks a ton for running through this and for helping improve Evergreen! -- Dan Scott Laurentian University
Re: [OPEN-ILS-DEV] Translations status: it_IT
2009/1/16 Luca Brivio luca.bri...@lem.coop: (not replying within the original thread because I've subscribed just now) I'm working on an Italian translation. If I can't reach its completion in the next few days, I'll send you a partial one to be tested. Thanks for the heads-up, Luca! -- Dan Scott Laurentian University
Re: [OPEN-ILS-DEV] Apache error
Hi George: 2009/1/21 Duimovich, George george.duimov...@nrcan-rncan.gc.ca: I couldn't find any reference to this but wonder if anybody has any thoughts on how to fix. Running ver 1.4RC2 Call up the default search screen and get this Error message: OK The server encountered an internal error or misconfiguration and was unable to complete your request. etc. Some observations - Apache is running ok, able to confirm with other local site (vuFind). - settings-tester.pl reports all is ok - some apache error.log snips below Snips from error.log --- [Wed Jan 21 11:51:13 2009] [error] [client my ip removed ] XMLENT XML Parse Error: syntax error at line 1: parsing /openils/var/web/opac/skin/default/xml/index.xml: data [an error occurred while processing this directive] ... [Wed Jan 21 11:51:13 2009] [debug] core.c(3748): [client my ip removed ] (500)Unknown error 500: default_handler: ap_pass_brigade returned 500 … [Wed Jan 21 11:51:14 2009] [error] [client my ip removed ] XMLENT XML Parse Error: mismatched tag at line 1108: parsing /openils/var/web/opac/skin/default/xml/home/index_body.xml: data \n/body\n\n\n --- I have not made any modifications to index.xml index_body.xml, etc. This kind of error usually means that an entity is missing from /openils/var/web/opac/locale/LOCALE/opac.dtd If you're looking at the en-US OPAC, then there should be no missing entities. One tricky source of errors is that when mod_deflate is enabled, files like the DTD file can be gzip-compressed but mod_xmlent doesn't know how to decompress the file before substituting the entities. So I would start by trying to disable mod_deflate, then force-reload Apache and try again: As root: a2dismod deflate /etc/init.d/apache2 force-reload You may also need to clear your browser cache. -- Dan Scott Laurentian University
Re: [OPEN-ILS-DEV] Problem when running srfsh
2009/1/23 david.jo...@canadabusiness.ca: Hi All I have a clean install on ubuntu 8.04.1. I had a problem with libdbi, which I have re-ran the makefile. When I run srfsh I get unable to bootstrap client error (attached srfsh.log). When ran, settings_tester.pl generates no errors ( see attached tester.log). Srfsh.log indicated an error from Jabber, but I am at a loss to what my next steps would be. Any assistance greatly appreciated. Thanks David Hi David: Just looking at the srfsh.log - you can't use 127.0.0.1 as a hostname or domain name; try localhost instead (or, if you're installing OpenSRF 1.0.2 / Evergreen 1.4, public.localhost for accessing the publicly exposed OpenSRF services if you followed the OpenSRF README examples). -- Dan Scott Laurentian University
Re: [OPEN-ILS-DEV] new opensrf install can't connect
2009/2/3 Raymond Norton ad...@lctn.org: Bump The instructions said to send a post to this list if I was having trouble with installation. Any ideas? What version of OpenSRF do you have installed? Do the users, passwords, and domains that you defined in opensrf_core.xml match the domains defined in ejabberd.cfg and the users you registered with ejabberdctl? As an aside, if someone has some time, an OpenSRF config settings testing script that walked through each user defined in opensrf_core.xml and that performed a connection test with the corresponding credentials would probably save a lot of troubleshooting grief down the road. There's some code that could be cribbed from the Evergreen settings-tester.pl script for this purpose. -- Dan Scott Laurentian University
Re: [OPEN-ILS-DEV] new opensrf install can't connect
2009/2/3 Raymond Norton ad...@lctn.org: What version of OpenSRF do you have installed? Do the users, passwords, and domains that you defined in opensrf_core.xml match the domains defined in ejabberd.cfg and the users you registered with ejabberdctl? OpenSRF 1.0.2 on Ubuntu Intreped 8.10 Ah, you need to upgrade to OpenSRF 1.0.3 for multidomain support - sorry about that. That's probably your problem right there. It sounds like you've done everything else right. Is this info exactly what I should have in /etc/hosts, or should it be 127.0.0.1? 127.0.1.2 public.localhostpublic 127.0.1.3 private.localhost private Yep, looks good. I went through the docs again, and believe I have everything correct in opensrf_core.xml. I don't see the same info in /usr/share/ejabbered/ejabberd.cfg. I am guessing it is somehow supposed to be updated with the proper info using ejabberdctl. I ran the following a second time, but it said the users are already registered. Uh - actually, you need to see it in /etc/ejabberd/ejabberd.cfg. The /usr/share/... path is just an example ejabberd.cfg file. -- Dan Scott Laurentian University
Re: [OPEN-ILS-DEV] new opensrf install can't connect
2009/2/4 Raymond Norton ad...@lctn.org: Uh - actually, you need to see it in /etc/ejabberd/ejabberd.cfg. The /usr/share/... path is just an example ejabberd.cfg file. No info in there either. Maybe that will change with the upgrade of opensrf Hmm. I'm not sure I understand. If you're following the directions at http://open-ils.org/dokuwiki/doku.php?id=opensrf:1.0.3:install it pretty clearly tells you to edit /etc/ejabberd/ejabberd.cfg yourself... -- Dan Scott Laurentian University
Re: [OPEN-ILS-DEV] new opensrf install can't connect
2009/2/4 Raymond Norton ad...@lctn.org: Hmm. I'm not sure I understand. If you're following the directions at http://open-ils.org/dokuwiki/doku.php?id=opensrf:1.0.3:install it pretty clearly tells you to edit /etc/ejabberd/ejabberd.cfg yourself... I have been going here: http://open-ils.org/dokuwiki/doku.php?id=server_installation Then here: http://open-ils.org/dokuwiki/doku.php?id=opensrf:1.0.1:ubuntu810:install (because I have intrepid 1.8.10) Okay, I'll update the server_installation page to point directly to 1.0.3; thanks. Then here: http://open-ils.org/dokuwiki/doku.php?id=opensrf:1.0.2:install (But now the instructions are gone, and it says to install 1.0.3) Right - I changed that when I saw you were installing an old version of the code. I will follow the instructions on the new link. What do I have to undo, so the new install works? You don't have to undo anything. All of the instructions are the same: http://open-ils.org/dokuwiki/doku.php?id=opensrf:1.0.2:installrev=1232916388 shows you what the 1.0.2 instructions had before the edit - and it included instructions to edit /etc/ejabberd/ejabberd.cfg. The only addition to the 1.0.3 instructions is to add /openils/lib to the system dynamic library path. -- Dan Scott Laurentian University
Re: [OPEN-ILS-DEV] new opensrf install can't connect
2009/2/4 Raymond Norton ad...@lctn.org: Should I be installing the Hardy Heron release on Intrepid? If you mean, should I follow the install instructions that say they're for Hardy Heron on my Intrepid system, the answer is yes, for the most part. When you install the prerequisites, use ubuntu-intrepid rather than ubuntu-hardy as your Make target. I follow these instructions (http://open-ils.org/dokuwiki/doku.php?id=server:1.4.0.1:ubuntu804:install) on my Ubuntu 8.10 Intrepid Ibex system without any noticeable problems. -- Dan Scott Laurentian University
Re: [OPEN-ILS-DEV] new opensrf install can't connect
2009/2/4 Raymond Norton ad...@lctn.org: Directing the output into a log file and attaching the log file would work for me. Here you go. Hmm. Can't figure out why you're running into that compile problem. Based on configure for libdbi-drivers here (also Ubuntu 8.10), the PostgreSQL include file test checks for libpq-fe.h in /usr/include/postgresql - and libpq-fe.h is supposed to be installed as part of the libpq-dev package. -- Dan Scott Laurentian University
Re: [OPEN-ILS-DEV] Opensrf install question
2009/2/10 Dale Arntson a...@uchicago.edu: Could someone take a look at this? I read through the code, and it seems like my config files are messed up, in particular the opensrf_core.xml. I am attaching these files so that someone more knowledgeable than I can take a look at them. Well, one thing is that mod_offline should be commented out in ejabberd.cfg. -- Dan Scott Laurentian University
Re: [OPEN-ILS-DEV] Opensrf install question
2009/2/10 Dale Arntson a...@uchicago.edu: Could someone take a look at this? I read through the code, and it seems like my config files are messed up, in particular the opensrf_core.xml. I am attaching these files so that someone more knowledgeable than I can take a look at them. Also, in opensrf.xml you still have: dbfile/different/path/to/dbfile/persist.db/dbfile in the application setting override section. This shouldn't cause the problem you're reporting, but it will prevent the opensrf.persist application from working (except in the unlikely case that /different/path/to/dbfile/persist.db is a real path on your system). -- Dan Scott Laurentian University
Re: [OPEN-ILS-DEV] osrf_router error over and over.....
2009/2/10 Hunt, Phil h...@nelinet.net: Hi I have evergreen running, but it seems a bit slow, so I looked and see opensrf_router is taking 95%+ on the cpu, and syslogd too. So I look at syslog and sure enough it is GIG long, with the following error over and over.. Feb 10 06:50:26 LNXOPNSRC1 router: [DEBG:16990:osrf_router.c:117:] Top router socket is active: 4 Feb 10 06:50:26 LNXOPNSRC1 router: [DEBG:16990:transport_session.c:155:] socket_wait returned error code -1 Feb 10 06:50:26 LNXOPNSRC1 router: [DEBG:16990:transport_client.c:142:] session_wait returned failure code -1: setting error=1 This isn't an error, it's the result of having your logging levels set to DEBUG (which is an insanely verbose logging level). Adjust the values in /openils/conf/opensrf_core.xml to something a bit more sane (in EG 1.4.0.2 we will set them to 3 (INFO) in the example config files, I believe) and restart. While you're at it, you'll probably want to adjust the default logging levels in /etc/apache2/sites-available/eg.conf from debug to something like warn instead (this has also been changed in the EG 1.4.0.2 default config files). -- Dan Scott Laurentian University
Re: [OPEN-ILS-DEV] Opensrf install question
2009/2/10 Hunt, Phil h...@nelinet.net: Ok That's what I thought. In the step by step for Ubuntu 8.04 and EG 1.4.0.1, it states to change private and public localhost lines to localhost 'throughout' for a single server install. Hmm, if it did say that somewhere, it certainly doesn't now. Are you working from a printed (old) set of instructions by any chance? The most recent (and most correct) instructions are at: * http://open-ils.org/dokuwiki/doku.php?id=opensrf:1.0:install * http://open-ils.org/dokuwiki/doku.php?id=server:1.4.0:install ... although they are for the upcoming releases, respectively. -- Dan Scott Laurentian University
Re: [OPEN-ILS-DEV] Upgrade 1.2.3 to 1.4 problem
2009/2/10 Garry Dunn ga...@trellisconsulting.ca:
I'm in the process of setting up a new test server using Ubuntu 8.04
and the instructions on the website. I can get everything running with
a blank database (with some minor deviations to get PostGres8.2 compiled
from source--stow was giving a 'conflict', so I installed without it). the
staff client and OPAC both work fine (albeit with no data).
Right, stow complains if other stuff is already in conlicting
/usr/local/ directories (/usr/local/man from installing CPAN packages,
for example). It's a nice tool, but not necessary.
Now I want to get our data from our live 1.2.3.1 system into this
test system. Our live system is running PostGres 8.1 (slap me--we
didn't know we were supposed to run 8.2!). I've got a PG_DUMP of the
entire database. Before importing that, I create a blank database and
run the 3 'createlang' commands and the tablefunc/tsearch2/pgxml
contribs. The PG_DUMP imports into this new PG 8.2/Ubuntu system without
major problems (the warnings are about the tsearch2 tables existing
already--which makes sense, I thought it might be wise to have the 8.2
tsearch2 version, rather than the 8.1 that will get imported).
Then I try running the upgrade script. After a bunch of successful
updates to the database, it fails with:
psql:/home/opensrf/Evergreen-ILS-1.4.0.1/Open-ILS/src/sql/Pg/1.2.3-1.4-upgrade-db.sql:1586:
ERROR: syntax error at or near IF LINE 1:
...('MAXFINES','LONGOVERDUE') OR stop_fines IS NULL) IF $4 =...
^
QUERY: SELECT COUNT(*) FROM action.circulation WHERE usr = $1 AND (
$2 IS NULL OR ( $2 IS NOT NULL AND circ_lib IN ( SELECT * FROM
explode_array( $3 ) ))) AND checkin_time IS NULL AND (stop_fines IN
('MAXFINES','LONGOVERDUE') OR stop_fines IS NULL) IF $4 = $5 THEN
$6 := 'config.circ_matrix_test.max_items_out'
CONTEXT: SQL statement in PL/PgSQL function item_user_circ_test near
line 105
This is one of the fixes that went into 1.4.0.2.
I'm wondering if I'm going at this in the right way. It's probably not the
normal upgrade path, but we like the idea of having a nice clean install and
bringing our data into that.
It sounds like a reasonable upgrade path to me. You will need to
switch from a single-domain to a multi-domain OpenSRF configuration,
FYI.
Any comments/suggestions?
Get 1.4.0.2 and you should be okay. The upgrade path hasn't been
heavily tested, so we would appreciate any further findings that you
might have.
--
Dan Scott
Laurentian University
[OPEN-ILS-DEV] Evergreen 1.4.0.2 is available
After a lengthy period of release candidates through Fall 2008 and quiet 1.4.0.0 and 1.4.0.1 releases in January 2009, the Evergreen development team is pleased to announce the immediate availability of Evergreen 1.4.0.2 and OpenSRF 1.0.4 for download from http://open-ils.org/downloads.php This release adds functionality, configuration, and usability improvements including, but not limited to, the following areas: * Improved administrative interfaces for defining organizations and permissions * Internationalization and localization (Armenian (hy-AM), Canadian French (fr-CA), Canadian English (en-CA), and Czech (cs-CZ)) * Multi-source Z39.50 search for staff * Pre-overdue (reminder) notices * SRU/Z39.50 server * Publication date filtering in advanced search * Preferred-language setting at both system and organizational level for search results * Web-based batch record importer/exporter Our deepest thanks to everyone in the Evergreen community who contributes documentation, patches, bug reports, ideas, and lends their voice to the project. You help make Evergreen a far stronger library system than it could ever be without you. -- Dan Scott Laurentian University
Re: [OPEN-ILS-DEV] Spoke too soon - can't login using srfsh either
2009/2/11 Hunt, Phil h...@nelinet.net:
I cannot login to my admin account on the client, or with srfsh.
Client gives error previously shown
srfsh says:
Received Data: {
ilsevent:1000,
textcode:LOGIN_FAILED,
desc:User login failed,
pid:5974,
stacktrace:oils_auth.c:473
}
So, how did my admin get hosed? And better yet, how can I add it back?
Must be sql to add the admin back
If it's not just a matter of using open-ils as the password and you
really do need to reset your password for the admin user, see the
top entry on
http://open-ils.org/dokuwiki/doku.php?id=scratchpad:random_magic_spells
--
Dan Scott
Laurentian University
Re: [OPEN-ILS-DEV] Translation for pt-BR completed
Hi Job! 2009/2/12 Job D R Borges j...@nupelia.uem.br: Hello Translation for Brazilian Portuguese are finish. the compressed directory (pt-BR) with all po files are attached with this email. Fabulous! Your translation appears to be almost perfectly clean, at least from a build perspective. There are just a few things to clean up in lang.dtd.po; I have attached my build log file for your reference. If you want to set up your own i18n build environment to test out your work in the future (at least this far), the required packages for Debian or Ubuntu are listed at the top of http://open-ils.org/dokuwiki/doku.php?id=evergreen-admin:customizations:i18n Here's what I did, starting with a fresh checkout of the Evergreen rel_1_4_0 branch: 1. Extracted the files to the Evergreen build/i18n/po/ directory to create a new build/i18n/po/pt-BR directory filled with your .po files. 2. Ran make newpot to ensure that the English version of all of the files was up to date. 3. Ran make LOCALE=pt-BR install to generate the required output files. I also captured the output of this command to check for errors, and found that there were a handful of strings in lang.dtd.po that contain ampersand characters (). Ampersands have a special meaning in the generated DTD file - they define entities - so you need to replace them with amp; instead to mean a literal ampersand. Before I add your translation to the repository, could you please send us a Developer's Certificate of Origin (DCO 1.1) as linked to and described at http://open-ils.org/documentation/contributing.html#Submitting%20a%20Patch ? I would like to follow our regular process for code contributions for translations as well. Thanks so much for this, Job - it looks great, and I'm looking forward to having pt-BR as part of Evergreen! -- Dan Scott Laurentian University
Re: [OPEN-ILS-DEV] no contrib folder to work from
2009/2/13 Mike Rylander mrylan...@gmail.com: On Fri, Feb 13, 2009 at 4:38 PM, Raymond Norton ad...@lctn.org wrote: I gave up on Intrepid, and am installing on Hardy now, hoping to get my first Evergreen install to work. I followed the instructions from the cheat sheet link on installing 8.2 from source. That all went fine, and postgresql is started. I have come to the following section in the instructions Issue the following commands on your PostgreSQL server: I do have /usr/share/postgresql/8.2, but all that resides in there is man. I searched for the contrib folder, but am not finding it. I ran make clean, and started over, but still do not have a contrib folder. In the source directory where you built Postgres there will be a contrib directory. cd into that and issue `make all install` to install the contrib modules. You should be set after that. Right, and if you followed the cheat sheet instructions then you will already have done this and the contrib modules will be in /usr/local/share/contrib instead of /usr/share/postgresql/8.2/contrib - which conflicts with the instructions as they currently stand because they were written for a packaged version of PostgreSQL. So, adjust accordingly - when I get a chance, I'll add a qualifier to that step that says if you followed the PostgreSQL install cheat sheet... -- Dan Scott Laurentian University
Re: [OPEN-ILS-DEV] Update needed for opensrf Makefile.install
2009/2/15 Carl T. Miller c...@carltm.com: Carl T. Miller wrote: After the gunzip command, there is no file named $(EJABBERD_PKG).gz. The chmod command should be updated to: chmod u+x $(EJABBERD_PKG) After making this change, the make command finishes with this output: make: *** No rule to make target `install', needed by `centos'. Stop. Is this a problem? Yep, it's a problem. Just remove that target from the centos: install target, so the line looks like: centos: install_centos_rpms install_ejabberd install_libmemcache install_libxml2 install_libxslt install_centos_perl create_ld_local I've updated Makefile.install in the source code repository. Sorry for the problems with the prerequisite installer - I had been trying to put together Red Hat / CentOS prerequisites some time ago, but when it became clear that we would be able to proceed with Debian or Ubuntu I abandoned the effort, and some of the refactoring that I've done since then has (obviously) gone untested on Red Hat / CentOS. Thanks for the problem reports, and please keep letting the list know your findings with CentOS. I know there are other institutions who have policies of only running Red Hat systems, and it would be great to make that adoption path nice and smooth. -- Dan Scott Laurentian University
Re: [OPEN-ILS-DEV] Evergreen install: Very close!
2009/2/16 Dale Arntson a...@uchicago.edu:
Hi all,
My Redhat 5 install is nearly there. But I have one more problem I would
like to pose to the dev-list. When I login as admin using srfsh, the login
succeeds, but then immediately times out. Im not sure how to read the logs
on this one. It seems like there may be a timeout set to 0 somewhere that
shouldn't be there. But I can't find any such timeout. But maybe some on the
list could comment?
Thanks,
-dale
srfsh# login admin open-ils
Received Data: 772300b1de59f02903567d6aa7ae300e
Request Completed Successfully
Request Time in seconds: 0.002844
Received Data: {
ilsevent:0,
textcode:SUCCESS,
desc: ,
pid:5440,
stacktrace:oils_auth.c:312,
payload:{
authtoken:19422d7157c7fee398eb9aa897a12624,
authtime:420.00
}
}
Request Completed Successfully
Request Time in seconds: 0.121702
Login Session: 19422d7157c7fee398eb9aa897a12624. Session timeout:
420.00
Are you interpreting the Session timeout: 420.00 statement as an
indication that your session has timed out? That's actually an
indication that your session will timeout in 420 seconds. It sounds
like you might be able to declare success...
--
Dan Scott
Laurentian University
Re: [OPEN-ILS-DEV] OpenSRF error
2009/2/16 Carl T. Miller c...@carltm.com: Thanks, Dan. Adding libmemcache was all it needed. I'm stuck at another error that I don't understand. How do I fix an undefined reference to rpl_malloc? Here is the pertinent output from make. Making all in libopensrf make[2]: Entering directory `/opt/opensrf/OpenSRF-1.0.4/src/libopensrf' /bin/sh ../../libtool --tag=CC --mode=link gcc -D_LARGEFILE64_SOURCE -DNDEBUG -pipe -g -Wall -O2 -fPIC -I/opt/opensrf/OpenSRF-1.0.4/include/ -I/usr/include/libxml2/ -I/usr/include/apache2 -I/usr/include/apr-1.0 -DASSUME_STATELESS -DOSRF_STRICT_PARAMS -rdynamic -fno-strict-aliasing -DOSRF_JSON_ENABLE_XML_UTILS -g -O2 -R /openils/lib -o opensrf-c opensrf.o -lxml2 -ldl -lmemcache -lopensrf -lxml2 -lreadline -lncurses -lmemcache -ldl gcc -D_LARGEFILE64_SOURCE -DNDEBUG -pipe -g -Wall -O2 -fPIC -I/opt/opensrf/OpenSRF-1.0.4/include/ -I/usr/include/libxml2/ -I/usr/include/apache2 -I/usr/include/apr-1.0 -DASSUME_STATELESS -DOSRF_STRICT_PARAMS -rdynamic -fno-strict-aliasing -DOSRF_JSON_ENABLE_XML_UTILS -g -O2 -o .libs/opensrf-c opensrf.o /opt/opensrf/OpenSRF-1.0.4/src/libopensrf/.libs/libopensrf.so -lxml2 -lreadline -lncurses -lmemcache -ldl -Wl,--rpath -Wl,/openils/lib /opt/opensrf/OpenSRF-1.0.4/src/libopensrf/.libs/libopensrf.so: undefined reference to `rpl_malloc' collect2: ld returned 1 exit status make[2]: *** [opensrf-c] Error 1 make[2]: Leaving directory `/opt/opensrf/OpenSRF-1.0.4/src/libopensrf' Any suggestions? Ugh. http://wiki.buici.com/wiki/Autoconf_and_RPL_MALLOC ? -- Dan Scott Laurentian University
Re: [OPEN-ILS-DEV] Errors at end of install
2009/2/17 Raymond Norton ad...@lctn.org: /etc/init.d/apache2 restart * Restarting web server apache2 httpd (no pid file) not running (98)Address already in use: make_sock: could not bind to address 0.0.0.0:443 no listening sockets available, shutting down Unable to open logs netstat -an -t | grep 443 Does not return anything. Got that part fixed. There was a ports.conf in /etc/apache2, as well as a line in eg.conf telling it to listen on 443. The two conflicted. Right, that's step 7.II of http://open-ils.org/dokuwiki/doku.php?id=server:1.4.0:install -- Dan Scott Laurentian University
[OPEN-ILS-DEV] ILS-Contrib repository for Project Conifer?
Hello: Just wondering if Project Conifer could have an ILS-Contrib repository to store its data migration tweaking scripts, circulation rules scripts, etc. We need a central repository for our work anyway, and thought that future academic institutions might find something of value in picking through our scraps... -- Dan Scott Laurentian University
Re: [OPEN-ILS-DEV] [OPEN-ILS-GENERAL] Thanks UPEI! Google Book Preview patch integrated into trunk
2009/3/8 Bill Ott b...@grpl.org: Dan Scott wrote: I think it'll need more than just I18n, unfortunately. It's currently set up to blow away the excerpt added content that other AC modules provide, I don't remember seeing any excerpts provided by Syndetics so far - if they do provide excerpts, perhaps they are few and far between for academic content at least - which is why I wasn't worried about the blowing away behaviour. I knew I'd seen at least one. Had to dig a bit to find one, but yes, Syndetics certainly has at least some excerpts. http://grpl.michiganevergreen.org/opac/en-US/skin/default/xml/rdetail.xml?r=4224479ol=9t=perltp=keywordl=9d=1hc=94rt=keyword Cool, good to see. Thanks Bill! It's not a concern any more, as my most recent commit sets up a separate Preview tab for Google Book Preview (which is required by Google Book Search branding guidelines in any case). I apologize for the ten hours that all libraries running bleeding edge trunk were in danger of trampling Syndetics excerpts :) -- Dan Scott Laurentian University
Re: [OPEN-ILS-DEV] Using opac_local.dtd
Hi George:
2009/3/9 Duimovich, George george.duimov...@nrcan-rncan.gc.ca:
Hello,
I would like to make some modifications to some of the default strings by
using *_local.dtd files (eg. I created an opac_local.dtd file), mainly to
trim some strings to save space as we compress the OPAC to fit our
institutional common look feel, plus some other local editing.
However, I can't seem to make my sample change display display live in my
local skin, but it does display live when I switch to the relevant language
in the default skin.
I am modifying/updating this file: ../opac/locale/fr-CA/opac_local.dtd by
adding this new entity:
!ENTITY advanced.search.reset Effacer
I have not made any changes to the files int the xml/advanced directory, so
I can see that the relevant code is intact in our new skin:
button onclick='clearSearchBoxes();'advanced.search.reset;/button
Any pointers on what I may be doing wrong? All of my links in the new skin's
xml directory have been re-pointed to the new directory location.
We're trying to avoid modifications to the xml, but some mods will be
necessary to support certain CSS work necessary to make the big squeeze
into our look feel.
My guess is that Warren might have taken the approach I have suggested
various times of defining a local DTD that over-rides specific entries
in the general DTD. I'm going to guess that you updated that local
DTD, but are looking at the default skin (or created a new skin since
then).
The trick is to define opac_local.dtd before opac.dtd in the index.xml
file for your particular skin; for example, you could create a new
skin by copying /openils/var/web/opac/skin/default to
/openils/var/web/opac/skin/nrcan, then add your opac_local.dtd to
override entity definitions to
/openils/var/web/opac/skin/nrcan/xml/index.xml like so:
...
!DOCTYPE html PUBLIC
-//W3C//DTD XHTML 1.0 Transitional//EN
http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd; [
!--#include virtual=/opac/locale/${locale}/opac_local.dtd--
!--#include virtual=/opac/locale/${locale}/opac.dtd--
]
...
Should work, in theory.
--
Dan Scott
Laurentian University
Re: [OPEN-ILS-DEV] Queries on the Source Documentation for Translation
2009/3/9 Betty Ing in...@mcmaster.ca: Hello, I am working on a translation for the db.seed.pot file. There is a source phrase: Allow a user to delete another user container (1) There was also another phrase: Allow a user to delete another user's title note (2) Should (1) read as ... another user's container? If so, what is the mechanism for correcting the source doc? Yes; the source string in Open-ILS/src/sql/Pg/950.data.seed-values.sql is: INSERT INTO permission.perm_list VALUES (49, 'DELETE_CONTAINER', oils_i18n_gettext(49, 'Allow a user to delete another user container', 'ppl', 'description')); In the context of the other *_CONTAINER permissions, it looks like it is talking specifically about containers of items, not containers of users. The mechanism for correcting the source doc is to point out the problem on the list (as you have done). I have checked the correction into trunk, rel_1_4, and rel_1_4_0; if you update your SVN checkout and run make newpot make LOCALE=de-DE updatepo in build/i18n/, you'll get the updated string in your PO file. Also, where are the available translations for this particular file? It would be helpful for me to obtain the French translation to assist with the German translation. The translations are visible in the build/i18n/po/locale subdirectories; for example, http://svn.open-ils.org/trac/ILS/browser/branches/rel_1_4_0/build/i18n/po/fr-CA Thanks for noticing the typo, Betty! -- Dan Scott Laurentian University
Re: [OPEN-ILS-DEV] unAPI
2009/3/10 Mike Rylander mrylan...@gmail.com: On Tue, Mar 10, 2009 at 3:55 PM, Grant Johnson fgjohn...@upei.ca wrote: Check this out... Top record. http://www.google.com/search?hl=enq=narrative+landscapes+morrisonsourceid=navclient-ffrlz=1B3GGGL_enCA295CA298ie=UTF-8 This is great but... How is Google finding this to crawl? I can't explain it, but they always seem to find the SlimPACs... :) Could there be any links to shared bookbags floating around? That's always been my pick for most likely bot entry point. One link to a bookbag and Google can effectively crawl the entire bib set via call number links and the subsequent call number browse. I can answer this: http://www.google.com/search?q=link%3Aislandpines.roblib.upei.ca The search in Google for show me all pages that link to our catalogue shows as the fifth link Island Studies | UPEI Robertson Library (library.upei.ca/reserves/islandstudies.html) which in turn exposes an RSS feed containing selected books on that subject in the SlimPac interface. From there (and similar reserves lists), Google happily crawls through related authors, subjects, etc... -- Dan Scott Laurentian University
Re: [OPEN-ILS-DEV] OrgTree.js - hardcoded strings?
2009/3/11 Duimovich, George george.duimov...@nrcan-rncan.gc.ca: Ok -- that makes sense. If I recall correctly, changes have to be updated with autogen.sh (RTFM, george!) Heh, don't beat yourself up. I forget about autogen.sh myself all the time. Actually, despite your high praise for our I18N work, right now while the org_tree_js.pl script is locale-aware, I haven't taught autogen.sh to be locale-aware; so we currently generate a single organization tree in /openils/var/web/opac/common/js/OrgTree.js - this has been bugging me for the last little while. I have a long plane ride this evening, and we need this ourselves real soon now - so I'll work on this tonight. -- Dan Scott Laurentian University
Re: [OPEN-ILS-DEV] OrgTree.js - hardcoded strings?
2009/3/11 Dan Scott deni...@gmail.com: 2009/3/11 Duimovich, George george.duimov...@nrcan-rncan.gc.ca: Ok -- that makes sense. If I recall correctly, changes have to be updated with autogen.sh (RTFM, george!) Heh, don't beat yourself up. I forget about autogen.sh myself all the time. Actually, despite your high praise for our I18N work, right now while the org_tree_js.pl script is locale-aware, I haven't taught autogen.sh to be locale-aware; so we currently generate a single organization tree in /openils/var/web/opac/common/js/OrgTree.js - this has been bugging me for the last little while. I have a long plane ride this evening, and we need this ourselves real soon now - so I'll work on this tonight. So, as mentioned, we weren't generating localized OrgTree.js (for the dynamic OPAC) or lib_list.inc (for the SlimPac) files. I checked two patches into trunk a few minutes ago; one to fix a bug in the localization support for requesting the org tree, and one to build localized versions of the org trees and teach the dynamic OPAC and SlimPac about them. We'll need to backport these to 1.4, after which you will have to rerun autogen.sh. I might be able to do that tonight - I'm pretty jet lagged. -- Dan Scott Laurentian University
Re: [OPEN-ILS-DEV] [open-ils-commits] r12510 - in trunk: Open-ILS/web/reports/xul build/i18n/po/en-US (miker)
2009/3/13 Mike Rylander mrylan...@gmail.com:
On Fri, Mar 13, 2009 at 5:47 PM, Dan Scott deni...@gmail.com wrote:
Note that you don't / shouldn't update POT files directly; instead,
you want to update the corresponding native en-US file (
Open-ILS/web/js/dojo/openils/reports/nls/en/us/reports.js in this
case).
Unfortunately, no such file exists. Firebug tells me that
Open-ILS/web/js/dojo/openils/reports/nls/reports.js does, though, so
I'll move my updates there and clear out the rest of the strings.
Ah, good catch. That's what I get for firing off a quick email at the
end of a long jet-lagged day. Sorry for leading you astray.
make newpot generates updated POT files and will overwrite
these changes based on the contents of reports.js. Similarly, just add
entity definitions directly to lang.dtd rather than lang.dtd.pot -- or
in this case hardcoding strings in the XUL -- heh :)
I believe that at this point you're the only one that knows the best
practices for all of the moving parts of i18n, so you'll need to bear
with the me (or point me to the the docs I missed on your dojo-PO
integration).
Docs, ah yes... the Dojo-PO piece was the last part I added during the
lead up to 1.4 and has suffered the ignominy of not yet having any
developer-oriented docs written about it, I'm afraid. My apologies!
The Dojo JavaScript property files are nice and simple - they're just
JSON hashes, where the key maps to a translation string, and you can
use variables in the string using ${0} ${1} notation.
I suppose we could delete the POT files from SVN. I had checked them
in to make it relatively easy for someone to grab a copy for their own
translation purposes; but if it's going to cause confusion, I can turf
them.
It seems to have, yes. If we leave them in place, what mechanism do
you suggest for keeping them up to date? We don't want translators
translating from what amounts to the previous version's strings, I
would think.
Well, given that the POT strings will likely be 9x% the same from
release to release, that's not so bad - and it was nice and easy to
point to the Trac instance for translators to download the POT files.
However, I have now removed them from the repository because the last
thing I want to do is slow down development.
One of the sites doing a translation had mentioned they were going to
host a Pootle instance for the Evergreen community, which would
simplify things significantly (provides a nice Web-based translation
interface and automatically generates reports on translation
completion percentages). That has not yet come to pass, though, so
perhaps I'll try running an instance on coffeecode.net.
--
Dan Scott
Laurentian University
Re: [OPEN-ILS-DEV] [open-ils-commits] r12520 - trunk/Open-ILS/xsl (dbs)
2009/3/14 Mike Rylander mrylan...@gmail.com: Would you mind terribly updating Open-ILS/src/sql/Pg/954.data.MODS33-xsl.sql as well, so that in-database XML processing (work underway, as you know) will have the same behavior as open-ils.supercat and open-ils.ingest? I don't mind at all; although this is probably one of those areas where we should just maintain one copy of the pertinent XSL in the source tree and copy it around (renaming if necessary) at install time. For now I'll update 954 accordingly. Thanks for the heads up, Mike! -- Dan Scott Laurentian University
Re: [OPEN-ILS-DEV] Custom entities
2009/3/15 Duimovich, George george.duimov...@nrcan-rncan.gc.ca: Any comments on support for custom entities in, say, the opac ? Could I just add a custom entity in my opac_local.dtd file or will this break things (i.e. does an entity have to be registered elsewhere, including in opac.dtd)? Nope, just go ahead and define custom entities in your opac_local.dtd file. We are using a customized left sidebar menu for certain navigational items, and we are also using /locale/ dtd's for Evergreen entities in our bilingual environment. I can handle non Evergreen links already (using /locale/ aware includes, hardcoding links, etc.) but I was just wondering if I could manage some of our external links using custom entities, and if so, any gotchas to look out for? You have to use amp; for ampersands instead of plain - that's about the only gotcha I can think of off the top of my head. Oh, and this is broader than just entities, but if you end up customizing some of the JS files, like skin/skin-name/js/rdetail.js, inside a skin, you'll discover that the corresponding XML file in the skin hardcodes a call to skin/default/js/rdetail.js - which can be surprising the first time you make major changes to a JS file in a skin and wonder why you don't see any changes. A little sed can take care of that; for example, in the following we point to the skin/skin-name/js/ directory for all JS files that would otherwise be loaded from skin/default/js/ in page_rdetail.xml (although you might want to use a bit more precision than this!): sed -i -e 's/skin\/default\/js/skin\/skin-name\/js/' /openils/var/web/opac/skin/skin-name/xml/page_rdetail.xml Step by step our customized opac coming along satisfactorily -- a few things to get used to and improve upon (like don't make /any/ xml errors, some minor CSS enhancements to be done for finer grain control, etc.), but I'm very impressed with the thinking and organization behind the OPAC layout pages! Good to hear that you're making progress, George! And yep, as usual, Bill/Mike/Jason's work excels. -- Dan Scott Laurentian University
Re: [OPEN-ILS-DEV] New Skin
2009/3/16 Grant Johnson fgjohn...@upei.ca: Hey, Any place we can demo the new OPAC skin to our staff? Hi Grant: If you're talking about craftsman, see: http://demo.gapines.org/opac/en-US/skin/craftsman/xml/index.xml I suppose the demo.gapines.org landing page could use a blurb about that... -- Dan Scott Laurentian University
Re: [OPEN-ILS-DEV] SuperCat - adding supported format?
Heh, you're about a week and a half behind: http://svn.open-ils.org/trac/ILS/changeset/12461 - at least in trunk. Backporting to rel_1_4 would be trivial. 2009/3/16 Duimovich, George george.duimov...@nrcan-rncan.gc.ca: FWIW - Terry Reese's recent MarcEdit update now includes Creative Commons Zero license headers to the FGDC stylesheets http://oregonstate.edu/~reeset/blog/archives/629 If possible, I'd like to see it added as an official supported supercat transform. We're keen to monitor and help support future versions of that format, especially after our phase II migration when we bring on board our map library. Cheers, George -Original Message- From: open-ils-dev-boun...@list.georgialibraries.org [mailto:open-ils-dev-boun...@list.georgialibraries.org] On Behalf Of Duimovich, George Sent: January 26, 2009 9:22 AM To: Evergreen Development Discussion List Subject: Re: [OPEN-ILS-DEV] SuperCat - adding supported format? Dan - I saw your post: http://www.coffeecode.net/archives/181-Adding-a-new-metadata-format-to-Evergreen-in-a-dozen-lines-of-code.html Thanks for that write-up! Very helpful. George Duimovich NRCan Library / Bibliothèque RNCan -Original Message- From: open-ils-dev-boun...@list.georgialibraries.org [mailto:open-ils-dev-boun...@list.georgialibraries.org] On Behalf Of Dan Scott Sent: November 6, 2008 1:06 PM To: Evergreen Development Discussion List Subject: Re: [OPEN-ILS-DEV] SuperCat - adding supported format? Hi George: 2008/11/4 Duimovich, George gduim...@nrcan.gc.ca: I am looking for some feedback on adding support for additional SuperCat transformations. We have a large map collection and have some key user communities standardized on the FGDC format [1]. This standard specifies the content of metadata for a set of digital geospatial data. I am impressed with the off-the-shelf transformations supported here [2] and I would like to hear from anyone on the process for adding an additional supported format. In particular, we are looking to support FGDC (and related ISO 19115) standard as one of the SuperCat output transformations. FYI, a sample crosswalk is available here [2], thanks to the work of Terry Reese. Note the available MARCXML21 = FGDC v.2 XSLT crosswalk. Any comments on next steps (getting started by adding it as a local only transformation vs. getting this officially part of SuperCat supported formats), etc. I think the first step would be getting a license for the crosswalk; the Oregon State repository that you pointed to simply says Items in ScholarsArchive are protected by copyright, with all rights reserved, unless otherwise indicated. and there is no other indication in either comments in the MARC21XML - FGDC crosswalk or other collateral that the stylesheet is available under any license. Assuming that we can get over the licensing hump, it should be a relatively straightforward matter of dropping the transform into Open-ILS/src/perlmods/OpenILS/Application/SuperCat.pm and Open-ILS/src/perlmods/OpenILS/WWW/SuperCat/Feed.pm (using something like MODS32 as a template). -- Dan Scott Laurentian University -- Dan Scott Laurentian University
[OPEN-ILS-DEV] Evergreen translation Web site (beta)
I took a few hours yesterday to set up a basic Pootle instance for the current Evergreen translations that we have. It's still very barebones, and I haven't set it up to allow direct commits to the repository, but it can be useful if you register and then log in - you can very quickly drill down to see the overall status of each language in the Evergreen project, then the status of each file per language, and have it show you just the untranslated or fuzzy strings for a given file. Or, if you prefer translating offline, you can download the zip file for your language, and later upload files as you complete their translation. If there is interest in the community in using this, I can certainly put some time into refining it and managing the permissions. I suspect it will make life a lot easier. -- Dan Scott Laurentian University
Re: [OPEN-ILS-DEV] Evergreen translation Web site (beta)
Gah, I'm a bit too tired: the barebones site is visible at http://coffeecode.net:8080/projects/Evergreen/ - register and log in options are at the top right. 2009/3/19 Dan Scott deni...@gmail.com: I took a few hours yesterday to set up a basic Pootle instance for the current Evergreen translations that we have. It's still very barebones, and I haven't set it up to allow direct commits to the repository, but it can be useful if you register and then log in - you can very quickly drill down to see the overall status of each language in the Evergreen project, then the status of each file per language, and have it show you just the untranslated or fuzzy strings for a given file. Or, if you prefer translating offline, you can download the zip file for your language, and later upload files as you complete their translation. If there is interest in the community in using this, I can certainly put some time into refining it and managing the permissions. I suspect it will make life a lot easier. -- Dan Scott Laurentian University -- Dan Scott Laurentian University
Re: [OPEN-ILS-DEV] Staff client and locale specific customizations
2009/3/23 Duimovich, George george.duimov...@nrcan-rncan.gc.ca: Regarding Staff client label string entity customizations. 1. There are a couple of untranslated strings in the fr-CA version of the staff client and we will be working towards updating these in the PO files. In the interim, may we proceed with local XUL edits in a manner similar to web OPAC DTD custom changes? For example, we can identify one of the untranslated strings in this file: /web/xul/current/server/locale/fr-CA/lang.dtd !ENTITY staff.main.menu.file.label File Should we proceed with creation of lang_local.dtd in for use in a manner similar to customized files created for OPAC entities (e.g. opac_local.dtd) or should we just update the lang.dtd directly for a temporary fix? Advantage of using lang_local.dtd - it will survive upgrades. Disadvantage of using lang_local.dtd - there are umpteen files that you have to add it. I think your best bet would be to modify lang.dtd locally and ensure that the translations make their way into 1.4.0.x (hopefully the Pootle web app will help with that) so that at the next upgrade you'll get the additional translations. Also, where can one set / change the default OPAC search to use for the F4 (search the catalogue) link for /each/ specific locale we want to use? I've committed a patch for this in trunk, rel_1_4, and rel_1_4_0; thanks to Jason for the assist. It will, unfortunately, require the install of a new staff client. -- Dan Scott Laurentian University
[OPEN-ILS-DEV] Evergreen 1.4.0.4 and OpenSRF 1.0.6 are available
The Evergreen development team is pleased to announce the immediate availability of Evergreen 1.4.0.4 and OpenSRF 1.0.6 for download from http://open-ils.org/downloads.php These releases are primarily bug fix releases; see http://open-ils.org/dokuwiki/doku.php?id=feature_list_1_4_0 for a complete list of fixed bugs. Some of the highlights are: * Improved OPAC support for Google Chrome, Internet Explorer, Opera, and Safari * Fixed a race condition for saving edited bibliographic records * Improved I18N support * Improved performance in authority lookups If you want to give Evergreen 1.4.0.4 a test drive, a VirtualBox image is available for download from http://open-ils.org/dokuwiki/doku.php?id=virtual:virtualbox:lenny Once again, our deepest thanks to everyone in the Evergreen community who contributes documentation, patches, bug reports, ideas, and lends their voice to the project. You help make Evergreen a far stronger library system than it could ever be without you. -- Dan Scott Laurentian University
Re: [OPEN-ILS-DEV] Evergreen 1.4.0.4 and OpenSRF 1.0.6 are available
2009/3/30 Job D R Borges j...@nupelia.uem.br: Hello Dan, Great Works in 1.4.0.4, I did the svn co. But the url http://open-ils.org/~denials/Debian_Lenny-1.4.0.4.vdi.bz2;, used to download the image, has permissions problens. Ah! My apologies - I have fixed the permissions on the image. Thanks for reporting the problem. -- Dan Scott Laurentian University
Re: [OPEN-ILS-DEV] How to test Evergreen after upgrading to 1.4.0.4?
Hi Václav: 2009/3/31 Václav Jansa v.ja...@stk.cz: Dear all, due to the problem with Czech in the staff client (and without manual repair of errors even in the OPAC) I have upgraded Evergreen from version 1.4.0.2 to version 1.4.0.4. The Czech localization works in the OPAC but the staff client keeps reporting errors (even with the pure installation) as described in the previous posts. The staff client will return a 500 version error if it can't find the appropriate translation at /openils/var/web/opac/locale/cs-CZ/lang.dtd - and then will fail with error messages about offline.properties after that if the corresponding files are not visible at /openils/var/web/xul/build-id/server/locale/cs-CZ If you don't want to do a fresh install, then from the 1.4.0.4 tarball you could copy the following files: OPAC: cp Open-ILS/web/opac/locale/cs-CZ/* /openils/var/web/opac/locale/cs-CZ/. Staff client (server side): cp Open-ILS/xul/staff_client/chrome/locale/cs-CZ/* /openils/var/web/xul/build-id/server/locale/cs-CZ/. cp Open-ILS/xul/staff_client/server/locale/cs-CZ/* /openils/var/web/xul/build-id/server/locale/cs-CZ/. cp Open-ILS/web/js/dojo/openils/conify/nls/cs/cz/* /openils/var/web/js/dojo/openils/conify/nls/cs/cz/. cp Open-ILS/web/js/dojo/openils/reports/nls/cs/cz/* /openils/var/web/js/dojo/openils/reports/nls/cs/cz/. But I think you would be better off just doing a fresh install from the 1.4.0.4 tarball. Oh, and you will either need the 1.4.0.4 staff client, or: cp Open-ILS/xul/staff_client/chrome/locale/cs-CZ/* C:\Program Files\Evergreen Staff Client\build\chrome\locale\cs-CZ\. (well, the equivalent on Windows). Is it possible to somehow test the installation so that it could be proved that it has been made correctly? Is it possible to test the database somehow? (Upgrade scripts were run – approx. three inserts and one index – then the database was loaded again, the Czech language switched on, all without errors.) You can delete the existing database strings from the database with: DELETE FROM config.i18n_core WHERE translation = 'cs-CZ'; ... then reload the updated database strings from Open-ILS/src/sql/Pg/950.data.seed-values-cs-CZ.sql Due to work duties I have not made it yet to finish the pure installation and using the current installation I have not made the decision to delete the database and redefine it (there are already some data inserted in the database). A fresh install of Evergreen doesn't require you to rebuild the entire database, so hopefully the config.i18n_core tip above works for you. The IP address of my installation is 213.220.227.200, the user is test (cataloging permissions), password demo123. Thank you in advance for any ideas! -- Dan Scott Laurentian University
Re: [OPEN-ILS-DEV] PATCH: Z39.50 import broken due to marc_view.html issues
The patch looks good to me, Jeff. There were a number of other places in the code where I have had to make similar changes to protect against XMLENT's meddlesome ways (/me shakes fist at XMLENT, while simultaneously being thankful for its existence). My apologies for introducing the regression via the eg_vhost.conf change in the first place. I'll reproduce and commit if it looks good. Thanks a ton for tracking this down, Jeff. 2009/4/2 Jeff Godin j...@tcnet.org: On Thu, 2 Apr 2009, Jeff Godin wrote: Patch against trunk is attached. If the patch is acceptable, please apply to the 1.4 branches also. Since Jason asked (and I forgot) here's a DCO for the patch submitted in my previous message, marc_view.patch. -jeff Developer's Certificate of Origin 1.1 By making a contribution to this project, I certify that: (a) The contribution was created in whole or in part by me and I have the right to submit it under the open source license indicated in the file; or (b) The contribution is based upon previous work that, to the best of my knowledge, is covered under an appropriate open source license and I have the right under that license to submit that work with modifications, whether created in whole or in part by me, under the same open source license (unless I am permitted to submit under a different license), as indicated in the file; or (c) The contribution was provided directly to me by some other person who certified (a), (b) or (c) and I have not modified it. (d) I understand and agree that this project and the contribution are public and that a record of the contribution (including all personal information I submit with it, including my sign-off) is maintained indefinitely and may be redistributed consistent with this project or the open source license(s) involved. Signed-off-by: Jeff Godin j...@tcnet.org -- Dan Scott Laurentian University
Re: [OPEN-ILS-DEV] PATCH: Z39.50 import broken due to marc_view.html issues
2009/4/2 Jeff Godin j...@tcnet.org: On Thu, 2 Apr 2009, Dan Scott wrote: The patch looks good to me, Jeff. There were a number of other places in the code where I have had to make similar changes to protect against XMLENT's meddlesome ways (/me shakes fist at XMLENT, while simultaneously being thankful for its existence). A number of other places, like the closed dates editor. :) (thanks for your help with that one the other night!) Yeah. If you grep all the files under /xul/ for CDATA, you'll see a ton there, too; mostly as a result of being broken by turning on XMLENT in earlier days. My apologies for introducing the regression via the eg_vhost.conf change in the first place. I'll reproduce and commit if it looks good. Thanks a ton for tracking this down, Jeff. You're welcome, and don't worry about it! I wasn't trying to point blame by citing a changeset (dbs broke it!) -- I was just trying to give enough context to explain the reason for the patch. :) Oh, don't worry I understand and appreciate the intent. Context is good! Thanks again for all your help. I really appreciate it. Aw, shucks :) Anyway, your patch tested out successfully and has been applied, with thanks. Keep 'em coming! -- Dan Scott Laurentian University
Re: [OPEN-ILS-DEV] Problems with open-ils.ingest.full.biblio.record_list
2009/4/8 Mike Rylander mrylan...@gmail.com: On Wed, Apr 8, 2009 at 12:21 AM, Dan Scott deni...@gmail.com wrote: snip I've fixed these issues in r12816 using a minimalist approach, but it's not clear to me why the current implementation is as complex as it is. ingest.full.biblio.record_list seems to be a copy of ingest.full.biblio.record, with a bit of extra code to iterate over the incoming list and to return a count of the records that were successfully processed. They could certainly be coalesced into a single implementation. The only important difference is null vs 0 on a single (or all) record error. Calling code looks at the return value of both as true/false, so returning the bib id from the non-list version isn't needed. That being said, it would not be hard to retain both existing return types based on $self-api_name. Ah, the $self-api_name trick; that would be a good direction to go. Thanks for the suggestion, Mike. Replacing it with an implementation that just iterates over ingest.full.biblio.record for each element of the list (below) works just as well, and (at least to my eyes) is easier to read. [snip implementation] For long lists of record ids, the extra round-tripping of a retrieval per record can cause significant slowdown. There was once a version that was much like what you have there, but I rewrote it to do batch re-ingests more efficiently. Oh, that makes perfect sense (of course). If we touch that area of code again without refactoring it away entirely, we should probably add a comment to that effect so that when Evergreen developer archaelogists from the year 3000 dig into the code, they won't run through the same rediscovery process. :) -- Dan Scott Laurentian University
Re: [OPEN-ILS-DEV] proper client
2009/4/9 Raymond Norton ad...@lctn.org: I think so. I don't know off-hand how to configure apache for allowing symlinks. How painful would it be to get a newer Evergreen image? I use vmware from wmware.com. I tried a different image earlier, but it wouldn't open. Which image would you suggest? All of the recent images have been built with VirtualBox (http://virtualbox.org/). The nice thing about VirtualBox is that it will open VMWare images as well. I would suggest the most recent image, the Evergreen 1.4.0.4 VirtualBox image, documented at http://open-ils.org/dokuwiki/doku.php?id=virtual:virtualbox:lenny -- Dan Scott Laurentian University
Re: [OPEN-ILS-DEV] Inconsistent description/steps on 1.4 Evg Install Docuwiki page
2009/4/9 John Craig jc-mailingl...@alphagconsulting.com: Page in question is: http://open-ils.org/dokuwiki/doku.php?id=server:1.4.0:instal Textual instructions say: We start Evergreen using three separate steps (the OpenSRF router, Perl services, and C services) to avoid a possible race condition with the start_all command. Step says (down a few lines): osrf_ctl.sh -l -a start_alll Which raises another question: Wait! You didn't ask the first question! Oh well. If you're worried about the difference between the description and the action, I've deleted the description. The race condition has (probably) gone away in 1.4 due to the addition of the --settings-startup-pause flag to opensrf-perl.pl; that descriptive text was a hangover from 1.2 days. Is the nature of the race condition understood so that the script could be improved to check for something (or just pause) to avoid it? I'd be happy to fiddle with it if I knew more about what needed to happen--or what needed to be prevented. Short version: Perl services start; C services start; C services depend on Perl services (settings server in particular); Perl services aren't ready by the time the C services ping them; C services fail to initialize; unhappiness. -- Dan Scott Laurentian University
Re: [OPEN-ILS-DEV] Searching the catalog
2009/4/13 Jason Etheridge ja...@esilibrary.com: So what's wrong, you ask? If I try a basic catalog search (in the OPAC or the staff client) I get zero results, regardless of what I search for. Garry, did you figure this out? Have you tried direct lookups by TCN or item barcode? Any ideas on where to start to correct this problem? I'd start looking at the various metabib.* tables, and see if they're getting populated. This is certainly a good idea. If they are indeed populated, I have another idea... One change between 1.2 and 1.4 is the staged search, which is much faster than the regular old 1.2 search. However, staged search is also much pickier about your org_unit hierarchy; if you have one org_unit at the wrong depth, or skip a depth in the hierarchy, your search is going to return nothing. You can tell if you are using staged search by checking for use_staged_searchtrue/use_staged_search in opensrf.xml - if changing it to false makes a difference, this is a pretty strong clue that you need to double-check actor.org_unit and actor.org_unit_type. -- Dan Scott Laurentian University
Re: [OPEN-ILS-DEV] ***SPAM*** Patch to fix insert subfield shortcut key conflict in Mac client
2009/3/26 Alexander O'Neill aone...@upei.ca:
Hi Everyone,
We encountered a problem with the Evergreen staff client when running on Mac
OS X. When editing a MARC record, the default shortcut key to add a new
subfield (Ctrl-d) didn't do anything. We discovered that it was conflicting
with the default Mac OS system behaviour - delete the character to the right
of the insertion point.
Anyway here is a very simple patch that makes Ctrl-i also be a shortcut to
add a subfield. This doesn't conflict with anything else since you can't
use italics in MARC subfields. ;)
The patch was against version rel_1_2_2_2, and needs to be applied in the
directory /openils/var/web/xul/[STAFF CLIENT BUILD NUMBER]/server/cat
because of the staff client build numbers insanity.
The patch also updates the text box when you hit the Help button on the MARC
edit screen.
If you don't want to apply a patch here are the changes:
marcedit.js - line 230:
Change:
if (event.charCode == 100 event.ctrlKey) { //
ctrl+d
To:
// Use Ctrl-I for Mac since Ctrl-D conflicts (UPEI)
if ((event.charCode == 100 || event.charCode == 105)
event.ctrlKey) { // ctrl+d
marcedit.xul - line 13
Change:
button label=Help accesskey=H oncommand=alert('Add Row:
CTRL+Enter\nInsert Row: CTRL+Shift+Enter\nAdd Subfield: CTRL+D\nRemove Row:
CTRL+Del\nRemove Subfield: SHIFT+Del\nCreate/Replace 006:
CTRL+F6\nCreate/Replace 007: CTRL+F7\nCreate/Replace 008: CTRL+F8\n');/
To:
button label=Help accesskey=H oncommand=alert('Add Row:
CTRL+Enter\nInsert Row: CTRL+Shift+Enter\nAdd Subfield: CTRL+D (CTRL+I on
Mac)\nRemove Row: CTRL+Del\nRemove Subfield: SHIFT+Del\nCreate/Replace 006:
CTRL+F6\nCreate/Replace 007: CTRL+F7\nCreate/Replace 008: CTRL+F8\n');/
We aren't running 1.4 yet but looking at the source code I think this bit is
unchanged from 1.2.
In 1.4 and beyond, the strings are in a separate file for
internationalization purposes - but otherwise, things were indeed
unchanged. Which made it easy for me to apply the patch to trunk in
r12862 - thanks a ton, Alex.
Hopefully this is useful for people looking to use the Mac client. If there
is interest in fixing the other shortcut key problems in the Mac client let
me know and I'll devote some more time to it.
I don't know what other shortcut key conflicts exist on the Mac, but
I'm sure that your offer is appreciated and will be taken advantage of
as more Mac users adopt Evergreen :)
Thanks again!
--
Dan Scott
Laurentian University
Re: [OPEN-ILS-DEV] Proximity stuff in 1.4.0.4 seems confused.....
Those prototype mismatch warnings are because you're running on Ubuntu Intrepid and there's a known problem in perl 5.10 on Intrepid for which I opened a bug and submitted a patch: https://bugs.launchpad.net/ubuntu/+source/perl/+bug/303765 - it shouldn't change the results of running /openils/bin/autogen.sh However, you do have some other problem in your setup that is causing problems: Can't call method content on an undefined value at /openils/lib/perl5/OpenILS/Utils/CStoreEditor.pm line 324 That's not good. Don't know what the problem is, though. Dan 2009/4/15 Hunt, Phil h...@nelinet.net: Just finished installing 1.4.0.4 and trying to setup the proximity stuff, getting these errors below. It is also taking A LONG TIME (5+ minutes, 1.4.0.2 finished in 15 seconds). See below: open...@lnxevg1os1:/home/phunt$ cd /openils/bin open...@lnxevg1os1:/openils/bin$ ./autogen.sh -c /openils/conf/opensrf_core.xml -u Updating fieldmapper Prototype mismatch: sub main::__LONG_MAX__ () vs none at /usr/lib/perl/5.10/_h2ph_pre.ph line 291. Constant subroutine __LONG_MAX__ redefined at /usr/lib/perl/5.10/_h2ph_pre.ph line 291. Updating web_fieldmapper Prototype mismatch: sub main::__LONG_MAX__ () vs none at /usr/lib/perl/5.10/_h2ph_pre.ph line 291. Constant subroutine __LONG_MAX__ redefined at /usr/lib/perl/5.10/_h2ph_pre.ph line 291. Updating OrgTree Prototype mismatch: sub main::__LONG_MAX__ () vs none at /usr/lib/perl/5.10/_h2ph_pre.ph line 291. Constant subroutine __LONG_MAX__ redefined at /usr/lib/perl/5.10/_h2ph_pre.ph line 291. cp: cannot stat `/openils/var/web/opac/common/js//en-US/OrgTree.js': No such file or directory Updating OrgTree HTML Prototype mismatch: sub main::__LONG_MAX__ () vs none at /usr/lib/perl/5.10/_h2ph_pre.ph line 291. Constant subroutine __LONG_MAX__ redefined at /usr/lib/perl/5.10/_h2ph_pre.ph line 291. Updating locales selection HTML Prototype mismatch: sub main::__LONG_MAX__ () vs none at /usr/lib/perl/5.10/_h2ph_pre.ph line 291. Constant subroutine __LONG_MAX__ redefined at /usr/lib/perl/5.10/_h2ph_pre.ph line 291. Updating Search Groups Prototype mismatch: sub main::__LONG_MAX__ () vs none at /usr/lib/perl/5.10/_h2ph_pre.ph line 291. Constant subroutine __LONG_MAX__ redefined at /usr/lib/perl/5.10/_h2ph_pre.ph line 291. Can't call method content on an undefined value at /openils/lib/perl5/OpenILS/Utils/CStoreEditor.pm line 324. Refreshing proximity of org units Prototype mismatch: sub main::__LONG_MAX__ () vs none at /usr/lib/perl/5.10/_h2ph_pre.ph line 291. Constant subroutine __LONG_MAX__ redefined at /usr/lib/perl/5.10/_h2ph_pre.ph line 291. Successfully updated the organization proximity Done open...@lnxevg1os1:/openils/bin$ Phil Hunt Program Director, Information Technology NELINET, Inc. ' Direct Phone: (508)597-1924 ' 1.508.460.7700 x1924 6 FAX (508)460-9455 * h...@nelinet.net -- Dan Scott Laurentian University
Re: [OPEN-ILS-DEV] Regarding installation of Evergreen 1.0.4
2009/5/7 Dibyendra Hyoju dibyen...@gmail.com: Hello everyone, I have been trying to install Evergreen 1.4.0 on Ubuntu 8.04 Hardy Heron since couple of days ago. I have successfully installed PostgreSQL 8.2 database system from the source code. Also, installation of the OpenSRF 1.0.6 was successful. After coming back to the installation of Evergreen 1.4.0, I have followed the provided 15 steps, as provided on http://open-ils.org/dokuwiki/doku.php?id=server:1.4.0:install, but couldn't succeed in starting Evergreen due to the problem occured in step 4, relating to PostgreSQL. While issuing the following command, following error occurs, although the two configuration files contain correct authentication parameters for PostgreSQL: r...@dibyendra-laptop:/home/opensrf/Evergreen-ILS-1.4.0.4# perl Open-ILS/src/support-scripts/eg_db_config.pl --update-config --service-all --create-schema --create-bootstrap --create-offline --user evergreen --password evergreendb --hostname localhost --port 5432 -- database evergreen Unknown option: service-all This is one of the keys! The option should be --service all - no connecting hyphen (-) between the two. This tells the script to update all of the Evergreen services in opensrf.xml that connect to a database to use the parameters that you are passing at the command line; or, if you don't pass a parameter at the command line, to use the first corresponding value of that it finds in opensrf.xml. So, when you pass -- database evergreen, the extra space between the -- and database is enough to confuse the script, and it goes to lookup the database name from the existing opensrf.xml file. Try --database evergreen instead. When you fix those two options in your command, things should be a lot better! -- Dan Scott Laurentian University
Re: [OPEN-ILS-DEV] Z39.50 Server off by one
2009/5/13 Warren Layton warren.lay...@gmail.com: I've managed to set up Evergreen as a Z39.50 server using Simple2Zoom. However, I noticed that when I would find N results, I could only retrieve N-1 of those results. It sounds like others may be having this problem. I poked around a bit in Simple2Zoom and made a quick 1-line fix (attached). It seems to have solved this issue for me on my simple Evergreen setup but I haven't tested it very much yet. I was wondering if anyone had narrowed this problem down to being an Evergreen issue or a Simple2Zoom issue. If it's a Simple2Zoom issue, then this patch might be helpful. I'm happy to say that this patch solved our off-by-one problem quite nicely. And I'm honestly happy to just have a working Z39.50 server, with the ability to scope searches by org_unit and surface holdings in a way that makes VDX happy, without worrying too much about whether the cause of the off-by-one lies in the Evergreen code or the Simple2ZOOM code. Thanks a ton, Warren! We should update the SRU/Z39.50 section of the wiki to reflect the status of the server, it has come a long way in the last month! -- Dan Scott Laurentian University
Re: [OPEN-ILS-DEV] ctrl+i for Mac Staff Client
Hey Grant:
2009/5/25 Grant Johnson fgjohn...@upei.ca:
Since I had a couple of requests for this here it is.
To use ctrl+i for Mac Staff clients, AO added the following to marcedit.js on
the server.
This is NOT a patch - just a code snippit for context.
It enables ctrl+i for ALL OS's cause italics doesn't matter in the EG staff
client. :-)
if (element.nodeKind() == 'attribute') element[0]=box.value;
else element.setChildren( box.value );
++ //Use Ctrl+i for Mac since Ctrl+d conflicts (UPEI)
if (element.localName() != 'controlfield') {
-- if (event.charCode == 100 event.ctrlKey) { //
ctrl+d
++ if ((event.charCode == 100 || event.charCode == 105)
event.ctrlKey) { // ctrl+d
--
Good news, I merged this to Evergreen trunk about a month ago as
http://svn.open-ils.org/trac/ILS/changeset/12862/trunk/Open-ILS/xul/staff_client/server/cat/marcedit.js
(and credited Alexander O'Neill accordingly).
--
Dan Scott
Laurentian University
Re: [OPEN-ILS-DEV] Patron Search
2009/5/25 Grant Johnson fgjohn...@upei.ca: How much work would it be to add a Search for Patron by username? and where would I look first ? In trunk, on the Search for Patrons interface, there is an OPAC Login field. Perhaps this is what you're looking for? Or are you looking for a quick search menu item like Search for copies by barcode? -- Dan Scott Laurentian University
[OPEN-ILS-DEV] Make craftsman the default catalogue skin in Evergreen 1.6?
How crazy would it be to make craftsman the default skin for the 1.6 release? I think that it would make sense for two reasons: 1) It would put the best face forward for new Evergreen installs. First impressions matter. 2) It would help us shake out any bugs that might remain in the craftsman skin at this point. I would hate to see the investment in this very nice facelift to the catalogue fall by the wayside. I was happy to see that my serials display code just works with craftsman, but it's visually jarring because it uses the legacy skin classes for its styling at the moment. -- Dan Scott Laurentian University
[OPEN-ILS-DEV] Fixing the mixed-content warnings in My Account
If I understand correctly, some browsers (hello IE!) throw up warnings
when patrons enter My Account in the OPAC because there are some
hard-coded HTTP requests mixed in with the HTTPS session. When patrons
opt to not allow the browser to load mixed content, hilarity (or some
miserable facsimile thereof) ensues. This is bad. Apaprently things
are even worse in IE8.
It looks like the mixed content is due to
Open-ILS/var/web/opac/skin/default/xml/setenv.xml:
setenv.xml:!--#set var=OILS_BASE
value=http://${SERVER_NAME}/${OILS_OPAC_BASE}--
setenv.xml:!--#set var=OILS_OPAC_JS_HOST
value=http://${OILS_OPAC_JS_HOST}--
setenv.xml:!--#set var=OILS_OPAC_CSS_HOST
value=http://${OILS_OPAC_CSS_HOST}--
Setting these to the following alleviates the problem:
setenv.xml:!--#set var=OILS_BASE value=${OILS_OPAC_BASE}--
setenv.xml:!--#set var=OILS_OPAC_JS_HOST value=--
setenv.xml:!--#set var=OILS_OPAC_CSS_HOST value=--
The win from having a non-scary default configuration seems to, in my
mind, outweigh the possible balancing of JS and CSS across different
hosts. Would there be any objection to my merging a commit that resets
each offending var to a non-scary default value, along with a comment
that explains what in the wide world of sports is going on?
--
Dan Scott
Laurentian University
Re: [OPEN-ILS-DEV] Fixing the mixed-content warnings in My Account
2009/5/29 Mike Rylander mrylan...@gmail.com:
On Fri, May 29, 2009 at 12:38 AM, Dan Scott deni...@gmail.com wrote:
If I understand correctly, some browsers (hello IE!) throw up warnings
when patrons enter My Account in the OPAC because there are some
hard-coded HTTP requests mixed in with the HTTPS session. When patrons
opt to not allow the browser to load mixed content, hilarity (or some
miserable facsimile thereof) ensues. This is bad. Apaprently things
are even worse in IE8.
It looks like the mixed content is due to
Open-ILS/var/web/opac/skin/default/xml/setenv.xml:
setenv.xml:!--#set var=OILS_BASE
value=http://${SERVER_NAME}/${OILS_OPAC_BASE}--
setenv.xml: !--#set var=OILS_OPAC_JS_HOST
value=http://${OILS_OPAC_JS_HOST}--
setenv.xml: !--#set var=OILS_OPAC_CSS_HOST
value=http://${OILS_OPAC_CSS_HOST}--
Setting these to the following alleviates the problem:
setenv.xml:!--#set var=OILS_BASE value=${OILS_OPAC_BASE}--
setenv.xml: !--#set var=OILS_OPAC_JS_HOST value=--
setenv.xml: !--#set var=OILS_OPAC_CSS_HOST value=--
The win from having a non-scary default configuration seems to, in my
mind, outweigh the possible balancing of JS and CSS across different
hosts. Would there be any objection to my merging a commit that resets
each offending var to a non-scary default value, along with a comment
that explains what in the wide world of sports is going on?
How about we do that /AND/ supply https: versions of those three,
having the code that deals with (and makes up) the My OPAC stuff use
those. Perhaps even make that explicit in the name by putting MYOPAC
in there:
setenv.xml:!--#set var=OILS_MYOPAC_BASE
value=https://${SERVER_NAME}/${OILS_OPAC_BASE}--
setenv.xml:!--#set var=OILS_MYOPAC_JS_HOST
value=https://${OILS_OPAC_JS_HOST}--
setenv.xml:!--#set var=OILS_MYOPAC_CSS_HOST
value=https://${OILS_OPAC_CSS_HOST}--
Then My OPAC is happy in tin-foil browsers, and those sites that need
a separate content server (at least the 2 largest production sites,
that I recall OTTOMH) don't have to jump through any more hoops than
anyone else at upgrade time -- it stays as config settings. Do you
see any issues with that modification to your plan?
Other than being more work and perhaps more susceptible to slipping in
an error somewhere for the simple case, no, I think it will maintain
the current approach for serving up static content in more complex
configurations. For now, we have adopted the simplistic serve
everything up from a single host approach (recognizing that that's
eating up our Apache backends like crazy, but hey, it's summer and
slow time for the academics).
Rather than trying to solve the problem in the Evergreen application
code, another approach would be to use something like nginx as a proxy
to serve up all known static types (*.js, *.png, *.gif, and the like)
/ locations and to hand off the dynamic requests to Apache. nginx is
apparently able to serve up static content at higher concurrency and
using far less CPU RAM than Apache requires. This would add one more
moving part to a production configuration, but it would have the
advantage of simplifying the application code (one less set of SSI to
deal with). Each server in a load-balanced cluster could be
responsible for serving up its own static content; or all static
content could be served up from a designated host; or in a simple
non-nginx environment, Apache could still serve up all static +
dynamic content.
There's a good intro to nginx at
http://www.linuxjournal.com/article/10108 for those interested in
pursuing this direction.
--
Dan Scott
Laurentian University
Re: [OPEN-ILS-DEV] By popular demand
2009/6/2 Mike Rylander mrylan...@gmail.com: I fixed up the major issues that I'm aware of in Craftsman in terms of functionality compared to the venerable 'default' (copy location display (or lack thereof) which was also causing massive JS fail, and added BibTemplate support, which just worked), and made it the default in the example Apache config file that will go into 1.6. I suspect we'll find more issues with it (probably 10 minutes after I finally wrap a 1.6.0 tarball) but it's in there now. You rock, Mike. Serials support just works too, but it's currently pulling in the classes that define styles for the classic default rather than the craftsman default default skin, which looks pretty funny. I'll see if there's a simple-ish fix for that this morning. -- Dan Scott Laurentian University
Re: [OPEN-ILS-DEV] Z39.50 sru vs marc21
2009/6/10 Grant Johnson fgjohn...@upei.ca: I have SRU returning marcxml records. What do I need to do to return marc21? At Conifer we're just following the steps that Mike and I wrote up at http://open-ils.org/dokuwiki/doku.php?id=evergreen-admin:sru_and_z39.50 - although at Conifer we're running something closer to trunk than 1.4, so your mileage may vary slightly. I spruced up the page a bit to document the options to limit search scope and expose holdings that are supported as of Evergreen 1.6. -- Dan Scott Laurentian University
Re: [OPEN-ILS-DEV] storing program of study/major information in Evergreen
2009/6/11 Robert Soulliere robert.soulli...@mohawkcollege.ca: Hi guys, I have a quick database question: We would like to store patron - program of study information in Evergreen. Which table should I store this in or is this even possible? From looking at the database tables, it looks like the usr_setting table might be a candidate. Any suggestions? This sounds like a perfect use for a patron statistical category (stat cat), I would think. You can get to it from Local System Administration - Statistical Category Editor. -- Dan Scott Laurentian University
Re: [OPEN-ILS-DEV] Z39.50 sru vs marc21
2009/6/11 Grant Johnson fgjohn...@upei.ca: OK - I made some changes... Thanks Dan. SRU still works... I may be really thick but is the issue I'm listening on localhost only? islandpines:/openils/conf# simple2zoom -c dgo.conf localhost:2210 -f xml2marc-yaz.cfg Found database: evergreen 09:55:42-11/06 [server] Adding dynamic listener on localhost:2210 id=0 09:55:42-11/06 [server] Starting server simple2zoom pid=7866 Oh, probably (the localhost thing, not the thick thing!). When you say localhost:2210, you're saying only respond to a Z client making requests to localhost:2210. Instead of localhost:2210, you can specify islandpines.roblib.upei.ca:2210 if you're allowing external connections to port 2210 on that server, for example. You can even specify multiple host/port listener combos with a command line like: simple2zoom -c dgo.conf -- -f xml2marc-yaz.conf localhost:2210 islandpines.roblib.upei.ca:2210 172.17.100.99:2210 -- Dan Scott Laurentian University
Re: [OPEN-ILS-DEV] Z39.50 sru vs marc21
2009/6/11 Grant Johnson fgjohn...@upei.ca: Can someone try hitting islandpines.roblib.upei.ca:2210 see if they can retrieve marc21 records? At least then I'd know if it was just my client or not... I'm getting the same error that you're getting. Using yaz-client here. The same query against our server works great. One note: our server is running yaz-3.0.45, while yours is yaz-3.0.38. -- Dan Scott Laurentian University
Re: [OPEN-ILS-DEV] Debugging OpenSRF installation
2009/6/19 Victoria Bush vb...@ilstu.edu: Well, I took the following text from the installation instructions: Copy /openils/conf/srfsh.xml.example to .srfsh.xml in the home directory of each user you want to use to run the srfsh command line client for testing OpenSRF, and edit .srfsh.xml as follows: * domain is the router hostname (following our domain examples, private.localhost will give your srfsh access to all OpenSRF services, while public.localhost will only give you access to those OpenSRF services that are publicly exposed) to mean that I needed to test both interfaces to verify they worked. You only showed private, but my assumption was that public also needed to be tested. If I wasn't supposed to test the public interface, it shouldn't have been mentioned. You did say to edit the file. :D -Vicki (who can be rather pendantic, unfortunately) I'm not trying to blame you, Vicki. You went beyond the defaults and the concrete instructions to perform a logical extra step, and found a bug. That's great! -- Dan Scott Laurentian University
Re: [OPEN-ILS-DEV] Error with autogen script
2009/6/23 Victoria Bush vb...@ilstu.edu: As I recall, if you look at the installation instructions, step 3 under starting Evergreen says: As the opensrf user, generate the Web files needed by the staff client and catalogue and update the organization unit proximity (you need to do this each time you change the library hierarchy in config.cgi): (emphasis added) You have to set up the hierarchy and organization units for your library, then regenerate the web pages using the autogen script. In theory, it should start up with the generic hiearchy and OUs, but I saw a few problems that went away after I set these up via the config.cgi script. It's a thought. That's rather magical. I suspect some other factor was to blame for your problems. My fear with directing users to touch the hierarchy before running autogen.sh is that they are much more likely to introduce other problems (like org units at the wrong depth). I think it's far better to get the out of the box system up and running, keeping as many defaults as possible, and then start to carefully tweak one variable at a time. -- Dan Scott Laurentian University
Re: [OPEN-ILS-DEV] Error with autogen script
2009/6/24 Ryan Laverdiere ryan484...@msn.com: I also have been running into some problems with a fresh install when I run the autogen script I receive this output Prototype mismatch: sub main::__LONG_MAX__ () vs none at /usr/lib/perl/5.10/_h2ph_pre.ph line 291. snip What do these errors indicate and how can they be fixed? These errors indicate that you're using Ubuntu Intrepid, which contained a flawed version of Perl. There was a fix posted at https://bugs.launchpad.net/ubuntu/+source/perl/+bug/303765 -- Dan Scott Laurentian University
Re: [OPEN-ILS-DEV] open-ils.cstore.json_query and HAVING clauses
Just a thought - this would be a perfect case for adding a set of unit
tests to ensure that we get the output expected for the corresponding
input, for all the nooks and crannies of JSON and SQL, as the code
continues to be refined / debugged / extended.
And the test cases could make for good examples, too.
Just saying.
2009/6/25 Scott McKellar m...@swbell.net:
I found the same glitch a few weeks ago and fixed it. When I test it in my
sandbox, using the test_json_query utility, I get the GROUP BY and HAVING
clauses in the right order. It also works from srfsh.
I don't know what version you're running, but you can probably grab the
current version of oils_cstore.c from trunk and rebuild without refreshing
anything else. Don't forget to restart the C services so that you're running
the new version.
Scott McKellar
--- On Thu, 6/25/09, Jeff Godin j...@tcnet.org wrote:
From: Jeff Godin j...@tcnet.org
Subject: [OPEN-ILS-DEV] open-ils.cstore.json_query and HAVING clauses
To: Evergreen Development Discussion List
open-ils-dev@list.georgialibraries.org
Date: Thursday, June 25, 2009, 8:35 AM
Greetings-
First off, a huge thank you to Scott and whoever else was
involved in
the production of JSON Queries: A Tutorial, found in
docs/TechRef/JSONTutorial.xml
I think I've found a bug in cstore when using GROUP BY with
a HAVING
clause. After a discussion with Mike Rylander, this might
be less of a
bug and more a case of incomplete support for HAVING
clauses.
Using an example from the tutorial:
{
select: {
aou: [
parent_ou, {
column:id,
transform:count,
alias:id_count,
aggregate:true
}
]
},
from:aou,
having: {
id: {
: {
transform:count,
value:6
}
}
}
}
I execute this in srfsh like so:
srfsh# request open-ils.cstore
open-ils.cstore.json_query.atomic {
select: { aou: [ parent_ou, { column:id,
transform:count, alias:id_count, aggregate:true
} ] },
from:aou, having: { id: { : {
transform:count,
value:1 } } } }
And the result is:
Received Exception:
Name: osrfMethodException
Status: Severe query error -- see error log for more
details
Status: 500
Received Exception:
Name: osrfMethodException
Status: An unknown server error occurred
Status: 404
Request Completed Successfully
Request Time in seconds: 0.000476
Checking logs, it appears that the GROUP BY and HAVING
clauses are
reversed in the generated SQL:
open-ils.cstore 2009-06-25 09:34:03 [ERR
:4398:oils_cstore.c:4213:]
open-ils.cstore: Error with query [SELECT
aou.parent_ou AS
parent_ou, count(aou.id ) AS id_count FROM
actor.org_unit AS
aou HAVING count(aou.id ) 1
GROUP BY 1;]
I looked at oils_cstore.c and it seems like things are
being placed
into the buffer in the correct order, but it's very
possible that I'm
reading this wrong, or missing something:
string =
buffer_release(group_buf);
if ( *string (
aggregate_found || (flags SELECT_DISTINCT) ) ) {
OSRF_BUFFER_ADD( sql_buf, GROUP BY );
OSRF_BUFFER_ADD( sql_buf, string );
}
free(string);
if( having_buf ) {
string = buffer_release(having_buf);
if
( *string ) {
OSRF_BUFFER_ADD( sql_buf,
HAVING );
OSRF_BUFFER_ADD( sql_buf, string
);
}
free(string);
}
If I take the generated SQL and manually re-order the GROUP
BY and
HAVING clauses, the query works.
Anyone with in-depth knowledge of open-ils.cstore care to
investigate
and let me know if this is a simple fix?
Thanks!
-jeff
--
Dan Scott
Laurentian University
Re: [OPEN-ILS-DEV] Record summary page not available
2009/6/29 Catherine Buck Morgan cmor...@statelibrary.sc.gov:
Error: missing ) after condition
Source File:
http://evergreen.statelibrary.sc.gov//opac//skin/default/js/rdetail.js
Line: 576, Column: 58
Source Code:
|| ( findOrgType(node.ou_type()).depth==1) {
Hmm, local customizations?
A quick glance at the source suggests you should append a ) right
after .depth==1).
--
Dan Scott
Laurentian University
[OPEN-ILS-DEV] Release 1.6 - testing notes
We're currently testing Evergreen rel_1_6_0 (there's no tarball release candidate yet) on a Debian Lenny, PostgreSQL 8.3 system and have noticed the following so far: * Reporter interface: sources all appear, but none of the fields for the sources appear * The skin default (not the default skin, that's craftsman) has display problems in the detailed record page (we have some local fixes that I can contribute) * 1.4 - 1.6 database upgrade script (or autogen.sh) needs to include UPDATE metatada.metarecord SET mods = NULL; * 1.4 - 1.6 database upgrade script needs to add VIEW_ORG_SETTINGS to staff and MFHD permissions to catalogers, and possibly other perms Confirmation or further reports of regressions or other problems that need to be fixed before a release candidate would be greatly appreciated! The rough 1.4-1.6 database upgrade script that Mike wrote is at http://open-ils.org/~miker/1.4.0.5-1.6.0.0-upgrade-db.sql; if you're upgrading, you'll also need to: * first, update OpenSRF to trunk (I think) * upgrade to dojo 1.3.1 * cp /openils/conf/oils_web.xml.example /openils/conf/oils_web.xml * update the Apache configuration files * update opensrf_core.xml and opensrf.xml * other stuff, undoubtedly -- Dan Scott Laurentian University
Re: [OPEN-ILS-DEV] Release 1.6 - testing notes
2009/7/10 Dan Scott deni...@gmail.com: We're currently testing Evergreen rel_1_6_0 (there's no tarball release candidate yet) on a Debian Lenny, PostgreSQL 8.3 system and have noticed the following so far: * Reporter interface: sources all appear, but none of the fields for the sources appear * The skin default (not the default skin, that's craftsman) has display problems in the detailed record page (we have some local fixes that I can contribute) A specific problem with the detailed record page is the new subject display isn't displaying correctly in Internet Explorer 7; I wrestled with this for about an hour with no joy. * 1.4 - 1.6 database upgrade script (or autogen.sh) needs to include UPDATE metatada.metarecord SET mods = NULL; * 1.4 - 1.6 database upgrade script needs to add VIEW_ORG_SETTINGS to staff and MFHD permissions to catalogers, and possibly other perms There seems to be a problem editing MARC records that have URIs-as-copies (856 $9 SHORTNAME); attempting to reingest the record generates an SQL error due to a duplicate entry in the database, so the changes aren't saved; but the staff client claims Record successfully saved. Two things need fixing here: the record needs to be able to be saved correctly, and a failed save operation needs to be reported accurately. -- Dan Scott Laurentian University
Re: [OPEN-ILS-DEV] Z39.50 Server off by one
2009/5/15 Warren Layton warren.lay...@gmail.com: On Fri, May 15, 2009 at 10:38 AM, Dan Scott deni...@gmail.com wrote: I'm happy to say that this patch solved our off-by-one problem quite nicely. And I'm honestly happy to just have a working Z39.50 server, with the ability to scope searches by org_unit and surface holdings in a way that makes VDX happy, without worrying too much about whether the cause of the off-by-one lies in the Evergreen code or the Simple2ZOOM code. I'm now pretty sure that the problem is Simple2Zoom. So it looks like this patch fixes the cause, and not just the symptom. Just a follow-up, Simple2ZOOM 1.0.4 was released in June 2009 and it fixed the off-by-one error (although credit went to Simon jacob at the National Library of Australia (http://cpansearch.perl.org/src/MIRK/Net-Z3950-Simple2ZOOM-1.04/Changes) - at least the credit stayed in the Commonwealth!) So, new installs of the Evergreen Z39.50 server shouldn't have to apply any special patches. Thanks again, Warren. -- Dan Scott Laurentian University
Re: [OPEN-ILS-DEV] Fix for problems with org trees
2009/7/14 James Fournie jfour...@sitka.bclibraries.ca: Hello, I was having a horrible time getting the hasCommonAncestor() function to work in the circ Javascripts. I eventually discovered that ScriptBuilder.pm was making a cstore actor.org_unit search with flesh = 2, which limited the search to org units above depth 2. My org units were depth 3. I changed the cstore flesh to -1 and this seems to retreive all org units. I also found an similar problem in AppUtils.pm Ah, that would probably explain why hasCommonAncestor() was failing for us earlier on, when we had a deeper hierarchy than we currently have. Good detective work! Your suggested change seems quite rational to me. -- Dan Scott Laurentian University
Re: [OPEN-ILS-DEV] Release 1.6 - testing notes
2009/7/10 Dan Scott deni...@gmail.com: 2009/7/10 Dan Scott deni...@gmail.com: snip There seems to be a problem editing MARC records that have URIs-as-copies (856 $9 SHORTNAME); attempting to reingest the record generates an SQL error due to a duplicate entry in the database, so the changes aren't saved; but the staff client claims Record successfully saved. Two things need fixing here: the record needs to be able to be saved correctly, and a failed save operation needs to be reported accurately. Thanks to a recent commit from Mike Rylander, the first problem (record wasn't being saved successfully) is resolved. Many thanks, Mike! The second problem (save operation failed, but success was reported) probably needs deeper inspection along the error-handling chain, but that might be outside of the scope for 1.6. -- Dan Scott Laurentian University
Re: [OPEN-ILS-DEV] RIS SuperCat Feed
Patch applied to trunk and the rel_1_6 branch. I didn't push this into rel_1_6_0 because we're trying to finalize the release. Many thanks once again, Warren! 2009/7/9 Warren Layton warren.lay...@gmail.com: Sorry, forgot to include a DCO... -- Developer's Certificate of Origin 1.1 By making a contribution to this project, I certify that: (a) The contribution was created in whole or in part by me and I have the right to submit it under the open source license indicated in the file; or (b) The contribution is based upon previous work that, to the best of my knowledge, is covered under an appropriate open source license and I have the right under that license to submit that work with modifications, whether created in whole or in part by me, under the same open source license (unless I am permitted to submit under a different license), as indicated in the file; or (c) The contribution was provided directly to me by some other person who certified (a), (b) or (c) and I have not modified it. (d) I understand and agree that this project and the contribution are public and that a record of the contribution (including all personal information I submit with it, including my sign-off) is maintained indefinitely and may be redistributed consistent with this project or the open source license(s) involved. Signed-off-by: Warren Layton -- Dan Scott Laurentian University
Re: [OPEN-ILS-DEV] OpenSRF and Ubuntu 9.04
2009/7/28 Jason Stephenson jstephen...@mvlc.org: Quoting Bill Erickson erick...@esilibrary.com: I've heard some chatter in IRC about newer versions of Ejabberd causing problems. I haven't investigated yet myself, but that could have something to do with it. Newer versions of Ejabberd apparently don't like empty froms in the xmpp messages. OpenILS/OpenSRF sends messages with empty froms when it doesn't care to get a reply. We had to downgrade the Ejabberd by a version on our test box here. Unfortunately, my assistant who has the details is out on vacation this week. He figured out which version of Ejabberd had the issue and which one to downgrade to. Wiktor Rzeczkowski from McMaster University determined that the most recent version of ejabberd that works with Evergreen was 2.0.2 (http://list.georgialibraries.org/pipermail/open-ils-dev/2009-April/004508.html), due to this change: https://support.process-one.net/browse/EJAB-812 We should probably add this to the FAQ, as I keep on digging up these links. Or better, fix OpenSRF to start sending from messages :) -- Dan Scott Laurentian University
Re: [OPEN-ILS-DEV] ***SPAM*** Re: Export to RefWorks in Evergreen
2009/7/29 Warren Layton warren.lay...@gmail.com: Here's an extra little patch to add a Export to RefWorks link for bookbags (against trunk). The link only appears if the user's bookbag is shared (if it's not shared, Supercat feeds for the bookbag won't be visible to outside world, including RefWorks). It appears under the Shared column (right under Yes (View) [RSS]). Hi Warren: The logic looks good and the functionality is certainly useful. One problem in reading the patch: you've introduced a new entity, but there's no corresponding diff for opac.dtd. A minor nit is that the existing code in the context of your changes uses tabs, and you've got spaces. An aside: at some point, we're going to have to consolidate all of the per-skin config vars into a single file. If you resubmit the patch, can you include the DCO as well? Many thanks, again! -- Dan Scott Laurentian University
[OPEN-ILS-DEV] Duplicating prereqs installed by OpenSRF Makefile.install in Evergreen Makefile.install?
Quick note: in a recent set of commits, a number of prereqs (such as liblog-log4perl-perl) were added to the Evergreen Makefile.install file, but these are already part of the prereqs installed by the OpenSRF Makefile.install. This seems to run counter to the approach of first, install OpenSRF (and therefore install its prereqs); then, install Evergreen (and its own additional prereqs) that keeps the prereqs separate and avoids dual maintenance. Was this intentional (in which case, it would be useful to know why it is necessary), or just an oversight? -- Dan Scott Laurentian University
Re: [OPEN-ILS-DEV] Duplicating prereqs installed by OpenSRF Makefile.install in Evergreen Makefile.install?
2009/8/14 Shawn Boyette sboye...@esilibrary.com: Dan Scott wrote: Quick note: in a recent set of commits, a number of prereqs (such as liblog-log4perl-perl) were added to the Evergreen Makefile.install file, but these are already part of the prereqs installed by the OpenSRF Makefile.install. This seems to run counter to the approach of first, install OpenSRF (and therefore install its prereqs); then, install Evergreen (and its own additional prereqs) that keeps the prereqs separate and avoids dual maintenance. Was this intentional (in which case, it would be useful to know why it is necessary), or just an oversight? Thanks, Dan. No, this wasn't intentional, it was me getting back into working on osrf after a really long time, forgetting exactly how it wants to be built, and trying to be really aggressive about catching all dependencies. I'll get the dupes cleaned out today. Cool, the dupes don't really hurt, but it could get messy in the long run. Thanks for that! P.S. I don't know exactly how long it's gonna take, but you're getting your wish for a (testing | optional sample) database at install time. Wow, awesome! Just minutes ago I wrote a separate message about that wish. You make me smile. -- Dan Scott Laurentian University
Re: [OPEN-ILS-DEV] Apache conf improvements
On 02/09/2009, Joe Atzberger a...@esilibrary.com wrote: I'm not trying to make the decision whether SSL is required for Evergreen or not. In fact, I explicitly added to the documentation: a2enmod ssl# enable mod_ssl If I recall correctly, that step is already in Makefile.install - and to date, anything that can be automated easily goes into Makefile.install and is not part of the distro-specific wiki directions (http://open-ils.org/dokuwiki/doku.php?id=server:1.4.0:install). The generic install instructions (http://open-ils.org/dokuwiki/doku.php?id=generic_installation_information) are probably wildly out-of-date, and like many pages on the wiki they need to either be updated or possibly deleted. I could see the generic install instructions including all of the explicit steps that are coded into Makefile.install simply to surface all of the implicit knowledge that is maintained there (we need X because of Y, etc), but boy howdy that would be a lot of work. Adding in the additional / dropped requirements for various releases complicates things in the generic install instructions just a bit more. On the other hand, it would significantly help people who want to add support for other distros (RHEL / OpenSUSE) / operating systems (*BSD, OpenSolaris). I guess it's a question of how much effort we want to put in that direction, and calculating the return on investment of that particular effort (versus, say, providing more how to develop new OpenSRF methods and services type documentation that would potentially enlarge the size of our development community and welcome new developers to the project). To date, things have been pretty much focused on Debian/Ubuntu with Makefile.install because to this point the primary goal has been to just get people up and running at a basic level. I'm sure the Documentation Interest Group (DIG) has ideas about expanding those goals (thankfully!) and there's probably room for a discussion about what the DIGgers want to do with the wiki. All that (mostly blather) said, welcome to the Evergreen community Joe! It's fabulous to have you on board; I'm sure your energy attention to detail will be a great boon to the project! -- Dan Scott Laurentian University
Re: [OPEN-ILS-DEV] Problems with Backup
2009/9/2 John van Rassel jvanras...@innisfil.ca: I have tried running this, and it still doesn't find anything. The search just sits and spins. I also did do the autogen. Hmm. Any errors being reported in the PostgresSQL server log or in the Evergreen logs? It's possible that, if this is a new database server, some of the required database server dependencies (such as the Perl module JSON::XS) haven't been installed and the creation of some of the required functions during the database restore failed. If no errors are being reported, can you ensure that SQL statements are being logged and rerun the search queries manually to see if those return results? That would take the time-out problem out of the equation. -- Dan Scott Laurentian University
Re: [OPEN-ILS-DEV] Apache conf improvements
2009/9/2 Joe Atzberger a...@esilibrary.com: Dan Scott wrote: On 02/09/2009, Joe Atzberger a...@esilibrary.com wrote: I'm not trying to make the decision whether SSL is required for Evergreen or not. In fact, I explicitly added to the documentation: a2enmod ssl # enable mod_ssl If I recall correctly, that step is already in Makefile.install - and to date, anything that can be automated easily goes into Makefile.install and is not part of the distro-specific wiki directions (http://open-ils.org/dokuwiki/doku.php?id=server:1.4.0:install). Yeah, and if I can get to it, I'll also be touching that to prevent that step from crashing on Debian etch, as it did during my initial attempts. Hmm, strange that no one else has reported that problem. I suspect most of us are working with Debian Lenny / Ubuntu Hardy these days. It might be worthwhile discussing how much effort we want to put into the support of Etch for Evergreen 1.6 / 2.0 given that Lenny has been out since the spring. Among other things, we apparently need to force install of Yaz, at least until indexdata fixes or forgoes a dependence on their remote test server (and your open firewall allowing access to it). Argh, not that problem again! I had hoped they would have learned from the last time. More notably, the package libuuid-perl isn't available in etch (or in my backports apt source). I had to cpan B/BR/BRAAM/UUID-0.02.tar.gz explicitly. Lacking that also crashed apache, due to the startup script. Hmm, this explains something... you're trying to complete an end-to-end install of a development release using an install document for the stable version of Evergreen. That said, I think that the contributor community is starting to grow at the rate that keeping a separate set of install documentation up to date with trunk would be a good way of avoiding needless re-discovering of the same new / revised requirements and steps. Also need to add a2enmod xmlent, but at a later point after that EG-specific piece is compiled and available, before the apache restart. Hmm. I don't think anyone else has mentioned this as a requirement before; is that new with trunk? In general, I think we need at least one end-to-end install document. It doesn't matter for what platform. Any distro-specific docs can replicate it, or be more of a diff, saying effectively Do steps 1-6 from the main doc. For step 7, do . Sure, that sounds reasonable. FWIW, there used to be separate Ubuntu and Debian install pages, but the diffs were so small, and with the annoyance of making the same changes to each page (or worse, making a change to one but forgetting the other) I consolidated them back in February. Ironically, now that the 'change Apache user to opensrf' section was struck out and an editorial comment was added that it shouldn't be necessary, etc, we no longer have an end-to-end install document for Evergreen 1.4. As distasteful as the 'change Apache user to opensrf' approach may be, it does work. To enable new users to continue to complete installs with the stable version successfully until a different Apache / opensrf approach is agreed on, a different way of resolving the problem would be to bring forward discomfort with that approach forward to the list, find out why that's the approach currently, and based on that understanding offer suggestions for how to avoid having to make that change (whether it be fine-grained sets of permissions that need to be changed under the /openils/var subdirectories or whatever). We also need a chart of what OpenSRF versions are compatible with what versions of EG. That makes a lot of sense. And the start/stop controls for router and others could be more bulletproofy. I'll stop now Sounds good! Your fresh eyes are probably going to find all kinds of rough areas that are invisible to many of us now, and that will definitely help improve the project. -- Dan Scott Laurentian University
Re: [OPEN-ILS-DEV] making pre-req installs %.001 more automated
2009/9/3 Bill Erickson erick...@esilibrary.com: Are there any objections to adding the -y and -q flags to aptitude in the prerequisite installer makefile for OpenSRF and Evergreen? No objections here! +1 -- Dan Scott Laurentian University
Re: [OPEN-ILS-DEV] When someone's who's better at Perl than I am is bored....
2009/9/9 John Craig jc-mailingl...@alphagconsulting.com Hi Folks, Just for the heck of it (less important now with the -l flag available on the osrf_ctl.sh command line), but this Perl one-liner in opensrf.xml.example is okay, as far as it goes, but the resulting display is confusing (it'd sure be nice to have a newline after it so that the following prompt doesn't just neatly join right up with it): perl -MNet::Domain -e 'print Net::Domain::hostfqdn();' Returns (for example): r...@nearly:/home/opensrf# perl -MNet::Domain -e 'print Net::Domain::hostfqdn();' nearly.adomain-name.comr...@nearly:/home/opensrf# I'm not Perlish enough to know what it needs to do this instead: r...@nearly:/home/opensrf# perl -MNet::Domain -e 'print Net::Domain::hostfqdn();' nearly.adomain-name.com r...@nearly:/home/opensrf# But it'd be worth it if it's not too difficult. John Try: perl -MNet::Domain -e 'print Net::Domain::hostfqdn() . \n;' This is actually in http://svn.open-ils.org/trac/ILS/browser/trunk/Open-ILS/examples/opensrf.xml.examplebut not in the corresponding OpenSRF trunk example. Dan
[OPEN-ILS-DEV] Rethinking the release process: (was: Trac usage, EG Versions)
On Fri, 2009-09-11 at 20:24 -0400, Joe Atzberger wrote: I'm looking to formally record in Trac the various bugs encountered during development and testing. Right now, the number of EG Versions to file against are a small subset of the actual number of available versions (plus 2.0 that doesn't yet exist). So I have a couple questions: * How should the 2.0 Version should be used? * What level of granularity do we want: each increment, major.minor only, something else? * What about trunk? I suggest we probably want each increment, but more important than that, I think we need a version for trunk (or HEAD) where the majority of bugs and enhancements will be filed... and some hopefully fixed. It would be counterproductive to file enhancements against a stable version, since all the new features should be going against trunk when possible. And you don't want it against whatever number version happens to be current now, because if the ticket sits a while or the feature takes more time to develop, it needs to keep up w/ the progressing version numbers and not look like a piece of history. Any thoughts on this? Hey Joe: A simple reply would be that one can and should modify tickets if a feature targeted for a given release gets bumped to a subsequent release. However, I think it would be worth revisiting how releases work in general; this is just one aspect (but an important one, I would love to see more formal use of Trac for bugs and features and I think it would be very healthy for the community). Our development and release process is a work in progress, as http://open-ils.org/documentation/contributing.html states. I'm going to suggest a few changes of direction that might help us move towards a more agile release process (and hopefully get a conversation going about other changes that we might want to consider). * Time-based releases: We've seen projected release dates slip because we were trying to fit a feature into a given release and waiting on that feature to be finalized. Meanwhile, other enhancements get stuck waiting on that release. Generating a regular (monthly? weekly? daily?) release tarball would give us the opportunity to have regular, objective feedback on the quality of our releases, get new features into the hands of interested parties with less hassle, and still give us the ability to anoint a given tarball an official release. But this won't be possible without a few other wishlist items: * Automated releases: Right now, the effort required to cut a release comes down to a whole lot of (rather poorly documented) manual work that doesn't really encourage a release often approach. If we were to automate the process of creating a release tarball corresponding staff client, we could start pumping out time-based releases that could get new features into the hands of testers or adopters earlier. This would require us to be disciplined about maintaining a database upgrade script each time the database schema is modified, rather than the heroic effort that miker has put into each and every database upgrade script to date. We would find out right away if fundamental pieces of the build break due to dependencies (such as the translations, which frustrated miker a while back when some of the Python modules used by the build were updated and broke our existing translation build scripts). * Automated testing: This is one area where Evergreen, a complex beast, is currently frighteningly weak - but I hear that there's some work underway to build a sample database, which would be a great base for a suite of regression tests (at least at the OpenSRF level; automated testing of XUL / Dojo interfaces / catalogue is another more complex kettle of fish, but it has been done by others...) Once we have that base available to us, I think it should be a condition that each new feature should come with a suite of tests to ensure that changes in another part of the stack (whether our code changes, or changes to external dependencies - hello, PostgreSQL 8.4!) don't unintentionally affect how this particular feature works. There's loads of room for adding test coverage of existing functionality, of course. When a bug is found, a test should be added that triggers the bug (and when the bug is fixed, the test will start passing). * Divide and conquer responsibilities: I think there are a number of responsibilities that could be picked up by more members of the community. Sharing responsibilities across a broader team should make everyone more efficient (at the cost of some communication and coordination overhead). Some ideas about possible roles: * Translation management, currently rather poorly done by me, could be relatively easily picked up by someone else (particularly if Pootle is adopted as an official tool). * Platform owners - people responsible for testing Evergreen releases on a particular distribution maintaining installation documentation /
[OPEN-ILS-DEV] ***SPAM*** Bug reporting (was: Evergreen Release Candidate 1.6.0.0RC1 is available)
On Mon, 2009-09-14 at 15:08 -0400, Grace Dunbar wrote: The Evergreen development team is pleased to announce the immediate availability of Evergreen 1.6.0.0RC1. I'm very glad to hear it's out, although as one of the members of the development team, I'm also a little surprised by the announcement. There hasn't been any discussion about releasing 1.6 on the dev list for quite some time. Was there a recent discussion on IRC that I missed in the logs? 1.6.0.0RC1 is a release candidate and, while we encourage our clients and community with test servers download this version to test, we do not endorse putting 1.6.0.0RC1 directly into production. The bug reporting window for 1.6.0.0RC1 will open on September 14, 2009 and close on October 2, 2009. Okay, so we are trying out a form of time-based releases then? Cool. For general community members reporting bugs, please send them to the development mailing list at Open-ils-dev@list.georgialibraries.org and please include “bug” and “1.6.0.0RC1” somewhere in the subject. If you have a support contract with an Evergreen vendor, please submit any bug reports through your normal support channels. I disagree with this suggestion. As the number of support vendors grows, I think it becomes more important to have bug reporting centrally and openly visible, rather than dividing the bug reports up between vendor support channels. Otherwise, there will be a duplication of effort on the part of testers and bug fixers - and some important but obscure bugs might be hidden that could otherwise be fixed by the community. Reporting the problem to a vendor support channel as well is fine, but I believe the priority channel for bug reporting should be the dev mailing list (in lieu of any more formal openly accessible bug reporting systems). The one exception might be security bugs, but those should probably go to a closed security list rather than only to vendor support channels.
Re: [OPEN-ILS-DEV] 1.6.0.0RC1 database update errors
On Mon, 2009-09-14 at 16:31 -0500, Alan Rykhus wrote:
Hello,
I had just recently installed Evergreen 1.4.0.4, had it up and running,
but had not loaded any data into it yet. I ran the upgrade and I'm on
the upgrade database step. I see 1 ERROR that doesn't bother me too much
and 2 that do.
Hi Alan - all of these errors are actually expected and you should be
okay. I'll explain more below, but as an aside to the dev team perhaps
we should consider shipping database upgrade scripts written in Perl so
that we can catch expected errors rather than issuing raw SQL (which
would also be subject to an individual user's ON_ERROR_STOP preferences,
which could cause problems if ON_ERROR_STOP=yes).
Error 1:
psql:Open-ILS/src/sql/Pg/1.4.0.5-1.6.0.0-upgrade-db.sql:3979: ERROR:
duplicate key violates unique constraint perm_list_code_key
Which corresponds to:
INSERT INTO permission.perm_list (code, description) VALUES
('DELETE_RECORD', 'Allow a staff member to directly remove a
bibliographic record');
Since this entry already exists, the error doesn't seem too bad.
Right, no need to worry about it.
Errors 2 and 3:
psql:Open-ILS/src/sql/Pg/1.4.0.5-1.6.0.0-upgrade-db.sql:4044: ERROR:
relation auditor.action_hold_request_history does not exist
psql:Open-ILS/src/sql/Pg/1.4.0.5-1.6.0.0-upgrade-db.sql:4045: ERROR:
relation auditor.action_hold_request_history does not exist
These correspond to:
ALTER TABLE auditor.action_hold_request_history ADD COLUMN cancel_cause
INT;
ALTER TABLE auditor.action_hold_request_history ADD COLUMN cancel_note
TEXT;
These tables do not exist in the database, so this seems like an area of
concern.
There are apparently sites that have set up auditing of extra tables,
and these lines are directed towards them. We should add at least a
comment to the script telling people not to worry about it when it
throws an error (or, if the DB upgrade was written in Perl, just catch
the error and move on without disturbing the user) - but I wonder
whether it makes sense to have the publicly available release be
internally consistent so that it doesn't throw extraneous errors.
[OPEN-ILS-DEV] 1.6 RC1 browser support for bibtemplate
First, a heads-up that Opera doesn't support the bibtemplate structure at all. I believe that's due to Dojo only officially supporting Opera on dojo core, not the dojox extensions. Probably not a huge concern with Opera hovering around 2% of browser market share, but when I'm browsing the Web on my Wii it would be so nice to have item details displaying properly... heh. Second, a slightly more obscure but also more serious bug (based on browser market share) is that Internet Explorer (6,7,8) don't support one of the advanced bibtemplate features; check the URL display for items that have located URIs; in IE, the URLs that are displayed always come from the bib record, rather than from the asset.uri table. I don't have a test case ready at hand, unfortunately, as I'm on leave at the moment, but it should be pretty easily reproducible. The item details template that we're using can be seen at http://laurentian.concat.ca with the most pertinent source at http://svn.open-ils.org/trac/ILS-Contrib/browser/conifer/trunk/web/opac/skin/default/xml/rdetail/rdetail_summary.xml An aside, Safari (at least on Windows) and Chrome / Chromium seem to work with bibtemplate just fine.
Re: [OPEN-ILS-DEV] Suggestion for handling country-specific variations in org_unit.html
On Wed, 2009-09-16 at 17:53 -0400, Ben Ostrowsky wrote: At the moment, org_unit.html requires a county, which doesn't have a whole lot of meaning in Canada, and uses a hardcoded regex for the postal code. For Canada, the regex /^[ABCEFGHJKLMNPRSTVXY][0-9][ABCEFGHJKLMNPRSTVWXYZ][\s]?[0-9][ABCEFGHJKLMNPRSTVWXYZ][0-9]$/ is appropriate. Good catch! Should this be stored in an org_unit_setting? Should it be an entity like conify.org_unit.addresses_pane.zip.regex; instead? I leave it to y'all to find the most sensible implementation. Tough question. mod_xmlent is probably the easiest short-term way of handling sets of regional settings like this - but it would also introduce more complexity for translators (who shouldn't be expected to have to maintain regular expressions). Raw org_unit settings are a bit unwieldy, if a required boolean and a validation regex would need to be manually maintained for each individual field. Perhaps there's a middle ground where one could choose a region for an org_unit (e.g. Canada) when initially creating it, and that would set the corresponding org_unit settings - which could then be subject to a manual override.
[OPEN-ILS-DEV] 1.6 RC1 (and 1.4 and probably before) subject searching
The subject search in bibtemplate, interestingly enough, searches
against the keywords index rather than the subject index.
This might just be a fortuitous mistake, but I suspect it is because
the subject index doesn't currently support searches of compound
subjects composed of topic + temporal + geographic headings.
The subject search:
http://laurentian.concat.ca/opac/en-CA/skin/lul/xml/rresult.xml?rt=subjecttp=subjectt=Great%20Britain%20History%20Wars%20of%20the%20Roses%2C%201455-1485.%20l=105d=1f=av=
results in 0 hits.
The keyword search:
http://laurentian.concat.ca/opac/en-CA/skin/lul/xml/rresult.xml?rt=keywordtp=keywordt=Great%20Britain%20History%20Wars%20of%20the%20Roses%2C%201455-1485.%20l=105d=1f=av=
results in 5 hits. Some of these hits are because the desired keywords
fall outside of the subject fields, but if you take a record (say,
ISBN 041596864X) and remove all of the pertinent keywords from
non-subject fields, reindex the record and resubmit the keyword
search, you'll see that the keyword search using the compound subject
terms does retrieve the desired record. Or just create a minimal
record with the following field: 651 0. ‡aGreat Britain ‡xHistory
‡yWars of the Roses, 1455-1485.
If you peek at the metabib.subject_field_entry table, you'll see that
the subject terms are all there, but broken up across entries.
Presumably, this is why the compound search doesn't find a hit against
them.
One way that I documented back in February
(http://coffeecode.net/archives/183-Evergreen-Exposed-introduction-to-Evergreen-development-OLA-2009.html)
of resolving this problem is to add an additional entry to the subject
search index:
INSERT INTO config.metabib_field (field_class, name, xpath, weight,
format, search_field)
VALUES ('subject', 'flat', '//mods32:mods/mods32:subject//text()',
1, 'mods32', 't');
Once that has been added, you can reindex all of your records and
compound subject searches will work as expected.
However, I would suggest that it would be better to have this as part
of the default search indexes in 1.6 - and that the bibtemplate
subject search should then be adjusted to search the subject index
accordingly, to avoid false positives that occur when using the
keyword index.
From a migration perpsective, one could conceivably avoid the cost of
reindexing all of the records by iterating over all of the unique
values of source in msfe and populating an additional row containing
the union of the subject terms for each source record. Once that's
complete, insert the new config.metabib_field entry and the system
would be golden.
If there's a better way of solving this problem, that would be great,
as adding the //mods32:mods/mods32:subject//text() xpath means that
we're effectively indexing all subject terms twice if we keep the
existing temporal / topic / geographic subject indexes as well. Maybe
instead of adding the xpath, we could populate a view or use rules to
maintain an additional row based on a union of all subject terms for a
given record? Just brainstorming in a slightly sick fashion. But in
the short term, that slight additional bloat seems like a small price
to pay for making subject searches work the way that our users appear
to expect them to work.
