| 02:09 |
|
berick joined #evergreen |
| 02:20 |
|
flopaul joined #evergreen |
| 03:58 |
|
dreuther joined #evergreen |
| 05:13 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 06:39 |
|
timlaptop joined #evergreen |
| 07:27 |
|
Callender joined #evergreen |
| 07:32 |
|
jboyer-isl joined #evergreen |
| 10:33 |
* csharp |
hasn't seen issues using 14.04 on his desktops/laptop |
| 10:34 |
csharp |
Dyrcona: what software is incompatible? |
| 10:34 |
csharp |
Dyrcona: I'm working with EDI now too, FYI, if you want to compare notes at any point |
| 10:35 |
Dyrcona |
csharp: I understand that Perl 5.18 causes some issues with tests in CPAN packages as well possibly our tests. |
| 10:35 |
Dyrcona |
csharp: I know that Horde, ckeditor, and mobile jquery, are installed with incompatible versions. |
| 10:35 |
csharp |
eww |
| 10:35 |
Dyrcona |
csharp: The latter causes parts of Horde web mail not to function properly. |
| 10:38 |
csharp |
lots of moving parts |
| 10:38 |
|
montgoc1 joined #evergreen |
| 10:39 |
Dyrcona |
As for EDI, I'm using this documentation: http://docs.evergreen-ils.org/2.5/_installation.html |
| 10:39 |
Dyrcona |
I'll set that much up today, since I don't have the information to configure any testing with vendors, yet. |
| 10:40 |
|
rfrasur joined #evergreen |
| 10:40 |
Dyrcona |
After that, I think I'll try upgrading my development vm from Ubuntu 12.04 to 14.04 to see what breaks. |
| 10:41 |
csharp |
Dyrcona: see the message on e56f3e59 regarding the replacement PO JEDI template |
| 13:33 |
gmcharlt |
I'm not; not on that basis, anyway |
| 13:35 |
RoganH |
I understand and I can see your position even if I come to a different conclusion. |
| 13:36 |
RoganH |
I suspect my position will be in the distinct minority when it comes to voting anyway and I won't be heart broken to be out voted. |
| 14:06 |
jeffdavis |
So does 2.6 require Postgres 9.3, or is 9.1 fine? |
| 14:07 |
jeffdavis |
I'm running 2.6 on a test server with a 9.1 db now and haven't run into any issues, but haven't thoroughly tested so far. |
| 14:08 |
bshum |
jeffdavis: 9.1 is fine |
| 14:08 |
bshum |
9.3 should work though |
| 14:08 |
bshum |
Or at least, that's what a bunch of bugs were directed at fixing |
| 14:09 |
jeffdavis |
thanks! |
| 14:17 |
dbs |
9.3 should work as of 2.6, right? |
| 14:18 |
dbs |
So upgrade from 2.5 to 2.6 on 9.1, then upgrade from 9.1 to 9.3 |
| 14:18 |
bshum |
dbs: That's the general idea. |
| 14:18 |
bshum |
I think |
| 14:18 |
bshum |
I didn't test it that way though, now that you mention it. |
| 14:19 |
bshum |
I just did 9.1 to 9.3 first, then upgraded the rest of the way from where I left off in my numbered scripts. |
| 14:19 |
bshum |
Ignoring any broken parts of the restore (since those were broken things fixed with the upgrade SQL) |
| 14:20 |
dbs |
Yeah. I wonder if there are clear pros to either approach for "normal" sites |
| 14:20 |
bshum |
Depends on how you do the PG upgrade I guess. |
| 14:20 |
bshum |
I think we'll also be moving to new hardware at the same time for us. So we have *lots* of moving parts in our equation. :\ |
| 14:31 |
gsams |
huzzah! |
| 14:37 |
Dyrcona |
If you run the upgrade SQLs before doing the upgrade of the database to 9.3, then the database should restore just fine. |
| 14:38 |
* Dyrcona |
chimes in a little late. |
| 14:38 |
Dyrcona |
bshum: Are you doing your production upgrade or is this a test? |
| 14:39 |
bshum |
Dyrcona: This is the hardware we're using for production upgrade. |
| 14:39 |
bshum |
Though I guess we're testing it the next couple weeks. |
| 14:39 |
Dyrcona |
bshum: I misunderstood when you said "mceraso is doing our next upgrade." I think I get it now. |
| 14:39 |
Dyrcona |
We're upgrading this Sunday, Mother's Day, and I'm doing this one. |
| 14:40 |
bshum |
Dyrcona: Ah, cool. Our upgrade will be Memorial Day weekend. |
| 14:40 |
bshum |
Doing both the switch to new hardware and Evergreen upgrade |
| 14:40 |
Dyrcona |
We've had staff testing it on our training server for the past few weeks. |
| 14:40 |
dbs |
yous++ |
| 14:40 |
bshum |
Dyrcona++ # going first this time ;) |
| 14:41 |
Dyrcona |
Heh. |
| 15:04 |
jl- |
imo VM is really all you need for unix |
| 15:05 |
jl- |
I love my raspberry pi though |
| 15:06 |
Dyrcona |
jl-: I disagree. For some applications, I prefer to run them on a dedicated, real machine in production. |
| 15:08 |
Dyrcona |
VMs are awesome for testing and development, and for smaller things in production. |
| 15:08 |
bshum |
Heh, for want of a USB memory drive, Ubuntu could not be installed on this machine :) |
| 15:08 |
bshum |
(yet) |
| 15:08 |
Dyrcona |
Heh, funny you mention that..... |
| 16:11 |
pinesol_green |
jeff: Try restarting apache. |
| 16:11 |
jeff |
zoia++ |
| 16:12 |
berick |
heh, zoia muscle memory |
| 16:15 |
gsams |
csharp: as far as I can see everything seems to be working. My current predicament tells me otherwise though. |
| 16:15 |
gsams |
postgres isn't throwing any issues related to the permissions, and as far as I can tell it is returning both ADMIN_TRIGGER and UPDATE_TRIGGER at the same time |
| 16:18 |
gsams |
maybe it's just the test server... |
| 16:18 |
jeff |
berick: i was intentionally incrementing zoia for having @decide, where pinesol_green does not. ;-) |
| 16:19 |
bshum |
It probably could. |
| 16:19 |
berick |
jeff: ohh, missed that |
| 16:21 |
bshum |
Yeah it's part of the original Assorted plugin, which we've only adapted bits and pieces of over time. |
| 16:21 |
gsams |
it is the test server |
| 16:22 |
gsams |
something isn't configured correctly I guess... |
| 16:47 |
bshum |
So has anyone ever seen this before, where Linux reads off the network device as "em1", "em2", etc. and not "eth0", "eth1" |
| 16:47 |
bshum |
It's kind of freaking me out, but nothing seems quite right with it other than the name. |
| 16:47 |
berick |
i've seen all manner of names |
| 16:49 |
bshum |
Thanks everyone, not going to freak out for now. |
| 16:55 |
jeff |
berick's "i've seen all manner of names" came across in a james earl jones voice. |
| 16:56 |
jeff |
"I'm interested in all kinds of astronomy." |
| 16:56 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:00 |
berick |
heh, too bad instead of wise / world-weary, I was really going for, "it's all crazy talk to me" |
| 17:04 |
|
mmorgan left #evergreen |
| 17:12 |
bshum |
jeff: That's one of my favorite movies :) |
| 03:48 |
|
eby__ joined #evergreen |
| 04:57 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 06:04 |
|
serflog joined #evergreen |
| 06:04 |
|
Topic for #evergreen is now Welcome to the #evergreen library system channel! | We are publicly logged. | Large pastes at http://paste.evergreen-ils.org |
| 06:28 |
|
dac joined #evergreen |
| 09:28 |
|
jwoodard joined #evergreen |
| 09:28 |
* csharp |
wonders if it's worth trying to backport the new marc_export script to 2.5.1 |
| 09:29 |
csharp |
I'm doing a full DB + holdings export, and that takes us about 48 hours with the "old" script |
| 09:31 |
bshum |
csharp: It's not scientific, but doing a parallel export test when that new marc_export was merged got me my whole DB in less than two hours what used to take 26 hours consecutive extracting. |
| 09:32 |
bshum |
(i.e. it might be worth it, if you're not planning to upgrade again for awhile) |
| 09:34 |
|
yboston joined #evergreen |
| 09:39 |
* Dyrcona |
thinks the new marc_export will just work on 2.5.1. |
| 09:39 |
jeff |
i don't think there's much to backport, yeah. |
| 13:01 |
Dyrcona |
Then you can git merge the custom branches into it. |
| 13:02 |
Dyrcona |
We base our custom branches on the master branch, because when we upgrade, we checkout from the master branch. |
| 13:02 |
Dyrcona |
For instance, we're upgrading this coming weekend. |
| 13:02 |
Dyrcona |
We also loaded everything on our training server in advance to give our members a chance to look at things and find any bugs that we missed during preliminary testing. |
| 13:03 |
eeevil |
csharp: sorta ... sick day :| |
| 13:04 |
Dyrcona |
We made the branch on the 16th of April and named it mvlc_20140416. |
| 13:04 |
csharp |
I'll just ask my question to the full channel (though I'd be happy if eeevil sees it) - I am making some edits to the reporter.classic_item_list definition in fm_IDL.xml, and wanted to know if it is correct to denote the "rel" attribute of the link between reporter.classic_item_list and our "legacy" stat cats as "might_have" rather than "has_a" |
| 13:05 |
Dyrcona |
It has had two or three bug fixes applied as well as our custom branches. |
| 13:05 |
|
tjspindler joined #evergreen |
| 13:05 |
csharp |
for reference http://git.evergreen-ils.org/?p=working/Evergreen.git;a=commit;h=0e114d1d33e4f23e28c43c3a5ef04bc8718348e3 |
| 13:06 |
Dyrcona |
It is a good idea to rebase your custom branches periodically to keep them up to date with changes or when you want to test a new branch, like going from 2.5 to 2.6 . |
| 13:06 |
eeevil |
csharp: checking something before answering ... working from memory is not a good idea today ;) |
| 13:06 |
csharp |
eeevil: understood |
| 13:08 |
|
mrpeters joined #evergreen |
| 17:27 |
|
vlewis joined #evergreen |
| 17:29 |
kmlussier |
All kidding aside, the thing that concerns me about all of our lists is that a new person entering the community might send a request for help to a low traffic list not knowing that he/she may get more responses if the same request were sent to the general list. |
| 17:30 |
kmlussier |
I'm primarily thinking of the sys admin list, where I've seen a couple of questions languish. |
| 17:30 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:34 |
|
krvmga joined #evergreen |
| 18:58 |
|
mjingle joined #evergreen |
| 20:02 |
|
doug joined #evergreen |
| 08:59 |
pinesol_green |
kmlussier: The operation succeeded. Dessert #8 added. |
| 09:07 |
tspindler |
bshum: thanks, I have a vague understanding about what they might mean but I don't want to assume, you know what they say about assuming |
| 09:08 |
|
jeff___ joined #evergreen |
| 09:10 |
bshum |
tspindler: I just sent the reply, I think I'll take some of what I said and add it to the bug wrangler wiki page for the milestone section of the page. |
| 09:11 |
bshum |
tspindler: Thanks for asking the question, it's something I've been a bit delinquent in getting fully explained in my past roles. |
| 09:12 |
|
akilsdonk joined #evergreen |
| 09:13 |
bshum |
tspindler: I just realized I didn't say anything specific about the one bug you linked to |
| 09:14 |
bshum |
I note in https://bugs.launchpad.net/evergreen/+bug/1086550/comments/13 that I guess I removed the pullrequest tag off the bug because there were conflicting approaches being suggested and we hadn't reached a final conclusion over what code we were testing/reviewing. |
| 09:14 |
pinesol_green |
Launchpad bug 1086550 in Evergreen "TPAC: Not clear to patron how to deselect a facet" (affected: 5, heat: 24) [Wishlist,Confirmed] |
| 09:14 |
bshum |
Without an active pullrequest and the unfinished discussion, I guess this one slipped through the cracks during development cycles for 2.5, etc. |
| 09:17 |
bshum |
My recommendation is to take back the conversation and get a new pullrequest on the bug with the code that should be reviewed. |
| 09:27 |
bshum |
That said, historically, our core group of bug wranglers have been a bit lax in this department. :( |
| 09:28 |
dbs |
bshum: suggestion for the "deleted record" that might make everyone happy - just add an extra @class value that sites that don't want greyed-out bibs can just override in their CSS with background-color: inherit; or whatever? |
| 09:29 |
kmlussier |
Since LP already allows any LP user to mark it as confirmed, I expect some people will do it whether it's part of our best practices or not. And I don't think that's a bad thing. We just need to be aware that there may be a valid reason why an importance isn't set when somebody marks a bug as confirmed. |
| 09:29 |
tspindler |
If i can chime in, i thinnk keeping the status changes to the bug wrangler team is important, i think it could really muddy things if all users could do this. A regular user can argue in a comment section for its importance or indicate it was tested. |
| 09:29 |
kmlussier |
+1 to dbs' suggestion. |
| 09:29 |
kmlussier |
tspindler: I'm not advocating that all users set the importance level. But I do think it's a good thing that they can mark it as confirmed. |
| 09:29 |
bshum |
dbs: That's a fair suggestion. I'm not even sure how much my users will even notice or complain about its return. I was just being grumpy yesterday :\ |
| 12:11 |
kmlussier |
Yeah, 33 doesn't look right to me. |
| 12:11 |
krvmga |
kmlussier: this search http://bark.cwmars.org/eg/opac/results?query=guns%20of%20navarone;qtype=keyword;locg=1;detail_record_view=1;page=1 number 19 |
| 12:11 |
krvmga |
kmlussier: the last library is not in alphabetical order |
| 12:11 |
kmlussier |
I have another thought. Hold on, let me look up the bug number... |
| 12:12 |
kmlussier |
I know https://bugs.launchpad.net/evergreen/+bug/1234845 was loaded on your test server a while back, and we talked about loading it in production because it looked good under my testing. |
| 12:12 |
pinesol_green |
Launchpad bug 1234845 in Evergreen "possible optimization for evergreen.ranked_volumes database function" (affected: 2, heat: 12) [Medium,Triaged] |
| 12:13 |
kmlussier |
Do you know if it ever was loaded in production? Because, if so and if my testing didn't catch something, that's where you would see the problem. |
| 12:14 |
krvmga |
kmlussier: i do not know if it was. i'll see if i can find out. |
| 12:14 |
kmlussier |
Nice. I actually listed what the expected ranking behavior was in my testing notes. It should be preferred library -> search library name ->call number label -> availability. |
| 12:17 |
jeff |
asking because it just came up in conversation: does anyone have an example of where you might use a copy's "reference" attribute vs the copy's "circulate" attribute (or perhaps more commonly, the copy's location's "circulate" attribute)? |
| 12:18 |
jeff |
i.e., is there a situation where "reference" wouldn't just be an inverse of "circulate"? |
| 12:19 |
gmcharlt |
jeff: to explain why it doesn't circulate, particulary for reference books that are interfiled with circulating material |
| 16:48 |
bshum |
Then give it to you for a quick glance and merge ;) |
| 16:48 |
gmcharlt |
ok |
| 16:55 |
bshum |
gmcharlt: Bug updated https://bugs.launchpad.net/opensrf/+bug/1315525 |
| 16:55 |
pinesol_green |
Launchpad bug 1315525 in OpenSRF "Add Ubuntu 14.04 makefile target for OpenSRF" (affected: 1, heat: 6) [Medium,Confirmed] |
| 17:08 |
|
bmills joined #evergreen |
| 17:17 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:30 |
pinesol_green |
[opensrf|Chris Sharp] LP#1315525: Updating Makefile.install for Ubuntu 14.04. Removing lucid support. - <http://git.evergreen-ils.org/?p=OpenSRF.git;a=commit;h=be5c3d8> |
| 17:30 |
pinesol_green |
[opensrf|Ben Shum] LP#1315525: Add trusty target and remove lucid from README - <http://git.evergreen-ils.org/?p=OpenSRF.git;a=commit;h=65ce998> |
| 17:41 |
bshum |
Thanks gmcharlt! Now the fun part, getting Evergreen squared away.... |
| 17:58 |
|
edoceo joined #evergreen |
| 18:09 |
bmills |
https://bugs.launchpad.net/evergreen/+bug/1315552 |
| 05:18 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 07:16 |
csharp |
@later tell bmills check out the action.find_hold_matrix_matchpoint function - it takes the pickup lib ID, the request lib ID, the copy ID, the user's ID, and the requestor's ID and will return the IDs of the matching hold rules and the one chosen (usage: SELECT action.find_hold_matrix_matchpoint(pickup_ou.id, request_ou.id, copy.id, user.id, requestor.id);) |
| 07:16 |
pinesol_green |
csharp: The operation succeeded. |
| 07:18 |
|
kmlussier joined #evergreen |
| 09:40 |
bshum |
Sounds intriguing. |
| 09:43 |
tsbere |
And of course only available for 9.3+ |
| 09:43 |
tsbere |
<_< |
| 09:44 |
bshum |
Yeah I just got to that part of the README |
| 09:44 |
bshum |
I'm giving serious thought towards using 9.3 for our nextgen DB server in a couple weeks. |
| 09:44 |
|
yboston joined #evergreen |
| 09:47 |
bshum |
It's hard to test all the parts of Evergreen with 9.3 but so far nothing too crazy jumping out at me in the test servers we're practicing on. |
| 09:48 |
bshum |
Also, it being the default in Ubuntu 14.04, maybe I'm just being lazy. :D |
| 09:57 |
|
denishpatel joined #evergreen |
| 10:00 |
bshum |
yboston: For DIG, I took a tiny thing and tried my hand at making a short asciidoc snippet (with pictures) in http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/bshum/docs-for-opensearch with an example of how to add OpenSearch to Firefox. If you have time later, I'd like to check with you on how to test how it looks and whether I screwed up a lot :) |
| 10:01 |
yboston |
I am off to a meeting, I will ping you when I am done, and thanks! |
| 10:11 |
remingtron |
bshum: if you have asciidoc installed on your machine, you can test the conversion to html with something like: |
| 10:11 |
remingtron |
asciidoc -a data-uri -a icons -a toc -d book -o OUTPUT_FILE |
| 10:12 |
remingtron |
oops, you also need your asciidoc file on the end :) |
| 10:12 |
bshum |
remingtron: Ah, the extra flags are helpful. I just did a basic conversion test, which failed to find all the images I embedded probably cause of the path I was using. |
| 10:12 |
remingtron |
yeah, I usually have a problem with the image path too, but your syntax looks fine for those |
| 10:22 |
|
jbfink joined #evergreen |
| 10:29 |
|
montgoc1 joined #evergreen |
| 14:06 |
rsoulliere |
I have a couple of items. |
| 14:06 |
rsoulliere |
#topic Conversion Coordinator Report |
| 14:06 |
yboston |
go ahead |
| 14:06 |
rsoulliere |
#info Evergreen Documentation for 2.6 is up and available now and pulling for the rel_2_6 branch. |
| 14:07 |
rsoulliere |
#info Note that the documentation processing is a bit finicky and asciidoc errors may hold back processing of pages you have edited. They may also prevent the PDF file from being produced. Testing asciidoc syntax before pushing is recommended. |
| 14:07 |
rsoulliere |
#info I sent out a question to the mailing list regarding retiring "Evergreen in Action" on Lulu? |
| 14:07 |
rsoulliere |
#link http://list.georgialibraries.org/pipermail/open-ils-documentation/2014-April/001645.html |
| 14:08 |
rsoulliere |
Any suggestions? |
| 14:08 |
remingtron |
do we have access to the purchase history? |
| 14:09 |
kbutler |
Given that it's out of date, it seems logical to take it down. But will/should/does anyone want to update it? |
| 14:09 |
|
Meme joined #evergreen |
| 15:00 |
remingtron |
krvmga: thanks for sharing your work |
| 15:01 |
krvmga |
yw :) |
| 15:01 |
remingtron |
yboston: go ahead and add the action, I think it only works for the person running the mtg |
| 15:01 |
yboston |
as a test, give it a shot |
| 15:02 |
yboston |
start with #action |
| 15:02 |
remingtron |
#action remingtron will send a 2.6 docs progress report to the DIG list in two weeks |
| 15:03 |
yboston |
I think that should work, but Iw ill make a dup action to be safe |
| 15:03 |
yboston |
#action remingtron will send a 2.6 docs progress report to the DIG list in two weeks |
| 16:53 |
* kmlussier |
doesn't really like cherry pie. |
| 16:53 |
jventuro |
Mmm dessert |
| 16:53 |
hbrennan |
it takes 5 tries to get something chocolate |
| 16:54 |
* kmlussier |
tests hbrennan's theory. |
| 16:54 |
kmlussier |
@dessert hbrennan |
| 16:54 |
* pinesol_green |
grabs a slice of Pecan Pie and sends it sliding down the dessert bar to hbrennan |
| 16:54 |
montgoc1 |
a la mode? |
| 16:54 |
kmlussier |
@dessert jventuro |
| 16:59 |
kmlussier |
Ooh! I can do that? |
| 17:01 |
bshum |
Hehe |
| 17:01 |
gmcharlt |
assuming bshum doesn't lock it away ;) |
| 17:01 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:01 |
gmcharlt |
though seriously, there would be worse things than the bot to use an an example/testbed for introductory programming tutorials |
| 17:01 |
kmlussier |
That's the problem. bshum has too much power. |
| 17:03 |
bshum |
Oh, really, can we not make them gray bibs again? bug 1084753 discussion makes me queasy |
| 01:26 |
|
MsAngel joined #evergreen |
| 01:26 |
MsAngel |
Hello I have problem in autogen.sh |
| 01:26 |
MsAngel |
ubuntu 12.04 and evergreen 2.5.4 |
| 05:02 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 05:59 |
csharp |
@later tell Dyrcona this made me think of you: http://developers.slashdot.org/story/14/04/30/0042250/the-ways-programming-is-hard |
| 05:59 |
pinesol_green |
csharp: The operation succeeded. |
| 07:05 |
|
timf joined #evergreen |
| 07:28 |
csharp |
looks like the upgrade path from 2.1 to 2.3 and forward doesn't include script 0738 |
| 07:28 |
csharp |
PINES doesn't have the updated vandelay.get_expr_from_match_set function either, so we'll have to schedule a time to run 0738 separately |
| 07:29 |
csharp |
(looking back at frank__'s problem yesterday rang a bell about the same issue I found on our acq testing server) |
| 07:41 |
|
collum joined #evergreen |
| 07:43 |
bshum |
csharp: I'm stepping out momentarily, today is one of my random days off; but I just wanted to touch base with you briefly on the Ubuntu 14.04 situation |
| 07:44 |
bshum |
I removed my working branch playtest for opensrf, I've been finding further complications with how I was hammering the changes to deal with the warnings during autoreconf |
| 10:41 |
yboston |
jeff & jboyer-isl : just pushed to working a slightly edited copy of the Stripe release notes info, that I plan to commit to the main docs. let me know if I you have any suggestions for me, and note that the release notes information will be left where it is http://git.evergreen-ils.org/?p=working/Evergreen.git;a=commitdiff;h=25ab425af44bd09a979b8d549e12398ff9c4499a |
| 10:42 |
mrpeters |
same deal with the PerlSetVar loaded |
| 10:42 |
mrpeters |
though, should i uncomment templates_custom from eg_vhost now? |
| 10:43 |
tsbere |
mrpeters: Just a thought, are you certain you are getting the correct vhost? Is your other directive matching instead of this one? (you could add your Location block from the one you pasted to the other one temporarily to test) |
| 10:43 |
mrpeters |
yeah let me throw up that section of the eg.conf |
| 10:44 |
pastebot |
"mrpeters" at 64.57.241.14 pasted "eg.conf" (22 lines) at http://paste.evergreen-ils.org/22 |
| 10:45 |
jboyer-isl |
yboston: Looks good to me, though I wonder about the point of including the bare setting names. Is that so direct-db users have an easier time setting them, or just because they were in the notes and were left? |
| 12:59 |
krvmga |
tsbere: i think i've got it! EUREKA! it's sorting on call number as related to the search |
| 13:01 |
krvmga |
tsbere: so, for instance, Marlborough actually has three copies but the call numbers are J DVD FINDING and J DVD DISNEY. J DVD DISNEY does not show up in the show more details returns. |
| 13:01 |
tsbere |
krvmga: or it could just be a fluke. :P |
| 13:01 |
krvmga |
tsbere: or that. |
| 13:02 |
krvmga |
tsbere: i'll test it on some other searches and see what happens. |
| 13:08 |
mrpeters |
score....got it! |
| 13:09 |
|
RoganH joined #evergreen |
| 13:09 |
pastebot |
"mrpeters" at 64.57.241.14 pasted "working eg.conf with secondary vhost for custom templates" (22 lines) at http://paste.evergreen-ils.org/24 |
| 13:17 |
tsbere |
For even *more* fun, the staff members that want it on by default want a user setting....and share the account with staff members that hate it. >_> |
| 13:18 |
krvmga |
tsbere: that extra complainy goodness... |
| 13:19 |
jeff |
stop sharing accounts. :P |
| 13:19 |
krvmga |
i'm still testing some examples of the search returns and they're not panning out consistently yet. |
| 13:20 |
tsbere |
jeff: I argued against it. I was outvoted. And for that matter, not really given a vote. |
| 13:20 |
dbs |
Hmm: artrhyno wrote 209edc8199677 a couple of years ago |
| 13:20 |
jeff |
i'm still interested in ideas like "require ssl client cert for any staff access" combined with "ssl client cert and maybe a role account gets you minimum access, but MOST things require you to log in with your individual staff credentials that are yours and yours alone" -- that's a mix of code and policy. |
| 16:36 |
* kmlussier |
went to library school and doesn't know the answer to that question. |
| 16:38 |
dbs |
mrpeters: it can be anywhere, but normally is at the end |
| 16:41 |
|
mtcarlson_away joined #evergreen |
| 17:09 |
bmills |
hello. has anyone found a way to uncover what hold matrix matchpoint id was used in a specific hold request? or if that is possible to find out? i'm looking to test and see what policies are being used when certain users are making hold requests |
| 17:18 |
|
RBecker joined #evergreen |
| 17:18 |
gsams |
mrpeters: our cataloging committee should be aware of that, and should be working that direction. We did have a bad start entering records without the URI information at first, but new ones coming in should be setup properly according to the documentation for 2.3(currently) |
| 17:30 |
|
mmorgan left #evergreen |
| 17:35 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:38 |
|
geoffsams joined #evergreen |
| 18:05 |
|
gsams joined #evergreen |
| 18:32 |
|
gsams joined #evergreen |
| 07:21 |
dbs |
You have to install the prereqs when you install OpenSRF, and then again once you start on Evergreen |
| 07:22 |
dbs |
that error suggests that the package that supplies libdbd-pgsql wasn't installed |
| 07:22 |
mika__ |
I don't encounter a problem when installing opensrf only in evergreen |
| 07:23 |
dbs |
However... I'm not 100% sure that 14.04 was tested with Evergreen 2.5, because we released 2.5 back in the fall and 14.04 only became stable last month |
| 07:23 |
mika__ |
what should I do? |
| 07:23 |
dbs |
I know we tested with Evergreen 2.6 |
| 07:23 |
mika__ |
so should i remove the 2.5.4? |
| 07:24 |
dbs |
What Makefile.install target did you use for Evergreen 2.5? |
| 07:24 |
mika__ |
I M just following the tutorial in there web.. i think Path: /openils/Bin |
| 10:18 |
Guest23408 |
please? |
| 10:20 |
jeff |
Guest23408: your open-ils.cstore service is no longer connected to the Jabber / XMPP server, or it simply isn't running at all. |
| 10:20 |
Guest23408 |
so i need to go back in jabber to run it again> |
| 10:21 |
jeff |
Guest23408: in very general terms, I would suggest stopping apache, stopping all OpenSRF services, then starting OpenSRF services and waiting for them to finish starting (watch CPU usage and/or logs), then start Apache again. |
| 10:21 |
jeff |
You could optionally test with srfsh in between starting OpenSRF services and starting Apache. |
| 10:22 |
jeff |
But keep an eye on logs to see if you have a problem that isn't fixed by a simple restart -- and I would recommend looking back in the logs to see what happened in the first place. |
| 10:22 |
jeff |
Guest23408: good luck! |
| 10:25 |
|
jcamins joined #evergreen |
| 10:26 |
|
ellie-bas joined #evergreen |
| 10:28 |
ellie-bas |
hello friends! i am having trouble to make Pull List for Hold Requests work |
| 10:40 |
ellie-bas |
jeff: this is probably because one of the holds was placed from opac, while the other was placed from staff client and probably there is a difference due to title / volume / copy level holds |
| 10:42 |
|
jboyer-laptaupe joined #evergreen |
| 10:45 |
ellie-bas |
jeff: the status of both entries in patron's account say: Waiting for copy |
| 10:51 |
jeff |
ellie-bas: is this a test system? also, are the copies in question in either Available or Reshelving statuses, or are they in some other status? |
| 10:55 |
ellie-bas |
jeff: yes, this is a test system, and everything works fine on other test branch. but on particular test branch the pull list does not seem to work. |
| 10:55 |
ellie-bas |
jeff: yes, the titles are available and they are not out. |
| 10:56 |
jeff |
ellie-bas: ah! another good clue. is the branch in question configured with hours of operation that show it as being open today/now? |
| 10:56 |
|
miguel___1 joined #evergreen |
| 10:56 |
ellie-bas |
jeff: wow, I never thought about that :) |
| 11:13 |
jeff |
ellie-bas: holds can be complex, and you might find that there's another issue after checking on the holds targeter. |
| 11:17 |
ellie-bas |
jeff: yes, there are available copies, an all the copies are on the same branch, i.e. circ library and owning library is the same |
| 11:17 |
tsbere |
ellie-bas: But is the circ/owning library the library you are running the pull list at? |
| 11:19 |
miguel___1 |
jeff >>>http://paste.evergreen-ils.org/17 |
| 11:20 |
miguel___1 |
When I test srfsh I get 4.... |
| 11:20 |
jeff |
miguel___1: if you could paste the contents of your ejabberd.cfg file at paste.evergreen-ils.org, i suspect you may need to adjust some settings. if you think you've already adjusted them correctly, you may need to completely stop and start ejabberd for them to take effect. |
| 11:21 |
miguel___1 |
I already did tat |
| 11:27 |
ellie-bas |
jeff: yes, circ/owning library is the library that my workstation is registered to and also my car/circ patron account has a home library of the same branch |
| 17:15 |
pinesol_green |
[evergreen|Thomas Berezansky] Checkout Fills Related Hold modifications - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=be76579> |
| 17:15 |
jeff |
tsbere: trying to picture a workflow/etc |
| 17:16 |
|
mmorgan left #evergreen |
| 17:19 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:23 |
jeff |
has anyone here made the transition from "staff use one account for patron-y and staff-y things" to "staff have a staff account and a patron account, and the patron account is not used for staff operations"? |
| 17:23 |
|
pastebot joined #evergreen |
| 17:23 |
jeff |
i'm interested in pitfalls, or good methods for avoiding same. |
| 00:16 |
|
kmlussier1 joined #evergreen |
| 00:38 |
* bshum |
is confused over what LBS stands for... |
| 05:18 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 06:12 |
|
RBecker joined #evergreen |
| 07:57 |
|
jboyer-isl joined #evergreen |
| 08:01 |
|
kmlussier joined #evergreen |
| 12:55 |
mllewellyn |
SOme of my adventurous librarians may try those and we don't whatn them to. |
| 12:55 |
jeff |
if the staff users in question don't have the underlying permission to merge or delete bibs, in theory the buttons will be enabled but not actually do what they do, unless someone enters credentials when prompted that DO have those underlying permissions. |
| 12:56 |
mllewellyn |
That's all I need is for rogue merging to be going on behind our backs. |
| 12:56 |
jeff |
i would recommend testing this theory in a test system with some unimportant bibs, or in a live system with (again) unimportant (say, generated for this test) bibs. :-) |
| 12:56 |
mllewellyn |
jeff: OK, thanks |
| 12:57 |
* csharp |
installs Windows XP in a VM so he can demonstrate how to install Lubuntu over it in documentation ;-) |
| 12:57 |
mllewellyn |
Since bibs do delete when they remove the last items, I'm thinking they kind of do have permission to delete. |
| 13:00 |
mllewellyn |
csharp: But you're right, I was hoping for some granularity. |
| 13:01 |
mmorgan |
mllewellyn: just tried to merge to records from a bucket as a user who didn't have permission, and was prompted for authorization to MERGE_BIB_RECORDS |
| 13:01 |
mmorgan |
btw, thanks for the cupcakes! |
| 13:02 |
mllewellyn |
mmorgan: thanks for testing, and you're welcome for the cupcakes. :) |
| 13:02 |
mllewellyn |
mmorgan++ |
| 13:04 |
|
mtate joined #evergreen |
| 13:12 |
phasefx_ |
hrmm, I think there's a typo in 0799.state_field_required_toggle.sql and 2.4.3-2.5.0-upgrade-db.sql. ui.patron.edit.au.state.require vs ui.patron.edit.aua.state.require, and similar |
| 13:13 |
tsbere |
phasefx_: It might be fixed by a later update....not sure. >_> |
| 16:55 |
kmlussier |
remingtron: At some point (not today), I want to run some ideas by you for organizing the public catalog chapter of the docs. I'm struggling with how we combine more administrative tasks with end user information. |
| 16:56 |
remingtron |
kmlussier: cool, I'll be glad to discuss that. I'm around most of the week. |
| 16:57 |
kmlussier |
remingtron: Sounds good. I'll be missing this week's DIG meeting. I'm hoping to have time to give it some real thought on Friday. |
| 17:01 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:04 |
sseng |
Question about authority.authority_linking table: if i have auth A and auth B (where auth A has a 500 that corresponds to to the 100 field in auth B), after the linking scripts run, what auth (A or B) is the source and what is the target in the authority.authority_linking table? |
| 17:14 |
|
mmorgan left #evergreen |
| 18:04 |
frank__ |
hi remingtron sorry but I was in a meeting, my EG version is 2.5.3 but I was analazyng and I discovered that the functions get_expr_from_match_set and get_expr_from_match_set_point doesnt have the last changes, I have to apply the http://git.esilibrary.com/?p=transitory.git;a=blob_plain;f=Open-ILS/src/sql/Pg/upgrade/XXXX.schema.vandelay.import-match-no-like-any.sql;hb=b82c278f404a142bb55d3659d61c5acf1087cf4c solution I guess |
| 05:02 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 05:07 |
|
kmlussier joined #evergreen |
| 05:10 |
|
kmlussier left #evergreen |
| 05:11 |
|
kmlussier joined #evergreen |
| 13:01 |
eeevil |
bshum: please do |
| 13:02 |
Dyrcona |
Well, I'm just going to spit this record's id out with a message that it errored. It is only one out of 6,218. |
| 13:02 |
Dyrcona |
I'm also spitting out a list of records that I can't fix, so I'll put it in that list. |
| 13:03 |
jeff |
Dyrcona: there's a comment in MARC::File::SAX (used by MARC::File::XML) to the effect of being more consistent with MARC::File::USMARC's behavior with regard to parse errors. |
| 13:04 |
jeff |
That's my usual mode -- identify the malformed records and exclude, or fix by hand. |
| 13:05 |
jeff |
Ideally they wouldn't get into biblio.record_entry.marc if they're malformed. I don't know if that's just imported or older record data. I haven't tested to see if you can sneak bad data in in current Evergreen. |
| 13:10 |
|
hbrennan joined #evergreen |
| 13:16 |
Dyrcona |
bshum++ |
| 13:25 |
Dyrcona |
On my MARC::Record error: I can print $@ to get the error message. |
| 15:52 |
|
Callender_ joined #evergreen |
| 15:52 |
jeff |
tsbere: adding it to the temp list fails in a fashion. if you request the anon cache key's value you see one electronic resource id, but you can never add it to a real (non-temp) list, and the next record you add to the list overwrites the electronic resource. |
| 15:52 |
tsbere |
huh, fun |
| 15:53 |
jeff |
overwrites is an oversimplification -- the contents of the anon cache are fetched, run through search, and then the new record is appended to the end of those results -- so the search step always eats the electronic resource. |
| 15:53 |
jeff |
unless your resource is an auri at the top of the org tree, i suspect (but haven't tested that) |
| 15:55 |
|
Callender__ joined #evergreen |
| 15:57 |
eeevil |
jeff: or within the current search scope? or acts-like-copies? |
| 16:09 |
jeff |
eeevil: "current search scope" is always "no org unit, defaults to top of tree" in this case, i think. |
| 09:09 |
dbwells |
eeevil: please do, thanks |
| 09:09 |
|
kbeswick joined #evergreen |
| 09:10 |
jl- |
so RoganH, what would the SQL look like? :) would this go into asset.copy? |
| 09:11 |
dbwells |
jl-: for quick creation of fake assets, I'd check out the stuff in the "Concerto" test set. |
| 09:11 |
RoganH |
jl-: I'm not sure what data you're working off of. the concerto stuff would be a good jumping off point. |
| 09:11 |
dbwells |
jl-: specifically, the functions in Open-ILS/tests/datasets/sql/env_create.sql and their use in Open-ILS/tests/datasets/sql/assets_concerto.sql |
| 09:11 |
RoganH |
jl-: basically you need entires in asset.call_number that reference bib records |
| 09:12 |
RoganH |
jl-: then entries in asset.copy that reference the call numbers |
| 09:12 |
eeevil |
dbwells: done, sir |
| 11:00 |
csharp |
happy to help! |
| 11:00 |
|
tspindler joined #evergreen |
| 11:00 |
* csharp |
looks around for what bshum is mumbling about ;-) |
| 11:21 |
bshum |
Random question |
| 11:21 |
bshum |
Right now, we pull in Business::ISBN via CPAN |
| 11:21 |
bshum |
is there any reason we can't use the packaged version like libbusiness-isbn-perl |
| 11:22 |
bshum |
(since the version in Trusty is 2.0.7, same as CPAN, I think?) |
| 11:22 |
bshum |
Or is this the sort of thing we're teasing out |
| 11:22 |
bshum |
With testing and breaking |
| 11:23 |
bshum |
Oh, nevermind I can see we already covered this with Wheezy |
| 11:24 |
* bshum |
ponders some edits to the section of the README about standalone DB requirements |
| 11:26 |
jeff |
bshum: you neverminded, but to the best of my knowledge, the only reason for bringing that in via CPAN was where it wasn't packaged by the distro in question. |
| 11:27 |
bshum |
jeff: That makes good sense. I guess that means we really ought to update the standalone DB portion of the README since it still uses CPAN and not packages that may exist. |
| 11:27 |
bshum |
I'm setting up a new standalone DB and it suddenly occurred to me to check on what packages may or may not exist |
| 11:28 |
* bshum |
will do some poking and whip up a branch for this later on. |
| 11:41 |
* jeff |
had fun killing a test vm repeatedly yesterday |
| 11:41 |
csharp |
@blame the test vm |
| 11:41 |
pinesol_green |
csharp: the test vm stole bradl's tux doll! |
| 11:42 |
jeff |
(intentional triggering of OOM conditions and adjusting Apache settings to avoid said conditions) |
| 11:42 |
* Dyrcona |
had "fun" upgrading his laptop to Ubuntu 14.04. |
| 11:42 |
jeff |
creating endless loops in php designed to quickly use as much memory as the php memory limit would allow, etc :-) |
| 11:58 |
|
kmlussier left #evergreen |
| 11:58 |
Dyrcona |
Erick316: I don't think the importer is going to deal very well with 35,000 records with match sets all at once. |
| 11:58 |
Dyrcona |
Erick316: The staff client is likely to time out waiting on the server. |
| 11:58 |
jl- |
yes start with 1k |
| 11:59 |
jl- |
or even 1 |
| 11:59 |
jl- |
just for testing |
| 11:59 |
jboyer-isl |
Start with 5 to make sure the match set works the way you want, after that your upper limit is determined by the complexity of your matches and your hardware. |
| 11:59 |
jboyer-isl |
It will be a lower limit than you would hope. |
| 12:01 |
Erick316 |
yeah actually I have 10 records only for testing |
| 12:02 |
Erick316 |
but the expression for the record match set, I don't know if it is correct, have anyone some expression to make another test? |
| 12:02 |
jboyer-isl |
How many are already in the system? Match set timing is effected by both incoming and existing. |
| 12:03 |
Erick316 |
I' ve already used this : Your Expression: (020 ‡a OR 022 ‡a OR 024 ‡a OR 028 ‡a) and Your Expression: (item_lang AND (240 ‡a OR 245 ‡a)) |
| 12:03 |
Erick316 |
are 3 queues already in system some of 300, another of 600, and other of 3500 |
| 13:10 |
jl- |
this script makes me very happy |
| 13:16 |
mrpeters |
possible to accomplish alternate tpac skins without the ability to create new vhosts? have a customer who is super locked down on what hostnames the city will let them create and they don't see the need for a second one for the library. their goal is one hostname for the "in the building" TPAC and then their current one for the public, outside the building. |
| 13:18 |
tsbere |
mrpeters: Er, if they have two hostnames (internal vs external) then, er, you have two hostnames already? |
| 13:20 |
jl- |
SELECT id FROM biblio.record_entry WHERE id <= 1000 ORDER BY RANDOM() LIMIT 1 berick |
| 13:20 |
jl- |
ceiling |
| 13:20 |
jl- |
tested |
| 13:20 |
jl- |
;) |
| 13:21 |
bshum |
Heh |
| 13:21 |
berick |
jl-: cool, glad it's working |
| 13:21 |
jeff |
mrpeters: i think it might be possible with creative apache config, but i haven't tried yet. |
| 17:18 |
bshum |
Probably right, holds don't have audit trails by default. |
| 17:19 |
gsams |
mkay, that'll have to do then |
| 17:19 |
bshum |
At least you have the exact moment when the hold was cancelled. |
| 17:19 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:19 |
gsams |
I think I know what happened though, and timestamps are enough for any local damage that might have been done. |
| 17:19 |
bshum |
That'll help with log sifting |
| 17:19 |
gsams |
csharp++ |
| 17:36 |
gsams |
bshum: that did the trick, thank you very much. Saving me from a lot of headaches down the line. |
| 17:36 |
gsams |
bshum++ |
| 17:37 |
gsams |
phasefx++ # for helping disable the clear shelf expired holds option back in September of 2013 |
| 17:41 |
bshum |
csharp: I'm building a new trusty demo to poke at the ubuntu makefile you setup for Evergreen. |
| 17:41 |
bshum |
OpenSRF seems fine with the revisions I threw in my working branch |
| 17:41 |
bshum |
Or at least, the basic test passes |
| 17:42 |
csharp |
cool |
| 17:42 |
csharp |
yeah - I was updating the Evergreen makefile to be able to test the opensrf makefile ;-) |
| 17:43 |
csharp |
beyond the math test, that is |
| 17:43 |
bshum |
Hehe, yeah |
| 17:43 |
bshum |
On paper, all the changes you suggest look alright. |
| 17:43 |
bshum |
I'm still not entirely sure what gmcharlt was warning us to watch for, some change in perl I think. |
| 17:43 |
bshum |
But I'm sure we'll hit something new |
| 17:47 |
gmcharlt |
bshum: upshot - hash key sort randomization caused failures in Koha's test cases of its copy of QueryParser |
| 17:48 |
gmcharlt |
that may (or may not) apply to Evergreen |
| 17:48 |
gmcharlt |
the issue manifested as a given query randoming resulting in different parse trees |
| 17:49 |
gmcharlt |
hopefully isn't not widespread |
| 17:50 |
bshum |
Guess we'll see. |
| 17:52 |
gmcharlt |
speaking of which, a minor example in OpenSRF - https://bugs.launchpad.net/opensrf/+bug/1285915 |
| 17:52 |
pinesol_green |
Launchpad bug 1285915 in OpenSRF "t/09-Utils-JSON.t can fail on Perl 5.18" (affected: 1, heat: 6) [Low,New] |
| 04:56 |
pinesol_green |
Incoming from qatests: Test Failure - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 06:57 |
|
kmlussier joined #evergreen |
| 07:03 |
kmlussier |
@coffee |
| 07:03 |
* pinesol_green |
brews and pours a cup of Sumatra Lintong, and sends it sliding down the bar to kmlussier |
| 10:08 |
|
yboston joined #evergreen |
| 10:08 |
|
atlas__ joined #evergreen |
| 10:08 |
|
phasefx joined #evergreen |
| 10:11 |
dbs |
yboston: finally took a look at those RDA records--great start! We also need some that have multiple 264 fields, too, to really exercise our tests, but that's going to be more work (trawling through records to find candidates) |
| 10:13 |
yboston |
dbs: I was planning on writing the cataloging list to ask for more non-OCLC records (while we confirm what we can do with OCLC records) |
| 10:13 |
dbs |
Also, today I learned that "Slackers" is a valid LCSH heading, thanks to Pineapple Express: id.loc.gov/authorities/subjects/sh2005006709.html |
| 10:14 |
yboston |
:) |
| 17:01 |
eeevil |
just shaped the same |
| 17:01 |
tsbere |
eeevil: Plus I had decided I didn't want "single org unit buckets" nor two columns nor things like "negative number means go look up a bucket" tricks |
| 17:03 |
eeevil |
hrm... well, making single-OU buckets easy to do via a "streamlined" interface ("select an org" creates a 1-org bucket) would allow the fkey |
| 17:03 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:03 |
eeevil |
just a thought |
| 17:04 |
tsbere |
eeevil: Time to go home today. I will see about finishing up some thoughts in my current notes and finding a place to post them soon. |
| 17:04 |
eeevil |
tsbere: thanks! (btw, did you have a chance to test the array-ish pcrud stuff? if you have a sec to answer) |
| 17:04 |
|
bbqben joined #evergreen |
| 17:05 |
tsbere |
eeevil: I haven't tested it fully, but I believe it at least compiled and seemed to return results. I don't recall trying to write with it though. |
| 17:05 |
eeevil |
tsbere: cool. if you hit issues, let me know. I think that may open up some broader improvements where we currently have global_required ... but we'll need to add more general array support... |
| 17:06 |
eeevil |
(array-writing support, I mean) |
| 17:08 |
* eeevil |
skee-daddles |
| 10:59 |
denishpatel |
eeevil: thanks for details |
| 10:59 |
bshum |
jl-: You know, I misread what you said earlier. 500k bibs sounds like a good amount (it occurs to me that our system is only around 1.1 million actives). 4 GB of RAM might not be covering that so well and it's slow for hitting disk. |
| 10:59 |
jl- |
has anyone thought of using apache solr? they have all kinds of search tweaking |
| 11:00 |
denishpatel |
eeevil: is there a way to download evergreen's postgres schema only to load into my test server? |
| 11:00 |
jeff |
jl-: someone did play with solr, but we never saw any code, and i don't think that it was at all integrated with evergreen, just searching an export of records from evergreen (but again -- never saw any code, so dunno) |
| 11:01 |
jl- |
vufind uses solr :) |
| 11:01 |
jeff |
shart290__: the error you pasted appears to be a timeout between the client and server -- the client (apparently) never received a response. |
| 11:17 |
eeevil |
jl-: bibs can be "owned" in (basically) one of two way, and the way you use depends on if it's an electronic resource or a barcoded, physical item |
| 11:17 |
eeevil |
for barcoded items, attach a call number and copy owned by the "owner" |
| 11:17 |
eeevil |
for e-resources, us a located uri (856 with an appropriate subfield 9) |
| 11:20 |
bshum |
jl-: Huh... so in your test system I can't find any copies. How did you make the bibs visible in search? (aka, did you just mark them as trascendent or something) |
| 11:24 |
bshum |
What I would normally expect in a migration is that the original MARC exported from the legacy ILS would have some sort of holdings tag containing basic info like barcode, call number, price, whatever. And then you would map those to callnumbers/copies in Evergreen, that linked to each given bib. |
| 11:25 |
dbwells |
jl-: If you are building an Evergreen instance from two (or more) catalogs that are currently independant (and it sounds to me like you are), you are going to want to combine and dedupe all the records from every system, preferably at an early point. This will not be a particularly straightforward task, and I doubt it's represented in the docs in any way. In fact, depending on how varied the records in your current catalogs are, it could be a monumen |
| 11:25 |
dbwells |
tal task by itself. |
| 11:25 |
bshum |
In Evergreen, bibs are all stored in biblio.record_entry, but there's the item holdings which are reflected in asset.call_number (which points back to a specific record ID), and then asset.copy (which points back at specific call number IDs) for each bib. |
| 11:38 |
bshum |
But that also depends on how the system is intended to be used / searched, I guess. |
| 11:40 |
bshum |
But let's say that having combined bibs saves you room in the database. |
| 11:42 |
bshum |
In any case, I would create all the libraries you think you're going to need as org-unit entries. Just so that you get the sorted. And then as you bring in new bib/copies, you just need to figure out how to correctly mark the volume/copies as owned by a specific org unit. You could leave bib deduplication to later on. |
| 11:42 |
jl- |
I understand, this seems very important but for now I think it would be overkill. If I can have two orgs with copies each, that would be fantastic |
| 11:42 |
jl- |
and if I have some duplicates, that's ok for testing the ILS |
| 11:43 |
jl- |
with this I mean deduplication |
| 11:43 |
jl- |
:) |
| 11:43 |
bshum |
yes, you can always create multiples of bibs, so basically like the "Star Wars" example, lots of times over. But you just set the ownership for each call number / copy accordingly. |
| 11:43 |
bshum |
And eventually poke at merging things. |
| 11:43 |
jl- |
anyway, so how do I actually attach copies, is there documentation? I have an items.txt with 400 entries |
| 13:37 |
jeff |
so you might have records with 856 tags that point to things like "author info" at loc.gov, etc. those aren't treated specially (assuming they don't have those values for ind1/ind2 and an appropriate subfield 9) |
| 13:37 |
jl- |
jeff: I want to create a subfield 9 in 856 and give it a shortname which I'll use for an org unit |
| 13:40 |
jl- |
marcedit will let me add any field and field data |
| 13:41 |
jeff |
i would recommend starting with a single test record. |
| 13:42 |
jeff |
ensure that you're getting the behavior you want before doing any kind of batch/mass updates. |
| 13:50 |
jl- |
yuo |
| 13:50 |
jl- |
yup |
| 13:51 |
jl- |
bshum: it seems like I can batch edit (and add) fields to records in the staff client, so it seems like adding an org shortname would not have to happen prior to importing ? |
| 15:32 |
dbwells |
bshum jeff: so what was the real reason for the ++s, or are you just going to leave us in the dark? |
| 15:33 |
jeff |
oh, sorry. i thought someone explained it. |
| 15:33 |
bshum |
Working on things for the community web server. |
| 15:34 |
jeff |
GPLS has taken some spare hardware and finished initial provisioning as a community VM host, so that things like the git and web servers can be on hardware that more than just csharp can restart, potentially other things like test servers/buildbots, etc. |
| 15:34 |
hbrennan |
Haha. Glad I wasn't the only curious one |
| 15:35 |
jeff |
A step toward csharp being able to go on vacation. :-) |
| 15:35 |
dbwells |
jeff: Is this what csharp and a few others of us were chatting about at the end of the conference? |
| 16:35 |
jeff |
jl-: and since none of the records appear to have visible copies, I'm assuming that their bib source is transcendent, which as eeevil noted is "the ballgame" :-) |
| 16:36 |
jeff |
at this point, i'm not sure we have enough information to recommend for/against the use of opac.located_uri.act_as_copy |
| 16:36 |
jeff |
(in jl-'s situation) |
| 16:37 |
eeevil |
jeff: true. if these are bibs that correspond to physical items on shelves in a library, the best thing to do would be to get that data from the current system and attache the items. minimally, that would be the call number label and the barcode. all else is of little import for a surface test of the system |
| 16:38 |
eeevil |
jl-: -^ |
| 17:13 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:25 |
|
atlas___ joined #evergreen |
| 17:53 |
|
RBecker joined #evergreen |
| 18:06 |
|
alynn26 joined #evergreen |
| 13:27 |
jeff |
shart291: what distro and version did you start with? |
| 13:28 |
shart291 |
Debian Squeeze, I initially began with the intent to preserve the existing system. When I learned the database wasnt recoverable I reinstalled With Wheezy. Thats when I was in the last couple of days trying to get things to run. |
| 13:28 |
shart291 |
I'm tired and just want to get it going. |
| 13:35 |
phasefx |
demo.evergreencatalog.com is up if anyone wants to give it a spin. I only tested a search and logging in to the TPAC |
| 13:36 |
kmlussier |
phasefx: Do you mind if I send an e-mail to the DIG list letting people know? |
| 13:36 |
phasefx |
kmlussier: go for it |
| 13:37 |
phasefx |
I'll be back in a bit if anyone has trouble with it |
| 13:58 |
* phasefx |
is going to whip up a stored procedure to protect the admin user |
| 13:58 |
kmlussier |
graced: Yeah, but even with a better data set, I think it would be useful to have a handful of barcodes of patrons in a "good" status, and then some barcodes of patrons with overdues or outstanding bills. |
| 13:59 |
graced |
We can provide that - that's the plan with the better data set |
| 13:59 |
kmlussier |
So that if they are documenting something related to penalties, for example, they know which test users already have those penalties. |
| 13:59 |
graced |
Exactly. |
| 13:59 |
kmlussier |
graced++ |
| 13:59 |
graced |
More like akilsdonk++ as she's doing all the hard work on this one |
| 14:13 |
sseng |
kmlussier: yep |
| 14:14 |
kmlussier |
Usually, I might select one to import non-matching and then select just one of the others to tell the system how to do the merge. I don't think it's typical to select all three. |
| 14:15 |
kmlussier |
We have some sites that only want the system to merge automatically if there is a single match, but if there are more they want to address it manually. |
| 14:15 |
sseng |
kmlussier: bshum: wanted to confirm that in master, whether the Marc batch importer/exporter works or whether i have somehing bad going on with my test environment |
| 14:15 |
kmlussier |
Other systems prefer to let Vandelay do all of the merging and will just tell it to select the best match. |
| 14:16 |
bshum |
In theory everything in master should be working, unless there's a bug filed about it. Or at least I like to dream that's the case. |
| 14:16 |
bshum |
:) |
| 14:16 |
sseng |
kmlussier: i am going to give that a try |
| 14:16 |
sseng |
bshum: =) |
| 14:16 |
bshum |
But in this particular case, please feel free to collect some details and let us know. Overall, the vandelay situation was complicated due to underlying changes made with MVF/CRA's addition |
| 14:16 |
bshum |
And we may not have shaken all the issues? |
| 14:17 |
bshum |
I would test more, but today is a "holiday" and nobody at Biblio is around. Other than those of us migrating our email to a new solution. |
| 14:17 |
kmlussier |
sseng: I did successfully do an acq upload on a recent version of master, but I didn't try anything in the batch import, so it's possible something else is going on there. |
| 14:17 |
bshum |
fwiw, mllewellyn did do a vandelay load of around 29 or so I think she said |
| 14:18 |
bshum |
And that seemed to go through without hijinks |
| 14:18 |
bshum |
But maybe it's size, or maybe it's the options used |
| 14:18 |
sseng |
bshum: kmlussier: going to do more testing, maybe a bad mrc file. (just wanted to do a quick check and see if anyone's used it recently) |
| 14:19 |
bshum |
Recently like... last week, sure. |
| 14:19 |
|
hbrennan joined #evergreen |
| 14:21 |
phasefx |
who was trying out the smartfaq plugin in wordpress? |
| 16:41 |
bshum |
Line 263 of configure.ac |
| 16:41 |
bshum |
For OpenSRF |
| 16:46 |
|
mllewellyn_ joined #evergreen |
| 17:13 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:27 |
|
mllewellyn joined #evergreen |
| 17:50 |
|
kmlussier left #evergreen |
| 23:09 |
|
artunit_ joined #evergreen |
