| # | Time | Nick | Message |
|---|
| # | 00:37:10 | dbs has quit IRC |
| # | 07:28:04 | sfortin has joined #evergreen |
| # | 07:53:23 | granitize has joined #evergreen |
| # | 08:29:42 | AaronZ has joined #evergreen |
| # | 08:44:19 | Dyrcona has joined #evergreen |
| # | 08:55:57 | dbwells has quit IRC |
| # | 08:56:27 | rsinger has quit IRC |
| # | 09:02:12 | sugubo has joined #evergreen |
| # | 09:03:08 | sugubo has quit IRC |
| # | 09:06:13 | Meliss has joined #evergreen |
| # | 09:11:37 | gdunbar has joined #evergreen |
| # | 09:24:14 | rsinger has joined #evergreen |
| # | 09:30:59 | jenny has joined #evergreen |
| # | 09:35:03 | bshum has joined #evergreen |
| # | 09:44:49 | dbs has joined #evergreen |
| # | 09:47:19 | gavv\w has joined #evergreen |
| # | 09:51:32 | bshum | Hmm |
| # | 09:52:09 | bshum | We just upgraded to 1.6.1.3 and when trying to check in/out books, it's asking us for a "CAPTURE_RESERVATION" permission. |
| # | 09:52:41 | bshum | Is this somehow tied to circulation now, even though we're not checking in/out items that are "bookable"? |
| # | 09:54:50 | senator | i think something that fixed that might not have been backported from trunk when it should have been. looking. |
| # | 09:55:55 | cerpy has joined #evergreen |
| # | 09:57:09 | bshum | Oh, interesting. Booking permissions were added to the circulator permission group, but not the others. That would explain why that worked for some staff accounts and not others. |
| # | 09:59:05 | eby_ has joined #evergreen |
| # | 09:59:08 | dbs | bshum: Makes sense to me. I suppose we could have added it to Staff instead of Circulator, but check in/out seems pretty circulatory to me |
| # | 09:59:23 | dbs | (and can't really anticipate custom permission groups) |
| # | 09:59:35 | bshum | dbs: Agreed, we have strange combined staff accounts with cross-permissions. |
| # | 09:59:55 | bshum | I guess we just weren't sure that the new booking permissions had to be granted to staff in order to check in/out |
| # | 10:00:26 | eby has quit IRC |
| # | 10:00:26 | eby_ is now known as eby |
| # | 10:01:20 | yboston has joined #evergreen |
| # | 10:02:00 | senator | so looking back, i have no idea why i didn't backport r17447 all the way to rel_1_6. that commit removed all checks for CAPTURE_RESERVATION and replaced them with checks for COPY_CHECKIN |
| # | 10:02:28 | dbs | senator++ # even better |
| # | 10:02:39 | eeevil | 1.6.1.4 coming soon, I guess :) |
| # | 10:02:40 | senator | under the reasoning that's there is no such permission as "CAPTURE_HOLD", so why should there be one for reservation, especially since capturing is supposed to be able to happen from the checkin interface |
| # | 10:02:46 | senator | yeah backporting :-/ |
| # | 10:02:58 | bshum | Whee |
| # | 10:03:44 | senator | for a hotfix, it'll only be a patch to booking.pm, and you might restart your open-ils.booking service. *shrugs* :-( |
| # | 10:04:01 | dbs | bshum: did you check to see if that reporter problem affected 2.0 as well? |
| # | 10:04:15 | bshum | dbs: I did not yet, but I can check that real quick on our beta1 server. |
| # | 10:04:25 | dbs | bshum: would be good |
| # | 10:04:28 | eeevil | dbs: I'm sure it does. I'll be looking at that |
| # | 10:04:50 | dbs | eeevil: okay, cool |
| # | 10:05:13 | eeevil | s/I'll be/I'm/ |
| # | 10:06:25 | eeevil | hrm... odd |
| # | 10:11:24 | eeevil | well... the intention of r18472 is obvious enough -- capture more information about the template and report params ... the implmentation is faulty, though. I'll do it right |
| # | 10:14:14 | dbs | b2 will be the better for it :) |
| # | 10:15:33 | eeevil | indeed |
| # | 10:15:49 | eeevil | plan to cut today unless there are loud protestations |
| # | 10:17:39 | bshum | dbs: Confirmed the same problem exists on b1 |
| # | 10:17:43 | bshum | For report running |
| # | 10:19:36 | dbs | bshum: yeah, eeevil just fixed it :) thanks man! |
| # | 10:21:15 | bshum | dbs: Glad to help where we can. |
| # | 10:21:44 | dbs | any other known problems with 2.0 / beta1 that haven't been resolved? https://launchpad.net/evergreen/+milestone/2.0beta2 is all I'm aware of |
| # | 10:24:34 | berick | re: known issues, i think the vandelay UI needs updating to support the updated holdings import back-end |
| # | 10:25:06 | berick | that's the last thing i keep meaning to knock out |
| # | 10:26:20 | dbs | hmm. I was just happy that my Vandelay imports (auth and bibs, simultaneously!) worked last night without the bad crashies that had been happening in the last couple of releases |
| # | 10:27:29 | dbs | working++ |
| # | 10:29:14 | berick | indeed |
| # | 10:32:45 | parsr has joined #evergreen |
| # | 10:42:43 | parsr | dbs: Translations > what happens to translated text like this one http://tinyurl.com/33osy2g where "No translations yet" but where translation is suggested (but still needs to be double checked). I take it we'd see the text still in English in fr-CA, correct? We're having many sections sent out to prof translators but context of course is not always apparent (especially for non Librarian... |
| # | 10:42:45 | parsr | ...translator). Just debating whether or not to push through translations that were flagged as "double check" versus leave them as "No translation yet" status. |
| # | 10:44:14 | eeevil | anyone interested in https://bugs.launchpad.net/evergreen/+bug/663965 ... is this still exhibited by b1? |
| # | 10:44:31 | eeevil | (if anyone has time to test) |
| # | 10:47:08 | bshum | I can try testing that to see what it looks like. |
| # | 10:51:43 | bshum | Well, I don't have a fresh database though, hmm |
| # | 11:07:15 | rickd_ has joined #evergreen |
| # | 11:09:39 | dbs | eeevil: that's what I was saying is no longer happening in trunk |
| # | 11:09:53 | dbs | e.g. vandelay works |
| # | 11:10:33 | dbs | parsr: unknown - I just pushed the most recent translation updates into 2.0 Saturday, IIRC, so we could check to see what happened there |
| # | 11:12:40 | cerpy has quit IRC |
| # | 11:12:53 | dbs | parsr: okay, saw what you linked to. That would indeed come through with English. |
| # | 11:13:23 | dbs was, ironically, busy doing homework for his french calss |
| # | 11:13:33 | dbs | (and now apparently needs english class as well) |
| # | 11:13:42 | bshum | eeevil: Importing into our b1 test system seemed to work alright. I was able to import the oss.marc files into our server. Course ours is non-empty. |
| # | 11:13:56 | bshum | I can re-test with an empty server, but it should work either way right? |
| # | 11:16:40 | dbs | bshum: the empty server part doesn't matter, we can mark it as "Fix released" in beta1 |
| # | 11:17:00 | bshum | Sounds good to me. |
| # | 11:17:02 | bshum | :) |
| # | 11:17:26 | dbs | (probably should have marked it as "fix committed" when eeevil committed his patch but we're up to date now) eeevil++ # for the fix |
| # | 11:18:24 | eeevil | bshum / dbs: thanks for checking |
| # | 11:18:59 | dbs | parsr: so I guess the question is whether "Something French but possibly incorrect" is worse than "Something English". I think people are (sadly) used to the former, and at least it gives them a chance at guessing what was intended if they're a completely non-English speaker |
| # | 11:21:39 | eeevil | dbs: agreed, fwiw ... I'd rather have a (possibly, mildly confusing) translation than none, given a product in not-english that I wanted to use |
| # | 11:27:37 | jenny has quit IRC |
| # | 11:31:21 | moodaepo | If I run eg_db_config.pl it should restore the db to clean state correct? (moving from a5 to b1) |
| # | 11:31:37 | bshum | eeevil: I thought 1.6.0.9 was the end of the line. .10? |
| # | 11:33:26 | bshum | moodaepo: I think so |
| # | 11:33:49 | bshum | That's what Dyrcona seems to indicate with this paste last week: http://paste.lisp.org/display/116518 |
| # | 11:34:26 | eeevil | bshum: because there are at least 2 bugs fixed since 1.6.0.9 ... the reporter being one of them. I could be convinced to not release 1.6.0.10, of course |
| # | 11:34:57 | bshum | eeevil: I was just wondering. Not that I mind there being more 1.6.0.x |
| # | 11:35:38 | gmcharlt | the reporter glitch is pretty visible - I'd prefer that there be a 1.6.1.10, since 1.6.0.9 has been out and downloaded for a few days now |
| # | 11:36:06 | gmcharlt | but after that, hopefully .10 can be the end of the line unless somebody else wants to adopt rel_1_6_0 |
| # | 11:39:47 | moodaepo is guessing gmcharlt meant he prefers there be a 1.6.0.10 (not 1.6.1.10) |
| # | 11:40:08 | moodaepo | Not that one day we won't have one of those : ) |
| # | 11:40:32 | moodaepo | By the way b1 still has the dojo issue |
| # | 11:40:34 | bshum | moodaepo: What are you talking about? We're all upgrading to 2.0 next week man! |
| # | 11:40:58 | moodaepo | i,e, ln -s tundra |
| # | 11:41:08 | moodaepo | bshum++ |
| # | 11:41:17 | bshum | moodaepo: I think we were pointing folks to the fix in Launchpad and having that be part of b2, but someone can refresh my memory. |
| # | 11:41:32 | moodaepo just wanted to make a note |
| # | 11:44:58 | brian_f has joined #evergreen |
| # | 11:46:27 | eeevil | I'll grab some lunch, then cut b2 unless there are objections or pending last-minute fixes. |
| # | 11:55:15 | moodaepo | eeevil: https://bugs.launchpad.net/evergreen/+bug/663965 Seems to have been fixed but for some reason 5 of the records from oss.marc keep getting imported even though they already exist. |
| # | 11:57:05 | parsr | dbs: thanks.. we'll have a record of items of concern and agree with eeevil's assessment that it's better to have something rather than not - so more of the 'double-check' ones to be pushed through. What I'd really like to do post-version 2.0 is to have more thorough "in-context" review of the translations. Also helpful will be to have additional bilingual partners coming on board next year... |
| # | 11:57:07 | parsr | ...to help with this (talking to 2 other fed departments of interest) |
| # | 12:00:05 | eeevil | moodaepo: I suspect that those 5 records do not have TCN (or otherwise) usable identifiers. the algo for finding existing records is weak at best, an area I hope can be improved soon-ish. |
| # | 12:01:42 | moodaepo | eeevil: Will do. While I'm at it I hate how we allow a "blank" named queue in the batch import, should probably write it up on launchpad if it's not already there : ) |
| # | 12:02:16 | moodaepo | s/hate/am irked/ |
| # | 12:02:25 | bshum | moodaepo: Agreed with you on that one. Took me awhile to figure that out during my testing :( |
| # | 12:08:51 | jenny has joined #evergreen |
| # | 12:36:49 | AaronZ has quit IRC |
| # | 12:43:19 | parsr has quit IRC |
| # | 12:48:39 | moodaepo | eeevil: I'd mentioned it late Friday evening any thoughts? > (17:30:35) moodaepo: So after loading records using "MARC Batch Import/Export" in the client it seems like the quality & fingerprint are not being created/loaded. So I'm guessing another 1.6.1.3 bug it could be the 1.6.1 branch bug. |
| # | 12:49:04 | moodaepo | bshum: Did you upgrade to 1.6.1.3 yesterday? |
| # | 12:49:18 | bshum | moodaepo: Yes, we upgraded to 1.6.1.3. |
| # | 12:50:19 | moodaepo | Could you try this MARC batch import? I used Open-ILS/tests/datasets/oss.marc set of MARC records and imported only the first two |
| # | 12:51:09 | moodaepo | bshum: Then looked at the imports in biblio.record_entry |
| # | 12:51:24 | moodaepo will go get some lunch now |
| # | 12:51:37 | bshum | moodaepo: I'll give that a try after lunch as well. |
| # | 12:51:47 | bshum | moodaepo: On our test server of course |
| # | 12:51:54 | moodaepo | Will do. |
| # | 12:52:15 | bshum | 1.6.0.x is dead to me now. |
| # | 12:52:35 | bshum off to lunch! |
| # | 12:52:45 | eeevil | moodaepo: I haven't looked at that yet. you have fingerprint_tgr on biblio.record_entry? |
| # | 12:56:47 | bshum | Okay I lied |
| # | 12:56:53 | bshum | I tried it instead of going to lunch |
| # | 12:56:59 | bshum | Import went fine as far as I can tell |
| # | 12:57:11 | bshum | The fingerprint field is empty for the records though |
| # | 12:58:11 | eeevil | do those records not have what's needed per select * from config.biblio_fingerprint; |
| # | 12:58:14 | eeevil | ? |
| # | 12:58:47 | bshum | That table does not exist. |
| # | 12:58:56 | eeevil | um ... |
| # | 12:59:04 | bshum | Are we having a 1.6 vs 2.0/trunk issue? |
| # | 12:59:45 | bshum | Or is my database bad :( |
| # | 12:59:48 | eeevil | oh, sorry, I thought moodaepo was talking about a 2.0/trunk issue with fingerprints |
| # | 13:00:16 | bshum | Ah, no, we're working with 1.6.1.3 |
| # | 13:00:24 | bshum | Or rather, that's what he was last asking me about. |
| # | 13:00:29 | eeevil | I haven't look at 1.6 at all for that, sorry ... |
| # | 13:00:31 | bshum | We're doing it all because we're awesome like that. |
| # | 13:00:39 | eeevil goes back to the beta salt mines ;) |
| # | 13:00:41 | jamesrf has joined #evergreen |
| # | 13:00:46 | bshum | Hehe |
| # | 13:01:01 | bshum | I have a VM Ubuntu ready to start loading b2 when it's ready |
| # | 13:01:08 | bshum | But after lunch |
| # | 13:01:14 | bshum | Which I shall actually go to get now... |
| # | 13:11:09 | phasefx | brian_f: still up for packaging the client once eeevil cuts the next beta? |
| # | 13:11:40 | brian_f | Yep, I'm up for packaging it. |
| # | 13:12:39 | phasefx | rock |
| # | 13:15:49 | eeevil taps fingers for i18n build |
| # | 13:16:54 | eeevil | too bad there's serialized bits in i18n build (ils_events.xml, fieldmapper) ... with 15 translations, it's a slog |
| # | 13:21:26 | rjackson-isl has joined #evergreen |
| # | 13:21:55 | phasefx | brian_f: updated http://evergreen-ils.org/dokuwiki/doku.php?id=scratchpad:packaging_the_staff_client_for_windows |
| # | 13:26:23 | dbs | if anyone wants to rewrite the i18n build, they're welcome to it |
| # | 13:27:12 | dbs | the slog wouldn't be such an issue if an automated build process existed, though, so I'd suggest energy focus on recreating that if any volunteers were about to throw their hat in the ring :) |
| # | 13:29:44 | dbs | moodaepo: another piece of fodder for website consideration: http://opensource.com/business/10/11/avoid-tool-trap-when-building-communities |
| # | 13:30:16 | dbs | (thanks for your response to my feverish missive, btw - much appreciated) |
| # | 13:38:05 | bshum | So here's a fun one |
| # | 13:38:17 | bshum | We're trying to save a new action/notification event definition |
| # | 13:38:30 | bshum | And it's clearly incrementing the event_definition_id_seq |
| # | 13:38:35 | bshum | But nothing is happening on the screen. |
| # | 13:38:45 | bshum | It just sits there and nothing gets entered on the table. |
| # | 13:39:02 | bshum | Saving it through the staff client I mean. |
| # | 13:40:40 | tsbere | bshum: In my experience, the sequence can be updated in a transaction block that gets a rollback and will stay incremented, so that just means it is trying. That is intended to that different transactions can enter data and not step on each other at commit, if I am not mistaken. |
| # | 13:40:57 | bshum | tsbere: Right, that's my guess as well. |
| # | 13:42:21 | eeevil | tsbere/bshum: that's how sequences work, yes. they don't give values back |
| # | 13:42:51 | bshum | So for some reason then, I guess our attempts to save a new event definition is failing, hmm |
| # | 13:43:21 | eeevil | bshum: the pg logs should tell you why |
| # | 13:43:46 | bshum | eeevil: Thanks for the helpful hint! I'll take a peek at those... |
| # | 13:47:52 | afterl has joined #evergreen |
| # | 13:55:05 | eeevil | beta2 is up at the usual place, including dbs-style changelog (ChangeLog-2.0-beta2) |
| # | 13:56:42 | phasefx | eeevil++ |
| # | 13:56:47 | phasefx | brian_f: http://evergreen-ils.org/downloads/Evergreen-ILS-2.0-beta2.tar.gz let me know if you run into any issues, and thanks! |
| # | 14:34:07 | bshum | Well, apparently there was something wrong with the event we were trying to clone. Seems to be working now for us as far as adding new event definitions. |
| # | 14:34:11 | bshum | though we can't seem to see them. |
| # | 14:36:10 | Stompro has quit IRC |
| # | 14:53:00 | jamesrf has quit IRC |
| # | 15:10:16 | moodaepo | bshum: Want me to try your issue on our install? |
| # | 15:10:44 | bshum | moodaepo: If you have time |
| # | 15:10:56 | bshum | moodaepo: I'm happy we're able to add new definitions, or clone them. |
| # | 15:11:09 | bshum | Editing them in the DB afterwards isn't as burdensome as building them from scratch every time. |
| # | 15:11:22 | moodaepo | So what's the issue, it just doesn't list? |
| # | 15:11:32 | bshum | It's listing things, but we're not seeing some of them. |
| # | 15:11:44 | bshum | Also, I'm seeing some paging issues where the last entry on the list doesn't show up properly |
| # | 15:11:48 | bshum | Due to how things are framed |
| # | 15:22:15 | mjgiarlo has quit IRC |
| # | 15:22:47 | mjgiarlo has joined #evergreen |
| # | 15:29:03 | Dyrcona | Weird: I loaded the database on an EG install on a virtual machine from a dump of our main EG install, and I can't login to the EG on the virtual machine with the client. It gives me the standard check server, username, and password dialog, even after deliberately setting the passwd in actor.usr. |
| # | 15:29:38 | bshum | Uh oh |
| # | 15:29:42 | Dyrcona | I did the usual autogen, and restarted all osrf services and apache after loading the dump. |
| # | 15:29:50 | bshum | Did you check via srfsh? |
| # | 15:29:51 | Dyrcona will try memcached. |
| # | 15:30:56 | Dyrcona will try srfsh, thanks, bshum. |
| # | 15:33:50 | moodaepo | eeevil: Ah I do not see a fingerprint_tgr in biblio |
| # | 15:34:40 | moodaepo | Dyrcona: Just checking..you have the correct client version right? |
| # | 15:34:41 | Dyrcona | Received no data from server |
| # | 15:34:50 | Dyrcona | from srfsh. looks like something is not running. |
| # | 15:36:31 | Dyrcona | Should there be an open-ils.auth OSRF drone running? |
| # | 15:37:09 | dmc1861 has joined #evergreen |
| # | 15:38:05 | csharp | Dyrcona: as far as I know, there should be (remembering "cannot communicate with open-ils.auth service" msgs...) |
| # | 15:38:46 | Dyrcona | csharp: thanks. I just checked the server that is working. It has open-ils.auth running, the one that doesn't work, doesn't. |
| # | 15:38:59 | Dyrcona goes to figure out why open-ils.auth isn't running. |
| # | 15:39:15 | csharp | weird |
| # | 15:41:21 | Dyrcona | Doesn't look like the OpenSRF C services are starting. |
| # | 15:41:29 | Dyrcona | Going to dig into logs, etc. |
| # | 15:43:12 | dbs | Dyrcona: opensrf-c is getting the correct hostname? |
| # | 15:43:20 | Dyrcona leaves it for tsbere to fix tomorrow morning. Looks like the virtual host is confused about it's hostname. |
| # | 15:43:29 | Dyrcona | dbs++ |
| # | 15:44:15 | bshum | moodaepo: Yeah that fingerprint thing is weird. |
| # | 15:45:30 | bshum | moodaepo: What exactly are we trying to do (or not do) with the batch loader? |
| # | 15:46:25 | dbs | phasefx: you've got the Google CSE key, right? Care to share it in an attempt to address whatever resources we're missing that rsoulliere wants added? |
| # | 15:46:36 | moodaepo | bshum: I will need to setup a stable server and see what the logs say for a proper import. |
| # | 15:48:35 | moodaepo | dbs: Thanks for the link, I'll pass it around the WIG. Also I'm anti-oblique language but didn't put up any resistance so apologies to everyone : ) |
| # | 15:49:18 | phasefx | dbs: I believe you and jeff should be admins for it. looking |
| # | 15:51:24 | dbs | phasefx: I only see my LU library site :) |
| # | 15:51:53 | phasefx | dbs: ah, pending registration it says for you |
| # | 15:52:06 | phasefx resends |
| # | 15:52:52 | dbs | moodaepo: it's ironic that the communications of the Communications Committee confuses me. heh |
| # | 15:53:00 | dbs | phasefx++ # persistence! |
| # | 15:53:04 | moodaepo | dbs++ |
| # | 15:53:59 | moodaepo yells it's a freakin committee man a COMMITTEE |
| # | 15:54:28 | dbs | moodaepo: Greg deKoenigsberg's comment on that blog entry is super-relevant too - and one thing that I think we've done reasonably well so far (archiving decisions and history), particularly since the IRC channel started getting logged |
| # | 15:54:55 | agJohn has joined #evergreen |
| # | 15:55:42 | bshum | moodaepo: Here's a fun one for you later. We're importing records in through z39.50 and none of them show up in the catalog search results :) |
| # | 15:56:35 | moodaepo | bshum: Probably the same reason |
| # | 15:56:46 | bshum | moodaepo: Yay :S |
| # | 15:57:17 | dbs | bshum: b2? |
| # | 15:57:30 | bshum | dbs: Live 1.6.1.3 upgrade |
| # | 15:57:41 | dbs | bshum: aughity |
| # | 15:57:42 | bshum | People are using it today so we're unraveling all the bugs |
| # | 15:58:13 | bshum | Making a list as I go to report on things |
| # | 15:58:37 | bshum | Fairly chaotic though |
| # | 15:58:38 | dbs adds an agenda item for tomorrow's meeting: How do we improve QA for point releases? |
| # | 15:58:49 | bshum | Wish I had chosen 1.6.1.2 or some other more tested release |
| # | 15:59:10 | rjackson-isl has quit IRC |
| # | 15:59:14 | moodaepo | I didn't even test 1.6.1.2 : ( |
| # | 15:59:15 | dbs | although an open-ended topic like that's not going to fit into a half-hour meeting primarily meant to focus on 2.0 release coordination |
| # | 16:00:07 | moodaepo | Jumped straight over to 1.6.1.3 (of course it is an odd numbered release so has to be unstable) |
| # | 16:00:11 | Meliss has quit IRC |
| # | 16:02:17 | bshum | Ha |
| # | 16:03:19 | dbs | Create tarball; push to demoXYZ.evergreen-ils.org test server; load test data and known configuration; give people a chance to hammer on a checklist of standard tasks for a day or two; then publish the release? |
| # | 16:03:36 | dbs | (assuming no brown-paper bag bugs of course) |
| # | 16:04:33 | sfortin has quit IRC |
| # | 16:04:52 | drv_ has joined #evergreen |
| # | 16:08:00 | bshum | moodaepo: To follow up, looks like you're right about the fingerprint not being generated for the newly imported records via z3950 |
| # | 16:08:44 | bshum | moodaepo: I assume that metabib creation is borked for it not to be generating any search results. Checking on that next |
| # | 16:08:46 | moodaepo | Yea I checked that and am actually digging through the logs |
| # | 16:13:05 | csharp | dbs: which blog post are you referencing above? |
| # | 16:13:57 | csharp cannot find it in scrollback ;-) |
| # | 16:15:45 | dbs | csharp, another piece of fodder for website consideration: http://opensource.com/business/10/11/avoid-tool-trap-when-building-communities (from 13:29) |
| # | 16:16:47 | dbs | good news, everybody! http://evergreen-ils.org/downloads/OpenSRF-ChangeLog-2.0.0-beta1 http://evergreen-ils.org/downloads/opensrf-2.0.0-beta1.tar.gz |
| # | 16:16:47 | csharp | dbs: excellent - thanks |
| # | 16:17:23 | csharp named one of his test servers 'farnsworth' |
| # | 16:17:59 | csharp | oh wait - that's OpenSRF! |
| # | 16:18:04 | csharp | cool! |
| # | 16:18:09 | moodaepo | csharp++ |
| # | 16:19:07 | dbs | csharp++ |
| # | 16:19:10 | bshum | moodaepo: Yep, searched metabib tables for entries related to the newly imported bibs and found either nothing or junk |
| # | 16:19:16 | bshum | A few keyword entries that made no sense |
| # | 16:19:21 | bshum | No titles, no authors |
| # | 16:19:30 | csharp | reading_carefully++ |
| # | 16:19:52 | dbs | farnsworth++ blowing_things_up++ blowing_production_servers_up-- |
| # | 16:19:55 | bshum | "text eng regular print 050204 200710031614200" as a keyword entry seems strange to me, but anyways. |
| # | 16:20:23 | csharp | I'll be blowing up something with OpenSRF-2.0.0 when I get a chance ;-) |
| # | 16:20:37 | moodaepo | I'm still digging through DEBUG logs for one z39.50 record entry, 3910 lines |
| # | 16:20:40 | moodaepo | debug_logs++ |
| # | 16:20:56 | dbs | phasefx: ahh! my gmail account filtered that and prevented it from forwarding to my "I actually pay attention to this" account - thanks :) |
| # | 16:21:27 | dbs | bizarre that the Goog doesn't show pending invites in my CSE account, oh well |
| # | 16:22:01 | csharp | dbs: that's a great article |
| # | 16:22:08 | bshum | moodaepo: Where are those to be found usually? I'll check mine for oddities :( |
| # | 16:23:02 | moodaepo | I only have it setup on the dev server since they get so huge...you set it in opensrf_core.log (option 4) |
| # | 16:23:05 | csharp | speaking of mailing lists, the new dedicated Evergreen mailing list server will be up later this week and we can start talking migration |
| # | 16:23:39 | dbs | phasefx: bizarre - I can't see the actual list of what URLs have been included in the evergreen-ils.org CSE by you; just partially obfuscated URLs. wacko. |
| # | 16:23:49 | moodaepo | csharp++ |
| # | 16:24:02 | bshum | moodaepo: In that case, ours are probably in the default place. That's one of the syslogs I didn't set properly this morning |
| # | 16:24:49 | moodaepo | bshum: How much use will the server get? They get large fast. |
| # | 16:25:11 | bshum | It'll be an adventure. |
| # | 16:26:25 | csharp | bshum++ |
| # | 16:27:04 | bshum | I'm not really sure I deserve that. This whole upgrade experience has been mixed blessing. Nice to have functional features, not so nice to combat all new bugs and quirks. |
| # | 16:27:23 | bshum | Still, good learning experience by all |
| # | 16:27:36 | bshum | Oh, for fun story |
| # | 16:27:55 | lisppaste | moodaepo pasted "MARC importing issue 1.6.1.3" at http://paste.lisp.org/display/116679 |
| # | 16:28:04 | csharp | bshum: I was upping your karma for your sense of adventure - that's why I'm here too ;-) |
| # | 16:28:05 | bshum | We backported tsbere's patch for opening a new tab when using the button bar. So far, it's been mixed reaction to that. |
| # | 16:28:33 | bshum | When the dust settles, I'll see if we can get some better feedback for tsbere on that one. |
| # | 16:28:44 | bshum | csharp: Ah, right, adventure :) |
| # | 16:30:44 | dbs | moodaepo: that paste doesn't really say much to me |
| # | 16:31:59 | moodaepo | dbs: I was just pulling out any metabib related lines..anything you'd suggest I keep an eye out for? |
| # | 16:35:56 | dbs | moodaepo: nothing in particular, I'm afraid; I just didn't see anything in that paste that I could jump on |
| # | 16:40:25 | bshum | Good luck moodaepo, I'm going home to look at this some more. Will check back with what I can see on our end. Cataloging has been suspended until we can figure it out, at least, so nothing new should gum up our work. |
| # | 16:43:01 | bshum has quit IRC |
| # | 16:48:19 | dbs | as long as the records are getting into biblio.record_entry safely, it should still be possible to ingest the records later |
| # | 16:52:20 | dbs | http://svn.open-ils.org/trac/ILS/changeset/18483 is the only change to ingest that I could find |
| # | 16:52:42 | dbs | err, to O:A:Ingest - other changes could affect ingest of course |
| # | 16:57:01 | lisppaste | moodaepo annotated #116679 "Diff between 1.6.0.8 and 1.6.1.3 Ingest.pm" at http://paste.lisp.org/display/116679#1 |
| # | 16:59:00 | dbs | moodaepo: oh, you jumped from 1.6.0.8 to 1.6.1.3? I assumed you were already at 1.6.1.2 - sorry :( |
| # | 16:59:49 | dbs | that broadens the scope of investigation widely |
| # | 17:00:20 | moodaepo | dbs: No worries. bshum is moving from a version before 1.6.0.8 |
| # | 17:00:29 | dbs probably shouldn't try to assist in debugging problems without paying full attention :( |
| # | 17:00:45 | moodaepo | And it doesn't help I didn't test 1.6.1.2 and got tempted by 1.6.1.3 goodies |
| # | 17:00:47 | dbs | @define disservice |
| # | 17:00:47 | pinesol` | dbs: Error: "define" is not a valid command. |
| # | 17:01:31 | moodaepo | dbs: On the other hand anything you mention gives us something to look at if we haven't already. |
| # | 17:02:52 | moodaepo | dbs: I reverted that revision and it works |
| # | 17:06:06 | dbs | damn |
| # | 17:08:29 | yboston has quit IRC |
| # | 17:08:43 | dbs | moodaepo: I say "damn" because we're running that revision |
| # | 17:09:04 | dbs | which makes me wonder why the heck it's failing for you, and why it works for us |
| # | 17:09:06 | moodaepo | I can search the staff client for the record, fingerprint and quality are generated and am checking if things got ingested |
| # | 17:09:41 | moodaepo | dbs: What version are you running? And where did you move from? |
| # | 17:09:51 | moodaepo | s/move/upgrade/ |
| # | 17:10:11 | afterl has quit IRC |
| # | 17:11:11 | dbs | we're on 1.6.1.2-ish |
| # | 17:11:34 | dbs | upgraded from 1.6.0-ish something to 1.6.1.2-ish |
| # | 17:14:06 | moodaepo | Well I don't get it wither then, I followed the upgrade script and the only addition was adding tsbere and bshum's changes for the client (which I might not do in production). |
| # | 17:14:08 | dbs | might be interesting to see what "SELECT id FROM asset.uri ORDER BY id DESC LIMIT 1;" returns on your database |
| # | 17:14:44 | moodaepo | dbs: nada |
| # | 17:14:50 | rsinger has quit IRC |
| # | 17:15:09 | dbwells has joined #evergreen |
| # | 17:15:13 | moodaepo | The uri tables are both empty. |
| # | 17:15:35 | dbs | that might explain it then; if the result is null, then you can't really add 1000 to it eh? |
| # | 17:16:42 | dbs | maybe add a test for $uri->id and just set $max_uri to 1000 if the test fails |
| # | 17:18:54 | moodaepo | dbs: Makes sense! See if you hadn't mentioned that revision we wouldn't have an answer : ) |
| # | 17:19:01 | moodaepo | dbs++ |
| # | 17:19:35 | dbs | Alternately, if you inserted a bogus row into asset.uri no code would need to be touched |
| # | 17:19:43 | moodaepo | So should the uri tables be populated i.e. are we not running something? |
| # | 17:20:27 | dbs | moodaepo: yeah, yeah, that's the ticket, it's not my commit that broke bibliomation's production server, it's a lack of seed data! |
| # | 17:20:46 | dbs | moodaepo: no, it's not your fault |
| # | 17:20:53 | moodaepo | dbs: That was my initial thought adding a fake entry in the table but that's a non-dev way of dealing with the issue. We should probably have a test for the uri. |
| # | 17:21:13 | dbs | moodaepo: well, we have fake entries for other tables so it's not unprecedented :) |
| # | 17:21:54 | dbs | INSERT INTO asset.uri (id, href, active) VALUES (-1, 'http://example.com/fake', FALSE); |
| # | 17:22:15 | moodaepo | Once we have fake data or a check for uri eeevil can cut 1.6.1.4 |
| # | 17:22:18 | brian_f | phasefx: What's your e-mail address? |
| # | 17:22:23 | dbs | would you care to give that a test? |
| # | 17:22:56 | dbs | best practice would be to have both, of course |
| # | 17:23:29 | rsinger has joined #evergreen |
| # | 17:26:12 | moodaepo | dbs: Works |
| # | 17:27:02 | dbs | yay! moodaepo++ |
| # | 17:30:07 | Dyrcona has quit IRC |
| # | 17:30:27 | moodaepo | dbs: I noticed when I did a diff of the file that in 1.6.0.8 we were "Remove leading and trailing space" but in the current rev it does not happen just wanted to make sure it's noted. |
| # | 17:32:38 | dbs | committed 18749 for 1_6 and 18750 for 1_6_1 |
| # | 17:32:40 | moodaepo | dbs: This will need to be addressed for the 1.6.0 branch also (?) > http://svn.open-ils.org/trac/ILS/log/branches/rel_1_6_0/Open-ILS/src/perlmods/OpenILS/Application/Ingest.pm |
| # | 17:32:51 | moodaepo | dbs++ #for reading minds |
| # | 17:35:25 | moodaepo | Tested that MARC batch import also works now. |
| # | 17:36:18 | drv_ has quit IRC |
| # | 17:36:49 | dbs | moodaepo: thanks! 18751 has 1.6.0 covered now |
| # | 17:38:19 | dbs | moodaepo: also, not immediately sure about the leading/trailing space piece - I know my fingers have been in that space but I don't remember off-hand what the resolution was |
| # | 17:41:33 | moodaepo | dbs: Yea you added that in 1.6.0 (see the last link I posted) but I'm guessing didn't add it to 1_6 which got branched to 1_6_1 (?) |
| # | 17:42:12 | dbs | http://svn.open-ils.org/trac/ILS/changeset/15740 -- right |
| # | 17:42:40 | moodaepo | Right |
| # | 17:43:21 | jenny has left #evergreen |
| # | 17:44:21 | dbs | okay, forward-ported to rel_1_6_1 and rel_1_6 |
| # | 17:45:13 | dbs | and my 9 million rows have been loaded onto my laptop database, so it's time to head home |
| # | 17:46:35 | dbs has quit IRC |
| # | 17:53:33 | bshum has joined #evergreen |
| # | 17:53:53 | moodaepo | bshum: Cataloging issue fixed |
| # | 17:54:01 | bshum | Yeah I'm reading the backlog |
| # | 17:54:04 | bshum | To learn what I missed. |
| # | 17:56:42 | moodaepo | bshum: So yea just add the fake entry "INSERT INTO asset.uri (id, href, active) VALUES (-1, 'http://example.com/fake', FALSE);" |
| # | 17:56:53 | bshum | moodaepo: Off to give that a whirl. |
| # | 17:57:01 | bshum | moodaepo++ and dbs++ |
| # | 18:05:08 | bshum | moodaepo: Added the value, so off to figure out how to reingest the records that were imported badly. |
| # | 18:05:16 | bshum | Thanks! |
| # | 18:05:41 | moodaepo | bshum: There is a script also did you import from Z39.50 as a test? |
| # | 18:06:28 | moodaepo | bshum: Well nah not script a spell > http://evergreen-ils.org/dokuwiki/doku.php?id=scratchpad:random_magic_spells&s[]=reingest#reingesting_bib_records |
| # | 18:07:32 | bshum | Magic spells work for me. |
| # | 18:07:34 | bshum | They're awesome. |
| # | 18:07:50 | bshum | Oh that's perfect too. |
| # | 18:07:58 | bshum | I have a list of all the new items by ID |
| # | 18:07:59 | moodaepo | Hmm but that doesn't look like what you need. |
| # | 18:08:05 | moodaepo | Or is it? |
| # | 18:08:24 | bshum | I'd change the SQL part to target the bibs I actually want to see reingested I think. |
| # | 18:08:44 | bshum | I have to import from z3950 as my test first though. |
| # | 18:09:48 | moodaepo | Well good luck I think we've got enough for 1.6.1.4 do you expect your peeps to find more bugs? |
| # | 18:10:08 | bshum | z3950 import seems to be working great again |
| # | 18:10:15 | bshum | Was able to find the record I imported. |
| # | 18:10:26 | bshum | I think we uncovered plenty of stuff for a 1.6.1.4 |
| # | 18:10:56 | bshum | We'll be doing more debugging over the next couple days as we stabilize post-upgrade |
| # | 18:11:06 | bshum | But you've already nailed and identified our big issues. |
| # | 18:15:49 | bshum | moodaepo: That magic spell mostly worked |
| # | 18:16:07 | bshum | The srfsh part at the end needed minor tweaking to run if you were already the opensrf user |
| # | 18:16:22 | bshum | Reingesting bibs now, yay! :) |
| # | 18:16:22 | moodaepo | Yay |
| # | 18:17:24 | bshum | Yep, able to find bibs again, whoot |
| # | 18:17:40 | bshum | Now I can go enjoy my dinner without feeling too guilty. |
| # | 18:19:39 | 18VABSL7Y has joined #evergreen |
| # | 18:20:07 | 18VABSL7Y is now known as jeff |
| # | 18:20:20 | jeff has joined #evergreen |
| # | 19:31:15 | brian_f has quit IRC |
| # | 19:37:32 | dmc1861 has quit IRC |
| # | 19:59:00 | bshum has quit IRC |
| # | 20:01:32 | bshum has joined #evergreen |
| # | 20:45:03 | jamesrf has joined #evergreen |
| # | 21:50:32 | bshum | Should we be testing OpenSRF 2.0.0-beta1 alongside our Evergreen 2.0 beta2 testing? Or are these considered separate projects for the time being and we should stick with OpenSRF 1.6.1? |
| # | 21:52:36 | jeff | the version numbers of evergreen and opensrf don't need to match, but each evergreen release has a certain minimum opensrf version it requires. |
| # | 21:53:07 | jeff | i don't know offhand if there's anything in opensrf 2.0 that breaks backward-compatability, but you could try it and find out! ;-) |
| # | 21:53:53 | bshum | jeff: Adventure it is |
| # | 21:53:55 | jeff | compatibility, even :P |
| # | 21:54:01 | bshum | Going to test installing them side-by-side |
| # | 21:54:22 | bshum | I know that they don't need to match, I find it amusing that they do. |
| # | 21:54:32 | bshum | Least up through 1.6.1 that is |
| # | 21:55:12 | jamesrf | hey i have a related question, can one install OSRF 1.6 onto an existing Evergreen with OSRF 1.4, or do you need to rebuild Evergreen as well? |
| # | 21:56:26 | jeff | bshum: if memory serves, and according to http://evergreen-ils.org/dokuwiki/doku.php?id=versioning they never matched |
| # | 21:56:45 | bshum | jamesrf: I've always reinstalled Evergreen every time I've upgraded OSRF |
| # | 21:56:51 | bshum | But then again, I was usually upgrading EG alongside |
| # | 21:57:14 | jamesrf | if i recall correctly, eg 1.2 did not work with opensrf 1.0 or greater |
| # | 21:58:04 | jamesrf | so i don't know if something similar might happen since opensrf 2.0 is a major version number |
| # | 21:58:21 | bshum | jamesrf: Good point. |
| # | 21:58:28 | jeff | jamesrf: i think the perl bits would be fine, and the evergreen c services seem to dynamically link to the opensrf libs, so... no immediate red flags i can think of. |
| # | 21:58:41 | bshum | Maybe I'll wait to try that out. More important to test EG 2.0 b2 I guess. |
| # | 21:59:07 | jeff | proabably "safer" to rebuild evergreen also, but it might not be a requirement. |
| # | 22:00:29 | jeff | i'm just full of the definitive answers tonight. :P |
| # | 22:04:35 | dbs has joined #evergreen |
| # | 22:06:16 | jamesrf | i'm still trying to clean up MARC records that EG decided were to horrifying to be allowed into 2.0 |
| # | 22:06:52 | jeff | thrilling! |
| # | 22:07:09 | jamesrf | fun like: Tag "`" is not a valid tag |
| # | 22:09:15 | bshum | That does sound like "fun" |
| # | 22:09:29 | bshum | I had that problem with silly "" errors. |
| # | 22:20:12 | dbs reads scrollback, agrees with jeff - I think the opensrf c libs have maintained api compatibility between 1.6 and 2.0, so stopping evergreen, installing opensrf 2.0.0, and restarting evergreen should be all that's needed. actual tests wouldn't hurt, of course |
| # | 22:22:03 | dbs | also, it might not be a bad idea to put together a list of the marcxml strictness issues to be fixed prior to a 2.0 install; would make it possible to run a series of UPDATEs against biblio.record_entry before upgrading to catch the most common examples |
| # | 22:22:41 | jeff | and if ABI compatability (if i'm even using that correctly) has been broken, the shared libs should get a bump to their .so.0.0.0 filenames, right? |
| # | 22:22:52 | jeff | not a c expert. |
| # | 22:23:23 | jeff | dbs: good idea re: marcxml strictness |
| # | 22:24:56 | dbs | jeff: yes, should. would they, in practice? hrm |
| # | 22:25:25 | jeff | i think it has to be a human decision in the build process, so i'm just mentioning it. :) |
| # | 22:25:56 | jeff | i'm sure things will blow up should that become the case, it'll just blow up one of two ways -- the 'correct' way and the 'different' way ;-) |
| # | 22:26:05 | dbs | a human decision that would be implemented in autotools I imagine. and when it comes to autotools, I'm often imagining things |
| # | 22:26:36 | jeff wanders blindly |
| # | 22:26:44 | jeff | :) |
| # | 22:27:12 | dbs imagines google search resulting in http://sourceware.org/autobook/autobook/autobook_91.html |
| # | 22:28:31 | dbs | I guess that's how it's supposed to be done :) |
| # | 22:34:25 | dbs has quit IRC |
| # | 22:38:07 | dbs has joined #evergreen |
| # | 22:38:07 | dbs has joined #evergreen |
| # | 22:39:54 | dbs | berick: nice to see you poking around in srfsh.py again :) |
| # | 22:40:21 | jeff grins |
| # | 22:40:49 | lisppaste | jamesrf pasted "marcxml strictness cleanup funcs" at http://paste.lisp.org/display/116692 |
| # | 22:41:54 | jamesrf | probably needs some tweaking |
| # | 22:43:05 | jamesrf | latah |
| # | 22:43:06 | jamesrf has quit IRC |
| # | 22:44:24 | jeff | jamesrf++ |
| # | 22:48:43 | dbs | jamesrf++ |
| # | 23:11:03 | phasefx | dbs: http://open-ils.org/~phasefx/cse.png |
| # | 23:17:10 | dbs | phasefx: http://imgur.com/VhYie.png (see first and second picture) |
| # | 23:19:22 | phasefx | dbs: not sure how to see anything other than one picture from that URL, but I believe you re: obfuscation. sucky |
| # | 23:20:10 | dbs | ahh, http://imgur.com/xRAdm.png is the second image :) |
| # | 23:20:31 | phasefx | lovely |
| # | 23:21:10 | jeff | heh |
| # | 23:21:11 | jeff | nice |
| # | 23:21:18 | jeff | google-- in this regard |
| # | 23:22:06 | phasefx | so if you use the drop-down Included sites from: <email>, it'll list them obfuscated? |
| # | 23:23:07 | dbs | ah, crap... that's how it gets revealed. dbs-- |
| # | 23:23:08 | jeff | i see them as you see them |
| # | 23:24:10 | phasefx | buckets, most popular query of all time |
| # | 23:24:46 | phasefx | then suspend hold, download the latest stable release (1.6), hold_verify, open-ils.auth, rss |
| # | 23:25:23 | bshum | Buckets? Really? |
| # | 23:25:40 | phasefx | tupac is in the list as well |
| # | 23:26:00 | phasefx | if we support more music libraries I think that might make a good codename for an opac :) |
| # | 23:26:21 | dbs | jeff: you should be able to select "Included sites: phasefx" and see the details |
| # | 23:27:03 | jeff | dbs: sorry, that's what i meant by "i see it as [phasefx] see[s] it" -- selecting the email showed me unobfuscated details :) |
| # | 23:27:31 | jeff | tucows + opac = TUPAC, The Ultimate Public Access Catalog? |
| # | 23:27:55 | phasefx | we could start defining this CSE with an xml file that we can commit to ILS-Contrib/evergreen-ils.org |
| # | 23:28:28 | jeff | i'm not sure there's a big win there. |
| # | 23:28:55 | jeff | other than allowing people with svn-but-no-gogle-account to update the cse def. |
| # | 23:29:29 | dbs | jeff: you get version control |
| # | 23:29:43 | jeff | revision history, yes. |
| # | 23:29:56 | phasefx | not as mission critical as the other stuff, though |
| # | 23:30:33 | dbs | tomato, tomato - if you have revision history, then you can restore a previous version :) |
| # | 23:30:39 | jeff | tradeoff being it makes adding to the cse something beyond just "click this bookmarklet" :) |
| # | 23:31:05 | dbs | well - but how do I get rid of phasefx's Woodchip repo if it's no longer pertinent? |
| # | 23:31:17 | phasefx | dbs: look at the Refinements section |
| # | 23:31:23 | dbs | I can add the same URL as an excluded site pattern? |
| # | 23:31:55 | jeff | lame |
| # | 23:32:03 | jeff | yeah, another win for having it in svn |
| # | 23:32:18 | jeff | you rely less on phasefx as the One True Admin Of The CSE |
| # | 23:32:24 | phasefx | dbs: can you add/delete the Refinements I have? |
| # | 23:32:45 | dbs | phasefx: I'm thinking - what refinements section? |
| # | 23:33:03 | phasefx | dbs: well, actually that would just get rid of the label/category, but the content would still show up in search results |
| # | 23:33:28 | phasefx | I see Control Panel -> Basics, Sites, Indexing, Refinements, etc. |
| # | 23:33:37 | jeff | yeah, i also see no refinements, but i have "excluded sites from" |
| # | 23:34:05 | jeff | i alsodon't have stats |
| # | 23:34:11 | phasefx | bleh |
| # | 23:34:18 | phasefx | so remove Woodchip? |
| # | 23:34:38 | dbs | Please |
| # | 23:34:57 | phasefx | done |
| # | 23:35:01 | dbs | Also, I can't funnel ad revenue to my account |
| # | 23:35:09 | dbs | LAME |
| # | 23:35:32 | phasefx | :D |
| # | 23:36:38 | jeff | yeah, for CSEs that i'm "contributing" to, i have none of the options above "Resources" on the side navigation |
| # | 23:36:39 | phasefx | may help to turn on ads there |
| # | 23:37:25 | phasefx | I bet certain competing vendors would sue us if their ads showed up :) |
| # | 23:39:00 | dbs | hmm, that would be an advantage to ESI owning the evergreen-ils.org domain - legal entity to sue is ESI, not Conservancy (perspectives may differ on that "advantage" - heh) |
| # | 23:39:24 | phasefx | har |
| # | 23:39:53 | dbs | anyway, now that more of my CSE stupidity has been exposed, we at least have the ability to try and address whatever rsoulliere or others think should be searched |
| # | 23:43:44 | youdonotexist has joined #evergreen |
| # | 23:49:23 | bshum has quit IRC |
April 10-13