| # | Time | Nick | Message |
|---|
| # | 00:26:17 | Dyrcona has quit IRC |
| # | 00:29:20 | pmpafk is now known as pmpcat |
| # | 01:07:29 | darshan has joined #evergreen |
| # | 01:10:46 | darshan | When I am taking reference of any record and importing that record ,I am receiving error mention in 1error.log file, After that when I am placing hold for my patron I am receiving error mention in 2error.log file, Then at time of capturing hold ,I am receiving error mention in 3error.log file. Atlast ,I want to set action trigger and for that I have set hook for hold.available and hold.capture but after doing set up also ,mail is |
| # | 01:11:00 | darshan | the links are-- 1error file-http://www.woofiles.com/dl-272575-iTt6ZCIw-1error.log 2error file-http://www.woofiles.com/dl-272576-q4Ru51P6-2error.log 3error file-http://www.woofiles.com/dl-272577-OxGOv9ye-3error.log |
| # | 01:12:05 | darshan | ne1 plz try to solve it |
| # | 04:10:40 | tfaile_ has joined #evergreen |
| # | 04:10:50 | adrienne_ has joined #evergreen |
| # | 04:11:48 | tfaile has quit IRC |
| # | 04:11:48 | adrienne has quit IRC |
| # | 05:38:42 | darshan | plz ne1 ,plz answer me ,i have been stuck here from last many days |
| # | 06:41:17 | darshan has quit IRC |
| # | 08:02:36 | collum has joined #evergreen |
| # | 08:17:25 | Dyrcona has joined #evergreen |
| # | 08:24:46 | gdunbar has joined #evergreen |
| # | 08:46:58 | Shae has joined #evergreen |
| # | 08:52:47 | bwicksall has joined #evergreen |
| # | 08:54:57 | tater-laptop has joined #evergreen |
| # | 09:00:44 | dkyle has quit IRC |
| # | 09:06:42 | Meliss has joined #evergreen |
| # | 09:31:00 | Meliss has quit IRC |
| # | 09:31:48 | Meliss has joined #evergreen |
| # | 09:32:16 | csharp | errors from Makefile.install for 2.1.1 on debian squeeze: http://pastebin.com/hiQewpcF |
| # | 09:32:47 | csharp | note that this is using my customized PINES repo, but I have not edited Makefile.install |
| # | 09:33:48 | jenny1 has joined #evergreen |
| # | 09:34:51 | dkyle has joined #evergreen |
| # | 09:34:52 | csharp sees that he had the same error with this version of SimpleServer.pm in August: http://open-ils.org/irc_logs/evergreen/2011-08/%23evergreen.23-Tue-2011.log (around 14:04) |
| # | 09:35:37 | tsbere | So SimpleServer setup stinks. Good to know. :P |
| # | 09:35:50 | tsbere | Or you are missing some other dep |
| # | 09:36:47 | csharp | yep |
| # | 09:39:16 | Dyrcona | looks like yaz isn't installed. |
| # | 09:39:31 | Dyrcona | or at least, yaz-dev |
| # | 09:42:17 | csharp | yaz's are installed: http://pastebin.com/XLEL4zzH |
| # | 09:44:17 | Dyrcona | Seach path for SimpleServer must be wrong. |
| # | 09:45:37 | Dyrcona | csharp: I'll bet you have to change -I/usr/local/include to -I/usr/include. |
| # | 09:48:56 | berick | tsbere: btw, the opensrf Perl code does support attaching handlers to app sessions that fire when the session ends (aka death callbacks). i'm still confused why/how the C code doesn't. may be worth pinging eeevil to see if there is something going on with C code that allows us to kill open transactions when a session ends. |
| # | 09:49:32 | tsbere | berick: session->userDataFree |
| # | 09:49:36 | tsbere | So it seems |
| # | 09:49:40 | tsbere | Provided that userData has been set |
| # | 09:49:49 | alynn26 has quit IRC |
| # | 09:50:06 | alynn26 has joined #evergreen |
| # | 09:50:07 | tsbere | Which means if I provide a function for "set audit info" in the cstore/rstore/pcrud code I can ensure userData *is* set |
| # | 09:50:07 | berick | tsbere: aha! |
| # | 09:50:13 | berick | yes, there it is |
| # | 09:50:24 | Dyrcona | csharp: Might also be that SimpleServer has been updated to expect a newer version of yaz. I don't find the missing facet.h in /usr/include/yaz on my Ubuntu system, which is based on debian. |
| # | 09:50:27 | berick sees the rollback in oils_sql.c now |
| # | 09:51:32 | berick | tsbere: you'll have to navigate the fact that userDataFree is already used when in a transaction |
| # | 09:52:10 | csharp | Dyrcona: intresting - I don't see facet.h either |
| # | 09:52:29 | tsbere | berick: No I won't. I plan on adding a "clear audit info" to userDataFree....in general. Regardless. :P |
| # | 09:53:12 | Dyrcona | csharp: If this is a test machine, I'd try removing the yaz packages and installing the most recent yaz from source to see if that helps. |
| # | 09:53:38 | tsbere has not, however, decided how to handle the *set* audit info......he can probably make the SQL query himself, or he can figure out how to json_query it....but *storage* will need one too and doesn't appear to have a json query equiv, and thus needs a manually constructed one anyway..... |
| # | 09:53:45 | Dyrcona | csharp: There is also the possibility that a particular version of SimpleServer is just plain broken. |
| # | 09:54:54 | tsbere | berick: Do you know offhand if I need to add a new call to the "main" storage list of calls when I add it to the Pg driver? (if only as a no-op, I guess) |
| # | 09:55:19 | berick | tsbere: i don't believe so |
| # | 09:56:22 | berick | tsbere: are you globally increasing the number of SQL calls by 200%? :) |
| # | 09:56:51 | berick | well, no |
| # | 09:57:10 | berick | there would be 2 additional calls per transaction or per one-off cstore (etc) query? |
| # | 09:57:48 | tsbere | I plan on adding a "Set SQL Audit" type call to cstore, rstore, and storage. When you disconnect from them I plan on adding a clear audit info call. If you do 9 transactions via one cstoreeditor then I will be hopefully only be adding 2 new sql calls, and one of them will be after you finish. |
| # | 09:58:31 | tsbere | Also, I ran thousands of the calls through paces for testing and didn't hit a full half second. :P |
| # | 09:59:09 | csharp | Dyrcona: I'll try installing yaz from source next |
| # | 09:59:12 | berick takes a step back |
| # | 09:59:24 | berick | tsbere: what happens when a user rolls back a transaction. is the audit info removed? |
| # | 10:00:06 | tsbere | berick: The audit info is nothing more than a couple of variables hiding in the Pg Perl layer so that audit triggers know what user and workstation is doing stuff. |
| # | 10:00:44 | berick | ok, so if the xact is rolled back, no audit table entries are added, so no removal required? |
| # | 10:00:47 | tsbere | Clearing them is because a new client hitting the same cstore/rstore/storage block may not *have* a user/workstation. So on disconnect I clear it. |
| # | 10:02:34 | tsbere runs a 10,000 count "set audit info" run on a VM-based postgres install and is done in 443ms |
| # | 10:03:53 | tsbere | Hmmm. Full get and set run took 1461 ms, that is 10,000 sets and 10,000 gets |
| # | 10:05:13 | berick | how does the audit info get passed to cstore, etc.? |
| # | 10:05:37 | tsbere | I plan on adding a .set_audit_info(authtoken) function to sit alongside things like .transaction.begin |
| # | 10:06:03 | tsbere | Which will require me finding anywhere a transaction.begin is added, for example, and if an authtoken is available I need to pass it on |
| # | 10:06:40 | berick | and then cstore, etc. will call out to open-ils.auth to get the user data from the cache? |
| # | 10:06:49 | csharp | argh - nevermind - this is dependency hell |
| # | 10:07:22 | tsbere | berick: I was thinking I might do something nutty and make cstore and rstore act like they are pcrud for that call ;) |
| # | 10:07:45 | tsbere | storage would, however, do that. Unless I decide to just have whatever has the authtoken pass the user and workstation id numbers through for me. Haven't decided which is easier yet |
| # | 10:07:45 | berick | oh, does pcrud talk directly to the cache? |
| # | 10:07:58 | csharp attempts to push through anyway |
| # | 10:08:02 | tsbere | pcrud requires an authtoken on *every call*, and loads/caches it |
| # | 10:08:43 | tsbere | and pcrud shares the oils_sql.c file with cstore/rstore. So if I make the .set_audit_info call just act like it is pcrud *all the time*.... |
| # | 10:08:54 | berick | right, just wasn't sure if it called out to open-ils.auth or not |
| # | 10:09:01 | tsbere | I believe it does |
| # | 10:09:04 | berick | k |
| # | 10:09:11 | tsbere hasn't decided which method is the better one yet either way |
| # | 10:09:38 | berick | fwiw, i'm more concerned about extra opensrf calls than extra db calls, from the load perspective |
| # | 10:09:49 | berick | passing the values in directly would help that, of course |
| # | 10:10:25 | berick | but, i may be prematurely optimizing |
| # | 10:10:34 | tsbere | I could say "give me an authtoken, a user id, and a workstation id" and then only do the auth lookup if I am pcrud or wasn't given a user id? |
| # | 10:11:06 | berick | yeah |
| # | 10:11:29 | csharp | Dyrcona: installing the newest debs from http://ftp.indexdata.dk/pub/yaz/debian/squeeze/ allowed installation to work |
| # | 10:11:34 | tsbere | pcrud won't be an issue. It needs the token either way, so why trust the provided user id / workstation? |
| # | 10:11:48 | Dyrcona | charp: good to know. |
| # | 10:12:13 | Dyrcona | oops. :0 |
| # | 10:12:27 | berick | agreed re: pcrud |
| # | 10:13:35 | tsbere | actually, I probably won't make pcrud expose the set_audit_info call. Just make it do that transparently. |
| # | 10:17:03 | Dyrcona | For the logs: Looks like these might be a good choice on Ubuntu Lucid http://ftp.indexdata.dk/pub/yaz/ubuntu/10.04/ |
| # | 10:17:21 | Dyrcona thinks he'll try them on his home dev server. |
| # | 10:18:56 | csharp | for the logs, I apt-get removed yaz and libyaz4*, then apt-get installed tcl8.4 libicu-dev libicu44, then installed yaz, libyaz4 and libyaz4-dev |
| # | 10:19:14 | csharp | Dyrcona: however, it was *master* I was testing, not 2.1.1 |
| # | 10:19:28 | csharp didn't check out rel_2_1_1 ;-) |
| # | 10:19:32 | Dyrcona only runs master on dev machine. |
| # | 10:19:35 | Dyrcona | machines. |
| # | 10:19:36 | csharp | good |
| # | 10:20:14 | csharp | I was wondering my my lucid test machine was not barfing in the same way ;-) |
| # | 10:20:58 | Dyrcona | csharp: one of my dev machines has two yaz installations, one in /usr and one in /usr/local, but neither has facet.h. |
| # | 10:21:09 | Dyrcona | it's ubuntu lucid. |
| # | 10:24:37 | yboston has joined #evergreen |
| # | 10:28:45 | csharp | Dyrcona: yeah - what I mean is that I was intending to test 2.1.1 (which I was sucessfully doing on my lucid machine), but I forgot to git checkout the branch on my squeeze one ;-) |
| # | 10:29:06 | Dyrcona | ok |
| # | 10:29:13 | tsbere has failed to elevate a new staff member to staff level in the ILS |
| # | 10:29:20 | csharp lives unwittingly on the bleeding edge |
| # | 10:29:34 | tsbere | We hired someone with multiple family members in our consortia that has no active library card! |
| # | 10:30:31 | Dyrcona | tsbere: I believe that. |
| # | 10:31:42 | Dyrcona plays with his dog for a bit. |
| # | 10:37:37 | dbs has joined #evergreen |
| # | 10:43:17 | Dyrcona | csharp: what version of yaz 4 did you install? |
| # | 10:45:26 | dbs reads scrollback a bit |
| # | 10:45:48 | dbs | master now installs yaz-4 from source + simpleserver 1.15 |
| # | 10:48:25 | dbs | 4.2.17 to be exact - that was what worked with simpleserver 1.15 at the time of installing on debian squeeze when I put the branch together |
| # | 10:49:08 | Dyrcona | dbs: thanks. |
| # | 10:50:52 | csharp | Dyrcona: I installed 4.2.20 (yaz, libyaz4, libyaz4-dev) |
| # | 10:51:18 | Dyrcona | csharp: thanks. I was considering trying that version since it is the latest. |
| # | 10:51:35 | csharp | since I'm on the PINES branch, it's likely that the master there is out of date |
| # | 10:52:02 | Dyrcona puts off playing with yaz. |
| # | 10:53:19 | csharp is initially alarmed to see his G+ friends appear in his pidgin window |
| # | 10:57:59 | dbs would have to lose a lot of weight to fit in there |
| # | 10:58:29 | csharp | ;-) |
| # | 10:59:27 | bshum | Hmm |
| # | 11:00:09 | bshum | SimpleServer seems different than Simple2ZOOM |
| # | 11:00:23 | bshum | Is this something different that ought to be reflected in the z39.50 setup instructions? |
| # | 11:01:40 | bshum | Or you know what, it's probably all different in 2.1+ and I should just go poke at it some more before asking that question :S |
| # | 11:02:11 | Dyrcona | bshum: I still use simple2zoom with master. |
| # | 11:02:32 | Dyrcona | bshum: I believe the simple2zoom instructions still work. |
| # | 11:03:45 | jeff | oh no! we're missing courtesy data for today! -- oh, no. three days from today is thanksgiving. |
| # | 11:04:58 | Dyrcona is finding it tricky to pick up something that he last worked on over a month ago. |
| # | 11:05:07 | dbs | bshum: Simple2ZOOM is the SRU piece, Net::Z3950::SimpleServer is the Z39.50 piece |
| # | 11:05:23 | dbs | (working from memory, so qualify the truthiness appropriately) |
| # | 11:06:59 | bshum | jeff++ |
| # | 11:07:12 | bshum starts to formulate that reply for our libs now... |
| # | 11:07:45 | bshum | Ahh, dbs++ |
| # | 11:07:48 | bshum | That makes sense now. |
| # | 11:08:08 | bshum | I was just peeking to see what we had installed on our z3950 server and got the simpleserver name wrong when checking the module. |
| # | 11:09:59 | Dyrcona | tsbere: is there an easy way to say commit changes I'm making now into a commit four commits back in git? |
| # | 11:10:11 | alynn26 has left #evergreen |
| # | 11:10:19 | tsbere | Dyrcona: Commit to new commit, rebase -i, move line up, set to fixup? |
| # | 11:10:45 | Dyrcona | tsbere: thanks, that's easier than what I was thinking..... |
| # | 11:11:11 | Dyrcona | i figured I have to make an unnamed branch and jump through flaming hoops. |
| # | 11:15:27 | dbs enjoys rebase -i |
| # | 11:16:01 | tsbere enjoys rebase in general ;) |
| # | 11:17:35 | alynn26 has joined #evergreen |
| # | 11:19:51 | tsbere | eeevil: http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/tsbere/auditor_boost if you want to start having people look at the DB side of things ;) |
| # | 11:20:31 | Dyrcona | tsbere: I think that worked. |
| # | 11:38:09 | mrpeters-isl has quit IRC |
| # | 11:44:26 | tspindler has joined #evergreen |
| # | 11:53:33 | tsbere | It is good when you know your editor's command line options :D |
| # | 11:57:28 | berick | tpac/html design question... i'd like to prevent users from re-submitting the credit card payment form. my first thought was to take the user to a "processing.." page after clicking Submit, then submit the form from this new page. |
| # | 11:57:40 | berick | without JS, though, the only way I can think to do that is with a meta refresh that has the form variables all crammed into the refresh URL, which feels a little dirty (though the user would never see it). |
| # | 11:58:18 | dbs | I think at some point JS is reasonable |
| # | 11:58:26 | berick | alternatively, the payment form could exit early with a token, then the UI could poll the backend for sign of completion using the token (also feels dirty) |
| # | 11:58:35 | tsbere | berick: Do we get a server-side session with hidden authtoken and such? If so, jam all the information in *that*, and make the processing page load it from there. |
| # | 11:59:04 | berick | tsbere: aha, yes, we can leverage memcache for such things |
| # | 11:59:07 | tsbere hopes that we aren't persisting *everything* via cookies and parameters |
| # | 11:59:22 | berick | there is no long-standing cached session |
| # | 11:59:31 | berick | apart from the ses cookie itself |
| # | 11:59:39 | tsbere | and what validates the ses cookie? |
| # | 12:01:33 | berick | ses cookie is passed off to open-ils.auth |
| # | 12:01:52 | berick | to validate, retrieve the user object |
| # | 12:02:21 | tsbere | so the ses cookie is the authtoken. Bah. |
| # | 12:02:46 | berick | it's the same cookie all other EG bits use |
| # | 12:02:54 | tsbere | Doesn't mean it is a good one ;) |
| # | 12:03:04 | Dyrcona | what about adding a payment cookie? |
| # | 12:03:29 | tsbere prefers backend session storage that doesn't itself represent things like authentication. Then you can store stuff for people who aren't logged in. |
| # | 12:03:32 | berick | ses cookie should be called auth cookie, that's all it's supposed to be |
| # | 12:04:25 | berick | it's not intended to be a session tracking cookie in the typical web sense.. |
| # | 12:10:26 | berick | tsbere++ thanks for the suggestion, i think that will do nicely |
| # | 12:10:34 | berick will push a collab branch anon |
| # | 12:12:17 | Dyrcona wonders if the above will affect Proxy.pm and his PhoneList.pm web module branch? |
| # | 12:12:21 | berick | dbs: yeah, i was willing to go there, if nothing else to grey out the submit button, but i'll see how this pans out. |
| # | 12:12:34 | berick | Dyrcona: i'm not changing the ses cookie |
| # | 12:12:39 | berick | that's a big project |
| # | 12:13:01 | Dyrcona | ok. good to know. didn't read all of the scroll back. |
| # | 12:13:41 | Dyrcona | or got lost doing other things in between, whatever. |
| # | 12:27:52 | dbs | csharp: good news! ran into the same yaz / simpleserver problem on our debian-squeeze box; will pound on it a bit |
| # | 12:29:00 | dbs | hmm, no "install_yaz" dependency, that seems like a clear issue |
| # | 12:29:34 | dbs | and install_cpan_force happens twice? yeesh |
| # | 12:43:40 | collum has quit IRC |
| # | 12:45:14 | dbs | okay, pushed a fix into master for the yaz / simpleserver issue (for debian and ubuntu) |
| # | 12:46:02 | tsbere dislikes mucking around in the C code |
| # | 12:48:10 | jeff has quit IRC |
| # | 12:54:56 | rogan has joined #evergreen |
| # | 12:59:51 | akilsdonk has joined #evergreen |
| # | 13:05:24 | jeff has joined #evergreen |
| # | 13:05:34 | jeff has joined #evergreen |
| # | 13:06:32 | csharp | dbs: awesome! thanks. |
| # | 13:26:20 | dbs getting lots of "ERROR: set-valued function called in context that cannot accept a set / CONTEXT: SQL statement "SELECT ARRAY_AGG(evergreen.upgrade_list_applied_deprecates(my_db_patch))" errors trying to apply Pg/upgrade scripts |
| # | 13:27:31 | dbs | (as applied by the update_db.sh tool, at least) |
| # | 13:29:18 | tsbere in many ways hates the new system despite never using the update_db.sh tool |
| # | 13:29:33 | tsbere | I end up having to tweak upgrade scripts so frequently it doesn't matter if there is a tool |
| # | 13:30:50 | dbs | maybe needs 0537 fix; will try |
| # | 13:31:37 | dbs | looks like that was the issue. sorry for the noise |
| # | 13:33:18 | dbs | oh. heh |
| # | 13:34:03 | dbs | trying to upgrade a 2.0 system to master just using the upgrade scripts is broken because, of course, there are numbered upgrades that only went into master that predate the current numbers in rel_2_0 |
| # | 13:34:03 | StephenGWills has joined #evergreen |
| # | 13:34:22 | dbs | (e.g. 526, 537, 572, 596)... |
| # | 13:36:38 | dbs | so: 1) use the standard consolidated upgrade scripts to get from 2.0.x to 2.1.x to 2.2.x and then apply atomic upgrade scripts from there, I guess |
| # | 13:46:10 | Dyrcona | berick: You mind if I push a commit to your collab tpac-unadorned-856-record-details-rebase-2 branch that limits the display to 856s with ind1 = 4 and ind2 = 0 or 1? |
| # | 13:47:00 | dbs | Dyrcona: you do that, and then I'll take over the ticket and sign off on both yours & berick's work |
| # | 13:47:05 | berick | Dyrcona: no, please do |
| # | 13:47:12 | Dyrcona | ok. will do. |
| # | 13:51:02 | Dyrcona | pushed. |
| # | 13:55:30 | berick wonders why chrome insists on reloading a page to view source |
| # | 14:16:30 | tsbere | Good sign: My cstore/rstore/pcrud changes compile! No clue if they work yet though. |
| # | 14:25:59 | tsbere | Hmm. At the perl osrf level...what is the difference between a "death" callback and a "disconnect" callback? |
| # | 14:30:03 | berick | tsbere: not sure what the intended difference is, but a death callback will be called even when not inside a stateful (connected) session |
| # | 14:30:31 | tsbere | ok |
| # | 14:31:12 | tsbere | berick: You know if there are any problems with registering multiple death (or disconnect) callbacks at the same time? |
| # | 14:31:34 | bshum | Hmm, anyone have some suggestions about where to start looking for trouble when it comes to the call number shelf browser in the OPAC? I checked the label_sortkey and that looked fine, but items seem to jump ranges without paying attention to the Dewey scheme. |
| # | 14:32:31 | berick | tsbere: should be fine. from the looks of it, though, you can't rely on them being called in the order in which they were added, if that matters |
| # | 14:33:06 | berick is not sure where they are registered as a hash and not an array |
| # | 14:33:39 | tsbere | berick: Don't think it matters much for me. Chances are if they all get called it is going to be during an automatic rollback. |
| # | 14:34:17 | dbs | bshum: it's pretty much all about label_sortkey - with a bit of OPAC visibility mixed in. maybe open a bug with an example list of call numbers and what the label_sortkeys look like and what's getting jumped? |
| # | 14:35:06 | bshum | dbs: It occurred to me to check and it seems we have a mix of different label_class at play with the call numbers. 1 and 2, generic and dewey? |
| # | 14:35:15 | dbs | bshum: sounds like it |
| # | 14:35:46 | dbs | Dyrcona / berick: if a given MARC record contains both an unadorned URI and a located URI, are we expecting to see both URIs in the appropriate scope to see the located URI? |
| # | 14:36:35 | dbs | my gut feel is "if located URI, then skip 'show unadorned URI'" but hey... |
| # | 14:37:05 | berick | dbs: the code appends to the list of URIs to show. it has no effect on when/how located URIs are shown |
| # | 14:37:58 | berick | avoiding display of unadorned URIs when located URIs are present works for me |
| # | 14:38:10 | berick imagines mixing will not be that common anyway |
| # | 14:38:58 | dbs | yeah, my major concern and testcase was to ensure we avoid showing out-of-scope located URIs |
| # | 14:39:05 | gmcharlt rather imagines that mixing will be common |
| # | 14:39:27 | gmcharlt | my preference is that an unadorned URI always display |
| # | 14:39:47 | berick | gmcharlt++ # balancing my uninformed opinion |
| # | 14:40:22 | tsbere | my preference is that the system read the minds of the catalogers entering the URIs. As that is impossible, I will vote for the "always display" view ;) |
| # | 14:41:42 | bshum | dbs: I think you're right about sortkey. I just checked one of the example "problem" records: http://ur1.ca/5zel5 and it has a label_sortkey of "919_800000000000000_ROB" and label_class of 2 (Dewey). |
| # | 14:41:52 | bshum | Might be a local data issue on our end. |
| # | 14:41:55 | dbs | tsbere++ |
| # | 14:42:03 | gmcharlt | tsbere: why are you working on the audit stuff when you could be working the mind reading module? ;) |
| # | 14:42:41 | tsbere | gmcharlt: I don't think I want to know, or have the system attempt to parse, what they are thinking. If only for my sanity and the system's stability. :P |
| # | 14:42:42 | dbs doesn't see much mixing in practice in Conifer and can't think of a reason why mixing would intentionally happen |
| # | 14:43:10 | dbs | "Here's the unproxied URL, go ahead and _try_ to access it, fools!" |
| # | 14:43:45 | dbs | Also, "Here's the unproxied URL, we've helpfully added a public note 'Unproxied URL' so that you'll know that you're not supposed to click it, even though it's highlighted" |
| # | 14:44:12 | gmcharlt smells YAOUS |
| # | 14:44:48 | csharp | YAOUS-irree |
| # | 14:45:27 | gmcharlt | although alternatively a UI on top of the MARC editor that takes over management of URIs (and puts up roadblocks to directly editing the 856) might be the way to make it clear what the actual visibility of a given URI is |
| # | 14:46:35 | csharp | even though the settings interface is an ever-growing monster, I do prefer it to having to grep raw code and track diffs ;-) |
| # | 14:47:52 | dbs | ungh. |
| # | 14:48:13 | dbs | seeing weird inconsistencies between located URI display in JSPac and TPac |
| # | 14:48:20 | edoceo has joined #evergreen |
| # | 14:52:05 | dbs digs back into in-db unapi after a long brain vacation |
| # | 14:54:58 | dbs | hah, <volume opac_visible="true" deleted="true"> |
| # | 14:58:09 | dbs | looks like unapi.bre may get confused by lots of deleted & recreated located uris - which happens anytime you edit a record |
| # | 15:01:27 | dbs | still, that's an issue that's distinct from the code at hand, so I'll push this branch and worry about in-db unapi separately |
| # | 15:14:12 | dbs suspects it's a combo of in-db unapi's "limit to 5 holdings results" default and not taking deleted volumes into account (because who has deleted volumes in their test data?) |
| # | 15:20:03 | bshum | dbs++ #it was call number label_class gunking us up |
| # | 15:20:16 | bshum | When I switched the library's holdings to all 2 for Dewey, things sorted properly again. |
| # | 15:20:35 | bshum | Will just have to run it for all our migrated volumes later on to get everybody on the same page. |
| # | 15:20:36 | bshum | Thanks! |
| # | 15:27:59 | dbs | bshum: yay :) |
| # | 15:28:26 | bshum | Yeah now I just have to find a quiet time to change all the label_class to 2 for over 3.9 million rows, hmm. |
| # | 15:28:33 | bshum | I miss having smaller databases. |
| # | 15:28:54 | bshum | I'm glad that it automatically updated the sortkey values though |
| # | 15:29:43 | dbs | bshum: I don't find those updates to be too heinous. You can always create a script that breaks the updates up into batches of 50,000 or so (WHERE id BETWEEN logic) |
| # | 15:30:15 | bshum | Hmm, true. |
| # | 15:33:18 | tsbere reiterates his dislike of mucking around in the C code as he finds his C code crashing |
| # | 15:33:18 | phasefx | ooh, this is kind of scary. Anyone else getting off by $1 on bill payment receipts? |
| # | 15:33:19 | rogan has quit IRC |
| # | 15:34:11 | phasefx | oh, false alarm. misunderstood what I was looking at (total xacts versus xact of interest) |
| # | 15:34:22 | phasefx wipes forehead |
| # | 15:38:49 | tspindler has quit IRC |
| # | 15:44:04 | dbs | in-db unapi deleted acn issue opened at https://bugs.launchpad.net/evergreen/+bug/893315 |
| # | 15:44:21 | dbs | tsbere: yep. and crashiness generally == exploitability |
| # | 15:44:50 | tsbere | dbs: In this case crashiness = broken code that won't run at all. <_< |
| # | 15:44:55 | tsbere is adding more debugging |
| # | 15:45:09 | dbs | broken code that won't run at all == the most secure code |
| # | 15:46:44 | youdonotexist has joined #evergreen |
| # | 15:46:58 | tsbere | True, but broken code is useless code ;) |
| # | 15:48:59 | phasefx | man, can't even use this code as a paperweight |
| # | 15:49:38 | tsbere | Oh goody, I got it to move one line further than before....but I am not sure what is going wrong now. But I don't think cstore is segfaulting any more. |
| # | 15:51:17 | tsbere is glad he has a quick and easy test case, though.....registering a workstation. <_< |
| # | 15:56:30 | Meliss has quit IRC |
| # | 15:59:44 | tsbere | Combination of "Forgot to osrfAppRespondComplete" and "used single quotes when I needed double quotes" |
| # | 16:03:20 | tsbere | So cstore works (yay!) but I broke pcrud (boo!) |
| # | 16:13:53 | edoceo has quit IRC |
| # | 16:15:24 | dbs about to get a taste of pinned-id medicine with the 2.0->2.1 update for permission.grp_tree |
| # | 16:16:01 | tsbere | :D |
| # | 16:16:12 | tsbere | My checked-in copies have user and workstation IDs in the auditor table :D |
| # | 16:17:09 | dbs notes that permission.grp_tree_id_seq still has last_value of 15 in master, setting future users up for upgrade pain |
| # | 16:20:01 | phasefx is in the camp that upgrade scripts probably shouldn't mess with grp_tree |
| # | 16:21:17 | phasefx | and yet, I've done it (added perms to groups). bleh |
| # | 16:21:54 | dbs still doesn't mind upgrade scripts messing with grp_tree, but 1) we should set the nextval for sequences to a high pinned point in the base schema and 2) we should avoid ids in any case |
| # | 16:21:56 | phasefx cuddles with his hobgoblins |
| # | 16:22:01 | dbs | phasefx++ |
| # | 16:22:33 | phasefx | dbs: did you see this? http://evergreen-ils.org/~phasefx/fix_perms.sql |
| # | 16:23:05 | dbs | mmm, and the FK relationships should probably ON UPDATE CASCADE so it becomes less painful to move existing custom grps out of the way of the bulldozer of standard groups |
| # | 16:23:25 | alynn26 has quit IRC |
| # | 16:23:43 | dbs | phasefx: I did not |
| # | 16:24:19 | tsbere | phasefx: The set id = id + 5000 block I would probably have been lazy and said "where id < 4000" |
| # | 16:25:29 | phasefx | yeah, definitely not the mindset I was in. Made nice use of \o foo.txt and vim |
| # | 16:26:05 | dbs throws "BEGIN; UPDATE permission.grp_tree SET id = id + 100 WHERE id > 5; UPDATE actor.usr SET profile = profile + 100 WHERE profile > 5; UPDATE permission.grp_perm_map SET grp = grp + 100 WHERE grp > 5; UPDATE permission.usr_grp_map SET grp = grp + 100 WHERE grp > 5;" against the wall |
| # | 16:26:43 | dbs | more to update than that but it's a (painful) start |
| # | 16:27:53 | Dyrcona has quit IRC |
| # | 16:28:31 | phasefx | dbs: tsbere: the fix_perms.sql thing, should we throw that into an upgrade script? |
| # | 16:28:58 | tsbere | phasefx: I would prefer you come up with a "stop caring about IDs" branch out ;) |
| # | 16:29:14 | phasefx would prefer someone else do it :) |
| # | 16:29:15 | tsbere | er, butchered that. whatever. |
| # | 16:29:21 | tsbere goes back to fighting with auditing |
| # | 16:34:14 | _bott_ has quit IRC |
| # | 16:35:21 | _bott_ has joined #evergreen |
| # | 16:39:01 | dbs throws https://bugs.launchpad.net/evergreen/+bug/893345 in as a potential stopgap 2.0->2.1 solution |
| # | 16:48:45 | Dyrcona has joined #evergreen |
| # | 16:51:10 | dbs notes to self: set up autodialer to equinox support on turkey day |
| # | 16:54:39 | tsbere | Anyone with more familiarity with the cstore/rstore/pcrud or storage driver want to take a look to make sure I didn't screw up? Tip of http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/tsbere/auditor_boost |
| # | 16:54:55 | tsbere | Things appear to work, but for all I know I missed something important. That I might not even know about. |
| # | 17:05:56 | alynn26 has joined #evergreen |
| # | 17:06:04 | akilsdonk has quit IRC |
| # | 17:06:15 | dbs has quit IRC |
| # | 17:08:52 | Shae has quit IRC |
| # | 17:34:50 | jenny1 has left #evergreen |
| # | 17:37:50 | StephenGWills has quit IRC |
| # | 17:47:30 | bwicksall has quit IRC |
| # | 18:04:27 | finnx has joined #evergreen |
| # | 18:30:54 | pmpcat is now known as pmpafk |
| # | 18:38:12 | alynn26 has left #evergreen |
| # | 18:38:59 | rangi | offtopic, but perhaps interesting for EG users too http://library-matters.blogspot.com/2011/11/plea-for-help-from-horowhenua-library.html |
| # | 18:45:12 | alynn26 has joined #evergreen |
| # | 19:04:59 | granitize has joined #evergreen |
| # | 19:08:11 | granitize has left #evergreen |
| # | 19:11:58 | youdonotexist has quit IRC |
| # | 19:25:56 | csharp | rangi: thanks for sharing - will do my best to broadcast it here |
| # | 19:38:47 | yboston has quit IRC |
| # | 19:48:10 | rangi | csharp: thank you |
| # | 20:01:30 | edoceo has joined #evergreen |
| # | 20:23:51 | wlayton has joined #evergreen |
| # | 21:31:19 | wlayton has quit IRC |
| # | 21:34:03 | denials | rangi: posted http://ur1.ca/5zmyr |
| # | 21:36:09 | rangi | thanks :) |
| # | 21:45:52 | denials | rangi: WTH is going on with NZ? First the bizarre SirsiDynix contract, then granting the trademark on Koha to PTFS - insanity |
| # | 21:46:29 | rangi | yeah, its all a bit of a mystery to me |
| # | 22:11:08 | denials | berick++ # FreeBSDism |
| # | 22:13:12 | Ryan__ has joined #evergreen |
| # | 22:16:21 | Ryan__ | So I had a question...does anyone know, are there plans to create an iOS app version of the evergreen circ ILS software? Is it even possible> |
| # | 22:16:23 | Ryan__ | ? |
| # | 22:16:52 | Dyrcona | Ryan__: It's possible, but as far as I know, no plans. |
| # | 22:20:02 | Dyrcona | Ryan__: As far as possible goes, it would likely need to be a reimplementation and not necessarily a port. |
| # | 22:30:15 | Ryan__ has quit IRC |
| # | 22:31:37 | bshum | Hmm |
| # | 22:35:36 | Dyrcona | bshum: ? |
| # | 22:35:58 | bshum | Dyrcona: Don't mean to bug you on your holiday, but do you know what the heck an "un-targeted expiration" is? For holds. |
| # | 22:36:13 | bshum | I'm searching the code to find out where that's coming from |
| # | 22:36:42 | Dyrcona | No, actually, I don't. |
| # | 22:36:59 | bshum | Alternatively, it seems that a slew of holds came up with expiration dates of years ago, and expired almost as quickly as they were placed. |
| # | 22:37:15 | bshum | So like something placed on 11/15 and canceled less than a second later on the same day |
| # | 22:37:21 | bshum | But the expire date was like 7/4/07 |
| # | 22:37:25 | bshum | Four years ago? |
| # | 22:37:36 | Dyrcona | Were these migrated? |
| # | 22:37:36 | bshum | But we weren't using Evergreen then... so very mysterious. |
| # | 22:37:51 | bshum | No, they weren't migrated. |
| # | 22:37:55 | Dyrcona | Do you have a migration going on right now? |
| # | 22:38:01 | bshum | Hmm |
| # | 22:38:05 | bshum | We did have a migration |
| # | 22:38:09 | bshum | Last week |
| # | 22:38:22 | bshum | And holds were one of the migrated pieces of data |
| # | 22:38:24 | Dyrcona | Maybe these were old holds that got moved over? |
| # | 22:38:26 | bshum | But this is from a live library |
| # | 22:38:32 | Dyrcona | oh. |
| # | 22:38:57 | bshum | Yep. Truly mysterious. |
| # | 22:39:25 | bshum | But I figure I should try to determine what a cancel cause of "1" was, which is "untargeted expiration" |
| # | 22:39:37 | bshum | I assume that's some sort of Evergreen lingo for a hold that took too long to fill. |
| # | 22:39:50 | bshum | Course I'm not sure why that happened to begin with |
| # | 22:40:05 | bshum | Seems unlikely for a staff to place a hold with an expire date years before they placed the hold. |
| # | 22:40:13 | bshum | But the staff keenly remember placing the hold. |
| # | 22:40:16 | bshum | Very strange. |
| # | 22:40:24 | Dyrcona | Bad clock on the client. |
| # | 22:40:34 | bshum | That's what I was thinking |
| # | 22:40:38 | bshum | Though I'm sure they won't like that. |
| # | 22:40:51 | Dyrcona | I'd have them check the system date. |
| # | 22:40:53 | bshum | I imagine the log might say something about what action was taken. |
| # | 22:42:10 | Dyrcona | These were placed on the 15th? |
| # | 22:42:16 | bshum | Yes |
| # | 22:42:38 | Dyrcona | So, the computer will likely think it is the 12th of July 2006 tomorrow. |
| # | 22:42:54 | Dyrcona | Or the 11th.... |
| # | 22:43:56 | bshum | request_time of 2011-11-15 15:15:59.006255-05, cancel_time of 2011-11-15 15:15:59.300228-05 |
| # | 22:43:59 | bshum | So less than a second? |
| # | 22:44:49 | Dyrcona | Yeah, about 294 milliseconds. |
| # | 22:55:07 | bshum | Heh |
| # | 22:55:25 | bshum | 1970-06-29 00:00:00-04 was the expire_time for several holds that have cancel_cause of 1 |
| # | 22:55:37 | bshum | We definitely weren't running Evergreen then :) |
| # | 22:56:00 | Dyrcona | negative expiration date. :) |
| # | 22:56:31 | Dyrcona | well, not negative, just very small. |
| # | 22:57:12 | Dyrcona | when were the 1970 expiration holds created? |
| # | 22:58:14 | bshum | Hmm, 2011-06-18 |
| # | 22:58:32 | bshum | *after* our Horizon migration |
| # | 22:58:58 | bshum | Weird. |
| # | 22:59:16 | Dyrcona | do they have anything else in common, like being created at the same ou, by the same requestor or for the same usr? |
| # | 22:59:22 | bshum | Yeah |
| # | 22:59:31 | bshum | They were all placed by the same library for a patron of another lib it seems |
| # | 22:59:42 | bshum | The timestamps for the request_time are a few minute apart |
| # | 22:59:53 | bshum | My guess is that the library was re-entering holds for the patron |
| # | 23:00:28 | Dyrcona | or they wanted them to expire if not filled in 10 days and didn't add a year? |
| # | 23:00:49 | Dyrcona tries entering an odd date on his dev server. |
| # | 23:01:08 | bshum | Oh I see what you're saying |
| # | 23:01:10 | bshum | Hmm |
| # | 23:03:42 | Dyrcona | I just tried placing a hold with "12/22" as the expiration date, and it says 11/20/2012 in the OPAC as the expiration date. |
| # | 23:03:58 | bshum | So maybe they placed the hold, fiddled with the expire_time wrong and it killed their holds moments after placing them? Not enough time in the milliseconds between it seems. |
| # | 23:04:25 | Dyrcona | The timing suggests a trigger or action trigger running. |
| # | 23:04:41 | bshum | Hmm |
| # | 23:04:50 | Dyrcona | I'm inclined to blame a bad clock on the client. |
| # | 23:04:51 | bshum | Ooh, you can key in expiration date |
| # | 23:04:59 | Dyrcona | yes. |
| # | 23:05:00 | bshum | Didn't realize that |
| # | 23:05:08 | bshum should probably use Evergreen more often... |
| # | 23:05:23 | bshum | I wonder if that would kill it |
| # | 23:05:32 | Dyrcona | That's what I did to put in "12/22". |
| # | 23:05:32 | bshum | Placing a hold on an item with a date in the past |
| # | 23:05:41 | bshum | The hold would try to trigger immediately and die |
| # | 23:06:03 | Dyrcona | yep. |
| # | 23:06:12 | bshum | Not sure if our hold expire interval of 180 days would kill any holds placed wrongly like that. |
| # | 23:06:17 | Dyrcona | I entered "12/22/70" and my hold says it is expired. |
| # | 23:06:25 | bshum | That would do it then. |
| # | 23:06:37 | Dyrcona | Ours is set to 1 year. |
| # | 23:07:15 | Dyrcona | I think if it can't parse the date ("it" being Dojo) then you get a default, but if dojo can parse a date, it will send it to the backend. |
| # | 23:07:30 | bshum | Peachy |
| # | 23:07:52 | bshum | I feel like this is worthy of a bug ticket |
| # | 23:08:00 | bshum | That someone shouldn't be able to create a hold that expires in the past. |
| # | 23:08:09 | bshum | A new hold I mean |
| # | 23:08:19 | bshum | If they edit it into the past well... that's a different problem |
| # | 23:09:03 | Dyrcona | Well, you can only do so much to protect people from themselves. |
| # | 23:09:19 | bshum | That much is true. |
| # | 23:09:33 | bshum | Well I feel slightly better about all this now :) |
| # | 23:09:34 | Dyrcona | However, stopping a new hold from having a backdated expiration is really no easier than doing that for editing, too. |
| # | 23:10:05 | bshum | Dyrcona++ |
| # | 23:10:10 | Dyrcona | check the patron's birthday in either case? |
| # | 23:10:11 | bshum | Maybe I'll poke at bug writing tomorrow. |
| # | 23:10:16 | bshum | Hmm |
| # | 23:10:58 | Dyrcona | might be something that happened with a newly registered patron and their birthdate. However, I question a 4 year old using the library with their own card. :) |
| # | 23:11:08 | bshum | No DOB |
| # | 23:11:21 | bshum | For the patron that had the expire date of 1970 |
| # | 23:11:25 | Dyrcona | Well, its not likely that then. |
| # | 23:11:39 | bshum | *hold expire date, rather |
| # | 23:11:47 | bshum | Oh well. |
| # | 23:11:52 | bshum | Thanks Dyrcona |
| # | 23:11:57 | bshum | Dyrcona++ |
| # | 23:12:01 | Dyrcona | yw. |
| # | 23:15:57 | Dyrcona goes to bed. |
| # | 23:56:08 | bshum | @later tell dbs Didn't see your notes from the last meeting, but read through the IRC log to start dev-meeting agenda for tomorrow - http://evergreen-ils.org/dokuwiki/doku.php?id=dev:meetings:2011-11-22 |
| # | 23:56:08 | pinesol_green | bshum: The operation succeeded. |
April 10-13