| # | Time | Nick | Message |
|---|
| # | 01:19:11 | tfaile has quit IRC |
| # | 03:36:24 | Callender has quit IRC |
| # | 05:54:05 | gmcharlt has quit IRC |
| # | 05:54:11 | gmcharlt has joined #evergreen |
| # | 06:21:47 | EgUser has joined #evergreen |
| # | 06:23:10 | EgUser | Could anyone here help with a Marc display problem on Staff Client? |
| # | 06:35:44 | bshum has quit IRC |
| # | 06:36:04 | EgUser has quit IRC |
| # | 06:51:32 | bshum has joined #evergreen |
| # | 06:51:33 | tfaile has joined #evergreen |
| # | 07:11:17 | EgUser has joined #evergreen |
| # | 07:51:23 | mrpeters-isl | EgUser: just ask, and someone will answer if they can |
| # | 07:52:45 | plux has joined #evergreen |
| # | 07:53:08 | EgUser | Thanks - I have systems setup for testing and although the imported MARC records looks fine, I can't get certain fields to display |
| # | 07:53:17 | EgUser | e.g 245 and 650 |
| # | 07:53:23 | plux has quit IRC |
| # | 07:53:45 | plux has joined #evergreen |
| # | 07:53:46 | EgUser | They should up on the list screen but when I click on the title and get directed to the summary screen only some fields show |
| # | 07:54:01 | EgUser | I have edited the correct XML as per the WIKI but they still won't show |
| # | 07:54:10 | EgUser | has anyone got any ideas where to start? |
| # | 07:54:32 | plux has quit IRC |
| # | 07:54:48 | plux has joined #evergreen |
| # | 07:57:33 | plux has quit IRC |
| # | 07:57:54 | plux has joined #evergreen |
| # | 08:08:23 | akilsdonk has joined #evergreen |
| # | 08:21:16 | collum has joined #evergreen |
| # | 08:23:38 | Dyrcona has joined #evergreen |
| # | 08:28:12 | kmlussier has joined #evergreen |
| # | 08:32:03 | mrpeters-isl | EgUser: Can you clarify where in the staff client you're expecting to see this? A screenshot maybe? |
| # | 08:32:33 | _bott_ has quit IRC |
| # | 08:32:38 | mrpeters-isl | im thinking of so many places you could be talking about |
| # | 08:33:34 | _bott_ has joined #evergreen |
| # | 08:34:08 | EgUser | Yeah, no problem. It will take me a few minutes to get screen shot |
| # | 08:54:49 | EgUser | A really strange thing.....here is the image first |
| # | 08:54:50 | EgUser | http://imagebin.org/193218 |
| # | 08:55:24 | EgUser | However, it seems to be working, but it took about 1 hour to work. |
| # | 08:55:39 | mrpeters-isl | oh, so you're wondernig why the author is blank? |
| # | 08:55:49 | adbowling-isl has joined #evergreen |
| # | 08:55:52 | EgUser | I edited the result_detail.xml file but no data appeared |
| # | 08:56:11 | mrpeters-isl | hmm you shouldnt have to be touching any of that stuff |
| # | 08:56:11 | EgUser | I refreshed, tried everything, then went to lunch and now the data is there |
| # | 08:56:24 | EgUser | I thought so too |
| # | 08:56:32 | EgUser | It's a system I inherited |
| # | 08:56:38 | EgUser | it is back on 2.05 |
| # | 08:57:04 | mrpeters-isl | so, this screenshot is out of date? your problem is solved now? |
| # | 08:57:37 | EgUser | Kind of but it has raised a lot more questions! Firstly, is the author blank as its an authority? If so, how can I add it... |
| # | 08:57:59 | mrpeters-isl | im not a good person to answer that...not a cataloger :( |
| # | 08:58:03 | EgUser | secondly, is there some delay in display/indexing update that would account for the changes not reflecting straight away? |
| # | 08:58:10 | mrpeters-isl | might help if you pasted the record for people to look at though |
| # | 08:58:20 | EgUser | The actual MARC record? |
| # | 08:59:18 | mrpeters-isl | yes |
| # | 08:59:38 | mrpeters-isl | use paste.lisp.org though |
| # | 08:59:57 | Dyrcona | EgUser: just hit the MARC Record on that screen you pasted and paste a screen shot or copy and paste to another paste service. |
| # | 09:00:11 | Dyrcona | MARC Record link. |
| # | 09:01:26 | EgUser | Eh....I will pass this time, and slap myself in the face! There is no author on this record! So that is solved. I suppose I need to figure out why my changes took so long to reflect |
| # | 09:01:49 | Dyrcona | EgUser: How did you change/load the record? |
| # | 09:02:53 | EgUser | I didn't change the marc record at all, that stayed the same. The problem was the Title was showing blank, for all records, so I edited the rdetail_summary.xml page and added it there.... |
| # | 09:03:08 | EgUser | but nothing happened, for a long time. Then suddenly it started to work |
| # | 09:03:28 | Dyrcona | EgUser: Browser or client cache, most likely. |
| # | 09:04:28 | EgUser | It is on the client. Strange that the new field labels I added appeared straight away though, although blank. Regardless, I can keep going trying to get my head around Evergreen! |
| # | 09:05:13 | mrpeters-isl | how did you import the record? batch loader? migration tools? |
| # | 09:06:07 | EgUser | I used the migration_tools |
| # | 09:06:22 | mrpeters-isl wonders if the ingest was slow to create metabib.real_full_rec and stuff? |
| # | 09:07:45 | mrpeters-isl | i just wonder if metabib.author_field_entrya nd its friends were not populated when you first did the search |
| # | 09:07:49 | dbs has joined #evergreen |
| # | 09:07:49 | dbs has joined #evergreen |
| # | 09:10:08 | tsbere | eeevil++ |
| # | 09:18:54 | Meliss has joined #evergreen |
| # | 09:21:04 | dbs | yay, we made it 1.5 weeks before hitting 100% Apache CPU usage after bumping max_stanza_size in ejabberd up to 4,000,000 |
| # | 09:21:06 | alynn26 has joined #evergreen |
| # | 09:21:53 | bshum | 4 million? o.O |
| # | 09:22:23 | dbs | yep |
| # | 09:23:00 | dbs | our suspicion for years is that we have some bibs with thousands of copies attached that seem to trigger an apache death spiral |
| # | 09:23:13 | bshum | Sounds ominous. |
| # | 09:23:25 | dbs | (migrated circulating serials that predate current serials support) |
| # | 09:23:25 | bshum | I think some of our stub records are like that. |
| # | 09:23:28 | bshum | Or magazines |
| # | 09:23:40 | bshum | Yeah, sounds evil. |
| # | 09:24:29 | Dyrcona | dbs: we have some records with huge numbers of copies. so far, we've noticed they don't display in holdings maintenance, cause they push the messages over the ejabberd max size. |
| # | 09:24:31 | dbs pleads weakly again for integrated RELEASE NOTES for simultaneous documentation of features/bug fixes like "placing holds on age-protected items" |
| # | 09:25:15 | berick | dbs: is there consensus on where the release_notes file should live? |
| # | 09:25:28 | Dyrcona jokes: Documentation is for sissies. :) |
| # | 09:25:49 | dbs | berick: tsbere expressed some reservations in IRC about the current branch (having the release notes filename in README) |
| # | 09:26:15 | dbs | but as far as I know there are no other proposals or branches being put forth, and meanwhile the release notes lag and lag |
| # | 09:27:46 | dbs wondering whether readme & release notes & Makefile.install* would fall into a class of commits that can go without review - assuming that a Fedora person who wants to commit fixes for Fedora prereqs / instructions is unlikely to get someone to actually test those changes |
| # | 09:28:35 | dbs | similarly, worst-case scenario for getting readme / release notes wrong is typos or incorrect info, versus functionality breaking for code changes |
| # | 09:28:53 | dbs | (okay, worst case scenario for readme is wiping somebody's server but let's hope we don't go there) |
| # | 09:30:33 | Callender has joined #evergreen |
| # | 09:31:02 | berick | +1 to non-review commits of readme & release notes. we should make it easy to bear fruit w/ doc writing |
| # | 09:31:58 | Dyrcona | +1 to non-review of readme and release notes |
| # | 09:32:14 | Dyrcona | -1 to non-review of Makfile.install. |
| # | 09:32:36 | tsbere | +1 to non-review commits to docs in general in the code repos |
| # | 09:32:37 | Dyrcona | I'd like people to at least eyeball any changes that I make, since I am known to make typos. |
| # | 09:32:40 | dbs | Dyrcona: great. who the hell is going to review Fedora changes |
| # | 09:33:03 | Dyrcona | dbs: I'd be happy to at least check them for Make syntax erros. |
| # | 09:33:12 | Dyrcona | doh.... see what I mean. :) |
| # | 09:33:14 | tsbere | dbs: When I attempted to look at some of your fedora changes my main goal was "make sure the package names look correct". Then I broke my ability to run perl tests and never signed off on that..... |
| # | 09:33:45 | dbs | That's a pretty low bar. Could we automate that test? |
| # | 09:34:50 | dbs | e.g. eeevil's change for pgsql 9.1 looked fine, but in practice was totally broken. and my change for APT_BACKPORT_TOOL was great for squeeze, but broke ubuntu |
| # | 09:35:11 | tsbere | So split them by platform |
| # | 09:35:15 | dbs | Makefile.install schism - yep |
| # | 09:35:25 | jenny has joined #evergreen |
| # | 09:35:36 | tsbere | "confirmed by X to work on platform Y" works for me so long as the same file isn't used for platform Z too ;) |
| # | 09:35:37 | Dyrcona | I could be persuaded to vote for non-review of Makefile.install changes if we split the file(s) up by platform. |
| # | 09:36:08 | dbs | we can add FreeBSD then too ! |
| # | 09:36:44 | tsbere thinks that "non-review" should be "didn't test on that platform" compared to "didn't even make sure there are no syntax errors" so long as the person submitting the changes claims they worked and you honestly don't have the platform in question to test on |
| # | 09:37:27 | dbs | tsbere: again, computers are way better at detecting syntax errors than humans are. Surely a test for that would be straightforward |
| # | 09:37:48 | tsbere | dbs: Yes, but should be run by the reviewer *anyway*, even if the author says they did ;) |
| # | 09:38:10 | dbs | tsbere: we should be running "make check" before any commit and any review, too, right? |
| # | 09:38:31 | dbs | and our dead testing server should be telling us the status, too |
| # | 09:39:02 | tsbere varies on running "make check" due to some things not being testable by it, prefers making sure the system actually *runs* and the affected portions still work |
| # | 09:39:54 | dbs | tsbere: that's *great* but sometimes the affected portions *aren't* obvious |
| # | 09:39:57 | tsbere | I *am*, however, willing to push for "when messing with the main SQL files one should drop their test DB and re-load from scratch before sign-off" |
| # | 09:40:04 | tsbere | <_< |
| # | 09:40:17 | dbs | sounds good to me |
| # | 09:40:59 | alynn26 has left #evergreen |
| # | 09:42:37 | dbs | hmm, 14M rows in auditor.asset_call_number_history, time to trim some of those heavily reingested ##URI## entries (buh bye, 3M rows) |
| # | 09:43:09 | tsbere is also freakishly paranoid about his own code, not even committing it more than half the time until it installs and functions on a full DB reload ... which has bitten him at least twice when he did a git clean without committing |
| # | 09:46:42 | dbs is pretty paranoid, but does commit locally regularly because he is also paranoid about losing work |
| # | 09:46:55 | Dyrcona used to not commit code at least until it was run on his dev machine, but now commits on his workstation and pulls to his dev machine for implementation testing. I've started using rebase before pushing to working more often. |
| # | 09:49:54 | dbs pushes stuff to Conifer repo to test on our testing server, and/or pulls from working branches |
| # | 09:59:12 | berick will not be dropping any test DB's :) but will gladly load altered files into a bare DB. |
| # | 09:59:32 | berick | at least, not until concerto has a bit of everything |
| # | 10:00:50 | tsbere blows his test db out at least one day a week at this point, and on those days does so at least 5-10 times |
| # | 10:01:19 | tsbere | berick: I disagree with concerto having "a bit of everything", BTW. I think users should be loaded from their own file, for example ;) |
| # | 10:01:36 | berick | tsbere: sorry, concerto and friends |
| # | 10:02:13 | dbs agrees with tsbere on that one - but concerto could stand to have a few more corner cases (like a title with non-filing indicators and "L'" beginning, for example, or more titles that line up with OpenLibrary...) |
| # | 10:03:14 | dbs | go little autovacuum go, recover from 36 hours of continuous updates to asset.call_number |
| # | 10:03:30 | tsbere | BTW, for fun, a windows shell "YMD" output that works for those that have M/D/Y output (because good luck making this work globally without more complicated scripting): %date:~-4,4%%date:~-10,2%%date:~-7,2% |
| # | 10:04:11 | dbs | heh, that reminds me of the hatred directed my way for the switch to M/D/Y date formatting in the staff client |
| # | 10:05:13 | tsbere is outputing filenames with the YMD chunk in them on the server, and for those that want to automate grabbing them figured he should provide a "this is how you tell a windows shell to spit that out" tip |
| # | 10:05:21 | dbs looks hopefully at format.date OUS |
| # | 10:05:49 | tsbere | Note that I would *prefer* to tell the entire staff client "dates look like YYYY-MM-DD" but our librarians would hate me. <_< |
| # | 10:06:25 | EgUser has quit IRC |
| # | 10:09:03 | sylvar | I ought to start a branch that uses icons like http://ragefac.es/106 instead of the standard warning/error icons |
| # | 10:09:56 | Dyrcona | Checkout, y u no work?!! |
| # | 10:10:25 | mrpeters-isl | yes! |
| # | 10:10:29 | bshum | sylvar: +1 |
| # | 10:18:15 | alynn26 has joined #evergreen |
| # | 10:21:40 | dbs | format.date++ |
| # | 10:21:50 | dbs | works pretty well |
| # | 10:38:11 | tecoripa has joined #evergreen |
| # | 10:38:56 | dbs | buh bye, 1.4M asset.call_number deleted ##URI## rows. you and your triggers and rules can't stop me. bwahahaha |
| # | 10:41:15 | tsbere | heh |
| # | 10:54:43 | Dyrcona | you know your vm's disk is thrashing when it has been 4 minutes since you typed git pull and nothing has changed in the terminal window. |
| # | 10:54:57 | dbs hopes this will speed up the reingest process for the next 200K bibs with modified located URIs. sigh. |
| # | 10:56:39 | tecoripa has left #evergreen |
| # | 11:00:33 | jenny1 has joined #evergreen |
| # | 11:02:02 | jenny has quit IRC |
| # | 11:03:51 | plux has quit IRC |
| # | 11:04:55 | graced has joined #evergreen |
| # | 11:17:32 | tspindler has joined #evergreen |
| # | 11:19:15 | youdonotexist has joined #evergreen |
| # | 11:39:26 | bshum | Hmm |
| # | 11:39:49 | bshum | So we're getting an interesting error when trying to view marc for new records that are to be imported via z39.50 |
| # | 11:39:54 | bshum | http://pastie.org/3172541 |
| # | 11:40:06 | bshum | Not sure what the story is yet, but I guess folks are concerned about it. |
| # | 11:40:24 | tsbere | That looks annoying |
| # | 11:40:25 | bshum | We don't use it often, so it may have just been missed under the radar. |
| # | 11:40:36 | bshum | Alternatively, it might be a quirk in our 2.0 system |
| # | 11:40:43 | bshum | I know that it's different in 2.1 or was it 2.2+? |
| # | 11:40:44 | Dyrcona | Are you using any patches, extra branches? You could be missing something. |
| # | 11:41:28 | bshum | Dyrcona: I'll have to double check on that, since we hand patch everything right now. Have to keep working on our git skills :( |
| # | 11:42:35 | bshum | I don't believe we have anything special related to that interface though |
| # | 11:43:47 | matt_carlson has joined #evergreen |
| # | 11:45:12 | bshum | The last thing that looks to have been changed there was something with search fields. |
| # | 11:45:30 | bshum | Granted, I think this is the first time I've ever been asked to test importing from OCLC |
| # | 11:45:36 | bshum | Using the login credentials, etc. |
| # | 11:45:43 | bshum | So I've never tested the interface in this way before |
| # | 11:49:15 | bshum | f.my_init() gets called in z3950.js on line 140, it seems. |
| # | 11:49:49 | bshum | Looks the same way in the rel_2_0 branch |
| # | 11:49:59 | bshum | So doesn't look too much like we changed anything there recently |
| # | 11:52:10 | dzeiger has joined #evergreen |
| # | 11:52:32 | tsbere forgot he wanted to build on https://bugs.launchpad.net/evergreen/+bug/876517 alongside all the hold stuff on his next major project....but with only one branch to build on he can just use that as his base branch anyway |
| # | 11:52:33 | pinesol_green | Launchpad bug 876517 in Evergreen "Circ Modifier Limits are too limiting" (affected: 1, heat: 6) [Wishlist,New] |
| # | 12:09:46 | bshum | "f.my_init" only appears once and it's in that z3950.js file |
| # | 12:16:00 | bshum | This makes me wonder if it works for others out there. |
| # | 12:16:17 | bshum | Sigh |
| # | 12:16:24 | tsbere has no clue, can ask catalogers if they ever import that way (if they are around today....I didn't notice yet >_>) |
| # | 12:17:10 | bshum | I suppose it's different for you guys though, tsbere. |
| # | 12:17:17 | bshum | Since you have the newer z39.50 stuffs |
| # | 12:17:41 | bshum | Still, doesn't hurt to ask :P |
| # | 12:17:58 | dbs has left #evergreen |
| # | 12:18:00 | bshum | My thought is whether the view marc would even work on a record that hasn't been imported yet |
| # | 12:18:13 | bshum | Besides the fact that the functions seem oddly broken |
| # | 12:18:13 | tsbere | bshum: Well, I am told we do use it, and we don't see errors. So master is likely working. <_< |
| # | 12:32:11 | dzeiger has quit IRC |
| # | 12:32:52 | tsbere | bshum: Decided to take a closer look at your issue. F is the marc_frame. It looks like it should have marc_view.html loaded into it (it is an iframe) which contains a my_init function.....either that or it should be marc_view.xul which also has a my_init. Thus should be a function either way. Maybe something blocked the file from loading? |
| # | 12:34:19 | tsbere also notes that both my_inits should be called by the onload handlers, and thus has no clue why the z3950.js file needs to call it too |
| # | 12:35:32 | bshum | tsbere: That sounds bad, I wonder what would cause it to fail to load. |
| # | 12:35:54 | tsbere | bshum: your server. Check the logs? |
| # | 12:36:09 | bshum | tsbere: The logs don't record the incident at all, it seems. |
| # | 12:36:40 | tsbere | bshum: apache access log entries for marc_view.blah? |
| # | 12:37:04 | phasefx | I think my_init gets called because the frame content gets re-used, not reloaded.. so more like reinit |
| # | 12:37:24 | bshum | Aha |
| # | 12:37:32 | bshum | tsbere: XMLENT XML Parse Error |
| # | 12:39:00 | bshum | tsbere: something like this- http://pastie.org/3173440 |
| # | 12:39:04 | tsbere | bshum: Well then, I think you have your answer as to what the base problem is. Now you need specifics. Like what XMLENT is broken. >_> |
| # | 12:40:57 | tsbere | bshum: I don't see why that file should be parsed that way, actually. You have something doing parsing for all .html files that is non-standard or something? |
| # | 12:41:15 | tsbere | (or some other difference in it from stock, or a corrupt file, etc....) |
| # | 12:41:52 | tsbere doesn't think that file has changed from rel_2_0 to master |
| # | 12:44:35 | bshum | tsbere: Our version of marc_view.html looks exactly the same as the one in master. Except for the location for constants.js which includes our stamped version |
| # | 12:44:52 | bshum | tsbere: It's always possible that something else is different though, I suppose. |
| # | 12:44:53 | matt_carlson has quit IRC |
| # | 12:45:21 | bshum | Unless it's something in apache you mean that's parsing badly? |
| # | 12:45:25 | tsbere | bshum: I was thinking "does your eg_vhost or similar apache config differ for .html files" |
| # | 12:46:35 | bshum | tsbere: I'll check our eg_vhost file, perhaps something in there that's too old or too new. |
| # | 12:46:54 | bshum | tsbere: We've been carrying it forward since our 1.6 days, but maybe didn't change something that should have been |
| # | 12:50:04 | bshum | tsbere: Are you referring to this block? http://pastie.org/3173503 |
| # | 12:50:22 | bshum | If so, ours reflects what's currently in the sample eg_vhost file that ships with Evergreen's examples |
| # | 12:51:57 | matt_carlson has joined #evergreen |
| # | 12:52:35 | tsbere | bshum: Huh. <_< |
| # | 12:52:42 | tsbere should try requesting that locally, perhaps |
| # | 12:53:07 | tsbere | Nope, loads fine here. |
| # | 12:53:28 | tsbere | bshum: What is your version stamp? Standard rel_2_0_blah type stuff? |
| # | 12:53:51 | bshum | tsbere: Yeah, we've kept ours at rel_2_0_6, but it's really like 2.0.10+ |
| # | 12:57:27 | Dyrcona | bshum: then your clients could be out of sync with the server and still "working." |
| # | 12:57:37 | Dyrcona | bhsum: that's likely the source of your problem. |
| # | 12:58:05 | bshum | Dyrcona: Possibly, but I'm testing it with the latest client builds based on our server version behind the scenes. |
| # | 12:58:25 | bshum | Dyrcona: Yes, I know our stamp process sucks :P |
| # | 12:59:13 | phasefx | hey, you're only a symlink away from changing the process :) |
| # | 12:59:29 | bshum | Yeah, I thought about doing that next time |
| # | 12:59:35 | bshum | But you know, people hate change and all that :P |
| # | 13:00:00 | bshum | Ideally I think we're changing it up whenever we do the next actual upgrade. |
| # | 13:00:11 | bshum | I can figure this out then I guess |
| # | 13:00:44 | bshum | -= THIS MESSAGE NOT LOGGED =- |
| # | 13:01:17 | Dyrcona | bshum: we often force the upgrades by deleting the older directories as well after making the symlink. |
| # | 13:01:59 | Dyrcona | bshum: we use something like 2_1_1mvlc_N for our version number where N is an integer that goes up by 1 each time. |
| # | 13:02:41 | tsbere | Dyrcona: bshum doesn't have automatic updates yet, to my knowledge, and thus can't do that. :( |
| # | 13:02:50 | tsbere | bshum: Upgrade to 2.1+ to get automatic updates. <_< |
| # | 13:03:20 | Dyrcona | true, but it would force them download new clients. |
| # | 13:03:28 | bshum | tsbere: Dyrcona: Yeah, yeah, 2.1+ ftw |
| # | 13:03:38 | Dyrcona | master FTW! |
| # | 13:04:09 | Dyrcona | I'm going to get you guys converted, yet. ;) |
| # | 13:21:35 | matt_carlson has quit IRC |
| # | 13:21:50 | matt_carlson has joined #evergreen |
| # | 13:25:34 | tspindler | I was wondering if anyone would know why we would have null values in the "label sortkey" of the asset.call_number table. We did a test load and our call numbers have been given the "Other" classification and then I ran a query with regex statemetns to identify dewey and lc and change the class accordingly |
| # | 13:26:02 | tspindler | I'm not sure if the sortkey was loaded blank or my script query would have done something |
| # | 13:26:33 | tspindler | here is the dewey check UPDATE asset.call_number SET label_class=2 WHERE label ~* '[0-9]{3}.*'; |
| # | 13:26:33 | kmlussier has quit IRC |
| # | 13:28:31 | jenny1 has quit IRC |
| # | 13:29:06 | Dyrcona | tspindler: they were likely loaded blank, but without knowing more I can only guess. |
| # | 13:29:39 | tspindler | yeah, i don't see any triggers that would cause them to be blank from my query |
| # | 13:30:34 | tspindler | the funny thing is, i can't even enter data into them with a query such as "update asset.call_number set label_sortkey='123' where id= 143223 |
| # | 13:31:12 | Dyrcona | what happens? |
| # | 13:31:13 | tspindler | sue is not sure why they would have loaded blank |
| # | 13:31:14 | jenny has joined #evergreen |
| # | 13:31:37 | tspindler | when i run the above query i get 1 record updated then look at the record and nothing is changed |
| # | 13:32:32 | tsbere | tspindler: asset.label_normalizer is called on all updates to asset.call_number. It force-sets label_sortkey on every update. |
| # | 13:32:36 | Dyrcona | label sort_key is generated from the label. |
| # | 13:32:50 | Dyrcona | what's the label on that record look like. |
| # | 13:34:15 | tspindler | there is "955.054" and "V Auth 173Se2" are a couple |
| # | 13:35:04 | tsbere | tspindler: the label_normalizer function looks at the asset.call_number_class based on new.label_class for a normalizer function to call. If class isn't listed you will get an empty sort key.... |
| # | 13:35:08 | Dyrcona | sounds like triggers were off when the acns were loaded. |
| # | 13:35:21 | Dyrcona | or that.... ;) |
| # | 13:35:30 | tsbere | Dyrcona: To me it sounds like they have no normalizer function in asset.call_number_class, and thus get a null sortkey by default. :P |
| # | 13:35:59 | tsbere | tspindler: What happens if you "update asset.call_number set label_class = 1 where id = 143223" ? |
| # | 13:36:01 | tspindler | tsbere: so if they were loaded with the "other" call number the label_normalizer wouldn't trigger, only triggers for lc and dewey? |
| # | 13:36:13 | Dyrcona has blocked out the migration and doesn't remember if he had to deal with the class, etc., at that time. |
| # | 13:36:49 | Dyrcona | tspindler: If "other" has a normalizer, that one will run. |
| # | 13:37:53 | tsbere sees no default "Other" for call number class, just "Generic", "Dewey", and "Library of Congress" entries |
| # | 13:37:59 | Dyrcona only has 3 classes in his database: Generic, Dewey, and LC. Each has a normalizer defined. |
| # | 13:40:24 | tspindler | drycona: we also only have 3 , |
| # | 13:40:41 | tspindler | tsbere: i'm trying a couple different queries to see something and will post in a minute |
| # | 13:41:13 | tsbere | tspindler: Set your cat.default_classification_scheme OU setting to "1" as a default, if you don't have it set to 1, 2, or 3, then run an update on all null label_class call numbers? |
| # | 13:41:43 | gmcharlt has quit IRC |
| # | 13:41:44 | gmcharlt has joined #evergreen |
| # | 13:45:54 | b_bonner has left #evergreen |
| # | 13:46:49 | bshum | tsbere: I figured it out. |
| # | 13:46:58 | kmlussier has joined #evergreen |
| # | 13:47:02 | bshum | It's related to our new use of mod_deflate it seems |
| # | 13:47:17 | bshum | When I turn back off that apache module, marc_view works happily. |
| # | 13:47:24 | bshum | But with it on, it dies horrendously. |
| # | 13:47:45 | tsbere | bshum: I bet it is compressing it *before* the xml validation/parsing happens, then |
| # | 13:47:48 | tspindler | tsbere: setting to 1 updated sortkey, it might be as jason said, I'm guessing that there are separate dewey and lc triggers that are off |
| # | 13:48:15 | gmcharlt | bshum: hmm - initial thing I would suggest, then, is keeping the mod_deflate entries in eg_vhost.conf active for IDL2js |
| # | 13:48:19 | Dyrcona | tspindler: sounds more like you didn't have a default defined. |
| # | 13:48:21 | gmcharlt | as that is a big win |
| # | 13:48:24 | tsbere | tspindler: There is *one* trigger. that trigger checks the label_class integer (or, if null, the OU setting I mentioned) to figure out what call number class to check the function name of. Then it calls that function. |
| # | 13:48:31 | gmcharlt | selectively comment out other references |
| # | 13:49:30 | tspindler | tsbere: then I'm not sure why the lc and dewey sortkey creations aren't updating |
| # | 13:50:10 | tsbere | tspindler: What are the label_class values for those? |
| # | 13:51:11 | bshum | gmcharlt: So other than the ones for /idl2js, comment out the rest is what you suggest? |
| # | 13:51:22 | bshum | gmcharlt: We'll give that a whirl then. Thanks. |
| # | 13:52:32 | matt_carlson has quit IRC |
| # | 13:53:21 | bshum | gmcharlt: Oh fun times |
| # | 13:53:23 | gmcharlt | bshum: correct - commenting out *all* of the rest is probably a little more aggressive than is necessary -- I encourage you to do some further tweaking on a test system -- but like I said, for the specific issue you had, IDL2js will be the big win |
| # | 13:53:29 | bshum | jamesrf reported this problem in https://bugs.launchpad.net/evergreen/+bug/652343 |
| # | 13:53:30 | pinesol_green | Launchpad bug 652343 in Evergreen "possible bug in r17593" (affected: 1, heat: 0) [Undecided,Confirmed] |
| # | 13:54:12 | jeff | i nominate that bug for a new title :-) |
| # | 13:54:20 | bshum | Indeed. |
| # | 13:54:25 | jeff | jamesrf++ reporting the bug, regardless of title :-) |
| # | 13:54:28 | tspindler | tsbere: 1-Generic 2-Dewey 3-Library of Congress (LC) , if that is what you mean, I checked org_unit setting for default classification and I can't change it, no box |
| # | 13:54:53 | tspindler | tsbere: the default value is blanking (running EG 2.2 alpha |
| # | 13:54:59 | tsbere | tspindler: "no box"? |
| # | 13:55:34 | tspindler | tsbere: in the ui, there is no box to enter a default classification scheme |
| # | 13:56:05 | gmcharlt accepts jeff's nomination and changes the title of the bug |
| # | 13:56:58 | tspindler | tsbere: can post a screenshot but forgot where a good place is for that |
| # | 13:59:52 | tspindler | tsbere: see http://screencast.com/t/M8cuPiYu5O |
| # | 14:00:07 | tsbere | huh |
| # | 14:00:17 | tsbere | Something is busted, apparently. |
| # | 14:01:20 | tsbere | tspindler: insert into actor.org_unit_setting(org_unit, name, value) VALUES (1, 'cat.default_classification_scheme', '1') |
| # | 14:01:21 | tspindler | tsbere: i need to go through it but there is at least one other library setting i stumbled on that has the same issue, default patron identification |
| # | 14:01:22 | tsbere | <_< |
| # | 14:04:05 | tspindler | tsbere: client locked up on me but ran your query to insert org setting and it made the difference, ran query to update call number to dewey and sortkey populated |
| # | 14:04:26 | tspindler | tsbere: i can report as a potential bug for 2.2 alpha? |
| # | 14:04:33 | bshum | gmcharlt: On cursory glance, looks like mod_deflate only gets used in those blocks for /opac //opac /js and /idl2js |
| # | 14:04:47 | bshum | gmcharlt: I'll try commenting out the other three for now :P |
| # | 14:05:04 | tsbere | tspindler: Once that query runs you should be able to update the call numbers with null label_class values to get them to have sortkeys too, without changing their label_class values (or just update the label_class values as appropriate, whatever) |
| # | 14:05:20 | tsbere | tspindler: *you* decide what is worthy of you reporting a bug. Just try and keep enough info around. :P |
| # | 14:05:53 | tspindler | tsbere: sometimes I'm just not sure if its a bug or our install ;) |
| # | 14:17:11 | bshum | gmcharlt: Commenting out those lines didn't solve the problem at all, unfortunately. Commenting out the ones for idl2js along with it, didn't help either. Disabling mod_deflate entirely seems to be the only way for us at the moment. |
| # | 14:17:26 | bshum | gmcharlt: No middle ground it seems with that :( |
| # | 14:18:32 | gmcharlt | bshum: there might be yet |
| # | 14:19:02 | gmcharlt | check /etc/apache2/mods-{enabled,available}/deflate.conf |
| # | 14:20:19 | bshum | Okay |
| # | 14:20:49 | bshum | What should I look for there? |
| # | 14:21:17 | gmcharlt | is it doing something like "AddOutputFilterByType DEFLATE text/html text/plain text/xml" ? |
| # | 14:21:17 | tsbere | bshum: The default is bad. Makes all html/xml/other files go through mod_deflate. :( |
| # | 14:21:29 | gmcharlt | exactly |
| # | 14:21:30 | bshum | Yeah, it does include that line, on 3 |
| # | 14:22:07 | gmcharlt | try applying your +1 keyboard of commenting out to that, then, and enabling the module again |
| # | 14:23:42 | tsbere | gmcharlt: A thought, in that regard. What if we add "RemoveOutputFilter" statements in the proper places in the default config? |
| # | 14:24:14 | tsbere isn't sure if that removes those added with the "ByType" command, hasn't tested |
| # | 14:24:36 | gmcharlt | tsbere: something like that is probably better in the slightly longer term, yes |
| # | 14:25:34 | bshum | gmcharlt: So, commented that line in the deflate.conf, disabled, re-enabled the mod. Then took out all the commenting I did in eg_vhost.conf and all is still well with the world. |
| # | 14:25:42 | bshum | gmcharlt: Marc_view is happy now |
| # | 14:25:55 | tsbere | hmmm |
| # | 14:26:14 | tsbere thinks about how to best "fix" this, has ideas |
| # | 14:26:33 | bshum | I'll make that modification to our production bricks to get folks back on track for now. |
| # | 14:26:45 | bshum | tsbere: We'll be happy to help test any of your ideas :) |
| # | 14:27:15 | tsbere | bshum: I should enable mod_deflate for testing. >_> |
| # | 14:27:37 | bshum tries to figure out a nice way of juggling the bricks to fix things... |
| # | 14:31:14 | tsbere broke things, that is a good first step, right? |
| # | 14:31:27 | bshum | Heh |
| # | 14:37:45 | tsbere | Ok, I broke them less. But marc view is busted. <_< |
| # | 14:44:56 | Dyrcona discovers that reading code is not as much fun as writing it. |
| # | 14:52:12 | tsbere | bshum / gmcharlt : AddOutputFilterBytype is deprecated and no longer recommended for use.....and *impossible* to undo the effects of in any way I can find once used. There is no corresponding "Remove" variant. mod_filter *might* be able to override it with the filterchain directive, I think it was, but would need to be enabled as well. |
| # | 14:53:58 | bshum | tsbere: Hmm, found a bug ticket that says it was "un-deprecated" |
| # | 14:53:59 | tsbere | On a different note, adding IfModule blocks for mod_deflate.c wherever we use XMLENT to include an AddOutputFilter directive like "AddOutputFilter INCLUDES;XMLENT;DEFLATE .ext" doesn't break anything (because we force deflate to happen last) |
| # | 14:54:14 | tsbere | bshum: I was reading the docs for.... 2.1 apparently? |
| # | 14:54:51 | tsbere thinks that something that cannot be overridden when needed should not only not be used globally, but should never be installed as a default config option for any module |
| # | 14:56:33 | tsbere | note that my above ;DEFLATE stuff was *after* I disabled the "ByType" variants, for the record. |
| # | 15:00:38 | tsbere | bshum: They un-deprecated it when they made it a mod_filter command, it seems. Which means it likely plays nice with the FilterChain directive, which would allow for overriding it then. |
| # | 15:01:08 | youdonotexist has quit IRC |
| # | 15:04:23 | bshum | Hmm |
| # | 15:04:28 | matt_carlson has joined #evergreen |
| # | 15:15:13 | dzeiger has joined #evergreen |
| # | 15:22:37 | tsbere | bshum: Only solution I have that doesn't rely on changes to make that directive go to mod_filter and/or require that mod_deflate's config be edited from the ubuntu default (bad ubuntu/debian, BAD!) is to use SetEnv no-gzip on anything with an XMLENT output filter attached. |
| # | 15:22:47 | tsbere | gmcharlt: ^ |
| # | 15:25:10 | gmcharlt | tsbere: well, that's a significant improvement over no compression at all |
| # | 15:25:17 | gmcharlt | thanks for running through this |
| # | 15:26:00 | tsbere can make up a branch to try and catch all of those cases, if desired, for the stock master eg_vhost config |
| # | 15:27:09 | gmcharlt will be happy to test such a branch |
| # | 15:29:52 | youdonotexist has joined #evergreen |
| # | 15:39:52 | tsbere | gmcharlt: http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/tsbere/xmlent_hates_deflate |
| # | 15:41:03 | tspindler has quit IRC |
| # | 15:43:24 | tsbere | bshum: You may want to look at that branch too ;) |
| # | 15:43:35 | bshum | tsbere: Happy to test it out. |
| # | 15:43:59 | bshum | tsbere: I can try it on our test server to see how it behaves. |
| # | 15:57:39 | collum has quit IRC |
| # | 15:59:00 | matt_carlson has quit IRC |
| # | 16:01:25 | dzeiger has quit IRC |
| # | 16:07:54 | dzeiger has joined #evergreen |
| # | 16:08:10 | matt_carlson has joined #evergreen |
| # | 16:10:09 | bshum | tsbere: Inserting those changes seem to be going fine so far. |
| # | 16:10:26 | bshum | For our 2.0 test server |
| # | 16:12:17 | akilsdonk has quit IRC |
| # | 16:13:22 | kmlussier has left #evergreen |
| # | 16:15:43 | bshum | At least as far as using marc_view goes |
| # | 16:15:56 | bshum | Not sure what else to test yet. |
| # | 16:21:50 | bjwebb has joined #evergreen |
| # | 16:21:51 | bjwebb has joined #evergreen |
| # | 16:25:36 | matt_carlson has quit IRC |
| # | 16:29:18 | tsbere | bshum: The opac, for one, I think. |
| # | 16:48:22 | dbs has joined #evergreen |
| # | 16:48:55 | bshum | tsbere: So far so good then. The OPAC checks out and so does looking at view marc in the staff client |
| # | 16:49:07 | dbs shocked he apparently said something intelligent about mod_deflate once upon a time; not shocked to see that he had to go back and forth on it for a while first (typical) |
| # | 16:49:59 | bshum | dbs: Was amused with http://open-ils.org/dokuwiki/doku.php?id=troubleshooting:problems_with_the_catalog (the other reference I found about mod_deflate, you did in 2008) |
| # | 16:50:38 | dbs | aha |
| # | 16:51:50 | tsbere | Should I add my branch to that ticket that was referenced and flag it as pullrequest? :P |
| # | 16:54:39 | bshum | +1, sounds reasonable to me. |
| # | 16:54:44 | dbs predicts the future: 2012-01-10T13:51:26 <dbs> yeah, IIRC mod_deflate did horrible things to HTTPS and/or XMLENT with the old default configs, I think that was sorted a while ago though |
| # | 16:55:15 | dbs | tsbere++ |
| # | 16:57:48 | dzeiger has quit IRC |
| # | 17:01:17 | jeffdavis | Is anyone here using the ApplyPatronPenalty a/t reactor? I can't see how to make it work. |
| # | 17:02:32 | bshum | jeffdavis: Just went to read about that reactor, did you setup the necessary environment variables? |
| # | 17:02:46 | bshum | jeffdavis: The perl file notes that "user" and "context_org" need to be assigned. |
| # | 17:03:18 | jeffdavis | I tried doing so but I suspect I am doin it rong. |
| # | 17:04:40 | jeffdavis | Went into Event Environment and added one with field_path = usr and label = user, another with field_path = circ_lib and label = context_org. |
| # | 17:06:24 | jeffdavis | But the reactor complains that $user and $context_org are undefined in that case (I added some logging for local testing purposes). |
| # | 17:06:50 | jeffdavis | No dice with anyother combinations I could think of. |
| # | 17:08:58 | bshum | jeffdavis: Hmm, I guess we're not using that reactor yet, so I don't have any examples on hand to play with. Maybe someone else here will have some suggestions on what to try. |
| # | 17:14:25 | senator | jeffdavis: what's the value of the hook column of the event definition where you're using the ApplyPatronPenalty reactor? |
| # | 17:23:57 | Dyrcona has quit IRC |
| # | 17:31:11 | jenny has quit IRC |
| # | 17:35:31 | Elizabeth_ has joined #evergreen |
| # | 17:41:39 | Elizabeth_ has quit IRC |
| # | 17:43:21 | jenny has joined #evergreen |
| # | 17:44:47 | jeffdavis | senator: sorry for delay, we had an all-hands-on-deck situation. |
| # | 17:45:02 | jeffdavis | The event def uses the 'checkout.due' hook so circ is the core type. |
| # | 17:45:11 | jenny has quit IRC |
| # | 17:47:19 | senator | jeffdavis: no problem |
| # | 17:50:46 | dbs has quit IRC |
| # | 17:53:09 | senator | jeffdavis: and group_field is null on the action_trigger.event_defintion row in question? i'm probably not suggesting anything you haven't already checked. sorry :-/ |
| # | 17:53:31 | senator | perhaps whoever's already using ApplyPatronPenalty can share their configuration |
| # | 17:53:54 | senator is out for now |
| # | 17:57:01 | jeffdavis | yep, group_field is null. I appreciate the suggestions. |
| # | 18:23:13 | tsbere has quit IRC |
| # | 18:32:37 | dzeiger has joined #evergreen |
| # | 18:44:17 | tsbere has joined #evergreen |
| # | 18:46:27 | b_bonner has joined #evergreen |
| # | 18:59:59 | Callender has quit IRC |
| # | 19:06:57 | Callender has joined #evergreen |
| # | 19:30:45 | tater-laptop has joined #evergreen |
| # | 19:34:05 | Callender has quit IRC |
| # | 19:36:58 | Callender has joined #evergreen |
| # | 19:43:59 | Callender has quit IRC |
| # | 19:46:12 | Callender has joined #evergreen |
| # | 19:53:28 | dzeiger1 has joined #evergreen |
| # | 19:56:39 | eeevil_ has joined #evergreen |
| # | 19:58:03 | kivilaht3o has joined #evergreen |
| # | 20:00:49 | graced has quit IRC |
| # | 20:03:41 | dzeiger has quit IRC |
| # | 20:03:41 | eeevil has quit IRC |
| # | 20:03:41 | kivilaht1o has quit IRC |
| # | 20:41:53 | bjwebb has quit IRC |
| # | 20:59:52 | tater-laptop has quit IRC |
| # | 21:00:01 | tater-laptop has joined #evergreen |
| # | 22:13:02 | Callender has quit IRC |
| # | 22:15:14 | youdonotexist has quit IRC |
| # | 22:16:38 | eeevil_ is now known as eeevil |
| # | 22:26:12 | Callender has joined #evergreen |
| # | 22:37:42 | dzeiger has joined #evergreen |
| # | 22:37:54 | dzeiger has left #evergreen |
| # | 22:41:05 | dzeiger1 has quit IRC |
| # | 23:19:02 | youdonotexist has joined #evergreen |
| # | 23:57:40 | tater-laptop has quit IRC |
April 10-13