| # | Time | Nick | Message |
|---|
| # | 00:02:13 | timhome has joined #evergreen |
| # | 01:22:02 | elene has joined #evergreen |
| # | 01:23:42 | elene has quit IRC |
| # | 01:44:21 | co_ajak_cewe_ngi has joined #evergreen |
| # | 01:44:21 | co_ajak_cewe_ngi has left #evergreen |
| # | 03:51:04 | _bott_ has quit IRC |
| # | 03:51:29 | _bott_ has joined #evergreen |
| # | 04:28:03 | luisb has quit IRC |
| # | 07:35:11 | wlayton has joined #evergreen |
| # | 07:58:55 | fortin has joined #evergreen |
| # | 07:59:12 | elene has joined #evergreen |
| # | 08:00:27 | magedshaker has joined #evergreen |
| # | 08:00:29 | magedshaker has left #evergreen |
| # | 08:05:19 | collum has joined #evergreen |
| # | 08:14:07 | akilsdonk has joined #evergreen |
| # | 08:18:11 | graced has joined #evergreen |
| # | 08:18:28 | kmlussier has joined #evergreen |
| # | 08:22:39 | Dyrcona has joined #evergreen |
| # | 08:23:51 | elene | hi all, I just did a test installation of 2.1.1 |
| # | 08:24:06 | _bott_ has left #evergreen |
| # | 08:24:26 | elene | everything works fine, but I can not change Org Units from Staff Clients |
| # | 08:24:48 | elene | I go to Admin > Server Administration > Organizational Units |
| # | 08:24:58 | elene | and I get Internal Server Error |
| # | 08:25:06 | elene | The server encountered an internal error or misconfiguration and was unable to complete your request. |
| # | 08:25:11 | elene | Is this something about Apache? |
| # | 08:25:22 | elene | Staff client seems to work fine, loading other pages with no issues |
| # | 08:28:37 | Dyrcona | elene: probably not, but checking your apache error logs will give you a clue. |
| # | 08:29:23 | _bott_ has joined #evergreen |
| # | 08:30:45 | elene | Thanks, Dyrcona. Do you happen to know where apache keeps its logs? :) |
| # | 08:30:57 | elene | I am on ubuntu 10.04 |
| # | 08:31:25 | elene | or would you happen to know where I should look for answers? |
| # | 08:31:43 | Dyrcona | elene: /var/log/apache2/ |
| # | 08:32:26 | elene | Thanks. |
| # | 08:32:28 | elene | This is the URL that gets Internal Server Error https:/domain.com/conify/en-US/global/actor/org_unit.html |
| # | 08:32:41 | elene | Can this be a Perl think then? |
| # | 08:32:59 | Dyrcona | elene: could be. could be a configuration problem all sorts of things. |
| # | 08:33:01 | elene | I remember back in 30s Int server errors were mostly for perl |
| # | 08:33:13 | elene | I see. but this is a fresh EG 2.1.1 install |
| # | 08:33:28 | Dyrcona | elene: did you run autogen.sh? |
| # | 08:34:33 | Dyrcona | without that, though, you probably could not login. |
| # | 08:35:33 | elene | When I reboot server, I can not run autogen, I run into IS NOT CONNECTED TO THE NETWORK!!! error |
| # | 08:35:43 | elene | when Updating fieldmapper |
| # | 08:35:57 | Dyrcona | elene: the opensrf services don't automatically restart. |
| # | 08:36:12 | elene | really? |
| # | 08:36:13 | Dyrcona | you should do osrf_ctl.sh -a start_all after a reboot. |
| # | 08:36:20 | elene | I see. |
| # | 08:36:26 | Dyrcona | you should also osrf_ctl.sh -a stop_all before a reboot. |
| # | 08:36:36 | elene | so what I do is, i run osrf_ctl.sh -l -a stop_all and then osrf_ctl.sh -l -a start_all |
| # | 08:36:46 | elene | ok i see |
| # | 08:36:54 | Shae has joined #evergreen |
| # | 08:36:58 | elene | so after that, autogen runs fine |
| # | 08:37:17 | elene | and I am able to log in to staff client |
| # | 08:37:26 | elene | but can not get to org units |
| # | 08:37:42 | elene | and i worked ok a couple of days ago when i did a fresh installation |
| # | 08:38:00 | Dyrcona | restart apache: sudo /etc/init.d/apache2 restart |
| # | 08:38:28 | Dyrcona | you should restart apache after restarting opensrf services. |
| # | 08:39:24 | csharp | good morning, all... in the action.hold_request table, what populates the "selection_ou" field? |
| # | 08:40:09 | csharp | we have an issue (that at first blush appears to be user error) where the pickup lib is not what the user intended/expected |
| # | 08:40:32 | elene | I see. Thanks. So, when server boots, I run osrf_ctl.sh -l -a start_all as opensrf and then reboot apache? |
| # | 08:40:42 | Dyrcona | elene: yes. |
| # | 08:40:54 | elene | Dyrcona: thanks :) |
| # | 08:41:04 | Dyrcona | yw. hope it helps solve your problem. |
| # | 08:41:06 | tsbere | csharp: I think that is altered by boundaries |
| # | 08:41:53 | tsbere | csharp: No, wait, the *depth* is altered by boundaries. The OU is probably defaulting to the request OU. |
| # | 08:43:04 | tsbere | csharp: Now, the pickup_lib defaults to the *user's* home library in 2.1, not the staff's work OU. If staff aren't paying attention and expecting the pickup_lib to be where they are *standing*..... |
| # | 08:43:11 | elene | Dyrcona: it solved my problem, thank you so much |
| # | 08:43:54 | csharp | tsbere: that sounds like a good clue - the specific example I'm looking at is a staff member |
| # | 08:48:34 | tsbere | csharp: Also, thinking about it, I believe that 2.1 got the code that says "we let you see *every* OU for hold placement" work, instead of just the opac visible ones, when logged in as a staff member... thus you could end up with an OU patrons can't even *see* being used as a pickup library. |
| # | 08:48:56 | csharp | yikes! |
| # | 08:49:12 | tsbere | csharp: That was intentional. Our central site can't be seen. We still want to pickup holds here ;) |
| # | 08:49:29 | csharp | tsbere: makes sense |
| # | 08:49:52 | tsbere | Just trying to give you the biggest picture I can for "how did X happen?" without even knowing 100% what X is ;) |
| # | 08:50:11 | csharp | in our case, OPAC invisibility means "closed" (or in at least case, "never existed") |
| # | 08:50:36 | csharp | tsbere: thanks - I'm still trying to figure out X too ;-) |
| # | 08:54:05 | tsbere | csharp: Given what little I know, though (bad pickup library on a hold) I am going to go for user error as the explanation. Thus, the answer for the staff member should probably be "Pay attention!" |
| # | 08:54:25 | csharp | yeah - that's what it looks like. I'm asking for more examples |
| # | 08:54:44 | csharp | given the fact that this is the first (or only) report, it must not be widespread |
| # | 08:54:58 | csharp | I'm just trying to head off any other surprise problems ;-) |
| # | 09:06:27 | Meliss has joined #evergreen |
| # | 09:27:26 | kmlussier_ has joined #evergreen |
| # | 09:29:40 | jenny1 has joined #evergreen |
| # | 09:30:13 | kmlussier has quit IRC |
| # | 09:33:27 | fortin has quit IRC |
| # | 09:36:16 | denials | bshum / tsbere: I wonder if we should remove qstore as dead / unused code; no sense in having a larger code footprint than necessary |
| # | 09:36:30 | bshum | denials: +1 |
| # | 09:36:35 | tsbere | +1 |
| # | 09:36:50 | tsbere | -1 if doing so distracts us too much from getting useful and functional code in, though ;) |
| # | 09:37:43 | alynn26 has joined #evergreen |
| # | 09:38:48 | eeevil | -1, it'd just come back later this year |
| # | 09:38:54 | berick | denials: it's not dead, it's (hopefully) going to be ... |
| # | 09:40:15 | tsbere | eeevil / berick: Any thoughts on https://bugs.launchpad.net/evergreen/+bug/937789 ? |
| # | 09:40:15 | pinesol_green | Launchpad bug 937789 in Evergreen "Deleting parts breaks hold interfaces" (affected: 1, heat: 6) [Medium,New] |
| # | 09:40:16 | berick | don't get me wrong, i love removing unused code ;) |
| # | 09:40:25 | eeevil | non-bib data browser, batch non-bib data update stuff |
| # | 09:42:42 | wlayton | hi all -- one very small suggestion for the OpenSRF README file... |
| # | 09:42:53 | wlayton | s/Subversion/Git/ |
| # | 09:43:28 | eeevil | tsbere: commented |
| # | 09:49:07 | elene has quit IRC |
| # | 09:51:29 | denials | wlayton: fire away |
| # | 09:53:18 | denials | eeevil / berick: well, you guys are the only ones who have any idea of what the large block of unused mysterious code that has sat there for 1.5 years, what's another 6 months eh? |
| # | 09:53:49 | tsbere | denials: wlayton's Subversion/Git thing *was* him firing away, I think. The README still says Subversion. |
| # | 09:54:59 | denials | tsbere: ah, got it; too subtle |
| # | 09:55:12 | denials needs a 2x4 for the state of his brain these days |
| # | 09:57:00 | denials | wlayton: pushed a fix to master |
| # | 09:58:56 | denials | also pushed to rel_2_0 |
| # | 09:59:19 | wlayton | denials: thanks -- didn't think it was worth a patch to change 2 words |
| # | 09:59:33 | wlayton | (as in, me submitting a patch) |
| # | 10:00:01 | denials | wlayton: or pushing a branch and getting author credits? Come on man, get your game on! |
| # | 10:00:04 | denials | :) |
| # | 10:03:26 | tsbere | denials: On the other hand, sometimes going through the "branch+launchpad bug" delays things by months ;) |
| # | 10:11:59 | sfortin has joined #evergreen |
| # | 10:13:26 | bshum | Reminder for those who haven't yet, please take a moment to fill out the doodle poll for scheduling the next developer meeting: http://www.doodle.com/hk6qmnss4x3vgwgb |
| # | 10:13:35 | bshum | kmlussier++ # for helping to set that up |
| # | 10:13:50 | tsbere did a wonderful job of not limiting time choices at all |
| # | 10:14:02 | tsbere | also, Doodle is under heavy load and not responding to all requests right now. |
| # | 10:14:05 | tsbere | doodle-- |
| # | 10:14:05 | bshum | (oh of course, I just clicked on that link and it's not working) |
| # | 10:14:08 | bshum | Sigh |
| # | 10:14:21 | bshum | Well, when it works, please take a moment to fill it out :) |
| # | 10:14:44 | kmlussier_ | bshum++ for the reminder. Worked for me this morning. :( |
| # | 10:16:04 | kmlussier_ | Worked when I took out the www - http://doodle.com/hk6qmnss4x3vgwgb |
| # | 10:16:37 | tsbere | kmlussier_: More like "just works now" |
| # | 10:16:48 | kmlussier_ | Spoke too soon - now it doesn't. |
| # | 10:17:11 | tsbere | Looks like Tuesday is still the best option day of week wise, though. Tis the only day with a full column of green so far. |
| # | 10:17:36 | tsbere | No, wait, stupid browser display glitch. Monday has one too. >_> |
| # | 10:18:06 | berick | kmlussier_++ bshum++ |
| # | 10:18:27 | tsbere figured that out when he looked at the bottom and saw the bold numbers, one of which disagreed with the column above it until he highlighted everything |
| # | 10:31:03 | graced_ has joined #evergreen |
| # | 10:32:46 | graced has quit IRC |
| # | 10:32:52 | graced_ is now known as graced |
| # | 10:44:36 | shopkins has joined #evergreen |
| # | 10:48:43 | elene has joined #evergreen |
| # | 10:58:36 | graced_ has joined #evergreen |
| # | 11:00:13 | graced has quit IRC |
| # | 11:00:26 | graced_ is now known as graced |
| # | 11:44:46 | denials | Dyrcona++ # bug wrangling |
| # | 11:48:16 | tsbere is considering pushing the updated upgrade script from bug 798255 with just his and Dyrcona's sign-offs.....and to a lesser extend the same thing for the circ limits branch from bug 876517 |
| # | 11:48:16 | pinesol_green | Launchpad bug 798255 in Evergreen master "archiving stat cats with aged circulation" (affected: 2, heat: 14) [Medium,In progress] https://launchpad.net/bugs/798255 |
| # | 11:48:17 | pinesol_green | Launchpad bug 876517 in Evergreen "Circ Modifier Limits are too limiting" (affected: 2, heat: 12) [Wishlist,In progress] https://launchpad.net/bugs/876517 |
| # | 11:49:49 | Dyrcona is making a "list." |
| # | 11:50:07 | bshum | And checking it twice? |
| # | 11:50:25 | Dyrcona | bshum: I'll send it to you so you can check it thrice. :) |
| # | 11:50:26 | denials | Dyrcona: question though - for a number of the bugs you've changed them to "In Progress", which we had been using for "someone has claimed this bug and is actively working on testing and integrating it" |
| # | 11:50:59 | Dyrcona | denials: That's pretty much the reason I changed to in progress, it looks like someone was or said they would do something with it. |
| # | 11:51:05 | denials | It doesn't seem like that's the case for Bug 838296 for example |
| # | 11:51:05 | pinesol_green | Launchpad bug 838296 in Evergreen "Seperate the MarkItemLost reactors from running with the rest of the daily triggers. " (affected: 1, heat: 6) [Undecided,In progress] https://launchpad.net/bugs/838296 |
| # | 11:51:41 | Dyrcona | denials: There's a git branch in the comments. That's another criteria that I used. |
| # | 11:51:46 | denials | 838296 isn't assigned to anybody, so it's "In Progress" with nobody responsible |
| # | 11:51:58 | Dyrcona | Several might be like that. |
| # | 11:52:22 | Dyrcona | I'm making a list of other bugs that need more attention to post to Google docs later. |
| # | 11:52:25 | denials | Ah. See, I use "In progress" as "Don't bother looking at the bug, somebody else is handling it" |
| # | 11:52:43 | Dyrcona | Ah. |
| # | 11:52:45 | denials | (for the few minutes that I get to dedicate to such activities these days) |
| # | 11:53:45 | Dyrcona | I'm trying to pare down the list of "new/undecided" bugs, and thought if there's code attached or looks like someone is looking into it, mark it in progress. |
| # | 11:54:10 | Dyrcona | The bug email did get you to look at it again, so that's half the battle. :) |
| # | 11:54:17 | denials | heh |
| # | 11:54:29 | Dyrcona | "You" not necessarily being denials, specifically. |
| # | 11:54:54 | berick also reads in-progress as "hands off, I got this" |
| # | 11:55:15 | Dyrcona | ok. good to know. |
| # | 11:55:40 | Dyrcona | i'll change my use of in progress to match what appears to be the consensus. |
| # | 11:56:20 | denials wonders if dbwells has had a chance to ponder denials' comments on bug 885528 |
| # | 11:56:20 | pinesol_green | Launchpad bug 885528 in Evergreen "LDAP authentication needed, preferably via an extensible authentication model" (affected: 1, heat: 6) [Wishlist,In progress] https://launchpad.net/bugs/885528 |
| # | 11:56:46 | Dyrcona | I am just trying to come up with a way for some of these older bugs to get some more attention. Perhaps we should put that on the agenda for the next dev meeting? |
| # | 12:03:23 | phasefx_ has quit IRC |
| # | 12:03:33 | phasefx_ has joined #evergreen |
| # | 12:04:22 | luisb has joined #evergreen |
| # | 12:05:11 | graced has quit IRC |
| # | 12:06:21 | dbwells | denials: Thank you very much for doing some testing on that branch and fixing a few clear blunders. I'll reply something to that effect on the bug. The only change I didn't quite understand was why the $cache assignment line caused load problems for you and not for me, but I see no problem with the change and didn't look into it any further. Also, I am actually replying to bug 932540 right now. |
| # | 12:06:21 | pinesol_green | Launchpad bug 932540 in Evergreen "Indexing multiple ISSNs in a single bib results in identifier|issn lookup failure" (affected: 1, heat: 6) [Undecided,New] https://launchpad.net/bugs/932540 |
| # | 12:07:59 | denials | dbwells: In the context of an operating system, that $cache thing generally works, but I had introduced a similar issue before and berick found that it did occasionally trigger issues |
| # | 12:08:44 | dbwells | denials: that is very good to know, thanks |
| # | 12:14:39 | bshum | Hmm, so I tried to modify the advanced search in tpac to show some more search filter options. And it worked, mostly. But then trying to retrieve a specific record result led us to internal server errors. |
| # | 12:15:10 | bshum | Does Tpac's record display include some sort of history or such that references search elements and my additional options are breaking that? |
| # | 12:15:38 | bshum | Background: I'm trying to add bib_level and lit_form as additional filter choices, since they were "missing" |
| # | 12:17:36 | denials | bshum: probably easier to show than to tell |
| # | 12:17:46 | bshum | denials: Good point :) |
| # | 12:17:55 | bshum | Let me push the changes somewhere |
| # | 12:26:26 | Dyrcona shakes his head at bugs referencing 1.6.2.4..... |
| # | 12:26:40 | bshum | denials: http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/bshum/tpac-advanced-search-filters |
| # | 12:26:45 | bshum | That's what I'm trying at the moment |
| # | 12:26:56 | bshum | Which seems to work so far as pulling in the desired data from the tables. |
| # | 12:27:40 | bshum | But I must be missing something else. |
| # | 12:37:48 | graced has joined #evergreen |
| # | 12:50:43 | berick | bshum: what exactly is breaking? |
| # | 12:51:07 | bshum | berick: When we try going into a specific record result, it goes to an apache internal server error message. |
| # | 12:51:24 | bshum | berick: I'm checking our error log but it wasn't exactly very forthcoming on why it died |
| # | 12:51:56 | bshum | The only error that was logged when we last tried it looked like this: http://pastie.org/3404298 |
| # | 12:53:00 | berick | bshum: mind checking the apache error log? |
| # | 12:55:04 | bshum | berick: Checking |
| # | 12:57:15 | bshum | http://pastie.org/3428497 was the only thing in the ap_error.log from that day. |
| # | 12:58:33 | berick | yeah, i've had problems with apache error logging and syslog |
| # | 12:58:38 | berick | for some reason, it does not log everything |
| # | 12:58:50 | senator | that is not apache log content at all |
| # | 12:58:54 | berick | when I kick it back to file logging, i start getting useful information again :( |
| # | 12:59:17 | berick | yep, well, that too |
| # | 12:59:19 | senator | could the apache logs be somewhere else due to misconfig? |
| # | 12:59:47 | bshum | senator: Certainly possible. I could try configuring the server back to standard logging for the time being. |
| # | 12:59:53 | bshum | And try recreating our errors :) |
| # | 13:03:50 | wlayton has quit IRC |
| # | 13:08:59 | bshum | Aha |
| # | 13:10:29 | bshum | berick/senator: http://pastie.org/3428587 |
| # | 13:10:55 | bshum | From the error.log for apache on that day |
| # | 13:11:34 | tsbere | That doesn't look like a JSPac issue, though |
| # | 13:12:10 | tsbere | Looks like a backend issue....and I see a *lot* of that kind of error without getting internal server errors here. |
| # | 13:12:27 | tsbere | Then again, I don't know how often I see them in the apache error logs |
| # | 13:13:03 | senator | bshum said tpac issue to start with, not jspac |
| # | 13:13:28 | bshum | Right, it's a tpac problem, not jspac |
| # | 13:13:31 | tsbere thought bshum was on a version of evergreen that doesn't play nice with TPac |
| # | 13:13:36 | tsbere | <_< |
| # | 13:13:44 | berick | bshum: that error probably relates to the cstore error in your first paste. i suggest back-bracking in osrfsys to find the CALL that created the error |
| # | 13:13:46 | bshum | We're testing master installs |
| # | 13:13:56 | bshum | And tweaking |
| # | 13:14:02 | tsbere | ahhh |
| # | 13:14:07 | berick | it should be a json_query call with from:actor.org_unit_ancestor_setting |
| # | 13:15:13 | berick | actually, hah |
| # | 13:15:27 | berick | it's right there in your first paste |
| # | 13:16:19 | berick | in the second line, ["1", ""] should just be a 1.. the org id is getting jacked up somehow |
| # | 13:17:20 | tsbere | berick: I bet I know how, too |
| # | 13:17:22 | bshum | Hmm |
| # | 13:17:33 | tsbere | ...&loc=1&...loc=&... |
| # | 13:17:52 | tsbere | Multiple instances is causing it to become an array in the backend |
| # | 13:18:09 | berick | yeah, if called in array context, that would do it |
| # | 13:18:26 | tsbere | and if called in a scalar context you may end up with a count, instead of the value |
| # | 13:18:51 | berick | not from cgi.param(). pretty sure it will return the first param value in scalar context |
| # | 13:19:10 | tsbere | depends on if you stored it *then* used it or not, I guess |
| # | 13:20:18 | berick | but, yeah, check the URL for extra 'loc' params, bshum |
| # | 13:20:46 | bshum | berick: Couldn't see them in the staff client (that's when we first noticed the issue), but I'll try it again in a browser |
| # | 13:21:14 | berick | bshum: in the staff client, debug -> modify URL |
| # | 13:21:23 | berick | menu along the top-right of browser container |
| # | 13:21:31 | bshum | Ahh, sweet |
| # | 13:21:35 | bshum | I'll remember that for next time |
| # | 13:23:48 | sal_ has joined #evergreen |
| # | 13:27:47 | elene has quit IRC |
| # | 13:32:00 | bshum | Haha |
| # | 13:32:08 | bshum | Course now I can't replicate my error, whee :) |
| # | 13:37:22 | bshum | Aha |
| # | 13:37:25 | bshum | There we go |
| # | 13:37:50 | bshum | berick: http://pastie.org/3428767 |
| # | 13:37:56 | bshum | That's from just now |
| # | 13:38:15 | bshum | Doesn't look like we have multiple loc anywhere |
| # | 13:39:47 | berick | bshum: those are just broken template errors |
| # | 13:39:57 | bshum | Boo :( |
| # | 13:43:49 | berick | bshum: searchbar.tt2, missing a closing %] |
| # | 13:43:58 | berick | none_label=l('All Formats');<br> |
| # | 13:51:07 | sfortin has quit IRC |
| # | 13:57:02 | graced_ has joined #evergreen |
| # | 13:59:02 | graced has quit IRC |
| # | 14:00:40 | graced has joined #evergreen |
| # | 14:02:31 | shopkins has quit IRC |
| # | 14:03:04 | graced_ has quit IRC |
| # | 14:17:50 | jamesrf has quit IRC |
| # | 14:18:15 | jamesrf has joined #evergreen |
| # | 14:24:23 | bshum | Okay |
| # | 14:24:37 | bshum | yeah, it has loc=1;loc=; |
| # | 14:24:43 | bshum | In the URL for a broken page |
| # | 14:27:56 | bshum | It actually only seems to break when I move the search sort from the end of that table row to a different row instead. |
| # | 14:28:02 | bshum | From limited testing |
| # | 14:28:08 | graced has quit IRC |
| # | 14:28:19 | bshum | Might also just be coincidence |
| # | 14:34:37 | graced has joined #evergreen |
| # | 14:38:55 | tsbere is having trouble deciding how to code a new WWW module >_> |
| # | 14:46:32 | dandrinkard has joined #evergreen |
| # | 14:47:13 | dandrinkard has left #evergreen |
| # | 15:06:33 | kmlussier_ has left #evergreen |
| # | 15:19:01 | bshum | berick: Found the source of the template error, it was user error on our end. Someone modified a file using windows and it included a bad return character |
| # | 15:21:39 | denials | WINDOWS? |
| # | 15:22:24 | bshum | :( |
| # | 15:23:25 | Dyrcona | <cr><lf> |
| # | 15:23:42 | Dyrcona | Hey, Bill! Teletype machines are dead! |
| # | 15:24:01 | Dyrcona had to maintain teletype software in the '90s. |
| # | 15:26:37 | tsbere | Dyrcona: Bill hasn't been significantly involved for a while now. Steve, maybe? :P |
| # | 15:26:53 | Dyrcona | Steve never wrote any code..... |
| # | 15:26:55 | tsbere | bshum: You should *only* give people access to edit those files via SSH. :P |
| # | 15:27:07 | bshum | tsbere: Heh |
| # | 15:27:10 | Dyrcona | Actually, I blame the guy that they bought QDOS from..... |
| # | 15:27:17 | bshum | Well, they're using WinSCP I think to talk to the server files |
| # | 15:27:27 | bshum | But sometimes they forget they shouldn't edit them using that program |
| # | 15:27:36 | tsbere | bshum: So disable SCP/SFTP for their accounts. :P |
| # | 15:27:40 | bshum | Heh |
| # | 15:27:51 | berick would be surprised if that caused any problems, apart from vim barking at you |
| # | 15:28:23 | Dyrcona | yeah... both <cr> and <lf> should be treated as whitespace in XML. |
| # | 15:29:25 | Dyrcona | unless the file got converted to UTF-16 or had one of the funky unicode line feeds, but even then.... |
| # | 15:29:33 | tsbere | Dyrcona: But Template Toolkit Templates aren't XML |
| # | 15:29:45 | berick | I bet this someone repaired the actual syntax error (from the log) and didn't fess up ;) |
| # | 15:29:51 | Dyrcona | oh. |
| # | 15:30:04 | Dyrcona was thinking of marc templates for some reason. |
| # | 15:30:58 | csharp | Hi all - general troubleshooting question here... |
| # | 15:31:45 | csharp | we have a library that is unable to start their staff client because it crashes with a JavaScript exception as it's loading, and the Debug Output button does not function for them |
| # | 15:32:43 | csharp | the debug console doesn't add output at the time of the crash either |
| # | 15:33:08 | csharp | so we're kind of flying blind... any other way we can generate debug output to work with? |
| # | 15:33:46 | csharp is not sure how helpful the actual Evergreen error is going to be but is trying all he can for the customer :-/ |
| # | 15:33:57 | tsbere | csharp: Might be a bad profile. Start with -P command line option? |
| # | 15:34:19 | csharp | tsbere: -P just creates a new blank profile? |
| # | 15:34:21 | tsbere | If it crashes *before* you get a profile selector then something is wrong, reinstall. Otherwise the profile has an issue, maybe the prefs.js file is correct. |
| # | 15:34:34 | tsbere | csharp: -P causes the profile selector to show up. |
| # | 15:34:38 | csharp | got it |
| # | 15:34:45 | tsbere | csharp: From there you can make a blank profile, delete the existing, etc... |
| # | 15:36:40 | mrpeters-isl | tsbere: do you know if the VM i shared last week ever made it up anywhere? |
| # | 15:37:07 | tsbere | mrpeters-isl: It made it to the downloads folder. Beyond that, no clue. |
| # | 15:37:14 | mrpeters-isl | yeah, 10-4 i figured as much |
| # | 15:37:23 | mrpeters-isl | bshum: any chance you can update the downloads page? |
| # | 15:37:37 | tsbere probably *could* update the website at this point, but isn't sure he *wants* to ;) |
| # | 15:37:54 | mrpeters-isl | no worries, just as long as someone will |
| # | 15:37:57 | bshum | mrpeters-isl: I could update the page, what's up? |
| # | 15:38:06 | mrpeters-isl | i put together a new developer VM |
| # | 15:38:35 | mrpeters-isl | based on master as of....umm...sometime last week |
| # | 15:39:17 | bshum | Ah okay |
| # | 15:39:21 | bshum | I'll try to update it momentarily. |
| # | 15:39:30 | mrpeters-isl | To enable you to get hands-on with the code as quickly as possible, the developer virtual image available from http://evergreen-ils.org/downloads/vm/EvergreenMasterSqueeze.ova is current with OpenSRF and Evergreen Master as of 2012-02-10. |
| # | 15:39:36 | bshum | Or if you'd like, you can submit a patch change on the website and I can apply it for you later. |
| # | 15:39:48 | tsbere | mrpeters-isl: Wasn't sure if you were going to give me a new copy with that nice automatic update script I handed ya tweaked and such |
| # | 15:42:04 | mrpeters-isl | ah, i havent had the chance to test it |
| # | 15:42:24 | mrpeters-isl | but i committed to at least getting this up so i want to make sure it gets on the site while it's still somewhat fresh |
| # | 15:42:48 | mrpeters-isl | does anyone still have a server with the auto-complete enabled that we coudl use to demo it Thursday at a meeting? |
| # | 15:45:53 | tsbere | mrpeters-isl: I think you can just update your master install |
| # | 15:46:48 | hopkinsju has joined #evergreen |
| # | 15:47:03 | mrpeters-isl | yeah, i can...but time is not on my side so i thought id see if anyone had it live still |
| # | 15:47:30 | tsbere | I would point you at my dev machine if it weren't horrible on whether or not it is usable ;) |
| # | 15:48:01 | mrpeters-isl | no worries...ill just have to find some time to get ot it |
| # | 15:48:13 | mrpeters-isl | ah, its in regular master now eh? |
| # | 15:48:17 | mrpeters-isl | that simplifies things big time |
| # | 15:48:58 | tsbere | mrpeters-isl: Went in yesterday |
| # | 15:49:04 | mrpeters-isl | <# |
| # | 15:49:07 | mrpeters-isl | <3 senator |
| # | 15:49:39 | tsbere | mrpeters-isl: You need some reingesting though >_> |
| # | 15:49:47 | mrpeters-isl | no worries, i only have a few hundred bibs |
| # | 15:50:43 | tsbere | was more of a "you can't just update the code and have it work" note ;) |
| # | 15:51:04 | mrpeters-isl | thanks |
| # | 15:51:09 | mrpeters-isl | you know me too well ;) |
| # | 15:51:32 | csharp | is is possible for the auth timeout problem to be affected by low bandwidth? I'm trying to troubleshoot the complaints from some (but not all) libraries about random timeouts |
| # | 15:51:34 | mrpeters-isl | is there any documentation for that? |
| # | 15:51:54 | mrpeters-isl | or shall i just dig back at the commits for autosuggest |
| # | 15:52:01 | hopkinsju | Didn't I see someone talking about running 2.2 alpha1 on Ubuntu 11.10? |
| # | 15:52:42 | eeevil | mrpeters-isl: the last commit, iirc, has a nice overview, and there's a new README as well, IIRC |
| # | 15:53:17 | tsbere | csharp: Once you are authed it shouldn't be a problem....login time, maybe, but not after the authtoken is there |
| # | 15:53:35 | tsbere | csharp: Although......if your memcache is filling up to capacity and things are being force-purged? |
| # | 15:53:42 | eeevil | mrpeters-isl: yeah: http://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=17e6420adc000b8a344519e4288d0d0cf09ae18a and http://git.evergreen-ils.org/?p=Evergreen.git;a=blob_plain;f=docs/TechRef/AutoSuggest/README;hb=17e6420adc000b8a344519e4288d0d0cf09ae18a |
| # | 15:53:59 | csharp | tsbere: how would I be able to see that in memcache? |
| # | 15:54:25 | tsbere | csharp: You know, I can never remember. I know you can telnet to the port to get status info with the right commands, though. Google? ;) |
| # | 15:54:34 | csharp | ;-) |
| # | 15:54:57 | eeevil | csharp: http://code.google.com/p/memcached/wiki/Tools |
| # | 15:55:11 | csharp | eeevil: excellent! |
| # | 15:55:15 | eeevil | so, google is the answer on multiple levels ;) |
| # | 15:55:20 | csharp | heh |
| # | 15:56:04 | mrpeters-isl | thank you eeevil |
| # | 15:58:49 | tsbere | csharp: Also, thinking about it, at one point we had some "in seconds" things set as something other than seconds. You might want to double check the inactivity timeout OU settings as well as the defaults in the xml configs. |
| # | 16:00:22 | Meliss has quit IRC |
| # | 16:00:30 | csharp | tsbere: cool - thanks |
| # | 16:00:41 | tsbere | csharp: For us it was, for example, the password reset timeout. We set it to "24 hours" and it got interpreted as "24 seconds" if I recall... |
| # | 16:00:51 | csharp | memcache-top verifies that memcache is not the issue, btw |
| # | 16:01:02 | csharp | good to know |
| # | 16:04:46 | mrpeters-isl | ok, i apologize but i'm not seeing the command needed to reingest for autosuggest |
| # | 16:07:08 | tsbere | mrpeters-isl: I think the easy solution is to "SELECT reingest_metabib_field_entries(id) FROM biblio.record_entry" but I could be wrong. |
| # | 16:07:24 | tsbere | Add "where delete = false" and similiar limits if desired |
| # | 16:07:44 | tsbere | or deleted, rather |
| # | 16:07:45 | tsbere | <_< |
| # | 16:08:23 | mrpeters-isl | hmm no function matches the given name |
| # | 16:08:43 | tsbere | Oh, right. Schema. Add "metabib." |
| # | 16:09:03 | mrpeters-isl | SELECT metabib.reingest_metabib_field_entries(id) FROM biblio.record_entry; |
| # | 16:09:07 | mrpeters-isl | yeah, thanks |
| # | 16:10:41 | tsbere is not looking forward to the update he is told to make that feature work on.... |
| # | 16:11:15 | mrpeters-isl | worried about performance? |
| # | 16:12:20 | tsbere | performance of what, the autosuggest feature itself? |
| # | 16:13:04 | mrpeters-isl | yeah |
| # | 16:13:09 | tsbere | Not really |
| # | 16:13:11 | mrpeters-isl | just curious what you arent looking forward to |
| # | 16:13:21 | tsbere | We have 916475 non-deleted bibs right now. <_< |
| # | 16:13:32 | mrpeters-isl | ah, yeah we've got you way covered :) |
| # | 16:13:48 | mrpeters-isl | but i see what you mean |
| # | 16:13:48 | bshum | The reingest script from 1.6-2.0 might be useful |
| # | 16:13:57 | tsbere | I think my estimates put the reingest at 6 hours or so? |
| # | 16:13:57 | bshum | Since that breaks it up into smaller chunks. |
| # | 16:14:53 | bshum | Though the final vacuums would suck. |
| # | 16:14:54 | tsbere was thinking that he might write up a better way to reingest just what is needed before then, though |
| # | 16:15:52 | akilsdonk has quit IRC |
| # | 16:16:28 | tsbere | basically grab the "browse_field" IF block out type deal |
| # | 16:17:01 | tsbere | Oh, and search_field too, I guess? |
| # | 16:17:09 | collum has quit IRC |
| # | 16:17:11 | tsbere hasn't fully examined it yet |
| # | 16:17:40 | tsbere | No, the search field stuff is already there. Just the browse field. |
| # | 16:19:16 | tsbere | For an initial populate it looks really easy to speed up, actually. |
| # | 16:25:31 | bshum | mrpeters-isl: For your virtual image, did you follow the same README style that denials had used previously? (users/passwords, etc.?) Or do you have your own accompanying documentation on how to use the virtual image? |
| # | 16:26:18 | bshum | Seems better to update both links on the downloads page appropriately. |
| # | 16:40:23 | tsbere | mrpeters-isl: http://pastebin.com/gHf9cKf1 maybe? |
| # | 16:40:41 | tsbere pokes senator about http://pastebin.com/gHf9cKf1 too |
| # | 16:45:22 | senator | tsbere: ok, almost didn't see your addition of 'where browse_field', |
| # | 16:45:57 | senator | and i would think you'd want to add DELETE FROM metabib.browse_entry_def_map WHERE source = bib_id; inside your outermost for loop to make it more reusable |
| # | 16:46:22 | senator | and i don't vouch that this is production-safe, but i would think it's certainly likely enough to work to try on a test system |
| # | 16:47:27 | tsbere | senator: I wasn't intending for "reusable" - regular reingest operations should otherwise take care of it, right? |
| # | 16:48:18 | tsbere was intentionally avoiding deletes of data that should realistically *not be there* right after the update scripts that create the new tables and such were run |
| # | 16:48:35 | senator | i suppose. i'm not considering all the circumstances where one may still want to avoid full reingest |
| # | 16:48:36 | tsbere | and searches for data that might be, etc and so forth |
| # | 16:50:56 | tsbere | senator: For that I would likely go for a modified reingest function that actually takes optional non-bibid parameters. Like an array of field entry ids that are used as a limiter if set and "skip_facets", "skip_browse", "skip_search" bools that default to false. |
| # | 16:51:38 | tsbere | Create new, drop existing. New one can then handle the calls for the existing one because only the bib_id is required, everything else can be skipped type deal. |
| # | 16:52:22 | senator | that would doubtless prove a very handy tool for some |
| # | 16:53:32 | Dyrcona aliases osrf_clt.sh to osrf_ctl.sh :) |
| # | 16:53:48 | tsbere | I think I have an exot alias ;) |
| # | 16:53:54 | wlayton has joined #evergreen |
| # | 16:55:08 | tsbere | senator: And now I am piecing together how to modify the function as I stated. >_> |
| # | 17:04:20 | Shae has quit IRC |
| # | 17:08:33 | tsbere | senator: Not 100% sure how to best deal with "just these field entries" - But I have "skip these parts" seemingly working: http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/tsbere/enhance_reingest |
| # | 17:08:46 | tsbere did minimal testing, though |
| # | 17:12:43 | senator | tsbere: nice. instead of dropping the old metabib.reingest_metabib_field_entry() function, wouldn't it be easier to keep it and have it simply call the newer version with false for the new parameters? |
| # | 17:12:53 | senator | oh |
| # | 17:13:02 | senator | n/m. i guess you have default false on the function args |
| # | 17:13:07 | senator | which i didn't know you could do |
| # | 17:17:11 | tsbere | senator: I like doing this kind of thing with defaults rather than helper functions. <_< |
| # | 17:27:49 | Dyrcona has quit IRC |
| # | 17:44:37 | jenny1 has quit IRC |
| # | 18:10:38 | hopkinsju has quit IRC |
| # | 18:15:16 | sal_ has quit IRC |
| # | 18:32:12 | edoceo has joined #evergreen |
| # | 18:35:59 | graced has quit IRC |
| # | 18:41:35 | graced has joined #evergreen |
| # | 18:45:02 | hopkinsju has joined #evergreen |
| # | 19:31:43 | hopkinsju has quit IRC |
| # | 19:32:53 | wlayton has quit IRC |
| # | 20:11:42 | graced has quit IRC |
| # | 22:07:44 | tsbere_ has joined #evergreen |
| # | 22:08:47 | tsbere has quit IRC |
| # | 22:16:52 | luisb has quit IRC |
| # | 22:34:15 | tsbere_ is now known as tsbere |
| # | 23:03:13 | tsbere_ has joined #evergreen |
| # | 23:04:39 | finnx has quit IRC |
| # | 23:04:52 | tsbere has quit IRC |
| # | 23:32:57 | hopkinsju has joined #evergreen |
April 10-13