2011-08-17T01:17:02 *** mrpeters-isl has quit IRC 2011-08-17T02:54:41 *** dbs has quit IRC 2011-08-17T05:01:11 *** natschil has joined #evergreen 2011-08-17T05:27:18 *** Faiz has joined #evergreen 2011-08-17T05:27:46 I have problem installing Evergreen 2011-08-17T05:28:20 i am using ubuntu lucid 10.04 server with no addons 2011-08-17T05:29:42 when i reach the command ./autogen.sh -c /openils/conf/opensrf_core.xml -u it gives error 2011-08-17T05:33:22 *** Faiz has left #evergreen 2011-08-17T05:40:38 *** Faiz_ has joined #evergreen 2011-08-17T05:44:47 *** Faiz has joined #evergreen 2011-08-17T05:46:01 *** Faiz has quit IRC 2011-08-17T05:46:28 *** mfaizch has joined #evergreen 2011-08-17T07:45:20 *** AaronZ-PLS has quit IRC 2011-08-17T07:45:21 *** bwicksall has quit IRC 2011-08-17T07:54:25 *** bwicksall has joined #evergreen 2011-08-17T07:59:03 *** collum has joined #evergreen 2011-08-17T08:10:28 *** Dmagick has quit IRC 2011-08-17T08:31:52 *** fortin has joined #evergreen 2011-08-17T09:00:24 *** akilsdonk has joined #evergreen 2011-08-17T09:05:06 *** dbs has joined #evergreen 2011-08-17T09:15:34 *** Dmagick has joined #evergreen 2011-08-17T09:15:38 So.... the 2.1 upgrade script really dislikes if for some unknown reason someone already has an evergreen schema defined. 2011-08-17T09:16:25 * tsbere would have more to say on that if he wasn't working with systems that are running a really early version of 2.2 2011-08-17T09:16:44 Well commenting out the line for CREATE SCHEMA evergreen helped a little 2011-08-17T09:16:53 I'm deciphering the next phase of bad upgrade errors now 2011-08-17T09:17:48 <_bott_> bshum: I'm testing/retesting moving all the way from 1.6.0.x to 2.1 ...talk about fun! 2011-08-17T09:18:00 _bott_: That sounds much more adventurous! 2011-08-17T09:18:15 Huh 2011-08-17T09:18:24 2.0-2.1-upgrade-db.sql:960: ERROR: cannot ALTER TABLE "circ_matrix_matchpoint" because it has pending trigger events 2011-08-17T09:18:31 Guess that's not good. 2011-08-17T09:19:04 <_bott_> I've got my process down to under 5 hours... well, I hope. Ask me in about 4 1/2 2011-08-17T09:19:15 Heh 2011-08-17T09:19:24 I think our 1.6 to 2.0 upgrade took a really long time. 2011-08-17T09:19:37 bshum: That can be annoying. I suspect there is an "update circ_matrix_matchpoint" statement or two before a second altering. 2011-08-17T09:20:01 <_bott_> oh yeah, the 1.6.1-2.0 is the most time consuming 2011-08-17T09:20:13 bshum: One option, if you don't care about being able to rollback the *entire* upgrade transaction, is to put a "COMMIT; BEGIN;" block just before the line that failed there. 2011-08-17T09:20:20 tsbere: That line is the start of a huge block of transaction aborted errors. 2011-08-17T09:20:29 <_bott_> I've chopped out a lot of time by removing things that are done in several scripts along the way 2011-08-17T09:20:48 bshum: Provided, of course, that something else isn't hanging partially done that needs later lines to be completed. <_< 2011-08-17T09:21:31 *** eby has joined #evergreen 2011-08-17T09:22:54 tsbere: I guess it's worth a shot. 2011-08-17T09:23:08 _bott_: saving time by making several smaller commits rather than one huge commit-the-upgrade, or do you mean something else? 2011-08-17T09:23:52 I created my own 1.6 -> 2.0 script for our upgrade, partially because we had already backported bits of 2.0 when we upgraded, but mostly because we were upgrading to 2.0.4-ish and there were a number of near-dupe kicks at the can that I could eliminate from the 2.0->2.0.1, 2.0.1->2.0.2, etc scripts along the way 2011-08-17T09:24:11 <_bott_> jeff: removing duplicate lines that are setting id = id, just to fire triggers 2011-08-17T09:24:29 _bott_: got it. 2011-08-17T09:25:05 the "--upgrade-schema" option in the future should be granular enough to avoid all of those dupe iterations over "fix config.metabib_field and reindex" 2011-08-17T09:25:14 <_bott_> de-duping authority records ahead of time so the unique index succeeds... pre-creating facets so they can just be dumped back in... 2011-08-17T09:30:42 heh, we haven't deduped our authority records yet 2011-08-17T09:30:48 * dbs throws another task onto the pile 2011-08-17T09:33:45 *** Meliss has joined #evergreen 2011-08-17T09:44:30 *** jenny has joined #evergreen 2011-08-17T09:48:51 bshum: in addition to whatever final product works for your system, if you keep notes on specifically what didn't work (each, and why if you can find it) would be ENORMOUSLY helpful (may be obv, but thought I'd request it) 2011-08-17T09:49:22 *** StephenGWills has joined #evergreen 2011-08-17T09:49:41 Is there an obvious way to default the template toolkit opac to a specific search library? 2011-08-17T09:49:58 (obvious being "query parameter" compared to, say, "apache config") 2011-08-17T09:50:24 eeevil: Sure thing. I'm waiting for another run through right now. 2011-08-17T09:50:56 (on a different note, apparently the template toolkit opac isn't obeying org unit opac_visible rules?) 2011-08-17T09:51:01 And waiting for additional copies of our 2.0 system to restore so that I have more databases to run through. 2011-08-17T09:51:34 bshum++ 2011-08-17T09:51:47 bshum: I find it faster to restore once, then "create" new databases using the restored database as a template. 2011-08-17T09:52:12 (provided you are on a single DB server) 2011-08-17T10:03:22 tsbere: create new databases you say eh? 2011-08-17T10:03:38 How does that go? 2011-08-17T10:03:48 bshum: Replace the "template0" with the name of an actual database in the create command. 2011-08-17T10:04:03 And it will use the database you specified as the "source" 2011-08-17T10:04:25 You still have to adjust search order to put the evergreen schema first, though, if needed. >_> That doesn't get copied from the template, last I checked. 2011-08-17T10:04:48 I might try that sometime. 2011-08-17T10:05:04 2.1 upgrade round 3 died in a different place. 2011-08-17T10:05:16 So your suggestion to add that commit; begin; combo helped. 2011-08-17T10:07:17 Next error: http://paste.lisp.org/display/124085 2011-08-17T10:09:13 tsbere: http://localhost/eg/opac/home?loc=4 works for me 2011-08-17T10:09:37 Hmmm. 2011-08-17T10:09:48 Maybe Dyrcona's install is missing a patch or two. 2011-08-17T10:12:02 Ah, bad data I guess 2011-08-17T10:12:04 Boo 2011-08-17T10:12:38 *** matt_carlson has joined #evergreen 2011-08-17T10:13:25 did the trustworthiness of #evergreen just level up? 2011-08-17T10:22:19 ah, the joys of editing action_trigger.event_definition templates via SQL 2011-08-17T10:25:36 "joys" sure. 2011-08-17T10:26:57 * dbs hasn't tried the action_trigger UI for editing templates recently but found it distinctly untrustworthy in days of yore 2011-08-17T10:26:59 dbs: how about regex in csv? 2011-08-17T10:27:13 type,pattern,repl 2011-08-17T10:27:15 "all","""([^""]+)""\.GWIA\.GW_DOMAIN(@staff.example.net)?","\1" 2011-08-17T10:27:40 jeff: regex in csv in json via SQL <_< 2011-08-17T10:27:41 whatever gets the job done :) 2011-08-17T10:28:00 Definitely very untrustworthy. 2011-08-17T10:34:27 Gah, there are 87 records where the call numbers under them have the same label. 2011-08-17T10:34:44 Weird migration strangeness, maybe? (one would have expected 2.0 to not allow this to occur) 2011-08-17T10:35:23 you're talking about a violation of asset_call_number_label_once_per_lib? 2011-08-17T10:35:57 Yeah 2011-08-17T10:36:04 I have 87 cases so far where that happened. 2011-08-17T10:36:13 i know that's a unique index in 1.6.0 because i hit it the other day with trying to bring back some deleted volumes. dunno about 2.0. 2011-08-17T10:36:21 Hmm 2011-08-17T10:36:30 Then I definitely think something went wonky in our data. 2011-08-17T10:37:48 * tsbere is getting tired of deleted items being checked out to people 2011-08-17T10:38:07 jeff: http://paste.lisp.org/+2NQT/1 is the query I'm using to find these strange occurances 2011-08-17T10:38:49 you can probably simplify to WHERE NOT acn.deleted 2011-08-17T10:39:03 umm. 2011-08-17T10:39:14 might be. 2011-08-17T10:39:40 jeff: Right, that was just following something I saw in the index create in the upgrade script 2011-08-17T10:39:46 * bshum adjusts 2011-08-17T10:47:36 Well I guess we'll double check to make sure we can't duplicate volume labels in 2.0 then. 2011-08-17T10:47:42 Thanks jeff :) 2011-08-17T10:48:00 \d asset.call_number should show the index 2011-08-17T10:51:36 *** jenny has quit IRC 2011-08-17T10:53:50 "asset_call_number_label_once_per_lib" UNIQUE, btree (record, owning_lib, label) WHERE deleted = false OR deleted IS FALSE -- on our 2.0 system 2011-08-17T10:55:13 bshum: then you seem to have been correct in using that criteria -- ignore my suggestion there. :-) 2011-08-17T10:55:18 * dbs prefers munging AT templates via SQL to munging MARCXML via SQL... but off he goes to do the latter anyway 2011-08-17T10:56:11 *** wolf29 has joined #evergreen 2011-08-17T10:56:23 I'm testing the 2.0 client to see if there's any reason why this is happening on our system. 2011-08-17T10:56:25 jeff: you need both because (pre-9.0 at least, and probably 9.0 as well) queries on "deleted = false" wouldn't use the index for "deleted IS FALSE" (and vice versa) 2011-08-17T10:56:40 dbs: aha! 2011-08-17T10:56:42 So far, no luck. 2011-08-17T10:56:50 bshum: migration, then? 2011-08-17T10:56:51 So it might just be strange data issues. 2011-08-17T10:56:59 Yeah, migration-related oddities, maybe. 2011-08-17T10:57:32 Good morning 2011-08-17T10:57:50 wolf29: Morning! And wolf29++ for writing steps for PG 9 upgrade :) 2011-08-17T10:57:58 bshum: my understanding of unique indexes might be off, but i'm having trouble imagining how the index and the data you're reporting could co-exist. :-) 2011-08-17T10:57:59 :-) 2011-08-17T10:58:10 I hadn't finished mine yet, so it's awesome that you got there first. 2011-08-17T10:58:21 jeff: That's what I find surprising. 2011-08-17T10:58:38 oh hey. 2011-08-17T10:59:16 wolf29: Just a question though, and I'd been kicking myself all weekend when I did it... 2011-08-17T10:59:18 nope, all the columns in the index are "not null". 2011-08-17T10:59:59 wolf29: I'm sure it depends on what site you are and how patient one is, but would doing a massive pg_dumpall and then psql reinsert take longer than using pg_dump/pg_restore? 2011-08-17T11:00:32 wolf29: I found that in our case, it took pretty long waiting for things to restore from a full data dump/ load 2011-08-17T11:01:18 bshum - that is a good question to which an answer I do not have. I have not done this with a "real" database 2011-08-17T11:01:54 bshum: the 8.4 docs have a Note not to use unique indexes as constraints directly. 2011-08-17T11:02:07 ``The use of indexes to enforce unique constraints could be considered an implementation detail that should not be accessed directly.'' 2011-08-17T11:02:36 I guess the easiest way to estimate would be do both pg_dump and pg_dumpall and diff the output files 2011-08-17T11:03:07 pg_restore also gives you parallel restore capabilities 2011-08-17T11:03:26 I can try that with our little demo db and see 2011-08-17T11:03:55 dbs: That's what I was thinking after I got stuck in agonizing wait for our psql load. 2011-08-17T11:04:24 * dbs thought he had written up the steps he used to get from 8.4 to 9.0 somewhere 2011-08-17T11:04:31 The 2.0 "official" DIG instructions for PG 9 upgrade don't suggest that idea anywhere. 2011-08-17T11:04:52 That's what I was working with as a baseline at first before diverging on my own exploration. 2011-08-17T11:04:57 but my experience also involved moving from Debian Lenny to Debian Squeeze, so no inplace upgrade 2011-08-17T11:05:45 jeff: Well, while we clean up our real database of these oddities, I'm just going to delete the items and call numbers affected in our test systems so that I can keep churning away at the 2.0-2.1 upgrade path 2011-08-17T11:12:37 bshum dumpall gives me a 2.69MB file, but dump gave me a 687B file 2011-08-17T11:13:59 I must have messed up my options in dump 2011-08-17T11:17:28 pg_dump evergreen -f outputfile left me with more similar sizes, but pg_dumpall was still 2.6KB larger 2011-08-17T11:28:34 *** mmorgan has joined #evergreen 2011-08-17T11:28:44 I think pg_dumpall includes stuff like login data, etc. 2011-08-17T11:28:51 login users, I mean 2011-08-17T11:37:11 ahh, good old tag=""... love it 2011-08-17T11:41:23 dbs: an example of the truly minimal metadata scheme we all aspire to? 2011-08-17T11:42:30 gmcharlt: heh. candidates for an is_well_formed_marcxml() variation on is_well_formed_xml() perhaps :) 2011-08-17T11:44:13 I think in the olden days the MARC editor would happily create (sometimes with a thrown in for good measure) 2011-08-17T11:44:39 dbs: agreed 2011-08-17T11:45:22 a wrapper for MARC::Lint would be helpful to, although most likely not as an insert/update trigger except for the truly particular 2011-08-17T11:47:16 having some way of bubbling the results back up to the MARC editor / Vandelay / etc would be super-nifty, on top of all of that 2011-08-17T12:24:16 *** jenny1 has joined #evergreen 2011-08-17T12:34:10 *** fortin_ has joined #evergreen 2011-08-17T12:36:07 *** fortin has quit IRC 2011-08-17T12:36:21 *** fortin_ is now known as fortin 2011-08-17T12:39:28 *** Justin__ has joined #evergreen 2011-08-17T12:51:03 *** Justin__ has quit IRC 2011-08-17T12:55:07 *** bjwebb has joined #evergreen 2011-08-17T12:55:07 *** bjwebb has joined #evergreen 2011-08-17T13:03:04 *** jamesrf has joined #evergreen 2011-08-17T13:05:07 berick: just pushed the "assume username in TPAC login in the absence of a barcode regex" change we discussed yesterday to the collab branch 2011-08-17T13:09:08 dbs++ 2011-08-17T13:09:38 _now_ I can try to replicate the big ol' list problems Dyrcona had reported :) 2011-08-17T13:11:32 * dbs is amused that after adding something to a list, the page refreshes but doesn't show that the item was added to the list until the subsequent page refresh 2011-08-17T13:12:26 apparently for items after the first one on a given page have been added, fwiw 2011-08-17T13:13:01 huh. seems to work now. 2011-08-17T13:13:04 * dbs scratches head 2011-08-17T13:13:10 http://paste.lisp.org/+2NQT/2 - facet trigger error, need to drop it first before creating it? (since it somehow already exists) 2011-08-17T13:13:52 inconsistent 2011-08-17T13:16:50 dbs: replicated db? 2011-08-17T13:17:04 jeff: nope, running locally on my laptop 2011-08-17T13:17:35 (t-pac branch, using the t-pac list UI) 2011-08-17T13:17:36 ah. sunspots, then. 2011-08-17T13:17:40 up to 38 items, still no problems 2011-08-17T13:21:00 two lists, one with 10 items, with with 48 items, still no problems 2011-08-17T13:21:53 although a list-oriented person is definitely going to want some more affordances on the list UI; showing all items of all lists on "My Lists" probably won't cut it :) 2011-08-17T13:22:10 still, awesome to have lists in the T-PAC - senator++ berick++ 2011-08-17T13:22:21 * berick agrees showing all won't cut it 2011-08-17T13:23:14 and links to the actual records, yada yada, it's all gravy for now 2011-08-17T13:24:09 oh ho ho 2011-08-17T13:24:52 we have a little XSS vulnerability in bookbag names in t-pac 2011-08-17T13:25:08 * dbs buckles down 2011-08-17T13:25:25 * berick plays Eye of the Tiger 2011-08-17T13:26:14 * dbs will delay his +1 response until that little bug is fixed 2011-08-17T13:26:20 and commences fixing 2011-08-17T13:35:14 * dbs thought there used to be more " | html_entity" escaping in play. hmm 2011-08-17T13:35:48 lots of bugs we're talking about in ttopac, and it's easy to lose track of them until we put them in LP. and we can't really put them in LP (at least without breaking convention) until tto's merged to master. so... where's that vote? 2011-08-17T13:35:48 *** kmlussier has joined #evergreen 2011-08-17T13:36:02 oh, right there on the list 2011-08-17T13:36:02 good 2011-08-17T13:36:29 I'm -1 right now 2011-08-17T13:37:14 which is why I'm not posting anything to the list until I sort out how much XSS we're looking at 2011-08-17T13:38:10 dbs: feel free to point me at something 2011-08-17T13:38:37 fwiw, there's no reason IMO we can't enter bugs in launchpad for major features that should stay as branches until there is no known severe brokenness 2011-08-17T13:39:06 I think we could just add a series for TPAC for that purpose if it would make you feel better 2011-08-17T13:39:36 i'm equally fine with leaving series unset or whatever else if you are 2011-08-17T13:47:35 *** jenny1 has quit IRC 2011-08-17T13:50:35 *** jenny1 has joined #evergreen 2011-08-17T14:02:52 * dbs lols at , wishes it wrapped "man" 2011-08-17T14:27:28 *** matt_carlson has quit IRC 2011-08-17T14:40:02 *** matt_carlson has joined #evergreen 2011-08-17T14:55:39 *** jenny1 has quit IRC 2011-08-17T15:33:11 *** fortin has quit IRC 2011-08-17T15:42:43 *** jcarocci has joined #evergreen 2011-08-17T15:58:41 *** Meliss has quit IRC 2011-08-17T16:02:03 *** matt_carlson has quit IRC 2011-08-17T16:07:04 *** jcarocci has quit IRC 2011-08-17T16:10:34 *** matt_carlson has joined #evergreen 2011-08-17T16:13:56 *** jenny has joined #evergreen 2011-08-17T16:22:06 *** collum has quit IRC 2011-08-17T16:32:07 *** kmlussier has quit IRC 2011-08-17T16:33:02 *** sal_ has joined #evergreen 2011-08-17T16:34:44 Compiling windows client from trunk source, and there is no xul 1.9.2.19 in pub/mozilla.org/xulrunner/releases/. There's 1.9.1.19, 2.0, 3.6.20, 5.0, 6.0, 6.0b5. Any suggestions? 2011-08-17T16:34:57 Mutter mutter mozilla rapid release cycle. 2011-08-17T16:35:56 I'd stick with 1.9.x 2011-08-17T16:36:44 1.9.2 is dead eh? 2011-08-17T16:36:54 Maybe we need to host that locally somewhere 2011-08-17T16:37:04 By locally I mean on the web server... 2011-08-17T16:37:19 Kind of like how phasefx did for 1.9.1.x for 1.6 back in the day? 2011-08-17T16:37:37 https://developer.mozilla.org/en/XULRunner_1.9.2_Release_Notes says "The current version of XULRunner 1.9.2 is 3.6.20" 2011-08-17T16:38:12 Oooh 2011-08-17T16:38:23 the version numbering changes making their way to xulrunner, it seems. 2011-08-17T16:38:27 Okay, so 3.6.20 it is :-) 2011-08-17T16:38:51 :-/ 2011-08-17T16:39:14 i make no claims as to how well it'll work, but please report back if it breaks :-) 2011-08-17T16:39:22 or works 2011-08-17T16:39:31 Will do, either way. 2011-08-17T16:40:05 *** gdunbar has quit IRC 2011-08-17T16:40:11 if nothing else, you'll likely need to tweak application.ini unless they have some "1.9.2 = 3.6.x" logic 2011-08-17T16:40:14 phasefx: right! 2011-08-17T16:40:26 If it doesn't, I still have a copy of the last one, 1.9.2.19 that I can throw on Lupin somewhere. 2011-08-17T16:41:24 as a non-developer, but one who got a bit burned by xulrunner's printing bug when updating to 1.6.1.8, I'm hoping there's a movement either towards a version of xulrunner that we customize for Evergreen,.... 2011-08-17T16:41:41 or away from xulrunner altogether 2011-08-17T16:42:21 there - I said that out loud ;-) 2011-08-17T16:42:35 with xulrunner matching pace with firefox, and with remote xul becoming not-recommended, i'm very interested in a non-xulrunner staff client. 2011-08-17T16:42:52 * causing problems again :-) 2011-08-17T16:43:24 we're going to start focusing on workflows. take a staff workflow, build something that staff interact with via a web browser. 2011-08-17T16:43:40 some staff will still have a full staff client, others may not. 2011-08-17T16:43:47 *** jenny has left #evergreen 2011-08-17T16:44:33 * phasefx works secretly on his ncurses client 2011-08-17T16:44:34 haven't yet determined if that will be mod_perl and tt on the/a server, but there will be ajaxy stuff with dojo or jquery, and an emphasis on touch/mobile devices. 2011-08-17T16:44:55 phasefx: koha had an curses client :) 2011-08-17T16:45:02 a curses too 2011-08-17T16:45:08 ipod touch with a bluetooth barcode scanner for weeding... taptap, and the item's weeded as far as the ils is concerned, etc. 2011-08-17T16:45:20 rangi: no one wanted to keep it going? 2011-08-17T16:45:32 bluetooth barcode scanner is easy. rfid looks tougher. 2011-08-17T16:45:38 pretty much yeah 2011-08-17T16:45:46 jeff: any chance you can do that as an Evergreen working branch? 2011-08-17T16:46:11 I'm sure you would have lots of people interested in helping. 2011-08-17T16:46:34 phasefx: http://photos.bigballofwax.co.nz/gallery2/main.php?g2_itemId=192 <-- history :) 2011-08-17T16:46:50 the idea is to do it from the start in the open, yes. working or contrib, depending on how deep the coupling is. 2011-08-17T16:47:02 Sigh. Forgot I can't download directly to VM. Mutter. 2011-08-17T16:48:01 * dbs is amused by the curses client 2011-08-17T16:48:02 rangi: awesome 2011-08-17T16:49:52 that was the second incarnation 2011-08-17T16:50:04 the first one used CDK, that one was Curses::UI 2011-08-17T16:50:30 * phasefx is playing with urwid for python 2011-08-17T16:50:43 *** wolf29 has quit IRC 2011-08-17T16:51:19 phasefx: http://invisible-island.net/cdk/ <-- we could crash the c libraries (seg fault) under heavy load, hence the rewrite to curses::ui 2011-08-17T16:51:44 BUT CAN IT PRINT RECEIPTS AND SPINE LABELS? 2011-08-17T16:51:54 receipts yes 2011-08-17T16:52:09 it threw stuff at lpq 2011-08-17T16:52:21 none of this fancy cups malarky :) 2011-08-17T16:52:48 dear cups: stop trying to snmp query my attached parallel port receipt printer, thanks. 2011-08-17T16:53:45 so, who all is going to access this year? 2011-08-17T16:57:16 * crashes VirtualBox. Okay, *that's* not supposed to happen. 2011-08-17T16:57:42 rangi: not i, sadly 2011-08-17T16:57:47 dang nabbit 2011-08-17T16:58:38 Well, fwiw, xulrunner 3.6.20 compiles nicely with the Evergreen 2.0.8 release stuff. 2011-08-17T16:58:51 I have to test it with 2.1 and master later, but presumably it's "fine" 2011-08-17T16:59:45 Well, when my server comes back up and I can get at the zip file, I'll have one datapoint for the master :-) 2011-08-17T17:00:52 * finds 1.9.2.19 zip file in share also (headdesk) 2011-08-17T17:00:57 I'll try it with 2.1 when my upgrade finally finishes. Hopefully I've worked out all our kinks. 2011-08-17T17:03:44 *** akilsdonk has quit IRC 2011-08-17T17:04:23 *** matt_carlson has quit IRC 2011-08-17T17:04:32 okay, will test and report tomorrow... thanks all! 2011-08-17T17:04:39 *** sal_ has quit IRC 2011-08-17T17:06:29 bizarre; http://localhost/eg/opac/results?qtype=author;query=S%C3%B8rensen%20Estrid;page=5;loc=1;detail_record_view=1 fails but http://localhost/eg/opac/results?qtype=author&query=S%C3%B8rensen+Estrid&page=0&x=0&y=0&fi%3Aitem_type=&loc=1&sort= works 2011-08-17T17:07:27 we get semicolons as param delimiters from the quick search links (author name, for example) 2011-08-17T17:08:03 *** mmorgan has left #evergreen 2011-08-17T17:08:20 or is it page=5 carrying over? hmm 2011-08-17T17:08:31 yep, that's it 2011-08-17T17:23:02 and instead of filing a bug, I'm pushing a fix 2011-08-17T17:23:05 pushed 2011-08-17T17:23:22 and I'm out of here 2011-08-17T17:28:16 *** dbs has quit IRC 2011-08-17T17:57:03 *** natschil has quit IRC 2011-08-17T18:24:45 *** StephenGWills has left #evergreen 2011-08-17T19:34:54 *** bjwebb has quit IRC 2011-08-17T20:50:35 *** Manderson has joined #evergreen 2011-08-17T21:12:01 *** Jesse has joined #evergreen 2011-08-17T21:12:27 *** Jesse is now known as Guest54667 2011-08-17T21:13:42 I hope this is a quick question. I'm installing Evergreen 1.6.1.8 on Ubuntu 10.04.03. During the OpenSRF installation process, I ran "make -f src/extras/Makefile.install ubuntu-karmic" (as root) and got the error message "No rule to make target ubuntu-karmic 2011-08-17T21:14:02 I ran it from /home/opensrf/opensrf-1.6.3 2011-08-17T21:14:37 I know this is something simple, but I can't locate the problem - any help would be appreciated 2011-08-17T21:15:30 Guest54667: Well, I would try ubuntu-lucid as a target instead. 2011-08-17T21:16:13 "ubuntu-karmic" was for Ubuntu 9.x I think, so wrong version. 2011-08-17T21:18:37 Guest54667: as bshum points out, Ubuntu 10.04 is known as "Lucid Lynx", so the ubuntu-lucid target would be a better fit. The reason you got that error "No rule to make target ubuntu-karmic" is because the OpenSRF 1.6.3 Makefile.install does not include a target for Karmic. 2011-08-17T21:19:11 Karmic isn't mentioned in the install wiki for OpenSRF 1.6.3, so it looks like it's only in the DIG pages. 2011-08-17T21:19:20 Ubuntu 9.10 (Karmic) is end of life, and no longer supported by Ubuntu 2011-08-17T21:22:21 can someone tell me, in the oils_web.xml file, what the base_path is suppose to point to? 2011-08-17T21:23:04 By default on my system is says /eg 2011-08-17T21:23:10 I don't believe I've ever altered ours. 2011-08-17T21:24:09 I assume that's a relative path, because I don't have a directory called "eg" off of root 2011-08-17T21:25:59 Manderson: I believe it's used when constructing URLs for some things. 2011-08-17T21:26:12 Not entirely sure :) 2011-08-17T21:26:32 Alright...I kind of figured it was something along those lines... 2011-08-17T21:36:35 *** Guest54667 has quit IRC 2011-08-17T21:40:08 Manderson: yes, the in oils_web.xml is used for urls, and does not correspond to an absolute path on the filesystem. 2011-08-17T21:49:28 thanks jeff 2011-08-17T21:50:03 I'm trying to scrub my conf files. I am doing a fresh install of evergreen onto a new debian server and I'm running into an error when running autoconf.sh 2011-08-17T21:50:25 sorry, autogen.sh 2011-08-17T21:50:49 Can't call method "opac_visible" on an undefined value at org_tree_html_options.pl line 55. 2011-08-17T22:01:09 you'll need the evergreen services running before you run autogen.sh -- are you to that point? 2011-08-17T22:04:15 Yes, I have everything running 2011-08-17T22:06:11 http://pastebin.com/SU3RBnXB 2011-08-17T22:10:19 what is your full autogen.sh command line? 2011-08-17T22:11:01 ./autogen.sh -c /data/openils/conf/opensrf_core.xml -u