| 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 :) |
| 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. |
| 00:17 |
Guest40233 |
I'm curious...what does Evergreen need to know about RDA? |
| 00:17 |
Guest40233 |
^bshum dbs |
| 00:21 |
bshum |
dcook: Well, the thing we're working on is some new work to show more RDA 264 tag elements in the catalog. Thing is, we don't have any sample bib records in our test dataset that ships with Evergreen that include 264 (or other RDA tags) |
| 00:22 |
bshum |
dcook: dbs' idea is to get some sample bibs that do contain these new tags into our test dataset so that future testing / work with RDA can be checked using those test bibs. |
| 00:22 |
dcook |
Mmm. Fair enough. I can certainly get behind that idea. |
| 00:22 |
dcook |
It would be nice to have a quintessial RDA record set |
| 00:22 |
dcook |
Man, that wasn't even spelled anywhere near correctly |
| 01:02 |
dcook |
It makes showing multiple 264s a breeze. At the moment, I don't think we differentiate between the different types of 264, but it would be a trivial change to make. |
| 01:02 |
dcook |
In any case, sleep well! |
| 01:57 |
|
zerick 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> |
| 07:38 |
|
akilsdonk joined #evergreen |
| 08:05 |
|
Dyrcona joined #evergreen |
| 08:07 |
Dyrcona |
So, I get daily promotional emails from Packt Publishing because I've bought some ebooks directly from them in the past. |
| 08:44 |
* bshum |
wonders how this became popular again |
| 08:48 |
Dyrcona |
bshum: If its there, someone will use it. |
| 08:48 |
bshum |
I suppose that's true. |
| 08:48 |
dbs |
bshum: to follow up on your convo with dcook, no, koha doesn't have a sample set of RDA records; I always load sample records from Evergreen's test datasets into Koha :) |
| 08:49 |
bshum |
Dyrcona: Maybe we need something in Questions on LP like what jcamins did for our issues tracker in github: https://github.com/evergreen-library-system/Evergreen/issues/9 |
| 08:49 |
bshum |
But to subtly point people at the lists |
| 08:49 |
dbs |
The "trawl LoC for sample RDA records" approach could work, although it's not as though LoC hasn't made errors before. |
| 08:50 |
Dyrcona |
dbs: I can throw some records with some of the 264 data at you. |
| 08:50 |
Dyrcona |
OCLC be damned. :p |
| 08:51 |
dbs |
Some is better than none. |
| 08:51 |
Dyrcona |
I'll see if I can dig up the IDs of the two or three that I used for testing. |
| 08:52 |
* dbs |
also hopes, like bshum, that the 3xx were taken into account with all the MVF/CRA stuff |
| 08:53 |
* dbs |
peers with interest at http://www.loc.gov/standards/mods/mods-conversions.html - nope, still no MARCtoMODS3.5 XSLT |
| 08:54 |
dbs |
Although there is an RDAtoMODS3.4 XSL (as in, Excel spreadsheet; and it's horrible) |
| 11:54 |
csharp |
mmorgan: that assumes that you chop your logs up by date/hour like we do |
| 11:56 |
mmorgan |
csharp: Thanks, that's helpful. Yes we do chop them up by hour. |
| 11:57 |
csharp |
mmorgan: you can also search the threadtrace in the activity.log (assuming that's there too) |
| 11:59 |
Dyrcona |
mmorgan: Circulation code is a mess, I see things going through it 3 and four times, even when testing and I know I only checked it in once. |
| 12:00 |
Dyrcona |
mmorgan: There's a) too much logging and b) too much bouncing back and forth among different methods. |
| 12:00 |
mmorgan |
yes, activity is there, too. I get a single line from activity for one of these threadtraces, and a whole bunch of stuff going on with the other one. |
| 12:01 |
mmorgan |
I know we have had a few situations where the same item was captured by two different holds. That's what brought me to this. |
| 12:59 |
|
hbrennan joined #evergreen |
| 13:03 |
|
fparks joined #evergreen |
| 13:27 |
eeevil |
dbwells: just a head's up, if gmcharlt's fixed field seed data ends up getting into 2.6.0, that needs to come /before/ the MVF/CRA conversion dance, so that the existing values are seen as controlled instead of uncontrolled |
| 13:39 |
* csharp |
really dislikes "does program X work with Evergreen?" questions |
| 13:39 |
csharp |
my pat answer is "test it and see" |
| 13:42 |
tsbere |
csharp: My first desire is to turn around and say "Does it have any reason to interact with the ILS directly?" For example, "Does Office work with Evergreen?" Well, since it doesn't actually interact with Evergreen at all to begin with.... |
| 13:47 |
_bott_ |
Reporter creates .xls files, so yes. In a 7 degrees of Kevin Bacon kinda way. |
| 13:48 |
jeff |
i need to work on guidelines for transitioning some willing initial staff members from "one account for all" to "this is my patron account" and "this is my staff member account" |
| 13:48 |
|
bibliophylum joined #evergreen |
| 13:51 |
csharp |
tsbere: this particular question is more about extending the OPAC with vendor widgets |
| 13:51 |
tsbere |
csharp: Ahhh. That can be more complicated and/or annoying. <_< |
| 13:51 |
csharp |
usually both in my experience ;-) |
| 13:52 |
csharp |
and I'm usually dealing with it after a library has purchased said service on the breezy assurances of the vendors |
| 13:52 |
csharp |
rather than after a rigorous test, which I'm happy to coordinate on our end ;-) |
| 13:53 |
csharp |
at least this particular library asked ahead of time, so I should be happy, not complaining |
| 13:53 |
* csharp |
is just tired today |
| 13:54 |
csharp |
jeff: are you doing that in a software-based way, or from a "this is my staff card, but *this* is my patron card" way? |
| 13:55 |
_bott_ |
jeff: we chose to transition unwilling staff into "this is your only account and you'll like it" |
| 13:58 |
* tsbere |
would like to move to *either* of those setups at MVLC, but can't |
| 13:59 |
bibliophylum |
Hey folks... I'm trying to explain to non-technical bosses what the implications of Heartbleed on Evergreen systems are. I've already covered, "we're aware of this *because* it's open source" and "no, there's no way of telling if a system was targeted", and "yes, it's patched". Any thoughts/tips? |
| 14:46 |
gmcharlt |
tsbere: on the face of it, looks much nicer than an attribute reingest |
| 14:49 |
eeevil |
agreed. purty |
| 14:49 |
gmcharlt |
tsbere++ |
| 14:50 |
* tsbere |
almost finds the WITH block abuse scary, though |
| 14:53 |
tsbere |
eeevil / gmcharlt: I very lightly tested it. Was thinking it might be best set up as a cron job, but not sure. |
| 14:53 |
jeff |
for evergreen specific impacts, if your ssl-speaking front-ends were apache linked against a vulnerable version of openssl, it was trivial to steal recently used session keys as well as cleartext credentials for recent logins. (or not-so-recent in terms of "wall clock time" if the target system was idle). |
| 14:54 |
* eeevil |
grumbles about CHAP ... ;) |
| 14:54 |
* Dyrcona |
just read some articles saying that exploits may have been circulating as long as last November. |
| 14:55 |
jeff |
if your front end was pound or nginx linked against a vulnerable version of openssl, i make no assertions because i didn't test that. :-) |
| 14:55 |
jeff |
we were happily on squeeze for ssl-speaking production systems. :-) |
| 14:57 |
Dyrcona |
'Ow nice for you. |
| 15:24 |
|
ldwhalen joined #evergreen |
| 15:54 |
jboyer-isl |
Does anyone else have any issues with Clark processes piling up around midnight (when most "I don't care when" reports are run)? Ours can creep up to 40+ processes a night, triggering an icinga alert almost daily. (we only run with -c 5, so that's over 8x the expected number of processes) |
| 16:55 |
jcamins |
(where body is a placeholder for the element, and styles might be called style) |
| 16:55 |
jcamins |
dbs: BTW, Laurentian's catalog looks fine without JS. |
| 16:55 |
jeff |
bshum: "swivels!" -- talk about missing some context. hopefully you didn't have a terrible run-in with an AMH/sorter? :-) |
| 16:56 |
* jcamins |
just tested it to see if TPAC handled no-JS pleasantly. |
| 16:57 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 16:57 |
bshum |
jeff: I was just remarking where dbs mentioned avoiding JS as much as possible and how berick and senator at the hackaway two years ago had thoughts about more swivels with JS to smooth out the transitions in record summary |
| 16:57 |
bshum |
For the added content, etc. |
| 16:57 |
Dyrcona |
jcamins: That was kind of the point of TPAC, no JS. |
| 17:41 |
|
ldwhalen joined #evergreen |
| 17:41 |
|
atlas__ joined #evergreen |
| 17:48 |
hbrennan_at_lunc |
It's possible I may be hungry |
| 17:51 |
gmcharlt |
hbrennan_at_lunc: enjoy testing that hypothesis empirically! |
| 18:27 |
dbs |
gmcharlt: I believe it's possible to issue multiple requests per Read API request; travelling back in time to when I was talking with the OpenLibrary folk about their rate-limiting etc |
| 18:28 |
dbs |
I brought up the exact same point: "So, you're not rate limiting the Read API, but I end up making _more_ requests than via the Cover API?" They agreed that was silly. |
| 18:28 |
gmcharlt |
dbs: I've verified that is is; possibly something for mark 2 of my patch for bug 1306258 |
| 17:35 |
dbwells |
Well, we've been teetering on the edge of a 2.6.0 release for a while now. Anyone wishing to push us over, please do: https://launchpad.net/evergreen/+milestone/2.6.0 |
| 17:37 |
yboston |
bshum: also, movie bib records also tend to be slighly different than books, often they don't have 1xx fields and I guess in this case they have a distributor and not a publisher> |
| 17:37 |
yboston |
? |
| 17:37 |
dbwells |
I wish I could recreate the acq bug, so I could have a bit more confidence that we've solved it, but I just don't have a test server big enough right now. |
| 17:38 |
bshum |
yboston: I could see that. I'm trying to trace back where in the code this might have gone off the rails. |
| 17:38 |
bshum |
I have an idea. |
| 17:38 |
bshum |
dbwells: I wish we could have tested it more fully too. Other than the limited, "seems to work" that we quickly did |
| 17:38 |
dbwells |
The acq bug is the only true blocker, at the moment at least :) |
| 17:39 |
bshum |
dbwells: I have nothing new to add to it at this time though :\ |
| 17:40 |
yboston |
bshum: feel free to post the bug if you want, but if not I will do it tomorrow morining (need to finsish somehting else tonight) |
| 17:50 |
pinesol_green |
[evergreen|Dan Wells] LP#1304559 Fix slow Vandelay-based imports - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=d42fbec> |
| 17:50 |
pinesol_green |
[evergreen|Ben Shum] LP#1304559 - stamping upgrade script for vandelay_record_attr_to_flat - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=f1fa38c> |
| 18:02 |
|
jboyer-isl joined #evergreen |
| 18:05 |
bshum |
Huh |
| 18:05 |
bshum |
args.pubinfo = "$args.pubplace $args.publisher $args.pubdate"; |
| 18:05 |
bshum |
But then later on, it also sets |
| 18:05 |
bshum |
args.pubinfo = (args.pubinfos.size) ? args.pubinfos.0 : ''; |
| 18:06 |
bshum |
So wouldn't that mean that it'll replace pubinfo with the results from the graphic_880s hunt for tags 260 and 264 |
| 18:06 |
bshum |
Which is probably why it doesn't narrow it to only 264 with ind2=1 |
| 18:07 |
|
csharp joined #evergreen |
| 18:09 |
* bshum |
ponders this more. |
| 18:17 |
bshum |
Yep, I think that's the problem |
| 18:20 |
bshum |
Maybe we should just explicitly name all the different parts pubplace, publisher, pubdate in the results, same as we do for record. |
| 18:20 |
bshum |
And skip this combined pubinfo, and reserve that for the 880s dance |
| 18:21 |
|
Dyrcona joined #evergreen |
| 18:23 |
bshum |
At that point, if we desired, we could add Dyrcona's additional RDA 264 definition types as other things to be displayed in the more details instead of publisher, etc. but with the right designations. Distributor instead of publisher, and so forth. |
| 18:24 |
bshum |
Hmm |
| 18:25 |
|
Dyrcona joined #evergreen |
| 18:43 |
bshum |
And boo, dbs is right, there are no 264 samples in the test data. |
| 18:43 |
bshum |
Guess we really ought to make several to test all the variations out. |
| 18:45 |
bshum |
Maybe after dinner. |
| 18:45 |
bshum |
@monologue |
| 18:45 |
pinesol_green |
bshum: Your current monologue is at least 16 lines long. |
| 18:57 |
bshum |
Hmm, maybe an IF publisher, ELSIF distributor, and down the list of potential 264 types for results... |
| 19:24 |
|
csharp joined #evergreen |
