| # | Time | Nick | Message |
|---|
| # | 00:45:12 | jeffdavis has joined #evergreen |
| # | 02:45:48 | edoceo has quit IRC |
| # | 05:51:30 | moodaepo has quit IRC |
| # | 05:51:54 | moodaepo has joined #evergreen |
| # | 06:26:47 | wlayton has joined #evergreen |
| # | 06:56:28 | wlayton has quit IRC |
| # | 07:21:26 | Callender has quit IRC |
| # | 07:21:26 | phasefx has quit IRC |
| # | 07:24:01 | Callender has joined #evergreen |
| # | 07:24:01 | phasefx has joined #evergreen |
| # | 08:16:27 | Dyrcona has joined #evergreen |
| # | 08:28:29 | kmlussier has joined #evergreen |
| # | 08:44:17 | moodaepo has quit IRC |
| # | 08:47:30 | Callender has quit IRC |
| # | 08:48:24 | moodaepo has joined #evergreen |
| # | 09:05:57 | Callender has joined #evergreen |
| # | 09:16:32 | tlilleberg has joined #evergreen |
| # | 09:22:46 | natschil has joined #evergreen |
| # | 09:26:05 | jenny has joined #evergreen |
| # | 09:27:22 | yboston has joined #evergreen |
| # | 09:30:54 | dbwells_ has joined #evergreen |
| # | 09:33:42 | moodaepo has quit IRC |
| # | 09:34:12 | dbwells has quit IRC |
| # | 09:42:22 | moodaepo has joined #evergreen |
| # | 09:47:12 | Dyrcona | Does tpac honor the transcendant flag on bib sources? |
| # | 09:47:45 | Dyrcona | Yes, apparently it does. |
| # | 09:48:28 | Dyrcona | tsbere: had to restart memcached. |
| # | 09:58:10 | Meliss has joined #evergreen |
| # | 09:59:34 | eeevil | Dyrcona: that's all in the back, yeah |
| # | 10:35:10 | tsbere | eeevil: My make_release.sh script now attempts upgrade scripts. |
| # | 10:38:57 | bshum | tsbere++ |
| # | 10:40:56 | eeevil | tsbere: rad, sir! 2.1.1 and 2.2-a1 !! |
| # | 10:42:20 | tsbere | eeevil: I will push a 2.1.1 test branch to working for quick review, then do the same (after building one) for 2.2-a1. Will want someone to double-check the upgrade scripts and such to make sure I didn't screw anything up on the autogenning ;) |
| # | 10:42:56 | eeevil | I'll check it |
| # | 10:45:48 | tsbere gets really lazy with the upgrade scripts and doesn't attempt the "remove dupe functions" run |
| # | 10:46:07 | tsbere | That is a manual process. There may be reasons they show up multiple times. |
| # | 10:46:58 | tsbere | eeevil: http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/tsbere/test_2_1_1 is my "build rel_2_1_1" auto-committed result. Re-named. ;) |
| # | 10:56:11 | eeevil | I'll look soon! |
| # | 11:00:16 | tsbere | eeevil: http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/tsbere/test_2_2_alpha1 |
| # | 11:03:53 | eeevil | tsbere: not critical, but we can remove the first rewrite of asset.merge_record_assets (0639) since it's then later rewritten again (0648) |
| # | 11:04:36 | eeevil | tsbere: re 2.1.1 |
| # | 11:04:44 | tsbere | eeevil: See my "* tsbere gets really lazy with the upgrade scripts and doesn't attempt the "remove dupe functions" run" a few min ago ;) |
| # | 11:05:27 | tsbere | make_release even *tells* me what functions may be duped. And I was still too lazy to go de-dupe them ;) |
| # | 11:06:03 | eeevil | heh, that's fine ... we want to keep the upgrade_log entry, though, if you do go do that |
| # | 11:07:20 | tsbere | Well, yea. The 2.2-alpha1 upgrade script will be a PITA for removing dupes from. Lots of them ;) |
| # | 11:08:34 | eeevil | indeed ... also, since these are going out at the same time, we'd generally remove whatever is in 2.1.0-2.1.1 from 2.1-2.2a1 |
| # | 11:09:08 | tsbere | I told 2.2a1 to base itself on rel_2_1...so it only gets things that exist in master but not rel_2_1 |
| # | 11:09:33 | tsbere | (as far as previous versions go) |
| # | 11:09:53 | eeevil | gotcha |
| # | 11:10:25 | eeevil | well... that seems untrue? |
| # | 11:11:17 | tsbere | Actually...my "get the list of files", now that I look at my *notes* for it, isn't ensuring that files that differ between the two aren't grabbed. Hmm.... |
| # | 11:11:18 | eeevil | 0639 is in 2.1 (it's in your 2.1.1 test branch), and in 2.2a1 |
| # | 11:11:41 | tsbere | So the files that differ only in the :eg_version being missing are in both. Will need to re-work that logic quick. |
| # | 11:11:57 | eeevil | yaa for test runs! :) |
| # | 11:19:07 | natschil has quit IRC |
| # | 11:19:26 | natschil has joined #evergreen |
| # | 11:24:28 | eeevil | tsbere: also, one more upgrade script coming to cover a missed explode_array->unnest conversion |
| # | 11:24:31 | eeevil | soon |
| # | 11:24:37 | eeevil | thanks to berick |
| # | 11:24:52 | eeevil | thanks to berick for the fix, not the breakage ;) |
| # | 11:27:43 | tsbere replaced his logic with a "compare the sets of upgrade script *numbers* between the two branches, rather than what ones differ, and only grab the ones in the new branch that aren't in the old" block |
| # | 11:28:34 | eeevil | perfect, sir |
| # | 11:29:12 | tsbere | Still going to require a bit of manual tweaking for the dupes, but looks like a lot *less* show up now :D |
| # | 11:30:02 | tsbere | eeevil: Should I tag a rel_2_2 branch while I am at it? Or are we going to run rel_2_2 out of master for a bit to reduce our "commit everything going into master *twice*" headaches? |
| # | 11:32:16 | gmcharlt | well, is anybody expecting to do any big pushes in the next couple weeks that they expect to *not* be ready for 2.2? |
| # | 11:32:21 | Dyrcona | hmmm. tpac search seems weird to me on my dev server. |
| # | 11:32:44 | pmpcat has joined #evergreen |
| # | 11:33:27 | eeevil | tsbere: IMO, beta is the time for a branch, alpha is just tags |
| # | 11:33:37 | tsbere | gmcharlt: My assumption then is "said push isn't ready for master, and perhaps shouldn't be pushed at all". AKA, should live as a topic branch. |
| # | 11:33:48 | Dyrcona thinks it might be his data. |
| # | 11:34:08 | gmcharlt | tsbere: agreed; I'm bring the question up just so that we're explicit about it |
| # | 11:35:53 | matt_carlson has joined #evergreen |
| # | 11:40:17 | natschil has quit IRC |
| # | 11:40:37 | natschil has joined #evergreen |
| # | 11:43:12 | tsbere | Anything other than the explode_array->unnest change mentioned we want to get into 2.1.1 or 2.2-alpha1? I would be willing to argue LP bugs 880906 and 870029 myself. And for 2.2 all of my open LP bugs, I guess, but that is probably a tad much and not needed for alpha1. |
| # | 11:44:58 | eeevil looks |
| # | 11:46:33 | eeevil | hrm... seems we shouldn't allow you to peer to the primary bib at all |
| # | 11:46:43 | eeevil | that would fix it, no? |
| # | 11:47:17 | tsbere | That would be another way to fix it, yes. Or, you know, do *both* just for the sake of covering *all* of our bases. |
| # | 11:48:03 | eeevil | :) |
| # | 11:48:10 | tsbere hasn't checked what happens if you merge record A into record B and a copy on record B was peer bibbed to A |
| # | 11:48:29 | tsbere | I have barely checked peer bibbing at all, really |
| # | 11:48:46 | eeevil | actually, yeah, that's enough of a use case |
| # | 11:48:59 | eeevil | I'll push 880906 in |
| # | 11:53:39 | tsbere | Hmmm. If we have a quick fix for 891240 that might not be a bad thing to get done either. |
| # | 11:55:03 | natschil has quit IRC |
| # | 11:59:00 | dbs has joined #evergreen |
| # | 11:59:01 | dbs has joined #evergreen |
| # | 11:59:51 | dbs | hey berick - your unadorned URIs branch doesn't test for ind1 = 4, ind2 = [01] - deliberate? |
| # | 12:00:28 | Dyrcona | dbs: doesn't matter, it still doesn't work. |
| # | 12:00:41 | dbs | Dyrcona: orthogonal issue |
| # | 12:01:01 | Dyrcona | dbs: yes, but one thing at a time. :) |
| # | 12:01:46 | dbs | I guess I could shut up and forget about it |
| # | 12:01:47 | eeevil | tsbere: no immediate fix apparent for 891240 |
| # | 12:02:29 | tsbere | eeevil: Was just a thought. |
| # | 12:03:51 | Dyrcona | dbs: I'd like to see it working as it is on my dev system before tackling your issue. |
| # | 12:07:02 | tsbere | eeevil: Thoughts on 870029 ? (I largely disagree with the OUS options, for the record) |
| # | 12:09:52 | berick grabs 0651 |
| # | 12:10:12 | berick | dbs: not deliberate, just an oversight |
| # | 12:10:44 | eeevil | tsbere: I'm not itching to push that in ASAP ... if there's community consensus that the branch is Right(tm) then let's commit to getting it in for 2.2, though |
| # | 12:11:00 | eeevil | I'm much more itchy to get 2.1.1 and 2.2-a1 out :) |
| # | 12:11:28 | tsbere | eeevil: Heh. And a lot of other people are itching for 2.2-anything to be out ;) |
| # | 12:13:26 | eeevil | indeed |
| # | 12:15:28 | kmlussier has quit IRC |
| # | 12:15:49 | bshum | Hmm, the little left/right arrows for navigating between records from a MARC expert search breaks when you reach the end of a search results page (10 results) whilst in rdetails page level. |
| # | 12:16:07 | bshum | We get to the tenth record and the arrow disappears, along with the "End" link |
| # | 12:16:56 | eeevil | tsbere: stealing berick's thunder, the unnest fix is in, and in master only |
| # | 12:17:11 | eeevil | IMO, you're clear |
| # | 12:17:55 | matt_carlson has quit IRC |
| # | 12:18:01 | matt_carlson has joined #evergreen |
| # | 12:20:16 | phasefx | eeevil: dbs: this may be a question for one of you. I'm looking at authority/list.js with venkman, and I'm in function displayAuthorities where it tries to grab the auth.id with a dojo.query("datafield[tag='901'] subfield[code='c']", node), except, that returns an empty array, so the auth.id is stuck at 0. How can I figure out what record I'm dealing with to check to see if it's shaped poorly? |
| # | 12:20:54 | tsbere | eeevil: I will get right on that.....after I get back from getting my lunch. ;) |
| # | 12:21:45 | phasefx tries to wade through "node" |
| # | 12:22:50 | phasefx | would node.textContent be the whole record in marc? |
| # | 12:23:05 | dbs | phasefx: can you grab datafield[tag='100'] subfield[code='a'] and display that? |
| # | 12:23:18 | dbs | phasefx: oh, that might work |
| # | 12:23:40 | phasefx | "\n 00270nz 02200073o 4500\n 1158873\n 040806|| aznznbba| un and |u\n \n Osborne, Mary Pope.\n Magic tree house series.\n Merlin mission (Sound recording)\n \n \n Magic tree house series.\n Merlin mission (Sound recording)\n \n " |
| # | 12:23:59 | phasefx | man that looks weird to me :) |
| # | 12:24:55 | dbs | phasefx: yeah, you're missing the tags & subfields cause they're attributes, not text nodes |
| # | 12:25:15 | dbs | But "Osborne, Mary Pope." is the auth record in question, methinks |
| # | 12:25:26 | dbs | sounds like the auth records don't have 901 fields? |
| # | 12:26:41 | phasefx | hrmm.. 126 such records don't have the 901 tag |
| # | 12:26:41 | dbs | which was a problem that was uncovered during the last EG Conf - upgraders from 1.6 -> 2.0 didn't get 901 fields on their auth records, but of course clean loads into a 2.0 system did, so it was amazingly hard to debug until the upgrade part was recognized |
| # | 12:27:12 | phasefx | how do you re-ingest them or whatnot? |
| # | 12:27:58 | phasefx | ooh, one was created yesterday. This is EG 2.0.7 |
| # | 12:28:16 | eeevil | phasefx: turn on force-on-same-marc and do a trivial update. you need the maintain-901 setting on as well |
| # | 12:28:31 | eeevil | the latter is probably your problem, then |
| # | 12:28:31 | phasefx | muchos gracias |
| # | 12:29:01 | eeevil | those are both internal flags, of course (and may both be exposed through global flags) |
| # | 12:29:45 | phasefx | I see force_on_same_marc.. don't see one mentioning 901 |
| # | 12:29:54 | phasefx | there's cat.maintain_controL_numbers |
| # | 12:30:13 | kmlussier has joined #evergreen |
| # | 12:33:13 | dbs | is the b_maintain_901 trigger on biblio.record_entry disabled? |
| # | 12:33:26 | dbs | oh wait - auth :) |
| # | 12:33:47 | dbs | is the b_maintain_901 trigger on authority.record_entry disabled? |
| # | 12:33:59 | phasefx checks |
| # | 12:34:20 | phasefx | it's enabled |
| # | 12:34:44 | dbs | maintain_901() isn't optional, so maybe the specific record has some weirdness to it that throws off the underlying regex |
| # | 12:34:53 | dbs | we ran into that before too |
| # | 12:34:55 | matt_carlson has quit IRC |
| # | 12:36:01 | phasefx | hrmm, I'll try to force update this one and see what happens |
| # | 12:36:25 | dbs thinks CPAN when he hears "force update" |
| # | 12:36:59 | phasefx thinks dpkg |
| # | 12:37:07 | dbs | that too :) |
| # | 12:37:46 | phasefx | oh, that record wasn't yesterday, it was yesterday last year :D |
| # | 12:37:59 | phasefx | tricked by coincidence |
| # | 12:38:43 | dbs | hah |
| # | 12:38:47 | tsbere | You were only off by one, right? ;) |
| # | 12:38:52 | phasefx | 901 successfully created :D |
| # | 12:38:55 | dbs | y2010 problem |
| # | 12:38:56 | phasefx | tsbere++ |
| # | 12:40:07 | phasefx | max(create_date) = 2011-02-22.. so I think I can just update those recs and let it simmer. thanks guys |
| # | 12:46:31 | Dyrcona | phasefx: off by 1 error. :) |
| # | 12:52:02 | enhancin has joined #evergreen |
| # | 12:54:25 | enhancin | I'm having some issues while testing some patron migration, I'm not very fluent in postgresql, but I'm hoping I can morph this insert statement to only insert unique ones. I have "INSERT INTO actor.card (usr, barcode) SELECT actor.usr.id, students.barcode FROM students INNER JOIN actor.usr ON students.username = actor.usr.usrname;" Would I be able to easily put this as update or will the script be more complicated? |
| # | 12:54:28 | matt_carlson has joined #evergreen |
| # | 12:56:49 | enhancin | I was thinking UPDATE actor.card SET usr = actor.usr.id, barcode = students.barcode FROM students INNER JOIN actor.usr ON students.username = actor.usr.usrname WHERE 1 NOT IN ( SELECT 1 FROM actor.usr WHERE actor.card.usr = actor.usr.id) |
| # | 12:57:07 | enhancin | but I'm not sure if this is correct syntax and don't want to mess it up |
| # | 12:57:37 | tsbere | enhancin: Add a "DISTINCT ON (students.barcode)" to the select, maybe? |
| # | 12:58:15 | tsbere isn't 100% sure what is being attempted |
| # | 12:58:21 | enhancin | ( SELECT 1 FROM actor.usr WHERE actor.card.usr = actor.usr.id DISTINC ON students.barcode ) ? I'm not sure what you mean I've never used distinct on...maybe I should research that -.- |
| # | 12:59:48 | enhancin | Oh, i'm migrating the patron database from a different system, sorry |
| # | 12:59:53 | enhancin | i've imported a few users and now |
| # | 13:00:03 | enhancin | I'm testing what happens when I need to 'update' user information |
| # | 13:00:46 | enhancin_ has joined #evergreen |
| # | 13:00:50 | enhancin_ | (got kicked off somehow) |
| # | 13:04:53 | enhancin has quit IRC |
| # | 13:08:25 | enhancin_ | Got it. If anyone is wondering: |
| # | 13:08:28 | enhancin_ | INSERT INTO actor.card (usr, barcode) SELECT actor.usr.id, students.barcode FROM students INNER JOIN actor.usr ON students.username = actor.usr.usrname WHERE 1 NOT IN ( SELECT 1 FROM actor.card WHERE actor.card.usr = actor.usr.id); UPDATE actor.card SET usr = actor.usr.id, barcode = students.barcode FROM students INNER JOIN actor.usr ON students.username = actor.usr.usrname WHERE actor.card.usr = actor.usr.id; |
| # | 13:08:46 | enhancin_ | inserts new records that aren't there and then updates records that already exist |
| # | 13:09:01 | eeevil | tsbere: if you haven't started re-cutting, I want to push one thing back from master into 2.1 |
| # | 13:10:17 | tsbere | eeevil: 2.1 is easy to re-cut. 2.2-alpha1 is a PITA for the upgrade script and dupes. |
| # | 13:10:33 | eeevil | it's jsut 2.1 |
| # | 13:10:39 | eeevil | so, I'll do it :) |
| # | 13:10:52 | dbs kind of worries that the flurry of commits to prep for a release runs a bit counter to the "should be able to cut a release at any point in time" ethos |
| # | 13:10:55 | tsbere wonders if we should just leave the dupes in 2.2-alpha1. It is an alpha, who cares about dupes in the upgrade script ;) |
| # | 13:11:28 | tsbere | dbs: There is "we are able to" and "we are *willing* to", I think ;) |
| # | 13:11:51 | eeevil | wait ... nevermind! already backported |
| # | 13:12:07 | eeevil | dbs: agreed, fwiw |
| # | 13:12:15 | dbs | tsbere: and granted, our pace before yesterday was pretty slow - but I suspect that's because we were manually testing each commit before merging |
| # | 13:12:32 | jamesrf has quit IRC |
| # | 13:12:42 | tsbere | eeevil: Any thoughts on the 2.2-alpha1 upgrade script? Should I continue de-duping the functions where I am comfortable, or just say "whatever" and go for it? |
| # | 13:12:55 | dbs hopes to spend some quality time with dbwells' LDAP branch soon |
| # | 13:14:21 | jamesrf has joined #evergreen |
| # | 13:14:24 | enhancin_ has quit IRC |
| # | 13:15:00 | eeevil | tsbere: function deduping is less important that table changes, obv, so if it's just functions then I say forget it |
| # | 13:20:47 | tsbere reverts his manual changes, fixes the second line, and tells the thing to get back to building stuff. |
| # | 13:22:21 | edoceo has joined #evergreen |
| # | 13:22:23 | tsbere | FYI, I'm lazy and want to tell my system to upload everything at once, so I am building both first ;) |
| # | 13:22:30 | Dyrcona | hmm. Template Toolkit doesn't cache compiled templates, does it? |
| # | 13:23:56 | StephenGWills has joined #evergreen |
| # | 13:26:13 | dbs | Dyrcona: it can do caching, if it has been enabled. we had it disabled by default |
| # | 13:26:38 | dbs hopes that he's remembering correctly through a sleep-deprived haze |
| # | 13:30:07 | berick | i believe caching is on |
| # | 13:30:48 | Dyrcona | berick: I wonder if that is why I see no change in tpac after installing your 856 branch. |
| # | 13:31:23 | berick | i doubt it. i've never had that kind problem w/ caching |
| # | 13:38:29 | tsbere | Huh. Apparently you can confuse the update email stuff by creating multiple branches with one push. |
| # | 13:39:00 | dbs | I didn't think we were going to create branches for tags any more? |
| # | 13:39:41 | tsbere | We tack stuff onto these things that we can't, to my knowledge, drop onto tags. |
| # | 13:39:43 | dbs | branches-as-tags, what are we, svn? :) |
| # | 13:41:07 | eeevil | dbs: not sure our release process is amenable to how we fiddle with versions in files ... if the git tag is enough for the (later) build tool to do the version dance, then I think we should do that |
| # | 13:42:39 | gmcharlt | eeevil: in principle the tag should provide enough information for future-build-tool |
| # | 13:42:42 | tater-laptop has joined #evergreen |
| # | 13:42:45 | matt_carlson has quit IRC |
| # | 13:43:02 | gmcharlt | unless there's something other than the version number that's ultimately needed |
| # | 13:43:41 | tsbere dumps all the downloads into place |
| # | 13:44:05 | tater-home has joined #evergreen |
| # | 13:45:46 | eeevil | gmcharlt: that's about it ... 1) update the changelog in the repo 2) archive the tag and do the dance in the clean tree 3) i18n 4) dojo 5) tar it up |
| # | 13:46:07 | eeevil | er, 1.5) tag it |
| # | 13:46:10 | tsbere | I never paid a lot of attention to this part of the process. Once things are uploaded, who do I contact and how? :P |
| # | 13:46:29 | eeevil | tsbere: you have sudo on the web server? |
| # | 13:46:35 | tater-laptop has quit IRC |
| # | 13:46:42 | eeevil | oh, you mean after you've dumped them in downloads/ |
| # | 13:46:44 | tsbere | eeevil: Yes. Files are literally in place. |
| # | 13:47:34 | eeevil | -dev, subject: RELEASE TEAM, body: what you did, request for web/wiki/etc updates |
| # | 13:47:35 | dbs | tsbere: moodaepo and bshum have been the heavy hitters on the EG web |
| # | 13:47:47 | eeevil | (that's what I do, anyway) |
| # | 13:48:03 | dbs | eeevil: oh yeah, the release team! |
| # | 13:48:08 | eeevil | :) |
| # | 13:48:24 | eeevil | csharp: how 'bout that release team ML? ;) |
| # | 13:48:26 | eeevil ducks |
| # | 13:48:38 | bshum | Hmm? |
| # | 13:48:55 | bshum | Oh |
| # | 13:49:16 | eeevil | tsbere: should we request a test of someone that isn't us? |
| # | 13:49:20 | eeevil | before updating the web site |
| # | 13:49:33 | tsbere has "Testing and Wiki/Web updates would be appreciated." in his email body |
| # | 13:49:36 | eeevil | "upgrade script WORKSFORME" or some such |
| # | 13:49:40 | eeevil | righto |
| # | 13:55:01 | bshum | Quirk with downloads page actually. There's probably not enough room on the page horizontally speaking to add the fourth branch for 2.2-alpha1. Time to say goodbye to 1.6? It probably ought to be fine on larger screens, but might get weird with 1024x768 or smaller. |
| # | 13:55:08 | tater-home has quit IRC |
| # | 13:58:26 | matt_carlson has joined #evergreen |
| # | 13:59:27 | tsbere | bshum: I would be happy with a "Here is a link to git. Learn how to check out and run master" page replacing the whole thing. ;) More seriously, I think we can stop advertising 1.6 downloads. |
| # | 13:59:32 | berick | Dyrcona: about to dissapear into a meeting.. i'll look at your sample record when i return |
| # | 13:59:37 | gmcharlt | bshum: I'd be fine with removing 1.6.x from the downloads page, but since it would be good to discourage people from trying to use alphas in production |
| # | 13:59:57 | gmcharlt | putting the alpha download in a separate area below the main download table would be my suggestion |
| # | 14:00:46 | jamesrf | +1 |
| # | 14:01:12 | bshum | Sounds good. I'll work with the others and poke at that page to see about that. |
| # | 14:01:17 | bshum | gmcharlt++ |
| # | 14:01:27 | tsbere | gmcharlt: What about those of us running production off of steadily marching forward master checkouts? ;) |
| # | 14:01:57 | gmcharlt | tsbere: you crazy people aren't exactly the target audience for the downloads page ;) |
| # | 14:02:40 | natschil has joined #evergreen |
| # | 14:02:40 | matt_carlson has quit IRC |
| # | 14:02:52 | gmcharlt | thought seriously, I *am* glad that it means that there's a strong impetus to keep master stable all the time |
| # | 14:03:22 | jeff | topic_branches++ |
| # | 14:03:28 | jeff | stable_master++ |
| # | 14:04:28 | Dyrcona | @later tell berick that sample is just a copy and paste from the OPAC, not a very good sample really. |
| # | 14:04:28 | pinesol_green | Dyrcona: The operation succeeded. |
| # | 14:09:25 | Dyrcona | I don't really get why any projects bother with numbered releases any more. |
| # | 14:16:27 | enhancin has joined #evergreen |
| # | 14:17:00 | enhancin | I'm now having an issue with just one user logging in, when I put in their password it encrypts it wrong...I'm not sure what it's even ecrypting to get that....when I update the database with a password it encrypts it correctly. |
| # | 14:18:09 | enhancin | I ran the password through http://www.md5decrypter.co.uk/hash-a-password.aspx and checked the logs and the password it encrypted does not match -anything- on there |
| # | 14:18:29 | Dyrcona | enhancin: when you say "logging in" how are you logging in? |
| # | 14:18:37 | enhancin | through the staff client, sorry |
| # | 14:18:46 | enhancin | the other users seem to work fine |
| # | 14:18:47 | Dyrcona | enhancin: the password isn't a simple md5 hash. |
| # | 14:18:57 | enhancin | in the db it seems to be |
| # | 14:19:35 | Dyrcona | when you login in with the staff client, a seed is first retrieved. |
| # | 14:19:57 | Dyrcona | that seed is hashed as md5, then concatenated to the raw password. |
| # | 14:20:09 | Dyrcona | the result is then hashed again as md5. |
| # | 14:20:45 | Dyrcona | the backend (not the database) stores the initial seed for the session and then does the same steps. |
| # | 14:21:01 | enhancin | is there anything that would cause a password mismatch to always occur for just that user? |
| # | 14:21:49 | Dyrcona | you got locked out for too many bad password attempts? *looks in tsbere's direction, though he's not at his desk to answer* |
| # | 14:22:39 | enhancin | hmm |
| # | 14:22:49 | Dyrcona | I think something like that was part of that anti-brute force patch, but the lockout is relatively short. |
| # | 14:23:17 | Dyrcona could be off base. It wouldn't be the first time. |
| # | 14:23:57 | Dyrcona | wait. I think I described that incorrectly..... |
| # | 14:24:24 | enhancin | the brute force patch, does it modify the db to change that or just some other setting somewhere |
| # | 14:24:52 | Dyrcona | its a setting stored in memcached. doesn't change the password in the database. |
| # | 14:25:07 | Dyrcona | btw, i was wrong about the combining of the hashes..... |
| # | 14:25:27 | Dyrcona | the password is hashed and combined with the raw seed, the result is then hashed again. |
| # | 14:27:54 | tsbere | General idea: Both ends have a hash of the password(the backend only has the hash in the DB, the frontend has the password and hashes it), and the seed. The seed and password hash are combined and sent back. If both ends agree, login success. If they disagree, the backend increments a counter. |
| # | 14:28:13 | tsbere | If the counter reaches too high the backend claims failure even on success |
| # | 14:28:36 | tsbere | After a period of time (90 seconds by default) sans password attempts the counter resets to 0 |
| # | 14:29:14 | Dyrcona | "too high" is configurable, isn't it? |
| # | 14:29:28 | tsbere | And "how long" |
| # | 14:29:40 | enhancin | it's still failing and I just went out for a cigarette before I got back on here, at least 10 minutes between my last attempt and this one |
| # | 14:30:03 | tsbere | Bad username? caps lock? |
| # | 14:30:08 | tsbere | Wrong server? |
| # | 14:30:12 | Dyrcona | bad password, even. |
| # | 14:30:17 | tsbere | Didn't restart apache after restarting backend services? |
| # | 14:30:34 | enhancin | i did an autogen.sh and apache restart before i went out |
| # | 14:30:37 | tsbere | memcached not running? |
| # | 14:30:42 | enhancin | memcached is running |
| # | 14:30:50 | enhancin | all other users work |
| # | 14:31:02 | enhancin | [INFO:29864:oils_event.c:46:1321470001161465] Creating new event: PERM_FAILURE |
| # | 14:31:08 | tsbere | No staff_login permission? |
| # | 14:31:23 | enhancin | it should...let me look in the db and compare |
| # | 14:31:29 | tsbere | Because PERM_FAILURE isn't "Your password failed" it is "you don't have permission to do that" |
| # | 14:31:40 | tsbere | Which could also mean no work OU defined |
| # | 14:31:59 | bshum | Speaking of work_ou |
| # | 14:32:27 | bshum | I just noticed yesterday that folks can use any staff account with STAFF_LOGIN to get in, regardless of workstation registered. |
| # | 14:32:46 | bshum | I tried lowering the staff_login perm to system level instead of consortium, but then nobody was able to log in. |
| # | 14:33:11 | bshum | I didn't think it used to do that |
| # | 14:33:11 | tsbere | bshum: I think STAFF_LOGIN is checked *before* workstation is looked at. |
| # | 14:33:36 | bshum | Like you needed the right workstation + right login with the right work_ou assigned. |
| # | 14:34:33 | tsbere | Looks like oils_auth.c uses a hardcoded -1, which I think ends up meaning "everywhere" |
| # | 14:34:41 | enhancin | i am logging in from a different workstation |
| # | 14:37:02 | enhancin | apparently the user permissions are 400? (in the database, i looked atht permision level, 17, and that is 400) |
| # | 14:38:40 | Dyrcona | enhancin: permission numbers are relatively meaningless. they CAN and often DO vary by Evergreen installation. |
| # | 14:38:53 | Dyrcona | the permission code is what you want to look at. |
| # | 14:39:19 | Dyrcona | STAFF_LOGIN is the code I think you want. |
| # | 14:39:48 | enhancin | 400 is ADMIN_ASSET_COPY_TEMPLATE |
| # | 14:40:27 | enhancin | this whole thing is confusing i bet i'm just lost |
| # | 14:40:28 | Dyrcona | when you say "the user permissions are 400" what table and column are you getting that from? |
| # | 14:41:27 | enhancin | In actor.usr I see the user and the usrgroup is 17? and in the permissions schema there is a user permissions map and 17 corresponds to 400.. |
| # | 14:41:53 | enhancin | permission.usr_perm_map |
| # | 14:42:11 | Dyrcona | what is the actor.usr.profile? actor.usr.usrgroup doesn't mean what you think it means. |
| # | 14:42:14 | enhancin | oh okay |
| # | 14:42:31 | enhancin | 2, which is STAFF_LOGIN |
| # | 14:42:54 | Dyrcona | nope. look up id 2 in permission.grp_tree. |
| # | 14:43:29 | enhancin | ohhh Patrons |
| # | 14:43:48 | enhancin | it needs to be "3"? Library Staff? |
| # | 14:44:08 | Dyrcona | that's one way, but you should make it 4 or 5 for cataloger or circulator. |
| # | 14:44:22 | enhancin | alright |
| # | 14:45:54 | Dyrcona | you can also add an entry in permission.usr_grp_map to add individual users to other groups. It's how I get my staff permissions. |
| # | 14:49:39 | tsbere | Anyone have thoughts on providing the packaged linux staff clients in the future? Would not be hard to build at release time. |
| # | 14:49:44 | tsbere | (for 2.1+ anyway) |
| # | 14:50:16 | Dyrcona | I think I'm neutral on that one, since I always build my own. |
| # | 14:51:13 | enhancin | in my experience it's better to build it on the machine it's running on, but you could have a script that does all of that for you |
| # | 14:51:31 | enhancin | that goes for any program really. |
| # | 14:52:05 | enhancin | some people like to have individual make properties, especially gentoo users |
| # | 14:53:08 | Dyrcona | We don't really support gentoo, do we? ;) |
| # | 14:53:45 | enhancin | no, gentoo users support gentoo....what I'm saying is you could offer packaged linux staff clients but you should also offer the source. |
| # | 14:54:12 | Dyrcona | enhancin: the source is always there for anyone who wants to build it. |
| # | 14:54:56 | enhancin | good, i think the optional package would be handy for some less-techy people |
| # | 14:55:03 | Dyrcona | when I build my packaged linux clients for my laptop, I also build the windows client, though I never use it, 'cause its easier than not building it. |
| # | 14:55:17 | Dyrcona | plus, some people do use it. |
| # | 14:55:27 | Dyrcona | for my development server anyway. |
| # | 14:55:35 | enhancin | ubuntu has become really popular with people who don't really...know how to do that stuff |
| # | 14:55:50 | Dyrcona | and some who do. :) |
| # | 14:55:56 | enhancin | that's where I see it being a good thing |
| # | 14:56:02 | Dyrcona | but I hear Minty is taking over in that space. |
| # | 14:56:39 | enhancin | I do like Ubuntu, I've converted a couple of my friends over to it because they were running Vista on 1-2GB |
| # | 14:56:41 | jeff | Minty Minotaur -- that's the upcoming Ubuntu release, right? |
| # | 14:56:49 | enhancin | but for myself I couldn't use it |
| # | 14:57:03 | Dyrcona actually likes Unity, though I do wish it had just a tad more options. I'd rather application icons be on the right of the screen. |
| # | 14:57:52 | Dyrcona | jeff: heh. typo on my part: http://linuxmint.com/ |
| # | 14:58:56 | Dyrcona | debian => ubuntu => mint. |
| # | 14:59:45 | Dyrcona | if ubuntu is a zulu word meaing 'couldn't install debian,' then mint is hipster slang for 'couldn't install ubuntu'? |
| # | 15:00:18 | enhancin | I haven't really used Linux for anything personal..I'm too much of a gamer to leave Windows for that....although I do use it on my development. I used to have an 8 node cluster of 3.0 Quad cores with 4GB DDR3 memory running on Ubuntu Cloud and that thing was a BEAST. I could compile Linux so fast. I also do a lot of testing with optimization on a gentoo virtual machine |
| # | 15:00:28 | edoceo | How did http://open-ils.org/documentation/evergreen-schema-1.6.0.1.html get made? |
| # | 15:00:34 | moodaepo | tsbere++ # Packaged linux clients |
| # | 15:01:08 | Dyrcona uses *NIX-like OSes on all of his personal computers. |
| # | 15:01:24 | enhancin | Ubuntu is a 4 click install....that's sad. |
| # | 15:01:34 | Dyrcona | tsbere: sorry to derail your poll. :p |
| # | 15:02:20 | tsbere | Wait, I had a poll? |
| # | 15:02:21 | tsbere | :P |
| # | 15:02:49 | matt_carlson has joined #evergreen |
| # | 15:05:15 | tsbere adds linux bundling to his make_release script, just for kicks |
| # | 15:05:25 | jeff | Dyrcona: yeah, sorry... i was punning. i should have ducked to make it more obvious. |
| # | 15:05:54 | Dyrcona | jeff: I thought so. what was ubuntu's M name anyway? |
| # | 15:06:24 | Dyrcona | Minty Minx would have been cute. :) |
| # | 15:06:25 | edoceo | Maverick Meerkat |
| # | 15:06:38 | Dyrcona | oh that's right... maverick. didn't use it. |
| # | 15:06:48 | edoceo | too rouge for me |
| # | 15:06:52 | edoceo | ;/ |
| # | 15:07:04 | Dyrcona | too rouge or too rogue? :) |
| # | 15:07:21 | edoceo | neither, it's both! |
| # | 15:10:35 | enhancin | my favorite is Lucid Lynx so far |
| # | 15:10:41 | enhancin | Although I do love Natty Narwhal... |
| # | 15:11:04 | Dyrcona | Natty was good. Oneiric is getting better now that they've worked some of the bugs. |
| # | 15:11:25 | Dyrcona | My favorite is FreeBSD, or OpenBSD, but the latter is slower and more conservative. :) |
| # | 15:11:42 | bshum | I miss Natty. |
| # | 15:12:28 | enhancin | I was mostly just talking about the name =P not sure which ubuntu is my favorite..I think we're using Lucid on this build |
| # | 15:13:05 | enhancin | nope i'm running Natty |
| # | 15:13:23 | bshum | The .10's tend to be strange and unwieldy. Or so I've been told. |
| # | 15:14:05 | bshum | In hindsight, I should have tried Oneiric more before upgrading my laptop. But oh well. |
| # | 15:14:20 | Dyrcona | http://pastebin.com/C8vrmt5n |
| # | 15:14:39 | bshum | Yuck |
| # | 15:14:44 | bshum | That does look nasty |
| # | 15:14:56 | Dyrcona | Is it upgrade or downgrade Perl XML-RPC to fix that? |
| # | 15:15:09 | bshum | I want to say upgrade |
| # | 15:15:23 | Dyrcona | CPAN says I have the latest.... |
| # | 15:15:31 | bshum | But I thought we already did that in the base makefile |
| # | 15:15:42 | Dyrcona | yep...i'll check the makefile. |
| # | 15:16:04 | Dyrcona | btw, bshum, you posted almost the identical paste in May. :) |
| # | 15:16:13 | bshum | Oh geez |
| # | 15:16:29 | bshum | I knew that felt familiar. |
| # | 15:16:54 | Dyrcona | it works on our production server, so maybe i'll just grab its XML-RPC lib. |
| # | 15:17:18 | Dyrcona | heh. maybe its my client.... :) |
| # | 15:17:32 | Dyrcona | didn't try from this workstation in production, just from the laptop. |
| # | 15:17:46 | Dyrcona | no wait... client is Python. never mind. |
| # | 15:19:37 | matt_carlson has quit IRC |
| # | 15:19:57 | matt_carlson has joined #evergreen |
| # | 15:21:21 | Dyrcona | same version of XML::RPC on both servers, 0.9.... |
| # | 15:21:35 | Dyrcona | time to check logs. |
| # | 15:21:49 | Dyrcona hates checking logs. |
| # | 15:23:32 | Dyrcona | http://pastebin.com/x699yvse |
| # | 15:23:45 | Dyrcona | tsbere probably has the answer, and all I have to do i shout to get it. :) |
| # | 15:23:48 | tlilleberg has quit IRC |
| # | 15:24:08 | tsbere has no clue |
| # | 15:26:28 | Dyrcona | does work in production. |
| # | 15:29:02 | Dyrcona | wow. irc logs in august and may both have references to that very error. |
| # | 15:29:06 | enhancin has quit IRC |
| # | 15:29:30 | bshum | Heh |
| # | 15:29:46 | bshum | I know ours came up because we were testing some third party vendor's tie-in |
| # | 15:30:00 | bshum | Come to think of it, I think we had a second one start using xml-rpc too |
| # | 15:30:03 | Dyrcona | yep ours, too. |
| # | 15:30:23 | Dyrcona | except, my dev machine claims to have the same version of XML::RPC as production. |
| # | 15:30:31 | Dyrcona | maybe I'll force it to install. |
| # | 15:38:07 | Dyrcona bangs his head on his desk.... |
| # | 15:38:24 | Dyrcona | RPC::XML not XML::RPC..... doh! |
| # | 15:38:29 | bshum | Oops, hehe |
| # | 15:38:35 | Dyrcona | two different packages. |
| # | 15:39:44 | Dyrcona | for the sake of the logs, I think I'll post the steps I took to fix it, that is if this fixes it. |
| # | 15:39:59 | tsbere | bshum: You do any testing of 2.1.1/2.2-alpha1 before forwarding that on? ;) |
| # | 15:40:33 | bshum | tsbere: Not entirely, but it's been practice in the past to have release team communications carried over the General Mailing list vs. solely dev side only. |
| # | 15:40:44 | tsbere | ok |
| # | 15:41:13 | tsbere only recently got this directly involved in releases ;) |
| # | 15:42:03 | Dyrcona | nope still borken. |
| # | 15:42:57 | matt_carlson has quit IRC |
| # | 15:43:04 | matt_carlson has joined #evergreen |
| # | 15:44:36 | Dyrcona | hmm..... |
| # | 15:45:27 | Dyrcona | whee! fixed. |
| # | 15:45:37 | Dyrcona | more work than I needed, though. |
| # | 15:46:48 | fortin has joined #evergreen |
| # | 15:47:14 | Dyrcona | for the logs; |
| # | 15:48:15 | Dyrcona | to fix this Un-convertable reference: HASH, cannot use at /usr/share/perl5/RPC/XML.pm line 164 in /var/log/apache2/error.log on Ubuntu Lucid Lynx. |
| # | 15:48:23 | Dyrcona | do the following steps. |
| # | 15:48:47 | akilsdonk has joined #evergreen |
| # | 15:48:59 | Dyrcona | sudo aptitude purge librpc-xml-perl |
| # | 15:49:11 | Dyrcona | perl -MCPAN -e shell |
| # | 15:49:31 | Dyrcona | note: there should be a sudo before that ... |
| # | 15:49:46 | Dyrcona | force install XML::RPC |
| # | 15:50:00 | Dyrcona | install RPC::XML::Function |
| # | 15:50:12 | Dyrcona | then quit CPAN. |
| # | 15:53:39 | Dyrcona | didn't even have to restart apache. :) |
| # | 15:53:46 | bshum | Dyrcona++ |
| # | 15:54:37 | Dyrcona | bshum: we get to do it all again with Precise Pangolin next April. :) |
| # | 15:54:51 | matt_carlson has quit IRC |
| # | 15:55:01 | bshum | Don't remind me :( |
| # | 15:55:11 | bshum | Though I think I'll actually try to enjoy that. |
| # | 15:56:34 | yboston has quit IRC |
| # | 16:00:33 | Meliss has quit IRC |
| # | 16:13:31 | kmlussier has quit IRC |
| # | 16:18:20 | tsbere | Anyone other than myself (and Dyrcona) think it would be worth writing up a new auditor setup that can (with hopefully minimal changes) mark the user and workstation IDs down with the changed rows? |
| # | 16:22:41 | gmcharlt | as long as it recognizes that not all row changes will have an operator and/or workstation associated with them |
| # | 16:23:11 | gmcharlt | and doesn't add much overhead |
| # | 16:23:22 | gmcharlt | but given that, yes, I can certainly see that being useful |
| # | 16:24:32 | eeevil | sounds something like the action tracker thingy idea berick/senator/me have been kicking around |
| # | 16:24:58 | dbs | action trigger tracker |
| # | 16:26:12 | eeevil | heh |
| # | 16:26:24 | eeevil | "last time someone did something" tracker |
| # | 16:26:42 | berick | aka, the trapper keeper |
| # | 16:26:45 | berick | why? i don't know |
| # | 16:27:03 | eeevil | berick: I LOVE IT |
| # | 16:27:05 | Dyrcona | the trigger trapper keeper |
| # | 16:27:25 | jeff | berick: he's on third. |
| # | 16:27:35 | tsbere | gmcharlt: I was planning on leaving things nullable. null = we had no info. |
| # | 16:28:05 | Dyrcona | beats having to grep through logs looking for events and authtokens. :) |
| # | 16:28:10 | tsbere | The *hard* part is determining where db access actually happens (I don't have a list) and whether or not I have access to user/workstation info |
| # | 16:28:19 | berick | jeff: who is? |
| # | 16:28:36 | jeff | berick: no, who's on first. |
| # | 16:28:58 | eeevil | born of the "last auth time" (definition unknown) request |
| # | 16:29:03 | berick | ah, that clears it right up |
| # | 16:30:38 | tsbere | For the record, the level of overhead would be "each time we go to talk to the DB on a new session and have a user/workstation, make one extra call before we start" combined with "the auditor functions make an extra call or two to get the information stored before we began". Maybe always call the before we start call so it can clear any previous session info? |
| # | 16:30:59 | _bott_ has quit IRC |
| # | 16:32:12 | _bott_ has joined #evergreen |
| # | 16:32:45 | tsbere | Does anyone *have* such a list of places I might need to edit handy? Doubtful, I know, but I might as well ask ;) |
| # | 16:33:06 | eeevil | tsbere: seems like an out-of-band async-called opensrf service that acts as a data sync, and wraps itself around methods that are correctly decorated (like authoritative does) would be least invasive |
| # | 16:34:10 | Dyrcona gets all swoony when eeevil uses that techy talk. :p |
| # | 16:34:19 | eeevil | so, you can foo, which was registered with the audit_me=>1 register_method flag (and how to find the auth token in the param set was defined, or assumed to be param 0) |
| # | 16:34:29 | tsbere | eeevil: Set and retrieve functions based on the information here: http://www.postgresql.org/docs/9.1/static/plperl-global.html - Call the set function before you begin your session, call the retrieve from the auditor functions. |
| # | 16:34:53 | eeevil | (s/you can foo/you call foo/) then, that thing runs before foo is called |
| # | 16:35:13 | eeevil | it knows the method name and the auth token, and from that can look up the user and ws_id |
| # | 16:35:48 | eeevil | tsbere: mmmmm ... I don't think that's the right level |
| # | 16:36:09 | eeevil | or, it's tracking something I don't see as worthwhile |
| # | 16:36:11 | eeevil | ;) |
| # | 16:36:30 | tsbere | I want to add the workstation and user ids to the audit tables. In general. :P |
| # | 16:36:48 | dbs has quit IRC |
| # | 16:37:07 | eeevil | ok, gotcha |
| # | 16:37:46 | eeevil | you just don't want to have to correlate the auditor with logs to point the blame arrow |
| # | 16:37:47 | tsbere | My method requires calling something like "evergreen.set_audit_info(user, workstation)" before you start (with nulls if you don't have either). The auditors can then call evergreen.get_audit_info or similar. |
| # | 16:38:35 | tsbere | If I can dump the set call into the pipeline where only the things actually accessing the DB need to know about it then the rest of the system can remain blissfully ignorant of the change. |
| # | 16:39:24 | eeevil | pcrud-driven changes would be easy ... cstore-driven, not so much |
| # | 16:39:24 | tsbere | Also, good luck finding the log entry some days. :P |
| # | 16:40:21 | eeevil | the activity log is almost always enough for blame, IME |
| # | 16:40:55 | tsbere | Someone wants to know what happened 15 months ago. You only keep 12 months of disk logs... |
| # | 16:41:34 | eeevil | meh |
| # | 16:41:39 | eeevil | ;) |
| # | 16:41:43 | tsbere | (all in all for us going back that far is useless either way beyond figuring out what *library* was responsible, but meh) |
| # | 16:43:47 | tsbere | eeevil: How many things use cstore directly, instead of say through CStoreEditor? |
| # | 16:43:51 | Dyrcona | Having people complain about something on a daily basis is a good motivator for gixing it. |
| # | 16:44:20 | Dyrcona | heh |
| # | 16:44:44 | Dyrcona | CStoreEditor works just fine without an authtoken, just so you know. |
| # | 16:44:47 | eeevil | tsbere: unless you're using a transaction, you can't depend on cstoreeditor, either. also, have to clean up on commit or error or rollback |
| # | 16:45:27 | eeevil | explicitly using a transaction, I mean |
| # | 16:46:03 | tsbere | eeevil: the indb perl method is per db connection. Call the set whenever dealing with a new opensrf-level client? |
| # | 16:46:39 | tsbere doesn't think you often get multiple authtokens per set of calls to the DB |
| # | 16:50:20 | eeevil | I'd definitely want to be able to turn something like this off |
| # | 16:53:08 | eeevil | the set part, I mean |
| # | 16:53:30 | eeevil | and then the get part would be an alternate auditor implementation, I'd assume |
| # | 16:53:35 | eeevil | not a replacement |
| # | 16:54:11 | tsbere | The get part would be "dump values into two variables we then add to two nullable columns" |
| # | 16:54:43 | eeevil | (bonus points for a function that en/disables the two different implementations) |
| # | 16:55:20 | eeevil | calling a plperlu function when you've chosen to never turn on the set part could very well be a big performance issue |
| # | 16:56:12 | eeevil | imagine an update to 100k copies directly in the db |
| # | 16:56:16 | tsbere sees BadDebt.pm, TemplateBatchBibUpdate.pm, AppUtils.pm, Ingest.pm, and a pile of support-scripts doing direct cstore write calls, he thinks |
| # | 16:57:18 | eeevil | Ingest needs to just be deleted ... but, what do those have to do with this? |
| # | 16:57:33 | tsbere | Looking for where I would need to worry about cstore without cstoreeditor |
| # | 16:57:34 | tsbere | :P |
| # | 16:57:37 | eeevil | there are plenty of things that change rows without user intervention |
| # | 16:58:15 | tsbere | and in those cases you would get nulls in the columns |
| # | 16:58:50 | eeevil | I still think an "action" log would be more useful for troubleshooting. record the api_name, time, user and wsid |
| # | 16:59:34 | tsbere | Which would need a lot more than the api_name, time, user, and wsid to even be possibly useful. Like what they were passing into the api. |
| # | 16:59:59 | eeevil | tsbere: sure -- that's a json blob called params :) |
| # | 17:00:35 | eeevil | but, neither here nor there ... testing will show if the get trigger change will be a perf issue |
| # | 17:03:04 | eeevil | tsbere: srsly, if there's little to no perf impact, I won't stand in the way! |
| # | 17:03:27 | eeevil | just need to argue for the devil |
| # | 17:03:32 | tsbere | eeevil: Need to do a test to find out how calling the get would impact things. Which means writing a get. Which I am halfway to. |
| # | 17:05:07 | eeevil | that should be fairly simple ... a generic one would be trivial for sure, but you probably don't want to call it twice if its avoidable |
| # | 17:05:44 | matt_carlson has joined #evergreen |
| # | 17:13:23 | tsbere | eeevil: SELECT evergreen.get_audit_user(), evergreen.get_audit_ws(), evergreen.set_audit_info(x, x+1) FROM generate_series(1,10000)x; takes 331 ms via pgadmin for me. And is setting/getting for every row. |
| # | 17:15:33 | eeevil | tsbere: that's not bad |
| # | 17:15:35 | eeevil | :) |
| # | 17:16:11 | eeevil | don't want an evergreen.{set/get}_global_var('foo'[,'bar']) ? |
| # | 17:17:20 | tsbere | Well, that could be done too. But I figure *one* call to set the user and workstation would be easier on at least that front ;) |
| # | 17:19:38 | eeevil | tsbere: what about when we want to set something else? :) |
| # | 17:19:47 | eeevil swings 180 |
| # | 17:19:52 | eeevil | ok ... out for now |
| # | 17:19:54 | eeevil | tsbere++ |
| # | 17:22:04 | wlayton has joined #evergreen |
| # | 17:24:45 | tsbere notes that speed-wise things are comparable with generics compared to specifics on getting. Setting is faster doing two at once. |
| # | 17:31:03 | pmpcat has quit IRC |
| # | 17:31:52 | Dyrcona has quit IRC |
| # | 17:39:48 | StephenGWills has left #evergreen |
| # | 17:54:01 | jeffdavis | is it just me, or is action_circulation_aging_tgr incredibly slow? |
| # | 17:54:44 | jenny has left #evergreen |
| # | 17:54:54 | jeffdavis | I find it takes about 6000 ms to age a circ via the trigger on a test server, vs 6 ms if I drop the trigger and manually copy the circ into action.aged_circulation/delete without trigger |
| # | 18:02:56 | enhancin has joined #evergreen |
| # | 18:03:28 | enhancin | Testing patron imports, anyone know where the students table gets created when it's just plain CREATE TABLE students? it doesn't appear to use a schema |
| # | 18:04:54 | enhancin | ah in the 'public' schema just got to that one in the list of clicking through |
| # | 18:05:22 | phasefx | it's certainly not a stock table; never heard of it before |
| # | 18:08:50 | Dyrcona has joined #evergreen |
| # | 18:13:20 | matt_carlson has quit IRC |
| # | 18:14:07 | matt_carlson has joined #evergreen |
| # | 18:20:02 | tsbere | phasefx: He is doing funky migration stuff and thus creating tables for joins ;) |
| # | 18:21:11 | enhancin | yes...we're building it for schools, each semester the list of students will change so we need to account for that... |
| # | 18:21:37 | jeffdavis | in my experience it's a good idea to confine your custom migration tables to their own schema |
| # | 18:21:56 | jeffdavis | ymmv |
| # | 18:24:32 | matt_carlson has quit IRC |
| # | 18:33:58 | Dyrcona | enhancin: how do you get your list of students? |
| # | 18:34:18 | enhancin | CSV file |
| # | 18:34:29 | enhancin | yeah i might have to have it put it in the actor schema |
| # | 18:34:35 | enhancin | it's complaining so much |
| # | 18:35:02 | Dyrcona | enhancin: i'd write something in perl that reads the csv file and not load it into the database. |
| # | 18:35:19 | Dyrcona | just a suggestion. |
| # | 18:35:26 | enhancin | in the documentation it's pretty straightforward...I got my first import working |
| # | 18:35:35 | Dyrcona | ok |
| # | 18:35:43 | enhancin | it's just having issues when I'm updating information and adding more now... |
| # | 18:38:00 | akilsdonk has quit IRC |
| # | 18:40:19 | fortin has quit IRC |
| # | 19:00:58 | jeffdavis | ah, slowness of aging circs was fixed back in july |
| # | 19:01:29 | jeffdavis | I'm all about stumbling across old, already-fixed bugs these days |
| # | 19:05:35 | bshum | I think tspindler wrote something for loading/updating student records using SQL. We derived some content off of that and did something similar at the start of this school year for our first school system. |
| # | 19:05:56 | bshum | Having it as a core component would be kind of neat. |
| # | 19:07:41 | enhancin | man...this is getting more complicated. I tried to make a table in the actor schema but now I get 'relation "actor.students" does not exist' on "SELECT actor.usr.id, actor.students.barcode FROM actor.students INNER JOIN actor.usr ON username = actor.usr.usrname" |
| # | 19:08:55 | enhancin | wow nevermind one sec |
| # | 19:09:48 | enhancin | I wasn't using the right db on the command line -.- i've been working too long today |
| # | 19:13:12 | enhancin | awesome...things are working now. When I type up the documentation for this I might submit it for any other schools who want some help with it |
| # | 19:21:41 | jeffdavis | I've also written some code for importing student records from CSV, which I shared on open-ils-dev a while back. |
| # | 19:22:54 | jeffdavis | Core functionality for this would be cool, but in my experience the import process can be quite complicated... |
| # | 19:23:09 | bshum | And unique too. |
| # | 19:23:33 | jeffdavis | Yeah. We've got two libraries doing student imports and the processes have diverged substantially already. |
| # | 19:23:37 | bshum | Trying to adopt a uniform pattern depends greatly on whether you can convince every school to agree on a standard of using fields in the patron record. Which they never do. |
| # | 19:23:44 | Dyrcona | bshum & tsbere : think I know what our problem with lost checkins is, but I'll know for sure in a few minutes. |
| # | 19:24:03 | bshum | Dyrcona: If you fix it, you will be a god among us. |
| # | 19:24:06 | bshum | More than usual ;) |
| # | 19:24:36 | tsbere is looking into his auditor stuff, and discovered that it is transaction-immune |
| # | 19:24:55 | tsbere | That is, the stored user and workstation stick around even after a rollback |
| # | 19:24:59 | jeffdavis awaits Dyrcona's apocolocyntosis |
| # | 19:26:06 | bshum just read Dyrcona's note |
| # | 19:26:16 | bshum | That conforms to some of the cases we encounter. |
| # | 19:26:42 | bshum | But it's most often related to backdated checkins or situations where no fines were accrued due to a policy of 0 cents per day to max of 0. |
| # | 19:27:02 | bshum | Still, happy thoughts for you as you poke about |
| # | 19:28:04 | Dyrcona | I think it is because the circulators don't have permissions to view another library's aous for the void lost billing. |
| # | 19:28:47 | Dyrcona | although, that doesn't really explain why it fails for me. |
| # | 19:28:54 | tsbere has fought with the "you need to be able to see that setting to do anything with it when it should be backend stuff" issue before |
| # | 19:29:02 | bshum | Actually that sounds like what mrpeters-isl faced |
| # | 19:29:12 | bshum | He encountered that problem when looking at that bug |
| # | 19:29:52 | bshum | But it turns out that Indiana doesn't void across lib lines, so they were okay with that aspect of the problem. |
| # | 19:30:20 | bshum | Or something like that. |
| # | 19:31:29 | bshum | But that does make sense. |
| # | 19:31:54 | Dyrcona | so it looks like just setting some permissions will fix it. |
| # | 19:32:17 | tsbere | I wouldn't be surprised if there is something else going on, though. |
| # | 19:32:37 | Dyrcona | neither would I. since I should have the permission everywhere. |
| # | 19:32:38 | tsbere | Because if it were permissions it wouldn't be reproducable when logged in with everything everywhere |
| # | 19:33:01 | Dyrcona | unless it is doing a broken check that didn't get fixed. |
| # | 19:33:09 | tsbere | Bad variable reference, maybe? Or only loading local ous and then referring to a remote one? |
| # | 19:33:23 | Dyrcona | i'm looking |
| # | 19:35:20 | Dyrcona | well, no, that shouldn't be it. |
| # | 19:36:02 | Dyrcona | it shouldn't be checking the perms, since it is passing in an editor and not setting the auth flag on ou_ancestor_setting. |
| # | 19:36:13 | Dyrcona | that's in AppUtils. |
| # | 19:37:30 | enhancin | anyone good with postgresql? I'm trying to get all the addresses that aren't used (for some reason I have a ton of them). I can get it to select the right ones, but once I change = to != it just select everything...sometimes like 10 times |
| # | 19:38:04 | bshum | enhancin: What's the query look like? |
| # | 19:38:12 | bshum | Perhaps paste us a bit |
| # | 19:38:43 | enhancin | SELECT id FROM actor.usr_address WHERE actor.usr.mailing_address = actor.usr_address.id; |
| # | 19:38:48 | enhancin | but I can't reference the usr table |
| # | 19:39:09 | bshum | Perhaps try something like: |
| # | 19:39:30 | enhancin | I can get to the other table like this: |
| # | 19:39:31 | enhancin | SELECT actor.usr_address.id FROM actor.usr_address, actor.usr WHERE actor.usr.mailing_address = actor.usr_address.id; |
| # | 19:40:27 | Dyrcona | heh, finances is spelled wrong in the ou editor: "Finanaces" |
| # | 19:40:34 | bshum | enhancin: http://pastie.org/2875313 |
| # | 19:40:41 | bshum | That's a very simple join between two tables. |
| # | 19:41:00 | bshum | The AS part aliases the table name to make things shorter for referencing |
| # | 19:41:20 | bshum | Then you can select any specific field of the combined table elements |
| # | 19:41:37 | bshum | Like au.id to get the usr ID, or aua.street1 for the street1 entry for a given user |
| # | 19:42:15 | bshum | Since the term "id" is used more than once (once on each table) you'd have to qualify exactly which id you were looking for. |
| # | 19:43:53 | bshum | enhancin: for fun reading - http://www.postgresql.org/docs/current/static/tutorial-join.html |
| # | 19:44:04 | bshum already learned something new reviewing the doc, heh |
| # | 19:44:10 | enhancin | but when I get to reverse that, I can't just change = to != |
| # | 19:44:26 | enhancin | in the end I need to select the ones that aren't there |
| # | 19:44:27 | tsbere | Hmmm. In theory, all updates are done during a transaction, right? |
| # | 19:44:31 | bshum | Well, then it would give you all the mailing addresses that weren't specifically assigned to a user. |
| # | 19:44:43 | bshum | Perhaps you have more entries than you think you do. |
| # | 19:44:45 | eeevil | enhancin: left join |
| # | 19:45:14 | eeevil | enhancin: or not exists |
| # | 19:45:47 | bshum | Edited the paste, perhaps like that: http://pastie.org/2875313 |
| # | 19:45:50 | enhancin | I have 39 entries in the actor.usr_address table and when I run that same query with != instead of = I get 342 rows |
| # | 19:46:35 | eeevil | bshum: nearly ... sec |
| # | 19:47:08 | bshum | That doesn't sound right. Perhaps you have a total of 381 (39 + 342) in the table. Which is what I would have expected from the potential switch of just = to != in the original query. |
| # | 19:47:23 | eeevil | http://pastie.org/2875326 |
| # | 19:47:37 | bshum | Oooh, interesting. |
| # | 19:47:40 | bshum | eeevil++ |
| # | 19:48:02 | eeevil | but, that's not quite what you need either, because there's another address field. sec |
| # | 19:48:02 | tsbere | bshum: != would become a cross product of everything *not* equal. So actor.usr count - 1 * actor.usr_address count - 1? |
| # | 19:48:37 | bshum | tsbere: Oy, and this is why I changed majors in college. |
| # | 19:48:48 | bshum goes to weep in the corner |
| # | 19:48:48 | enhancin | eeevil++ I could probably figure it out now |
| # | 19:49:05 | enhancin | sorry bshum...you were close! and thanks for trying! |
| # | 19:49:57 | enhancin | select * from actor.usr AS au RIGHT OUTER JOIN actor.usr_address AS aua ON aua.id = au.mailing_address OR aua.id = au.billing_address WHERE au.mailing_address IS NULL OR au.billing_address IS NULL; |
| # | 19:50:05 | eeevil | http://pastie.org/2875326 |
| # | 19:50:24 | tsbere | eeevil++ |
| # | 19:50:24 | enhancin | showing off unions now, eh? |
| # | 19:50:27 | enhancin | first it was right outer joins |
| # | 19:50:31 | tsbere | For the simple to read solution |
| # | 19:50:38 | eeevil | enhancin: ;) ... wait unit I whip out the EXCEPT |
| # | 19:50:46 | enhancin | oh dear |
| # | 19:50:58 | eeevil | anyway, that should get you unused addrs |
| # | 19:51:13 | enhancin | Thanks! I think postgresql needs an UPSERT |
| # | 19:52:03 | eeevil | with predicate locking in now, that's possible ... some day |
| # | 19:52:07 | eeevil | UPSERT, I mean |
| # | 19:52:24 | eeevil | but it would be spelled MERGE, and follow the sql standard :) |
| # | 19:53:04 | tsbere | eeevil: Can you think of anywhere that an insert, update, or delete would happen without a transaction in progress? |
| # | 19:57:42 | eeevil | tsbere: if it goes through cstore (and friends) it's not allowed |
| # | 19:58:23 | eeevil | and the only other app that can write is storage, and that's pretty mature, so ... nope, I don't think so |
| # | 19:59:20 | enhancin | that other one isn't working , I think I get the good select from the last query I posted but that one is giving me 0 rows for some reason |
| # | 19:59:55 | tsbere | eeevil: For fun, we can use this overall storage method to pull data *out* of a rolled back transaction. Which seems crazy as far as ideas go for me, I can't think of many reasons to use this method compared to, say, doing your query to get the data and then issuing the rollback...........maybe funky needs for an upgrade script? |
| # | 20:02:18 | eeevil | tsbere: you lost me, sorry... |
| # | 20:03:08 | tsbere | eeevil: Long story short, global perl storage ignores rollbacks. Or rather, transactions in general. |
| # | 20:03:36 | eeevil | tsbere: ok, right. it's just a perl var inside the running interpreter |
| # | 20:08:37 | eeevil | tsbere: if you want to get really crazy, look into custom variable classes and set_config() with is_local true |
| # | 20:09:32 | eeevil | would be basically free, just needs cooperation with pg in the config file |
| # | 20:09:55 | enhancin | right outer joins don't just by chance work on delete's do they? |
| # | 20:10:08 | eeevil | enhancin: they do |
| # | 20:10:21 | enhancin | orly so I can just change SELECT * to DELETE on that statement of yours? |
| # | 20:10:29 | enhancin | the first one |
| # | 20:10:38 | enhancin | i modified it to select the rows I wanted because the union one wasn't working |
| # | 20:11:42 | enhancin | eeevil: it's saying sntax error near RIGHT =/ |
| # | 20:11:45 | eeevil | ahh... you may need to grab just the non-NULL values for the columns on actor.usr |
| # | 20:12:10 | eeevil | enhancin: you can't just change SELECT * to DELETE |
| # | 20:12:19 | enhancin | yeah, i figured i couldn't |
| # | 20:12:21 | eeevil | it works a little differently |
| # | 20:12:28 | eeevil | sec |
| # | 20:12:55 | enhancin | select au.billing_address from actor.usr AS au RIGHT OUTER JOIN actor.usr_address AS aua ON aua.id = au.mailing_address OR aua.id = au.billing_address WHERE au.mailing_address IS NULL OR au.billing_address IS NULL; |
| # | 20:12:55 | eeevil | http://pastie.org/2875326 |
| # | 20:13:32 | enhancin | that might just have worked |
| # | 20:13:40 | tsbere | eeevil: Wrong url? Looks like the previous pastie |
| # | 20:13:47 | enhancin | eeevil++ |
| # | 20:13:52 | eeevil | tsbere: shift-refresh? |
| # | 20:13:55 | eeevil | just edited |
| # | 20:13:58 | eeevil | pastie-- |
| # | 20:14:05 | enhancin | caching-- |
| # | 20:14:07 | tsbere | eeevil: Ah, I didn't click. Just said "that number looks familiar" |
| # | 20:14:13 | eeevil | :) |
| # | 20:14:15 | enhancin | memory-- |
| # | 20:14:15 | Dyrcona | tsbere: found it! |
| # | 20:14:28 | Dyrcona | it's a stupid ou setting that we haven't set. |
| # | 20:15:29 | eeevil steps away |
| # | 20:16:06 | wlayton has quit IRC |
| # | 20:16:15 | Dyrcona | tsbere: lost items usable on checkin |
| # | 20:16:22 | Dyrcona | set to true solves it for us. |
| # | 20:16:26 | Dyrcona | doh! |
| # | 20:16:48 | tsbere | Yea, but is it not working with that off due to a bug? :P |
| # | 20:17:07 | Dyrcona | what bug? |
| # | 20:17:42 | Dyrcona | well, in the handle_lost method it sets the status to reshelving. |
| # | 20:17:49 | Dyrcona | probably more to it than just that. |
| # | 20:17:58 | enhancin | I hope documentation I write can help people, this was pretty frustrating but i've learned quite a bit |
| # | 20:18:31 | Dyrcona | i'll keep poking. |
| # | 20:19:25 | Dyrcona | might be a bug. |
| # | 20:19:28 | enhancin | anyways. thanks. later guys |
| # | 20:19:46 | Dyrcona | if you look at Circulate.pm line 3304, that's where the value is checked. |
| # | 20:20:08 | enhancin has quit IRC |
| # | 20:20:17 | Dyrcona | if its not set, and we're not at the owning lib, we don't change the status. we also don't do anything with the billings. |
| # | 20:20:41 | Dyrcona | i'm going to unset it and try something again. |
| # | 20:21:29 | Dyrcona | it looks like it might void the billing when it gets home, but I don't seem to recall that happening in my testing earlier this week. |
| # | 20:22:37 | Dyrcona | also explains why it "doesn't come off the record when they check it in." |
| # | 20:26:49 | Dyrcona | weird: my example wouldn't checkin at the home library until i voided the billings first. |
| # | 20:27:03 | bshum | That is weird. |
| # | 20:30:00 | Dyrcona | that time, it worked...... but I manually made the copy lost. |
| # | 20:31:20 | Dyrcona | ah.... this is tricky, but I think I know what is happening. |
| # | 20:31:28 | Dyrcona | need to play some more. |
| # | 20:33:52 | Dyrcona | not so sure now. i wonder if it has something to do with the library that set it to lost. |
| # | 20:41:02 | Dyrcona | damn. now its working on my dev machine no matter what I do. |
| # | 20:41:15 | bshum | Heh |
| # | 20:41:24 | bshum | Spooooooky |
| # | 20:41:26 | Dyrcona | i'm gonna clear memcached. |
| # | 20:43:31 | Dyrcona | this is frustrating. |
| # | 20:46:41 | Dyrcona | if i check them in from the patron's record, it seems to work now now matter what. |
| # | 20:46:51 | Dyrcona | even if I'm not at the owning library. |
| # | 20:47:15 | Dyrcona | if I check them in on the normal checkin interface, it won't remove the bills. |
| # | 20:47:33 | bshum | Well... that's unsettling |
| # | 20:47:35 | tsbere | New question is thus "what are they doing differently?" |
| # | 20:47:35 | Dyrcona | bills don't come off at the home library 'cause the copy is in transit. |
| # | 20:48:04 | tsbere | So the copy being in transit kills the bills coming off? |
| # | 20:48:13 | Dyrcona | tsbere: right. |
| # | 20:48:18 | tsbere | Logic needs some re-ordering, perhaps |
| # | 20:48:20 | Dyrcona | when it gets home, it looks like. |
| # | 20:48:32 | Dyrcona | i'll double check. |
| # | 20:49:10 | Dyrcona | yep. item is in transit. |
| # | 20:49:43 | Dyrcona | since the item itself isn't lost when it gets home, circ doesn't try to void any billings. |
| # | 20:49:51 | Dyrcona | so that's a part of it. |
| # | 20:51:18 | Dyrcona | another part is that the code that voids the billings also sets the copy status to reshelving. |
| # | 20:51:34 | Dyrcona | i think that is an error, since the copy status is set later anyway. |
| # | 20:52:10 | Dyrcona | that maybe why (if there is a why) the void code is skipped if lost usable on checkin is off and we're not home. |
| # | 20:53:33 | matt_carlson has joined #evergreen |
| # | 20:53:47 | eeevil | Dyrcona: I'd suggest conferring with berick tomorrow ... he's the nominal master of run_method() ;) |
| # | 21:00:16 | matt_carlson has quit IRC |
| # | 21:00:52 | matt_carlson has joined #evergreen |
| # | 21:26:22 | tecoripa has joined #evergreen |
| # | 21:26:33 | tecoripa | hello, anyone here? |
| # | 21:26:59 | bshum | Maybe |
| # | 21:27:03 | bshum | Sorta |
| # | 21:27:06 | bshum | Not really ;) |
| # | 21:27:18 | Dyrcona | no. no one here. go away. :) |
| # | 21:27:41 | Dyrcona | just us bug wranglers, wrangler an odd bug. |
| # | 21:29:10 | Dyrcona | tecoripa: if you have a question, just ask. |
| # | 21:29:25 | tecoripa | sorry, turned away for a second... |
| # | 21:29:34 | Dyrcona | np |
| # | 21:29:43 | tecoripa | circling around *almost* have my view, controller, and datbase allhooked up |
| # | 21:30:08 | tecoripa | so: I have a new column in the table actor.stat_cat: "required", boolean |
| # | 21:30:37 | Dyrcona | actor.stat_cat didn't have that already? |
| # | 21:30:52 | tecoripa | and I modified stat_cat_editor.xhtml and stat_cat_editor.js to display, edit the value of this field in the Statistical Category Editor |
| # | 21:30:58 | bshum | It does not. |
| # | 21:31:20 | Dyrcona | asset.stat_cat does...... that's why I assumed actor.stat_cat did. |
| # | 21:31:40 | tecoripa | and I updated fm_IDL.xml to include this new field in the model, and I stopped/restarted evergreen |
| # | 21:31:44 | tecoripa | so far, so good |
| # | 21:32:29 | Dyrcona anticipates the "but...." |
| # | 21:32:39 | tecoripa | now: when I try to update the value of the filed in the editor, I get this error in open-ils.storage_stderr.log: |
| # | 21:33:12 | tecoripa | ** required() isn't there. Please create me somewhere (like in actor::statcat)! |
| # | 21:33:24 | tecoripa | actor::stat_cat, really |
| # | 21:33:35 | tsbere | You didn't update CDBI stuff, did ya? |
| # | 21:33:36 | tecoripa | so I'm still missing a piece somewhere |
| # | 21:33:41 | tecoripa | no, I didn't |
| # | 21:33:53 | tecoripa | I took a look at that config file, and it was pretty terse |
| # | 21:33:55 | Dyrcona | autogen.sh, too, needs to be run. |
| # | 21:34:13 | tecoripa | not anything in config.pm that clearly indicated it needed to be updated |
| # | 21:34:31 | tecoripa | I did run autogen.sh (forgot to mention that) |
| # | 21:34:46 | Dyrcona | yeah, that's often the case, but you'll find things don't work unless you do. |
| # | 21:35:12 | tecoripa | sorry, referring to...? |
| # | 21:35:18 | tecoripa | I should do ...? |
| # | 21:35:19 | Dyrcona | find the entry for actor::stat_cat in config.pm and required as an "essential" field. |
| # | 21:35:26 | Dyrcona | ^add |
| # | 21:35:28 | tecoripa | ah, ok |
| # | 21:35:41 | tecoripa | I missed that in the config.pm file |
| # | 21:35:54 | tecoripa | let me look, make sure I was editing the correct file |
| # | 21:37:15 | tecoripa | this isn't site_perl/OpenILS/Application/Storage/CDBI/config.pm, is it? |
| # | 21:37:18 | Dyrcona | no. there isn't an entry for actor::stat_cat in there and there wouldn't be. |
| # | 21:37:31 | Dyrcona | that's for the config schema.... |
| # | 21:37:36 | tecoripa | ah, ok. I'm looking at the wrong file, then. |
| # | 21:37:49 | Dyrcona | i told you too in email. :( |
| # | 21:37:54 | Dyrcona | to.... |
| # | 21:37:58 | tecoripa | let me read that again |
| # | 21:37:59 | Dyrcona | must be getting tired. |
| # | 21:38:12 | Dyrcona | i told you to edit the wrong file. |
| # | 21:38:17 | Dyrcona | my mistake. |
| # | 21:38:29 | Dyrcona | i had just updated config::bib_source in some other work. |
| # | 21:38:39 | tecoripa | no sweat. I'm glad you're around to set me straight. :) |
| # | 21:39:07 | Dyrcona | so you restarted everything....ran autogen.sh....and still get the error. |
| # | 21:39:36 | tecoripa | right. but I have not edited *config.pm* file yet. |
| # | 21:39:43 | tecoripa | which apparently I still need to do. |
| # | 21:39:56 | tecoripa | ? |
| # | 21:39:58 | tsbere | actor.pm |
| # | 21:40:05 | Dyrcona | yeah. |
| # | 21:40:09 | tsbere | CDBI/actor.pm should have the actor::stat_cat stuff |
| # | 21:40:32 | Dyrcona | Open-ILS/src/perlmods/lib/OpenILS/Application/Storage/CDBI/actor.pm |
| # | 21:40:36 | tecoripa | just a sec, let me look... |
| # | 21:40:48 | Dyrcona | wasted time typing it all out. |
| # | 21:41:06 | tecoripa | found it. beautiful. |
| # | 21:41:17 | Dyrcona | see. i told you the wrong file. :) |
| # | 21:41:22 | tecoripa | let me edit that file, try it again... |
| # | 21:41:27 | tecoripa | back in a few minutes |
| # | 21:42:13 | bshum | tsbere++ #just finished testing 2.1.1 installs from scratch on clean Squeeze/Lucid VMs |
| # | 21:42:16 | bshum | Looks good to me so far. |
| # | 21:42:21 | tecoripa | do I need to rerun autogen.sh after editing that file? |
| # | 21:42:28 | tecoripa | or just restart evergreen? |
| # | 21:42:38 | Dyrcona | restart evergreen and apache. |
| # | 21:42:45 | Dyrcona | don't think you need to run autogen. |
| # | 21:42:55 | tecoripa | ok, got it |
| # | 21:43:11 | Dyrcona | you only need to run autogen is you change the fieldmapper idl or your org unit hierarchy. |
| # | 21:43:31 | Dyrcona | ^is^if |
| # | 21:43:37 | Dyrcona | definitely getting tired. |
| # | 21:43:52 | tecoripa | ok, thanks |
| # | 21:44:43 | Dyrcona | may be a stupid question, but you are doing a make install? |
| # | 21:45:00 | tecoripa | no, not anymore |
| # | 21:45:15 | Dyrcona | so where did you edit the file? |
| # | 21:45:23 | Dyrcona | @quote search armenian |
| # | 21:45:23 | pinesol_green | Dyrcona: 1 found: #5: "<senator> the armenian regression sounds like a..." |
| # | 21:45:33 | Dyrcona | @quote get 5 |
| # | 21:45:33 | pinesol_green | Dyrcona: Quote #5: "<senator> the armenian regression sounds like a spy novel" (added by bshum at 03:44 PM, February 22, 2011) |
| # | 21:45:34 | tecoripa | I'm editing the pm file in the site_perl lib directly right now (after making suitable backups) |
| # | 21:46:35 | Dyrcona | ok. i don't usually do that, though sometimes I just cp the file from the git working area to the site_perl directory after making changes if its only 1 file that doesn't need make to run. |
| # | 21:47:19 | Dyrcona | @quote add <bshum> The staff client looks pretty in Armenian |
| # | 21:47:19 | pinesol_green | Dyrcona: Error: You must be registered to use this command. If you are already registered, you must either identify (using the identify command) or add a hostmask matching your current hostmask (using the "hostmask add" command). |
| # | 21:47:20 | tsbere frequently edits files in place, even perl files, when editing debug lines.....but pretty much never for the CDBI/* files |
| # | 21:47:28 | tecoripa | yeah, same here. since it's just one file, and I'm on a test machine, I just copied the file, edited it, and copied it back into place. |
| # | 21:47:55 | Dyrcona grumbles at pinesol |
| # | 21:48:01 | bshum | Teehee |
| # | 21:48:11 | tecoripa | why not edit the CDBI files in place? |
| # | 21:49:28 | tsbere | I just don't usually. |
| # | 21:49:37 | tecoripa | ok, fair enough. |
| # | 21:49:42 | Dyrcona | i don't usually edit anything in place. |
| # | 21:49:43 | tsbere | Rarely rapid-testing changes to them |
| # | 21:50:08 | Dyrcona | @quote add <bshum> The staff client looks pretty in Armenian |
| # | 21:50:08 | pinesol_green | Dyrcona: The operation succeeded. Quote #20 added. |
| # | 21:50:43 | Dyrcona | i should change my staff client to French. |
| # | 21:51:13 | Dyrcona | it would be fun telling folks to click on the "annuller" button. |
| # | 21:51:18 | tecoripa | success!! |
| # | 21:51:27 | tecoripa | thank you, Drycona! |
| # | 21:51:44 | Dyrcona | yw. and tsbere++ |
| # | 21:51:59 | tecoripa | I'm documenting all this, as a case study of how to make a change, starting with zero knowledge. |
| # | 21:52:06 | Dyrcona | good idea. |
| # | 21:52:11 | tecoripa | and thank you, too, tsbere! |
| # | 21:52:13 | Dyrcona | @quote get 19 |
| # | 21:52:13 | pinesol_green | Dyrcona: Quote #19: "_bott_: I wish I'd get what I wanted instead of what I asked for" (added by Dyrcona at 11:02 AM, November 15, 2011) |
| # | 21:52:24 | Dyrcona | oops. wrong quote. :) |
| # | 21:52:34 | Dyrcona | which is apropos..... |
| # | 21:53:02 | Dyrcona | I think this quote sums up the problem with lost billings not clearing. |
| # | 21:53:08 | Dyrcona | @quote get 18 |
| # | 21:53:08 | pinesol_green | Dyrcona: Quote #18: "Alan McKay: Like the ski resort of girls looking for husbands and husbands looking for girls, the situation is not as symmetrical as it might seem." (added by Dyrcona at 11:51 AM, November 10, 2011) |
| # | 21:53:22 | bshum | Dyrcona++ |
| # | 21:53:25 | bshum | Indeed |
| # | 21:54:08 | Dyrcona | all right enough fun with pinesol_green.....i have a bug to update. |
| # | 21:54:30 | Dyrcona yawns. |
| # | 21:54:34 | Dyrcona | then, to bed. |
| # | 21:54:47 | tecoripa | goodnight, sleep well |
| # | 22:11:55 | jeff | death to void. |
| # | 22:12:08 | jeff | forgiveness all the way. |
| # | 22:16:49 | Dyrcona | all fines to /dev/null! :) |
| # | 22:16:59 | bshum | +1 |
| # | 22:17:34 | jeff | no, we want to see history... just not change history. |
| # | 22:17:36 | Dyrcona | bshum++ |
| # | 22:17:53 | jeff | i have branches to push |
| # | 22:18:04 | bshum | jeff++ |
| # | 22:18:12 | bshum | :D |
| # | 22:18:13 | Dyrcona | jeff: not my folks....they want those billings obliterated. |
| # | 22:18:25 | Dyrcona | jeff++ |
| # | 22:18:26 | matt_carlson has quit IRC |
| # | 22:18:41 | Dyrcona | more branches to climb. :) |
| # | 22:18:45 | jeff | we don't do refunds, and we prefer not to have history of "this was taken in as payment for THIS billing type" change |
| # | 22:19:36 | Dyrcona | we're a consortium. "we" whatever "we" want. "we" each member on their own..... :) |
| # | 22:19:46 | Dyrcona | oh man.... |
| # | 22:19:53 | Dyrcona | that's it. I am going to bed, now. |
| # | 22:20:11 | jeff | yeah. we're a district with four boards of trustee. |
| # | 22:20:16 | Dyrcona | good night or morning, afternoon, or whatever it is wherever you are. |
| # | 22:20:21 | jeff | Dyrcona: nite! |
| # | 22:20:30 | Dyrcona has quit IRC |
| # | 22:46:34 | tecoripa has left #evergreen |
| # | 22:56:06 | AaronZ-PLS has quit IRC |
April 10-13