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 |
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 |
01:27 |
|
zerick joined #evergreen |
04:41 |
|
dbs joined #evergreen |
04:56 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
06:58 |
|
timlaptop joined #evergreen |
07:51 |
|
collum joined #evergreen |
08:04 |
|
rjackson-isl joined #evergreen |
09:17 |
jl- |
fgin=fine |
09:18 |
RoganH |
jl-: Is it fine for each cataloger to edit each bib record? |
09:18 |
dbwells |
jl-: Yes, search scoping can happen via the call number /copy ownership. |
09:18 |
jl- |
RoganH: at this point it's test run and there won't be any catalogers (library staff?) |
09:18 |
jl- |
it's more of a proof-of-concept |
09:19 |
RoganH |
jl-: Ah. Well, when you get to that stage that will be a big deal. If they feel territorial and each university has to "own" their bib that will be a big issue. |
09:19 |
Dyrcona |
Yeah, jl-, the more you learn now, the better off you will be later. |
09:19 |
jl- |
well they certainly own the individual books? |
10:54 |
yboston |
Any US citizens that want to give me tips of how to submit the RDA records I am acquiring to be added tot he communtiy dataset? |
10:54 |
dbs |
And then download the MARC (Unicode) records one by one. You could put them all together and submit them as a branch, after which they would get munged into the sample loader format |
10:55 |
yboston |
(nevermind) |
10:55 |
dbs |
(e.g. drop them into a Open-ILS/tests/datasets/RDA/ subdirectory and then they could get reformulated) |
10:55 |
yboston |
(thanks for the path, was just about to ask) |
10:58 |
yboston |
I assume it OK if I start with a branch with just a few RDA files , then create more branches later |
10:58 |
yboston |
s/it/it is/ |
11:05 |
mrpeters |
one of our customers wants to become a target for the community so i'm just relearning the process. It was kind of a set it and forget it thing when I did it the other time. |
11:08 |
|
ldwhalen joined #evergreen |
11:09 |
jeff |
Dyrcona: sounds like a bug (re: gists). have an example? |
11:10 |
* dbs |
doesn't know if there's a way to search catalog.loc.gov for 264 ind2 != 1 though, which is what we need to test Dyrcona's branch |
11:14 |
Dyrcona |
jeff: I would have said open any gist, click on the link for raw, right-click in the window, choose save as, and then open the file in a text editor to see the HTML. |
11:15 |
Dyrcona |
I've seen that twice. |
11:15 |
Dyrcona |
However, when I tried to repeat that just now, it didn't happen. I got plain text. |
11:31 |
RoganH |
asimon: it doesn't really affect availability per se, we are configured so that it can still be targeted for holds and checked out |
11:32 |
asimon |
*: TY to all. I have to run. |
11:34 |
|
denishpatel joined #evergreen |
11:35 |
dbwells |
So, I've already cut 2.6.0 and am testing now, but can anyone take a look at the newly posted bug #1308590? |
11:35 |
pinesol_green |
dbwells: Error: Could not gather data from Launchpad for bug #1308590 (https://launchpad.net/bugs/1308590). The error has been logged |
11:38 |
gmcharlt |
hmm; LP isn't responding ATM |
11:39 |
dbwells |
eyeball test says it won't cause any harm, but better to be sure. Branch is here, since LP isn't responding: http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/dbs/lp1308590_fix_schemaorg_type |
11:39 |
gmcharlt |
https://bugs.launchpad.net/evergreen/+bug/1308590 |
11:39 |
pinesol_green |
Launchpad bug 1308590 in Evergreen "CCVM/icons broke schema.org type matches" (affected: 1, heat: 6) [Undecided,New] |
11:41 |
|
mmorgan left #evergreen |
11:41 |
|
mmorgan joined #evergreen |
11:41 |
gmcharlt |
dbwells: I can test and push to master in the next 15 minutes or so |
11:41 |
gmcharlt |
up to you whether to recut 2.6.0, but I certainly have no objection if your doing that |
11:41 |
gmcharlt |
*to your doing that |
11:42 |
dbwells |
gmcharlt: excellent, thanks |
11:43 |
|
RoganH left #evergreen |
11:44 |
|
jventuro joined #evergreen |
16:45 |
shart290 |
already |
16:46 |
Dyrcona |
shart290: Yep. So, what happens if you do cd to go back to your home directory and then run osrf_control without the ./? |
16:48 |
shart290 |
it worked when I entered a login session for opensrf but not when I use sudo -u opensrf |
16:49 |
dbs |
mrpeters: are the staff hitting the big red "X" button to delete the address? |
16:49 |
dbs |
'cause that's what ours do. |
16:50 |
* dbs |
just fired up the staff client for the first time in *months* and added a user on the test server |
16:51 |
Dyrcona |
shart290: osrf_control starts daemon processes and that may not work with sudo. |
16:51 |
shart290 |
is there another way to execute as one user from another? |
16:51 |
* dbs |
does "sudo su - opensrf" and then runs the commands. |
16:54 |
* csharp |
usually does 'sudo -i' then 'su opensrf' so I can move between opensrf and root, but tomayto/tomahto |
16:55 |
shart290 |
ok, lemme try this. I am so close and my head is about to implode |
16:55 |
* dbs |
confirms "sudo -i -u opensrf osrf_control -l --stop-all" works whereas "sudo -u opensrf osrf_control -l --stop-all" does not |
16:56 |
shart290 |
bingo |
16:56 |
shart290 |
thanks you all |
16:57 |
shart290 |
dbs++ Dyrcona++, mrpeters++ csharp++ |
16:57 |
shart290 |
now to get the client to test. I will be setting up another computer to handle the staff client. |
16:57 |
shart290 |
just need to get an interface. |
16:58 |
Dyrcona |
I always login to the server as the opensrf user, then sudo if I need root. |
16:58 |
Dyrcona |
Anyway, time for me to go. |
16:59 |
|
mdriscoll left #evergreen |
17:23 |
hbrennan |
Haha |
17:28 |
gmcharlt |
Evergreen: keeping circ desk staff alert since 2007 |
17:28 |
gmcharlt |
s/2007/2006/ |
17:29 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
17:31 |
shart290 |
gonna reboot. |
17:42 |
|
shart290 joined #evergreen |
17:47 |
pastebot |
"shart290" at 64.57.241.14 pasted "Issues running evergreen after install" (58 lines) at http://paste.evergreen-ils.org/60 |
01:28 |
|
eby__ joined #evergreen |
04:17 |
|
tfaile joined #evergreen |
05:12 |
|
phasefx joined #evergreen |
05:30 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
07:00 |
|
timf joined #evergreen |
07:03 |
|
Callender joined #evergreen |
07:04 |
|
tfaile joined #evergreen |
09:35 |
jl- |
jcamins: what are the implications of that? I've been using equinox migration tools and they have served me well so far |
09:36 |
jl- |
mrpeters: http://paste.debian.net/hidden/46f59b30/ |
09:36 |
jcamins |
jl-: potentially you'll run into a situation where existing tools don't seem to be giving you the expected result. That's all. |
09:37 |
jl- |
jcamins: yes, thankfully this is a test run |
09:37 |
jl- |
I've already had to do some costumizing |
09:38 |
jl- |
*custom |
09:38 |
jl- |
and thanks for the koha link jcamins, that is the next ILS we are wanting to test |
09:39 |
jcamins |
There are other versions of the migration toolkit, so you might want to look around to see if anyone has anything better. |
09:39 |
dbs |
jl-: mfhd for serials may end up going into serial.record_entry if your library doesn't circulate your serials |
09:39 |
Dyrcona |
jl-: Looking at the code that jcamins pointed out, it appears to expect some item information in the bibliographic (MARC) records. That gets matched up with other information from items.txt later. |
13:23 |
Dyrcona |
csharp: Did you do it as a consortial admin or did library staff do it? |
13:23 |
csharp |
library staff |
13:23 |
Dyrcona |
I agree that it sounds like a bug. |
13:23 |
csharp |
we tested it on our test system as a local admin |
13:23 |
RoganH |
did the local admin have all working locations assigned? |
13:24 |
csharp |
RoganH: I don't know who did it |
13:24 |
RoganH |
I want to say the issue for us came up when internal help desk staff who had all working locations did it. |
13:24 |
csharp |
it appeared on everyone's closed dates, though, and it's 2 weeks away (our normal checkout duration) |
13:25 |
kmlussier |
Looking at the Closed Dates Editor, my expectation would be that it would apply to all the children of the OU that's selected at the top of the screen. |
13:25 |
csharp |
could someone please test after me? |
13:25 |
kmlussier |
Even if the person using the editor had permission at more working locations. |
13:25 |
csharp |
it may be something local |
13:25 |
RoganH |
I'll test right now. |
13:25 |
csharp |
RoganH: much appreciated |
13:34 |
RoganH |
csharp: just tested with my 2 account. Account A has all working locations. Account B only has the locations in one system. In both cases the closed date applied to all locations where that account has working locations regardless of where in the org tree they applied the date. |
13:34 |
RoganH |
If the "apply to all my libraries" is checked. |
13:35 |
RoganH |
If that is not checked it is only applied to the individual library. |
13:36 |
jeff |
gmcharlt: thanks! (re: libki) |
13:36 |
RoganH |
In neither case does it go down the org unit tree and apply to child org units. |
13:37 |
csharp |
RoganH: thanks |
13:39 |
dkyle |
Jeff: we are testing libki. bott has done a few mods for EG integration |
13:40 |
RoganH |
csharp: one of the reasons I never reported it as a bug is I'm OK with it functioning like that. It means it's not practical for me to set the closed dates for each library system and they have to do it. |
13:50 |
|
jwoodard joined #evergreen |
14:16 |
|
mcooper joined #evergreen |
14:18 |
|
RoganH joined #evergreen |
14:23 |
|
geoffsams joined #evergreen |
14:34 |
|
mrpeters joined #evergreen |
14:36 |
dbs |
Dyrcona: finally running your branch with test RDA bibs. Very interesting. |
14:36 |
|
kmlussier1 joined #evergreen |
14:37 |
dbs |
Dyrcona: in the case of record matching (OCoLC)825763702, there's "264 4 ‡c℗2013" that doesn't appear to be displayed anywhere |
14:38 |
* Dyrcona |
is in a meeting. I'll look later. |
14:39 |
dbs |
Also looks like, with more descriptive 7xx fields, we're going to have to revise the added author stuff further (probably picking up from a discussion that bshum and I were having a while back) |
14:39 |
dbs |
cool |
14:58 |
|
kayals_ joined #evergreen |
15:05 |
dbs |
@later tell Dyrcona dang, the batch of RDA bibs you supplied only has 18 records with "264 ind2=<anything other than 1>" and all of those simply have 264 ind2=4 $c<date>" which doesn't get displayed; that is, |
15:05 |
pinesol_green |
dbs: The operation succeeded. |
15:06 |
dbs |
@later tell Dyrcona that is, the test bibs don't really help with testing that part of the patch. Really useful for the added author / schema.org type matching though! |
15:06 |
pinesol_green |
dbs: The operation succeeded. |
15:06 |
Dyrcona |
dbs: Hmm. sorry. I grabbed records that had all the RDA fields that came up in the IRC discussion. |
15:09 |
dbs |
Dyrcona: no worries! if you want to hand-pick a few that have more interesting 264 fields for your patch's purpose, it would be easy to roll those in |
15:10 |
Dyrcona |
dbs: If I can find the ones that I tested with, sure. |
15:10 |
Dyrcona |
Movies seem to be good choices. |
15:10 |
dbs |
Dyrcona++ |
15:23 |
yboston |
dbs & Dyrcona : the two Berklee catalogers will start picking RDA records to be added to the EG data set |
15:33 |
kayals_ |
yes |
15:34 |
kayals_ |
Electronic resources does NOT show in the search result page but does show up in record summary |
15:34 |
kmlussier |
kayals_: Does it show up in the search results after you click the "Show more details" button at the top of the page? |
15:34 |
kayals_ |
i know other libraries have their search result page show Electronic Resource listed with links |
15:35 |
kayals_ |
we do not use show/hide more details as we removed that tabs |
15:35 |
kayals_ |
i can add it and test it |
15:53 |
kayals_ |
kmlussier - I added back show/hide more details in the results.tt2 file still no luck |
15:53 |
kayals_ |
it does not show electronic resource |
15:56 |
|
kmlussier1 joined #evergreen |
16:07 |
bshum |
kayals_: URI entries for 856 only appear when making use of the $9 trick |
16:07 |
rjackson-isl |
right and don't you need to be logged in to the branch showin gin the $9 as well? |
16:35 |
gmcharlt |
yboston: sorry for the delay; it shoudl work now |
16:40 |
yboston |
gmcharlt: thanks, it works |
17:07 |
|
RoganH left #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:22 |
|
mmorgan left #evergreen |
18:43 |
bshum |
Hmm |
18:43 |
bshum |
So in Open-ILS/xul/staff_client/server/circ/checkout.js |
00:33 |
bshum |
@later tell kmlussier The LJ article about open source systems is up online now: http://www.thedigitalshift.com/2014/04/ils/open-source-options-library-systems-landscape/ |
00:33 |
pinesol_green |
bshum: The operation succeeded. |
01:12 |
|
b_bonner joined #evergreen |
01:13 |
|
mtcarlson_away 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> |
05:45 |
|
pastebot0 joined #evergreen |
05:47 |
|
jventuro joined #evergreen |
08:04 |
|
collum joined #evergreen |
11:32 |
|
asimon joined #evergreen |
11:33 |
Dyrcona |
kmlussier: Could be the version. I think bibliomation and MVLC are on a newer "release." We're on the equivalent of 2.5+. |
11:34 |
kmlussier |
Dyrcona: This is 2.5.3 |
11:38 |
asimon |
I'm attempting to overlay the action_trigger schema using pg_restore, but I keep getting hung up on restoring the *pkey table constraints, even after using the --clean and --data-only options. Attempting to drop one of the constraints as a test suggest that I use CASCADE, but that affects indices. Is there an easier way to do this? |
11:43 |
bshum |
Yeah, we're like halfway to 2.6 |
11:43 |
bshum |
Well, more like 75% of the way |
11:44 |
csharp |
asimon: so by "overlay" do you mean "remove the data that's there and insert new data"? |
16:15 |
bshum |
To get things to pop up |
16:15 |
bshum |
I remember this bug now |
16:17 |
bshum |
gmcharlt++ # thanks |
16:18 |
eeevil |
kmlussier: so phasefx ran the auth-auth linker on cwmars' test system, but that will only cause a reingest on the /unauthorized/ side of an auth-auth link (that's the record that changes with the addition of a $0). the remainder of the auth records would not have been reingested, thus the lowercased main entries. After the current auth-bib linking work, the plan is to do a non-propagating auth reingest, which will clear up those remainders |
16:18 |
bshum |
Good ol' https://bugs.launchpad.net/evergreen/+bug/1091885 |
16:18 |
pinesol_green |
Launchpad bug 1091885 in Evergreen "Reingest bib needs to deal with missing metabib.record_attr entries" (affected: 2, heat: 12) [Medium,Confirmed] |
16:19 |
kmlussier |
eeevil: OK, I though they said a full authority reingest had been done, but they have misunderstood. |
16:36 |
kmlussier |
eeevil: I don't know if this makes a difference, but the lowercase display was not for the main entries. It was only for the unauthorized headings. If the auth-auth script reingested the unauthorized heading, shouldn't those be displaying in proper case? |
16:36 |
kmlussier |
Sorry if I'm missing something obvious. |
16:42 |
|
finnx joined #evergreen |
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 |
dbwells |
eeevil: yboston: I've been in meetings all afternoon, sorry. The upgrading section of the docs is pretty generic. The salient instructions about reingesting are dumped to screen at the end of the big 2.5.0 upgrade script. |
17:02 |
yboston |
dbwells: good to know |
17:03 |
dbwells |
I do think it makes sense to get that info into the docs as well. |