2011-07-20T03:50:27 *** edoceo has quit IRC 2011-07-20T05:05:18 *** edoceo has joined #evergreen 2011-07-20T08:04:21 *** kmlussier has joined #evergreen 2011-07-20T08:40:12 *** sfortin has joined #evergreen 2011-07-20T08:56:29 *** ernieSimuro has quit IRC 2011-07-20T09:04:42 *** Dyrcona has joined #evergreen 2011-07-20T09:06:10 *** Meliss has joined #evergreen 2011-07-20T09:15:57 *** LBA has joined #evergreen 2011-07-20T09:26:24 *** dbs has joined #evergreen 2011-07-20T09:31:51 *** jenny1 has joined #evergreen 2011-07-20T09:37:04 Huh 2011-07-20T09:37:12 I just crashed out the client by closing it at the wrong moment. 2011-07-20T09:43:30 xulrunner crash? 2011-07-20T09:43:44 *** akilsdonk has joined #evergreen 2011-07-20T09:44:22 *** demiankatz has joined #evergreen 2011-07-20T09:44:54 Good morning. Anyone have a moment to help with some OpenSRF upgrade troubleshooting? 2011-07-20T09:44:55 I fixed a broken patron (only card on the account was inactive). Tested to make sure they load, as soon as they started loading I closed the entire window. Got an error window in response. 2011-07-20T09:45:21 Hmm, LP looks different today. 2011-07-20T09:45:40 Or maybe I only just noticing some of the differences. 2011-07-20T09:45:53 demiankatz: Go for it 2011-07-20T09:46:27 I've just upgraded to 2.0 following the instructions at http://open-ils.org/dokuwiki/doku.php?id=opensrf:2.0:install but now the OpenSRF C process won't start. 2011-07-20T09:46:32 demiankatz pasted "opensrf error log" at http://paste.lisp.org/display/123379 2011-07-20T09:46:42 There's the error log I'm seeing. 2011-07-20T09:46:57 demiankatz: upgraded from 1.6? 2011-07-20T09:47:04 Correct. A recent system update also upgraded the jabber service, so it's possible that is a factor as well. 2011-07-20T09:47:10 if so, you'll need to recompile EG 2011-07-20T09:47:31 symbol tables changed between 1.x and 2.x 2011-07-20T09:47:39 I'm currently trying to test with the example configs shipped with OpenSRF -- haven't tried to get Evergreen working yet. 2011-07-20T09:48:01 so the opensrf apps are trying to use functions (one in particular, actual) that don't exist 2011-07-20T09:48:04 hrm... 2011-07-20T09:48:10 well, that's odd 2011-07-20T09:48:50 upgrading jabber /could/ have caused problems with (or killed) the mnesia db 2011-07-20T09:48:55 (it's user db) 2011-07-20T09:48:58 its, even 2011-07-20T09:49:25 I can certainly try recreating all of my users -- that's not too big of a project. 2011-07-20T09:49:34 * tsbere has had thoughts of providing a "use a database-driven user db setup with ejabberd" just because the mnesia db is a PITA at times 2011-07-20T09:50:54 I'm getting "user already registered" errors when I try to re-register my users... so they seem to still be in the database. Is it worth unregistering them and starting over? 2011-07-20T09:51:46 case of old opensrf libs being in the "old" locations on disk? I don't remember offhand if they moved between opensrf 2.0 and before. 2011-07-20T09:52:30 jeff: they didn't move 2011-07-20T09:52:45 dbs: thanks. 2011-07-20T09:53:01 I did see some old chat logs with a similar error message, and there was some discussion of things being in /opensrf vs. /openils... but that doesn't seem to be the case here -- everything appears to be in /openils where it belongs. 2011-07-20T09:53:05 The OpenSRF Perl modules moved out of /openils/lib/perl5 but I think that was between OpenSRF 1.4 and 1.6 2011-07-20T09:53:55 demiankatz: did the ejabberd upgrade mess with ejabberd.cfg? 2011-07-20T09:54:23 Let me check... 2011-07-20T09:54:38 *** yboston has joined #evergreen 2011-07-20T09:55:16 File modification dates suggest it hasn't changed recently. 2011-07-20T09:55:33 (assuming /etc/ejabberd/ejabberd.cfg is the right file) 2011-07-20T09:55:55 demiankatz: yep, that would be the right file 2011-07-20T09:56:18 It also appears that the Perl service starts up just fine... it's only the C service that's choking. Not sure if that's significant. 2011-07-20T09:57:26 you're using the -l flag for osrf_ctl.sh I assume? 2011-07-20T09:57:30 Yes. 2011-07-20T09:57:51 To test just the C service, I've been using: 2011-07-20T09:57:52 osrf_ctl.sh -l -a start_c 2011-07-20T09:58:43 moodaepo: http://open-ils.org/dokuwiki/doku.php?id=server:git_install looks pretty sketchy (and old) to me; if you want locales, we should properly document how to build locales in the README 2011-07-20T09:59:20 dbs: Late last night, I pointed out the two places where moodaepo was getting the errors. 2011-07-20T09:59:31 demiankatz: did you run ldconfig after compiling & installing OpenSRF? 2011-07-20T09:59:38 Yes. 2011-07-20T09:59:59 Is there a library config I should double-check to be sure ldconfig actually loaded the right things? 2011-07-20T10:00:53 Wait, answered my own question -- /etc/ld.so.conf.d/osrf.conf looks right to me. 2011-07-20T10:00:59 bshum: okay, I saw moodaepo's mention of that page last night (was feeling pretty under the weather) and it was bugging me 2011-07-20T10:01:03 bshum++ 2011-07-20T10:01:33 (I still think that the git:install page should just be instructions for how to clone a git repo, then point to the README) 2011-07-20T10:01:59 demiankatz: maybe try stop_all again, and ensure that no opensrf processes are still running 2011-07-20T10:02:10 ps wax | grep -i open 2011-07-20T10:03:12 Aww, pinesol didn't like my insert of the bad unicode character either. 2011-07-20T10:03:42 I've definitely tried stopping already -- that's how I noticed that the C service was broken, since when I stopped things I was notified that the C service wasn't running, but everything else shut down properly. 2011-07-20T10:04:07 I just noticed that there's a /usr/share/ejabberd/ejabberd.cfg file on my system; I wonder if that could be conflicting with /etc/ejabberd/ejabberd.cfg somehow. 2011-07-20T10:04:43 demiankatz: unlikely. It's probably used to seed /etc/ejabberd/ejabberd.cfg 2011-07-20T10:05:08 Yes, that would make sense -- just grasping at straws. :) 2011-07-20T10:10:55 Would it make sense to try to test Jabber itself on a more fundemental level? If so, is there a good way to do that? 2011-07-20T10:11:15 demiankatz: settings-tester.pl tests some of the ejabberd accounts 2011-07-20T10:11:47 Thanks, I'll give that a shot. 2011-07-20T10:12:05 but I would suggest stop_all, ensure no opensrf services are still running, clear logs, start_router - check logs - start_perl - check logs - and then try hitting one of the perl services from srfsh 2011-07-20T10:12:53 Checking Jabber connection for user router, domain public.localhost 2011-07-20T10:12:53 Use of uninitialized value $@ in concatenation (.) or string at /usr/local/share /perl/5.10.1/OpenSRF/Transport/SlimJabber/Client.pm line 147, line 32. 2011-07-20T10:12:53 * Error connecting to jabber: 2011-07-20T10:12:53 SCALAR(0x24bbde0) 2011-07-20T10:13:21 well, hello! that's a good message 2011-07-20T10:13:27 The opensrf accounts work, but both of the router accounts give similar errors. 2011-07-20T10:14:08 mind you, there's a good chance the settings-tester.pl code has fallen out of sync, it has been forever since I've looked at it 2011-07-20T10:15:11 any chance the router passwords are messed up in opensrf_core.xml? maybe the unregister / reregister step would be a good idea 2011-07-20T10:15:30 I'll give it a shot. 2011-07-20T10:17:11 Ahh, sheer stupidity! When I updated the file, I searched for "passwd" and filled in passwords... but some of the passwords are in "password" tags so I missed those. Duh. 2011-07-20T10:17:55 demiankatz: I've always disliked how the tags are different, but kept forgetting to synchronize those at significant release boundaries 2011-07-20T10:18:38 The only thing that mystifies me is that I'd swear at one point I tried restoring my old configuration file (which does have all the passwords in the right places) and it still didn't work. But maybe I did something else wrong. In any case, opensrf seems happy again. Thanks for the help. 2011-07-20T10:18:38 also, we would obviously benefit from nice, clear error messages when a given jabber user can't connect 2011-07-20T10:19:39 Yeah, a slightly more obvious error message might have led me to the right place a little faster... but this has been a good troubleshooting exercise. :) 2011-07-20T10:21:48 fail fast, fail loud :) 2011-07-20T10:22:19 ...share your embarrassing failures on IRC. :) 2011-07-20T10:23:07 Anyway, things are looking pretty good now -- I've restored my old Evergreen configs and OpenSRF is still happy... so now to upgrade to 2.0.7. Wish me luck! 2011-07-20T10:23:30 Happiness! 2011-07-20T10:27:58 demiankatz: good luck 2011-07-20T10:31:42 mrpeters-isl: lp#647121, did you try hitting Cancel on the override dialogs? re: skull & crossbones 2011-07-20T10:32:19 oooh, no 2011-07-20T10:32:28 demiankatz: I'm having that same opensrf_c issue on new installs of 1.6.1.8 on Debian lenny... I'll have to triple-check my configs,but I was just as mystified 2011-07-20T10:32:46 still working on it (gave up briefly) 2011-07-20T10:32:57 good call, phasefx 2011-07-20T10:33:00 that's still broken 2011-07-20T10:33:09 * dbs was just about to ask the same question of mrpeters-isl :) 2011-07-20T10:33:15 sorry about that guys 2011-07-20T10:33:24 i think i might know how to fix this though 2011-07-20T10:33:33 doesnt this probably need an entry in ils_events.xml? 2011-07-20T10:34:06 *** AaronZ-PLS has quit IRC 2011-07-20T10:34:28 stacktrace shows "ilsevent":"", 2011-07-20T10:39:43 csharp: good luck! I hope your solution turns out to be as easy as mine. 2011-07-20T10:39:46 *** demiankatz has left #evergreen 2011-07-20T10:48:53 dbs/phasefx: if someone says "No" to the override there isn't really anything else that should be displayed, right? 2011-07-20T10:49:29 i'm updating checkout.js/ils_events.xml to handle it quietly after you say "No" to an override 2011-07-20T10:49:34 mrpeters-isl: there's a relatively new breed of events that don't get defined in ils_events.xml. checkout.js is trying to handle those by looking for ilsevent == null, but apparently that has changed such that it should probably look for "" as well. 2011-07-20T10:49:58 aha, so this can be much smaller 2011-07-20T10:50:06 i was thinking i'd need to track down all of the unhandled events 2011-07-20T10:50:29 actually, to be correct, checkout.js should look at something else other than ils_event, rather than assume any "" or null it comes across is "handled" 2011-07-20T10:51:10 the idea is that a "handled" event (one that staff handled by saying No to the override dialog) shouldn't further bother anyone 2011-07-20T10:51:50 well.. I think we're throwing the override prompt on any undefined event in this case 2011-07-20T10:51:57 so you think just having it handle "" in addtion to a null is the way to go? 2011-07-20T10:52:02 so it's okay to assume they're handled 2011-07-20T10:52:11 mrpeters-isl: yeah 2011-07-20T10:52:12 rather than tracking down all of the unhandled events that are "new" 2011-07-20T10:52:28 just add case "": right above case null: 2011-07-20T10:52:31 see if that works 2011-07-20T10:53:24 just a new twist on an old theme.. values changing slightly (am I getting a number or a number as a string? a null or an empty string? bleh:) 2011-07-20T10:55:07 maybe switch stmts tightened up their underlying comparison operator from == to === in recent xulsss 2011-07-20T10:55:22 maybe 2011-07-20T10:59:05 hmm no dice on that 2011-07-20T11:00:41 mrpeters-isl: oh, the switch statement has a funky expression it's testing 2011-07-20T11:00:48 * tsbere dislikes "we did X with our new items and they still aren't working" when they have given absolutely 0 item barcodes for us to look at 2011-07-20T11:01:34 mrpeters-isl: so it's turning "" into NaN before it gets to the case :-/ 2011-07-20T11:02:44 NaN = not a numbeR? 2011-07-20T11:02:47 mrpeters-isl: instead of that case "":, try replacing the switch with this: switch(test_permit[i].ilsevent == null || test_permit[i].ilsevent == '' ? null : Number(test_permit[i].ilsevent)) { 2011-07-20T11:03:52 ugh, == really? 2011-07-20T11:04:29 dbs: I haven't really internalized ===, have to look it up each time. Alternate suggestions welcome 2011-07-20T11:05:55 since success is already tested, we could just do switch( ! test_permit[i].ilsevent ? null | Number(test_permit[i]) ) 2011-07-20T11:05:55 did the trick, phasefx 2011-07-20T11:06:15 pushing this up to working/mrpeters-isl/event_handling 2011-07-20T11:10:30 http://git.evergreen-ils.org/?p=working/Evergreen.git;a=commitdiff;h=926d8bbfd25e39db17fdb7c505d14c8e2da4da5c 2011-07-20T11:11:29 thanks, phasefx, for saving me a ton of work hunting down all of these and adding ils_events for them! 2011-07-20T11:14:48 random thought: i wonder how irc discussion affects coding style when it comes to single line vs multi-line solutions. 2011-07-20T11:16:09 * dbs thinks single-line solutions are baked into phasefx's ROM 2011-07-20T11:16:52 hah! see, i almost typed that in #code4lib so that it wouldn't seem like i was picking on phasefx ;-) 2011-07-20T11:17:51 * dbs would: 1) assign test_permit[i].ilsevent to a local variable; 2) use local var in the dump stmt; 3) set the local var to null in a preliminary if() stmt; 4) use the local var in the switch 2011-07-20T11:18:03 and then there would be 10 more lines :) 2011-07-20T11:19:23 and I would probably have introduced a subtle bug or stomped on a global var 2011-07-20T11:22:17 any opinions on how to categorize this bug? https://bugs.launchpad.net/evergreen/+bug/807258 2011-07-20T11:22:24 Opinion/Wishlist perhaps? 2011-07-20T11:24:04 I'd say... wishlist with a status of in progress. Isn't that one of the GSOC students? 2011-07-20T11:24:26 think so 2011-07-20T11:30:51 yup, Joe is one of the GSoC students 2011-07-20T11:31:03 * tsbere tests mrpeters-isl's event_handling branch 2011-07-20T11:31:45 does anyone recall in 1.x versions (or at least before the new single-page patron registration) that Permission Groups were unselectable? 2011-07-20T11:32:17 We're ending up with people assigning patrons to a group, "Patrons" for example, that was historically "greyed-out" and just used as a group heading. 2011-07-20T11:33:16 mrpeters-isl: Yes, I recall that. 2011-07-20T11:33:19 * mrpeters-isl tries to think of cases where it'd be valid to assign someone to one of those, instead of picking "Resident" or "Student" or something like that. 2011-07-20T11:33:46 I think our system does that now. 2011-07-20T11:34:10 If there are valid cases, then it's not a bug...just a customization we'd like to pursue. If there aren't valid cases, then i'd call it a bug since it wasn't previously possible to assign that profile. 2011-07-20T11:34:21 bshum: the old way, or the "new" way? 2011-07-20T11:34:47 mrpeters-isl: In our 2.0 system, user permission groups that are marked as "can have users" = false are grayed out in our selection dropdown. 2011-07-20T11:34:48 yes, permission groups such as Patrons were un-selectable. we had people in Patrons from migration, and it was a (iirc, simple) config change to make Patrons selectable -- i think it was just a lack of group application permission on staff users. 2011-07-20T11:34:50 So that's... normal? 2011-07-20T11:35:07 oh, then maybe it was just the can have users bit on the Patrons group. 2011-07-20T11:35:09 I'm picturing this could kind of like the way "can have users" works for Org Units. If that's false then the heading is greyed out. 2011-07-20T11:35:23 very similar. 2011-07-20T11:35:33 jeff: so that exists currently you think? 2011-07-20T11:35:58 * mrpeters-isl has looked for it...could be going blind! 2011-07-20T11:35:58 Sorry 2011-07-20T11:36:03 usergroup = true/false 2011-07-20T11:36:08 Is what probably controls that 2011-07-20T11:36:10 mrpeters-isl: it exists via group application permission 2011-07-20T11:36:19 for use 2011-07-20T11:36:22 * phasefx has been trying to stay under 80 chars with new stuff; it's had a change on the prevalence of one-liners :) 2011-07-20T11:36:27 and what bshum said for "can_have_users" 2011-07-20T11:36:51 ok, so if checked then it CAN have users? 2011-07-20T11:36:58 My understanding: If you don't have group application permission it doesn't show up in your list when editing a patron. If you do, it disables on not being in the "can have users = true" state. At least in master. 2011-07-20T11:37:00 phasefx: ooh, EEPROM! 2011-07-20T11:37:23 * dbs and his limited brain thanks phasefx++ profusely 2011-07-20T11:37:28 mrpeters-isl: Check your permission.grp_tree entry for Patrons, perhaps it's usergroup = TRUE 2011-07-20T11:37:36 yeah, it is 2011-07-20T11:37:38 dbs: I have a fear of electricity though; been shocked way too many times 2011-07-20T11:37:46 * phasefx twitches 2011-07-20T11:37:50 * dbs lols 2011-07-20T11:37:51 so if i uncheck that it'll prevent new users from being added with that group? 2011-07-20T11:37:57 mrpeters-isl: Correct 2011-07-20T11:37:59 * tsbere is considering making mrpeters-isl's event_handling branch his first push 2011-07-20T11:38:03 Though any existing users in that group 2011-07-20T11:38:13 Will come up with a bad value 2011-07-20T11:38:15 If you edit them 2011-07-20T11:38:22 yeah...but they need fixin' anyways! 2011-07-20T11:38:34 so this will force the librarian to pick the right value 2011-07-20T11:39:17 It should. 2011-07-20T11:39:18 tsbere: maybe you should add a signed-off-by phasefx as the originator of the patch :) 2011-07-20T11:39:40 dbs: Heh. 2011-07-20T11:39:41 oh no, let mrpeters-isl get credit for my oneliners ;) 2011-07-20T11:39:43 3 sign-offs better than one 2011-07-20T11:39:44 agreed 2011-07-20T11:39:51 hah 2011-07-20T11:39:58 i would have wasted a lot of time without him pointing that out 2011-07-20T11:40:01 * tsbere refuses to add a sign-off for someone else 2011-07-20T11:40:32 * phasefx feels compelled to actually test anything he signs off on if he can help it 2011-07-20T11:41:06 Hey, so do I. Which is why I am loading rel_2_0 in my dev box to test it there, just because. 2011-07-20T11:41:22 mrpeters-isl: when you mark a ticket as Confirmed, you're actually duplicating the issue? 2011-07-20T11:42:25 * dbs notes that mrpeters-isl's commit doesn't follow git comment practice described in http://evergreen-ils.org/dokuwiki/doku.php?id=contributing#submitting_code_to_the_project 2011-07-20T11:43:08 yes. it's either something I've gone in and tested or its something we've experienced many times here in Indiana (eg - 758982) 2011-07-20T11:43:08 * tsbere hasn't even looked at the comment yet, has been focusing on the "test if the code changed work" stage <_< 2011-07-20T11:44:17 you're right. it is lacking. 2011-07-20T11:44:21 first line should be shorter; somewhere should point back to the LP bug that it addresses; and there's an opportunity to include in the body of the commit a stmt like "follows a suggestion by phasefx in IRC; tested and works"! 2011-07-20T11:44:37 any way i can amend it easilly? i know that gets sticky with public git repos 2011-07-20T11:44:45 Hmmm. My dev box barfed on rel_2_0. Without mrpeters-isl's change. 2011-07-20T11:44:49 heh 2011-07-20T11:45:23 mrpeters-isl: Just git commit --amend and force push (prefix the local with a +). Not that big a deal. :P 2011-07-20T11:45:23 mrpeters-isl: given that you have the audience of people testing it, you could "git commit --amend" and force-push an update to that branch 2011-07-20T11:45:44 if it was to be a long-lived feature branch, different matter :) 2011-07-20T11:46:13 so, the fun is i've deleted the local branch 2011-07-20T11:46:26 you can check out the remote branch 2011-07-20T11:47:29 * tsbere is going to assume that since the code cherry-picks into rel_2_0 without conflicts and the surrounding code doesn't appear to have changed since then that the rel_2_1 and master tests validate the rel_2_0 test, because his dev box is not set up for the rel_2_0 perl locations 2011-07-20T11:47:51 * tsbere is also going to wait for a better commit message, though 2011-07-20T11:47:52 git checkout -b lp647121 remotes/working/user/mrpeters-isl/event_handling (or something like that) 2011-07-20T11:49:46 * tsbere has an urge to edit the contributing page to change "there might be bugs" to include a ", in fact we are positive there are" after it <_< 2011-07-20T11:50:59 tsbere++ 2011-07-20T11:51:41 * dbs de-typos 'branc' 2011-07-20T11:51:47 *** phasefx has quit IRC 2011-07-20T11:54:56 http://git.evergreen-ils.org/?p=working/Evergreen.git;a=commitdiff;h=5af5a65c17c5132fac8cdc3d2657a13cd85dc67f better? 2011-07-20T11:58:12 general FYI for those struggling with bib search speed in 2.0 2011-07-20T11:58:13 http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/collab/gmcharlt/rel_2_0_rank_cd 2011-07-20T11:58:49 mrpeters-isl: Generally I try and put a blank line before the sign-off, and git prefers a blank line after the first line of the commit. 2011-07-20T11:59:33 ok, updated 2011-07-20T12:00:28 apparently it's not picking up my new lines 2011-07-20T12:00:30 gmcharlt: hrm... I thought that made it into 2.0 already ... anyway, yes, that and removing all rows from search.relevance_adjustment, indeed 2011-07-20T12:00:57 which, of course, you said in the commit msg :P 2011-07-20T12:01:14 mrpeters-isl: Perhaps your line endings are off? 2011-07-20T12:02:26 oh, I see ... I gave that to Callender to give to mrpeters-isl for testing by IN ;) ... it's in /a/ 2.0, just not /the/ 2011-07-20T12:04:44 tsbere: I see http://img15.imageshack.us/img15/6941/commitmsg.png 2011-07-20T12:05:52 we haven't had any troubles with the rank_cd patch, obviously 2011-07-20T12:06:14 or i'd have been crying to someone about it :) 2011-07-20T12:06:24 mrpeters-isl: Put an extra blank line between the first and second lines. Beyond that, newlines every 80 chars probably isn't a bad idea either. 2011-07-20T12:07:03 * tsbere gets a bright-red highlighted line if he has no blank line after the first line in a commit message 2011-07-20T12:07:04 is there a variable i can set to have vi do that for me when it's envoked from git commit ? 2011-07-20T12:07:32 gmcharlt: your commit for rank_cd lists mrpeters-isl as the author? 2011-07-20T12:07:38 I enable syntax highlighting in vim and get nice colors indicating even the end of the "safe" first line. 2011-07-20T12:07:52 mrpeters-isl: export EDITOR=vim 2011-07-20T12:08:16 or, duh... yeah, my vimrc enables syntax highlighting 2011-07-20T12:08:19 well no, i have that dbs. i mean a way to have vi start a new line after 80 char's, but only when i'm using it for git 2011-07-20T12:09:03 syntax on (in .vimrc) 2011-07-20T12:09:03 Well, you could tell it to do that for files named COMMIT_EDITMSG 2011-07-20T12:09:37 fedora's default vimrc is most excellent 2011-07-20T12:10:02 textwidth=78 2011-07-20T12:11:16 the git commit message settings here actually use textwidth=72 2011-07-20T12:11:26 syntax=gitcommit 2011-07-20T12:11:56 *** agJohn has joined #evergreen 2011-07-20T12:13:49 dbwells: Do you have a moment to answer a couple of serials questions, or should I mail the question to the dev list or pose my questions in some other more asynchronous way? 2011-07-20T12:14:14 @seen dbwells 2011-07-20T12:14:14 jeff: dbwells was last seen in #evergreen 23 hours, 11 minutes, and 20 seconds ago: dbs++ # thanks for leading, I do find them helpful 2011-07-20T12:15:54 dbs: convulated path - idea was ultimately eeevils, but put in place at ISL and made it into the ISL git repo under mrpeters-isl 's name 2011-07-20T12:16:11 dbs pasted "gitcommit filetype for vim (from vim 7.3, for mrpeters-isl)" at http://paste.lisp.org/display/123382 2011-07-20T12:16:12 * tsbere asks that someone review https://bugs.launchpad.net/evergreen/+bug/810748 if only so that he can be comfortable installing it this weekend to shut up the people who it is intended to shut up <_< 2011-07-20T12:16:35 mrpeters-isl: found in /usr/share/vim/vim73/syntax/gitcommit.vim 2011-07-20T12:17:54 *** phasefx has joined #evergreen 2011-07-20T12:18:22 eeevil: if no objections from the peanut, I'll just add a switch in opensrf.xml to make it optional and propose pushing the lot to rel_2_0, yes? 2011-07-20T12:18:28 *peanut gallery 2011-07-20T12:20:51 dbs: yep, i've got it working nicely now 2011-07-20T12:20:58 sweet 2011-07-20T12:21:04 * berick makes sacrifice to the Great Peanut 2011-07-20T12:21:06 and i forced the update, but still no dice on the repo 2011-07-20T12:21:34 oh, wait its good 2011-07-20T12:21:59 mrpeters-isl: Indeed 2011-07-20T12:22:14 For the logs -- I found http://vim.runpaint.org/extending/integrating-vim-with-git/ very helpful. 2011-07-20T12:22:27 * dbs is missing out on something - opensrf.xml switch for what? 2011-07-20T12:22:28 And it looks like there are some extra tools available there that aren't shipped by default. 2011-07-20T12:22:58 dbs: for gmcharlt/rel_2_0_rank_cd i think 2011-07-20T12:23:41 yep 2011-07-20T12:23:45 oh, for which version of the relevance algo, got it 2011-07-20T12:23:46 gmcharlt: no objections, certainly a regression fix 2011-07-20T12:23:46 mrpeters-isl: Now, though, the patch gets to wait for me to go get and eat lunch. ;) 2011-07-20T12:23:58 no objections here 2011-07-20T12:24:11 good idea, tsbere going to do the same 2011-07-20T12:24:21 Found a neat helper function for title-case formatting. Emailed the author asking for GPL+DCO so we can include it. http://postgresql.1045698.n5.nabble.com/Re-Proper-case-function-td2851615.html 2011-07-20T12:24:24 gmcharlt: by all means, amend that so i'm not the author if you want 2011-07-20T12:24:31 i dont want credit for something i had nothing to do with :) 2011-07-20T12:25:45 mrpeters-isl: And who deserves the credit? And who deserve the fame? Nikolai Ivanovitch Lobachevsky is his name! 2011-07-20T12:25:54 s/fame/blame/? 2011-07-20T12:26:10 sylvar: this is to address the problem that we don't have a non-normalized version of the title handy in 2.0? 2011-07-20T12:26:13 I can't tell if I've listened to too much Tom Lehrer or nt nearly enough 2011-07-20T12:26:32 :) 2011-07-20T12:26:49 sylvar: there's never too much Tom Lehrer.... 2011-07-20T12:26:57 dbs: My itch was incoming patron data with nary a lower-case letter in the patrons' names. But it could help that too. 2011-07-20T12:27:07 sylvar: Well, maybe if you do start poisoning pigeons in the park. 2011-07-20T12:27:33 Or turning my Pop into the Pope. 2011-07-20T12:27:56 Don't forget to genuflect. :) 2011-07-20T12:29:21 mrpeters-isl: well, since you were the first to actually create a patch, your name can stay :) 2011-07-20T12:29:27 * gmcharlt is just the humble scribe in this case 2011-07-20T12:32:06 Dyrcona pasted "bills, bills, bills" at http://paste.lisp.org/display/123383 2011-07-20T12:33:00 * Dyrcona is an abusive admin. :) 2011-07-20T12:38:33 *** dbs has quit IRC 2011-07-20T12:40:42 * Dyrcona is trying to figure out what goes on with the SIP23738 branch sometimes not seeming to find bills. 2011-07-20T12:44:21 Dyrcona annotated #123383 "velly interesting...." at http://paste.lisp.org/display/123383#1 2011-07-20T12:46:03 Yes, ladies and gentleman, someone owes $57,621.64 in library fines. 2011-07-20T12:47:11 * tsbere has a guess for the name of that someone 2011-07-20T12:50:21 *** ernieSimuro has joined #evergreen 2011-07-20T12:53:22 * Dyrcona thinks the undef is more interesting... 2011-07-20T12:54:49 * Dyrcona doesn't have to guess: N/A Stolen? 2011-07-20T12:55:07 Can someone tell me how we determine the staus of a hold, when we create a hold its status is waiting for copy. can someone tell me which tables/fields define the various status. 2011-07-20T12:55:14 I am assuming that, in that case, the call just plain timed out due to way too many things on it. 2011-07-20T12:55:39 ernieSimuro: Those statuses (for holds) are determined by the hold's state. 2011-07-20T12:55:43 Boo, so, apparently our system is still blocking patrons from placing holds when they reach max fines even though we removed that from the block list names in the standing penalty :( 2011-07-20T12:56:00 ernieSimuro: There is no table listing them (although there are likely translations hiding somewhere). 2011-07-20T12:56:09 bshum: did you restart everything? 2011-07-20T12:56:19 Dyrcona: Hmm, everything 2011-07-20T12:56:24 I did at one point 2011-07-20T12:56:32 But not memcached, guess I could try that. 2011-07-20T12:56:33 bshum: Indb circ/hold rules or legacy script? 2011-07-20T12:56:43 tsbere: indb circ/hold rules 2011-07-20T12:57:49 That shouldn't even require a restart of things, then. 2011-07-20T12:58:06 It should start having an effect as soon as HOLD was no longer in the block list, I think. 2011-07-20T12:58:15 That's what I would have thought 2011-07-20T12:58:22 But experimentation is showing otherwise. 2011-07-20T12:58:31 You sure it is the max fines one stopping them? 2011-07-20T12:58:46 tsbere: The patron only has a silent note and the max fines 2011-07-20T12:58:59 So it might be the silent note, but I don't think so 2011-07-20T12:59:07 Hmmm. 2011-07-20T12:59:15 You have the ID of the user, I assume 2011-07-20T12:59:20 Or can get it easily 2011-07-20T12:59:25 there is no status field in the hold_request table which field(s) drive the status 2011-07-20T12:59:45 ernieSimuro: There are multiple fields that drive the status, depending on their current state. 2011-07-20T13:00:11 tsbere: That is correct 2011-07-20T13:00:24 ernieSimuro: current_copy, capture_time, fullfillment_time, shelf_time, frozen, maybe others 2011-07-20T13:01:13 is there somewhere I can look up which fields drive which state ? 2011-07-20T13:01:16 * Dyrcona notes that the program runs much more slowly in production on the sip server than it ran on his workstation in production or on his development server. 2011-07-20T13:01:58 * Dyrcona doesn't like random people sending him links in IM. 2011-07-20T13:02:05 bshum: Actually, I just noticed something. A question for you: Do your hold tests have stop_blocked_user set to true? 2011-07-20T13:02:14 tsbere: That's a good question 2011-07-20T13:02:33 bshum: If so, then CIRC blocks will also bring things to a halt. 2011-07-20T13:02:46 ours don't, IIRC. 2011-07-20T13:02:53 tsbere: Oooh, in the hold policy entry 2011-07-20T13:02:59 bshum: Yea 2011-07-20T13:03:03 We do have stop_blocked_user set to true on all our rules 2011-07-20T13:03:11 well, there you go. 2011-07-20T13:03:12 Then CIRC blocks will also stop holds 2011-07-20T13:03:13 Never knew what that meant, heh 2011-07-20T13:03:49 * Dyrcona doesn't see the point in letting people place holds if you won't check out to them, but I guess its an opportunity to pay fines..... 2011-07-20T13:07:27 Dyrcona annotated #123383 "even more interesting" at http://paste.lisp.org/display/123383#2 2011-07-20T13:07:42 tsbere++ Dyrcona++ that was our problem indeed 2011-07-20T13:07:44 Thanks muchly! 2011-07-20T13:07:55 yvw 2011-07-20T13:08:22 *** dbs has joined #evergreen 2011-07-20T13:08:23 *** dbs has joined #evergreen 2011-07-20T13:09:24 so something goes bang in the dark.... by not checking the datatype that it is handed. 2011-07-20T13:09:58 * dbs resolves to not natter about code formatting / commit comments for at least 24 hours 2011-07-20T13:15:10 *** collum has quit IRC 2011-07-20T13:20:28 weird: it seems to be crashing on a perm check. not what I expected. 2011-07-20T13:26:16 *** jenny1 has quit IRC 2011-07-20T13:34:43 agJohn: just returned from lunch. Did you get your questions answered? 2011-07-20T13:39:09 *** collum has joined #evergreen 2011-07-20T13:42:44 dbwells, no actually. But I did send it to the dev list--although I may have a lead on it, if you'd take a look at that, I'd be most grateful. 2011-07-20T13:45:02 Given a cursory glance at agJohn's post, I probably would have thrown the text holdings into 86[678] fields in serial.record_entry.marc records until such time as I was able to properly normalize all the data 2011-07-20T13:47:53 agJohn: Alright, I will take a look and reply via the list in a little while. 2011-07-20T13:50:04 dbs, so is that what I *should* have done--your note above seems a little vague. The heart of the matter is: where in the DB does the data come from that's displayed by the OPAC as the summary of holdings? (I can certainly generate textual holdings in a MARC format (only a minor major pain to generate) if that's what I need to do--just need to know where the data really needs to be to get... 2011-07-20T13:50:05 ...displayed in OPAC. 2011-07-20T13:51:06 agJohn: I suspect dbwells will say you *should* have done something else. I was just going with what I know works, in the absence of clear docs on what needs to go where. Sounds like dbwells is going to try and provide more of that. 2011-07-20T13:54:12 Knowing something that does work is a good starting point; thanks! 2011-07-20T13:59:08 *** jenny1 has joined #evergreen 2011-07-20T14:01:41 *** KN2W has joined #evergreen 2011-07-20T14:03:22 *** kmlussier has quit IRC 2011-07-20T14:04:26 *** KN2W has quit IRC 2011-07-20T14:04:45 *** kmlussier has joined #evergreen 2011-07-20T14:08:27 * mrpeters-isl thinks "Nominate for Trunk" probably needs to be "Nominate for Master" now, right? 2011-07-20T14:08:35 on launchpad, that is 2011-07-20T14:09:10 I don't have enough rights to touch some of that. <_< 2011-07-20T14:09:14 But yea, probably 2011-07-20T14:09:28 Only release team folks can do that I think. 2011-07-20T14:09:33 So that's dbs, eeevil, or Dyrcona 2011-07-20T14:09:43 Last I checked anyways :) 2011-07-20T14:09:44 trivial, but helps with being consistent 2011-07-20T14:12:55 mrpeters-isl: I kind of consider everything nominated for master, since it is the default unless you specify. 2011-07-20T14:14:26 fair point 2011-07-20T14:14:55 ooh. guess I can change the series name, but I won't unless I hear from dbs or eeevil..... 2011-07-20T14:15:49 * Dyrcona suddenly hears Ernest Bognine's voice in his head. "Eeeeevil!" 2011-07-20T14:16:26 Dyrcona and his fancy Head Bug Wrangler powers! 2011-07-20T15:02:16 *** sfortin has quit IRC 2011-07-20T15:03:33 hrmm, noticed the org unit settings for org.patron_opt_boundary/org.patron_opt_default have label/label instead of label/description for their oils_i18n_gettext entries 2011-07-20T15:08:59 * Dyrcona is also having fun with org_unit_settings, but with permissions instead. 2011-07-20T15:09:57 * Dyrcona discovered that if you set a view_perm on an org_unit_setting, you can't actually use that setting unless you have the view_perm: unified volume editor as an example. 2011-07-20T15:11:06 also, if you remove the view_perm from the setting, now the accounts with the update_perm can't see what the setting is, but they can still change it. 2011-07-20T15:11:29 however, removing the view_perm makes the setting work for those who lack the perm. 2011-07-20T15:11:55 * Dyrcona is thinking that there is a bug (or at least unintended behavior) in there somewhere. 2011-07-20T15:13:20 ok, I got the DCO for that title-case function; is there a sensible place for me to forward that (and the code) to? 2011-07-20T15:14:48 sylvar: launchpad bug? 2011-07-20T15:15:15 tag it with 'patch' 2011-07-20T15:15:18 Maybe a git branch? :p 2011-07-20T15:15:27 (then a launchpad bug to point at said branch) 2011-07-20T15:15:40 either way. :) 2011-07-20T15:15:50 DCO should probably go on the bug. 2011-07-20T15:15:57 Dyrcona: I say go ahead with the Nominate cahnge 2011-07-20T15:16:08 dbs: will do. 2011-07-20T15:17:08 * dbs can no longer spell 2011-07-20T15:17:25 dbs: done. 2011-07-20T15:17:47 and i can sympathize. i seem to make more typos in here than normal. 2011-07-20T15:19:56 * tsbere decided to make http://egdev.mvlcstaff.org/ if anyone is interested. 2011-07-20T15:21:34 for all: "trunk" on LaunchPad is now "master" 2011-07-20T15:28:15 Dyrcona++ 2011-07-20T15:29:47 *** mmorgan has joined #evergreen 2011-07-20T15:53:17 *** mrpeters-isl has quit IRC 2011-07-20T15:53:26 *** mrpeters-isl has joined #evergreen 2011-07-20T15:53:36 *** csharp has quit IRC 2011-07-20T15:53:49 *** csharp_GPLS is now known as csharp 2011-07-20T15:54:29 circulation type question--how does the list in opensrf.conf map to the database/server? When I run the client, I have no circulation modifiers set up at all. (And if I add modifiers in the client, I don't seem to be able to select it in the item editor.) 2011-07-20T15:54:53 I'm running 2.1 from source, patched w/ 37/38 (which may be part of the problem right now.) 2011-07-20T15:55:50 sal_: I'm pretty sure that the circ modifiers in opensrf.xml are ignored (since 1.4 anyway) 2011-07-20T15:56:19 they may be retained for .... backwards compatibility maybe? 2011-07-20T15:56:48 since no one runs pre 1.6 nowadays, they can probably be safely removed, methinks 2011-07-20T15:57:13 Well, that answers question one. Is there anything I should be doing in the client other than adding the circulation modifiers to make them show up in the item editor? 2011-07-20T15:57:37 sal_: Restart the client. 2011-07-20T15:57:46 Circ mods get loaded at login, I believe 2011-07-20T15:57:48 sal_: clear the cache, maybe? 2011-07-20T15:58:42 thanks, will try first restarting client, then if that doesn't work, clearing cache, and report back :-) 2011-07-20T15:58:57 *** Meliss has quit IRC 2011-07-20T16:04:20 tsbere: restarting client did it, thanks 2011-07-20T16:07:47 phasefx: did some additonal research about the asset.copy_location sorting in the Advanced Search interface. Results are not encouraging... 2011-07-20T16:08:16 It's not sorting by database id, so I think that complicates things significantly :( 2011-07-20T16:10:09 next question, where is SIP pulling CK value from? (I created a circ_mod value of 003 for my DVD, is coming back 006 in SIP 17, so that's definitely not it :-) 2011-07-20T16:10:25 Are there any plugins or problems with Firefox that would prevent a patron from getting a listing of their items checked out? 2011-07-20T16:10:41 The patron has been trying v 3.6.19 and 5.0 too 2011-07-20T16:10:49 SIP 18 (sigh) 2011-07-20T16:10:56 Both give him a blank white area where there should be items listed. 2011-07-20T16:11:19 We've asked them to perform a hard refresh and cache clear, so it doesn't seem like it's balking at strange cache problems. 2011-07-20T16:11:46 maybe its blocking Javascript? 2011-07-20T16:11:51 security setting somewhere? 2011-07-20T16:12:12 Well if it were doing that, one would expect it to be broken everywhere 2011-07-20T16:12:21 Rather than just a single piece of the my account area. 2011-07-20T16:12:23 specifcally, maybe it's blocking myopac.js 2011-07-20T16:12:29 Hmm 2011-07-20T16:12:37 what if he has fines? does he get the same render problem? 2011-07-20T16:12:49 or is it only on checked out items? 2011-07-20T16:13:20 * mrpeters-isl thinks he'll probably have issues seeing his bills, holds, etc. too 2011-07-20T16:13:55 They claim only troubles with checked out. 2011-07-20T16:14:05 But I'm attempting to investigate more. 2011-07-20T16:14:18 They're a savvy patron, they're giving me some fancy screenshots with firebug data in them. 2011-07-20T16:14:20 I'd give him a new bill for like $2000.00 and see if he notices :) 2011-07-20T16:14:41 if he blindly keeps thinking he has no bills, we'll know that page isn't rendering correctly. hehe 2011-07-20T16:14:56 Heh 2011-07-20T16:20:51 bshum: there was a problem with pre-catalogued items for a while, IIRC 2011-07-20T16:22:49 *** kmlussier has quit IRC 2011-07-20T16:26:51 dbs: That doesn't seem to be the problem unfortunately. I can view the items out listed in the OPAC. 2011-07-20T16:27:07 Under Chrome and Firefox (same versions he's trying) 2011-07-20T16:28:00 The firebug output that we got is showing that they're getting some sort of abort error 2011-07-20T16:28:12 mrpeters-isl: I bet the copy locations are coming out in database order. 2011-07-20T16:28:25 (which isn't id order) 2011-07-20T16:28:33 "undefined" :) 2011-07-20T16:33:55 *** ernieSimuro has quit IRC 2011-07-20T16:37:30 mrpeters-isl: I can confirm the locations are coming out in DB order. 2011-07-20T16:51:22 *** akilsdonk has quit IRC 2011-07-20T16:58:31 bshum: only thing I can suggest is to have the patron copy and paste you the results of "about:plugins" in the address bar 2011-07-20T16:58:50 dbs: That sounds like a plan. 2011-07-20T16:59:08 and Help -> Restart with Add-ons disabled 2011-07-20T16:59:22 * dbs out 2011-07-20T16:59:27 *** dbs has quit IRC 2011-07-20T17:00:40 *** mmorgan has left #evergreen 2011-07-20T17:03:28 *** sal_ has quit IRC 2011-07-20T17:28:14 *** Dyrcona has quit IRC 2011-07-20T17:33:54 *** LBA has quit IRC 2011-07-20T17:47:45 *** yboston has quit IRC 2011-07-20T17:55:07 *** LBA has joined #evergreen 2011-07-20T17:58:56 *** jenny1 has left #evergreen 2011-07-20T18:13:52 *** egbuilder has quit IRC 2011-07-20T18:13:57 *** egbuilder has joined #evergreen 2011-07-20T18:49:58 *** egbuilder_ has joined #evergreen 2011-07-20T18:54:35 *** egbuilder has quit IRC 2011-07-20T19:21:05 *** granitize has joined #evergreen 2011-07-20T19:22:37 *** granitize has left #evergreen 2011-07-20T21:04:05 *** tater-laptop has joined #evergreen 2011-07-20T21:08:09 *** LBA has quit IRC 2011-07-20T22:34:34 *** tater-laptop has quit IRC 2011-07-20T22:51:27 bshum: are you trying this with the patron's account, or your account? if some bad json is making its way in somewhere based on the current state of the patron's items out...