| # | Time | Nick | Message |
|---|
| # | 00:10:42 | Kip_ has quit IRC |
| # | 00:43:37 | jamesrf has joined #evergreen |
| # | 01:12:04 | jennam has joined #evergreen |
| # | 06:05:59 | jennam has quit IRC |
| # | 06:11:09 | jennam has joined #evergreen |
| # | 06:26:38 | tater-laptop has quit IRC |
| # | 07:04:28 | mtisi has quit IRC |
| # | 07:15:46 | shopkins has joined #evergreen |
| # | 07:26:53 | sfortin has joined #evergreen |
| # | 08:01:21 | collum has joined #evergreen |
| # | 08:02:11 | tater-laptop has joined #evergreen |
| # | 08:35:43 | mtate has quit IRC |
| # | 08:35:45 | mtisi has joined #evergreen |
| # | 08:37:23 | kmlussier has joined #evergreen |
| # | 08:37:38 | mtate has joined #evergreen |
| # | 08:41:29 | rjackson-isl has joined #evergreen |
| # | 08:44:18 | tspindler has joined #evergreen |
| # | 08:52:23 | Dyrcona has joined #evergreen |
| # | 08:57:14 | berick | bshum: cool, glad it worked |
| # | 09:02:28 | dave-esi has joined #evergreen |
| # | 09:04:59 | dbs has joined #evergreen |
| # | 09:07:45 | Meliss has joined #evergreen |
| # | 09:09:07 | rsinger has quit IRC |
| # | 09:15:14 | rsinger has joined #evergreen |
| # | 09:18:20 | shopkins | hi, I installed rel_2_0_2 in mid feb no problems - tried to install on another server today and I keep getting "configure: error: "pgsql drivers not installed?' I have double check eg.conf file and made sure postgresql 8.4 is installed, any suggestions? |
| # | 09:20:49 | jenny has joined #evergreen |
| # | 09:29:26 | yboston has joined #evergreen |
| # | 09:29:43 | mrpeters-isl | hi shopkins! where in the install process does that appear? |
| # | 09:30:36 | dbs | shopkins: wild guess, you don't have the libdbi / libdbi-drivers installed |
| # | 09:30:44 | csharp pasted "EGWeb.pm error" at http://paste.lisp.org/display/120350 |
| # | 09:31:04 | csharp | symptom: cannot access any of the dojo interfaces |
| # | 09:31:28 | mrpeters-isl | csharp - this is familiar...hmm |
| # | 09:31:45 | mrpeters-isl | run settings tester? i'm wondernig if it's a db connection issues |
| # | 09:31:47 | csharp | I have one server that works (a standalone 'localhost' setup) and a clustered one that doesn't |
| # | 09:32:05 | mrpeters-isl | maybe the connection from brick01-head isn't allowed via pg_hba.conf ? |
| # | 09:32:35 | mrpeters-isl | i know i ran into this when first setting up bricks |
| # | 09:33:04 | dbs | csharp: you have an oils_web.conf file or whatever? |
| # | 09:33:06 | csharp | mrpeters-isl: settings_tester.pl checks out - thanks for the suggestion - good to rule things out |
| # | 09:33:20 | csharp | dbs: ah... - I bet that's it |
| # | 09:33:23 | csharp checks |
| # | 09:33:25 | mrpeters-isl | man, i know i've had this |
| # | 09:33:27 | dbs | oils_web.xml |
| # | 09:33:31 | dbs | in /openils/conf/ |
| # | 09:33:52 | csharp | dbs: that is the cause |
| # | 09:33:53 | csharp | thanks! |
| # | 09:33:59 | mrpeters-isl | http://paste.lisp.org/display/85268 in fact |
| # | 09:33:59 | csharp | hivemind++ |
| # | 09:34:13 | mrpeters-isl | http://www.open-ils.org/irc_logs/openils-evergreen/2009-08/%23openils-evergreen.03-Mon-2009.log |
| # | 09:34:21 | mrpeters-isl | jeff had the same solution as dbs :) |
| # | 09:35:01 | dbs | the power of reading source code |
| # | 09:35:10 | mrpeters-isl | hey csharp: http://lmgtfy.com/?q=Can%27t+call+method+%22mtime%22+on+an+undefined+value+at+%2Fopenils%2Flib%2Fperl5%2FOpenILS%2FWWW%2FEGWeb.pm+line+174. |
| # | 09:35:11 | mrpeters-isl | hehehehe |
| # | 09:35:18 | shopkins | dbs/mrpeters-isl - this happens after I restart postgresql 8.4 and before the Staff Build |
| # | 09:35:43 | dbs | shopkins: you've run Makefile.install ? |
| # | 09:35:47 | mrpeters-isl | shopkins: check what dbs said above regarding libdbi drivers |
| # | 09:36:08 | mrpeters-isl | csharp: sorry - haha i had to use that one someone - i thought it was hilarious |
| # | 09:37:16 | csharp | mrpeters-isl: ha! |
| # | 09:37:23 | mrpeters-isl | too funny, right? |
| # | 09:37:30 | dbs | perhaps the import() method in EGWeb.pm should out-and-out die() instead of return; ? |
| # | 09:37:44 | csharp | that's great - will add to PINES Helpdesk procedures manual |
| # | 09:37:49 | mrpeters-isl | hahah! |
| # | 09:38:10 | mrpeters-isl | thats why i needed to use it on someone who would laugh - otherwise i might be tempted to use it on someone who would be offended :) |
| # | 09:39:24 | dbs | at the very least, check_web_config() should check to ensure that $web_config_file can be read before stat-ing/mtime-ing it |
| # | 09:39:53 | mrpeters-isl | maybe that could be added to settings tester? |
| # | 09:39:58 | mrpeters-isl | a check that those config files exist? |
| # | 09:40:23 | mrpeters-isl | dont know how common the problem is except for people like me who just seem to gloss over it in the directions :) |
| # | 09:40:33 | dbs | mrpeters-isl: could be. Would be better to catch the problem at run time and announce it loudly in the error logs. |
| # | 09:41:15 | mrpeters-isl | maybe it's bad workflow on my part, but usually when I have a problem I go to settings-tester.pl first, then the logs |
| # | 09:41:31 | mrpeters-isl | of cousre, that's just when I'm building an install for the first time |
| # | 09:41:58 | csharp | useful_error_logging++ |
| # | 09:42:09 | mrpeters-isl | but i agree with you - a check that it exists would when you start services would be great too |
| # | 09:48:17 | mrpeters-isl | shopkins: any luck? |
| # | 09:55:10 | shopkins | mrpeters-isl - yes, that fixed it, I just never had to install that separately before |
| # | 09:55:58 | jenny has left #evergreen |
| # | 10:07:20 | mrpeters-isl | 10-4 |
| # | 10:07:28 | mrpeters-isl | the makefile should have installed that, i think |
| # | 10:07:54 | mrpeters-isl | so you may run into other things that are missing, if the makefile didn't install all of the dependencies |
| # | 10:09:04 | shopkins | mrpeters-isl - ok maybe I'll just start over |
| # | 10:09:22 | csharp | I would like to see the Makefile.install have more 'bailouts |
| # | 10:09:36 | csharp | when something is not installed, STOP |
| # | 10:10:08 | csharp says this from his cushy armchair, a non-Makefile expert ;-) |
| # | 10:24:29 | dbwells has quit IRC |
| # | 10:26:33 | dbwells has joined #evergreen |
| # | 10:28:35 | collum has quit IRC |
| # | 10:50:09 | bshum | yaz 3.0.52 (that's packaged with lucid) should die a slow death for all the pain it's giving me |
| # | 10:51:10 | csharp | bshum: do you know what's different in the packaged version? |
| # | 10:53:27 | bshum | csharp: I'm not too sure yet, I'm checking on the changes between versions. |
| # | 10:54:52 | bshum | From my (okay, limited...) testing, it seems that Yaz 3.0.52 doesn't play nicely with the simple2zoom script that is run for z39.50 services |
| # | 10:54:56 | csharp | bshum: are you on 2.0.1? |
| # | 10:54:58 | bshum | Otherwise, it's fine. |
| # | 10:55:17 | bshum | Testing with the Yaz version used in the makefile 3.0.47 worked fine. |
| # | 10:55:55 | bshum | And the latest one, seemed to work correctly so far |
| # | 10:55:58 | bshum | That's 4.1.5 |
| # | 10:56:38 | bshum | I'm not too familiar with the Perl modules used in these situations though. It seems that they still point to the wrong version if they were compiled initially using the 3.0.52 |
| # | 10:56:51 | bshum | Even after I've removed the old one and compiled a different one. |
| # | 10:57:11 | bshum | So "fixing" the problem has been most complicated |
| # | 10:57:44 | bshum | csharp: Oh, sorry, yes, 2.0.1 currently. But I've also been testing this using fresh Ubuntu systems without Evergreen installed on them. |
| # | 10:58:09 | bshum | The SRU isn't affected by the Yaz version so far. |
| # | 10:58:21 | bshum | It's just the simple2zoom z3950 thingy |
| # | 11:04:58 | dbs | so, bshum, are you saying that if the Makefile.install was to avoid installing libyaz on lucid that these problems would be avoided? |
| # | 11:05:07 | csharp wonders whether it's something about the Debian modifications to Yaz or something about a dependency |
| # | 11:05:37 | bshum | dbs: I believe so. At the very least, it needs to be done before you install the net::z3950::simple2zoom module |
| # | 11:06:11 | bshum | dbs: Or rather, not avoid installing it, but install the specific version specified in the makefile rather than the package that comes with the OS by default. |
| # | 11:06:15 | bshum | At least for Lucid |
| # | 11:06:22 | dbs | bshum: that's what I meant |
| # | 11:06:26 | bshum | Squeeze seems fine, since their packaged Yaz is 4+ |
| # | 11:07:05 | bshum | More eyes on this would be handy, but that's what I've been observing so far with our 2.0 systems |
| # | 11:07:08 | dbs | I looked at the commit logs some time ago, and there was something about API changes post-3.0.47. wouldn't surprise me if indexdata.dk broke something that was never fixed in 3.0.x because their eyes were on 4.x |
| # | 11:07:46 | bshum | Yeah, rsoullierre and I found a bug in 3.0.52 that would cause the yaz-client to fail when trying to talk with a z3950 server too. |
| # | 11:07:55 | bshum | So there's definitely something wrong with that version in other regards as well. |
| # | 11:10:01 | dbs | gah, Makefile.install is turning into such a mess |
| # | 11:10:06 | dbs blames ubuntu-- |
| # | 11:10:13 | bshum | I do too :( |
| # | 11:10:38 | jeff | so, LTS-only? ;-) |
| # | 11:10:48 | csharp | jeff: +1 |
| # | 11:10:53 | bshum | Absolutely. |
| # | 11:11:22 | bshum has enough to worry about with 10.04 than to worry about the next thing :( |
| # | 11:12:46 | dbs tries to figure out what jeff means by LTS-only, as Makefile.install (at least in trunk) only has targets for hardy and lucid, and lucid is the problem in this case |
| # | 11:12:55 | dbs | Long Term Suckage? |
| # | 11:14:05 | jeff | then we're already there, and i was mis-understanding your blame. :) |
| # | 11:14:18 | bshum | True, it only has targets for that, but I remember reading on the list that someone was using maverick (10.10). So maybe using the lucid targets for the newer version. |
| # | 11:14:32 | bshum | *others may be... |
| # | 11:15:23 | dbs | bshum: yes, that's true, people try that. i don't offer much help to them personally |
| # | 11:16:05 | bshum | Is there a compelling reason to keep the default net access levels at "filtered, unfiltered, no access"? Or can these be changed to "allowed, not allowed"? I presume that this is something that matters most to the 3rd party systems we're setting up to use those fields, right? |
| # | 11:16:06 | dbs | short-term goal: fix display of pre-cat items in myopac |
| # | 11:16:48 | dbs | bshum: that's my understanding. We hide the field entirely in our patron registration interface |
| # | 11:18:12 | bshum | dbs: Cool, thanks. |
| # | 11:18:22 | csharp | bshum: do your libraries use CIPA filters? |
| # | 11:19:11 | bshum | bshum: Never heard of it, so maybe not. |
| # | 11:19:26 | bshum | Ooops, heh, ^^-csharp |
| # | 11:19:41 | jeff | my understanding of CIPA is that a TPM cannot be disabled by patron preference, it has to be on by default at the start of every session. Could be wrong. |
| # | 11:20:38 | csharp | bshum: http://en.wikipedia.org/wiki/Children's_Internet_Protection_Act |
| # | 11:23:00 | bshum | csharp: Ah. |
| # | 11:23:11 | csharp | jeff: to be honest, I'm not sure how it's used in practice in PINES - I'll have to check into that |
| # | 11:23:30 | csharp adds to neverending to-do list |
| # | 11:23:33 | jeff | hah |
| # | 11:23:44 | jeff | don't open any cans of worms on my account. |
| # | 11:24:00 | csharp | jeff: don't worry - I won't - there are too many open here already! |
| # | 11:24:25 | sfortin has quit IRC |
| # | 11:28:45 | dbs considers writing a python script to generate prereqs/ubuntu/hardy/Makefile.install, prereqs/fedora/14/Makefile.install, etc, rather than the all-in-one monster that we currently have |
| # | 11:30:14 | csharp | jeff: bshum: apparently the "filtered/unfiltered" is a setting visible to staff to indicate that a minor has been given parental permission to have unfiltered access - I don't think it's read by the PC Reservation-type software |
| # | 11:31:13 | csharp | dbs: I like that idea very much, fwiw |
| # | 11:31:49 | dbs | and then if i was crazy, I could have it spit out a post-install check script |
| # | 11:32:02 | csharp | oooh |
| # | 11:40:54 | dchristens has joined #evergreen |
| # | 11:43:36 | bshum | dbs: I'm still poking at this thing, and now I'm wondering if maybe it's libyaz, libyaz-dev instead of just plain yaz. Changing the yaz still isn't getting our program to work, but neither is removing the libyaz versions. Trying to think up alternatives. |
| # | 11:44:20 | bshum | I think I've made a mess of the server I'm "testing" this on |
| # | 11:44:22 | dbs | bshum: sorry, I should have been explicit. yes, remove all packaged yaz crud. |
| # | 11:45:27 | bshum | dbs: Does the makefile target install those libraries back? Or maybe that's what I'm missing? |
| # | 11:46:37 | dbs | Yes, for lucid, Makefile.install installs libnet-z3950-zoom-perl \ libyaz-dev \ yaz |
| # | 11:47:47 | csharp | would libnet-z3950-zoom-perl conflict with the CPAN version? (wondering if it's installing both) |
| # | 11:49:23 | bshum | Well, when I try cpan Net::Z3950::ZOOM it says the version is 1.28 and up to date. |
| # | 11:49:24 | jenny has joined #evergreen |
| # | 11:49:53 | csharp | bshum: can you do 'dpkg -l | grep zoom'? |
| # | 11:50:12 | bshum | csharp: Ran that and it came back with nothing |
| # | 11:50:18 | csharp | bshum: ok |
| # | 11:50:25 | bshum | I uninstalled the libnet package |
| # | 11:50:34 | csharp | I was just wondering how well CPAN and APT get along |
| # | 11:50:57 | bshum | Well, it seems that I had both at some point then. |
| # | 11:52:04 | csharp | the packaged version is 1.25 |
| # | 11:52:15 | csharp | (APT-packaged on lucid) |
| # | 11:53:14 | bshum | Hmm, the one that was installed on mine was 1.27 |
| # | 11:53:35 | bshum | Maybe my apt sources are bad. |
| # | 11:55:28 | eeevil | dbwells / phasefx: I assume that nothing is going to happen on https://bugs.launchpad.net/evergreen/+bug/727432 RSN? like to cut 2.0.3 and various 1.6.x's |
| # | 11:57:37 | tsbere | dbs: In regards to makefiles, why not use Makefile.install but have it include other files? |
| # | 11:57:57 | dbwells | eeevil: actually, I am about 30 seconds from posting a patch for that bug to LP. phasefx, do you have a minute to look it over? |
| # | 11:57:59 | dbs | tsbere: if you want to overhaul Makefile.install, be my guest |
| # | 11:58:34 | tsbere | dbs: Sure! After I finish grace periods. Maybe some dojo work. Permissions overhauling. Our migration and related tasks.......might be a while ;) |
| # | 11:58:43 | dbs | tsbere: i hear you |
| # | 11:58:49 | tsbere | Oh, and I don't actually run most of the targets right now. :( |
| # | 11:58:52 | eeevil | dbwells: whatever phasefx does, I'll look at it too |
| # | 12:01:52 | brian_f has joined #evergreen |
| # | 12:02:52 | dbwells | eeevil: phasefx: patch posted |
| # | 12:03:07 | eeevil | dbwells: looks sane to me ... passed manual testing, I assume? |
| # | 12:03:58 | dbwells | eeevil: correct. I would vote for committing it, but didn't want to step on any toes. |
| # | 12:07:29 | eeevil | commit away, sir! |
| # | 12:07:59 | dbwells | alright, one moment |
| # | 12:09:05 | phasefx | yeap, bills.js is defunct |
| # | 12:10:01 | phasefx | dbwells++ |
| # | 12:11:58 | dbwells | phasefx: thanks for the reassurance. Fix is committed. |
| # | 12:31:48 | bshum | dbs: berick: Re: AutoGrid fixes, it doesn't seem to consistently work for us. When going straight to the A/T interface, we cannot select an event and clone it straightaway. We seem to have to open an A/T event first. All subsequent clone attempts then begin to carry the information over correctly. |
| # | 12:45:39 | rjackson-isl | Hi, our site is ramping up for 2.0 upgrade and libraries have been informed of extended down time. They are instructed to use offline mode. My question is how to instruct backup of offline transactions for libraries if they may be down for 2-3 days? |
| # | 12:46:42 | bshum | rjackson-isl: Welcome to the soon-to-be exciting times of 2.0 life. |
| # | 12:46:44 | bshum | :) |
| # | 12:47:10 | bshum | rjackson-isl: By "backup" what do you mean? That you want to have multiple offline transaction logs? One for each day? |
| # | 12:47:24 | bshum | Cause I think you can just roll all those into a single offline transaction log |
| # | 12:47:46 | rjackson-isl | bshum: to ensure that data in offline mode is backup up (redundant copy on external drive/pen drive) |
| # | 12:48:00 | bshum | Ah |
| # | 12:48:20 | rjackson-isl | should read backed up |
| # | 12:48:39 | eeeevil has joined #evergreen |
| # | 12:50:14 | csharp | rjackson-isl: you can manually copy the pending_xacts file in OpenILS\open_ils_staff_client\Profiles\[randomstring].default to a pendrive |
| # | 12:50:55 | rjackson-isl | csharp: SO that is all? THanks! |
| # | 12:50:56 | csharp | rjackson-isl: of course, very few frontline library staff know what the heck that means or how to do it ;-) |
| # | 12:51:34 | csharp | well, pending_xacts is where all the transactions are stored (not divided by date) |
| # | 12:51:46 | rjackson-isl | csharp: Right - but I am being asked by a site so I need advise from the pros ++ |
| # | 12:52:06 | csharp | keep in mind that I'm speaking from knowledge of how it works in 1.4 and before |
| # | 12:53:24 | bshum | Couldn't you export the transactions to a file? |
| # | 12:53:28 | bshum | And then backup that file |
| # | 12:53:35 | bshum | And import them back when it's time for upload |
| # | 12:53:38 | csharp | bshum: you could - but it's buggy |
| # | 12:53:50 | bshum | csharp: Oh, buggy isn't cool :( |
| # | 12:53:54 | dbs | damn we need tests. |
| # | 12:54:12 | csharp | bshum: rjackson-isl: fyi: https://bugs.launchpad.net/evergreen/+bug/543381 |
| # | 12:55:16 | csharp | rjackson-isl: I missed a directory in the path I gave you - it's in the "chrome" directory within the [randomstring].default directory |
| # | 12:57:29 | rjackson-isl | csharp: I found this path: C:\Users\RJackson\AppData\Local\OpenILS\open_ils_staff_client\Profiles is that the correct one (taking into account user account) |
| # | 12:57:42 | csharp | yes - on Win7 |
| # | 12:57:56 | csharp | it's a comparable path on XP |
| # | 12:58:22 | rjackson-isl | csharp: THat is a definite maybe then? ;-) |
| # | 12:59:21 | rjackson-isl | csharp++ |
| # | 13:01:52 | csharp | rjackson-isl: exporting works, but automatic purging doesn't, so if you go the exporting route, make sure you know that the transactions are not purged and will result in duplicated transactions if you're not careful ;-) |
| # | 13:02:34 | rjackson-isl | csharp: Sounds like something to avoid with the number of libraries we have! |
| # | 13:02:40 | csharp learned this when a stubborn library without internet access to a bookmobile accidentally uploaded over 10,000 duplicate transactions |
| # | 13:03:20 | rjackson-isl | csharp: Sounds exciting (NOT!) |
| # | 13:03:32 | csharp | heh - it was pretty harrowing |
| # | 13:04:34 | csharp | they had kept the file running for over a year and a half and were manually removing the older transactions via Excel |
| # | 13:04:53 | csharp | then one day they forgot to manually edit and just uploaded the whole thing |
| # | 13:05:07 | rjackson-isl | csharp: Ouch |
| # | 13:05:52 | eeevil | dbwells: question re last commit, is that reasonable to backport to 1.6? (or is it just not a problem) |
| # | 13:14:26 | eeevil | in any case, I'm going to cut 2.0.3 now, and 2.1-tech-preview. 1.6.1 and 1.6.2 if there's time this afternoon, or tomorrow if not |
| # | 13:15:22 | dbwells | eeevil: I don't have any hands-on experience with credits in 1.6. I know the payment stuff is quite a bit different (bill2.js, the patched file, doesn't even exist). Also, based on what I see and this page http://www.open-ils.org/dokuwiki/doku.php?id=scratchpad:patron_credit , the credit stuff is disabled in 1.6 unless you dig into the code. |
| # | 13:15:44 | Meliss has quit IRC |
| # | 13:15:46 | dbwells | eeevil: maybe phasefx would have some more insight on it. |
| # | 13:16:19 | eeevil | dbwells: I believed the state of 1.6 to be as you point out, so I'm going with "this is not the fix you are looking for" |
| # | 13:16:22 | eeevil | :) |
| # | 13:17:11 | tsbere | eeevil: Patron reg pre-2.1 preview? :D |
| # | 13:17:25 | tsbere | (and my tab-complete habits are failing with an eeeevil in here) |
| # | 13:17:29 | artunit has quit IRC |
| # | 13:17:38 | eeevil | tsbere: yeah, I'll commit that now |
| # | 13:17:43 | eeevil | hey ... who's that? |
| # | 13:18:20 | eeevil | it's me ... from a phone |
| # | 13:18:21 | eeevil | odd |
| # | 13:18:46 | dbwells | getting more evil all the time, it seems |
| # | 13:18:59 | eeevil | dbwells: that's the plan, yes |
| # | 13:19:36 | eeevil | oh ... I know what that is ... tablet at home |
| # | 13:25:18 | dbs digging into the non-display of non-cat circs in myopac.js, getting weirder and weirder |
| # | 13:35:05 | dbs | bah, classic pre-cat / non-cat confusion. nevermind |
| # | 13:35:23 | dbs | you freaks and your non-cat items |
| # | 13:42:28 | AaronZ-PLS has quit IRC |
| # | 13:43:55 | dbs | heh. checking in a non-cat item or trying to change its due date to make it disappear fails nice and ugly |
| # | 13:47:41 | dbwells has left #evergreen |
| # | 13:52:47 | jenny1 has joined #evergreen |
| # | 13:54:01 | jenny has quit IRC |
| # | 13:56:30 | jenny1 has left #evergreen |
| # | 13:58:33 | dchristens | is there a canonical way of batch-editing the marc field in biblio.record_entry? Here's my situation: a batch of about 2500 recs are missing their 300 tags; I can pull the bib ids (and marc) out using sql, and match that up to the records in the original MARC file. I'm thinking it would be easiest to do the edits with Perl and then SQL-update the biblio.record_entry marc field...? Thouhts? |
| # | 13:59:34 | dbs | ARGH. the pre-cat / non-cat confusion is not just mine |
| # | 13:59:36 | dbs weeps |
| # | 14:00:00 | dbs | dchristens: you'll need to reingest the bibs after that too |
| # | 14:00:20 | dchristens | dbs: ah, yes. thanks :-) |
| # | 14:00:34 | dbs | otherwise, sounds like a reasonable plan to me |
| # | 14:01:00 | dchristens | reingest takes care of metabib.record_entry? |
| # | 14:01:36 | dchristens | er, metabib.real_full_rec |
| # | 14:02:10 | eeevil | dchristens: and other stuff, yes |
| # | 14:02:30 | dchristens | excellent. thanks :-) |
| # | 14:03:40 | dbs | myOPACDrawNonCatCircs calls myOPACDrawNonCatCircs2 calls myOPACDrawNonCatCirc. man I'm looking forward to opac-tt-poc becoming opac |
| # | 14:03:50 | AaronZ-PLS has joined #evergreen |
| # | 14:04:02 | dbs | eeeevil: you're probably already there, but this is a good fix for 2.0.x |
| # | 14:04:42 | eeevil | dbs: arg... |
| # | 14:04:53 | dbs | no problemo, next time around |
| # | 14:05:17 | eeevil | just tagged. but if it's committed I'll backport |
| # | 14:05:24 | eeevil | not wrapped yet |
| # | 14:05:55 | eeevil | dbs: well, it's not committed yet, I see, but if you're about to commit, I'll wait a few minutes |
| # | 14:07:22 | tsbere likes git commit -a --amend as he makes incremental changes to files |
| # | 14:09:02 | dbs | eeeevil: just committed to rel_2_0, will forward-port |
| # | 14:09:26 | eeevil | thanks! |
| # | 14:12:26 | eeevil | ok, 2.0.3 has it, exporting for wrapping now |
| # | 14:13:01 | dbs | eeeevil++ |
| # | 14:13:20 | dbs can see the release PR now: "The fix-laden 2.0.3 release..." |
| # | 14:13:33 | bshum | :) |
| # | 14:14:38 | eeevil | yay for install_all_locales! |
| # | 14:15:33 | dbs mumbles to himself that the pre-cat thing probably needs to be backported to 1.6 too |
| # | 14:15:50 | dbs | eeeevil: heh, I think mdxi added that long ago for the benefit of the original buildbot |
| # | 14:15:52 | dbwells has joined #evergreen |
| # | 14:16:04 | eeevil | ahh. I never saw it |
| # | 14:16:33 | dbs | sure is a lot nicer than typing all that out by hand :) |
| # | 14:16:40 | eeevil | indeed |
| # | 14:17:03 | eeevil | though I usually just do the part described in update_all_locales ... no newpo, IOW |
| # | 14:19:50 | dbs | oh yeah. 2.0.3 has the fix for fr-ca instead of fr/ca for the Dojo locales |
| # | 14:21:05 | eeevil | tsbere: applying your patron reg patch now |
| # | 14:22:17 | tsbere | :D |
| # | 14:25:00 | dbs | gar. "-uris" is not numeric in 1431 of OpenILS/WWW/SuperCat.pm. indeed it is not |
| # | 14:26:13 | eeevil | so ... shall I actually tag something from 2.1 for the "technology preview / pre-alpha" or just export it and do the wrapping dance? |
| # | 14:26:40 | tsbere | My vote is just export |
| # | 14:26:50 | dbs | Let's tag it, that way we know when we find bugs from what version it came |
| # | 14:27:21 | gmcharlt | agreed, let's tag it |
| # | 14:27:48 | gmcharlt | tag_2_1_I_am_the_harbinger_of_future_goodies |
| # | 14:28:13 | eeevil | gmcharlt: that tag is the winner |
| # | 14:28:37 | berick | heh. harbinger_of_cuddles |
| # | 14:28:50 | eeevil | ok... no, bericks' wins |
| # | 14:29:00 | eeevil | svn copy . svn://svn.open-ils.org/ILS/tags/rel_2_1_harbinger_of_cuddles |
| # | 14:29:37 | gmcharlt | heh |
| # | 14:29:43 | eeevil | well... that will end up in the staff client as the default ID... ok, going with boring "prealpha1 |
| # | 14:30:09 | Dyrcona | boorrriinngg |
| # | 14:30:14 | Kip_ has joined #evergreen |
| # | 14:30:23 | Dyrcona | +1 harbinger_of_cuddles |
| # | 14:31:53 | csharp | cute_code_names++ |
| # | 14:32:05 | csharp | onanistic otter |
| # | 14:32:36 | tsbere wonders if it will be a harbinger of headaches too, with the 9.0 DB requirement |
| # | 14:32:41 | eeevil | ok ... I'll use harbinger_of_cuddles for RC1 ;) |
| # | 14:34:46 | tsbere | harbinger_of_confusion on the svn commit |
| # | 14:36:16 | tsbere wonders why files were removed.....only to be put back? |
| # | 14:36:23 | tsbere | In the same commit? |
| # | 14:38:10 | eeevil | tsbere: eh? |
| # | 14:38:27 | eeevil | tsbere: sounds like a move/rename |
| # | 14:38:32 | tsbere | eeevil: My webmail client couldn't show me the "make the tag" email due to the size of it. |
| # | 14:39:17 | tsbere | Something around 23320 lines of body in that message |
| # | 14:39:56 | dbs probably is responsible for that |
| # | 14:40:31 | tsbere wonders how dbs could be responsible for a commit marked "Author: miker" |
| # | 14:41:03 | dbs | Guess not. I failed to use my xray vision to read tsbere's screen again |
| # | 14:41:27 | dbs wonders about vaguely alarming things without details just to see if people are paying attention |
| # | 14:41:54 | eeevil | tsbere: I have no idea why that email lookslike that |
| # | 14:42:05 | eeevil | that's really weird |
| # | 14:42:13 | dbs | git-svn? |
| # | 14:42:16 | eeevil | no |
| # | 14:42:17 | eeevil | just svn |
| # | 14:42:33 | tsbere | lots of bzr tags in the top though? |
| # | 14:42:58 | eeevil | right, that's one of the weird parts |
| # | 14:43:16 | eeevil | the other is ... that anything happened at all other than copying a branch to a tag |
| # | 14:43:41 | dbs | maybe harbinger_of_cuddles is an SVN easter egg |
| # | 14:43:54 | eeevil | heh |
| # | 14:44:02 | mrpeters-isl has quit IRC |
| # | 14:44:28 | tsbere | Almost looks like the patron reg stuff was forcibly re-introduced by deleting anything that conflicted and re-copying them into place. |
| # | 14:45:59 | eeevil | yeah ... dunno |
| # | 14:46:12 | eeevil | but, only touched that tag, so not too worried |
| # | 14:46:35 | moodaepo has quit IRC |
| # | 14:46:42 | mtate has quit IRC |
| # | 14:46:52 | mtate has joined #evergreen |
| # | 14:48:26 | eeevil | dbs: it's build/i18n/* that I'm safe to remove, correct? |
| # | 14:48:51 | eeevil | dbs: well, all of build/i18n |
| # | 14:49:23 | dbs | eeeevil: that is safe to remove, from a "does not harm installing / running Evergreen" perspective |
| # | 14:49:41 | eeevil | right. in the tarball |
| # | 14:50:35 | dbs | eeeevil: we will probably want ship the raw source for that directory as the preferred source form, per the GPL, but for now I say do it |
| # | 14:51:04 | dbs | (build/i18n/Makefile has no useful "make clean" to assist with that, so ... later) |
| # | 14:51:11 | moodaepo has joined #evergreen |
| # | 14:51:14 | eeevil | dbs: hrm.. I thought that was the recommendation, considering the reduction in size of the tarball |
| # | 14:51:44 | mrpeters-isl has joined #evergreen |
| # | 14:52:31 | dbs | eeeevil: yes, I recommended it as the quickest means to reducing tarball size. I'm just saying that keeping the PO files around (without all of the build locale files, etc) would be the preferred distribution method. it just requires more work that hasn't been done yet |
| # | 14:52:50 | eeevil | understood |
| # | 14:53:14 | eeevil | so, fwiw, diff --exclude=*svn* -purbB ILS-2.1-prealpha1/ ILS-2.1/ says that tag is fine ... sorry for the crazy email |
| # | 14:53:38 | gmcharlt has quit IRC |
| # | 14:53:55 | dbs | (and, looking at build/i18n/po, it looks like it's massive all by itself. crap.) |
| # | 14:54:00 | eeevil | I used my local checkout of rel_2_1 to do the svn copy, though normally I used the remote svn:// url, so that's the difference and, I guess, the cause |
| # | 14:54:35 | dbs | maybe someday we split each language out into their own separately-distributable language packs |
| # | 14:54:49 | eeevil | indeed |
| # | 14:55:22 | dbs | maybe someday we'll have a real i18n maintainer :) |
| # | 14:56:07 | gmcharlt has joined #evergreen |
| # | 14:56:51 | eeevil | ok ... 2.0.3 is in the usual place |
| # | 14:56:56 | eby | quick question. does autogen need to be ran for most configuration changes, like addition of fine types? |
| # | 14:57:17 | eeevil | eby: no |
| # | 15:00:00 | berick | is the plan to cut a staff client to go along with the preview? |
| # | 15:00:12 | eeevil | csharp: any movement on the mailing list server move stuff? |
| # | 15:00:26 | eeevil | berick: we probably should, so it's easy to get going |
| # | 15:00:51 | berick | eeevil: yeah, i've heard reports of 2.0 clients not working with trunk. presumably the same is true for 2.1 |
| # | 15:00:57 | tsbere | At this point the makefile target could be used to build one, including installer (if additonal pieces are there) |
| # | 15:01:23 | csharp | eeevil: we're stalled by other GPLS IT priorities that have prevented the move to the new IP block - I don't have an ETA, but I hope that it will be within the next 3 - 4 weeks |
| # | 15:01:24 | tsbere | berick: You can blame me for that. I changed a pile of things that made it to trunk (and thus 2.1) but never got backported to 2.0. |
| # | 15:01:37 | csharp | thanks to everyone for your patience about this |
| # | 15:02:27 | berick | tsbere: meh, no blaming necessary. there's no reason a 2.0 client has to work with 2.1 |
| # | 15:04:20 | sfortin has joined #evergreen |
| # | 15:13:50 | tsbere | I am digging through code already for grace period stuff, anyone think it is a good idea to say that the renewals remaining should be overridden by a smaller number of allowed renewals from the matchpoint table (or script, for that matter)? So that if you checked out with 50, and they changed it to 5, when you renew it would cap at 5? |
| # | 15:15:27 | eeevil | tsbere: FWIW, we explicitly avoid that today because (for instance) the patron my have a receipt that says 50 renewals |
| # | 15:18:29 | tsbere | I suspected that was part of the reasoning |
| # | 15:18:34 | tjvcarter has joined #evergreen |
| # | 15:20:41 | eeevil | (and obvious patron-service variations on same) |
| # | 15:24:30 | artunit has joined #evergreen |
| # | 15:37:42 | shopkins has quit IRC |
| # | 15:42:18 | eeevil | and ... Evergreen-ILS-2.1-prealpha1.tar.gz and Evergreen-ILS-2.1-prealpha1.tar.gz.md5 are up now |
| # | 15:42:53 | jeff | eeevil++ # yay |
| # | 15:45:12 | tsbere | On grace periods - When adding them to the database, should the parameter on the cron job be ignored or treated as a minimum? |
| # | 15:46:20 | eeevil | tsbere: I would think it would be the default |
| # | 15:47:14 | tsbere | eeevil: The default for? I wasn't planning on making the database value nullable. |
| # | 15:49:03 | eeevil | tsbere: oh, I figured it would be an ou setting (haven't been following your plan, sorry) |
| # | 15:50:17 | tsbere | eeevil: Basically, I am duplicating how renewals work. Main setting on the recurring fine rule, override setting in the matchpoint table. |
| # | 15:50:40 | tsbere | Thus, the circulation table(s) get a new field in the process, and I wasn't planning on making that one nullable |
| # | 15:50:53 | eeevil | I see |
| # | 15:51:16 | tsbere | I figure this way you can have more strict grace periods on certain item types. Like DVDs or something. |
| # | 15:52:31 | eeevil | my concern is that it's just one more thing to set (or forget to set) on all rules where (like in PINES) it's just "one fine interval" across the board |
| # | 15:53:24 | eeevil | and ... what would you set it to on upgrade? (secondary concern, but ... still ... how and what?) |
| # | 15:54:07 | eeevil | if it's nullable and the cron-fired script passes a default value, then totally uniform sites can just not worry about it |
| # | 15:54:27 | rjackson-isl has quit IRC |
| # | 16:01:59 | tsbere | eeevil: A question about that to begin with, actually. Circulation triggers fine generation as well, it seems. But there is no grace period set *there*. What happens on checkin within the grace period? |
| # | 16:02:20 | bshum | phasefx: Presuming that any 2.1 staff client should get a new ID for the windows side. Or wait, does the 2.1 have the automated builder now? |
| # | 16:02:22 | tsbere | (since currently the only place grace period is defined in on the cron job) |
| # | 16:05:34 | phasefx | bshum: I'd prefer 2.1 start using the NSIS installer and the staff client makefile, rather innosetup |
| # | 16:05:48 | tsbere_ has joined #evergreen |
| # | 16:05:59 | tsbere has quit IRC |
| # | 16:06:05 | tsbere_ is now known as tsbere |
| # | 16:06:06 | bshum | phasefx: That's what I thought, only poked at that a tiny bit but it looked pretty cool to use. |
| # | 16:06:09 | phasefx | bshum: see http://evergreen-ils.org/dokuwiki/doku.php?id=mozilla-devel:building_the_staff_client |
| # | 16:06:57 | phasefx is a bit swamped this week, but can try to roll clients soon if there's too much of a barrier |
| # | 16:07:00 | tsbere | logs say....I missed one line directed at someone else on that disconnect. |
| # | 16:10:51 | bshum | phasefx: I'm getting the 2.0.3 started right now. Will play with the 2.1 release sometime after that. I assume that the install steps for that might be different now. |
| # | 16:11:19 | phasefx | bshum++ |
| # | 16:11:33 | bshum | Well, maybe later this week :) |
| # | 16:11:40 | bshum | 2.1 is when we need PG 9.0 right? |
| # | 16:11:43 | tspindler has quit IRC |
| # | 16:12:01 | bshum | Amongst several other things I'm sure. |
| # | 16:14:46 | bshum | phasefx: Hmm, should we package with xulrunner 1.9.2.15 (latest) or stick with what we had been using? |
| # | 16:16:18 | phasefx | bshum: my vote is to always use the latest 1.9.2.x. I can see an argument for sticking with previous versions for bug fix releases though |
| # | 16:17:15 | phasefx | though I expect for 1.9.2.x to be very stable and any bump there is usually for the good |
| # | 16:17:37 | phasefx | after 1.9.2 though, all hell is going to break loose :) |
| # | 16:17:39 | dbs | yeah, typically closes security holes |
| # | 16:17:45 | bshum | Heh |
| # | 16:17:49 | dbs | until "close security hole: remote XUL" |
| # | 16:18:20 | phasefx can point to a hole they can fill :) |
| # | 16:18:31 | bshum | Well, in that case, I'll build the 2.0.3 staff client using 1.9.2.15 |
| # | 16:18:44 | bshum | And if it breaks, well... hmm |
| # | 16:18:47 | bshum | :) |
| # | 16:19:50 | phasefx | if it breaks we have flexibility for rolling new clients, changing the code to address the new bugs and cutting a new release, etc. |
| # | 16:20:34 | dbs | yep |
| # | 16:21:08 | phasefx | UI testing.. fun |
| # | 16:21:09 | dbs | "ln -sf rel_2_0_3 rel_2_0_2" and point the 2.0.2 client at it |
| # | 16:25:30 | eeevil | tsbere: (sorry for the delay) yes, good point. non-nullable it is, then, I agree. which means, I think, we should remove the grace period from the cron job and also as a parameter to the fine generator method |
| # | 16:25:34 | eeevil | to remove confusion |
| # | 16:26:01 | tsbere | alrighty then |
| # | 16:26:17 | dbs | +1 to that |
| # | 16:26:25 | b_bonner has joined #evergreen |
| # | 16:26:25 | eeevil | dbwells: I haven't forgotten our QP thread on the mailing list, btw, just haven't had time to respond appropriately yet :) |
| # | 16:27:02 | tsbere | Although......no clue how to deal with reservations. |
| # | 16:27:50 | bshum | Hmm, maybe it's just me, but I can't seem to bring up fr-CA to translate any strings in the staff client menus. Was it always this way? |
| # | 16:28:14 | bshum | (other languages are mix-match, but I would have thought french would have been more complete) |
| # | 16:28:34 | dbs | bshum: it shouldn't be that way |
| # | 16:28:47 | bshum | dbs: It's possible I compiled the staff client incorrectly. |
| # | 16:28:51 | kmlussier has quit IRC |
| # | 16:29:07 | dbs | or possible that yet another i18n monstrosity has occurred |
| # | 16:29:16 | bshum | Right |
| # | 16:29:22 | bshum | Just thought I would mention it. |
| # | 16:30:01 | bshum | Yeah, in my 2.0.2 staff client, the french locale translates things fine, but the 2.0.3 staff client I just made isn't. |
| # | 16:30:29 | dbs | hmm. Other locales have stuff? |
| # | 16:31:17 | eeevil hopes it's not the 'make newpo' bit included in install_all_locales |
| # | 16:31:20 | sfortin has quit IRC |
| # | 16:31:27 | eeevil | but, if it is, I will re-build and wrap |
| # | 16:31:46 | bshum | dbs: Checking |
| # | 16:31:52 | bshum | I can upload a copy of the staff client first |
| # | 16:31:57 | bshum | So that you guys can see it |
| # | 16:31:59 | dbs hopes as well |
| # | 16:32:24 | dbs will download the tarball and inspect |
| # | 16:32:25 | bshum | Russian has stuff |
| # | 16:32:40 | bshum | Armenian too |
| # | 16:33:27 | bshum | The OPAC displays in french |
| # | 16:33:32 | eeevil | dbs: well, I removed build/i18n |
| # | 16:33:34 | bshum | When using fr-CA for the staff client |
| # | 16:33:54 | bshum | It's only affected menus/buttons |
| # | 16:34:02 | dbs | eeeevil: doesn't matter, install would put the stuff into the XUL subdirs |
| # | 16:34:12 | dbs | damn tablet! |
| # | 16:34:19 | bshum | Check in is french |
| # | 16:34:54 | phasefx | btw, in 2.0.2, en-CA, I see what looks like arabic in chrome/locale/en-CA/offline.properties |
| # | 16:35:10 | dbs | lang.dtd is all english in fr-CA |
| # | 16:35:23 | tsbere | eeevil: Noticed a problem. I have no clue how to apply grace periods to reservations, having never looked into how they work. They also suffer from the "when circ triggers fine generation we don't have a grace period" issue, though. Should I leave that as a todo item? |
| # | 16:35:26 | dbs | Open-ILS/xul/staff_client/chrome/locale/fr-CA/lang.dtd |
| # | 16:36:11 | eeevil | hey ... I'm putting the brakes on 2.0.3 folks. Callender just spotted a big issue in the 1.6.1-2.0 upgrade for the booking schema |
| # | 16:36:17 | dbs | but lang.dtd for hy-AM is definitely armenian. what the heck. |
| # | 16:36:42 | dbs | curse those bookers! |
| # | 16:36:44 | eeevil | dbs: I bet I broke it with newpo |
| # | 16:36:59 | dbs | eeeevil: why would hy-AM work and fr-CA not? |
| # | 16:37:09 | eeevil | dbs: dunno... |
| # | 16:37:28 | dbs | sounds like a good conclusion to jump to, but I'm not buying it |
| # | 16:37:35 | dbs | (not without... testing!) |
| # | 16:37:54 | bshum | eeevil: Boo, about the upgrade script difficulty :( |
| # | 16:39:28 | dbs says "IN YOUR FACE" to eeeevil, as he looks at raw build/i18n/po/lang.dtd/fr-CA.po containing not a single translation |
| # | 16:40:00 | tsbere | dbs: Why so rude to his tablet? ;) |
| # | 16:40:13 | eeevil | dbs: gah |
| # | 16:40:27 | eeevil | tsbere: heh |
| # | 16:40:39 | dbs fears this is in part due to launchpad's insistence that fr-CA was not a real locale, and therefore forcing everything to plain old fr |
| # | 16:40:55 | dbs will stab wildly |
| # | 16:44:42 | bshum | Well good luck all. |
| # | 16:47:55 | dbs | nooooooooooooooo |
| # | 16:48:03 | dbs | eeevil appears to be right |
| # | 16:48:39 | dbs | dbs-- |
| # | 16:50:30 | dbs will remove "newpo" from install_all_locales target |
| # | 16:50:48 | eeevil | which makes it the same as update_, I think |
| # | 16:51:10 | eeevil | anyone have a 1.6.1 test box they'd like to run a new 2.0 upgrade script on? |
| # | 16:51:35 | dbs | nope |
| # | 16:51:45 | dbs | update_all_locales just does updatepo |
| # | 16:51:56 | eeevil | hm... ok |
| # | 16:52:01 | dbs | damn thing has been there since http://svn.open-ils.org/trac/ILS/changeset/15087/trunk/build/i18n/Makefile |
| # | 16:52:21 | eeevil | mind shoving it into rel_2_0_3? |
| # | 16:52:28 | dbs | eeeevil: not at all |
| # | 16:52:33 | eeevil | thanks |
| # | 16:53:05 | eeevil | I'll see if I can test the upgrade script (checking in so others can too) tonight |
| # | 16:53:12 | eeevil | and we'll try for 2.0.3 tomorrow? |
| # | 16:53:50 | dbs | no, wait |
| # | 16:53:57 | eeevil | wating |
| # | 16:54:14 | dbs | sorry, go ahead with upgrade script, I'm thinking out loud here |
| # | 16:55:04 | dbs | the reason fr-CA in particular was affected by that, given that LOCALE was not set explicitly, is because fr-CA is the default value for LOCALE; which explains why only fr-CA was affected by the 'newpo' target |
| # | 16:55:23 | eeevil | ok ... http://svn.open-ils.org/trac/ILS/changeset/19667 |
| # | 16:55:43 | eeevil | dbs: so newpo is still considered harmful, and that default makes it more so for fr-CA? |
| # | 16:56:20 | dbs | newpo is needed when you're generating the PO files for a locale for the first time |
| # | 16:57:02 | eeevil | right, but don't point it at an existing locale! :) |
| # | 16:57:12 | dbs | If taught to test for the existence of each target PO file before generating it, it wouldn't be harmful (and would be helpful if just one PO file was missing) |
| # | 16:57:44 | dbs | I think that latter case was why mdxi added it - when we were adding PO files in dribs and drabs, it made buildbot v.1 vomit |
| # | 16:57:50 | gmcharlt | eeeevil: change looks OK |
| # | 16:58:27 | dbs | in any case: ripping newpo out of install_all_locales, I'd rather have it fail loudly than silently remove all translations of the only other language I care significantly about :) |
| # | 16:59:15 | eeevil | dbs: agreed |
| # | 16:59:47 | eeevil | I'm going to delete the tarball |
| # | 17:00:25 | eeevil | well, move it |
| # | 17:00:57 | eeevil | alkdkl ... ok, I have to drive. back later |
| # | 17:01:22 | tjvcarter has quit IRC |
| # | 17:02:59 | dbwells | tsbere: concerning grace periods and fine generation on checkin. In 1.6 fine generation on normal checkins doesn't happen by default (it is in the feature list, though, so perhaps it was meant as a trigger?). In any case, I see that fine generation is indeed hardcoded into do_checkin on 2.0, so my guess is that grace periods no longer work in 2.0+ at all |
| # | 17:04:15 | tsbere | dbwells: That is what I have been thinking for a while. |
| # | 17:05:53 | dbs | we stopped using grace periods entirely, because with a four-hour loan a grace period of 1 hour or 1 minute (if defined as '240 minutes') made no sense either way |
| # | 17:06:24 | dbs | which was why I started going down the road of adding a grace period column to config.rule_recurring_fine - and discovered that tsbere was way ahead of me |
| # | 17:06:26 | dbs | tsbere++ |
| # | 17:07:09 | tsbere | dbs: This is my.....third run on this? Previous attempts were rejected because I put too many things into one patch. |
| # | 17:09:46 | dbs | Given that there's a separate official docs repository, perhaps we should "svn rm docs" from the root of the Evergreen repo in trunk/rel_2_1 to save 1 MB |
| # | 17:10:58 | dbwells_ has joined #evergreen |
| # | 17:13:14 | dbs has quit IRC |
| # | 17:14:40 | dbwells has quit IRC |
| # | 17:14:55 | dbwells_ is now known as dbwells |
| # | 17:15:27 | tsbere | here's hoping I haven't horribly broken a pile of things... |
| # | 17:15:56 | tsbere still needs an upgrade script, unfortunetly, but figures he should make sure the code works first |
| # | 17:17:58 | dbwells | tsbere: so you have a grace period patch more or less prepared? I am anxious to look at it, as broken grace periods on 2.0 would be a show stopper for us :( |
| # | 17:18:42 | tsbere | dbwells: I have it in progress, at least. No clue how badly it breaks things, though, as my testing has yet to begin, and I am building it on at least partial assumption of features already in 2.1. |
| # | 17:19:23 | tsbere | Oh, and it won't help reservations with fine intervals, as I haven't even looked at that part of the system. |
| # | 17:19:51 | dbwells | tsbere: as far as grace periods go, neither has anyone else ;) |
| # | 17:22:21 | dbwells | tsbere: I forget, is your devel repo public somewhere? |
| # | 17:22:52 | tsbere | dbwells: I haven't pushed this to it. And I think I break things with lots of rebasing. |
| # | 17:26:06 | tsbere | dbwells: If you want you can take a look here now: http://git.mvlcstaff.org/?p=tsbere/ILS.git;a=summary |
| # | 17:26:35 | tsbere | Although I typoed the repo name, meh. |
| # | 17:26:57 | tsbere | Will likely fix it later, fair warning |
| # | 17:27:23 | tsbere | Or just now |
| # | 17:27:32 | tsbere | I think |
| # | 17:27:55 | dbwells | tsbere: thanks. And no problem, I worked for 6 months in a repo named 'seials-integration' |
| # | 17:28:11 | tsbere | I just fixed it according to gitweb. |
| # | 17:29:50 | tsbere | And testing waits for today, as it is time to go. |
| # | 17:29:52 | yboston has quit IRC |
| # | 17:30:12 | Dyrcona has quit IRC |
| # | 17:31:28 | dchristens has quit IRC |
| # | 17:37:03 | AaronZ-PLS has quit IRC |
| # | 17:46:22 | b_bonner has quit IRC |
| # | 17:59:07 | b_bonner has joined #evergreen |
| # | 18:00:42 | b_bonner has quit IRC |
| # | 18:15:45 | tater-laptop has quit IRC |
| # | 19:23:49 | eeevil | dbwells: grace periods are far from "not working at all" |
| # | 19:24:58 | eeevil | well ... hrm... |
| # | 19:27:47 | tsbere | eeevil: What do you call "on checkin, we calculate fines without one. For everything." ?? |
| # | 19:33:14 | eeevil | tsbere: no, I see what you and dbwells are saying. which is why I said "well ... hrm..." ... typed before I finished reading the scrollback |
| # | 19:34:20 | tsbere | feel free to look at my work in progress. Had to ditch some of what I thought was done due to forgetting I changed tactics between attempts. |
| # | 19:37:17 | rsinger has quit IRC |
| # | 19:56:07 | eeevil | ok, the adjusted 1.6.1-2.0 upgrades a 1.6.1.7 without incident, I believe |
| # | 20:29:18 | rsinger has joined #evergreen |
| # | 20:33:44 | eeeevil2 has joined #evergreen |
| # | 20:33:44 | eeeevil has quit IRC |
| # | 20:35:35 | brian_f has quit IRC |
| # | 20:41:59 | dbs has joined #evergreen |
| # | 20:41:59 | dbs has joined #evergreen |
| # | 20:48:28 | eeevil | so ... this is odd: http://paste.lisp.org/display/120367 says we should be inserting an event def 20 (password reset, btw) |
| # | 20:48:35 | eeevil | but ... we don't |
| # | 20:48:55 | eeevil | so the upgrade script against 1.6.1.7 will never succeed |
| # | 20:49:06 | dbs | eeevil: call up mck9 |
| # | 20:49:57 | eeevil | well, yeah, but people have been testing |
| # | 20:50:06 | eeevil | with that script |
| # | 20:50:21 | dbs | umm |
| # | 20:50:30 | eeevil | which makes me think that things are altogether wonky ... |
| # | 20:50:55 | eeevil | so, in a clean 1.6.1.7, if I teach the script to do what it claims to do, it succeeds |
| # | 20:50:56 | dbs | our test upgrade worked, but I had to hack the upgrade script for some local customizations at the time |
| # | 20:51:16 | dbs | you're talking about 1.6.1-2.0? |
| # | 20:51:49 | dbs | in rel_1_6_1 we create event_definition 15 for pw reset |
| # | 20:51:58 | dbs goes to check the 1.6.1-2.0 upgrade script |
| # | 20:53:11 | eeevil | dbs: right, and in 2.0, for some reason, that's now known as event def 20 |
| # | 20:53:34 | eeevil | because of 0237.data.password-reset.sql |
| # | 20:55:00 | eeevil | unfortunately, the fkeys don't cascade on update ... I could make them do that, and then push all ids that we're not explicitly setting in either 1.6.1 or 2.0 to past 100 |
| # | 20:55:15 | eeevil | and reset the sequence |
| # | 20:56:44 | dbs | weird. "as long as we create #20 before committing" and we don't. Okay, I have now caught up to where you were 7 minutes ago |
| # | 20:56:51 | eeeevil2 has quit IRC |
| # | 20:58:43 | dbs | someone tell the libraries that have upgraded to 2.0 that they can't possibly have succeeded! |
| # | 20:59:11 | bott-otr has joined #evergreen |
| # | 21:02:07 | bshum | dbs: Uh oh! |
| # | 21:03:08 | dbs creates a clean 1.6 schema and runs the upgrade script, just for fun |
| # | 21:04:16 | dbs gets the expected error 18929: ERROR: insert or update on table "environment" violates foreign key constraint "environment_event_def_fkey" |
| # | 21:04:16 | bshum | What was supposed to be 20? |
| # | 21:04:46 | eeevil | IDs explicitly touched in the upgrade script: (4,6,7,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36) |
| # | 21:04:58 | eeevil | IDs from 1.6.1.7: 1,2,3,5 |
| # | 21:05:03 | dbs | password reset event definition was supposed to move from 15 to 20 because password reset got added to 1.6.1 with id 15 while 2.0 got something else |
| # | 21:05:31 | bshum | Maybe we missed it by leaping from 1.6.1.2 to 2.0.0 |
| # | 21:05:41 | bshum | Our password reset definition is id 161 |
| # | 21:05:43 | bshum | Way out there |
| # | 21:06:00 | eeevil | bshum: that's ok, and saved you actually |
| # | 21:06:23 | bshum | Well, when we tested 2.0, the highest version was only 1.6.1.4 |
| # | 21:06:24 | eeevil | though the (probably unspoken) launching point was 1.6.1.4, IIRC |
| # | 21:06:31 | eeevil | or, intended to be |
| # | 21:06:35 | bshum | Right. |
| # | 21:06:54 | eeevil | so, the idea was "go as far as you can in 1.6.1, then upgrade to 2.0" |
| # | 21:07:37 | eeevil | anyway ... I believe I can address this with a simple INSERT of 20 |
| # | 21:08:13 | eeevil | from the 0237 upgrade script |
| # | 21:09:08 | dbs is still trying to shake brains into place, seeing that this 15/20 stuff existed way back in the original commit of the 1.6.1-2.0 upgrade script |
| # | 21:09:09 | bshum | Oh, that's right. |
| # | 21:09:15 | bshum | We were the ill-fated 1.6.1.3 site |
| # | 21:09:21 | dbs | AH |
| # | 21:09:24 | bshum | So we only had to get to 1.6.1.4 |
| # | 21:09:33 | bshum | Which that upgrade script was adding back the URI |
| # | 21:09:38 | dbs | the original upgrade script also had the insert 20 stmt |
| # | 21:09:41 | bshum | So we just did that manually and moved on to 2.0 |
| # | 21:09:45 | eeevil | dbs: did it? |
| # | 21:09:53 | eeevil | haven't looked at history |
| # | 21:10:07 | dbs | yep, near the top |
| # | 21:10:21 | dbs | line 2340 |
| # | 21:11:10 | dbs | http://svn.open-ils.org/trac/ILS/browser/branches/rel_2_0/Open-ILS/src/sql/Pg/1.6.1-2.0-upgrade-db.sql?rev=17494 for the curious |
| # | 21:13:51 | dbs | ding ding: http://svn.open-ils.org/trac/ILS/changeset/18640/branches/rel_2_0/Open-ILS/src/sql/Pg/1.6.1-2.0-upgrade-db.sql |
| # | 21:15:27 | eeevil | gmcharlt! ;) |
| # | 21:15:52 | eeevil | ok ... I'll just put that back in |
| # | 21:16:20 | dbs | sounds bueno to me (i'll be happy to test again once you do) |
| # | 21:17:02 | gmcharlt | oy |
| # | 21:17:56 | dbs | hrm. apparently in my customized 1.6.1-2.0 upgrade script on our test server, I hacked around that damage thinking it was due to damage I had inflicted on our database, cause I don't have an ID = 20 in action_trigger.event_definition |
| # | 21:18:04 | dbs | dbs-- |
| # | 21:18:09 | dbs | should have caught that. |
| # | 21:20:58 | dbs | stemmed from https://bugs.launchpad.net/evergreen/+bug/671213 - so really, we can blame jamesrf :) |
| # | 21:22:26 | dbs | duplicate name constraint woes mayhaps? |
| # | 21:23:29 | eeevil | heh |
| # | 21:23:40 | eeevil | ahh... I see |
| # | 21:23:41 | eeevil | sec |
| # | 21:25:04 | gmcharlt | line 55 of http://svn.open-ils.org/trac/ILS/browser/branches/rel_1_6_1/Open-ILS/src/sql/Pg/1.6.0.4-1.6.1.0-upgrade-db.sql , say? |
| # | 21:27:18 | gmcharlt | r16502 - upgrade script had the id initial set to 15 |
| # | 21:27:33 | gmcharlt | r16508 - got changed to nextval() |
| # | 21:28:12 | dbs | heh, awesome |
| # | 21:28:59 | gmcharlt | well, at least we have impetus to code the next advance in strong AI |
| # | 21:29:44 | dbs | so can we blame eeevil then? :) |
| # | 21:30:37 | eeevil | oh, I'm sure it's my fault /somehow/ |
| # | 21:30:38 | dbs buys a nice big sack of brown paper bags for everybody to dress up in |
| # | 21:30:45 | eeevil | it's always the fault of evil |
| # | 21:30:54 | eeevil | devil made 'im do it, etc ;) |
| # | 21:31:18 | dbs | IT WAS THE TABLET YER HONOR |
| # | 21:31:39 | gmcharlt | eeevil: cool; not only have you written AI, it is so efficient it runs on a tablet! |
| # | 21:32:20 | dbs | eeevil's treasured Windows XP pen computing tablet, natch |
| # | 21:32:56 | eeevil | dbs / gmcharlt: check out that commit, eh? |
| # | 21:34:32 | dbs | eeevil: better than staring at a weird set of binary files that OCLC produced as a response to a batch reclamation project I'm working on |
| # | 21:34:40 | eeevil | heh |
| # | 21:34:52 | eeevil | running another test |
| # | 21:36:07 | eeevil | that worked for me |
| # | 21:37:10 | dbs | atevdef 20 = password reset, so there's that |
| # | 21:38:11 | gmcharlt | eeevil: there's a side effect of deleting all of the old password reset events, no? |
| # | 21:38:57 | gmcharlt | not that that's the end of the world, but at the very least it would make the update starting at line 3229 superfluous |
| # | 21:39:15 | eeevil | gmcharlt: not deleting them, moving them to def 20 |
| # | 21:40:13 | eeevil | gmcharlt: where are you seeing me deleted the old events? |
| # | 21:40:53 | dbs | I think gmcharlt was thinking that deleting atevdef = 15 would cascade and wipe out the associated events. but no |
| # | 21:41:03 | gmcharlt | yes |
| # | 21:41:08 | eeevil | nope ... no CASCADE on that fkey |
| # | 21:41:10 | gmcharlt | looks like it would actually restrict, though |
| # | 21:41:24 | eeevil | naw, it's DEFERRABLE INITIALLY DEFERRED |
| # | 21:41:44 | dbs spent a good day or two making everything deferrable ages ago |
| # | 21:41:48 | eeevil | so, it's checked at commit time, at which point RI is intact |
| # | 21:41:51 | gmcharlt | ah, gotcha |
| # | 21:42:06 | eeevil | dbs++ for that |
| # | 21:42:31 | eeevil | ok, I'll toss that over in 2.0.3 and then re-wrap in the morning |
| # | 21:42:45 | dbs | postgresql++ # for being a civilized database |
| # | 21:42:54 | gmcharlt | heh |
| # | 21:43:20 | gmcharlt | having_to_do_this_kind_of_bookkeeping--, though |
| # | 21:43:36 | eeevil | indeed |
| # | 21:43:52 | eeevil | that juggling was totally not worth it |
| # | 21:46:47 | gmcharlt nominates the release packager for any future brown bag releases: |
| # | 21:46:48 | gmcharlt | http://www.flickr.com/photos/s1mbiosis/119206824/ |
| # | 21:47:59 | dbs looks at 950.data.seed-values.sql in rel_1_6_1 and wonders why ADMIN_ACQ_FUND is being inserted into permission.perm_list twice |
| # | 21:49:34 | tsbere | BTW eeevil, I think we can blame you for grace periods being rendered useless, but it happened back in 2009 according to SVN logs. (I was wondering what the commit message was, dug it up) |
| # | 21:50:02 | eeevil | tsbere: yes, I'm sure that's true |
| # | 21:50:25 | dbs happy to trade grace periods for accurate fines at check-in time |
| # | 21:50:35 | tsbere | And that was, I believe, the intent. |
| # | 21:50:49 | eeevil | it was, for hourly circs |
| # | 21:50:57 | dbs | and that was why I said what I said |
| # | 21:51:12 | eeevil | with the plan to move to ou setting for grace |
| # | 21:52:13 | eeevil | (that being the "grace period is a function of the library as a whole" viewpoint, vs the "grace period is a function of the specifc circulation" viewpoint that tsbere is currently working on) |
| # | 21:52:52 | eeevil | (I mention that because the original is closer to the former, so it's a change in semantics, not just how it gets configured) |
| # | 21:53:23 | eeevil | but, to be honest, I don't care either way personally ;) |
| # | 21:54:01 | dbs | yeah. I could see an OU setting for grace period = some % of the circ duration (rather than the "1 unit of circ duration" thing) as a fallback where no specific grace period was specified |
| # | 21:54:02 | tsbere | I figure with it tied to the circ it can still be set as a library level setting, but tied to an ou setting it can't be rigged as a circ level. |
| # | 21:54:44 | eeevil | tsbere: yes, as a circ setting it's more flexible in terms of configuration |
| # | 21:55:41 | tsbere | BTW, my current setup is using 0 as a default on the seed recurring fine rules. Should I change that? |
| # | 21:56:16 | eeevil | the one property it loses (which is not something I'm arguing for, mind you, but just a functional difference) is the ability to change the amount of grace on existing circs by changing the ou setting (not that it works in 2.0 anyway...) |
| # | 21:57:31 | eeevil | that's a good question ... I'm tempted to suggest 1, since that's the stock (intended) default via cron, and provide instructions for adjusting that (perhaps via \set variable at the top of the upgrade script) |
| # | 21:58:10 | tsbere | I figure grace period being set on circ at least updates on renewal. Renewal count doesn't even do that ;) |
| # | 21:58:58 | eeevil | hrm... so, I know at one point we only ran the fine generator on checkin for circs with a duration shorter than a day |
| # | 21:59:32 | tsbere | I don't see that in the changelogs, but I didn't go through them all. Maybe that never made it into trunk (the only place I am looking) but was only in 1.6 somewhere? |
| # | 21:59:34 | eeevil | for 2.0, as a bug fix, would that sound like a reasonable compromise so that grace works? |
| # | 21:59:47 | eeevil | tsbere: possibly ... probably, even |
| # | 21:59:58 | tsbere | dbwells I think mentioned something about that |
| # | 22:01:38 | tsbere | And yea, running only on shorter duration circs seems like a decent workaround, with the understand that they won't have a grace period. |
| # | 22:01:44 | tsbere | *understanding |
| # | 22:03:55 | eeevil | right |
| # | 22:04:04 | dbs | dang. http://svn.open-ils.org/trac/ILS/changeset/18962/branches/rel_1_6_1/Open-ILS/src/sql/Pg/950.data.seed-values.sql introduced the dupe ppl entries |
| # | 22:04:53 | eeevil | well: duration % 1 day != 0 |
| # | 22:05:41 | tsbere | eeevil: Actually, the duration shouldn't be the issue. The fine interval would make more sense to be checking, IMO. |
| # | 22:06:12 | eeevil | dbs: i notived some failures loading 1.6.1.7 |
| # | 22:06:32 | dbs | eeevil: I'm working on removing those dupes |
| # | 22:06:55 | eeevil | noticed, even |
| # | 22:08:26 | eeevil | tsbere: sure, that works. they're generally linked (greater than a day duration usually has day fine interval), but I agree |
| # | 22:16:42 | tsbere | I have started my upgrade script, if only to put notes in it. Have two \set lines at the top, one for the default grace period for recurring fine rules (default 1) and one for whether or not to update active circs (also default 1, comment says to change to 0 to disable updating circs). |
| # | 22:18:21 | tsbere hopes that any query, no matter how complex, with a "WHERE (blah) AND 0" passes really quickly, compared to a "WHERE (blah) AND 1" where it actually works |
| # | 22:19:12 | eeevil | tsbere: that'll work, yes. |
| # | 22:19:39 | eeevil | out of pedantism I'd probably cast that to a bool |
| # | 22:19:54 | tsbere | Hmmm |
| # | 22:19:56 | tsbere goes to run a test |
| # | 22:22:16 | eeevil | http://paste.lisp.org/display/120369 |
| # | 22:23:07 | dbs | pedantism / easier to read in 6 months and know that a boolean test really was intended |
| # | 22:23:35 | tsbere | Well, my test works |
| # | 22:23:51 | tsbere | My variable is no longer defaulting to 1. It now defaults to TRUE and says to change to FALSE. |
| # | 22:24:16 | dbs | Nice! |
| # | 22:25:00 | tsbere | Apparently \set works a lot like a define in that it causes future use of the variable to be replaced outright. May even be able to put query chunks in it, but don't want to try. |
| # | 22:27:17 | tsbere | Secondary test: \set doesn't work in pgadmin. Not that I would normally run upgrade scripts through it, still good to know. |
| # | 22:28:18 | tsbere | eeevil: paste looks good to me after a very quick look, provided you caught all the references to id. |
| # | 22:28:36 | tsbere | No, wait |
| # | 22:28:41 | tsbere | eeevil: It doesn't look good. |
| # | 22:29:12 | tsbere | ANd..now it does. Ok, what is my remote desktop doing when I alt-tab |
| # | 22:29:51 | tsbere grabs the stupid paste into his local browser |
| # | 22:30:29 | tsbere | Ok, local browser says good. Remote desktop + something in firefox = unhappy rendering. |
| # | 22:31:07 | eeevil | \set is a psql thing |
| # | 22:31:55 | eeevil | so, yeah, other tools may not understand it |
| # | 22:32:36 | eeevil | (and yes, you can put all kinds of junk in a \set variable) |
| # | 22:33:02 | eeevil | ok ... I'm 'bout burned out for the day. time to rest |
| # | 22:33:18 | tsbere | So every time I bring up firefox it decides to wipe out around 9 chars from rendering. Which I was seeing as a - missing on one line. Then it wasn't, but there was a missing ;, then that wasn't but several words had extra spaces. |
| # | 22:33:32 | dbs | eeevil++ # thanks for everything man |
| # | 22:47:05 | dbs tries creating 2.0 schema on postgresql 9.0; "use strict;" now being in effect means unhappiness |
| # | 22:47:16 | dbs | which doesn't bode well for in-place upgrades |
| # | 22:50:36 | bott-otr has left #evergreen |
| # | 22:52:39 | tsbere | I thought we knew that. |
| # | 22:55:31 | tsbere recalls previous wondering if we would need a "get 2.0 to 9.0 compatible before you upgrade your DB, then get 2.0 to 2.1 once you are on 9.0 afterwards" upgrade plan |
| # | 22:57:23 | eeevil | hrm... I have a 2.0 schema on 9.0 |
| # | 22:57:37 | dbs | tsbere: I thought that those problems had been resolved |
| # | 22:58:13 | eeevil | well, I take that back. trunk. but should be no better for 9.0 than 2.0 |
| # | 22:59:04 | dbs | http://paste.lisp.org/display/120370 |
| # | 22:59:52 | dbs thinks... I _do_ have plperl installed, right? |
| # | 23:01:11 | dbs | hmm. maybe that pgsql 9.0 package I downloaded from postgresql.org is sketchy |
| # | 23:09:06 | dbs | Yeah. If I replace that method body with just "return undef;" then I still get the same error. BOOOOOO |
| # | 23:23:21 | dbs tries http://yum.pgrpms.org/howtoyum.php instead |
| # | 23:33:38 | eeevil | dbs: aren't we using plperlu for everything now? |
| # | 23:33:53 | dbs | eeevil: yes |
| # | 23:34:52 | eeevil sleeps |
| # | 23:48:25 | dbs | yum.pgrpms.org appears to be the good stuff, getting much further with it |
| # | 23:49:42 | dbs | yup, have a nice 2.0 schema on 9.0 now. yay |
| # | 23:55:21 | dbs has quit IRC |
April 10-13